| 00:01:54 | sideral | kugel: 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:17 | kugelp | sideral: I can have a go |
| 00:07:29 | sideral | great! |
| 00:07:55 | kugelp | my repro recipe doesn't work for you? |
| 00:08:16 | | Join Jotunn [0] (~jot@74-142-217-72.dhcp.insightbb.com) |
| 00:09:29 | | Join robin0800 [0] (~robin0800@149.254.61.29) |
| 00:14:08 | | Join lixxus [0] (~Mehdi@94-193-41-177.zone7.bethere.co.uk) |
| 00:14:26 | kugelp | sideral: ^ |
| 00:20:48 | sideral | kugel: 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:30 | sideral | ah, found an SD card |
| 00:27:05 | sideral | and... your recipe works on my Fuzev2 (but I haven't applied the d_names offset patch yet) |
| 00:27:15 | kugel | cool |
| 00:27:41 | | Quit efyx (Remote host closed the connection) |
| 00:28:40 | sideral | let me update to current first and see whether I can still reproduce it, then I'll try the patch... |
| 00:29:04 | kugel | I assume it's the "does not fit into previos" path because dircache info shows "last size" correctly |
| 00:29:20 | kugel | and only if last size is 0 then it goes through a complete build |
| 00:29:37 | kugel | the patch doesn't help, for me anyway |
| 00:29:56 | | Quit robin0800 (Ping timeout: 250 seconds) |
| 00:30:02 | sideral | Yeah... I'll apply it right away :) |
| 00:30:45 | | Quit jhMikeS () |
| 00:32:47 | kugel | last_size is also bigger than the reserve buffer in my case |
| 00:32:53 | kugel | so yes, it should really go into that path |
| 00:33:18 | sideral | OK, I can still reproduce it |
| 00:34:18 | kugel | no wait |
| 00:34:33 | kugel | I think last size is slightly less, but bigger including the sd contents |
| 00:34:44 | sideral | the 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:44 | kugel | ahhh. last size is 65700, reserve is 65500 |
| 00:35:54 | sideral | On my Fuze I can see which path is taken by looking for the "scanning disk" splash |
| 00:36:02 | kugel | i see that too |
| 00:36:15 | kugel | which means it goes through the thread, no? |
| 00:36:31 | sideral | main() shows that only if the last size is 0, in which case dircache rebuilds in the foreground |
| 00:36:41 | kugel | strange |
| 00:36:52 | sideral | I think :) |
| 00:38:04 | kugel | then the dircache info screen shows last_size wrongly |
| 00:38:22 | | Part lixxus |
| 00:38:32 | sideral | maybe it shows the "current" last size |
| 00:38:46 | sideral | the one being used for the next dircache_build call |
| 00:40:14 | sideral | let me try disabling compaction... |
| 00:41:30 | kugel | sideral: I think I have a solution |
| 00:41:41 | sideral | yeah? :) |
| 00:41:52 | kugel | try http://pastie.org/2296376 |
| 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] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 00:42:30 | | Quit bertrik (Changing host) |
| 00:42:30 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 00:42:39 | sideral | I'll try, but I'm not convinced this will work :) |
| 00:43:09 | sideral | the 2nd hunk is semantically equivalent. that was my confusion before |
| 00:43:13 | kugel | seems to work for me |
| 00:43:23 | kugel | yes, I thought so too |
| 00:43:37 | kugel | but now I didn't think but just tried if it does anything :) |
| 00:44:23 | sideral | I 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] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) |
| 00:44:46 | | Quit jhMikeS (Changing host) |
| 00:44:46 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 00:45:48 | kugel | I've no fking idea :) |
| 00:51:49 | | Quit mudd1 (Quit: Ex-Chat) |
| 00:51:50 | sideral | kugel: confirmed: it works. |
| 00:52:08 | sideral | I like the new expression much better than the older one anyway :) |
| 00:52:30 | kugel | me too |
| 00:52:39 | kugel | I don't know why I didn't do it in the first place |
| 00:52:59 | kugel | however since we both thought it's equivalent to the old one we should perhaps figure out why it isn't? |
| 00:53:00 | sideral | maybe entry_count is wrong for some reason? |
| 00:54:24 | sideral | perhaps the counting is one difference between the native and hosted implementations? |
| 00:55:59 | sideral | no, it's only ever incremented in allocate_entry |
| 00:58:30 | | Join BHSPitLappy [0] (~BHSPitLap@unaffiliated/bhspitmonkey) |
| 00:58:36 | kugel | I have a suspiciion |
| 00:58:41 | kugel | line 339+ |
| 00:58:56 | kugel | I think dircache_size is one too small |
| 01:00 |
| 01:00:01 | kugel | %d is 2 byte, "1" is 1 byte, so sizeof(VOL_NAMES) != snprintf()+1 |
| 01:00:50 | sideral | plausible |
| 01:01:18 | sideral | shouldn't it rather be dircache_size += sizeof(VOL_NAMES)? |
| 01:01:45 | sideral | that's how much d_names_start is decremented |
| 01:02:08 | kugel | that's why I suspect |
| 01:02:56 | | Join Jotunn [0] (~jot@74-142-217-72.dhcp.insightbb.com) |
| 01:03:01 | kugel | right. that seems to work too |
| 01:03:05 | sideral | that also explains why it works in the sim |
| 01:03:16 | kugel | however, += sizeof(VOL_NAMES) isn't entirely correct |
| 01:03:31 | sideral | why? |
| 01:03:37 | kugel | will be wrong for the 100th sd card :) |
| 01:04:04 | kugel | VOL_NAMES is just the format string, it's not what actually goes into the buffer |
| 01:04:32 | sideral | I think it will be correct for dircache_size. it's just that the string buffer can overflow :) |
| 01:05:03 | kugel | the string that snprintf builds is smaller |
| 01:05:05 | | Nick Jotunn is now known as Jotun (~jot@74-142-217-72.dhcp.insightbb.com) |
| 01:05:07 | sideral | because that's how much d_names_start is decremented |
| 01:05:11 | kugel | but you don't know beforehand |
| 01:05:16 | | Part Jotun |
| 01:05:31 | kugel | yes, I'm saying decrementing by sizeof(VOL_NAMES) isn't entirely correct |
| 01:05:50 | sideral | yeah |
| 01:05:54 | sideral | I see what you mean |
| 01:08:02 | sideral | but I cannot be bothered to fix it tonight :) |
| 01:08:09 | kugel | ah, clever, the correct thing is VOL_ENUM_POS+3 |
| 01:08:25 | kugel | that's after the format string and after the resulting string at the same time |
| 01:08:43 | kugel | (this is what it did before my commits too) |
| 01:09:05 | kugel | ah no |
| 01:09:20 | kugel | I was confused, it's flawed the same why as sizeof(VOL_NAMES) |
| 01:10:22 | sideral | yep |
| 01:11:10 | kugel | but I don't feel like calculation log10 for the volumes :) |
| 01:13:15 | | Join Jotun [0] (~jot@74-142-217-72.dhcp.insightbb.com) |
| 01:13:51 | sideral | Famous last words: "99 volumes ought to be enough for anybody"? |
| 01:14:01 | sideral | ;) |
| 01:14:43 | kugel | more than the 26 in the windows world :) |
| 01:15:45 | * | kugel commits the fix |
| 01:16:50 | sideral | yay! great work kugel! |
| 01:17:37 | | Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) |
| 01:20:44 | sideral | and, kugel, rethink that plan to introduce even more moving allocations into Rockbox once more please! ;) |
| 01:20:57 | kugel | no, why? |
| 01:21:15 | kugel | moving is easier than compacting :) |
| 01:21:44 | kugel | I 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:00 | CIA-14 | New commit by kugel (r30224): Dircache: Fix 2 nasty bugs introduced with the reworks starting with r30032. ... |
| 01:22:44 | sideral | which limitation did it not address? |
| 01:23:37 | kugel | not being able to dynamically allocate memory for the entire runtime |
| 01:24:05 | kugel | as I said I dont remember the details of your proposal |
| 01:24:21 | kugel | I'm not even sure I remember it at all. wasn't it about setting memory aside at boot? |
| 01:24:50 | sideral | no, I suggested to introduce dynamic allocation on two levels: |
| 01:25:08 | kugel | it's to late to rethink my project, and it was on the gsoc page for many years without complaint |
| 01:25:25 | sideral | the first one would alloc large, fixed-size chunks. the audio buffer would be composed of multiple/many of these chunks. |
| 01:25:45 | sideral | then there could be one or more allocators for allocating smaller objects in these chunks |
| 01:25:48 | CIA-14 | r30224 build result: 1 errors, 1 warnings (kugel committed) |
| 01:26:29 | kugel | that isn't actually an error! (and not mine anyway) |
| 01:26:44 | sideral | this would allow freeing large regions as a whole, without any fragmentation except for chunking and any remaining internal fragmentation |
| 01:27:26 | sideral | I am not at all against your project, but I think it's vastly more complex and hard to get right |
| 01:27:29 | kugel | this 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:16 | kugel | freeing does also mean that it can be re-used, e.g. by the audio buffer, which cannot have holes |
| 01:28:22 | sideral | it does: the dircache could release its chunk(s) as a whole if so desired |
| 01:28:27 | kugel | and 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:59 | kugel | sideral: _releasing_ is easy, even with the current system, re-using for other purposes not so much |
| 01:29:00 | sideral | the 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:29 | sideral | yeah, hence the idea to standardize the unit of allocation |
| 01:29:36 | kugel | it's a ring buffer which doesn't support holes |
| 01:29:44 | sideral | not yet, right ;) |
| 01:29:59 | kugel | that it can "jump" because it's a ring buffer has nothing to do with that |
| 01:30:49 | sideral | yeah, it's kind of a stretch :) but I wanted to illustrate the complexity of supporting non-contiguous streams |
| 01:31:00 | kugel | I don't think a chunk size makes it particularly more easy |
| 01:31:06 | gevaerts | sideral: 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:40 | sideral | gevaerts: I'd define the tradeoffs differently |
| 01:32:29 | sideral | I'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:16 | kugel | dircache 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:26 | sideral | Also, 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:28 | kugel | all those don't apply to plain moving |
| 01:34:29 | sideral | I'd say the dircache problems highlighted exactly the problems to expect from moving allocations: |
| 01:34:53 | sideral | dangling pointers and buffer miscalculations |
| 01:35:01 | kugel | I analized the code base. other allocations are very different |
| 01:35:24 | kugel | miscalculations can happen regardless of moving |
| 01:35:52 | kugel | the one I just fixed was in fact completely unrelated to moving or compacting |
| 01:36:01 | sideral | well, we're adding a whole new class of miscalculations: forgetting to move object pointers along with an alloc move |
| 01:36:41 | kugel | yes, that's where you need to be careful, but I have my analysis about those |
| 01:36:50 | sideral | no, it was totally related: two dangling pointers and an off-by-something buffer size computation error |
| 01:36:56 | kugel | I don't disagree that it adds complexity |
| 01:37:03 | gevaerts | sideral: 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:03 | kugel | but also adds a lot of value |
| 01:37:36 | gevaerts | Unless there's something I'm not seeing |
| 01:38:19 | | Quit neferty (Quit: ohshi-) |
| 01:38:34 | sideral | gevaerts: 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:17 | kugel | allocate around a movable middle? |
| 01:39:18 | sideral | kugel: 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@173.242.127.201) |
| 01:39:27 | kugel | that you didnt propose before |
| 01:39:36 | kugel | and that also sounds very complex to implement to me |
| 01:39:39 | sideral | unmovable, not "movable" |
| 01:39:41 | | Quit stripwax_ (Quit: http://miranda-im.org) |
| 01:39:50 | kugel | unmovable, sorry |
| 01:40:07 | kugel | sideral: I like the challenge :) |
| 01:40:25 | | Nick Jotun is now known as Jotunn (~jot@74-142-217-72.dhcp.insightbb.com) |
| 01:40:26 | gevaerts | sideral: 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:46 | kugel | except you waste 9k when you need 1k |
| 01:40:59 | sideral | the 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:29 | kugel | what would be the exact advantage of that chunk size? |
| 01:41:51 | kugel | nothing is gained if allocation can span multiple chunks, no? |
| 01:42:07 | sideral | gevaerts: this helps because there cannot be fragmentation below the chunk size that everyone uses |
| 01:42:32 | kugel | I don't see that |
| 01:43:15 | sideral | if 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:21 | kugel | I 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:30 | gevaerts | sideral: what sort of chunk size do you have in mind? |
| 01:43:37 | sideral | I'd imagine a chunk size of 64KB or larger |
| 01:43:39 | kugel | since you need chunks next to each other the result is the same |
| 01:44:07 | sideral | kugel: No, that's the point: you don't need chunks next to each other |
| 01:44:29 | kugel | then you need all clients to teach about holes in their allocation |
| 01:44:47 | kugel | which 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:53 | sideral | only the ones that desire larger contiguous allocations. which would be p |
| 01:45:03 | sideral | mainly the pcm driver? |
| 01:45:26 | sideral | gevaerts: I have a very different intuition that yours |
| 01:45:38 | gevaerts | Yes, clearly :) |
| 01:45:43 | sideral | almost all allocator clients need smaller objects |
| 01:45:59 | kugel | therefore 64k wastes a lot |
| 01:46:22 | sideral | correction: almost all allocator clients need *lots of* smaller objects |
| 01:47:06 | sideral | high 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:08 | kugel | we have allocations with 12k, 20k, 40k |
| 01:47:19 | kugel | and as I said, about 15 in total |
| 01:47:35 | kugel | you're suggestion to throw a away like 100-200k |
| 01:47:47 | kugel | which is about half of the clipv1 entire free ram :) |
| 01:48:21 | sideral | I suggest to find a chunk size that makes sense :) |
| 01:48:22 | kugel | then you suggest to make the others aware of discontigous allocs which is probably more work than making them movable |
| 01:50:10 | sideral | That'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:47 | sideral | they'd allocate those from their chunks. the clients don't need their small objects to be contiguous |
| 01:51:22 | kugel | so, all clients need to implement a small allocator too |
| 01:51:26 | kugel | even more work :) |
| 01:51:56 | sideral | well, they could probably share one chunk-based small-object allocator, but use different chunks |
| 01:52:05 | sideral | depends on their requirements, really |
| 01:52:36 | sideral | anyway, my gut feeling is that this is vastly less work than supporting moving allocations in all alloc clients |
| 01:52:48 | kugel | I don't share this feeling |
| 01:53:02 | kugel | and I have done a throughout analysis on the entire code base |
| 01:53:58 | sideral | I hope you're right! But I think we got a taste of what's coming in the past few weeks |
| 01:54:12 | kugel | anyway, 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:16 | sideral | that's fine! I certainly won't attempt to block any of your work. But I'm scared of it anyway ;) |
| 01:55:27 | kugel | I 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:40 | kugel | but those aren't really all related to moving |
| 01:56:12 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 01:56:55 | sideral | I'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:13 | sideral | but I think it highlights the problem areas that will become more prominent |
| 01:57:15 | | Quit bertrik (Client Quit) |
| 01:57:50 | kugel | so we now know better what we need to be careful about. that's profit :P |
| 02:00 |
| 02:05:34 | *** | Saving seen data "./dancer.seen" |
| 02:29:55 | | Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) |
| 02:43:46 | | Quit antil33t () |
| 03:00 |
| 03:04:55 | | Join robin0800 [0] (~robin0800@genld-217-238.t-mobile.co.uk) |
| 03:09:40 | | Quit robin0800 (Client Quit) |
| 03:10:43 | | Join robin0800 [0] (~robin0800@149.254.219.238) |
| 03:27:50 | | Quit funman (Ping timeout: 258 seconds) |
| 03:50:55 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 04:00 |
| 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] (parafin@paraf.in) |
| 04:17:36 | | Join robin0800 [0] (~robin0800@genld-217-238.t-mobile.co.uk) |
| 04:22:24 | | Quit sideral (Quit: Leaving.) |
| 04:28:18 | | Quit ReimuHakurei_ (Read error: Connection reset by peer) |
| 04:28:23 | | Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) |
| 04:31:45 | | Quit robin0800 (Ping timeout: 260 seconds) |
| 04:38:28 | | Join ReimuHakurei_ [0] (~kudo@wireless.sit-co.net) |
| 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@112.166.15.141) |
| 04:57:50 | | Quit timccc (Ping timeout: 250 seconds) |
| 04:58:22 | | Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) |
| 05:00 |
| 05:02:26 | | Quit BHSPitLappy (Ping timeout: 250 seconds) |
| 05:03:36 | | Quit antil33t () |
| 05:09:58 | | Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) |
| 05:25:58 | | Nick bluefoxx_ is now known as bluefoxx (fuzzylomba@2002:4647:1f1f::4647:1f1f) |
| 05:36:32 | | Join mystica555_ [0] (~mike@184-229-140-209.pools.spcsdns.net) |
| 05:42:20 | | Join hskf [0] (~textual@24-181-22-218.static.gwnt.ga.charter.com) |
| 05:43:06 | | Join Rob2222 [0] (~Miranda@p4FFF037C.dip.t-dialin.net) |
| 05:46:39 | | Quit Rob2223 (Ping timeout: 246 seconds) |
| 05:56:24 | | Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) |
| 06:00 |
| 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: http://www.textualapp.com/) |
| 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@83.228.31.135) |
| 06:58:42 | | Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 07:00 |
| 07:23:16 | * | [Saint] wonders why there's not a hint of anything Android on http://www.rockbox.org/wiki/TargetStatus#New_Platforms_Currently_Under_De |
| 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]@124-197-58-10.callplus.net.nz) |
| 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:00 |
| 08:02:46 | mc2739 | [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:12:24 | [Saint] | *jpg |
| 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:13 | mc2739 | [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:44 | mc2739 | where 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:43 | mc2739 | windows or linux? |
| 08:31:56 | [Saint] | Linux |
| 08:32:28 | mc2739 | linux is always more case sensitive than windows |
| 08:32:57 | | Join mystica555_ [0] (~mike@static-173-210-70-210.ngn.onecommunications.net) |
| 08:33:34 | mc2739 | you might just try renaming for no other reason than to rule it out as a cause |
| 08:40:32 | | Join T44 [0] (~Topy44@g228143042.adsl.alicedsl.de) |
| 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@83.228.31.135) |
| 09:00 |
| 09:15:30 | | Quit Keripo (Read error: Connection reset by peer) |
| 09:17:43 | | Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) |
| 09:28:48 | | Join stoffel [0] (~quassel@p57B4A5E1.dip.t-dialin.net) |
| 09:29:00 | | Quit sasquatch (Quit: WeeChat 0.3.5) |
| 09:29:27 | | Join sasquatch [0] (~username@p4FF2DA71.dip.t-dialin.net) |
| 09:37:48 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
| 09:48:14 | | Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) |
| 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:00 | kugelp | [Saint]: it's the Linux file systems that are case sensitive.however we should be able to fix this on our end |
| 09:59:42 | kugelp | I noticed this ages ago on the sim |
| 10:00 |
| 10:03:07 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 10:03:07 | | Quit bertrik (Changing host) |
| 10:03:07 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 10:03:40 | | Join bluebrother [0] (~dom@g231120001.adsl.alicedsl.de) |
| 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] (~fs-bluebo@g231120001.adsl.alicedsl.de) |
| 10:07:37 | | Quit bluebroth3r (Ping timeout: 276 seconds) |
| 10:21:34 | | Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) |
| 10:24:12 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 10:54:03 | | Join ender` [0] (~ender@foo.eternallybored.org) |
| 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:00 |
| 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] (~chatzilla@p54B668FC.dip.t-dialin.net) |
| 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:57 | Buschel | is there anyhting speaking against submitting a first step of FS #12176 ? |
| 11:52:58 | fs-bluebot | http://www.rockbox.org/tracker/task/12176 New Chiptune codec pack based on Game_Music_Emu library ;) (patches, unconfirmed) |
| 11:53:17 | Buschel | first step = minor changed v03-patch as the latest do not compile |
| 11:53:50 | Buschel | this will bring in some more synthesizer codecs |
| 11:53:59 | Buschel | non optimized, but working |
| 12:00 |
| 12:04:25 | kugel | Buschel: he addressed my concerns of the previous patches |
| 12:04:53 | kugel | but he didnt answer one question of mine |
| 12:05:46 | *** | Saving seen data "./dancer.seen" |
| 12:05:56 | kugel | I also don't understand the changes to codecs.[ch] |
| 12:07:37 | kugel | well, 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] (~quassel@p57B4A5E1.dip.t-dialin.net) |
| 12:13:46 | | Quit user890104 () |
| 12:14:56 | Buschel | kugel: if you mean the author did some changes _after_ v03 which you were asking for, which were these? |
| 12:16:09 | kugel | Buschel: I posted a comment |
| 12:16:44 | Buschel | which one do you mean exactly? |
| 12:16:58 | kugel | the one from 5 min ago :) |
| 12:17:12 | * | Buschel presses F5 |
| 12:17:19 | kugel | don't! |
| 12:17:32 | kugel | flyspray doesn't like f5 :) |
| 12:18:02 | Buschel | worked fine here :) but you shouldn't do F5 after any you did a change to the task :) |
| 12:21:45 | kugel | [Saint]: no body ever complained about the db display, so it was wanted |
| 12:22:15 | kugel | but 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:41 | kugel | (re: FS #12213) |
| 12:22:42 | fs-bluebot | http://www.rockbox.org/tracker/task/12213 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:16 | Buschel | kugel: 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:25 | Buschel | still 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] (~skx@78-20-16-156.access.telenet.be) |
| 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:39 | kugel | no |
| 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:02 | kugel | IIRC bertrik removed himself with the 128x64x1 unification |
| 12:30:36 | kugel | we still complained to JdGordon that he made it initially only for one wp |
| 12:30:37 | kugel | wps |
| 12:30:55 | kugel | so 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 now...so 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:21 | kugel | btw, 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:48 | Buschel | kugel: 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:38:50 | [Saint] | *s/of/or/ |
| 12:39:10 | Buschel | good enough imho |
| 12:40:30 | kugel | did anyone else review the patch? |
| 12:40:38 | kugel | other than testing it? |
| 12:41:09 | Buschel | saratoga made some comments regarding IRAM optimizations, but I am not sure here had time to review the patch |
| 12:41:11 | kugel | probably difficult to do because it's a C++ to C conversion of foreign code |
| 12:41:38 | kugel | yes, I read comments about premature optimizations but not about review :) |
| 12:43:03 | kugel | I 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:16 | Buschel | in rockbox specific files |
| 12:43:22 | Buschel | of this patch |
| 12:47:16 | kugel | Buschel: do you try with files and such a metadata containing playlist in the sam folder? |
| 12:48:57 | kugel | i wonder how that integrates |
| 12:50:23 | Buschel | kugel: sorry, I don't get your question |
| 12:51:54 | kugel | Buschel: it's apparently common to store metadata about tracks in a playlist file in the same directory (non-standard .m3u) |
| 12:52:09 | kugel | because the files have crappy tags |
| 12:52:15 | kugel | (if at all) |
| 12:52:32 | Buschel | kugel: I do not use .m3u's at all |
| 12:53:01 | kugel | see how all the metadata parser call gme_load_m3u() |
| 12:55:06 | Buschel | hmmm |
| 12:55:13 | kugel | and my comments in one of the previous tasks |
| 12:57:48 | Buschel | kugel: what do you think about the gme_m3u-stuff? should this be removed in the first step? |
| 12:58:08 | kugel | no, not removed :) |
| 12:58:24 | | Quit stoffel (Ping timeout: 240 seconds) |
| 12:58:43 | kugel | i just wonder how it integrates into the ui etc |
| 12:59:55 | kugel | from the other tasks it appeared to me that supporting these m3us for metadata is essential for these formats |
| 13:00 |
| 13:00:18 | | Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) |
| 13:00:45 | Buschel | as 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:06 | Buschel | the test files have metadata within the files themselves |
| 13:02:11 | Buschel | (not all of them though) |
| 13:03:55 | | Quit [Saint] (Remote host closed the connection) |
| 13:04:23 | Buschel | I am definately pro removal of gme_m3u |
| 13:05:18 | | Join [Saint] [0] (~st.lasciv@124-197-58-10.callplus.net.nz) |
| 13:05:51 | kugel | Buschel: but it contains metadata for the tracks which cannot be in the files directly as I understood it |
| 13:09:37 | Buschel | well, 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:54 | Buschel | baah, too many typos :/ |
| 13:12:44 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 13:13:50 | kugelp | i don't know anything about these formats, but I'm not against parsing an extra file for metadata in the metadata step |
| 13:14:09 | kugelp | if that's what's usual for those formats |
| 13:14:46 | Buschel | we do not do this at all in our metadata handling, and it sounds like a specific workaround solution |
| 13:16:17 | kugelp | it was in the codecs in the previous patches/tasks. to that I objected |
| 13:18:05 | kugelp | it'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:47 | sideral | Does anyone know who owns the http://github.com/rockbox 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:22 | rasher | surely the official should be on rockbox.org |
| 13:25:08 | sideral | rasher: yeah. but there should be a semi-official mirror to allow people to create a github fork from easily |
| 13:25:35 | sideral | Torne 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:40 | kugel | rasher: it appears we won't host such forks |
| 13:31:49 | kugel | so the idea is we push to some mirror which is read-only for others and let github host forks |
| 13:42:52 | CIA-14 | New commit by kugel (r30225): Move AFMT_MPA_L1 down in the enum as hwcodec can't play it. ... |
| 13:47:18 | | Join stoffel [0] (~quassel@p57B4A5E1.dip.t-dialin.net) |
| 13:48:27 | CIA-14 | r30225 build result: All green |
| 13:50:54 | | Quit mystica555_ (Remote host closed the connection) |
| 13:57:40 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 14:00 |
| 14:02:36 | Torne | i would really prefer that people *don't* use github :) |
| 14:02:44 | Torne | the github workflow is terrible |
| 14:03:11 | pamaury | what is the github workflow ? |
| 14:03:26 | Torne | publishing everything constantly such that you can't sanely rebase ever |
| 14:03:49 | Torne | and it introduces another way for people to send changes to us :) |
| 14:03:53 | Torne | (sending github merge requests) |
| 14:04:56 | sideral | Torne: 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:46 | Torne | why does there have to be a way? |
| 14:05:48 | *** | Saving seen data "./dancer.seen" |
| 14:06:29 | sideral | because it's the hosting service people do use. and apparently "we" don't want to provide hosting for patches/forks anymore |
| 14:07:15 | sideral | obviously, we won't accept merge requests there unless we ever switch over to it officially :) |
| 14:07:30 | Torne | so that's introducing another way to submit changes that we will ignore, yes |
| 14:07:38 | Torne | that doesn't sound like a feature :) |
| 14:07:47 | sideral | anyway, I'm taking you up on your own offer to push to a mirror there :) |
| 14:08:13 | gevaerts | Can't people clone from non-github repositories on github? |
| 14:08:31 | gevaerts | If not, that sounds like lock-in to me, which I'd see as a good reason not to use them |
| 14:08:40 | Torne | not usefully, no |
| 14:08:46 | Torne | you can clone from our repo and then push it to github |
| 14:08:49 | sideral | gevaerts: of course that's also possible, but not with a single mouse click. It's a hassle |
| 14:08:55 | Torne | but that involves downloading the whole thing and then uploading it again |
| 14:09:02 | Torne | Their server side magic only works with things they are hosting |
| 14:09:51 | sideral | gevaerts: Github is not very locky-inny. It's easy to migrate stuff elsewhere. It just provides convenient hosting and collaboration |
| 14:10:04 | sideral | in a way that Rockbox doesn't :) |
| 14:10:05 | Torne | anyway. 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:44 | gevaerts | sideral: only allowing easy cloning from repositories hosted on github is not my definition of "convenient collaboration" |
| 14:11:03 | sideral | Torne: We have discussed that "we" don't want to provide hosting for patches/forks. This has to happen somewhere. |
| 14:11:08 | Torne | No, it doesn't |
| 14:11:21 | Torne | You seem to be missing a major point here :) |
| 14:11:33 | Torne | Either we care about someone's branch and it can go on our server, or we don't |
| 14:11:52 | sideral | Torne: Do you want me to dig out the chat log where you say you'd be willing to push to github? |
| 14:12:19 | Torne | i don't see the relevance |
| 14:12:24 | sideral | Torne: This is for stuff "we" don't care about, aka not ready for commit, but useful to have for some |
| 14:12:45 | gevaerts | I also honnestly don't see how we are no longer providing hosting for forks |
| 14:13:01 | Torne | Isn't this just reopening the argument about people wanting to have a repository of patches that aren't being merged on FS? |
| 14:13:24 | sideral | yes, it is, in a way. |
| 14:14:26 | Torne | If 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:42 | sideral | gevaerts: 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:57 | Torne | THat doesn't mean pick something else to do it |
| 14:15:04 | gevaerts | sideral: that's patches. You also said forks |
| 14:15:05 | Torne | THe point is that we don't want to fulfil that "need" at all |
| 14:15:23 | sideral | Torne: that's nonsense. Lots of projects have a mirror on github, and it's what people expect. |
| 14:15:31 | | Join Poodlemastah [0] (~chatzilla@h-241-205.a218.priv.bahnhof.se) |
| 14:16:10 | kugel | I'm with sideral here |
| 14:16:13 | sideral | gevaerts: "fork" is just Github speak for someone private, but publicly visible repo, which is akin to what we call a patch |
| 14:16:21 | Torne | No, it isn;t |
| 14:16:27 | gevaerts | sideral: it's not. It's very different |
| 14:16:28 | kugel | if rockbox.org doesn't host my fork then I need another place for it |
| 14:16:30 | Torne | There's a big functional difference between a patch and a fork repo |
| 14:16:39 | Torne | kugel: who said it wouldn't? |
| 14:16:50 | kugel | you |
| 14:16:59 | Torne | no I didn't. |
| 14:17:22 | kugel | I 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:30 | Torne | Right |
| 14:17:34 | Torne | Having your own repo is stilly |
| 14:17:37 | Torne | er, silly |
| 14:17:41 | Torne | Why would you want that? |
| 14:17:58 | Torne | if you *can* have a branch in the real repository then it's better in every way |
| 14:18:06 | Torne | the 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:28 | Torne | You can work *exactly the way you chose* |
| 14:18:36 | Torne | A repository is not a unit of anything except storage in git |
| 14:18:48 | Torne | You can work *identically* with a set of branches in a repo vs a seperate repo |
| 14:18:48 | sideral | Torne: with git, everyone has his own repo on his machine. |
| 14:19:17 | Torne | sideral: Right, but ones that are not published are uninteresting |
| 14:19:30 | kugel | Torne: I don't want to mess with the official repo all the time or mind about namespace collision with branches |
| 14:19:37 | Torne | kugel: why not? |
| 14:19:44 | Torne | And there's no namespace collisions |
| 14:19:45 | kugel | I don't want to |
| 14:19:49 | kugel | simple as that |
| 14:19:51 | Torne | refs/personal/kugel/* |
| 14:19:52 | Torne | done ;) |
| 14:19:55 | sideral | Some are not interesting for Rockbox, but need to be discoverable / available anyway. That's what external repos are for |
| 14:20:02 | Torne | write a refspec for your local copy which uses that |
| 14:20:12 | Torne | you now have something that looks and behaves exactly like a fork on github |
| 14:20:12 | kugel | a separate repo is easier to handle for me and everyone else |
| 14:20:19 | Torne | except it's hosted on our server and uses less space |
| 14:20:22 | kugel | without that strange refs/X/Y/Z thing |
| 14:20:23 | Torne | Why? |
| 14:20:34 | Torne | Er, I don't think you understand how git works very well then :) |
| 14:20:41 | kugel | perhaps |
| 14:20:42 | Torne | all repositories work the same way |
| 14:20:52 | Torne | It happens that the default on clone is to clone refs/heads/* |
| 14:20:55 | sideral | Anyway. 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:00 | Torne | you can just pass a different argument to clone and get something different |
| 14:21:28 | kugel | Torne: can I ask you to be more open towards how other people want to use git? |
| 14:21:42 | gevaerts | sideral: why should we care about diskspace on systems with obvious design flaws like not allowing external cloning? |
| 14:21:42 | sideral | It a matter of managing expectations to educate users which workflows will work and which don't |
| 14:21:56 | Torne | I am pointing out that the system we already have supports the exact workflow you want |
| 14:22:04 | sideral | gevaerts: it does allow external cloning. It's just a git hoster with some extra features |
| 14:22:19 | Torne | that's the opposite of stopping you using it how you want, surely :) |
| 14:22:23 | kugel | Torne: my workflow includes a repo just for me |
| 14:22:39 | gevaerts | sideral: then exactly what is the problem? |
| 14:22:57 | sideral | Torne: Yes, it does, but it doesn't make my personal branches discoverable and maintainable (with bug tracking and such) as Github does |
| 14:23:14 | Torne | sideral: How doesn't it? |
| 14:23:19 | Torne | They are perfectly discoverable |
| 14:23:47 | Torne | they're right there on the server, you can just look |
| 14:24:12 | sideral | gevaerts: 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:29 | gevaerts | sideral: then clone on github! |
| 14:24:36 | Torne | that's not true |
| 14:24:42 | Torne | It doesn't have to be ready to be committed |
| 14:24:50 | Torne | the point is to not host stuff that *will not* be commited |
| 14:24:55 | Torne | not to stop you from working on things |
| 14:24:57 | Torne | that would be stupid |
| 14:24:58 | sideral | gevaerts: 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:14 | kugel | Torne: we happen to have stuff that's not going to be committed |
| 14:25:25 | kugel | yes, we shouldn't host that. but we want to host it somewhere |
| 14:25:36 | gevaerts | sideral: 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:00 | gevaerts | I'm not against a github mirror as such, but I'd like people to be honest about the reasons... |
| 14:26:07 | Torne | it just maintains its own mirrors of other people's repositories |
| 14:26:13 | Torne | which you can then cheaply clone on launchpad :) |
| 14:26:20 | Torne | i am not sure why github doesn't do this |
| 14:26:50 | sideral | gevaerts: 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:50 | sideral | s/quote/quota/ |
| 14:27:52 | Torne | it just seems like an attractive nuisance :) |
| 14:28:56 | Torne | OK, 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:01 | gevaerts | sideral: 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:11 | sideral | this 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:12 | kugel | I'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:23 | Torne | I 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:01 | sideral | gevaerts: it could, but it doesn't. bitching about it is rather pointless |
| 14:30:04 | kugel | Torne: because we don't want to host not-going-to-be-committed stuff |
| 14:30:31 | sideral | Torne: The mirror's not just for me, but especially for noncommitters |
| 14:30:39 | gevaerts | sideral: yes, which brings us back to "Why should *we* work around badly designed third party systems?" |
| 14:30:52 | sideral | But I also like to host/mirror my stuff elsewhere, like kugel |
| 14:31:21 | sideral | gevaerts: To make it more convenient for Github users, which happens to be the #1 hoster for open source today |
| 14:31:24 | Torne | kugel: i personally don't care waht you feel like putting into a ref namespaced by your name.. |
| 14:31:27 | sideral | for a reason, mind you |
| 14:31:42 | Torne | sideral: We want to *very strongly* encourage those noncommitters to actively work with us and work towards getting their code into our tree |
| 14:31:57 | Torne | that's much of the point of this :) |
| 14:32:08 | sideral | Torne: That would be preferable. But it's not the reality. |
| 14:32:11 | Torne | GIving them a bunch of alternatives doesn't seem like a great way to achieve it |
| 14:32:22 | Torne | ..what? |
| 14:32:26 | Torne | what do you mean? |
| 14:32:32 | sideral | The reality is that even committers host tons of useful patches in FS that people actually use. |
| 14:32:35 | kugel | why does github prevent this in any way? |
| 14:32:38 | sideral | This includes gevaerts, BTW :) |
| 14:33:00 | gevaerts | sideral: excuse me? Which patches do I have on FS that are not meant for inclusion? |
| 14:33:18 | sideral | The reality also is that often patches need to simmer for years before they can be committed. |
| 14:33:41 | Torne | kugel: maintaining an attractive nuisance |
| 14:34:10 | kugel | huh? |
| 14:34:50 | Torne | kugel: 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:33 | sideral | gevaerts: 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:54 | kugel | you say "the way we would like people to do things" as if we now magically have such a way |
| 14:36:10 | Torne | ..do we not? |
| 14:36:20 | kugel | I, for one, don't want to impose any workflow on others |
| 14:36:22 | Torne | i thought we were pretty settled in that regard |
| 14:36:46 | kugel | we 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:44 | Torne | because 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:46 | sideral | gevaerts: I could also say: if they were meant for inclusion surely you would have completed them? ;) |
| 14:38:06 | gevaerts | sideral: right, I should go and close the things really... |
| 14:38:28 | sideral | gevaerts: No, you shouldn't. You're providing value by having them available. |
| 14:39:47 | sideral | gevaerts: for example, I plan to complete FS #11619 ... eventually ... unless you finish it first ;) |
| 14:39:47 | fs-bluebot | http://www.rockbox.org/tracker/task/11619 Restore pitch and speed settings on resume (patches, new) |
| 14:39:48 | amiconn | If 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:53 | kugel | Torne: I don't believe so |
| 14:40:28 | Torne | kugel: have you tried rebasing things on github? :) |
| 14:40:29 | sideral | amiconn: I'd like it to be "official" in the sense that our Gerrit repo mirrors to it |
| 14:40:30 | kugel | people can still make clones on github, with or without our mirror |
| 14:40:34 | | Join user890104 [0] (~Venci@83.228.31.135) |
| 14:40:45 | kugel | and use all the github features with other forks |
| 14:40:54 | sideral | Torne: rebasing is not an issue on Github, I do it regularly |
| 14:40:54 | gevaerts | sideral: I assume you mean FS #11619 and FS #11644? |
| 14:40:55 | fs-bluebot | http://www.rockbox.org/tracker/task/11619 Restore pitch and speed settings on resume (patches, new) |
| 14:40:55 | fs-bluebot | http://www.rockbox.org/tracker/task/11644 Playlist isn't loaded after reboot if it had ended (patches, new) |
| 14:41:01 | Torne | sideral: you are mistaken |
| 14:41:05 | Torne | :) |
| 14:41:06 | kugel | if we provide a mirror we can at least keep track of that more easily |
| 14:41:15 | kugel | and make life easier for the forks because of shared quota |
| 14:41:19 | Torne | as with *all* published git branches, if you rebase them you break everyone downstream of you |
| 14:41:48 | sideral | gevaerts: yeah, that's the ones I'm most interested in |
| 14:42:09 | Torne | if 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:21 | kugel | Torne: it doesn't |
| 14:42:26 | gevaerts | sideral: to be honest, I can't remember why I haven't committed FS #11644 yet... |
| 14:42:27 | fs-bluebot | http://www.rockbox.org/tracker/task/11644 Playlist isn't loaded after reboot if it had ended (patches, new) |
| 14:42:29 | sideral | Torne: often there is no one downstream :) |
| 14:42:33 | kugel | it's not only about playing upstream for someone else |
| 14:42:37 | Torne | then why publish it? |
| 14:43:09 | kugel | sharing between computers, for example |
| 14:43:10 | sideral | Torne: just as with patches: to allow people to make use of the stuff, and for backup/sync purposes |
| 14:43:24 | Torne | "People making use of the stuff" == someone downstream |
| 14:43:25 | | Quit fs-bluebot (Quit: timeout?) |
| 14:43:27 | kugel | or a webinterface to view patches/commits/etc |
| 14:43:29 | | Join fs-bluebot [0] (~fs-bluebo@g231120001.adsl.alicedsl.de) |
| 14:44:06 | sideral | Torne: Please, I know of the tradeoffs. This discussion isn't about them. It's about convenient repo forking and hosting extensions. |
| 14:44:38 | amiconn | sideral: 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:05 | kugel | that's what going to happen |
| 14:45:13 | | Quit user890104 (Ping timeout: 250 seconds) |
| 14:45:19 | kugel | we're not going to do merge requests on the mirror |
| 14:45:23 | kugel | it's read-only |
| 14:45:27 | gevaerts | amiconn: 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:28 | fs-bluebot | http://www.rockbox.org/tracker/task/11619 Restore pitch and speed settings on resume (patches, new) |
| 14:45:29 | sideral | amiconn: 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:38 | Torne | if 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:01 | kugel | so? |
| 14:46:15 | Llorean | sideral: 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:50 | Llorean | Flyspray has long been under a policy of "only for stuff working towards being committed" |
| 14:47:22 | sideral | Torne: 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:25 | Torne | i'm not blocking anything.. |
| 14:48:28 | | Quit Keripo (Quit: Leaving.) |
| 14:48:44 | sideral | Llorean: 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:47 | Torne | i'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:20 | Torne | gevaerts: and i'm not intending to be in charge of these decisions either :) |
| 14:49:21 | Llorean | sideral: 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:34 | sideral | gevaerts: maybe, but I Torne does have a say in the git migration, I feel ;) |
| 14:49:39 | amiconn | sideral: Yes, and the point is that we do *not* want to host them anymore, officially or semi-officially |
| 14:49:43 | Torne | sideral: no more than anyone else |
| 14:49:50 | gevaerts | sideral: surely a mirror is unrelated to the migration? |
| 14:49:51 | Torne | i'm doing the part i know hwo to do, for the benefit of everyone |
| 14:49:56 | kugel | amiconn: we're not hosting it |
| 14:50:21 | kugel | amiconn: it'd be hosted in other people's repos, not in the mirror |
| 14:50:26 | sideral | Llorean: "We" won't. Github will host them. I'm just asking for a mirror there so that people can easily clone/fork |
| 14:50:31 | Llorean | Completely 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:48 | Llorean | sideral: Creating an official mirror there for that explicit purpose is "us" doing it. |
| 14:50:48 | sideral | er, amiconn^ |
| 14:50:52 | gevaerts | sideral: are you using FS #11644? |
| 14:50:53 | fs-bluebot | http://www.rockbox.org/tracker/task/11644 Playlist isn't loaded after reboot if it had ended (patches, new) |
| 14:50:55 | Torne | anyway, yes, as gevaerts points out this is not related to the migration at all |
| 14:51:04 | Torne | there is zero point in providing a mirror on github until the migration is done |
| 14:51:09 | sideral | Llorean: yeah, that's what I want us to do, for this purpose. |
| 14:51:11 | kugel | that's true :) |
| 14:51:26 | Torne | because if it turns out for some reason we need to rewrite the current repo then an existing mirror would break |
| 14:51:33 | Llorean | sideral: So bring up a discussion, on the -dev list, of changing the project policy away from discouraging uncommittable patches. |
| 14:51:41 | Torne | Until we are actually developing on git instead of svn there's no need to decide :) |
| 14:51:47 | Llorean | Rather than making the discussion about github, which requires the policy change, get the policy change first. |
| 14:51:57 | sideral | Llorean: Pushing to a mirror elsewhere should not be this big a deal |
| 14:52:11 | Llorean | sideral: If it's not a big deal, give up on it. |
| 14:52:30 | Llorean | If 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:31 | sideral | moving unwanted stuff to github is *implementing* our policy, not new policy |
| 14:52:52 | Torne | sideral: 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:54 | sideral | Torne: 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:11 | Llorean | sideral: one way of managing expectations is not doing it. |
| 14:54:22 | Llorean | It's much more effective than by doing it but saying "but we encourage you not to use it." |
| 14:55:03 | sideral | I don't see us not encouraging 3rd-party development. That's not our policy. |
| 14:55:13 | sideral | We just don't want to host it |
| 14:56:02 | CIA-14 | New commit by gevaerts (r30226): Reload the current playlist after reboot even if it has ended. (FS #11644) ... |
| 14:57:07 | gevaerts | OK, that leaves FS #11619... |
| 14:57:08 | fs-bluebot | http://www.rockbox.org/tracker/task/11619 Restore pitch and speed settings on resume (patches, new) |
| 14:57:14 | Llorean | sideral: 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:06 | sideral | Llorean: 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:13 | gevaerts | Llorean: 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:35 | Llorean | sideral: Anything that starts out as noncommittable but has the intent of reaching committable is "ok to host" |
| 14:58:56 | Torne | the point is to have stuff be intended to be in rockbox |
| 14:59:03 | Torne | not that it has to be ready |
| 14:59:10 | amiconn | sideral: That's the point - it does take years, but it shouldn't |
| 14:59:25 | Torne | Yeah, there's basicall no reason why anything should take years |
| 14:59:32 | sideral | amiconn: we have no way to change that. We have to accept this reality. |
| 14:59:35 | Llorean | gevaerts: 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:58 | rasher | Who the hell works for ages on stuff they don't want in Rockbox anyway? |
| 15:00 |
| 15:00:07 | gevaerts | Llorean: yes, but there's a difference between putting stuff in an official mirror and cloning stuff from an official mirror |
| 15:00:09 | CIA-14 | r30226 build result: All green |
| 15:00:11 | Torne | rasher: evidently sideral :) |
| 15:00:17 | rasher | Torne: he's not said that |
| 15:00:21 | | Join user890104 [0] (~Venci@213.226.63.150) |
| 15:00:41 | Torne | I guess. People whose patches sideral uses, then, I assume? :) |
| 15:00:53 | Llorean | gevaerts: 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:02 | rasher | Torne: that's not making any sense |
| 15:01:11 | rasher | :):):):):) |
| 15:01:19 | sideral | Even 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:31 | Llorean | gevaerts: 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:38 | gevaerts | Llorean: 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:41 | Torne | what is the issue for issue tracking? |
| 15:01:43 | rasher | I 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:53 | Torne | If you try out a patch someone is working on and you have feedback |
| 15:01:55 | Torne | post it on the patch |
| 15:02:00 | Torne | et voila, people can see |
| 15:02:05 | Llorean | rasher: I think the excuses are more for why "let's close Flyspray" than "let's move to git/gerrit" |
| 15:02:28 | rasher | Llorean: But the excuses are mostly very flimsy |
| 15:02:42 | rasher | So why not just say "we want to use git and don't want to bother with Flyspray2 |
| 15:03:10 | kugel | gevaerts: I sure want a repo for me also for backup purposes |
| 15:03:14 | Torne | rasher: 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:25 | Llorean | rasher: 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:25 | kugel | I'm not too much after publishing uncommittable stuff for others |
| 15:03:27 | rasher | People 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:38 | kugel | but to have a backup of it, and share between PCs |
| 15:03:42 | rasher | Llorean: I'm talking about the whole switching to git/gerrit process, not this github thing |
| 15:03:56 | Llorean | rasher: Ah. Well, I thought that was already decided anyway. |
| 15:04:05 | Torne | it is |
| 15:04:11 | Llorean | I don't think the reasoning really matters at this point, since the decision has been made. |
| 15:04:13 | rasher | Oh it is. It's the excuses I find sad |
| 15:04:13 | Torne | unless somoene is objecting :) |
| 15:04:25 | Llorean | We can now say "we like gerrit because its name reminds us of the sounds frogs make" and it's fine. |
| 15:04:28 | sideral | Torne: Didn't you tell me that patches on Gerrit wouldn't be as categorized/browsable as on FS? |
| 15:04:38 | Torne | CUrrently, yes |
| 15:04:49 | bertrik | I thought git was decided and gerrit is still under consideration |
| 15:05:05 | Torne | bertrik: Absolutely nobody has offered any objections since I made the demo available |
| 15:05:07 | sideral | rasher: which of my "excuses" do you find sad, specifically? |
| 15:05:08 | Torne | Months ago |
| 15:05:15 | Torne | and lots of people have appoved |
| 15:05:15 | kugel | bertrik: nobody considered something else for 2 month :) |
| 15:05:20 | Torne | so that seemed like a conclusion to me |
| 15:05:28 | rasher | sideral: Not yours, the "let's move to git/ditch flyspray" excuses |
| 15:05:40 | Llorean | bertrik: 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:44 | Torne | We've not yet actually done anything about moving to gerrit that we can't trivially change our minds about |
| 15:05:52 | Torne | I put the demo up, and that's it |
| 15:06:05 | Torne | All 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:13 | fs-bluebot | http://www.rockbox.org/tracker/task/11619 Restore pitch and speed settings on resume (patches, new) |
| 15:06:15 | kugel | people tend to mix the git switch and flyspray closure together but they're separate discussions and decisions |
| 15:06:16 | Torne | So yeah, we are not committed to it |
| 15:06:35 | Torne | but i've yet to hear an alternative proposed, or any objections :) |
| 15:06:46 | Torne | so i'm going with the assumption that we're using it :) |
| 15:06:52 | rasher | kugel: that's because it's being pushed as the same thing |
| 15:07:05 | Torne | rasher: not really; the point is that one *enables* the other |
| 15:07:10 | sideral | kugel: they're connected in that if new hosting for patches is needed, we should host it on some Git place |
| 15:07:22 | kugel | rasher: they happened to be consecutive topics at the devcon, but that's about it |
| 15:07:31 | kugel | the git switch was decided independantly |
| 15:07:40 | rasher | Using git and closing flyspray will cause all patches to be instantly committable and candy will fall from the sky |
| 15:07:45 | Torne | rasher: 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:59 | Torne | if we don't do the former, we shouldn't do the latter (unless another alternative comes up instead) |
| 15:08:01 | Llorean | gevaerts: 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:03 | gevaerts | rasher: yes, that's why we want that |
| 15:08:19 | sideral | Torne: except that we'll reject stuff that should be rightfully hosted someplace |
| 15:08:29 | rasher | As long as I get a cut of the candy |
| 15:08:41 | Torne | sideral: it will be :) |
| 15:09:23 | sideral | Torne: that I'm sure of. the question is just how convenient / discoverable this place is |
| 15:09:24 | Torne | gerrit doesn't delete closed reviews. |
| 15:09:31 | Torne | that would be silly |
| 15:09:39 | gevaerts | Llorean: if I remember correctly, (and if I see things right) it doesn't currently do that |
| 15:09:44 | Llorean | sideral: Why is it our responsibility to care about how convenient/discoverable patches we don't want are? |
| 15:09:46 | Torne | you can always upload another version and try again |
| 15:10:10 | Llorean | gevaerts: 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:13 | sideral | Llorean: because often, after years, a developer will take interest and get it into committable state |
| 15:10:31 | Llorean | sideral: If that's the case, it was a patch we wanted. |
| 15:10:41 | Torne | Llorean: because apparently sideral is the one guy who likes to trawl through FS for ancient patches and finish them |
| 15:10:44 | Torne | :) |
| 15:10:47 | Llorean | You don't seem to be distinguishing between "patches we want, but aren't ready" and "patches we don't want." |
| 15:10:52 | gevaerts | Llorean: in what way? |
| 15:11:03 | Llorean | gevaerts: I'm uncertain what you're asking. |
| 15:11:04 | sideral | gevaerts: re FS #11619: I agree with the last comment from fml2 |
| 15:11:05 | fs-bluebot | http://www.rockbox.org/tracker/task/11619 Restore pitch and speed settings on resume (patches, new) |
| 15:11:18 | gevaerts | Llorean: "I'd just like it to go beyond that" |
| 15:11:24 | Torne | argh, can fs-bluebot ratelimit that stuff? :) |
| 15:11:24 | rasher | Llorean: You're making it sound like this is something new. We've never cared about patches we don't want |
| 15:11:30 | sideral | Torne: yes, that's about right :) |
| 15:11:35 | Llorean | gevaerts: 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:40 | Torne | I don't want to ignore it because i like getting the titles |
| 15:11:45 | Torne | but having it for the same patch over and over is tedious ;) |
| 15:12:00 | gevaerts | sideral: yes, I think I agree too. Without that resetting pitch/speed is a bit tedious |
| 15:12:02 | Llorean | rasher: 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:18 | gevaerts | Torne: you mean like for FS #11619? ;) |
| 15:12:19 | fs-bluebot | http://www.rockbox.org/tracker/task/11619 Restore pitch and speed settings on resume (patches, new) |
| 15:12:23 | rasher | Llorean: No he's not |
| 15:12:30 | rasher | He's making the distinction while you aren't |
| 15:12:59 | Torne | gevaerts: 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:40 | sideral | I just wanted to sit back and see you guys interpret me, but rasher has spoiled the fun |
| 15:13:48 | gevaerts | Llorean: 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:51 | Llorean | I'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:38 | sideral | Llorean: That's a good summary, but I disagree with your conclusion |
| 15:14:46 | Llorean | gevaerts: 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:21 | gevaerts | My 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:22 | fs-bluebot | http://www.rockbox.org/tracker/task/11644 Playlist isn't loaded after reboot if it had ended (patches, closed) |
| 15:15:23 | bertrik | Which targets have a 4066 power management chip? I know of the ipod video, ipod nano 1g, ipod nano 2g |
| 15:15:25 | Torne | Llorean: 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:29 | Llorean | sideral: 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:30 | sideral | Llorean: I think it is partly our concern, because developers and user alike should be able to discover old / previously unwanted / offbeat stuff |
| 15:15:47 | Torne | (someone is working on making gerrit support arbitrary labels, incidentally) |
| 15:16:02 | sideral | Torne: that's correct as well |
| 15:16:12 | Llorean | Torne: I'm concerned about the categories, etc. But that's valid for *our* patches too. |
| 15:16:29 | Llorean | That's one of those "arguments that don't require us to change project policy" that I was asking for earlier. :) |
| 15:16:33 | Torne | Llorean: you can search by text, by which files are affected, and a few other things :) |
| 15:16:44 | Torne | label support appears to be coming but isn't in the release version yet |
| 15:16:49 | sideral | Llorean: because a good ecosystem with many choices is beneficial even for us. |
| 15:16:50 | Llorean | Torne: Tags would be nice, but I find half the time they're misapplied or vague anyway. |
| 15:16:56 | Torne | Indeed |
| 15:17:14 | Torne | I pretty much entirely ignore all the labels on all the bugtracker/etc systems i use |
| 15:17:45 | Torne | anything i can find by label i can generally find just as easily by text searchi |
| 15:18:08 | sideral | whereas I care about them and maintain them for the stuff I'm interested in |
| 15:18:25 | Llorean | sideral: 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:39 | Llorean | Saying "it's beneficial for us" to care doesn't tell us what benefit we get. |
| 15:18:42 | sideral | because you want me to be productive? |
| 15:18:43 | [Saint] | (I'm actually serious, too) |
| 15:18:55 | Llorean | sideral: Ah, yes. We want you to be productive on non-Rockbox projects, so we help you access them? |
| 15:19:30 | Torne | anyway; we have had this entire discussion here before. |
| 15:19:31 | sideral | this applies to "our" bugs/patches as well, as you noticed |
| 15:19:46 | Torne | THe people who were at devcon were mostly in agreement htat discoverability is a *problem*, not a *feature |
| 15:19:53 | Llorean | sideral: Yes, and I've stated that my opinion is different in regard to ours. |
| 15:20:07 | Torne | Not having it means people who want a given change have to make an effort to push it forward :) |
| 15:20:07 | sideral | Saint: 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:39 | Llorean | sideral: 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:45 | sideral | I never expected people would be opposed to pushing to a mirror there |
| 15:20:51 | gevaerts | Llorean: 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:16 | Llorean | gevaerts: Yes. That's why I suggested some logic (though I have no idea how easy/difficult to code) that would address it. |
| 15:21:27 | gevaerts | I'm thinking about it :) |
| 15:21:52 | Torne | sideral: 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:56 | sideral | Llorean: 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:59 | Llorean | To me, pitch changes should apply to "current playlist only" if playing, and "next playlist only" if stopped. |
| 15:22:24 | Llorean | sideral: 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:38 | Llorean | sideral: Why are you refusing to distinguish between things we consider "we may want" and things we actually reject? |
| 15:22:47 | gevaerts | We'd have to set a flag when setting pitch if playback is not active, and checking/clearing that when starting |
| 15:22:50 | gevaerts | I think |
| 15:23:19 | Llorean | gevaerts: 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:32 | gevaerts | Llorean: same for me, actually :) |
| 15:24:02 | sideral | Llorean: 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:38 | Llorean | sideral: 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:59 | Torne | i think you are drawing entirely the wrong distinction |
| 15:25:11 | Llorean | I'd be surprised if anyone's been saying "nobody can put patches up except existing Rockbox developers" |
| 15:25:16 | Torne | It's not for *permanently* hosting *anything* (other than our trunk and release branches) |
| 15:25:43 | Torne | It's for temporarily hosting *anything* while it gets developed for inclusion |
| 15:25:46 | Torne | from anyone |
| 15:25:55 | Torne | "third party" etc is an irrelevant distinction |
| 15:26:15 | Torne | the point is it is for hosting "things which have not been committed *yet*" |
| 15:26:24 | sideral | Torne: would you say that all patches currently in FS would have a place in Gerrit? |
| 15:26:41 | Llorean | sideral: All patches that haven't erroneously been left open when they should've been rejected, yes. |
| 15:26:50 | Llorean | Rejected or closed for other reasons ("too old") |
| 15:27:21 | Torne | sideral: I would say that anything anyone is interested in uploading for review has a place |
| 15:27:25 | Torne | that's what it's for |
| 15:27:26 | Llorean | Torne: Does gerrit make it possible to re-open old tasks/patches, relatively easily and recover the work? |
| 15:27:31 | Torne | Llorean: Totally trivial |
| 15:27:38 | Torne | just upload a new version |
| 15:27:42 | Llorean | I imagined so, but I figured it'd be nice to have an explicit statement of it. |
| 15:27:45 | Torne | it un-abandons the change atuomatically |
| 15:28:01 | Torne | you don't need to do anything to "recover" it, anyway |
| 15:28:03 | Llorean | Torne: What if it's someone new interested in working on it. Can the acquire the abandoned change easily? |
| 15:28:04 | Torne | the changes are not deleted |
| 15:28:10 | Llorean | Okay, just making sure. |
| 15:28:12 | Torne | There is no ownershi[ |
| 15:28:20 | Llorean | Explicit is good here, since we've had a few possible misunderstandings already |
| 15:28:20 | Torne | you can upload a new version of *any* change |
| 15:28:36 | sideral | Here'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:37 | fs-bluebot | http://www.rockbox.org/tracker/task/11977 autoresume: Add option to prevent accidental rewind to 0:00 (patches, new) |
| 15:29:02 | Llorean | Torne: I think we can safely say "Anything that belongs on flyspray, would also belong on gerrit"? |
| 15:29:17 | Torne | Llorean: i don't see why not. |
| 15:29:26 | Torne | but sideral constnatly referring to "Hosting" is misdirecting things |
| 15:29:30 | Llorean | sideral: If it's been rejected, why isn't it closed? |
| 15:29:36 | Torne | *neither* of these systems are intended to *host* stuff |
| 15:29:40 | Torne | not permanently |
| 15:29:43 | Llorean | sideral: "for now" isn't rejected. |
| 15:29:49 | Torne | they host it temporarily while it's under consideration |
| 15:30:07 | gevaerts | sideral: 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:33 | gevaerts | Knowing that it's not ready *yet* is not a reason to leave it off |
| 15:30:39 | Llorean | sideral: 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:47 | sideral | It's not closed because it provides value to some, and there's no other / better place to host it |
| 15:30:57 | Torne | the 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:48 | Llorean | sideral: That's not a reason not to close it. Has it been explicitly stated the feature won't be included in Rockbox? |
| 15:31:48 | Unhelpful | The 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:48 | Torne | Unhelpful: SOmeone is working on that for gerrit too |
| 15:31:48 | Torne | obviously it won't handle conflicts :) |
| 15:31:53 | * | gevaerts stops the discussion again to ask a question |
| 15:31:59 | Torne | but there will probably be a button to rebase any nonconflicting change at some point |
| 15:32:03 | gevaerts | Where should I look for new playlist logic? |
| 15:32:14 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 15:32:30 | Unhelpful | Torne: oh, I meant one that could do more than rebase can. ;) |
| 15:32:33 | sideral | yeah, 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:54 | Llorean | sideral: Wherever those people want to be. |
| 15:33:09 | Llorean | There's nothing that stops them from creating an unofficial repository or hosting location. |
| 15:33:25 | Llorean | Many modified builds have had their own homepage and patch pages for their duration of existence. It's not uncommon. |
| 15:33:33 | sideral | Llorean: They want it here, on FS, so that they can discover it at all. Alternatively, another central location −− Github maybe? ;) |
| 15:33:49 | Torne | Can 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:57 | Llorean | sideral: Wherever they want that is created wholly by *them* |
| 15:34:02 | Torne | You can, trivially, mirror it to github yourself |
| 15:34:07 | sideral | Torne: sure, but "we" need to push to that mirror for it to be useful |
| 15:34:08 | Torne | SUch that anyone else can fork your mirror |
| 15:34:10 | Torne | No, you don't |
| 15:34:14 | Torne | ANyone can do it |
| 15:34:18 | Torne | It makes no difference |
| 15:34:32 | Torne | you just need one person willing to push to it |
| 15:34:39 | Torne | it will count against that person's quota on github |
| 15:34:43 | Torne | everyone else can fork that |
| 15:34:56 | Torne | So, if we don't push it from gerrit directly, you can still do it :) |
| 15:35:29 | sideral | Torne: I have no online server to automatically pull & push new changesets (leaving aside the issue of learning of new revisions) |
| 15:36:29 | Torne | if 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:29 | Unhelpful | I didn't think github forks were kept in sync automatically, either... |
| 15:37:33 | sideral | I 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:38 | Torne | Unhelpful: they are not |
| 15:37:47 | kugel | Torne: if it's so trivial why can't we do it? |
| 15:37:51 | Torne | sideral: It's not sufficient for a backup |
| 15:38:08 | Torne | so, we shouldn't be relying on it, we should be using actual backups |
| 15:38:30 | gevaerts | Torne: wouldn't it be sufficient as a backup location if we have network issues? |
| 15:38:50 | Torne | gerrit does not, yet, store all change metadata in the git repository, though it's getting there :) |
| 15:38:53 | Torne | gevaerts: hm? |
| 15:39:01 | Torne | not sure what you mean |
| 15:39:51 | gevaerts | Torne: I mean right now when svn.rockbox.org is down (which does happen occasionally), we're stuck |
| 15:39:57 | Torne | Oh. |
| 15:40:03 | Torne | Well, we would still be pretty stuck |
| 15:40:32 | Torne | if there was a mirror on github then you could, er, create new clones while the server was down |
| 15:40:38 | Torne | or update your copy up to the point it went down |
| 15:40:40 | Torne | btu that's about it |
| 15:40:51 | Torne | we wouldn't (sanely or reasonably) be able to commit there |
| 15:40:56 | gevaerts | Yes, it's not a full solution |
| 15:41:34 | gevaerts | And of course a DVCS ensures that if you already have a local copy, you're less likely to need the server anyway |
| 15:42:20 | Torne | kugel: we can, it is trivial :) |
| 15:42:29 | Torne | the whole point of this is whether we should |
| 15:43:09 | Torne | anyway, i need to go :) |
| 15:43:29 | sideral | Torne: 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:49 | Llorean | gevaerts: Look for the new dynamic playlist warning? |
| 15:47:55 | Llorean | Er the "erase dynamic playlist" warning, I mean. |
| 15:48:15 | gevaerts | Llorean: 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:51 | Llorean | I don't think it happens for restoring bookmarks. But, I don't typically do that during playback, so I don't know. |
| 15:48:58 | Llorean | But either way, it might give a clue as to where things are happening. |
| 15:49:08 | * | gevaerts looks |
| 15:49:57 | gevaerts | That's called from six different places :\ |
| 15:50:00 | Llorean | =/ |
| 15:51:07 | | Join Poodlemastah [0] (~chatzilla@h-241-205.a218.priv.bahnhof.se) |
| 15:52:23 | sideral | Do 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:35 | gevaerts | "playlist_get_current()->num_inserted_tracks = 0; /* make warn on playlist erase work */" |
| 15:53:38 | gevaerts | AAAAAAAAAAAAAAAAAAA |
| 15:53:50 | gevaerts | This is a mess! |
| 15:54:32 | gevaerts | sideral: you wanted the thing, you figure it out! ;) |
| 15:54:36 | bertrik | And I think it doesn't actually even work :) |
| 16:00 |
| 16:05:52 | *** | Saving seen data "./dancer.seen" |
| 16:14:33 | | Join fdinel [0] (~Miranda@modemcable036.124-131-66.mc.videotron.ca) |
| 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] (~chatzilla@p57B58689.dip0.t-ipconnect.de) |
| 16:56:31 | | Quit bertrik (Read error: Connection timed out) |
| 16:57:06 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 16:57:06 | | Quit bertrik (Changing host) |
| 16:57:06 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 17:00 |
| 17:09:25 | kugel | amiconn: 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: http://miranda-im.org) |
| 17:18:07 | gevaerts | Any 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] (~blub@roam193.rz.tu-ilmenau.de) |
| 17:20:06 | kugel | gevaerts: IIRC we use different (more) steps but don't have a higher maximum |
| 17:20:22 | gevaerts | kugel: did you see the recent findings on the forum? |
| 17:20:23 | kugel | why do you want to change it? |
| 17:20:59 | pamaury | I think it's because it damages the screen/backlight |
| 17:21:10 | pamaury | (iirc from the forum thread) |
| 17:22:06 | gevaerts | The 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:25 | soap_ | The shutter speed test appears pretty conclusive. |
| 17:23:07 | pamaury | sideral: I'm not sure we have it |
| 17:23:14 | pamaury | but it would definitely be useful |
| 17:23:52 | Gentoochild | Hello. 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:56 | Gentoochild | so thanks for your work |
| 17:24:50 | Gentoochild | what I noticed in those few days: the FM radio module could be more consistent with the WPS |
| 17:25:12 | sideral | pamaury: 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:15 | Gentoochild | i.e. a single Select click goes back to the menu, whereas a long Select click brings you to the radio stations list |
| 17:25:37 | kugel | gevaerts: I don't object. people have verified we go higher |
| 17:25:42 | pamaury | sideral: but you implement backtrace ? |
| 17:25:51 | sideral | not yet |
| 17:25:59 | Gentoochild | and th only thing that I missed was an option to sort/reorder that list of radio stations. |
| 17:26:02 | Gentoochild | +e |
| 17:26:27 | sideral | pamaury: BTW, have you had any chance to put my Clip+ to good use? |
| 17:26:54 | gevaerts | Gentoochild: yes, the radio screen seems to be a bit less loved than the wps in general |
| 17:27:02 | bertrik | Gentoochild, nice to hear it's working well for you :). The keymap could indeed be a bit more consistent. |
| 17:27:12 | sideral | Gentoochild: I agree, and have modified my personal keymap accordingly |
| 17:27:31 | Gentoochild | gevaerts: I'm pretty happy with it in every other respect. especially the display signal strength is extremely useful |
| 17:27:41 | Gentoochild | +of |
| 17:29:04 | pamaury | sideral: not yet |
| 17:29:56 | bertrik | gevaerts, I am in favour of that new backlight setting |
| 17:30:09 | CIA-14 | New commit by gevaerts (r30227): Lower the maximum brightness of the fuzev2 backlight even more. ... |
| 17:30:09 | bertrik | I wonder if it gets hot in the OF at that setting too |
| 17:30:21 | gevaerts | Done :) |
| 17:30:25 | Gentoochild | As 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:27 | bertrik | If so, we might be doing something else wrong |
| 17:30:54 | gevaerts | Gentoochild: libpng? |
| 17:30:57 | Gentoochild | The “rion” Gentoo overlay, as suggested on the download page, didn't have anything rockbox related |
| 17:31:02 | Gentoochild | gevaerts: yep |
| 17:31:29 | gevaerts | Gentoochild: ok. There are plans to link libpng statically to avoid that in the future. Not done yet though |
| 17:31:58 | Gentoochild | I tried the sources, but couldn't find out how to compile them |
| 17:32:59 | sideral | gevaerts: this should go to the v3_9 branch as well |
| 17:33:06 | | Quit froggyman (Ping timeout: 264 seconds) |
| 17:33:09 | gevaerts | sideral: 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:58 | CIA-14 | New commit by gevaerts (r30228): Lower the maximum brightness of the fuzev2 backlight even more. ... |
| 17:34:00 | gevaerts | There |
| 17:34:27 | sideral | that was very soon |
| 17:34:42 | CIA-14 | r30227 build result: All green |
| 17:36:11 | gevaerts | Yes, I had to get a 3.9 checkout first. Somehow I didn't have one yet |
| 17:43:23 | kugel | bertrik: apparently the OF doesn't have that setting |
| 17:43:41 | kugel | I mean this high values |
| 17:45:58 | | Join soap__ [0] (~soap@218.sub-97-132-100.myvzw.com) |
| 17:46:00 | bertrik | Oh, 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:02 | gevaerts | Yes, 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] (~st.lasciv@124-197-58-10.callplus.net.nz) |
| 18:00 |
| 18:00:18 | * | sideral is about to check in FS #12132 |
| 18:00:19 | fs-bluebot | http://www.rockbox.org/tracker/task/12132 tagnavi: Support "basename" in formats and conditions; replace <Untagged> in track views (patches, new) |
| 18:02:15 | Gentoochild | I'm off, bye |
| 18:02:16 | | Part Gentoochild ("Konversation terminated!") |
| 18:02:29 | | Join stoffel [0] (~quassel@p57B4A5E1.dip.t-dialin.net) |
| 18:05:53 | *** | Saving seen data "./dancer.seen" |
| 18:08:23 | | Join user890104_ [0] (~Venci@213.226.63.159) |
| 18:10:24 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 18:10:28 | | Quit user890104 (Ping timeout: 252 seconds) |
| 18:26:32 | CIA-14 | New commit by sideral (r30229): FS #12132 patch 6, part 1: tagnavi.config: Add support for string ... |
| 18:26:36 | CIA-14 | New commit by sideral (r30230): FS #12132 patch 6, part 2: tagnavi.config: Add support for "basename" ... |
| 18:26:41 | CIA-14 | New 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:31 | CIA-14 | r30229 build result: 525 errors, 0 warnings (sideral committed) |
| 18:31:20 | bertrik | yay! ;) |
| 18:32:02 | sideral | oops, split the patch at the wrong place. :) r30230 should fix this. Let's wait and see... |
| 18:35:10 | CIA-14 | r30231 build result: All green |
| 18:36:47 | sideral | hmm, 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:40 | sideral | Which architecture do the Ondas have? |
| 18:45:00 | gevaerts | mips |
| 18:46:07 | sideral | darn, I only have arm and sh cross compilers |
| 18:47:17 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
| 18:52:46 | | Join robin0800 [0] (~robin0800@genld-224-239.t-mobile.co.uk) |
| 18:54:43 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
| 19:00 |
| 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@83.161.135.61) |
| 19:15:23 | | Join fyrestorm [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) |
| 19:15:31 | | Quit Strife89 (Read error: Connection reset by peer) |
| 19:16:02 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
| 19:20:42 | | Quit robin0800 (Quit: Leaving) |
| 19:22:01 | | Join robin0800 [0] (~robin0800@genld-219-239.t-mobile.co.uk) |
| 19:37:55 | | Quit FOAD (Quit: I'll be back) |
| 19:45:46 | | Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) |
| 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:00 |
| 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@213.226.63.159) |
| 20:54:26 | | Join Thra11 [0] (~thrall@87.115.50.100) |
| 21:00 |
| 21:06:02 | | Quit GodEater (Read error: Connection reset by peer) |
| 21:06:36 | | Join CaptainKewl [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 21:22:33 | | Quit robin0800 (Read error: Connection timed out) |
| 21:23:46 | | Join robin0800 [0] (~robin0800@genld-217-239.t-mobile.co.uk) |
| 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] (~chatzilla@p54A3A875.dip.t-dialin.net) |
| 21:48:26 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 21:53:27 | | Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) |
| 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] (~robin0800@genld-217-239.t-mobile.co.uk) |
| 22:00 |
| 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@83.161.135.61) |
| 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] (~quassel@162-78.97-97.tampabay.res.rr.com) |
| 22:42:20 | | Join Thra11_ [0] (~thrall@87.114.12.64) |
| 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] (~quassel@162-78.97-97.tampabay.res.rr.com) |
| 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@83.161.135.61) |
| 23:00 |
| 23:00:34 | | Join robin0800 [0] (~robin0800@genld-217-239.t-mobile.co.uk) |
| 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] (~mike@c-76-114-156-34.hsd1.md.comcast.net) |
| 23:34:04 | | Join FOAD [0] (~dok@83.161.135.61) |
| 23:39:37 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 23:42:33 | | Quit robin0800 (Quit: Leaving) |
| 23:43:07 | | Join robin0800 [0] (~robin0800@genld-224-239.t-mobile.co.uk) |
| 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] (~st.lasciv@124-197-58-10.callplus.net.nz) |
| 23:54:48 | | Quit froggyman (Ping timeout: 276 seconds) |
icon identifies that the person is a core developer (has commit access).