00:05:37 | *** | Saving seen data "./dancer.seen" |
00:32:05 | | Join dconrad [0] (~dconrad@152.117.104.232) |
00:36:50 | | Quit dconrad (Ping timeout: 265 seconds) |
01:00 |
01:17:57 | | Join dconrad [0] (~dconrad@152.117.104.232) |
01:22:24 | | Quit dconrad (Ping timeout: 244 seconds) |
02:00 |
02:02:45 | rb-bluebot | Build Server message: New build round started. Revision 727d2ab749, 345 builds, 8 clients. |
02:02:45 | rb-bluebot | wps skin_parser free up skin ram with int16_t by William Wilgus |
02:05:39 | *** | Saving seen data "./dancer.seen" |
02:06:23 | | Join dconrad [0] (~dconrad@152.117.104.232) |
02:10:48 | | Quit dconrad (Ping timeout: 252 seconds) |
02:24:10 | rb-bluebot | Build Server message: Build round completed after 1286 seconds. |
02:24:11 | rb-bluebot | Build Server message: Revision 727d2ab749 result: All green |
02:30:42 | | Quit massiveH (Ping timeout: 276 seconds) |
02:54:45 | | Join dconrad [0] (~dconrad@152.117.104.232) |
02:59:01 | | Quit dconrad (Ping timeout: 244 seconds) |
02:59:51 | | Quit bpye (Quit: Ping timeout (120 seconds)) |
03:00 |
03:00:26 | | Join bpye [0] (~bpye@user/bpye) |
03:43:28 | | Join dconrad [0] (~dconrad@152.117.104.232) |
03:47:58 | | Quit dconrad (Ping timeout: 252 seconds) |
04:00 |
04:05:43 | *** | Saving seen data "./dancer.seen" |
04:31:46 | | Join dconrad [0] (~dconrad@152.117.104.232) |
04:36:30 | | Quit dconrad (Ping timeout: 272 seconds) |
05:00 |
05:20:01 | | Join dconrad [0] (~dconrad@152.117.104.232) |
05:24:54 | | Quit dconrad (Ping timeout: 265 seconds) |
05:53:44 | | Join lebellium [0] (~lebellium@2a01cb0405d07f00987db405e50f0afb.ipv6.abo.wanadoo.fr) |
05:55:38 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
05:55:38 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
05:56:13 | speachy | _bilgus: I don't think that lang_english_to_id() "optimization" really is one |
05:57:00 | speachy | since instead of being able to bail on (eg) the first character or two of the string now we have to walk each string to find the length. |
05:58:05 | speachy | if we stored the length as part of the lang table this optimization would make sense, but as it stands now, I'd put down money that it's actually slower. |
06:00 |
06:00:32 | speachy | (and that's true even if strlen() is optimized...) |
06:05:45 | *** | Saving seen data "./dancer.seen" |
06:08:28 | | Join dconrad [0] (~dconrad@152.117.104.232) |
06:12:46 | | Quit dconrad (Ping timeout: 244 seconds) |
06:17:14 | speachy | ...the !OPTIMIZE_SIZE strcmp actually works roughly the same way as an combined+optimized strlen+memcmp. |
06:32:45 | speachy | so... speaking of optimizations, should I rework that "support >16bit unicode code points" patch to make that entirely optional for smallmem targets? |
06:34:17 | speachy | it adds ~3.3K of static/global RAM usage on mips, and undoubedly more at runtime. |
06:56:53 | | Join dconrad [0] (~dconrad@152.117.104.232) |
07:00 |
07:00:52 | | Join WebGuest12 [0] (~WebGuest1@14-137-67-54.sta.dodo.net.au) |
07:01:12 | | Quit dconrad (Ping timeout: 252 seconds) |
07:15:51 | rb-bluebot | Build Server message: New build round started. Revision a8540390c2, 345 builds, 9 clients. |
07:15:51 | rb-bluebot | FS #13536: Updated German Translation (Karl Huber) by Solomon Peachy |
07:25:21 | speachy | also, instead of playing games postprocessing unicode normalization stuff, IMO we're better off just biting the bullet and doing it properly in the core. this also gets us case folding. |
07:27:04 | speachy | since we don't have the equivalent of itunes to pre-mangle everything for us. |
07:27:41 | speachy | remember this also affects tihngs like playlist files and any other text-based formats. |
07:28:19 | speachy | (and file metadata) |
07:31:29 | | Join luscusrex [0] (~luscusrex@user/luscusrex) |
07:32:16 | | Join nift4 [0] (~nick@132.145.243.111) |
07:33:52 | nift4 | Hi, I've been trying to build for Android and am having some issues. Had to rework installToolchain.sh (will upload that to gerrit once I get this to build), now I pass compliation phase however linker complains about missing symbols |
07:34:18 | nift4 | /home/nick/rockbox/out/firmware/libfirmware.a(thread.o): In function `make_context':\nthread.c:(.text+0xe0): undefined reference to `sigemptyset'\nthread.c:(.text+0xec): undefined reference to `sigaddset'\nthread.c:(.text+0x114): undefined reference to `sigemptyset'\nthread.c:(.text+0x170): undefined reference to `sigfillset'\nthread.c:(.text+0x17c): undefined reference to `sigdelset' |
07:34:52 | nift4 | Is this a known issue? |
07:34:54 | speachy | Back up a few steps; what is committed in git right now builds completely cleanly. |
07:35:46 | speachy | that 'installToolChain.sh' doesn't appear to be part of rockbox at all? |
07:35:55 | | Quit rb-bluebot (Remote host closed the connection) |
07:36:03 | | Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility) |
07:36:56 | speachy | _bilgus: also, wrt the skin_parser shrinkage, can we guarantee that a given image is always going to be under 64K? |
07:37:09 | nift4 | My diff is https://bpa.st/DN2Q - I've followed android/README for building |
07:38:29 | speachy | ah, ok. I confess I've never actually even looked at that file |
07:38:53 | rb-bluebot | Build Server message: Build round completed after 1382 seconds. |
07:38:55 | rb-bluebot | Build Server message: Revision a8540390c2 result: All green |
07:39:17 | speachy | and I set up the necessary sdks manually via the sdk gui.. |
07:40:18 | nift4 | what NDK did you use? I'm using the last NDK that supports gcc (r17) maybe that's too recent? |
07:40:20 | speachy | also I'm not sure any any ndk > r10e works; I recall having problems when I was trying to set tlat all up years ago |
07:40:37 | nift4 | ok let me try r10e and I'll report back |
07:42:09 | speachy | _bilgus: eg a raw 320x240 24-bit bitmap is 230K. |
07:45:01 | | Join dconrad [0] (~dconrad@152.117.104.232) |
07:45:22 | speachy | (in struct image_display) |
07:46:41 | speachy | (unless I'm misunderstanding what 'offset' means in this context) |
07:49:51 | | Quit dconrad (Ping timeout: 276 seconds) |
08:00 |
08:05:49 | *** | Saving seen data "./dancer.seen" |
08:14:18 | | Quit WebGuest12 (Quit: Client closed) |
08:32:42 | | Quit speachy (Quit: WeeChat 4.5.0) |
08:33:28 | | Join dconrad [0] (~dconrad@152.117.104.232) |
08:37:59 | | Quit dconrad (Ping timeout: 252 seconds) |
08:55:13 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
08:55:13 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
09:00 |
09:02:15 | _bilgus | I assume you mean offset for the image strips https://download.rockbox.org/daily/manual/rockbox-agptekrocker/rockbox-buildap4.html#x19-444000D.21 |
09:05:12 | speachy | ah so it's a logical index, not a binary offset |
09:05:37 | _bilgus | and the lag to id is faster you have to do the strlen anyway |
09:05:52 | _bilgus | english to id |
09:06:18 | _bilgus | even if it doesn't match you have to do the strlen to walk the strings |
09:06:33 | _bilgus | but its not near hot enough to matter |
09:06:39 | speachy | hmm. that does change things |
09:07:45 | speachy | couldn't we just look up the string start from the master id[] table instead of walking the raw lang data? |
09:08:52 | speachy | we're iterating over i=0..LANG_LAST_INDEX_IN_ARRAY but not actually using the lang[] adday |
09:09:05 | speachy | ie we don't have to do use strlen |
09:10:42 | _bilgus | man that would be nice.. |
09:12:57 | speachy | I'm like "Wtf was it done this way?" |
09:18:37 | _bilgus | I'm not sure how that would work once you change languages |
09:19:22 | _bilgus | thats my only thought for the 'Why' |
09:19:40 | speachy | it's the same way we look up any string in the system, using that jump table |
09:20:00 | _bilgus | in theory the builtins index should still be right |
09:21:09 | speachy | ie: #define str(x) language_strings[x] |
09:22:02 | | Join dconrad [0] (~dconrad@152.117.104.232) |
09:22:19 | _bilgus | you still have to inspect/walk them figure its looking for the english phrase to match? |
09:22:29 | _bilgus | or I'm missing something.. |
09:22:38 | speachy | ..oh wait that's right. |
09:23:08 | speachy | the language_strings[] array is for the loaded language, not engrish |
09:23:34 | speachy | I vaguely remember having this same realization the last time I ran into this function |
09:23:49 | _bilgus | anyway unless you have a match very early that patch adds 2 extra strlens but anything over about 1/4 of the array ends up faster |
09:24:14 | speachy | thankfully this is only used by the skin code |
09:24:15 | _bilgus | I want it for the tagnav stuff |
09:24:41 | speachy | ah yeah, it's also usd by the tagnav patch in gerrit |
09:25:01 | _bilgus | its still not ot enough to mtter I don't think |
09:25:22 | speachy | I think I agree |
09:25:44 | speachy | not worth burning >4K for an english_strings[] table. |
09:26:26 | | Quit dconrad (Ping timeout: 248 seconds) |
09:29:14 | _bilgus | the rest of the in16_t in xywh were my only other concern but half of them already were shorts |
09:29:38 | speachy | I don't think that's likely to be a problem given the screen resolutions we work with |
09:30:00 | _bilgus | yeah I think people just didn't think about it as they added new ones |
09:30:17 | speachy | hmm, chris_s did more work on g#5932 since I last looked at it but might not be ready still. |
09:30:20 | rb-bluebot | Gerrit review #5932 at https://gerrit.rockbox.org/r/c/rockbox/+/5932 : Database view is fully translatable and entries can be voiced. by Paul Sauro |
09:33:03 | speachy | so... what's still holding up 4.0 at this point? |
09:33:51 | speachy | I mean we're never going to be "done" but what's in flight or known broken that "needs" to be fixed? |
09:34:22 | _bilgus | few bugs (unconfirmed) clip+? that tlb thing |
09:35:05 | speachy | ...my low-level storage changes seem to be stable |
09:35:47 | speachy | the jz47xx usb driver is still completely broken too |
09:35:53 | _bilgus | and IDK of much else kinda waiting to hear about any bugs from this months patch frenzy the other show.. |
09:36:07 | _bilgus | SHOE* |
09:37:07 | _bilgus | I figure as I go through stuff moving things around might bring up some alignment issues |
09:37:10 | speachy | I'm reluctant to land that >16bit unicode thing due to the potential for all sorts of subtle shenanigans. |
09:38:11 | _bilgus | it'd be nice to set that up to by dynamically loaded |
09:38:46 | | Join JanC_ [0] (~janc@user/janc) |
09:38:46 | | Nick JanC is now known as Guest6471 (~janc@user/janc) |
09:38:46 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
09:38:54 | speachy | well, the >16bit support is indepent of the normalization thing |
09:39:01 | _bilgus | oh |
09:39:53 | _bilgus | so with that you don't have the glyph but since its not ignored its still a viable path then? |
09:40:00 | speachy | but I don't really see any way around effectively wiring it up to everything in the core. |
09:40:07 | speachy | (or not at all) |
09:40:55 | speachy | right now if we decode a UCS code point > 16bit we truncate it to 0xfffd (I think). |
09:41:04 | | Quit Guest6471 (Ping timeout: 265 seconds) |
09:41:59 | speachy | I _think_ that has no effect on paths internally (which are raw c strings) |
09:42:27 | speachy | but it may be a problem for (eg) displayed lists. |
09:42:33 | _bilgus | its just the conversion back and forth then |
09:42:57 | _bilgus | once you write it out you lose the info |
09:43:33 | sark | is there a documented bug for that clip+ issue you mentioned ? |
09:47:28 | _bilgus | I seem to have lost it.. I think it came in on the forums |
09:48:21 | _bilgus | its not in flyspray |
09:48:26 | sark | that will make it hard to confirm/reproduce |
09:48:38 | sark | yes, was scrolling through flyspray |
09:48:41 | rb-bluebot | Build Server message: New build round started. Revision 3389a08d56, 345 builds, 9 clients. |
09:48:42 | rb-bluebot | dynamic playlist erase warning: skip for finished playlists by Christian Soffke |
09:49:03 | sark | not much in flyspray that would block a 4.0 from my uneducated point of view |
09:49:55 | | Join chris_s [0] (~chris_s@2a09:bac2:2e70:2464::3a0:46) |
09:53:06 | _bilgus | sark https://forums.rockbox.org/index.php/topic,54557.msg254344.html#msg254344 |
09:55:47 | | Part sark |
09:56:12 | | Join spork [0] (topic@188-142-52-99.fixed.kpn.net) |
09:57:23 | speachy | hmm, our scroll engine.. seems broken for unicode. or at least the buffer is sized for the byte stream not the number of codepoints/glpyhs. |
10:00 |
10:00:12 | nift4 | speachy: g#6286 and g#6288 with ndk r10e made it produce apk file on my host |
10:00:18 | rb-bluebot | Gerrit review #6286 at https://gerrit.rockbox.org/r/c/rockbox/+/6286 : android: make installToolchains.sh work again by nift4 |
10:00:18 | rb-bluebot | Gerrit review #6288 at https://gerrit.rockbox.org/r/c/rockbox/+/6288 : android: target java 1.7 bytecode by nift4 |
10:05:50 | *** | Saving seen data "./dancer.seen" |
10:08:18 | | Quit cnx (Remote host closed the connection) |
10:09:09 | | Join cnx [0] (~cnx@tem.loang.net) |
10:09:11 | rb-bluebot | Build Server message: Build round completed after 1230 seconds. |
10:09:13 | rb-bluebot | Build Server message: Revision 3389a08d56 result: All green |
10:09:24 | rb-bluebot | Build Server message: New build round started. Revision fe78b07db6, 345 builds, 9 clients. |
10:09:24 | rb-bluebot | Playlist Viewer: Address problematic index buffer sharing by Christian Soffke |
10:09:54 | speachy | nift4: thanks! btw we're going to need a RealName to accept patches. |
10:10:13 | _bilgus | speachy pretty sure its aware but I might be thinking of another area |
10:10:48 | _bilgus | I know we have a utf8_len function rolling around in there somewhere |
10:10:48 | speachy | just trying to sort out potential gotchas that I might hav emissed |
10:13:38 | _bilgus | other potential place is the function font_getstringnsize() |
10:14:01 | _bilgus | it uses byte offset instead of looking for a combiner |
10:14:01 | speachy | that I already have fixed |
10:14:27 | speachy | oh wait, not for that issue |
10:14:29 | _bilgus | that was my doing to allow splash to work on read only buffers |
10:16:15 | | Join dconrad [0] (~dconrad@152.117.104.232) |
10:16:31 | speachy | I think that's going to require hte normalization stuff. do we handle combiners at all? |
10:20:23 | | Quit dconrad (Ping timeout: 245 seconds) |
10:27:39 | | Quit chris_s (Quit: Client closed) |
10:27:50 | _bilgus | not sure |
10:28:55 | speachy | I want to say "nope" |
10:31:53 | _bilgus | sorta kinda? utf8length and utf8seek are the building blocks |
10:32:58 | rb-bluebot | Build Server message: Build round completed after 1416 seconds. |
10:33:00 | rb-bluebot | Build Server message: Revision fe78b07db6 result: All green |
10:33:21 | _bilgus | SKIN_TOKEN_SUBSTRING in skin_tokens is aware |
10:34:00 | _bilgus | the keyboard too |
10:34:29 | _bilgus | but they still don't do the combiners |
10:34:51 | speachy | they're all aware (I had to fix all of them up to handle 32-bit codepoints) |
10:34:58 | speachy | but yeah, no combiners at all. |
10:38:25 | _bilgus | not a concern for core stumbling block for user files |
10:38:46 | speachy | yep, that's why utf8proc's [de]normalization is necessary. |
10:41:51 | _bilgus | yeah no way around it thats going to be trouble free |
10:42:35 | _bilgus | you can't just strip them because you will get name conflicts it has to be repeatable in each direction |
10:42:58 | speachy | which means normalizing everything into a common internal representation and matching based on that. |
10:43:06 | _bilgus | I'm sure your list is longer than that.. |
10:43:32 | _bilgus | or devil in details.. |
10:43:40 | speachy | oh it's awful. |
10:43:57 | speachy | still, 32-bit codepoint support is a step in the right direction. |
10:47:45 | _bilgus | it have been nice if the codebase started that way but hwcodec probably held that back |
10:47:56 | nift4 | speachy: in git commiter identity or just say it here? |
10:48:18 | _bilgus | nift4, usually in the credits.. |
10:49:08 | _bilgus | and gerrit but I think that isn't necessary? speachy? |
10:50:19 | nift4 | am i supposed to upload a patch adding myself to docs/CREDITS or how'd that work? |
10:50:53 | _bilgus | yep |
10:51:12 | _bilgus | usually just stack them with the commit or put it in with it |
11:00 |
11:01:26 | | Quit Arsen (Quit: Quit.) |
11:06:29 | | Join Arsen [0] (arsen@gentoo/developer/managarm.dev.Arsen) |
11:06:59 | | Join dconrad [0] (~dconrad@152.117.104.232) |
11:11:27 | | Quit dconrad (Ping timeout: 265 seconds) |
11:24:04 | _bilgus | found this commit looks like the start of unicode support https://github.com/Rockbox/rockbox/commit/7682cb5ca8f201be74dc12c1388cdd69a6c178bc |
11:27:34 | speachy | nift4: in the patches themselves but also in the credits file (and yeah, stack it in with your first commit) |
11:27:36 | _bilgus | that same committer 'tomers' had a hand in alot of that https://github.com/Rockbox/rockbox/commits?author=tomers&after=fe78b07db6bd2806dbbdeca05f263c9e0cf0a57e+244 |
11:28:28 | speachy | nift4: if you aren't comfortable with your identity being public that's ok as long as we have a private record of it should the lawyers come knocking again. |
11:28:45 | _bilgus | the rtl handling and diacritics specifically |
11:29:42 | speachy | our unicode support is surprisingly comprehensive. I'm especially surprised we have RTL stuff in there given how poor the translation coverages have been. |
11:30:41 | _bilgus | seeing they have a patch that shrunk the tables makes me wonder what size it was a first since I have since gone and knocked off a bunch more a few years ago |
11:31:39 | _bilgus | the person hours in this project is staggering |
11:33:07 | speachy | yeah, clearly our forbearers had WayTooMuchTimeOnTheirHands(tm) |
11:36:43 | speachy | I know folks who could update the Arabic and Farsi translations but I don't think they'd ever actually use rockbox so it's quite an ask |
11:42:17 | _bilgus | lol maybe get them into it first lol |
11:42:54 | _bilgus | hey have you tried rockbox oh yeah its great here is a device with songs already loaded for you oh yeah it has language support |
11:44:31 | _bilgus | then just wait for them to get annoyed by it and bring it up :p |
11:48:31 | _bilgus | I was looking for themes that used a lot of ram on the clipzip to test out that patch and I found one called 'Pro' that uses 277k |
11:49:20 | _bilgus | 207k of that is images |
11:53:27 | _bilgus | I think most of that is two images volume-knob.bmp which is an image strip and hold-hack.bmp which is a mask, both seem far larger than the screen uses so I wonder if we store the full image and scale on display or if we scale on load and (maybe scale again later) |
11:55:22 | _bilgus | if the former it might be a good idea to scale on load to something more managable. other thought would be image strips I wonder if we could store differences instead of the whole image, and if its worthwhile to slow down each step to do so |
11:56:21 | | Join dconrad [0] (~dconrad@152.117.104.232) |
11:57:19 | _bilgus | like load and store the initial image and store masks instead of actual images for the rest worst case the image is totally different and you tore the whole thing best case it has small changes and the mask is just a few bytes so you load initial image and apply the mask for the offset |
12:00 |
12:00:25 | | Quit lebellium (Quit: Leaving) |
12:00:54 | | Quit dconrad (Ping timeout: 260 seconds) |
12:03:49 | _bilgus | yeah we read bitmaps in directly |
12:05:53 | *** | Saving seen data "./dancer.seen" |
12:07:11 | _bilgus | read_bmp_fd does support scaling if defined(HAVE_BMP_SCALING) so that might be pretty easy |
12:07:55 | | Quit jjs0077018310196 (Ping timeout: 264 seconds) |
12:08:38 | _bilgus | hmm but I bet that messes with the offsets they supply for the image strips though |
12:09:03 | _bilgus | well the height of the element they supply |
12:10:06 | _bilgus | wonder if the images carry around their format where I could check before I load it |
12:18:44 | _bilgus | cleanscreen_spinaltap takes the cake at nearly 800k |
12:21:15 | _bilgus | again with an image strip for the volume that seems way to high res |
12:22:09 | _bilgus | might be better to just go through and update the themes that have abnormally large image strips |
12:28:58 | | Join dconrad [0] (~dconrad@152.117.104.232) |
12:33:45 | | Quit dconrad (Ping timeout: 260 seconds) |
12:37:09 | _bilgus | Ah I see now they use it as a full screen item and it looks weird scaled |
12:38:36 | _bilgus | but really what they should have done is make a background image at screen size and then make the image in the image strip half what it was with transparent regions |
12:40:08 | _bilgus | assuming you can display both (if the theme engine supports it) speachy do we have a way to upload updated themes thru the page or do we have to upload to the server drect? |
12:41:03 | _bilgus | I assume we have a list of the original uploader email somewhere.. |
12:58:47 | _bilgus | from the spinaltap wps '# The 83 images in the volume bitmap image break down as follows: 1 image for mute (-81dB), 80 images(-80dB through -1dB) for reduced-volume sound, 1 image for unreduced-volume sound (0dB), and 1 image for peak sound (1dB through 6dB)' |
12:59:02 | _bilgus | so 83 screen sized images |
12:59:59 | _bilgus | I think its less more like 23 but I bet the note is from the original |
13:00 |
13:02:22 | nift4 | speachy: sorry for late reply, busy with new years, will upload in next few days |
13:17:31 | speachy | _bilgus: one can update/replace an existing theme, yes. |
13:18:02 | speachy | if you're the owner, anyway. an admin _should_ be able to do that too. |
13:18:32 | speachy | nift4: no worries, if it's not already clear rockbox isn't exactly schedule-driven |
13:25:09 | | Join dconrad [0] (~dconrad@152.117.104.232) |
13:25:16 | | Quit COMPL_EXE (Read error: Connection reset by peer) |
13:25:36 | | Join COMPL_EXE [0] (~compl.exe@aosc/dev/origincode) |
13:30:07 | | Quit dconrad (Ping timeout: 264 seconds) |
14:00 |
14:02:50 | | Join dconrad [0] (~dconrad@152.117.104.232) |
14:05:54 | *** | Saving seen data "./dancer.seen" |
15:00 |
15:41:24 | _bilgus | it looks to me that there isn't a way to do what I want which is to display a background image and an imagestrip as well ill have to see if I can get it to work using whats existing but I still need a way to get it centered without supplying coords maybe te 9 segment stuff might do it |
15:55:41 | _bilgus | looks like 9 segment bmps are just made to ensure good scaling it doesn't look like there is a way to do an image strip with it |
15:56:31 | rb-bluebot | Build Server message: New build round started. Revision 832e0fd458, 345 builds, 9 clients. |
15:56:31 | rb-bluebot | update .gitignore to ignore macos files by Yakov |
16:00 |
16:03:50 | | Quit emash (Ping timeout: 244 seconds) |
16:05:59 | *** | Saving seen data "./dancer.seen" |
16:15:39 | | Join emash [0] (~emash@user/emash) |
16:17:11 | | Join Everything [0] (~Everythin@195.138.86.118) |
16:18:03 | rb-bluebot | Build Server message: Build round completed after 1293 seconds. |
16:18:05 | rb-bluebot | Build Server message: Revision 832e0fd458 result: All green |
16:20:22 | speachy | huh, my builder corrupted its rockbox git dir |
16:55:07 | | Quit luscusrex (Quit: Leaving) |
17:00 |
17:41:16 | | Quit user890104 () |
17:58:12 | | Quit Everything (Quit: leaving) |
18:00 |
18:06:01 | *** | Saving seen data "./dancer.seen" |
18:07:59 | | Join user890104 [0] (~Venci@freemyipod/user890104) |
18:51:12 | | Join massiveH [0] (~massiveH@2600:4040:a982:5400:d071:ba43:7a81:7834) |
19:00 |
19:56:42 | | Quit dconrad (Remote host closed the connection) |
20:00 |
20:06:05 | *** | Saving seen data "./dancer.seen" |
20:12:41 | | Join dconrad [0] (~dconrad@152.117.104.232) |
20:15:58 | | Quit dconrad (Remote host closed the connection) |
20:16:11 | | Join dconrad [0] (~dconrad@152.117.104.232) |
20:26:19 | rb-bluebot | Build Server message: New build round started. Revision 44e36aba94, 345 builds, 9 clients. |
20:26:19 | rb-bluebot | skin_render small cleanup by William Wilgus |
20:42:50 | rb-bluebot | Build Server message: Build round completed after 991 seconds. |
20:42:52 | rb-bluebot | Build Server message: Revision 44e36aba94 result: All green |
22:00 |
22:06:08 | *** | Saving seen data "./dancer.seen" |
22:38:24 | _bilgus | ah crap I apparently pushed the wrong version of my strcasestr function |
23:00 |
23:00:54 | | Join babagu [0] (~babagu@185.34.32.217) |
23:01:00 | babagu | hello there! |
23:02:33 | babagu | i hope this is the right place to ask. I have read the FM and searched on the forums, but maybe missed something. i have a pretty well functioning install of rockbox on a Surfans F20, but upon launching any plugin, i have an "incompatible version" message. is that a known issue? anyone has an idea of what to do to fix it? what did i miss? thanks! |
23:03:01 | babagu | (i am so pleased of finding rockbox in such an active state, about 15y after the last time i had used it last!! <3) |
23:07:50 | | Quit dconrad (Remote host closed the connection) |
23:08:38 | rb-bluebot | Build Server message: New build round started. Revision e79996e031, 345 builds, 9 clients. |
23:08:38 | rb-bluebot | [Bugfix] strcasestr by William Wilgus |
23:09:23 | _bilgus | babagu, you have plugins that don't match your running version |
23:10:23 | _bilgus | sometimes its that things have changed and your best bet is to rename that .rockbox go download the latest dev version and unzip to your device as a fresh install |
23:10:59 | _bilgus | then you can transfer anything important over from the old install and or delete it |
23:12:29 | _bilgus | if that doesn't work or this was a clean install maybe something got broken in the build |
23:17:46 | | Quit babagu (Quit: Client closed) |
23:21:24 | | Quit jn (Ping timeout: 252 seconds) |
23:21:29 | | Join jn_ [0] (~quassel@2001-4dd4-9638-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) |
23:21:29 | | Quit jn_ (Changing host) |
23:21:29 | | Join jn_ [0] (~quassel@user/jn/x-3390946) |
23:22:43 | rb-bluebot | Build Server message: Build round completed after 846 seconds. |
23:22:45 | rb-bluebot | Build Server message: Revision e79996e031 result: All green |
23:23:49 | | Join dconrad [0] (~dconrad@152.117.104.232) |
23:28:32 | | Quit dconrad (Ping timeout: 265 seconds) |
23:42:24 | | Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) |