--- Log for 18.04.120 Server: livingstone.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 16 days and 18 hours ago 00.02.49 *** Saving seen data "./dancer.seen" 00.18.34 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 00.19.52 Join prof_wolfff [0] (~prof_wolf@195.206.107.25) 00.30.14 Join PimpiN8 [0] (~PimpiN8@178.239.173.228) 01.06.22 Quit lebellium (Quit: Leaving) 01.20.16 Join ZincAlloy1 [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 01.21.11 Quit ZincAlloy (Ping timeout: 256 seconds) 01.28.24 Quit pamaury (Ping timeout: 256 seconds) 01.48.10 Quit ZincAlloy1 (Quit: Leaving.) 01.58.45 Quit petur (Quit: Leaving) 02.02.52 *** Saving seen data "./dancer.seen" 02.21.27 Quit MrZeus (Ping timeout: 258 seconds) 02.49.47 Quit sakax (Remote host closed the connection) 03.17.43 Join MrZeus [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net) 03.24.04 Join massiveH [0] (~massiveH@ool-18e4eaeb.dyn.optonline.net) 03.25.00 Quit MrZeus (Ping timeout: 250 seconds) 03.26.17 # offhand, anyone know what happened to the gerrit commit hook that announced commits to twitter, the mailing list, and presumably IRC too? 03.26.46 # or is it one of those thigns that fell into disrepair as the gerrit instance became mostly unmaintained? 03.27.34 # (I suppose it could have been switched off intentionally...) 03.28.03 Quit blackyus17 (Ping timeout: 265 seconds) 03.33.47 Quit prof_wolfff (Ping timeout: 256 seconds) 03.38.35 Join blackyus17 [0] (~blackyus1@ip189.ip-144-217-213.net) 04.02.56 *** Saving seen data "./dancer.seen" 04.20.23 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 04.29.45 Join fenugrec [0] (~fenugrec@97.107.220.18) 04.31.25 # Hi, I'm having issues with Rockbox (hold on, I forgot the version #) on a Sansa Fuze : copying files to the external SD causes the device to shutdown pretty much instantly 04.31.52 # the Fuze is old now, is there still any point in filing a proper bug report / getting debug info ? 04.35.32 # it crashes / shutdowns when copying to the internal memory too, for that matter...\ 04.51.25 Quit chrisb (Quit: leaving) 04.54.13 # I can write to that uSD card just fine in another reader, so I'm inclined to believe the card itself is not (totally) the problem 05.13.33 Quit fenugrec (Ping timeout: 256 seconds) 05.37.09 Part Aldem ("Leaving") 05.54.02 Quit massiveH (Quit: Leaving) 05.58.02 Quit [7] (Ping timeout: 246 seconds) 05.58.46 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.02.59 *** Saving seen data "./dancer.seen" 06.38.30 Join advcomp2019 [0] (~advcomp20@65-131-163-116.sxct.qwest.net) 06.38.30 Quit advcomp2019 (Changing host) 06.38.30 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 06.40.13 Quit advcomp2019_ (Ping timeout: 240 seconds) 07.48.27 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 08.03.03 *** Saving seen data "./dancer.seen" 09.17.17 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr) 10.03.04 *** No seen item changed, no save performed. 10.22.55 Join prof_wolfff [0] (~prof_wolf@195.206.107.25) 10.47.57 Join MrZeus [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net) 10.56.51 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 11.01.29 Quit ZincAlloy (Ping timeout: 256 seconds) 11.04.09 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.09.11 Quit ac_laptop (Ping timeout: 265 seconds) 11.20.16 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 11.20.45 Quit advcomp2019 (Ping timeout: 256 seconds) 11.38.36 Join dys [0] (~dys@tmo-100-92.customers.d1-online.com) 11.42.25 Quit S|h|a|w|n (Read error: Connection reset by peer) 11.42.49 # fenugrec should have upgraded to the latest Dev version before trying to diagnose bugs, My guess would be a weak battery or funny voltagr settings on the cpu 11.43.10 # My guess would be a dead battery 11.51.55 Quit pamaury (Ping timeout: 256 seconds) 12.03.07 *** Saving seen data "./dancer.seen" 12.23.40 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 12.46.44 Quit prof_wolfff (Ping timeout: 256 seconds) 12.57.05 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.29.57 Quit sakax (Ping timeout: 256 seconds) 14.01.44 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 14.03.09 *** Saving seen data "./dancer.seen" 14.21.04 Join prof_wolfff [0] (~prof_wolf@195.206.107.25) 14.29.17 Quit prof_wolfff (Ping timeout: 265 seconds) 14.50.53 Quit sakax (Ping timeout: 258 seconds) 14.52.00 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 14.52.04 Quit sakax (Client Quit) 15.08.21 Join fenugrec [0] (~fenugrec@97.107.220.18) 15.10.22 Quit koniu (Ping timeout: 240 seconds) 15.10.36 # yay, nighty voice and manual builds went off without a hitch this time. Fixed another bug in the logbot rottion code, but I do believe all of the moving pieces are good. 15.11.18 # just need to schedule a suitable window for the final transition. 15.21.59 Quit Rower (Ping timeout: 256 seconds) 15.22.27 Join Rower [0] (~husvagn@d83-183-134-99.cust.tele2.se) 15.23.53 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 15.24.28 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 15.35.38 # Looks like we really need to put in a wipe Config file option 15.36.33 # I know there must be something funky about the version checking code in the cfg file 15.37.31 # hmm, wasn't it just a config version ID? Or do we actually try to read the whole thing regardless? 15.37.46 # or I suppose it could be an option that has bad input 15.38.13 # do we have a copy of the offending cfg file? 15.42.28 # I think I asked for it last few times but generally we never get them bc deleting it fixes the issue 15.43.56 # I don't actually see any version checking in the cfg load code 15.44.20 # https://github.com/Rockbox/rockbox/blob/master/apps/settings.c 15.45.16 Join krabador [0] (~krabador@unaffiliated/krabador) 15.45.32 # Hi, is there any debug logging related to USB MSC mode ? I'm getting crashes when writing to the uSD card over USB on a Fuze 15.46.14 # (v 3.14) 15.46.45 # fenugrec, update to 3.15 first, and see if it's still a problem. 15.46.55 # speachy, will do. brb 15.48.05 # Bilgus, it's a little inefficient, it effectively ignores keys that aren't recognized.. but there's no protection against (eg) a bad enum setting. 15.50.01 # as there's no range checks baked into the settings parser.. 15.50.02 # maybe we could put a version Id 'setting' 15.50.27 # then if it doesn't match either ignore the config or ask the user 15.51.04 # ie a (ignore once, import, restore defaults) choice? 15.51.33 # and it would be incumbent upon us to bump that version string every time the setings list changes? 15.52.09 # heh, maybe we could get clever and do a checksum of the compiled settings_list table. 15.52.26 # so any change in the table means the old config is potentially invalid. 15.52.27 # we already have a version number baked into the fw 15.52.53 # we just write that as the version string each time the settings getsaved 15.52.58 # I don't want it to use the compiled fw version, folks that use daily builds will potentially have to reset their config every time they update, which seems unnecessary 15.53.15 # they just say import 15.53.44 # tada when it writes again the new version string is saved 15.54.09 # new build new prompt 15.54.19 # config loading happens pretty early on though, is it feasible to prompt the user that early (before potentially loading in a config that trashes things?) 15.54.30 # you could also IGNORE ALWAYS 15.55.12 # even if it loads and trashes things they can always restart after 15.55.56 # we don't actually HAVE to have a prompt it could just be a WARNING in the settings 15.56.15 # WARNING CONFIG VER MISMATCH 15.56.39 # pretty sure we have a config reset option 15.57.24 # yeah, "reset settings" in the manage settings menu 15.57.34 # yeah I just had to look too 15.58.18 # so we already have the means just bring user to that menu after they answer 15.59.15 # I'll think something up< I don't think its feasible to sanatize the settings 15.59.36 # no, sanitizing the settings is effectively impossible (especially across the swath of tergets) 15.59.38 # although there already is a mechinism for checking their values 15.59.57 # they all get checked when the setting is input 16.00.30 # but I veered away from that due to the fact those Ranges don't always match what people want 16.00.43 # 32000 files in the browser for instance 16.01.25 # atm they can bump that in the cfg if I check inputs they get what they get (and throw a fit?) 16.02.17 # we really should check be checking enum ranges where they're known. 16.03.13 *** Saving seen data "./dancer.seen" 16.03.15 # then you have to go through and specify what shouldn't be checked 16.03.18 # because no version check will catch a file deliberately modified.. 16.03.31 # speachy, ok, can't reproduce with 3.15, but I also fsck'd the uSD so that might have helped too... 16.04.21 # I feel like if you screw it up deliberatly then you kno why its screwed up 16.04.24 # but I do get a strange dmesg entry " sdd: detected capacity change from 7948206080 to 0 " after unmounting the uSD 16.04.52 # fenugrec, the card was logically "ejected" from the slot. 16.05.02 # that sounds like a entirely logical message 16.05.09 # lol 16.05.15 # that^ 16.06.15 # Idk i'll mull it over if we are going to check enums then 16.06.25 # I might crc the whole file 16.06.54 # get rid of manual editing and give them a script 16.08.09 # or just get rid of manual editing and se some better limits 16.08.14 # well, for now we know checking to see if the settings list has changed from when the file was saved is a good thing. 16.08.36 # dealing with user stupidity/maliciousness is a step beyond that. 16.08.47 # crc is pretty cheap too 16.09.12 Join prof_wolfff [0] (~prof_wolf@195.206.107.25) 16.09.35 # especially as it's already present in the firwmare images. :P 16.10.59 # as far as checking ranges I can just use the macros already there in the settings code 16.11.08 # IMO it needs to be a runtime checksum rather than compile-time, or we should checksum the preprocessed version, as the HAVE_XXX definitions can change (thereby changing the settings table) without the actual file changing 16.12.19 # pretty trivial to implement the actual checksum and verification. UI about what to do is the more complex bit 16.12.29 # it'll just be a runtime checksum only I think 16.13.05 # well, I'll be back if it acts up again. Thanks 16.13.15 # between that and checking enums compared to the settings 16.13.44 # I think we will leave the user config file alone though 16.14.13 # the overide file I can never remember the name 16.15.04 # FIXEDSETTINGSFILE 16.15.23 # the nvram already crc checks its settings 16.16.38 # so no user prompt just strong checking inputs a crc and a fixed settings cfg file that allows freedom 16.17.18 # then you can still break it if you want to but normal users get a better experience 16.18.47 # weyeah 16.20.42 Quit prof_wolfff (Ping timeout: 260 seconds) 16.22.37 # like it's called "fixed" + settingsfile file extension (I believe ".cfg" but am not sure) 16.22.54 Part fenugrec ("Leaving") 16.24.47 # well, g#2361 is what I just pulled from my posterior 16.24.48 # Gerrit review #2361 at http://gerrit.rockbox.org/r/2361 : WIP: Checksum settings table, and detect if it changes. by Solomon Peachy 16.25.11 # it compiles therefore it must be okay. :D 16.27.25 # now it doesn't actually _do_ anything when it detects the checksum has changed. but, eh, have to start somewhere 16.27.51 # (did this as an exercise/refresher in my own edumication; feel free to ignore it) 16.34.15 # lol you are the overachiever 16.48.14 # story of my life.. misguided overachievement 16.48.27 # it's how I fill the endless void in my soul 16.49.16 # but now the rest of the natives are stirring, and I'm on breakfast duty. 17.41.58 Join chrisb [0] (~chrisb@unaffiliated/chrisb) 18.03.18 *** Saving seen data "./dancer.seen" 18.47.45 Join ac_laptop [0] (~ac_laptop@37.166.82.250) 18.55.24 Quit Frans-Willem (Ping timeout: 264 seconds) 19.09.39 Quit krabador (Quit: Leaving) 19.14.12 Join PimpiN8 [0] (~PimpiN8@178.239.173.228) 19.17.35 Join PimpiN8_ [0] (~PimpiN8@178.239.173.228) 19.18.51 Quit PimpiN8 (Ping timeout: 256 seconds) 19.22.24 Quit fs-bluebot_ (Ping timeout: 264 seconds) 19.24.31 Join fs-bluebot [0] (~fs-bluebo@port-92-193-93-3.dynamic.as20676.net) 19.25.02 Join Frans-Willem [0] (~quassel@94-210-82-195.cable.dynamic.v4.ziggo.nl) 19.27.10 Quit fs-bluebot (Remote host closed the connection) 19.29.24 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.29.29 # okay, updated the patch, now it actually works. 19.30.11 # all it does is splash "cfgver changed" on startup. 19.31.33 Join fs-bluebot [0] (~fs-bluebo@port-92-193-93-3.dynamic.as20676.net) 19.43.10 Quit bluebrother (Read error: Connection reset by peer) 19.43.10 Quit fs-bluebot (Read error: Connection reset by peer) 19.43.21 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.43.34 Join fs-bluebot [0] (~fs-bluebo@port-92-193-93-3.dynamic.as20676.net) 20.03.19 *** Saving seen data "./dancer.seen" 20.10.25 Quit ac_laptop (Ping timeout: 256 seconds) 20.30.26 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 20.35.29 Join advcomp2019 [0] (~advcomp20@65-131-163-116.sxct.qwest.net) 20.35.29 Quit advcomp2019 (Changing host) 20.35.29 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 20.59.38 Quit sakax (Quit: Leaving) 21.00.01 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 21.07.41 Quit GeekShadow (Ping timeout: 260 seconds) 21.08.04 Join ac_laptop [0] (~ac_laptop@37.166.42.10) 21.13.41 Quit ac_laptop (Read error: Connection reset by peer) 21.13.56 Quit bertrik (Read error: Connection reset by peer) 21.31.43 Join prof_wolfff [0] (~prof_wolf@195.206.107.25) 21.41.25 Join GeekShadow [0] (~antoine@nzf.turmel.info) 21.41.26 Quit GeekShadow (Changing host) 21.41.26 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) 22.03.21 *** Saving seen data "./dancer.seen" 22.49.05 Quit prof_wolfff (Ping timeout: 256 seconds) 23.04.23 Join prof_wolfff [0] (~prof_wolf@195.206.107.25) 23.18.21 Quit lebellium (Quit: Leaving) 23.19.56 Quit sakax (Quit: Leaving) 23.44.10 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")