| 00:21:36 | | Quit othello7 (Ping timeout: 268 seconds) |
| 00:35:51 | | Quit CH23[x] (Ping timeout: 255 seconds) |
| 00:36:44 | | Join jacobk [0] (~quassel@64.189.201.150) |
| 00:42:00 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:11:54 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 01:14:43 | | Quit advcomp2019 (Ping timeout: 260 seconds) |
| 01:41:04 | | Quit AlHaz (Remote host closed the connection) |
| 01:41:23 | | Join AlHaz [0] (~AlHaz@166.70.59.28) |
| 02:00 |
| 02:36:58 | | Quit ukleinek (Quit: reboot) |
| 02:42:01 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:11:29 | | Quit jacobk (Ping timeout: 268 seconds) |
| 04:00 |
| 04:25:35 | | Quit PheralSparky (Quit: Leaving) |
| 04:26:00 | | Quit speachy (Quit: WeeChat 4.2.2) |
| 04:42:04 | *** | Saving seen data "./dancer.seen" |
| 04:43:41 | | Join lebellium [0] (~lebellium@2a01cb0405d07f0040242e96eac75f17.ipv6.abo.wanadoo.fr) |
| 05:00 |
| 05:08:20 | | Quit berber_l51 (Quit: The Lounge - https://thelounge.chat) |
| 05:31:49 | | Join berber_l51 [0] (~berber@2a03:4000:7:4e0::) |
| 06:00 |
| 06:25:09 | | Join f_ [0] (~AUGESOUND@fases/developer/funderscore) |
| 06:29:26 | | Quit CH23[m] (Read error: Connection reset by peer) |
| 06:29:41 | | Join CH23[m] [0] (~CH23@revspace/participant/ch23) |
| 06:42:07 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:01:11 | | Quit Bobathan_ (Ping timeout: 264 seconds) |
| 07:01:23 | | Quit f_ (Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.) |
| 07:08:02 | | Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) |
| 07:52:41 | | Join CH23 [0] (~CH23@revspace/participant/ch23) |
| 07:53:19 | | Quit CH23 (Client Quit) |
| 08:00 |
| 08:28:51 | | Join speachy [0] (~speachy@hurricane.shaftnet.org) |
| 08:28:51 | | Quit speachy (Changing host) |
| 08:28:51 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 08:28:51 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 08:42:11 | *** | Saving seen data "./dancer.seen" |
| 08:44:53 | | Quit Bobathan_ (Ping timeout: 272 seconds) |
| 08:49:45 | | Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) |
| 09:00 |
| 09:47:23 | | Quit CH23[m] (Ping timeout: 264 seconds) |
| 09:49:06 | | Join CH23[m] [0] (~CH23@revspace/participant/ch23) |
| 10:00 |
| 10:01:50 | | Join jacobk [0] (~quassel@64.189.201.150) |
| 10:42:14 | *** | Saving seen data "./dancer.seen" |
| 10:42:41 | rb-bluebot | Build Server message: New build round started. Revision 0a89d1d4df, 304 builds, 10 clients. |
| 10:42:41 | rb-bluebot | Fix a typo in English by Solomon Peachy |
| 10:43:24 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 10:50:54 | speachy | huh. running the sim I see this: |
| 10:50:59 | speachy | read_bmp_file: can't open '/.rockbox/icons/viewers.bmp', rc: -3 |
| 10:51:15 | speachy | what _is_ present is viewers.6x8x1.bmp |
| 10:53:42 | rb-bluebot | Build Server message: Build round completed after 661 seconds. |
| 10:53:43 | rb-bluebot | Build Server message: Revision 0a89d1d4df result: All green |
| 10:58:52 | jssfr | so sandisk support says the troublesome card is genuine. |
| 11:00 |
| 11:03:17 | jssfr | any "easy way" (i.e.: maybe a constant or two to change in the rockbox source) to increase read timeouts or something in the bootloader? |
| 11:13:23 | _bilgus_ | nothing in the bootloader is easy since we don't update them very often |
| 11:13:25 | speachy | I'm still suspecting GPT. |
| 11:13:51 | speachy | it's common to have an "compatibillity MBR" in place |
| 11:14:05 | _bilgus_ | Ive had some weird stuff where the drive showed as FAT32 on computers but wouldn't work in device |
| 11:14:23 | speachy | what does rockbox's debuginfo say about the actual partitions? |
| 11:14:56 | _bilgus_ | when I looked with a disk hex editor it had like pasted over the previous and once I erased the disk and reformatted it was fine |
| 11:15:24 | speachy | depending on exactly when those bootloaders were built, I know I made robustness improvements to the partition parsing and FAT code. |
| 11:16:07 | _bilgus_ | yes the difference being that the older bootloaders are more permissive than the FW |
| 11:16:23 | speachy | heh, we know all of our bootloaders _compile_ cleanly with current git master but that's not to say that they actually _work_. |
| 11:16:25 | _bilgus_ | that should be in those bootloaders I linked |
| 11:16:59 | _bilgus_ | jssfr I'll cut a new bootloader tonight for you just to be sure we are using the very latest |
| 11:17:25 | jssfr | _bilgus_, <3 |
| 11:17:50 | _bilgus_ | yeah till tested I don't want to update any of the bootloaders |
| 11:17:52 | jssfr | speachy, you mean, the boot info debug menu? or is there something else to look at? |
| 11:18:02 | _bilgus_ | I've got the sansas pretty well covered |
| 11:18:20 | speachy | system/debug/view partitions |
| 11:18:46 | jssfr | (note that the card seems to work fine post bootloader) |
| 11:20:36 | jssfr | speachy, https://paste.debian.net/hidden/e4b5acdb/ if I typed this correctly |
| 11:20:40 | _bilgus_ | my (clipzip) partition info reads 0 for P0-P3 and p5-p7 p4 reads S:800 T:b 121941 MB |
| 11:20:51 | jssfr | (I changed the partition size of the SD card to ~60 GB the other day to see if it's about that) |
| 11:20:56 | jssfr | *it's about the size) |
| 11:21:37 | _bilgus_ | wonder why my start is 800 vs yours at 8000 |
| 11:23:06 | speachy | ~400K vs 4MB, huh. Not that this should matter. |
| 11:23:07 | _bilgus_ | IDK let me check another card |
| 11:23:29 | jssfr | odd is that fdisk says start is 32768 |
| 11:23:36 | speachy | that's just where the partitioner set up the first partiton. @1MB is typical these days. |
| 11:23:38 | jssfr | ah. |
| 11:23:39 | jssfr | hex. |
| 11:24:13 | speachy | 0x8000 places the first partition at 16MB. |
| 11:24:33 | speachy | nothing wrong with that either |
| 11:24:40 | _bilgus_ | hmm my other clipzip has all the P entries filled and totally different |
| 11:24:46 | jssfr | what were marker bytes of GPT again? I only know MBR :) |
| 11:25:21 | _bilgus_ | sorry I gtg will check back |
| 11:25:27 | speachy | P0-3 would be the internal storage. |
| 11:25:31 | speachy | P4-7 are the SD card |
| 11:25:44 | jssfr | _bilgus_, no worries! I have to leave soon-ish for the day, too. |
| 11:26:05 | _bilgus_ | Id say this card has lots of partitions and junk its v. old |
| 11:26:23 | jssfr | according to hexdump, there's nothing between 0x200 and 0x01000000 |
| 11:26:28 | _bilgus_ | 8 gb |
| 11:26:35 | _bilgus_ | if that says anything |
| 11:26:39 | jssfr | which means there's no GPT, I think? |
| 11:27:53 | speachy | GPT would be mirrored after the MBR and at the end, yteah. |
| 11:29:05 | speachy | well, sector 1 (ie offset 0x100) would have the GPT. |
| 11:30:10 | _bilgus_ | I'd really try wiping the damn thing and formatting it with something different or at least wiping it with dd first |
| 11:30:19 | speachy | if sector 1 starts with 0x5452415020494645 it has a GPT. |
| 11:30:43 | speachy | we don't checksum the GPT fwiw. |
| 11:31:00 | speachy | it's possible there is a garbled GPT there that we're tripping over |
| 11:31:42 | _bilgus_ | I swear I'm going to make a disk format plugin one of these days |
| 11:32:35 | speachy | dd if=/dev/zero of=/dev/sdX bs=512 count=1 seek=1 |
| 11:34:01 | _bilgus_ | thats what I did when I had this issue |
| 11:34:33 | _bilgus_ | first time I took it to a windows pc and did a ll format which is on the forum |
| 11:35:05 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 11:35:22 | _bilgus_ | second time dd'd the entire thing in linux that worked too and was faster than finding windows |
| 11:35:50 | speachy | hmm, we only try to do a GPT parse if there is a MBR that includes a GPT_GUARD partition type. |
| 11:36:16 | speachy | but the debuginfo doesn't include that so this isn't the problem. |
| 11:36:33 | jssfr | speachy, this is in bytes, so 0x200 is actually the end of sector 1 |
| 11:36:49 | speachy | of course. |
| 11:36:54 | speachy | sorry, brain being really special today |
| 11:36:56 | jssfr | and from there on it's all zeroes |
| 11:36:58 | jssfr | it's ok:) |
| 11:38:35 | jssfr | I can wipe sector one tomorrow and see what that does, though fdisk doesn't see anything suspicious |
| 11:38:39 | jssfr | gotta go now though |
| 11:38:41 | jssfr | see you |
| 11:38:46 | jssfr | and thanks a lot so far! |
| 11:39:37 | | Quit CH23[m] (Ping timeout: 268 seconds) |
| 11:41:21 | | Join CH23[m] [0] (~CH23@revspace/participant/ch23) |
| 11:47:11 | | Quit CH23[m] (Read error: Connection reset by peer) |
| 11:47:42 | | Join CH23[m] [0] (~CH23@revspace/participant/ch23) |
| 11:47:52 | | Join f_ [0] (~AUGESOUND@fases/developer/funderscore) |
| 12:00 |
| 12:42:18 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:04:06 | | Quit jacobk (Ping timeout: 268 seconds) |
| 13:50:42 | | Nick f_ is now known as f_|afk (~AUGESOUND@fases/developer/funderscore) |
| 13:51:04 | | Nick f_|afk is now known as f_ (~AUGESOUND@fases/developer/funderscore) |
| 13:52:57 | | Join jacobk [0] (~quassel@utdpat241106.utdallas.edu) |
| 14:00 |
| 14:04:05 | | Quit CH23[m] (Ping timeout: 272 seconds) |
| 14:04:15 | | Join CH23[m] [0] (~CH23@revspace/participant/ch23) |
| 14:42:22 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:00:39 | | Quit CH23[m] (Read error: Connection reset by peer) |
| 15:00:54 | | Join CH23[m] [0] (~CH23@revspace/participant/ch23) |
| 15:45:57 | | Quit davisr (Quit: yeehaw) |
| 16:00 |
| 16:01:30 | | Quit Bobathan_ (Ping timeout: 255 seconds) |
| 16:01:56 | _bilgus_ | so I want to extend openplugin to basically be a way to load plugins by hash for the shortcut plugin and really anywhere someone needs to store a path. currently it just makes hashes from the filename and stores the records to disk for later lookup |
| 16:03:05 | _bilgus_ | I'm a bit worried about collisions with the current code though running on my device all paths generate a unique hash but thats just luck |
| 16:03:47 | | Quit sam_d (Ping timeout: 272 seconds) |
| 16:04:40 | _bilgus_ | so my idea is to store the hashes in the header as a lookup table into the record offsets and as a way to check collisions if a hash matches something in the db then we need to check if it has the same path and if not add 1 and try again |
| 16:04:58 | speachy | what's the hash algorithm? |
| 16:05:07 | _bilgus_ | FNV1a |
| 16:06:11 | speachy | are you hashing the file you're trying to open basically? |
| 16:06:20 | _bilgus_ | well the path |
| 16:06:50 | | Quit f_ (Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.) |
| 16:06:51 | _bilgus_ | its not really a hash table its more like a uuid |
| 16:07:03 | speachy | hmm. |
| 16:07:37 | speachy | to save the user from having to re-select the plugin they selected? |
| 16:08:36 | _bilgus_ | it is really a database so you can recall a file path by the hash |
| 16:09:11 | speachy | in-ram? on disk? what are its bounds? how does stuff get expired or dropped>? |
| 16:09:24 | _bilgus_ | currently its on disk |
| 16:09:26 | speachy | (what if you select the wrong plugin?)_ |
| 16:09:39 | _bilgus_ | I figure you want to run a plugin you are hitting the disk anyway |
| 16:10:21 | _bilgus_ | well then you run the wrong plugin till you select another |
| 16:10:44 | _bilgus_ | the stuff for the start screen (core) keys off lang id which sucks a bit |
| 16:12:08 | speachy | I mean if the system remembers the (wrong) plugin how will the suers elect a different one next time? Or is this just an optimization to push the last used plugin to the top of the list or something like that? |
| 16:13:27 | _bilgus_ | the system won't remember the wrong one it checks if the lang ids are wrong and dumps those core ones, the ones by file path hash should always be good |
| 16:13:56 | _bilgus_ | there is also a plugin if you want to look at the dat file and edit them |
| 16:14:34 | speachy | I just wonder if this is a lot of extra complexity for not much benefit |
| 16:14:57 | | Join sam_d [0] (~sam@user/sam-d/x-8933526) |
| 16:15:46 | _bilgus_ | it works as is but I think with some robustness for the generated hashes it should allow some code savings esp in regards to the shortcut plugin |
| 16:16:11 | _bilgus_ | currently it makes a big old link list for every shortcut with a path or not |
| 16:16:34 | _bilgus_ | think like 600bytes a pop |
| 16:17:01 | _bilgus_ | pretty sure I can get my hash table in there with a single entry |
| 16:17:20 | _bilgus_ | (the look up one) |
| 16:22:07 | | Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) |
| 16:22:32 | _bilgus_ | tbh it'd probably just work but I worry if its moe than a few core plugins that a hash colliding would make for a very confused user |
| 16:23:24 | _bilgus_ | and currently theres no way to rectify or even know (in the code) |
| 16:25:35 | _bilgus_ | again the core stuff is keyd on lang_ids so no worries there but if I expand it to general use.. |
| 16:37:18 | | Quit kugel_ (Remote host closed the connection) |
| 16:42:23 | *** | Saving seen data "./dancer.seen" |
| 16:49:09 | | Join kugel_ [0] (~kugel@ip4d164469.dynamic.kabel-deutschland.de) |
| 16:50:31 | | Join PheralSparky [0] (~Shawn@user/shawn/x-4432647) |
| 16:59:28 | | Quit kugel_ (Ping timeout: 260 seconds) |
| 17:00 |
| 17:01:17 | | Join kugel [0] (~kugel@ip4d164469.dynamic.kabel-deutschland.de) |
| 17:05:03 | | Quit kugel (Client Quit) |
| 17:14:06 | | Quit lebellium (Quit: Leaving) |
| 18:00 |
| 18:01:02 | | Quit Bobathan_ (Ping timeout: 268 seconds) |
| 18:30:40 | | Join CH23_ [0] (~CH23@revspace/participant/ch23) |
| 18:42:25 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:32:41 | | Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) |
| 19:58:24 | | Join ac_laptop [0] (~ac_laptop@2001:910:107e:0:e29d:31ff:fe2d:a258) |
| 20:00 |
| 20:01:29 | | Quit ac_laptop (Client Quit) |
| 20:06:49 | | Join massiveH [0] (~massiveH@2600:4040:a982:c800:dc5d:ce6f:a48f:4b45) |
| 20:18:48 | | Quit IPG (Read error: Connection reset by peer) |
| 20:20:57 | speachy | winrat: My mini2g: p1 @63, len 80262. p2@80325, filling the rest of the disk. |
| 20:42:30 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:16:03 | | Join CH23 [0] (~CH23@revspace/participant/ch23) |
| 21:45:54 | rb-bluebot | Build Server message: New build round started. Revision 8c86fb6da0, 304 builds, 9 clients. |
| 21:45:55 | rb-bluebot | arm: Use -masm-syntax-unified when compiling with gcc8 or newer by Solomon Peachy |
| 21:55:41 | rb-bluebot | Build Server message: Build round completed after 587 seconds. |
| 21:55:42 | rb-bluebot | Build Server message: Revision 8c86fb6da0 result: 32 errors 0 warnings |
| 22:00 |
| 22:00:48 | speachy | missed one, d'oh. |
| 22:04:18 | rb-bluebot | Build Server message: New build round started. Revision 1957237a46, 304 builds, 9 clients. |
| 22:04:18 | rb-bluebot | Fix red in 8c86fb6da0 (ipod5g only) by Solomon Peachy |
| 22:13:32 | rb-bluebot | Build Server message: Build round completed after 555 seconds. |
| 22:13:33 | rb-bluebot | Build Server message: Revision 1957237a46 result: All green |
| 22:14:12 | rb-bluebot | Build Server message: New build round started. Revision e37cd0f2f5, 304 builds, 9 clients. |
| 22:14:12 | rb-bluebot | x1000: Enable NOCROSSREFS_TO() by Aidan MacDonald |
| 22:21:26 | speachy | trying to flush out some of these patches that are enabled by the new toolchain |
| 22:23:17 | rb-bluebot | Build Server message: Build round completed after 546 seconds. |
| 22:23:19 | rb-bluebot | Build Server message: Revision e37cd0f2f5 result: 20 errors 0 warnings |
| 22:23:23 | | Quit Bobathan_ (Ping timeout: 264 seconds) |
| 22:25:33 | speachy | that's odd. I just built this. |
| 22:27:17 | mendel_munkis | Sorry about the errors, I am bringing up uzziyah on a new box after moving and forgotto install sdl-dev |
| 22:27:23 | speachy | no that's not you |
| 22:27:42 | speachy | well, not all yopu |
| 22:29:58 | mendel_munkis | Is there any way for me to trigger a full build round locally? |
| 22:30:15 | mendel_munkis | I.E make sure I am not missing any other dependencies |
| 22:31:32 | speachy | just execute a build yourself |
| 22:31:58 | speachy | ie run configure, pick an appropriate target+options, make |
| 22:32:59 | | Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) |
| 22:40:30 | rb-bluebot | Build Server message: New build round started. Revision 54389dcf2f, 304 builds, 9 clients. |
| 22:40:31 | rb-bluebot | configure: fix test for LD version on non-macos systems by Solomon Peachy |
| 22:42:31 | *** | Saving seen data "./dancer.seen" |
| 22:45:09 | speachy | mendel_munkis: the buildclient should have bailed if sdl-config wasn't working |
| 22:46:32 | mendel_munkis | nope, it just wrote a no upload message and then went on to the next build |
| 22:49:12 | rb-bluebot | Build Server message: Build round completed after 523 seconds. |
| 22:49:13 | rb-bluebot | Build Server message: Revision 54389dcf2f result: All green |
| 22:49:16 | rb-bluebot | Build Server message: New build round started. Revision 6e82897bfc, 304 builds, 10 clients. |
| 22:49:16 | rb-bluebot | make: Update help text by Solomon Peachy |
| 22:57:46 | rb-bluebot | Build Server message: Build round completed after 511 seconds. |
| 22:57:47 | rb-bluebot | Build Server message: Revision 6e82897bfc result: All green |
| 23:00 |
| 23:04:04 | | Quit massiveH (Quit: Leaving) |
icon identifies that the person is a core developer (has commit access).