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).

#rockbox log for 2011-07-31

00:01:54sideralkugel: and what do you think of it?
00:05:33***Saving seen data "./dancer.seen"
00:06:04 Quit funman (Ping timeout: 260 seconds)
00:07:17kugelpsideral: I can have a go
00:07:55kugelpmy repro recipe doesn't work for you?
00:08:16 Join Jotunn [0] (
00:09:29 Join robin0800 [0] (~robin0800@
00:14:08 Join lixxus [0] (
00:14:26kugelpsideral: ^
00:20:48sideralkugel: Unfortunately I don't have an SD card ready to try it with. And my DB-based recipe is not reliable enough
00:21:02 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
00:25:48 Quit Jotunn (Ping timeout: 276 seconds)
00:26:30sideralah, found an SD card
00:27:05sideraland... your recipe works on my Fuzev2 (but I haven't applied the d_names offset patch yet)
00:27:41 Quit efyx (Remote host closed the connection)
00:28:40siderallet me update to current first and see whether I can still reproduce it, then I'll try the patch...
00:29:04kugelI assume it's the "does not fit into previos" path because dircache info shows "last size" correctly
00:29:20kugeland only if last size is 0 then it goes through a complete build
00:29:37kugelthe patch doesn't help, for me anyway
00:29:56 Quit robin0800 (Ping timeout: 250 seconds)
00:30:02sideralYeah... I'll apply it right away :)
00:30:45 Quit jhMikeS ()
00:32:47kugellast_size is also bigger than the reserve buffer in my case
00:32:53kugelso yes, it should really go into that path
00:33:18sideralOK, I can still reproduce it
00:34:18kugelno wait
00:34:33kugelI think last size is slightly less, but bigger including the sd contents
00:34:44sideralthe only strangeness I found in that path was that allocated_size was set to a fixed value, and that d_names_end is way beyond dircache_root + allocated_size. But that doesn't appear to be a problem
00:35:44kugelahhh. last size is 65700, reserve is 65500
00:35:54sideralOn my Fuze I can see which path is taken by looking for the "scanning disk" splash
00:36:02kugeli see that too
00:36:15kugelwhich means it goes through the thread, no?
00:36:31sideralmain() shows that only if the last size is 0, in which case dircache rebuilds in the foreground
00:36:52sideralI think :)
00:38:04kugelthen the dircache info screen shows last_size wrongly
00:38:22 Part lixxus
00:38:32sideralmaybe it shows the "current" last size
00:38:46sideralthe one being used for the next dircache_build call
00:40:14siderallet me try disabling compaction...
00:41:30kugelsideral: I think I have a solution
00:41:41sideralyeah? :)
00:42:03 Quit bertrik (Read error: Connection timed out)
00:42:25 Quit kevku (Ping timeout: 260 seconds)
00:42:30 Join bertrik [0] (
00:42:30 Quit bertrik (Changing host)
00:42:30 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
00:42:39sideralI'll try, but I'm not convinced this will work :)
00:43:09sideralthe 2nd hunk is semantically equivalent. that was my confusion before
00:43:13kugelseems to work for me
00:43:23kugelyes, I thought so too
00:43:37kugelbut now I didn't think but just tried if it does anything :)
00:44:23sideralI verified in the debugger that the 2 expressions yield the same value. Why wouldn't they on a target?
00:44:46 Join jhMikeS [0] (
00:44:46 Quit jhMikeS (Changing host)
00:44:46 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
00:45:48kugelI've no fking idea :)
00:51:49 Quit mudd1 (Quit: Ex-Chat)
00:51:50sideralkugel: confirmed: it works.
00:52:08sideralI like the new expression much better than the older one anyway :)
00:52:30kugelme too
00:52:39kugelI don't know why I didn't do it in the first place
00:52:59kugelhowever since we both thought it's equivalent to the old one we should perhaps figure out why it isn't?
00:53:00sideralmaybe entry_count is wrong for some reason?
00:54:24sideralperhaps the counting is one difference between the native and hosted implementations?
00:55:59sideralno, it's only ever incremented in allocate_entry
00:58:30 Join BHSPitLappy [0] (~BHSPitLap@unaffiliated/bhspitmonkey)
00:58:36kugelI have a suspiciion
00:58:41kugelline 339+
00:58:56kugelI think dircache_size is one too small
01:00:01kugel%d is 2 byte, "1" is 1 byte, so sizeof(VOL_NAMES) != snprintf()+1
01:01:18sideralshouldn't it rather be dircache_size += sizeof(VOL_NAMES)?
01:01:45sideralthat's how much d_names_start is decremented
01:02:08kugelthat's why I suspect
01:02:56 Join Jotunn [0] (
01:03:01kugelright. that seems to work too
01:03:05sideralthat also explains why it works in the sim
01:03:16kugelhowever, += sizeof(VOL_NAMES) isn't entirely correct
01:03:37kugelwill be wrong for the 100th sd card :)
01:04:04kugelVOL_NAMES is just the format string, it's not what actually goes into the buffer
01:04:32sideralI think it will be correct for dircache_size. it's just that the string buffer can overflow :)
01:05:03kugelthe string that snprintf builds is smaller
01:05:05 Nick Jotunn is now known as Jotun (
01:05:07sideralbecause that's how much d_names_start is decremented
01:05:11kugelbut you don't know beforehand
01:05:16 Part Jotun
01:05:31kugelyes, I'm saying decrementing by sizeof(VOL_NAMES) isn't entirely correct
01:05:54sideralI see what you mean
01:08:02sideralbut I cannot be bothered to fix it tonight :)
01:08:09kugelah, clever, the correct thing is VOL_ENUM_POS+3
01:08:25kugelthat's after the format string and after the resulting string at the same time
01:08:43kugel(this is what it did before my commits too)
01:09:05kugelah no
01:09:20kugelI was confused, it's flawed the same why as sizeof(VOL_NAMES)
01:11:10kugelbut I don't feel like calculation log10 for the volumes :)
01:13:15 Join Jotun [0] (
01:13:51sideralFamous last words: "99 volumes ought to be enough for anybody"?
01:14:43kugelmore than the 26 in the windows world :)
01:15:45*kugel commits the fix
01:16:50sideralyay! great work kugel!
01:17:37 Join Keripo [0] (
01:20:44sideraland, kugel, rethink that plan to introduce even more moving allocations into Rockbox once more please! ;)
01:20:57kugelno, why?
01:21:15kugelmoving is easier than compacting :)
01:21:44kugelI don't remember the details of your proposal but IIRC it doesn't solve the limitations we have now
01:21:48 Join funman [0] (~fun@rockbox/developer/funman)
01:22:00CIA-14New commit by kugel (r30224): Dircache: Fix 2 nasty bugs introduced with the reworks starting with r30032. ...
01:22:44sideralwhich limitation did it not address?
01:23:37kugelnot being able to dynamically allocate memory for the entire runtime
01:24:05kugelas I said I dont remember the details of your proposal
01:24:21kugelI'm not even sure I remember it at all. wasn't it about setting memory aside at boot?
01:24:50sideralno, I suggested to introduce dynamic allocation on two levels:
01:25:08kugelit's to late to rethink my project, and it was on the gsoc page for many years without complaint
01:25:25sideralthe first one would alloc large, fixed-size chunks. the audio buffer would be composed of multiple/many of these chunks.
01:25:45sideralthen there could be one or more allocators for allocating smaller objects in these chunks
01:25:48CIA-14r30224 build result: 1 errors, 1 warnings (kugel committed)
01:26:29kugelthat isn't actually an error! (and not mine anyway)
01:26:44sideralthis would allow freeing large regions as a whole, without any fragmentation except for chunking and any remaining internal fragmentation
01:27:26sideralI am not at all against your project, but I think it's vastly more complex and hard to get right
01:27:29kugelthis doesn't allow freeing
01:28:10*gevaerts thinks that any solution that still suffers from fragmentation is bound to be problematic in the long term
01:28:16kugelfreeing does also mean that it can be re-used, e.g. by the audio buffer, which cannot have holes
01:28:22sideralit does: the dircache could release its chunk(s) as a whole if so desired
01:28:27kugeland it wastes lots of memory
01:28:36 Quit ender` (Quit: An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it is also more nourishing. -- H. L. Mencken)
01:28:59kugelsideral: _releasing_ is easy, even with the current system, re-using for other purposes not so much
01:29:00sideralthe audio buffer already supports jumps (it's a ring buffer after all), so extending it to multiple equal-sized buffers doesn't sound especially hard
01:29:29sideralyeah, hence the idea to standardize the unit of allocation
01:29:36kugelit's a ring buffer which doesn't support holes
01:29:44sideralnot yet, right ;)
01:29:59kugelthat it can "jump" because it's a ring buffer has nothing to do with that
01:30:49sideralyeah, it's kind of a stretch :) but I wanted to illustrate the complexity of supporting non-contiguous streams
01:31:00kugelI don't think a chunk size makes it particularly more easy
01:31:06gevaertssideral: the problem as I see it is that some allocations are very large compared to the total RAM size. If you have *any* fragmentation, you'll end up not being able to allocate those
01:31:17 Quit pamaury (Remote host closed the connection)
01:31:40sideralgevaerts: I'd define the tradeoffs differently
01:32:29sideralI'd be willing to tolerate some internal fragmentation (unused parts if chunks) in exchange for less complexity. And I suspect supporting movable allocations will be a killer
01:33:16kugeldircache is a different beast; the problems where do to compacting, not moving. plus it worked a lot differntly before my rework. plus it has many code paths for building
01:33:26sideralAlso, that fragmentation could be reduced quite substantially by having one high-level allocator that's shared among the various clients needing small allocations, or by introducing slab caches
01:33:28kugelall those don't apply to plain moving
01:34:29sideralI'd say the dircache problems highlighted exactly the problems to expect from moving allocations:
01:34:53sideraldangling pointers and buffer miscalculations
01:35:01kugelI analized the code base. other allocations are very different
01:35:24kugelmiscalculations can happen regardless of moving
01:35:52kugelthe one I just fixed was in fact completely unrelated to moving or compacting
01:36:01sideralwell, we're adding a whole new class of miscalculations: forgetting to move object pointers along with an alloc move
01:36:41kugelyes, that's where you need to be careful, but I have my analysis about those
01:36:50sideralno, it was totally related: two dangling pointers and an off-by-something buffer size computation error
01:36:56kugelI don't disagree that it adds complexity
01:37:03gevaertssideral: I don't see problems with *small* allocations (apart from some loss due to fragmentation), but on lowmem targets there can be allocations that are 30% or 40% (I don't have exact numbers) of the total free RAM. If you can't move those, you're suddenly in a situation that you can't enable the database, voice, and audio speedup unless you happen to enable them in exactly the right order. That's no fun
01:37:03kugelbut also adds a lot of value
01:37:36gevaertsUnless there's something I'm not seeing
01:38:19 Quit neferty (Quit: ohshi-)
01:38:34sideralgevaerts: I think that issue would be covered by mandating a fixed allocation size. Clients would allocate multiple chunks around the unmovable chunk allocations in the middle.
01:39:17kugelallocate around a movable middle?
01:39:18sideralkugel: sure, if we can get it to work, it will be great. but I'm afraid of the cost
01:39:20 Join neferty [0] (~andor@
01:39:27kugelthat you didnt propose before
01:39:36kugeland that also sounds very complex to implement to me
01:39:39sideralunmovable, not "movable"
01:39:41 Quit stripwax_ (Quit:
01:39:50kugelunmovable, sorry
01:40:07kugelsideral: I like the challenge :)
01:40:25 Nick Jotun is now known as Jotunn (
01:40:26gevaertssideral: I don't really see how saying you allocate in 10K blocks instead on byte blocks changes anything
01:40:36*kugel neither
01:40:41 Part Jotunn
01:40:46kugelexcept you waste 9k when you need 1k
01:40:59sideralthe way it would work is that the tagcache (for example) would allocate multiple chunks if one wouldn't suffice. the tagcache consists of lots of rather small objects that can be allocated by a higher-level allocator sitting on top of multiple chunks, and they don't have to be contiguous
01:41:29kugelwhat would be the exact advantage of that chunk size?
01:41:51kugelnothing is gained if allocation can span multiple chunks, no?
01:42:07sideralgevaerts: this helps because there cannot be fragmentation below the chunk size that everyone uses
01:42:32kugelI don't see that
01:43:15sideralif the tagcache needs more space (to commit, for example) its high-level allocator allocates more chunks. afterwards, it frees them again. the fragmentation afterwards will not be increased
01:43:21kugelI can imagine it would perhaps help if chunks don't need to be consecutive for a single allocation, but that's not the case
01:43:30gevaertssideral: what sort of chunk size do you have in mind?
01:43:37sideralI'd imagine a chunk size of 64KB or larger
01:43:39kugelsince you need chunks next to each other the result is the same
01:44:07sideralkugel: No, that's the point: you don't need chunks next to each other
01:44:29kugelthen you need all clients to teach about holes in their allocation
01:44:47kugelwhich is just a lot of more effort than making them movable
01:44:51*gevaerts isn't at all sure that the added complexity for supporting non-contiguous blocks is less than that for supporting moving
01:44:53sideralonly the ones that desire larger contiguous allocations. which would be p
01:45:03sideralmainly the pcm driver?
01:45:26sideralgevaerts: I have a very different intuition that yours
01:45:38gevaertsYes, clearly :)
01:45:43sideralalmost all allocator clients need smaller objects
01:45:59kugeltherefore 64k wastes a lot
01:46:22sideralcorrection: almost all allocator clients need *lots of* smaller objects
01:47:06sideralhigh level allocators can alloc many of them in one chunk, per client. and clients can free chunks as a whole (e.g. when reloading the database or dircache)
01:47:08kugelwe have allocations with 12k, 20k, 40k
01:47:19kugeland as I said, about 15 in total
01:47:35kugelyou're suggestion to throw a away like 100-200k
01:47:47kugelwhich is about half of the clipv1 entire free ram :)
01:48:21sideralI suggest to find a chunk size that makes sense :)
01:48:22kugelthen you suggest to make the others aware of discontigous allocs which is probably more work than making them movable
01:50:10sideralThat's where I disagree :) there isn't much teaching to be done. The alloc clients actually use many small objects, which they today carve out of one large buffer by hand
01:50:47sideralthey'd allocate those from their chunks. the clients don't need their small objects to be contiguous
01:51:22kugelso, all clients need to implement a small allocator too
01:51:26kugeleven more work :)
01:51:56sideralwell, they could probably share one chunk-based small-object allocator, but use different chunks
01:52:05sideraldepends on their requirements, really
01:52:36sideralanyway, my gut feeling is that this is vastly less work than supporting moving allocations in all alloc clients
01:52:48kugelI don't share this feeling
01:53:02kugeland I have done a throughout analysis on the entire code base
01:53:58sideralI hope you're right! But I think we got a taste of what's coming in the past few weeks
01:54:12kugelanyway, no matter of what we discuss, I'll continue with my work because there's simply not enough time left to even consider a strategy change
01:55:16sideralthat's fine! I certainly won't attempt to block any of your work. But I'm scared of it anyway ;)
01:55:27kugelI understand you're bitter because those bugs were tricky to find and existed for quite some time because I couldn't look earlier
01:55:39 Quit bertrik (Read error: Connection timed out)
01:55:40kugelbut those aren't really all related to moving
01:56:12 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
01:56:55sideralI'm not bitter at all. I agree that we're better of with dircache compaction, and that would have been coming without movable allocations
01:57:13sideralbut I think it highlights the problem areas that will become more prominent
01:57:15 Quit bertrik (Client Quit)
01:57:50kugelso we now know better what we need to be careful about. that's profit :P
02:05:34***Saving seen data "./dancer.seen"
02:29:55 Join antil33t [0] (
02:43:46 Quit antil33t ()
03:04:55 Join robin0800 [0] (
03:09:40 Quit robin0800 (Client Quit)
03:10:43 Join robin0800 [0] (~robin0800@
03:27:50 Quit funman (Ping timeout: 258 seconds)
03:50:55 Quit GeekShadow (Quit: The cake is a lie !)
04:05:36***Saving seen data "./dancer.seen"
04:07:06 Quit [7] (Disconnected by services)
04:07:18 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
04:07:39 Quit Keripo (Quit: Leaving.)
04:13:47 Quit robin0800 (Ping timeout: 252 seconds)
04:14:01 Join parafin [0] (
04:17:36 Join robin0800 [0] (
04:22:24 Quit sideral (Quit: Leaving.)
04:28:18 Quit ReimuHakurei_ (Read error: Connection reset by peer)
04:28:23 Join ReimuHakurei [0] (
04:31:45 Quit robin0800 (Ping timeout: 260 seconds)
04:38:28 Join ReimuHakurei_ [0] (
04:40:02 Quit ReimuHakurei (Ping timeout: 276 seconds)
04:49:07 Quit amiconn (Disconnected by services)
04:49:09 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:49:14 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:49:46 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:49:46 Quit pixelma (Disconnected by services)
04:50:07 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04:51:20[Saint]bertrik: for the logs... "%?mv<%pvdB|%?pv<%xd(IDENTIFIERsubidentifier)|.......>" would do it.
04:51:40[Saint]But, for what its worth I'm against this change unless ll other cabbies get this feature as well.
04:52:06[Saint]*all other
04:52:33[Saint]I don't see any point in having a default theme if there's going to be differences between the targets.
04:52:48[Saint]*s/differences/major differences/
04:55:02 Join timccc1 [0] (~aoeu@
04:57:50 Quit timccc (Ping timeout: 250 seconds)
04:58:22 Join antil33t [0] (
05:02:26 Quit BHSPitLappy (Ping timeout: 250 seconds)
05:03:36 Quit antil33t ()
05:09:58 Join antil33t [0] (
05:25:58 Nick bluefoxx_ is now known as bluefoxx (fuzzylomba@2002:4647:1f1f::4647:1f1f)
05:36:32 Join mystica555_ [0] (
05:42:20 Join hskf [0] (
05:43:06 Join Rob2222 [0] (
05:46:39 Quit Rob2223 (Ping timeout: 246 seconds)
05:56:24 Join Keripo [0] (
06:00:20 Quit mystica555_ (Ping timeout: 255 seconds)
06:05:39***Saving seen data "./dancer.seen"
06:15:54 Quit hskf (Quit: Textual IRC Client:
06:23:24 Join Horscht [0] (~Horscht@xbmc/user/horscht)
06:26:38 Quit Horschti (Ping timeout: 276 seconds)
06:54:15 Quit antil33t ()
06:55:20 Quit user890104 (Remote host closed the connection)
06:55:33 Join user890104 [0] (~Venci@
06:58:42 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier.
07:23:16*[Saint] wonders why there's not a hint of anything Android on
07:23:47[Saint]...the Maemo and Pandora ports are listed.
07:47:57 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.)
07:50:10 Join [Saint] [0] (~Saint]
07:51:52[Saint]Is albumart display known broken in the SDL app?
07:52:26[Saint]I can't seem to get it to display, despite embedded AA and Folder.jpg being present.
08:02:46mc2739[Saint]: it needs to be folder.jpg
08:05:40***Saving seen data "./dancer.seen"
08:12:15[Saint]mc2739: "Folder.jpg and folder.jpd are both fine.
08:13:14[Saint]The directory that I am playing music from via the SDL app is my iPod, where the AA works fine.
08:14:50[Saint]as for Folder vs. folder, afaik this makes no difference.
08:28:13mc2739[Saint]: i thought the search was case sensitive, but I may be thinking back to when jpg album art was first added
08:29:50[Saint]Well...all my AA is named "Folder.jpg" (as this is a common convention for desktop media players) and works fine.
08:30:07[Saint]...except in the SDL app, apparently :-S
08:30:44mc2739where are you running the SDL app?
08:31:11[Saint]On my desktop.
08:31:26[Saint]btw, I also used Folder.bmp pre-jpg AA iirc.
08:31:43mc2739windows or linux?
08:32:28mc2739linux is always more case sensitive than windows
08:32:57 Join mystica555_ [0] (
08:33:34mc2739you might just try renaming for no other reason than to rule it out as a cause
08:40:32 Join T44 [0] (
08:43:32[Saint]Yep...that's it. Seems rather a crappy limitation.
08:43:55[Saint]Why is it only the SDL app seems to care about this?
08:44:07 Quit Topy (Ping timeout: 255 seconds)
08:44:42[Saint]RaaA and any of the targets running ROckbox natively couldn't give a crap apparently.
08:44:48[Saint]*Rockbox too
08:52:08 Quit user890104 (Remote host closed the connection)
08:52:19 Join user890104 [0] (~Venci@
09:15:30 Quit Keripo (Read error: Connection reset by peer)
09:17:43 Join Keripo [0] (
09:28:48 Join stoffel [0] (
09:29:00 Quit sasquatch (Quit: WeeChat 0.3.5)
09:29:27 Join sasquatch [0] (
09:37:48 Join evilnick [0] (~evilnick@rockbox/staff/evilnick)
09:48:14 Join bluefoxx_ [0] (
09:50:49 Quit bluefoxx (Ping timeout: 260 seconds)
09:57:27 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
09:59:00kugelp[Saint]: it's the Linux file systems that are case sensitive.however we should be able to fix this on our end
09:59:42kugelpI noticed this ages ago on the sim
10:03:07 Join bertrik [0] (
10:03:07 Quit bertrik (Changing host)
10:03:07 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
10:03:40 Join bluebrother [0] (
10:03:40 Quit bluebrother (Changing host)
10:03:40 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
10:05:43***Saving seen data "./dancer.seen"
10:06:01 Quit fs-bluebot (Ping timeout: 255 seconds)
10:07:12 Join fs-bluebot [0] (
10:07:37 Quit bluebroth3r (Ping timeout: 276 seconds)
10:21:34 Join antil33t [0] (
10:24:12 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
10:54:03 Join ender` [0] (
10:57:02 Join otih [0] (~otih@2a01:4f8:100:9ff6:1::2)
10:57:02 Quit otih (Changing host)
10:57:02 Join otih [0] (~otih@CAcert/Assurer/otih)
11:15:04 Quit antil33t ()
11:31:32 Quit saratoga (Ping timeout: 252 seconds)
11:39:47 Join sideral [0] (~sideral@rockbox/developer/sideral)
11:45:34 Join Buschel [0] (
11:47:05 Quit stoffel (Ping timeout: 258 seconds)
11:52:46*[Saint] considers scrapping the recently added +/- buttons on the volume popup.
11:52:57Buschelis there anyhting speaking against submitting a first step of FS #12176 ?
11:52:58fs-bluebot New Chiptune codec pack based on Game_Music_Emu library ;) (patches, unconfirmed)
11:53:17Buschelfirst step = minor changed v03-patch as the latest do not compile
11:53:50Buschelthis will bring in some more synthesizer codecs
11:53:59Buschelnon optimized, but working
12:04:25kugelBuschel: he addressed my concerns of the previous patches
12:04:53kugelbut he didnt answer one question of mine
12:05:46***Saving seen data "./dancer.seen"
12:05:56kugelI also don't understand the changes to codecs.[ch]
12:07:37kugelwell, seems to be the same thing after all. sgc.c opens a bios file for which the patch enables file I/O functionso for non-encoders
12:12:19 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
12:13:25 Join stoffel [0] (
12:13:46 Quit user890104 ()
12:14:56Buschelkugel: if you mean the author did some changes _after_ v03 which you were asking for, which were these?
12:16:09kugelBuschel: I posted a comment
12:16:44Buschelwhich one do you mean exactly?
12:16:58kugelthe one from 5 min ago :)
12:17:12*Buschel presses F5
12:17:32kugelflyspray doesn't like f5 :)
12:18:02Buschelworked fine here :) but you shouldn't do F5 after any you did a change to the task :)
12:21:45kugel[Saint]: no body ever complained about the db display, so it was wanted
12:22:15kugelbut it apparently can't be done incrementally because it just doesn't happen (as it didn't when it was in svn previously)
12:22:41kugel(re: FS #12213)
12:22:42fs-bluebot Cabbie v2 for 128x64x1 (sansa clips): show volume in dB when changing volume (patches, new)
12:23:21[Saint]that's the problem with "I want this change, but I'm only prepared to do it on X target"
12:24:02[Saint]then someone like myself feels obligated to "fix" things.
12:24:16Buschelkugel: the bios-file thing is interesting. but it does not seem to be used at all. I just commented the coleco_bios array and the corresponding code
12:24:25Buschelstill works
12:24:33[Saint]I've really got shit all time, and I feel bad for it. Its a trivial change but I don't have the time to do things I want to work on :-S
12:25:49 Quit skx` (Ping timeout: 252 seconds)
12:26:06 Join skx` [0] (
12:29:23[Saint]kugel: My main concern was that I thought it was removed intentionally as none of the other cabbies had this feature.
12:29:46[Saint]If it was indeed removed accidentally, then by all means it should go back...but I'd really like to see it go in for all targets.
12:30:02kugelIIRC bertrik removed himself with the 128x64x1 unification
12:30:36kugelwe still complained to JdGordon that he made it initially only for one wp
12:30:55kugelso I'm not sure we should accept the same thing again
12:31:25[Saint]I recall pixelma and myself discussing making this change for all cabbies if time was found during DevCon, but I have only just remembered this I guess no time was found.
12:32:55[Saint]If I actually knew my schedule these days, by all means I would volunteer to do this. But I'm not certain I could, nor could I promise to, have it done in any reasonable time frame.
12:36:21kugelbtw, how's the 320x480 port of your cabbie going?
12:38:28[Saint]Almost there. I'm hoping to find some time to work on it this evening. It seems as though every time I get some free time (of think I do) <something> happens.
12:38:48Buschelkugel: the sources thell that the ffect of not being able to load this BIOS file is failing support for Colecovision SGC-files −− "Master System" and "Game Gear" SGC's will work though
12:39:10Buschelgood enough imho
12:40:30kugeldid anyone else review the patch?
12:40:38kugelother than testing it?
12:41:09Buschelsaratoga made some comments regarding IRAM optimizations, but I am not sure here had time to review the patch
12:41:11kugelprobably difficult to do because it's a C++ to C conversion of foreign code
12:41:38kugelyes, I read comments about premature optimizations but not about review :)
12:43:03kugelI think perhaps at least the non-gme portions should be looked at. looking at a couple dozen of cpu emulators is boring
12:43:08*Buschel sees several "//" comments
12:43:16Buschelin rockbox specific files
12:43:22Buschelof this patch
12:47:16kugelBuschel: do you try with files and such a metadata containing playlist in the sam folder?
12:48:57kugeli wonder how that integrates
12:50:23Buschelkugel: sorry, I don't get your question
12:51:54kugelBuschel: it's apparently common to store metadata about tracks in a playlist file in the same directory (non-standard .m3u)
12:52:09kugelbecause the files have crappy tags
12:52:15kugel(if at all)
12:52:32Buschelkugel: I do not use .m3u's at all
12:53:01kugelsee how all the metadata parser call gme_load_m3u()
12:55:13kugeland my comments in one of the previous tasks
12:57:48Buschelkugel: what do you think about the gme_m3u-stuff? should this be removed in the first step?
12:58:08kugelno, not removed :)
12:58:24 Quit stoffel (Ping timeout: 240 seconds)
12:58:43kugeli just wonder how it integrates into the ui etc
12:59:55kugelfrom the other tasks it appeared to me that supporting these m3us for metadata is essential for these formats
13:00:18 Join mudd1 [0] (
13:00:45Buschelas you pointed me towards this m3u-stuff: I don't like the idea to have a more or less "generic" m3u implementation only used for libgme codecs
13:01:06Buschelthe test files have metadata within the files themselves
13:02:11Buschel(not all of them though)
13:03:55 Quit [Saint] (Remote host closed the connection)
13:04:23BuschelI am definately pro removal of gme_m3u
13:05:18 Join [Saint] [0] (
13:05:51kugelBuschel: but it contains metadata for the tracks which cannot be in the files directly as I understood it
13:09:37Buschelwell, I am not sure about this m3u-stuff. If this is a gme-specific solution I do not like to have this in rockbox. gme just provides decoders for several formats. if the formats themselves do not carry all metadata, we might just miss this info. the author might provide this m3u-speciality with an additional patch to be discussed and decided independantly
13:10:54Buschelbaah, too many typos :/
13:12:44 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
13:13:50kugelpi don't know anything about these formats, but I'm not against parsing an extra file for metadata in the metadata step
13:14:09kugelpif that's what's usual for those formats
13:14:46Buschelwe do not do this at all in our metadata handling, and it sounds like a specific workaround solution
13:16:17kugelpit was in the codecs in the previous patches/tasks. to that I objected
13:18:05kugelpit's perhaps a good idea to remove it from this patch and discuss it in a separate one
13:18:23 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
13:19:07*Buschel is just working on such updated patch
13:22:47sideralDoes anyone know who owns the account? I'd love to have this as our official git mirror that people can clone from (especially after the Gerrit migration)
13:23:40 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
13:24:22rashersurely the official should be on
13:25:08sideralrasher: yeah. but there should be a semi-official mirror to allow people to create a github fork from easily
13:25:35sideralTorne said it would be no problem for Gerrit to push to any number of mirrors
13:27:11*sideral sends a message to the account owner
13:30:40kugelrasher: it appears we won't host such forks
13:31:49kugelso the idea is we push to some mirror which is read-only for others and let github host forks
13:42:52CIA-14New commit by kugel (r30225): Move AFMT_MPA_L1 down in the enum as hwcodec can't play it. ...
13:47:18 Join stoffel [0] (
13:48:27CIA-14r30225 build result: All green
13:50:54 Quit mystica555_ (Remote host closed the connection)
13:57:40 Join stripwax [0] (
14:02:36Tornei would really prefer that people *don't* use github :)
14:02:44Tornethe github workflow is terrible
14:03:11pamaurywhat is the github workflow ?
14:03:26Tornepublishing everything constantly such that you can't sanely rebase ever
14:03:49Torneand it introduces another way for people to send changes to us :)
14:03:53Torne(sending github merge requests)
14:04:56sideralTorne: there has to be a way to fork stuff on github, so we better provide one. Or else people will clone old/outdated stuff and run into problems later
14:05:46Tornewhy does there have to be a way?
14:05:48***Saving seen data "./dancer.seen"
14:06:29sideralbecause it's the hosting service people do use. and apparently "we" don't want to provide hosting for patches/forks anymore
14:07:15sideralobviously, we won't accept merge requests there unless we ever switch over to it officially :)
14:07:30Torneso that's introducing another way to submit changes that we will ignore, yes
14:07:38Tornethat doesn't sound like a feature :)
14:07:47sideralanyway, I'm taking you up on your own offer to push to a mirror there :)
14:08:13gevaertsCan't people clone from non-github repositories on github?
14:08:31gevaertsIf not, that sounds like lock-in to me, which I'd see as a good reason not to use them
14:08:40Tornenot usefully, no
14:08:46Torneyou can clone from our repo and then push it to github
14:08:49sideralgevaerts: of course that's also possible, but not with a single mouse click. It's a hassle
14:08:55Tornebut that involves downloading the whole thing and then uploading it again
14:09:02TorneTheir server side magic only works with things they are hosting
14:09:51sideralgevaerts: Github is not very locky-inny. It's easy to migrate stuff elsewhere. It just provides convenient hosting and collaboration
14:10:04sideralin a way that Rockbox doesn't :)
14:10:05Torneanyway. my point is just that the way github pretty much forces you to work is generally the *opposite* of the ways we have discussed :)
14:10:14 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
14:10:44gevaertssideral: only allowing easy cloning from repositories hosted on github is not my definition of "convenient collaboration"
14:11:03sideralTorne: We have discussed that "we" don't want to provide hosting for patches/forks. This has to happen somewhere.
14:11:08TorneNo, it doesn't
14:11:21TorneYou seem to be missing a major point here :)
14:11:33TorneEither we care about someone's branch and it can go on our server, or we don't
14:11:52sideralTorne: Do you want me to dig out the chat log where you say you'd be willing to push to github?
14:12:19Tornei don't see the relevance
14:12:24sideralTorne: This is for stuff "we" don't care about, aka not ready for commit, but useful to have for some
14:12:45gevaertsI also honnestly don't see how we are no longer providing hosting for forks
14:13:01TorneIsn't this just reopening the argument about people wanting to have a repository of patches that aren't being merged on FS?
14:13:24sideralyes, it is, in a way.
14:14:26TorneIf we go to the trouble of maintaining an official mirror of the code on github then people are going to expect to be able to use github's tools to work with us
14:14:42sideralgevaerts: I ran into major opposition here for wanting to keep hosting patches that aren't ready for commit on FS, and was told Gerrit is not for this
14:14:57TorneTHat doesn't mean pick something else to do it
14:15:04gevaertssideral: that's patches. You also said forks
14:15:05TorneTHe point is that we don't want to fulfil that "need" at all
14:15:23sideralTorne: that's nonsense. Lots of projects have a mirror on github, and it's what people expect.
14:15:31 Join Poodlemastah [0] (
14:16:10kugelI'm with sideral here
14:16:13sideralgevaerts: "fork" is just Github speak for someone private, but publicly visible repo, which is akin to what we call a patch
14:16:21TorneNo, it isn;t
14:16:27gevaertssideral: it's not. It's very different
14:16:28kugelif doesn't host my fork then I need another place for it
14:16:30TorneThere's a big functional difference between a patch and a fork repo
14:16:39Tornekugel: who said it wouldn't?
14:16:59Torneno I didn't.
14:17:22kugelI asked you whether we'd have a space for our own repos (not branches), and you said that's not going to happen
14:17:34TorneHaving your own repo is stilly
14:17:37Torneer, silly
14:17:41TorneWhy would you want that?
14:17:58Torneif you *can* have a branch in the real repository then it's better in every way
14:18:06Tornethe only need to have a seperate repository is if you don't have permission..
14:18:16*kugel doesn't want to discuss now with someone who declares my favorite work flow silly
14:18:28TorneYou can work *exactly the way you chose*
14:18:36TorneA repository is not a unit of anything except storage in git
14:18:48TorneYou can work *identically* with a set of branches in a repo vs a seperate repo
14:18:48sideralTorne: with git, everyone has his own repo on his machine.
14:19:17Tornesideral: Right, but ones that are not published are uninteresting
14:19:30kugelTorne: I don't want to mess with the official repo all the time or mind about namespace collision with branches
14:19:37Tornekugel: why not?
14:19:44TorneAnd there's no namespace collisions
14:19:45kugelI don't want to
14:19:49kugelsimple as that
14:19:52Tornedone ;)
14:19:55sideralSome are not interesting for Rockbox, but need to be discoverable / available anyway. That's what external repos are for
14:20:02Tornewrite a refspec for your local copy which uses that
14:20:12Torneyou now have something that looks and behaves exactly like a fork on github
14:20:12kugela separate repo is easier to handle for me and everyone else
14:20:19Torneexcept it's hosted on our server and uses less space
14:20:22kugelwithout that strange refs/X/Y/Z thing
14:20:34TorneEr, I don't think you understand how git works very well then :)
14:20:42Torneall repositories work the same way
14:20:52TorneIt happens that the default on clone is to clone refs/heads/*
14:20:55sideralAnyway. I think it's a fact some people want to host on Github. And we should provide a semi-official repo for cloning. That also saves disk space for Github users
14:21:00Torneyou can just pass a different argument to clone and get something different
14:21:28kugelTorne: can I ask you to be more open towards how other people want to use git?
14:21:42gevaertssideral: why should we care about diskspace on systems with obvious design flaws like not allowing external cloning?
14:21:42sideralIt a matter of managing expectations to educate users which workflows will work and which don't
14:21:56TorneI am pointing out that the system we already have supports the exact workflow you want
14:22:04sideralgevaerts: it does allow external cloning. It's just a git hoster with some extra features
14:22:19Tornethat's the opposite of stopping you using it how you want, surely :)
14:22:23kugelTorne: my workflow includes a repo just for me
14:22:39gevaertssideral: then exactly what is the problem?
14:22:57sideralTorne: Yes, it does, but it doesn't make my personal branches discoverable and maintainable (with bug tracking and such) as Github does
14:23:14Tornesideral: How doesn't it?
14:23:19TorneThey are perfectly discoverable
14:23:47Tornethey're right there on the server, you can just look
14:24:12sideralgevaerts: I've been told "we" don't care for third-party extensions (today hosted as patches in FS) with no chance for quick commit any more. This has to be hosted somewhere.
14:24:29gevaertssideral: then clone on github!
14:24:36Tornethat's not true
14:24:42TorneIt doesn't have to be ready to be committed
14:24:50Tornethe point is to not host stuff that *will not* be commited
14:24:55Tornenot to stop you from working on things
14:24:57Tornethat would be stupid
14:24:58sideralgevaerts: that's what I want to do. The most convenient thing is to clone from a github-hosted mirror, and that's what this discussion is about
14:25:14kugelTorne: we happen to have stuff that's not going to be committed
14:25:25kugelyes, we shouldn't host that. but we want to host it somewhere
14:25:36gevaertssideral: so the reason is "Github misses an obvious feature, so we'll bother every single open source project in existence and ask them to do extra work"?
14:25:58*Torne notes that Launchpad handles this just fine for bzr hosting, btw :)
14:26:00gevaertsI'm not against a github mirror as such, but I'd like people to be honest about the reasons...
14:26:07Torneit just maintains its own mirrors of other people's repositories
14:26:13Tornewhich you can then cheaply clone on launchpad :)
14:26:20Tornei am not sure why github doesn't do this
14:26:50sideralgevaerts: You're missing the issue of disk quotas. Forking a github project doesn't use any quote there.
14:27:07*gevaerts whispers to kugel and sideral: "having a clone on github provides a convenient backup in case we have network or disk problems"
14:27:52Torneit just seems like an attractive nuisance :)
14:28:56TorneOK, look: whether we had a mirror on github or not I would expect that committers would use our own resources.
14:28:57 Quit Poodlemastah (Quit: ChatZilla 0.9.87 [Pale Moon 5.0-x64/20110624114230])
14:29:01gevaertssideral: I'd argue that that's the same issue really. Github could easily make sure to only have one copy of every remote, and share the disk quota cost between cloners
14:29:11sideralthis whole discussion would be pointless if we were willing to maintain the "patches" FS category. If we would, then in the future this would refer to a branch on Gerrit instead of hosting the patch directly on FS
14:29:12kugelI'm hosted. I want a repo for my stuff even if it's just for sharing code between computers. stuff that's not hosted on our repo because it's not going to be committed
14:29:23TorneI find it very odd that you would want to use github instead of our own infrastructure, since you are committes and will have permission to do so
14:30:01sideralgevaerts: it could, but it doesn't. bitching about it is rather pointless
14:30:04kugelTorne: because we don't want to host not-going-to-be-committed stuff
14:30:31sideralTorne: The mirror's not just for me, but especially for noncommitters
14:30:39gevaertssideral: yes, which brings us back to "Why should *we* work around badly designed third party systems?"
14:30:52sideralBut I also like to host/mirror my stuff elsewhere, like kugel
14:31:21sideralgevaerts: To make it more convenient for Github users, which happens to be the #1 hoster for open source today
14:31:24Tornekugel: i personally don't care waht you feel like putting into a ref namespaced by your name..
14:31:27sideralfor a reason, mind you
14:31:42Tornesideral: We want to *very strongly* encourage those noncommitters to actively work with us and work towards getting their code into our tree
14:31:57Tornethat's much of the point of this :)
14:32:08sideralTorne: That would be preferable. But it's not the reality.
14:32:11TorneGIving them a bunch of alternatives doesn't seem like a great way to achieve it
14:32:26Tornewhat do you mean?
14:32:32sideralThe reality is that even committers host tons of useful patches in FS that people actually use.
14:32:35kugelwhy does github prevent this in any way?
14:32:38sideralThis includes gevaerts, BTW :)
14:33:00gevaertssideral: excuse me? Which patches do I have on FS that are not meant for inclusion?
14:33:18sideralThe reality also is that often patches need to simmer for years before they can be committed.
14:33:41Tornekugel: maintaining an attractive nuisance
14:34:50Tornekugel: giving people an alterantive option which works completely differently from the way we would like people to do things
14:35:16*Llorean thought one of the arguments *for* moving to Git was "stop patches from sitting around not in the official repository and create an environment of 'get them committed soon, or dispose of them'"
14:35:33sideralgevaerts: I haven't said they're not meant for inclusion, but they're *old*. But w/o a repo such as FS or github, I wouldn't have been able to find them.
14:35:54kugelyou say "the way we would like people to do things" as if we now magically have such a way we not?
14:36:20kugelI, for one, don't want to impose any workflow on others
14:36:22Tornei thought we were pretty settled in that regard
14:36:46kugelwe settled on gerrit yes, but I don't see how github stands in the way there
14:37:17 Join y4n [0] (y4n@unaffiliated/y4ndexx)
14:37:44Tornebecause having branches in different repos in github where people do their development makes it significantly less sensible and convenient to post patches for review? ;)
14:37:46sideralgevaerts: I could also say: if they were meant for inclusion surely you would have completed them? ;)
14:38:06gevaertssideral: right, I should go and close the things really...
14:38:28sideralgevaerts: No, you shouldn't. You're providing value by having them available.
14:39:47sideralgevaerts: for example, I plan to complete FS #11619 ... eventually ... unless you finish it first ;)
14:39:47fs-bluebot Restore pitch and speed settings on resume (patches, new)
14:39:48amiconnIf someone wants a clone on github, then he could do that. But I'm with Torne that it should definitely not be an official one.
14:39:53kugelTorne: I don't believe so
14:40:28Tornekugel: have you tried rebasing things on github? :)
14:40:29sideralamiconn: I'd like it to be "official" in the sense that our Gerrit repo mirrors to it
14:40:30kugelpeople can still make clones on github, with or without our mirror
14:40:34 Join user890104 [0] (~Venci@
14:40:45kugeland use all the github features with other forks
14:40:54sideralTorne: rebasing is not an issue on Github, I do it regularly
14:40:54gevaertssideral: I assume you mean FS #11619 and FS #11644?
14:40:55fs-bluebot Restore pitch and speed settings on resume (patches, new)
14:40:55fs-bluebot Playlist isn't loaded after reboot if it had ended (patches, new)
14:41:01Tornesideral: you are mistaken
14:41:06kugelif we provide a mirror we can at least keep track of that more easily
14:41:15kugeland make life easier for the forks because of shared quota
14:41:19Torneas with *all* published git branches, if you rebase them you break everyone downstream of you
14:41:48sideralgevaerts: yeah, that's the ones I'm most interested in
14:42:09Torneif there's nobody downstream of your repository then you won't notice a problem, but then that kinds defeats the point of hosting it publicly if nobody is looking anyway :)
14:42:21kugelTorne: it doesn't
14:42:26gevaertssideral: to be honest, I can't remember why I haven't committed FS #11644 yet...
14:42:27fs-bluebot Playlist isn't loaded after reboot if it had ended (patches, new)
14:42:29sideralTorne: often there is no one downstream :)
14:42:33kugelit's not only about playing upstream for someone else
14:42:37Tornethen why publish it?
14:43:09kugelsharing between computers, for example
14:43:10sideralTorne: just as with patches: to allow people to make use of the stuff, and for backup/sync purposes
14:43:24Torne"People making use of the stuff" == someone downstream
14:43:25 Quit fs-bluebot (Quit: timeout?)
14:43:27kugelor a webinterface to view patches/commits/etc
14:43:29 Join fs-bluebot [0] (
14:44:06sideralTorne: Please, I know of the tradeoffs. This discussion isn't about them. It's about convenient repo forking and hosting extensions.
14:44:38amiconnsideral: And the point is that it should not be official because we do want all non-committers to submit patches meant for inclusion through gerrit
14:45:05kugelthat's what going to happen
14:45:13 Quit user890104 (Ping timeout: 250 seconds)
14:45:19kugelwe're not going to do merge requests on the mirror
14:45:23kugelit's read-only
14:45:27gevaertsamiconn: you objected to speed and pitch settings in nvram as implemented in FS #11619. The idea I had in mind was that pitch and speed are restored on reboot, but are reset when starting a new playlist (which is why it isn't a setting). In general, I'd like reboot to be as transparent as possible.
14:45:28fs-bluebot Restore pitch and speed settings on resume (patches, new)
14:45:29sideralamiconn: again, this is for stuff that has no chance of being committed, for various reasons, like many of the patches we today host as FS patches
14:45:38Torneif people do that at the same time as having development on github then they are going to break their *own* repositories because of rebases :)
14:46:15Lloreansideral: Any patch on flyspray that has no chance of being committed, should've been removed during a cleanup. If it hasn't, that's an error, not intentionaly
14:46:50LloreanFlyspray has long been under a policy of "only for stuff working towards being committed"
14:47:22sideralTorne: I don't have time all day to go into the minutiae. Would you be willing to push to an external git mirror, such as on Github, like you offered a few weeks ago, or are you blocking this now?
14:48:25Tornei'm not blocking anything..
14:48:28 Quit Keripo (Quit: Leaving.)
14:48:44sideralLlorean: I've had this discussion with others before, and I know I'm in the minority here. But I for one would like to have some place that can host extensions not ready for inclusion, because I personally derive value from many of those patches on FS. If FS/Gerrit don't host it, it will have to live elsewhere. Github is an obvious option for that
14:48:47Tornei'm making a suggestion
14:49:02*gevaerts feels that maybe he should point out that Torne doesn't have (sole, or at all) access to the hosting server :)
14:49:20Tornegevaerts: and i'm not intending to be in charge of these decisions either :)
14:49:21Lloreansideral: So you're saying "I know the project policy is explicitly against this, but I think we as a project should do it anyway?"
14:49:34sideralgevaerts: maybe, but I Torne does have a say in the git migration, I feel ;)
14:49:39amiconnsideral: Yes, and the point is that we do *not* want to host them anymore, officially or semi-officially
14:49:43Tornesideral: no more than anyone else
14:49:50gevaertssideral: surely a mirror is unrelated to the migration?
14:49:51Tornei'm doing the part i know hwo to do, for the benefit of everyone
14:49:56kugelamiconn: we're not hosting it
14:50:21kugelamiconn: it'd be hosted in other people's repos, not in the mirror
14:50:26sideralLlorean: "We" won't. Github will host them. I'm just asking for a mirror there so that people can easily clone/fork
14:50:31LloreanCompletely unofficial hosting of such patches is fine. If they're to be official, you should start up a discussion explicitly on whether we want to start allowing a repository or tracking of not-to-be-included patches somewhere.
14:50:48Lloreansideral: Creating an official mirror there for that explicit purpose is "us" doing it.
14:50:48sideraler, amiconn^
14:50:52gevaertssideral: are you using FS #11644?
14:50:53fs-bluebot Playlist isn't loaded after reboot if it had ended (patches, new)
14:50:55Torneanyway, yes, as gevaerts points out this is not related to the migration at all
14:51:04Tornethere is zero point in providing a mirror on github until the migration is done
14:51:09sideralLlorean: yeah, that's what I want us to do, for this purpose.
14:51:11kugelthat's true :)
14:51:26Tornebecause if it turns out for some reason we need to rewrite the current repo then an existing mirror would break
14:51:33Lloreansideral: So bring up a discussion, on the -dev list, of changing the project policy away from discouraging uncommittable patches.
14:51:41TorneUntil we are actually developing on git instead of svn there's no need to decide :)
14:51:47LloreanRather than making the discussion about github, which requires the policy change, get the policy change first.
14:51:57sideralLlorean: Pushing to a mirror elsewhere should not be this big a deal
14:52:11Lloreansideral: If it's not a big deal, give up on it.
14:52:30LloreanIf it's a big enough deal for you to argue about it this long, surely it is as well for others to be against it.
14:52:31sideralmoving unwanted stuff to github is *implementing* our policy, not new policy
14:52:52Tornesideral: do you not believe that something being done by the project, versus something being done by someone else, leads to different expectations? (serious question)
14:53:54sideralTorne: Sure. But expectations can be managed. And I see no other way for having an up-to-date mirror than the project pushing to one
14:54:11Lloreansideral: one way of managing expectations is not doing it.
14:54:22LloreanIt's much more effective than by doing it but saying "but we encourage you not to use it."
14:55:03sideralI don't see us not encouraging 3rd-party development. That's not our policy.
14:55:13sideralWe just don't want to host it
14:56:02CIA-14New commit by gevaerts (r30226): Reload the current playlist after reboot even if it has ended. (FS #11644) ...
14:57:07gevaertsOK, that leaves FS #11619...
14:57:08fs-bluebot Restore pitch and speed settings on resume (patches, new)
14:57:14Lloreansideral: Ah, no, that may be where the difference in opinion is. We want to encourage people to work on committable stuff. By necessity that means saying "we'd rather you don't work on non-committable stuff." If there's a reason it can't be included, they should be trying to address it rather than ignoring it.
14:58:06sideralLlorean: Most committable stuff starts out as noncommittable stuff, and takes *years* to complete. This is true for many of the "patches" in FS, that "we" don't want to host anymore.
14:58:13gevaertsLlorean: I'm not sure I agree. I think it implies "we'd rather you never tell us about non-committable stuff", which is a bit different
14:58:35Lloreansideral: Anything that starts out as noncommittable but has the intent of reaching committable is "ok to host"
14:58:56Tornethe point is to have stuff be intended to be in rockbox
14:59:03Tornenot that it has to be ready
14:59:10amiconnsideral: That's the point - it does take years, but it shouldn't
14:59:25TorneYeah, there's basicall no reason why anything should take years
14:59:32sideralamiconn: we have no way to change that. We have to accept this reality.
14:59:35Lloreangevaerts: We'd rather you not use some official channel, such as an official mirror, to advertise stuff you know can't be, or don't want to have included in Rockbox
14:59:57*kugel things we should discuss this after the migration
14:59:58rasherWho the hell works for ages on stuff they don't want in Rockbox anyway?
15:00:07gevaertsLlorean: yes, but there's a difference between putting stuff in an official mirror and cloning stuff from an official mirror
15:00:09CIA-14r30226 build result: All green
15:00:11Tornerasher: evidently sideral :)
15:00:17rasherTorne: he's not said that
15:00:21 Join user890104 [0] (~Venci@
15:00:41TorneI guess. People whose patches sideral uses, then, I assume? :)
15:00:53Lloreangevaerts: This is true, but creating an official mirror explicitly for people to be cloning for projects they don't intend to be included is saying "go ahead with them" in advance. It's contrary to asking people "please try to work toward inclusion"
15:01:02rasherTorne: that's not making any sense
15:01:19sideralEven if we'd host unfinished stuff in our git repo, there's still the issue of discoverability and issue tracking. I was explicitly referred to host stuff privately because FS/patches is going to be closed for this purpose.
15:01:31Lloreangevaerts: I mean, for all I know there's some good reasons for having this mirror for things that are intended to be included. Nobody's brought them up yet, though, and I'd like to hear those.
15:01:38gevaertsLlorean: that's why you provide a proper description with the official mirror, such as saying you're only having it for backup purposes :)
15:01:41Tornewhat is the issue for issue tracking?
15:01:43rasherI don't see why we can't just say "We want to use git and gerrit because it'd be awesome", rather than all these weird excuses about patches
15:01:53TorneIf you try out a patch someone is working on and you have feedback
15:01:55Tornepost it on the patch
15:02:00Torneet voila, people can see
15:02:05Lloreanrasher: I think the excuses are more for why "let's close Flyspray" than "let's move to git/gerrit"
15:02:28rasherLlorean: But the excuses are mostly very flimsy
15:02:42rasherSo why not just say "we want to use git and don't want to bother with Flyspray2
15:03:10kugelgevaerts: I sure want a repo for me also for backup purposes
15:03:14Tornerasher: because some people seem to think "using git" means "having all the same processes and workflows that other projects that use git have"
15:03:25Lloreanrasher: Well the main issue isn't git, gerrit, or flyspray. It's "let's create a mirror on github explicitly for the purpose of making it easier for people who don't want to contribute to the project to work on it."
15:03:25kugelI'm not too much after publishing uncommittable stuff for others
15:03:27rasherPeople are making it sound like changing to a different hosting of patches/code means we'll get a brand new set of world class coders
15:03:38kugelbut to have a backup of it, and share between PCs
15:03:42rasherLlorean: I'm talking about the whole switching to git/gerrit process, not this github thing
15:03:56Lloreanrasher: Ah. Well, I thought that was already decided anyway.
15:04:05Torneit is
15:04:11LloreanI don't think the reasoning really matters at this point, since the decision has been made.
15:04:13rasherOh it is. It's the excuses I find sad
15:04:13Torneunless somoene is objecting :)
15:04:25LloreanWe can now say "we like gerrit because its name reminds us of the sounds frogs make" and it's fine.
15:04:28sideralTorne: Didn't you tell me that patches on Gerrit wouldn't be as categorized/browsable as on FS?
15:04:38TorneCUrrently, yes
15:04:49bertrikI thought git was decided and gerrit is still under consideration
15:05:05Tornebertrik: Absolutely nobody has offered any objections since I made the demo available
15:05:07sideralrasher: which of my "excuses" do you find sad, specifically?
15:05:08TorneMonths ago
15:05:15Torneand lots of people have appoved
15:05:15kugelbertrik: nobody considered something else for 2 month :)
15:05:20Torneso that seemed like a conclusion to me
15:05:28rashersideral: Not yours, the "let's move to git/ditch flyspray" excuses
15:05:40Lloreanbertrik: I thought git was decided, and "trying gerrit" was decided. Which isn't the same as committing to it, but without alternatives it will end up as such.
15:05:44TorneWe've not yet actually done anything about moving to gerrit that we can't trivially change our minds about
15:05:52TorneI put the demo up, and that's it
15:06:05TorneAll the other work I ahve done is about converting the history of svn to git, which is the same work whatever hosting solution we use
15:06:12*gevaerts tells people to stop discussing uninteresting stuff and start discussing FS #11619 instead!
15:06:13fs-bluebot Restore pitch and speed settings on resume (patches, new)
15:06:15kugelpeople tend to mix the git switch and flyspray closure together but they're separate discussions and decisions
15:06:16TorneSo yeah, we are not committed to it
15:06:35Tornebut i've yet to hear an alternative proposed, or any objections :)
15:06:46Torneso i'm going with the assumption that we're using it :)
15:06:52rasherkugel: that's because it's being pushed as the same thing
15:07:05Tornerasher: not really; the point is that one *enables* the other
15:07:10sideralkugel: they're connected in that if new hosting for patches is needed, we should host it on some Git place
15:07:22kugelrasher: they happened to be consecutive topics at the devcon, but that's about it
15:07:31kugelthe git switch was decided independantly
15:07:40rasherUsing git and closing flyspray will cause all patches to be instantly committable and candy will fall from the sky
15:07:45Tornerasher: having gerrit as a way to propose, review/discuss, and accept/reject patches is what allows us to sensibly stop accepting patches on FS
15:07:59Torneif we don't do the former, we shouldn't do the latter (unless another alternative comes up instead)
15:08:01Lloreangevaerts: I like the patch, though I would argue that resetting them when starting a new playlist isn't necessarily ideal if you have music intentionally stopped, set pitch/speed, then start a playlist. So "resetting them if they haven't been changed since the last playlist was started, and a new playlist is started" or similar.
15:08:03gevaertsrasher: yes, that's why we want that
15:08:19sideralTorne: except that we'll reject stuff that should be rightfully hosted someplace
15:08:29rasherAs long as I get a cut of the candy
15:08:41Tornesideral: it will be :)
15:09:23sideralTorne: that I'm sure of. the question is just how convenient / discoverable this place is
15:09:24Tornegerrit doesn't delete closed reviews.
15:09:31Tornethat would be silly
15:09:39gevaertsLlorean: if I remember correctly, (and if I see things right) it doesn't currently do that
15:09:44Lloreansideral: Why is it our responsibility to care about how convenient/discoverable patches we don't want are?
15:09:46Torneyou can always upload another version and try again
15:10:10Lloreangevaerts: I like the nvram method. A lot. And I'm fine with it. I'd just like it to go beyond that. To me, it doesn't have to immediately, but it sure would be nice. :)
15:10:13sideralLlorean: because often, after years, a developer will take interest and get it into committable state
15:10:31Lloreansideral: If that's the case, it was a patch we wanted.
15:10:41TorneLlorean: because apparently sideral is the one guy who likes to trawl through FS for ancient patches and finish them
15:10:47LloreanYou don't seem to be distinguishing between "patches we want, but aren't ready" and "patches we don't want."
15:10:52gevaertsLlorean: in what way?
15:11:03Lloreangevaerts: I'm uncertain what you're asking.
15:11:04sideralgevaerts: re FS #11619: I agree with the last comment from fml2
15:11:05fs-bluebot Restore pitch and speed settings on resume (patches, new)
15:11:18gevaertsLlorean: "I'd just like it to go beyond that"
15:11:24Torneargh, can fs-bluebot ratelimit that stuff? :)
15:11:24rasherLlorean: You're making it sound like this is something new. We've never cared about patches we don't want
15:11:30sideralTorne: yes, that's about right :)
15:11:35Lloreangevaerts: I like nvram preventing 'last playlist's speed' from applying to 'this new playlist.' I'd like a sane way for that to happen without a reboot as well.
15:11:40TorneI don't want to ignore it because i like getting the titles
15:11:45Tornebut having it for the same patch over and over is tedious ;)
15:12:00gevaertssideral: yes, I think I agree too. Without that resetting pitch/speed is a bit tedious
15:12:02Lloreanrasher: We delete patches we don't want from flyspray. sideral is now proposing we make it easier for them to be hosted and discovered.
15:12:18gevaertsTorne: you mean like for FS #11619? ;)
15:12:19fs-bluebot Restore pitch and speed settings on resume (patches, new)
15:12:23rasherLlorean: No he's not
15:12:30rasherHe's making the distinction while you aren't
15:12:59Tornegevaerts: hehe
15:13:00*rasher has no interest in this, really
15:13:01 Part rasher
15:13:14*Llorean wonders which distinction rasher even meant.
15:13:40sideralI just wanted to sit back and see you guys interpret me, but rasher has spoiled the fun
15:13:48gevaertsLlorean: I'm confused. Are you saying you want pitch/screen to be settable before starting a playlist, but also that new playlists should reset pitch/speed?
15:13:51LloreanI've said that any patch that intends to be committed should be fine on our gerrit. At least as long as 'closed' patches can be found and reopened. The only ones we shouldn't want there are ones we know we are against including, and then it's not our concern that they can't find easy hosting elsewhere.
15:14:38sideralLlorean: That's a good summary, but I disagree with your conclusion
15:14:46Lloreangevaerts: Yes. If pitch has not been touched since last playback stop, reset it on new playlist. Basically. So if you resume, it stays. If you stop, then adjust it, then start, it applies to the new playlist. Otherwise it's lost.
15:15:21gevaertsMy goal with that patch (not mentioned to avoid fs-bluebot!) really was the same as with FS #11644, i.e. make (especially idle-timeout) reboots as invisible as possible (which I think is invaluable for car-mode)
15:15:22fs-bluebot Playlist isn't loaded after reboot if it had ended (patches, closed)
15:15:23bertrikWhich targets have a 4066 power management chip? I know of the ipod video, ipod nano 1g, ipod nano 2g
15:15:25TorneLlorean: the problem there is that sideral's past objection is that gerrit doesn't make it easy enough to find them because it doesn't have labels (yet). He cares about the categories (database/playback/etc) and the affected players and so on.
15:15:29Lloreansideral: Why should we be concerned about people who want to work toward a project other than our own (which patches not ever to be included are)? It's like hosting a fork.
15:15:30sideralLlorean: I think it is partly our concern, because developers and user alike should be able to discover old / previously unwanted / offbeat stuff
15:15:47Torne(someone is working on making gerrit support arbitrary labels, incidentally)
15:16:02sideralTorne: that's correct as well
15:16:12LloreanTorne: I'm concerned about the categories, etc. But that's valid for *our* patches too.
15:16:29LloreanThat's one of those "arguments that don't require us to change project policy" that I was asking for earlier. :)
15:16:33TorneLlorean: you can search by text, by which files are affected, and a few other things :)
15:16:44Tornelabel support appears to be coming but isn't in the release version yet
15:16:49sideralLlorean: because a good ecosystem with many choices is beneficial even for us.
15:16:50LloreanTorne: Tags would be nice, but I find half the time they're misapplied or vague anyway.
15:17:14TorneI pretty much entirely ignore all the labels on all the bugtracker/etc systems i use
15:17:45Torneanything i can find by label i can generally find just as easily by text searchi
15:18:08sideralwhereas I care about them and maintain them for the stuff I'm interested in
15:18:25Lloreansideral: And if you care about them and maintain them, why should we care?
15:18:37*[Saint] thinks the obvious solution here is for sideral to host these patches. ;)
15:18:39LloreanSaying "it's beneficial for us" to care doesn't tell us what benefit we get.
15:18:42sideralbecause you want me to be productive?
15:18:43[Saint](I'm actually serious, too)
15:18:55Lloreansideral: Ah, yes. We want you to be productive on non-Rockbox projects, so we help you access them?
15:19:30Torneanyway; we have had this entire discussion here before.
15:19:31sideralthis applies to "our" bugs/patches as well, as you noticed
15:19:46TorneTHe people who were at devcon were mostly in agreement htat discoverability is a *problem*, not a *feature
15:19:53Lloreansideral: Yes, and I've stated that my opinion is different in regard to ours.
15:20:07TorneNot having it means people who want a given change have to make an effort to push it forward :)
15:20:07sideralSaint: I want to host them ... on Github, hence this discussion
15:20:33[Saint]I think the discussion came from using the word "official"
15:20:38[Saint]as, it won't be.
15:20:39Lloreansideral: But you haven't been using that as the basis of your argument. Are you giving up on "non-Rockbox patches" now or will you answer the question I had in regard to them and how it's beneficial to us to encourage people to not work on Rockbox?
15:20:45sideralI never expected people would be opposed to pushing to a mirror there
15:20:51gevaertsLlorean: I'd say your use case (i.e. setting pitch/screen before starting) is probably rather important to some people, so a dumb reset on new playlist would count as a regression...
15:21:16Lloreangevaerts: Yes. That's why I suggested some logic (though I have no idea how easy/difficult to code) that would address it.
15:21:27gevaertsI'm thinking about it :)
15:21:52Tornesideral: i don't think anyone is flat out opposed to it, but we are questining the point/value of bothering, and questioning your motivation for wanting it somewhat :)
15:21:56sideralLlorean: I already answered, I thought: I like us being able to draw from 3rd party stuff when we're ready to, hence it's good to maintain a good ecosystem for 3rd-party development
15:21:59LloreanTo me, pitch changes should apply to "current playlist only" if playing, and "next playlist only" if stopped.
15:22:24Lloreansideral: And third party stuff we'd like to draw from should be in our patch tracking system *anyway*. As I've said countless times now.
15:22:38Lloreansideral: Why are you refusing to distinguish between things we consider "we may want" and things we actually reject?
15:22:47gevaertsWe'd have to set a flag when setting pitch if playback is not active, and checking/clearing that when starting
15:22:50gevaertsI think
15:23:19Lloreangevaerts: To be fair, I don't use pitch at all outside of having tried it out. I just tried to assume the use case I was afraid might get trampled.
15:23:32gevaertsLlorean: same for me, actually :)
15:24:02sideralLlorean: because it's been made clear to me that Gerrit is not for hosting 3rd-party stuff (with no qualification as to whether we might *eventually* want it or not)
15:24:38Lloreansideral: What do you mean by "third party?" The term, to me, means "anything not made by the first party (Rockbox developers)." I'd say we want anything intended for inclusion, including 3rd party patches.
15:24:51 Quit mystica555 (Read error: Operation timed out)
15:24:59Tornei think you are drawing entirely the wrong distinction
15:25:11LloreanI'd be surprised if anyone's been saying "nobody can put patches up except existing Rockbox developers"
15:25:16TorneIt's not for *permanently* hosting *anything* (other than our trunk and release branches)
15:25:43TorneIt's for temporarily hosting *anything* while it gets developed for inclusion
15:25:46Tornefrom anyone
15:25:55Torne"third party" etc is an irrelevant distinction
15:26:15Tornethe point is it is for hosting "things which have not been committed *yet*"
15:26:24sideralTorne: would you say that all patches currently in FS would have a place in Gerrit?
15:26:41Lloreansideral: All patches that haven't erroneously been left open when they should've been rejected, yes.
15:26:50LloreanRejected or closed for other reasons ("too old")
15:27:21Tornesideral: I would say that anything anyone is interested in uploading for review has a place
15:27:25Tornethat's what it's for
15:27:26LloreanTorne: Does gerrit make it possible to re-open old tasks/patches, relatively easily and recover the work?
15:27:31TorneLlorean: Totally trivial
15:27:38Tornejust upload a new version
15:27:42LloreanI imagined so, but I figured it'd be nice to have an explicit statement of it.
15:27:45Torneit un-abandons the change atuomatically
15:28:01Torneyou don't need to do anything to "recover" it, anyway
15:28:03LloreanTorne: What if it's someone new interested in working on it. Can the acquire the abandoned change easily?
15:28:04Tornethe changes are not deleted
15:28:10LloreanOkay, just making sure.
15:28:12TorneThere is no ownershi[
15:28:20LloreanExplicit is good here, since we've had a few possible misunderstandings already
15:28:20Torneyou can upload a new version of *any* change
15:28:36sideralHere's an example: FS #11977 has been rejected for inclusion for now, but some people use it. Can it be hosted in gerrit?
15:28:37fs-bluebot autoresume: Add option to prevent accidental rewind to 0:00 (patches, new)
15:29:02LloreanTorne: I think we can safely say "Anything that belongs on flyspray, would also belong on gerrit"?
15:29:17TorneLlorean: i don't see why not.
15:29:26Tornebut sideral constnatly referring to "Hosting" is misdirecting things
15:29:30Lloreansideral: If it's been rejected, why isn't it closed?
15:29:36Torne*neither* of these systems are intended to *host* stuff
15:29:40Tornenot permanently
15:29:43Lloreansideral: "for now" isn't rejected.
15:29:49Tornethey host it temporarily while it's under consideration
15:30:07gevaertssideral: depends on your intention as a submitter. If you want it included in some form (possibly after major reworking), sure. If you *never* want it included in any form, no.
15:30:33gevaertsKnowing that it's not ready *yet* is not a reason to leave it off
15:30:39Lloreansideral: By "rejected" I mean: task closed, explicit statement saying "we don't want that feature as this patch is written, start a new patch"
15:30:47sideralIt's not closed because it provides value to some, and there's no other / better place to host it
15:30:57Tornethe fact that you uploaded it to flyspray *specifically because* you don't think it will be accepted in trunk means you are misunderstanding what we *already* use flyspray for
15:31:48Lloreansideral: That's not a reason not to close it. Has it been explicitly stated the feature won't be included in Rockbox?
15:31:48UnhelpfulThe old change may not apply any more, though, if you are trying to rescue an abandoned patch. Until we have an auto-forward-porting review system, anyway.
15:31:48TorneUnhelpful: SOmeone is working on that for gerrit too
15:31:48Torneobviously it won't handle conflicts :)
15:31:53*gevaerts stops the discussion again to ask a question
15:31:59Tornebut there will probably be a button to rebase any nonconflicting change at some point
15:32:03gevaertsWhere should I look for new playlist logic?
15:32:14 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
15:32:30UnhelpfulTorne: oh, I meant one that could do more than rebase can. ;)
15:32:33sideralyeah, so I may be misusing FS (let's assume this for the purpose of discussion) and it should be rejected. Still, people want to use it. Where to now?
15:32:54Lloreansideral: Wherever those people want to be.
15:33:09LloreanThere's nothing that stops them from creating an unofficial repository or hosting location.
15:33:25LloreanMany modified builds have had their own homepage and patch pages for their duration of existence. It's not uncommon.
15:33:33sideralLlorean: They want it here, on FS, so that they can discover it at all. Alternatively, another central location −− Github maybe? ;)
15:33:49TorneCan I just point out that if *you* really want a mirror on github, you could do that regardless of what the project decides
15:33:57Lloreansideral: Wherever they want that is created wholly by *them*
15:34:02TorneYou can, trivially, mirror it to github yourself
15:34:07sideralTorne: sure, but "we" need to push to that mirror for it to be useful
15:34:08TorneSUch that anyone else can fork your mirror
15:34:10TorneNo, you don't
15:34:14TorneANyone can do it
15:34:18TorneIt makes no difference
15:34:32Torneyou just need one person willing to push to it
15:34:39Torneit will count against that person's quota on github
15:34:43Torneeveryone else can fork that
15:34:56TorneSo, if we don't push it from gerrit directly, you can still do it :)
15:35:29sideralTorne: I have no online server to automatically pull & push new changesets (leaving aside the issue of learning of new revisions)
15:36:29Torneif i was in your position and felt that it was that important/useful to have then I would arrange for it, even if that cost me time/effort/money :)
15:37:29UnhelpfulI didn't think github forks were kept in sync automatically, either...
15:37:33sideralI think pushing to a github mirror is no big deal for Rockbox, and we should do it to make this more convenient for people who want to use Github *for whatever reason*, and also to provide a backup for the project itself
15:37:38TorneUnhelpful: they are not
15:37:47kugelTorne: if it's so trivial why can't we do it?
15:37:51Tornesideral: It's not sufficient for a backup
15:38:08Torneso, we shouldn't be relying on it, we should be using actual backups
15:38:30gevaertsTorne: wouldn't it be sufficient as a backup location if we have network issues?
15:38:50Tornegerrit does not, yet, store all change metadata in the git repository, though it's getting there :)
15:38:53Tornegevaerts: hm?
15:39:01Tornenot sure what you mean
15:39:51gevaertsTorne: I mean right now when is down (which does happen occasionally), we're stuck
15:40:03TorneWell, we would still be pretty stuck
15:40:32Torneif there was a mirror on github then you could, er, create new clones while the server was down
15:40:38Torneor update your copy up to the point it went down
15:40:40Tornebtu that's about it
15:40:51Tornewe wouldn't (sanely or reasonably) be able to commit there
15:40:56gevaertsYes, it's not a full solution
15:41:34gevaertsAnd of course a DVCS ensures that if you already have a local copy, you're less likely to need the server anyway
15:42:20Tornekugel: we can, it is trivial :)
15:42:29Tornethe whole point of this is whether we should
15:43:09Torneanyway, i need to go :)
15:43:29sideralTorne: Yeah, let's continue when you've changed your mind *again* ;)
15:45:12 Quit dfkt (Read error: Connection reset by peer)
15:45:12 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt)
15:46:05 Quit dfkt_ (Read error: Connection reset by peer)
15:46:26 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
15:46:55 Quit dfkt (Read error: Connection reset by peer)
15:47:11 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
15:47:19*gevaerts doesn't see where he should add code that has to be run when starting a *new* playlist
15:47:49Lloreangevaerts: Look for the new dynamic playlist warning?
15:47:55LloreanEr the "erase dynamic playlist" warning, I mean.
15:48:15gevaertsLlorean: does that only happen for *new* playlists, or also for e.g. restoring bookmarks?
15:48:17 Quit dfkt (Read error: Connection reset by peer)
15:48:34 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
15:48:51LloreanI don't think it happens for restoring bookmarks. But, I don't typically do that during playback, so I don't know.
15:48:58LloreanBut either way, it might give a clue as to where things are happening.
15:49:08*gevaerts looks
15:49:57gevaertsThat's called from six different places :\
15:51:07 Join Poodlemastah [0] (
15:52:23sideralDo we already have code somewhere to generate a stack backtrace as part of the crash handler?
15:52:49 Quit dfkt (Ping timeout: 250 seconds)
15:53:35gevaerts"playlist_get_current()->num_inserted_tracks = 0; /* make warn on playlist erase work */"
15:53:50gevaertsThis is a mess!
15:54:32gevaertssideral: you wanted the thing, you figure it out! ;)
15:54:36bertrikAnd I think it doesn't actually even work :)
16:05:52***Saving seen data "./dancer.seen"
16:14:33 Join fdinel [0] (
16:14:34 Quit stoffel (Ping timeout: 240 seconds)
16:22:52 Join dfkt [0] (dfkt@unaffiliated/dfkt)
16:38:03 Quit GeekShadow (Quit: The cake is a lie !)
16:42:46 Join lasser [0] (
16:56:31 Quit bertrik (Read error: Connection timed out)
16:57:06 Join bertrik [0] (
16:57:06 Quit bertrik (Changing host)
16:57:06 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
17:09:25kugelamiconn: what could be the reason that the player is stuck on the bootloader?
17:10:52 Join soap_ [0] (~soap@rockbox/staff/soap)
17:13:34 Quit stripwax (Quit:
17:18:07gevaertsAny fuze people around? Any objections to changing the max. brightness on the fuzev2 to 12, which seems to be the maximum in the OF?
17:19:29 Join Gentoochild [0] (
17:20:06kugelgevaerts: IIRC we use different (more) steps but don't have a higher maximum
17:20:22gevaertskugel: did you see the recent findings on the forum?
17:20:23kugelwhy do you want to change it?
17:20:59pamauryI think it's because it damages the screen/backlight
17:21:10pamaury(iirc from the forum thread)
17:22:06gevaertsThe old maximum caused dangerous overheating. The new (current) maximum still makes things hot for some people, but it's unclear if it's still dangerous. The OF doesn't go higher than our 12.
17:22:25soap_The shutter speed test appears pretty conclusive.
17:23:07pamaurysideral: I'm not sure we have it
17:23:14pamaurybut it would definitely be useful
17:23:52GentoochildHello. I've been using RB on my Clip for a few days now - it's really amazing. I've always dreamt of being able to carry around and listen to the entire High Voltage SID Collection :D
17:23:56Gentoochildso thanks for your work
17:24:50Gentoochildwhat I noticed in those few days: the FM radio module could be more consistent with the WPS
17:25:12sideralpamaury: too bad. I'm chasing an occasional crash in retrieve() that I cannot reproduce in the simulator... Right now my hypothesis is a stack overflow, so for now I've added a stack check to the crash handler. But I haven't managed to trigger the crash since then
17:25:15Gentoochildi.e. a single Select click goes back to the menu, whereas a long Select click brings you to the radio stations list
17:25:37kugelgevaerts: I don't object. people have verified we go higher
17:25:42pamaurysideral: but you implement backtrace ?
17:25:51sideralnot yet
17:25:59Gentoochildand th only thing that I missed was an option to sort/reorder that list of radio stations.
17:26:27sideralpamaury: BTW, have you had any chance to put my Clip+ to good use?
17:26:54gevaertsGentoochild: yes, the radio screen seems to be a bit less loved than the wps in general
17:27:02bertrikGentoochild, nice to hear it's working well for you :). The keymap could indeed be a bit more consistent.
17:27:12sideralGentoochild: I agree, and have modified my personal keymap accordingly
17:27:31Gentoochildgevaerts: I'm pretty happy with it in every other respect. especially the display signal strength is extremely useful
17:29:04pamaurysideral: not yet
17:29:56bertrikgevaerts, I am in favour of that new backlight setting
17:30:09CIA-14New commit by gevaerts (r30227): Lower the maximum brightness of the fuzev2 backlight even more. ...
17:30:09bertrikI wonder if it gets hot in the OF at that setting too
17:30:21gevaertsDone :)
17:30:25GentoochildAs another feedback: the only problem I had with installation was that the Linux RB Utility wouldn't run due to a library version mismatch. I had to boot to Windows to use it.
17:30:27bertrikIf so, we might be doing something else wrong
17:30:54gevaertsGentoochild: libpng?
17:30:57GentoochildThe “rion” Gentoo overlay, as suggested on the download page, didn't have anything rockbox related
17:31:02Gentoochildgevaerts: yep
17:31:29gevaertsGentoochild: ok. There are plans to link libpng statically to avoid that in the future. Not done yet though
17:31:58GentoochildI tried the sources, but couldn't find out how to compile them
17:32:59sideralgevaerts: this should go to the v3_9 branch as well
17:33:06 Quit froggyman (Ping timeout: 264 seconds)
17:33:09gevaertssideral: yes, I'll commit it there soon
17:33:28 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.)
17:33:58CIA-14New commit by gevaerts (r30228): Lower the maximum brightness of the fuzev2 backlight even more. ...
17:34:27sideralthat was very soon
17:34:42CIA-14r30227 build result: All green
17:36:11gevaertsYes, I had to get a 3.9 checkout first. Somehow I didn't have one yet
17:43:23kugelbertrik: apparently the OF doesn't have that setting
17:43:41kugelI mean this high values
17:45:58 Join soap__ [0] (
17:46:00bertrikOh, I see on the forum thread that there's no more heat at setting 12 (our new highest setting)
17:47:57 Quit soap_ (Ping timeout: 260 seconds)
17:51:02gevaertsYes, I'm fairly confident that capping at 12 is the right fix for this
17:55:19 Quit soap__ (Quit: Leaving)
17:55:42 Join [Saint] [0] (
18:00:18*sideral is about to check in FS #12132
18:00:19fs-bluebot tagnavi: Support "basename" in formats and conditions; replace <Untagged> in track views (patches, new)
18:02:15GentoochildI'm off, bye
18:02:16 Part Gentoochild ("Konversation terminated!")
18:02:29 Join stoffel [0] (
18:05:53***Saving seen data "./dancer.seen"
18:08:23 Join user890104_ [0] (~Venci@
18:10:24 Join stripwax [0] (
18:10:28 Quit user890104 (Ping timeout: 252 seconds)
18:26:32CIA-14New commit by sideral (r30229): FS #12132 patch 6, part 1: tagnavi.config: Add support for string ...
18:26:36CIA-14New commit by sideral (r30230): FS #12132 patch 6, part 2: tagnavi.config: Add support for "basename" ...
18:26:41CIA-14New commit by sideral (r30231): FS #12132 patch 7: Add a new default format for untagged tracks: ...
18:30:06 Quit evilnick (Read error: Connection timed out)
18:30:31CIA-14r30229 build result: 525 errors, 0 warnings (sideral committed)
18:31:20bertrikyay! ;)
18:32:02sideraloops, split the patch at the wrong place. :) r30230 should fix this. Let's wait and see...
18:35:10CIA-14r30231 build result: All green
18:36:47sideralhmm, pretty hefty binsize tax...
18:37:15 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.)
18:41:17 Quit Strife89 (Ping timeout: 252 seconds)
18:43:01*sideral checks what's changed for the ClipV1
18:43:40sideralWhich architecture do the Ondas have?
18:46:07sideraldarn, I only have arm and sh cross compilers
18:47:17 Join evilnick [0] (~evilnick@rockbox/staff/evilnick)
18:52:46 Join robin0800 [0] (
18:54:43 Join Strife89 [0] (
19:05:45 Quit lasser (Quit: ChatZilla 0.9.87 [Iceweasel 3.5.16/20110701113851])
19:08:17 Quit FOAD (Quit: I'll be back)
19:14:04 Join funman [0] (~fun@rockbox/developer/funman)
19:14:06 Join FOAD [0] (~dok@
19:15:23 Join fyrestorm [0] (
19:15:31 Quit Strife89 (Read error: Connection reset by peer)
19:16:02 Join Strife89 [0] (
19:20:42 Quit robin0800 (Quit: Leaving)
19:22:01 Join robin0800 [0] (
19:37:55 Quit FOAD (Quit: I'll be back)
19:45:46 Join lebellium [0] (
19:46:17 Quit lebellium (Client Quit)
19:52:46 Quit Buschel (Ping timeout: 255 seconds)
19:57:25 Quit sideral (Ping timeout: 246 seconds)
20:05:07 Quit stoffel (Remote host closed the connection)
20:05:19 Join soap_ [0] (~soap@rockbox/staff/soap)
20:05:57***Saving seen data "./dancer.seen"
20:36:26 Quit soap_ (Quit: Leaving)
20:36:38 Nick user890104_ is now known as user890104 (~Venci@
20:54:26 Join Thra11 [0] (~thrall@
21:06:02 Quit GodEater (Read error: Connection reset by peer)
21:06:36 Join CaptainKewl [0] (
21:22:33 Quit robin0800 (Read error: Connection timed out)
21:23:46 Join robin0800 [0] (
21:25:31 Quit dfkt (Read error: Connection reset by peer)
21:25:32 Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
21:28:29 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
21:29:42 Join dfkt [0] (dfkt@unaffiliated/dfkt)
21:29:55 Quit dfkt_ (Ping timeout: 252 seconds)
21:33:24 Join n1s [0] (~quassel@rockbox/developer/n1s)
21:39:50 Join Buschel [0] (
21:48:26 Join petur [0] (~petur@rockbox/developer/petur)
21:53:27 Join GodEater [0] (
21:53:27 Quit GodEater (Changing host)
21:53:27 Join GodEater [0] (~bibble@rockbox/staff/GodEater)
21:54:48 Quit robin0800 (Read error: Connection timed out)
21:55:44 Join robin0800 [0] (
22:01:32 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723])
22:02:04 Quit scorche (Disconnected by services)
22:02:11 Join scorche` [0] (~scorche@rockbox/administrator/scorche)
22:04:36 Quit mc2739 (Ping timeout: 260 seconds)
22:05:58***Saving seen data "./dancer.seen"
22:07:10 Quit benedikt93 (Quit: Bye ;))
22:09:47 Join FOAD [0] (~dok@
22:10:22 Quit robin0800 (Quit: Leaving)
22:11:52 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
22:12:22 Quit bertrik (Quit: :tiuQ)
22:13:13 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
22:20:26 Quit Poodlemastah (Remote host closed the connection)
22:29:41 Quit FOAD (Remote host closed the connection)
22:35:27 Quit y4n (Quit: Today is the perfect day for a perfect day.)
22:35:57 Quit bieber (Ping timeout: 258 seconds)
22:41:02 Quit petur (Quit: Leaving)
22:41:16 Join bieber [0] (
22:42:20 Join Thra11_ [0] (~thrall@
22:43:01 Join froggyman [0] (~seth@unaffiliated/froggyman)
22:45:02 Quit Thra11 (Ping timeout: 240 seconds)
22:45:02 Quit dfkt (Read error: Connection reset by peer)
22:45:05 Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
22:45:45 Quit bieber (Ping timeout: 246 seconds)
22:46:49 Quit dfkt_ (Read error: Connection reset by peer)
22:46:50 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
22:47:34 Quit dfkt (Read error: Connection reset by peer)
22:47:35 Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
22:48:52 Join bieber [0] (
22:48:53 Quit dfkt_ (Read error: Connection reset by peer)
22:59:24 Quit froggyman (Ping timeout: 252 seconds)
22:59:55 Join FOAD [0] (~dok@
23:00:34 Join robin0800 [0] (
23:01:46 Quit merbanan (Ping timeout: 255 seconds)
23:06:35 Join dfkt [0] (dfkt@unaffiliated/dfkt)
23:30:11 Quit FOAD (Remote host closed the connection)
23:31:06 Join mystica555 [0] (
23:34:04 Join FOAD [0] (~dok@
23:39:37 Join froggyman [0] (~seth@unaffiliated/froggyman)
23:42:33 Quit robin0800 (Quit: Leaving)
23:43:07 Join robin0800 [0] (
23:43:41 Join sideral [0] (~sideral@rockbox/developer/sideral)
23:43:57 Part domonoky
23:45:36 Quit n1s (Remote host closed the connection)
23:50:10 Quit bertrik (Quit: :tiuQ)
23:53:12 Join [Saint] [0] (
23:54:48 Quit froggyman (Ping timeout: 276 seconds)

Previous day | Next day