Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2020-06-17

00:15:19***Saving seen data "./dancer.seen"
00:22:00 Join ecs [0] (esawady@d2evs.net)
00:32:43 Quit Coolguy1260 (Remote host closed the connection)
01:00
01:10:06 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01:14:37 Quit ZincAlloy (Ping timeout: 258 seconds)
01:26:46 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:9130:240b:ed19:66b4)
01:28:27 Quit ZincAlloy (Client Quit)
02:00
02:15:20***Saving seen data "./dancer.seen"
03:00
03:10:21 Quit Guest60959 (Quit: All for nothing)
03:11:45 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr)
03:16:28 Join petur [0] (~petur@rockbox/developer/petur)
03:58:04 Join langest [0] (~langest@185.200.118.106)
04:00
04:15:21***Saving seen data "./dancer.seen"
04:46:56edhelasgot an issue on Debian with rbutils
04:46:56edhelas$ ./RockboxUtility
04:46:56edhelas./RockboxUtility: error while loading shared libraries: libcryptopp.so.8: cannot open shared object file: No such file or directory
04:47:09edhelason testing it seems that there's only libcrypto++6/testing,now 5.6.4-9
04:50:33gevaertsYes. People are looking at that, I don't remember the exact status
04:51:22gevaertsOn Debian, you can work around the issue by installing libcrypto++8 from snapshot.debian.org
04:51:59gevaertsLast time I tested, I used http://snapshot.debian.org/archive/debian/20190811T225353Z/pool/main/libc/libcrypto%2B%2B/libcrypto%2B%2B8_8.2.0-1_amd64.deb
04:56:11 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:00
05:01:35edhelasthanks, will try it :)
05:28:06 Quit S|h|a|w|n (Read error: Connection reset by peer)
05:38:23 Quit livvy (Ping timeout: 240 seconds)
05:39:09 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
05:48:42 Quit beencubed (Ping timeout: 258 seconds)
05:50:29 Join beencubed [0] (~beencubed@209.131.238.248)
05:57:28 Join TheSphinX_ [0] (~briehl@srv001.nosupamu.de)
05:58:14 Quit TheSphinX^ (Ping timeout: 256 seconds)
05:59:45 Join TheSphinX^ [0] (~briehl@srv001.nosupamu.de)
06:00
06:02:22 Quit TheSphinX_ (Ping timeout: 260 seconds)
06:03:43 Quit langest (Quit: Leaving)
06:15:26***Saving seen data "./dancer.seen"
07:00
07:56:56 Quit livvy (Remote host closed the connection)
07:57:54 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
08:00
08:08:18 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
08:08:53 Join massiveH [0] (~massiveH@ool-18e4eaeb.dyn.optonline.net)
08:15:30***Saving seen data "./dancer.seen"
08:27:41 Join MrZeus [0] (~MrZeus@89-168-118-226.dynamic.dsl.as9105.com)
08:46:20 Join vmx [0] (~vmx@ip5f5ac60f.dynamic.kabel-deutschland.de)
09:00
09:07:40 Quit Frans-Willem (Ping timeout: 256 seconds)
10:00
10:09:30 Quit massiveH (Quit: Leaving)
10:15:33***Saving seen data "./dancer.seen"
10:58:43 Join dys [0] (~dys@tmo-123-80.customers.d1-online.com)
11:00
11:50:15 Quit petur (Quit: Connection reset by beer)
12:00
12:15:35***Saving seen data "./dancer.seen"
12:53:49Horrorcatheyho
12:54:03Horrorcatso I’ve that clip zip with rock box on it, but I don’t think this is device specific
12:54:44Horrorcatspecifically, sometimes when hitting the "next" button repeatedly (e.g. when skipping an ad in a podcast using skip length set to 5 seconds or something), it will jump to the first track in a completely different folder
12:55:08Horrorcat(in this very unfortunate case, my wife is accidentally triggering this feature during migraines, and unfortunately the first track in that folder it jumps to is death metal by amon amarth. not helping at all ;D)
12:55:21HorrorcatI was wondering if this is a config setting I overlooked, a bug or something else entirely
12:55:30Horrorcatauto-change directory is set to No
12:56:19Horrorcatit does not happen always. I got the impression, without being able to validate it completely, that it correlates with holding "next" for a while to skip a longer section, releasing, and then hitting it again immediately
12:56:30Horrorcat(this is always far away from the end of track btw)
13:00
13:05:38speachycan't say I've ever seen that.
13:05:58speachyare you playing from a playlist, or did you just hit play in the podcast directory?
13:06:27Horrorcatthe latter (so a dynamic playlist)
13:06:37HorrorcatI wonder if this is a hardware glitch and what is being triggered is in fact ACTION_WPS_ABSETB_NEXTDIR
13:07:00Horrorcatreading the source, this can lead to change_dir -> audio_next_dir
13:07:17speachyI've never seen it jump out of the current playlist.
13:07:20HorrorcatACTION_WPS_ABSETB_NEXTDIR can be triggered by BUTTON_NEXT|BUTTON_POWER
13:07:32Horrorcat*BUTTON_RIGHT|BUTTON_POWER I meant
13:08:03HorrorcatI’ll try to trigger that one intentionally when I have the device in my hands again
13:08:14Horrorcatand if it’s that, I’ll simply patch it out :)
13:08:28speachywell, it could be a hw glitch, yeah, especially if it's being operated under migraine conditions
13:09:13speachyIIRC the sansas use a scanned gpio array for input
13:10:03Horrorcat(I also have observed this when operating the device without looking at it in my pocket and stuff, so unintentional triggering of the power button is certainly plausible)
13:10:44Horrorcatother than that, I can’t find any codepath leading to a directory change from BUTTON_RIGHT, so I suppose it’s that
13:10:53Horrorcatthanks for being my rubberduck today, #rockbox :)
13:10:58HorrorcatI’ll report back once I get a chance to test it
13:11:02speachyyeah, the clips are pretty tiny and it's all too easy to fat-finger it
13:11:36*Horrorcat pours a cup of sacrifice in memoriam of his iriver h320
13:11:47Horrorcatserved me well for about a decade, RIP
13:13:32 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr)
13:46:39 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
14:00
14:15:38***No seen item changed, no save performed.
14:30:26 Quit vmx (Ping timeout: 256 seconds)
14:40:39 Quit Moarc (Read error: Connection reset by peer)
14:44:04 Join Moarc [0] (~chujko@a105.net128.okay.pl)
15:00
15:55:19__builtinmendel_munkis: what's the rationale behind adding the extra layer of indirection to accessing the framebuffer?
16:00
16:09:35 Join tchan1 [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net)
16:10:17mendel_munkis__builtin: in order to insure that the plugin can run no matter what framebuffer is currently active
16:10:39 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
16:11:14 Join XDjackieXD_ [0] (~jackie@tureis.comfix.cc)
16:11:15mendel_munkisI also hope to make the plugin not need to know the screen size although I'm not sure how practical that is.
16:11:42__builtinyeah, a lot of stuff assumes that LCD_WIDTH/HEIGHT are known at compile-time
16:11:47 Join megal0ma1iac [0] (~root@104.248.101.37)
16:12:28mendel_munkisI figure at a minimum removing that requirement from the plugin API is a good thing
16:12:46__builtinnot much use in isolation, though - is it?
16:13:29__builtinalso, just to clarify - the indirection is there in case core code sets a different framebuffer that's not lcd_static_framebuffer?
16:13:43mendel_munkismostly
16:14:44mendel_munkis__builtin: its mostly meant as an incremental step towards more screen dynamicism
16:15:39***Saving seen data "./dancer.seen"
16:18:52 Join emacsoma1 [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
16:18:54 Quit tchan (*.net *.split)
16:18:54 Quit J_Darnley (*.net *.split)
16:18:54 Quit emacsomancer (*.net *.split)
16:18:54 Quit XDjackieXD (*.net *.split)
16:18:54 Quit megal0maniac (*.net *.split)
16:36:02 Quit Tsesarevich (Ping timeout: 244 seconds)
16:39:00 Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx)
16:41:00speachyIMO getting rid of non-lcd-core things that directly interact with the static fb is good
16:45:54 Quit ZincAlloy (Quit: Leaving.)
16:47:46 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
16:48:44 Quit Tsesarevich (Max SendQ exceeded)
16:52:37 Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx)
16:57:14 Quit Tsesarevich (Ping timeout: 240 seconds)
17:00
17:01:48 Join krabador [0] (~krabador@unaffiliated/krabador)
17:02:24 Join vmx [0] (~vmx@ip5f5ac60f.dynamic.kabel-deutschland.de)
17:06:21__builtinhmm, makes sense to me then
17:11:09 Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx)
17:13:42 Quit Natch (Ping timeout: 256 seconds)
17:17:27 Join Natch [0] (~Natch@c-b471e255.014-297-73746f25.bbcust.telenor.se)
17:32:53 Quit vmx (Quit: Leaving)
17:34:15pamaurybluebrother: I was thinking about the crypto++ situation on Windows, I don't know if you have acted on this, there is actually a simple solution: on Windows we can just use the Crypto API
17:36:38blbro[m]1That would be nice for Windows but it's still a major problem on MacOS.
17:37:52blbro[m]1I did have a short look into libtomcrypt which looks promising. Especially since it's C things become a lot easier.
17:42:11pamaurygood point, just in case, this is the code I have for Windows: https://gerrit.rockbox.org/r/#/c/2422/
17:42:21 Quit krabador (Quit: Leaving)
17:45:32 Quit lebellium (Quit: Leaving)
17:52:05speachyFWIW, I'd support moving to libtomcrypt.
18:00
18:13:09speachyseems rather nuts to have two or three different crypto paths when all we're doing is mucking with aes-ecb, sha1, md5, and des primitives.
18:15:30 Quit sakax (Quit: Leaving)
18:15:42***Saving seen data "./dancer.seen"
18:20:29 Quit tchan1 (Quit: WeeChat 2.8)
18:21:05 Join tchan [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net)
18:21:05 Quit tchan (Changing host)
18:21:05 Join tchan [0] (~tchan@lunar-linux/developer/tchan)
18:23:38 Quit MrZeus (Ping timeout: 260 seconds)
18:37:03 Quit ZincAlloy (Quit: Leaving.)
18:50:14 Join MrZeus [0] (~MrZeus@89-168-118-226.dynamic.dsl.as9105.com)
18:52:25fs-bluebotBuild Server message: New build round started. Revision a29ddc1, 292 builds, 9 clients.
19:00
19:04:40 Quit pamaury (Ping timeout: 246 seconds)
19:08:36fs-bluebotBuild Server message: Build round completed after 969 seconds.
19:08:37fs-bluebotBuild Server message: Revision a29ddc1 result: All green
19:34:34 Join bonfire [0] (~bonfire@2601:680:c400:3ad0::bcd6)
19:45:28speachyExcellent. That commit made it to the -cvs mailing list.
19:45:36speachyand onto gmane.
19:55:34 Quit MrZeus (Read error: Connection reset by peer)
20:00
20:12:46 Join MrZeus [0] (~MrZeus@89-168-118-226.dynamic.dsl.as9105.com)
20:15:44***Saving seen data "./dancer.seen"
20:26:15 Quit MrZeus (Read error: Connection reset by peer)
20:29:10 Quit scorche (Read error: Connection reset by peer)
20:33:59 Join scorche [0] (~scorche@rockbox/administrator/scorche)
20:36:19 Join MrZeus [0] (~MrZeus@89-168-118-226.dynamic.dsl.as9105.com)
21:00
21:12:22 Join amiconn_ [0] (jens@rockbox/developer/amiconn)
21:12:23 Nick amiconn is now known as Guest14837 (jens@rockbox/developer/amiconn)
21:12:23 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn)
21:12:32 Quit pixelma (Ping timeout: 256 seconds)
21:12:43 Join pixelma [0] (marianne@rockbox/staff/pixelma)
21:12:57 Quit Guest14837 (Ping timeout: 260 seconds)
21:30:16 Quit MrZeus (Ping timeout: 246 seconds)
21:59:51 Quit dys (Ping timeout: 260 seconds)
22:00
22:01:15 Join MrZeus [0] (~MrZeus@89-168-118-226.dynamic.dsl.as9105.com)
22:15:46***Saving seen data "./dancer.seen"
22:32:17 Nick emacsoma1 is now known as emacsomancer (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
23:00
23:01:12 Quit ecs (Excess Flood)
23:01:20 Join ecs [0] (esawady@d2evs.net)
23:16:36 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
23:19:12 Quit advcomp2019 (Ping timeout: 256 seconds)
23:52:47 Quit [7] (Ping timeout: 260 seconds)
23:52:58 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)

Previous day | Next day