--- Log for 05.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 hours and 25 minutes ago 00.01.46 # pamaury: the user still got the message "Device didn't send the expected amount of data " for Kas and "get" with parameter -s nw-wm1 00.02.46 # for kas that's expected, but if it also gets it for get, that may mean that the wm1 is based on something completely different 00.05.13 # <__builtin> fulon: could it be this? http://aitendo2.sakura.ne.jp/aitendo_data/product_img2/product_img/aitendo-kit/mp3/mp3-AU7842.pdf 00.05.34 # <__builtin> if it is, it has "In-system firmware upgrade through U-disk or SD/MMC" 00.06.52 # pamaury: ok, Sony watch you and decided it's time to change the encryption :( if you get and idea and something else to try out, just put the instructions here (I read logs) 00.07.00 # __builtin: just disassembled 00.07.09 # it has the same JT (or pi) chip 00.07.10 Quit paulk-collins (Read error: Connection reset by peer) 00.07.23 # I am trying to read the label 00.12.11 Quit lebellium_z3c (Quit: Bye) 00.17.04 Nick __builtin is now known as builtin (~xray@rockbox/developer/builtin) 00.17.09 Nick builtin is now known as __builtin (~xray@rockbox/developer/builtin) 00.17.55 Nick __builtin is now known as builtin (~xray@rockbox/developer/builtin) 00.18.22 Nick builtin is now known as __builtin (~xray@rockbox/developer/builtin) 00.19.36 Quit pamaury (Ping timeout: 258 seconds) 00.21.29 Join bittin [0] (~luna@unaffiliated/bittin) 00.22.05 Nick __builtin is now known as builtin (~xray@rockbox/developer/builtin) 00.26.32 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 00.34.44 Quit Senji (Ping timeout: 245 seconds) 00.36.10 *** Saving seen data "./dancer.seen" 00.37.06 # builtin: couldnt read the full label and I have no tools around to help me, but its the same LJ or pi symbol and starts with ab1 something 00.37.09 # :) 00.42.28 Quit ZincAlloy (Quit: Leaving.) 00.47.00 Quit pamaury (Ping timeout: 248 seconds) 00.47.08 # have you poked around the firmware already on there? 00.47.19 # maybe its just a generic mp3 decoder IC, there should be another one for mcu 00.47.24 # I cant dump it 00.47.29 # no tool so far accepted it 00.47.45 # I mean like running it and looking around the software interface 00.48.37 Nick builtin is now known as __builtin (~xray@rockbox/developer/builtin) 00.49.15 # yes, it just says "welcome", then shows a crappy interface for music, mp3 and settings. settings is like language, contrast and light 00.49.20 # hum 00.49.32 # let me put some files, maybe it shows something more 00.52.08 Quit ender` (Quit: I spilled Spot Remover on my dog... Now he's gone.) 00.58.39 Quit girafe (Read error: Connection reset by peer) 01.06.26 # <__builtin> is there a way to upgrade firmware anywhere? 01.06.52 # <__builtin> also how did you acquire it? 01.11.24 # __builtin: on the street. No manual, no brands, nothing :P 01.12.16 # __builtin: https://www.youtube.com/watch?v=t-YiUbu406k 01.12.19 # ^this one 01.15.45 # I think I saw a MCU IC around and this AB1244 looks like a mp3 player IC, the same one used on Arduino mp3 shields. Let me check this one... brb 01.18.20 # <__builtin> hmm, it seems like it's pretty popular 01.24.29 Quit TheSeven (Remote host closed the connection) 01.27.34 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 01.28.50 # pamaury: "... which means one needs to update the BL, a daily build is not enough" Is the BL not in the build system then? I see the source in rbutil\mkzenboot\. 01.32.18 Quit treaki__ (Ping timeout: 248 seconds) 01.46.35 Join PurlingNayuki [0] (~Thunderbi@114.255.40.10) 01.50.59 Quit PurlingNayuki (Ping timeout: 245 seconds) 02.00.51 Join idonob_ [0] (~Owner@S010610c37b922980.vs.shawcable.net) 02.05.12 Quit skapazzo (Quit: leaving) 02.06.33 # __builtin: 621b or 6218. Its connected between the sdcard and the other I mentioned early. 8-pins. I will try to check how those aitendo boards were used/programmed. Maybe I get something to drop the firmware or some tip on how this interface firmware ended up there. The battery glue went over the ICs and its pretty difficult to read. 02.20.41 # <__builtin> wow... I just thought of a stupidly simple way to solve a problem 02.21.10 # * __builtin is missing a good acos() function, so acos(x)=atan2(sqrt(1-x^2),x) 02.36.11 *** Saving seen data "./dancer.seen" 02.36.37 # Build Server message: 3New build round started. Revision 3190728, 255 builds, 16 clients. 02.37.09 # <__builtin> all green, just watch ;) 02.47.06 # Build Server message: 3Build round completed after 629 seconds. 02.47.07 # Build Server message: 3Revision 3190728 result: All green 02.47.34 # <__builtin> \o/ 03.12.39 Quit TheSeven (Ping timeout: 245 seconds) 03.14.31 # Build Server message: 3New build round started. Revision 1464cb9, 255 builds, 16 clients. 03.24.09 # Build Server message: 3Build round completed after 579 seconds. 03.24.10 # Build Server message: 3Revision 1464cb9 result: All green 03.24.11 # Build Server message: 3New build round started. Revision dbee727, 255 builds, 14 clients. 03.26.20 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 03.27.05 Join chrisb [0] (~chrisb@pool-71-175-243-155.phlapa.east.verizon.net) 03.30.06 Quit elensil (Ping timeout: 258 seconds) 03.30.57 Part chrisb 03.34.38 # Build Server message: 3Build round completed after 627 seconds. 03.34.39 # Build Server message: 3Revision dbee727 result: 5 errors 0 warnings 03.35.05 Quit aptzero (Quit: Leaving.) 03.37.00 # <__builtin> crap 03.37.47 # <__builtin> what the heck? 03.37.56 # <__builtin> /home/rockbox/firmware/export/eeprom_settings.h:31:1: error: expected ',' or '}' before 'enum' 03.38.01 # <__builtin> I didn't even touch that file 03.39.15 Quit nlogex (Ping timeout: 246 seconds) 03.44.15 # <__builtin> ah well, it's probably an issue with that one build client 03.52.02 Join elensil [0] (~edhelas@2001:1c02:1903:d800:c11f:b244:218f:200c) 04.05.20 Quit n17ikh (*.net *.split) 04.05.20 Quit ranmacha1 (*.net *.split) 04.05.20 Quit rudi_s (*.net *.split) 04.05.20 Quit rasher (*.net *.split) 04.05.20 Quit Horrorcat (*.net *.split) 04.05.20 Quit Staphylo (*.net *.split) 04.05.20 Quit ender| (*.net *.split) 04.05.26 Join rasher [0] (~rasher@rockbox/developer/rasher) 04.05.28 Join ranmachan [0] (~ranma@yumi.uguu.de) 04.05.30 Join rudi_s [0] (~simon@kraftwerk.ruderich.eu) 04.05.36 Join n17ikh [0] (~n17ikh@95.46.199.100) 04.05.36 Join Staphylo [0] (~Staphylo@2a01:4f8:190:126a:d70a:378:c354:a3a3) 04.05.41 Join Horrorcat [0] (~unknown@electron.h.sotecware.net) 04.05.45 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 04.05.47 Quit Horrorcat (Signing in (Horrorcat)) 04.05.47 Join Horrorcat [0] (~unknown@unaffiliated/horrorcat) 04.05.50 Quit n17ikh (Changing host) 04.05.50 Join n17ikh [0] (~n17ikh@unaffiliated/n17ikh) 04.07.35 Quit prof_wolfff (Ping timeout: 256 seconds) 04.20.46 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) 04.23.49 Join chrisb [0] (~chrisb@pool-71-175-243-155.phlapa.east.verizon.net) 04.23.54 # __builtin: I thought aCos = aTan(sqrt(1-x^2)/x) or is the atan2 function doing the last div? 04.26.44 # IIRC atan2 only does sign? 04.27.12 # maybe i should say 'Quadrant' 04.29.03 # what kind of precision are you needing on this function? I think I'd do a LUT if you need to call it often 04.30.17 # do some extrapolation for the values in between 04.34.13 # sorry interpolate lol 04.36.12 *** Saving seen data "./dancer.seen" 04.48.44 Join PurlingNayuki [0] (~Thunderbi@2001:da8:215:4ff:940b:659f:39da:b835) 04.52.48 Quit PurlingNayuki (Ping timeout: 240 seconds) 06.35.28 Quit TheSeven (Ping timeout: 240 seconds) 06.36.14 *** Saving seen data "./dancer.seen" 06.36.36 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 07.13.57 Join nlogex [0] (~filip@CPE30469a4d21ac-CMa84e3f5c8560.cpe.net.fido.ca) 07.29.28 Join parchd [0] (~parchd@unaffiliated/parchd) 07.52.18 Quit alucryd (Remote host closed the connection) 07.54.06 Join alucryd [0] (~quassel@archlinux/developer/alucryd) 08.36.17 *** Saving seen data "./dancer.seen" 08.41.01 Join ender` [0] (krneki@foo.eternallybored.org) 08.50.35 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:e487:274b:f219:a314) 08.57.23 Join PurlingNayuki [0] (~Thunderbi@2001:da8:215:4ff:28dd:f462:53f6:5455) 08.58.15 Quit ZincAlloy (Quit: Leaving.) 09.00.33 Quit Bray90820_ (Ping timeout: 256 seconds) 09.02.02 # Build Server message: 3New build round started. Revision 6c83739, 255 builds, 16 clients. 09.13.01 # Build Server message: 3Build round completed after 659 seconds. 09.13.02 # Build Server message: 3Revision 6c83739 result: 42 errors 0 warnings 09.15.08 Quit PurlingNayuki (Ping timeout: 240 seconds) 09.18.55 Join Bray90820 [0] (~bray90820@172.56.12.156) 09.21.53 # Huh? A commit by jhMikeS and he's not around once more (and for coders in Europe it's still a bit too early) :\ 09.24.10 # Build Server message: 3New build round started. Revision bc4c13e, 255 builds, 15 clients. 09.33.48 # Build Server message: 3Build round completed after 578 seconds. 09.33.50 # Build Server message: 3Revision bc4c13e result: All green 09.38.48 Quit cc___ (Ping timeout: 240 seconds) 09.43.12 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.47.49 Quit idonob_ (Read error: Connection reset by peer) 09.48.05 Join idonob_ [0] (~Owner@S010610c37b922980.vs.shawcable.net) 10.00.39 Join Guest93 [0] (~textual@145.132.155.235) 10.04.17 Join Link8 [0] (~me@145.132.155.235) 10.11.50 Quit pamaury (Ping timeout: 258 seconds) 10.13.25 Quit Link8 (Remote host closed the connection) 10.15.23 Join Bray90820_ [0] (~bray90820@173-25-204-30.client.mchsi.com) 10.18.12 Quit Bray90820 (Ping timeout: 248 seconds) 10.19.14 Quit krnlyng (Ping timeout: 248 seconds) 10.22.19 Quit Guest93 (Quit: My MacBook has gone to sleep. ZZZzzz…) 10.32.41 Join krnlyng [0] (~liar@77.116.51.233.wireless.dyn.drei.com) 10.36.19 *** Saving seen data "./dancer.seen" 11.25.34 Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) 11.25.45 Quit pamaury (Changing host) 11.25.45 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.47.43 Quit mikroflops (Ping timeout: 256 seconds) 11.49.32 Join mikroflops [0] (~yogurt@178.174.137.46) 11.55.38 Quit mikroflops (Ping timeout: 272 seconds) 11.56.57 Join mikroflops [0] (~yogurt@178.174.137.46) 11.57.52 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 11.59.15 Join skapazzo [0] (~skapazzo@151.9.205.1) 12.04.30 Quit mikroflops (Ping timeout: 272 seconds) 12.07.08 Join mikroflops [0] (~yogurt@178.174.137.46) 12.16.04 Quit mikroflops (Ping timeout: 248 seconds) 12.35.50 Join mikroflops [0] (~yogurt@178.174.137.46) 12.36.22 *** Saving seen data "./dancer.seen" 12.40.08 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:21c:b3ff:feb5:d1e2) 12.41.26 Quit mikroflops (Ping timeout: 255 seconds) 12.43.58 Quit diox (Ping timeout: 246 seconds) 12.52.39 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 12.55.43 Quit Jinx (*.net *.split) 12.55.44 Quit ruskie (*.net *.split) 12.55.44 Quit gluytium (*.net *.split) 12.55.44 Quit Riku (*.net *.split) 12.55.44 Quit beveradb (*.net *.split) 12.55.44 Quit anonus (*.net *.split) 12.55.44 Quit vifino (*.net *.split) 12.55.44 Quit ved (*.net *.split) 12.55.52 Join gluytium [0] (U2FsdGVkX1@ma.sdf.org) 12.55.53 Join ved [0] (ved@ddsbox.tk) 12.56.10 Join anonus [0] (~anonymous@citadel.niflheim.info) 12.56.22 Join beveradb [0] (~beveradb@irc.beveridge.uk) 12.56.40 Join Riku [0] (~riku@hatsune.thisis.moe) 12.57.16 Join vifino [0] (~vifino@tty.sh) 12.58.01 Quit elensil (Remote host closed the connection) 12.58.12 Quit chrisb (Ping timeout: 248 seconds) 13.13.26 Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) 13.15.47 Join Moarc [0] (~chujko@a105.net128.okay.pl) 13.16.08 Quit Moarc (Client Quit) 13.16.24 Join Moarc [0] (~chujko@a105.net128.okay.pl) 13.31.28 Quit paulk-blaze (Quit: Leaving) 13.55.08 Join elensil [0] (~edhelas@2001:1c02:1903:d800:b5c5:7f95:63dd:652) 13.59.03 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 14.03.53 Join mikroflops [0] (~yogurt@178.174.137.46) 14.11.05 Join Yogurt [0] (~Yogurt@ip-145-116-168-43.wlan-int.ru.nl) 14.11.12 # hey all 14.12.09 # I've noticed an uptick in activity related to the sony walkman devices 14.12.25 # is there any word on which ones will probably supported and which ones wont? 14.13.38 # specifically the E585 14.14.25 # Yogurt: potentially all the ones that run linux. Although the port is currently in progress, the list in this file: 14.14.25 # https://git.rockbox.org/?p=rockbox.git;a=blob;f=utils/nwztools/upgtools/upg.c 14.14.25 # gives a rough idea. The E580 Series will be supported 14.14.41 # (this list is not complete by the way) 14.15.03 # awesome 14.15.08 # thanks for the link 14.16.08 # any word on a schedule or is just a "when it's done" kind of thing? 14.18.02 # currently I have something running but playback doesn't work 14.27.20 # * Yogurt orders a E585 14.29.00 Join aptzero [0] (~Adium@96-95-20-86-static.hfc.comcastbusiness.net) 14.31.20 Join diox [0] (~u@c80-216-192-86.bredband.comhem.se) 14.36.24 *** Saving seen data "./dancer.seen" 15.05.35 Quit paulk-collins (Quit: Leaving) 15.12.43 Quit diox (Ping timeout: 246 seconds) 15.13.51 Join diox [0] (~u@c80-216-192-86.bredband.comhem.se) 15.15.05 Quit TD-Linux (Ping timeout: 260 seconds) 15.15.15 Join TD--Linux [0] (~Thomas@2604:a880:1:20::173:1001) 15.29.33 Quit pamaury_ (Remote host closed the connection) 15.33.05 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 15.35.31 Join chrisb [0] (~chrisb@pool-71-175-243-155.phlapa.east.verizon.net) 15.41.32 Quit pamaury_ (Remote host closed the connection) 15.43.30 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 15.43.56 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 15.44.16 # pixelma: agreed, I don't like this behaviour of pushing stuff without being around or discussing it, even if it's in an area of the code I don't really know 15.57.04 Quit chrisb (Read error: Connection reset by peer) 16.08.35 # arg, why is attribute packed broken on mingw32 ?? 16.13.49 # heh 16.17.52 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 16.18.24 # so basically, mingw has managed to try to be compatible with msc but failed and is now incompatible with both msc and gcc, great 16.18.35 # * pamaury_ #pragma pack 16.23.20 # pamaury_: you should use mingw-w64 16.23.48 # funman: I am 16.24.09 # i686-w64-mingw32, straight out of debian repo 16.24.44 # ok then you can pester ktietz on #mingw-w64 :) 16.30.30 # bluebrother: my multiplatform scsi library now supports linux and windows: g#1454 \o/ (I cross compiled using mingw, haven't tried with msvc) 16.30.32 # 3Gerrit review #1454 at http://gerrit.rockbox.org/r/1454 : 3Add multiplatform library for raw SCSI commands by Amaury Pouly 16.36.27 *** Saving seen data "./dancer.seen" 16.42.02 Quit pamaury (Remote host closed the connection) 16.46.38 Quit pamaury_ (Ping timeout: 258 seconds) 16.47.09 Join Senji [0] (~Senji@85.187.103.250) 16.51.41 Join cohokiller673 [0] (cohokiller@c-24-22-103-176.hsd1.wa.comcast.net) 16.57.43 Quit skapazzo (Quit: Lost terminal) 17.04.31 Join skapazzo [0] (~skapazzo@151.9.205.1) 17.06.41 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 17.09.36 Quit diox (Ping timeout: 246 seconds) 17.10.36 Join diox [0] (~u@c80-216-192-86.bredband.comhem.se) 17.15.46 Quit paulk-blaze (Quit: Leaving) 17.26.02 # pixelma: "Huh? A commit by jhMikeS and he's not around once more" What does 'not around once more' mean? He's around generally, e.g. http://forums.rockbox.org/index.php/topic,51605.msg238636.html#msg238636 17.35.44 Quit Yogurt (Ping timeout: 255 seconds) 17.43.29 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 17.46.08 Join Yogurt [0] (~Yogurt@ip-213-124-168-108.ip.prioritytelecom.net) 18.02.18 Quit Yogurt (Quit: Lost terminal) 18.10.45 Quit elensil (Remote host closed the connection) 18.17.09 # <[Saint]> chrisjj: she means, as usual, not participating in basically anything outside the (very) occasional forum post. 18.17.57 # <[Saint]> at this point he's basically notorious for dropping hot rocks on people with no warning and then going awol for ~6 months at a time. 18.36.29 *** Saving seen data "./dancer.seen" 18.40.19 Nick TD--Linux is now known as TD-Linux (~Thomas@2604:a880:1:20::173:1001) 18.40.19 Quit TD-Linux (Changing host) 18.40.19 Join TD-Linux [0] (~Thomas@about/essy/indecisive/TD-Linux) 18.54.52 Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) 19.17.16 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.21.49 # if I say so in IRC, I meant that he wasn't around in IRC at this time... (a) it would have been a chance to talk about some open questions after his file system rework - though only if more of the other core developers would have been around, which I guess was not the case. And (b) I'd like to have a talk about his style of combining things in this specific commit, fixing one thing - ok, introducing a different fading algorithm should have been a 19.21.49 # seperate commit IMHO. If there are any new bugs introduced by it we are again forced to chose between reverting all or fixing another part of the code he has the biggest knowledge of 19.39.20 Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) 19.48.15 Join soap_ [0] (~soap@rockbox/staff/soap) 19.50.50 # pixelma: so it looks like the solution is to PM him on the forum, asking him to come here to discuss and make things clear once for all :) 19.50.59 Join LiberalSquash [0] (~LiberalSq@kol-kvintus.cust.fsknet.dk) 19.51.04 Part LiberalSquash 19.51.35 Quit soap (Ping timeout: 268 seconds) 19.54.49 # <[Saint]> pulling git access would do it. 19.54.59 # <[Saint]> force him through gerrit. 19.55.30 # that's more efficient but not very nice 19.57.11 # <[Saint]> well, I tend to feel more like he should know better, can't /not/ know how people feel about the last time this happened, and no one should need to go running after him. 19.57.21 # <[Saint]> but I'm also not a very nice person, so... 19.58.59 # who gives git access? 19.59.06 # Not [Saint] :) 19.59.44 # <[Saint]> ...duh. 19.59.52 # IIRC he doesn't even have access and doesn't want it 19.59.54 # right? 19.59.58 # <[Saint]> correct. 20.00.15 # <[Saint]> If I had my way, virtually no one would. 20.00.39 # <[Saint]> I still tend to think everything should go via gerrit. 20.00.57 # <[Saint]> then disputes like this wouldn;t happen. 20.01.23 # At this point, nothing else would happen either 20.03.05 # <[Saint]> just like the switch from svn to git, if people want to leave over trivial things like that then...so be it. 20.03.09 # <[Saint]> there's no point in having the review service if people still think their shit is super special and doesn't need it. 20.03.29 # <[Saint]> quick little fixes or reverts, yeah - I can see that. 20.03.42 # <[Saint]> adding any form of feature, or removing any? any major adaption? 20.03.44 # <[Saint]> ...gerrit. 20.03.52 # <[Saint]> it's not rocket science. 20.04.08 # Where it will stay for three months and then get either abandonned or committed anyway without review 20.04.33 # <[Saint]> then I say again there's no point in having it. 20.04.51 # [Saint] may review every patch 20.04.55 # everbody's happy then :D 20.07.23 # <[Saint]> I think the problem at this point is the lack of variety in expertise. 20.09.24 # I'm not sure people push patchs onto gerrit to get reviewed. It looks like more a personal draft where you can update your work dozens of times until it's good enough and thus keep git clean enough. 20.09.59 # That and people without direct commit access 20.10.27 # <[Saint]> flyspray's still up... 20.10.31 # <[Saint]> (lol) 20.11.21 # I often use to get comments, usually from wodz 20.11.25 # <[Saint]> lebellium: I can see you're point but I'm not positive people do it for that reason if not for review, given that git itself serves that purpose. 20.11.47 # <[Saint]> there's no need to use gerrit as a personal stash when git does this already and is the guts of it. 20.12.35 # [Saint]: I also use as a personal draft ;) 20.12.57 # [Saint]: there is value in having a public backup 20.13.18 # <[Saint]> but...but...but! 20.13.18 # * [Saint] throws his toys. 20.13.25 # :) 20.13.36 # <[Saint]> At that point, it's like a cross between a local git stash and a bragging list. ;) 20.13.57 # also it's sometimes nice to put it there and later scroll through it to review it yourself, you just need a browser for that 20.14.04 # <[Saint]> "look what I can do - I don't want your input, just...look at it!" 20.14.10 # <[Saint]> "BEHOLD MY GLORY" 20.14.18 # [Saint]: even in such cases people *can* comment 20.14.25 # and if someone finds it interesting, he/she can comment 20.14.28 # And such comments are valuable 20.15.35 # Anyway, I'm not very attached to gerrit, but it *is* the status quo 20.16.08 # I quite like gerrit, but any other tool would do, just a tool 20.17.12 # <[Saint]> I like gerrit too...but, it's a bit of an echo chamber. 20.17.40 # <[Saint]> as I stated I would prefer everyone use it, even if we just enforced at least a 48h holding period. 20.18.11 # <[Saint]> didn't see it or review in that period? - fuck you, too late. your problem. 20.18.38 # <[Saint]> but people conflate me not reviewing things that aren't in my area with me not being interesting in things, and then people forget you exist and forget to tag you in on things...and...well, here we are. 20.20.08 # <[Saint]> I have no business reviewing everything, no one does - but we have it now where the people who are working in their area are often the only person with skill sets of deep knowledge of that area. 20.20.30 # <[Saint]> So...what, they review themselves? There's not enough skilled brains to go around anymore. 20.21.49 Quit girafe (Ping timeout: 245 seconds) 20.23.30 Quit diox (Ping timeout: 246 seconds) 20.24.34 Join diox [0] (~u@c80-216-192-86.bredband.comhem.se) 20.24.49 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 20.27.14 Quit parchd (Ping timeout: 245 seconds) 20.36.32 *** Saving seen data "./dancer.seen" 20.36.51 # this discussion is kinda of pointless anyway, even if we wanted to review everything we couldn't. I can only review stuff in firmware/ and bootloaders/ mostly. The problem is apps / 20.39.46 # <[Saint]> We did actually talk about a holding period as suggested above initially. 20.39.57 # <[Saint]> it was one of the many things that was supposed to happen with gerrit. 20.40.11 # <[Saint]> the other msot notable one was build system hooks. 20.40.28 # I would be mostly fine with a holding period. A build system hook would be very nice indeed 20.41.28 # Some build checking in utils/ would also be useful sometimes but hey 20.43.23 Join Bilgus_ph [0] (~Bilgus_ph@108.120.229.147) 20.43.58 # <[Saint]> proper unit testing would be nontrivial. 20.46.03 # Luckily there aren't a whole lot of bootloader updates. Ntm there aren't a whole lot of people qualified to do boot loaders. At least apps won't brick someones player. 20.47.24 # bootloaders are always tested before releasing them anyway 20.47.31 # Not that i have much experience with gerrit but my like 40 commits on the one patch it is nice to be able to see how the code evolved and being able to edit in browser is a plus 20.48.30 Quit Bilgus_ph (Remote host closed the connection) 20.48.46 # <[Saint]> something something, git-gui 20.49.36 # gerrit provides you more tools than git-gui though, you can track the history of your changes 20.49.55 # like the newer git-series 20.51.09 # <[Saint]> well, proper local branching solves that. 20.51.21 # <[Saint]> I always get the feeling most people are using git halfassedly. 20.51.22 Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) 20.51.23 # not really 20.51.28 # <[Saint]> how so? 20.51.40 # unless you have one branch per version of your patch, you can do it 20.51.49 # and that gets messy super quickly 20.52.25 # * pamaury points to http://events.linuxfoundation.org/sites/events/files/slides/git-series.pdf 20.53.47 # <[Saint]> I branch for each change, and then rebranch and tag for each major direction change. 20.54.02 # <[Saint]> it gets messy sometimes but it's a usable flow. 20.54.35 # Agreed, I'm just saying that if a tool can do it for you, why not use it ? 20.54.59 # <[Saint]> said tool may not be there at any given point. 20.55.04 # <[Saint]> your local repo will be. 20.55.48 # <[Saint]> if gerrit goes down you're left twiddling your thumbs. 20.56.03 # I still my branch with the changes 20.56.08 # the latest version 20.57.39 Quit idonob_ (Ping timeout: 248 seconds) 21.05.08 Quit mutnai (Quit: Page closed) 21.29.35 Join jhMikeS [0] (~jhMikeS@d192-24-173-177.try.wideopenwest.com) 21.36.49 Part jhMikeS 21.37.00 Join parchd [0] (~parchd@unaffiliated/parchd) 21.37.05 Join _jhMikeS_ [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 21.42.36 # bluebrother: ping 21.48.16 Quit _jhMikeS_ (Quit: Confucius say: The short dandelion survive the lawnmower) 21.58.36 Join jhMikeS [0] (~jhMikeS@d192-24-173-177.try.wideopenwest.com) 21.58.44 Part jhMikeS 22.00.32 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 22.00.40 Quit jhMikeS (Client Quit) 22.01.04 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 22.03.45 Quit michaelni (Ping timeout: 248 seconds) 22.08.46 # * jhMikeS sees in the logs he was rustling some jimmies 22.10.00 # <[Saint]> huh - so you /do/ read logs... 22.10.07 # <[Saint]> good to know. 22.14.14 Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) 22.15.13 Join idonob_ [0] (~Owner@199.119.235.226) 22.16.08 # [Saint]: was setting stuff up on a new machine and had to re-register my nicks too 22.16.10 # pamaury: pong 22.16.32 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 22.26.15 # bluebrother: I'm trying to make my tools work on windows for scsi 22.26.33 # I can do scsi if I give paths like \\.\PhysicalDriveX but this is horrible and it's not obvious 22.26.44 # is there a way to map something like C: to PhysicalDriveX ? 22.27.01 # good question ... 22.28.59 # see resolveDevicename in base/utils.cpp in Rockbox Utility sources 22.29.45 # there is an implementation for something like that 22.30.54 # bluebrother: okay that's what I was trying actually but I have a problem 22.31.08 # CreateFile fails with access denied if I try to open something like "F:" 22.31.46 # is the application running elevated? 22.31.58 # unless there is some magic involved and F: doesn't work but \\.\C: would ? Yes I'm running an admin terminal 22.32.04 # or is that not enough ? 22.32.20 # that should be enough 22.32.30 # (I was assuming that run for elevated terminal => run programs elevated) 22.32.32 # when looking at that code the UNC version does work 22.32.45 # so you really might need to use UNC paths here 22.34.11 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 22.34.37 # hum that's weird, indeed \\.\C: does work 22.34.39 # for some reason 22.34.46 # Windows is weird ;-) 22.35.25 # actually (from my understanding) is that UNC is kinda "extended" and thus supports more things while the "old" drive letters are kinda DOS compatibility 22.35.29 # yeah... thanks for the tip 22.35.38 # so it's not really surprising to me that using a UNC path works 22.35.50 # though that's not obvious :) 22.36.33 *** Saving seen data "./dancer.seen" 22.37.48 # * pamaury hasn't use Windows in a long time 22.38.20 # * bluebrother develops on Linux inside a VM running on Windows at work these days 22.38.29 Quit idonob_ (Ping timeout: 245 seconds) 22.38.46 # bluebrother: I just installed Win 10 in a VM for that 22.38.59 # much better ;) 22.39.36 # hehe. I have a Win7 VM running on Linux on my personal machine for that :) 22.40.06 # but work ... well, can't decide that. Companies are pretty bound to Windows 22.41.10 # though I don't mind using Windows as platform to run things on these days. Win7 just works. And the MS dev tools are actually quite good 22.44.39 # anyway, I'm off for today. 22.48.50 # bluebrother: actually, it seems that you can send SCSI pass-through directly to \\.\F: 22.50.07 # not sure if that's specific to Win10 or not 22.53.10 Quit aptzero (Quit: Leaving.) 22.56.05 # <[Saint]> jhMikeS: yeah - to be honest, I don't really feel too strongly either way about the recent commits, other than sharing a view that it would be nice if there was some separation. 22.56.55 # <[Saint]> jhMikeS: I think the major issue was that it brings back memories of the filesystem rework, which is still classified as WIP, which no one understands and wasn't left in a state of parity. 22.59.17 # [Saint]: Yes, I'm a shithead. There's getting it back in the sim and the dircache pointer scheme that needs to get finished. 22.59.46 # jhMikeS: tagcache in ram is an often requested feature, for hard drive 22.59.54 # it has been disabled in your commit iirc 23.00.07 # <[Saint]> and from memory there was another...errrr...shit. 23.00.07 # I don't know why, is that an oversight or is there a fundamental reason for that ? 23.00.15 # yep. it wasn't supposed to be this long. think that has highest priority? 23.00.40 # <[Saint]> oh, walking across internal and external storage for relative links in playlists got busted. 23.00.52 # the new dircache code just plain wasn't compatible. 23.01.09 # I would TC in ram is high priority because it makes those device unusable apparently 23.01.12 # [Saint]: Just now? 23.01.22 # when? 23.01.24 # <[Saint]> jhMikeS: no, since. 23.01.40 # <[Saint]> the filesystem rework. 23.01.46 # walking accross internal/extenal storage for relative links should be easy. Basically someone added special code for it and you did not keep it in your rework 23.01.54 # and by relative links you mean? 23.02.09 # <[Saint]> jhMikeS: and, no - don't say that, unless it was humorous intent. 23.02.11 # maybe [Saint] remembers the commit in question. I didn't even know we had this feature ;) 23.02.26 # (and was confused by it) 23.02.45 # <[Saint]> I don't feel any way about you personally. 23.03.21 # <[Saint]> major hit and run commits however... 23.03.23 # [Saint]: don't say what? there's more relative path support in the FS now. things like /a/../b/./c 23.03.31 # <[Saint]> that you're a shithead. 23.04.00 # jhMikeS: it's something completely different 23.04.05 # I think it's commit af6ceba2a3b857ca03d1db548830e29d478ee788 23.04.09 # [Saint]: am too a shithead 23.04.25 # <[Saint]> well, /I/ don't think so... ;) 23.04.29 # <__builtin> jethead, you mean? :P 23.05.27 # or maybe not, no it's another commit 23.06.45 # jhMikeS: commit b30edcd62f2e16525bc9c6fe0b52769ae30b0dc8 I think 23.06.56 # pamaury: maybe I'll look at what that was intended to do. I can create playlists with relative paths and they work. I might have intentionally changed something to be more standardized as well. will look. 23.07.32 # I think it's about relative paths in external storage 23.07.38 # that's what the commit says 23.07.44 # it has some explanation 23.07.48 Join rela_ [0] (~x@p200300764D5CC800A0B011247A05BFD0.dip0.t-ipconnect.de) 23.08.15 # <[Saint]> there was some smarts that tried to guess which volume the playlist was aiming for. 23.08.54 # <[Saint]> it left it open to the playback engine to decide if the playlist was pointing at internal or external storage based on some deterministic magic. 23.09.38 # playback engine doesn't guess anything, it's just does what's it's told by the playlist 23.10.17 # <[Saint]> right, which one supposes is the problem. 23.10.23 # <[Saint]> apparently that's a regression. 23.10.50 # <[Saint]> s/apparently// 23.10.54 # [Saint]: "she means, as usual, not participating in basically anything outside the (very) occasional forum post." Thanks. She's wrong. He also participated by submitting the bug fix patch of which she's complaining. 23.11.15 Quit rela (Ping timeout: 260 seconds) 23.11.43 # [Saint]: tell me if I'm wrong, doesn't that happen when *saving* playlists ? 23.11.54 # * [Saint] wonders if chrisjj has any input that isn't just being deliberately contrarian to literally everything 23.12.13 # <__builtin> chrisjj: does it really matter? 23.12.50 # pixelma: "I meant that he wasn't around in IRC at this time..." OK, thanks for the explanation. I was unaware anyone thinks that a fix committer should be around on this IRC. 23.13.29 # jhMikeS: or maybe the issue is the following: if the playlist has non-relative paths, like /bla/music.mp3 BUT the playlist and files are on external disk then /bla/music.mp3 won't work 23.14.00 # so this code checks if the playlist file in on an external drive and if so, adds / to the paths, something like that 23.14.24 # I might be wrong, the code if that commit is unclear to me... 23.14.27 # *of 23.14.30 # [Saint]: possible it's the guessing based upon trying to find a volume string in the path. 23.14.59 Quit nlogex (Read error: No route to host) 23.15.01 # <[Saint]> I believe so. 23.15.25 # => /*check if the playlist is on a external card, and correct path if needed */ 23.15.36 # yes, I fucked with that. 23.15.43 Join Rockbox [0] (ac66091a@gateway/web/freenode/ip.172.102.9.26) 23.15.43 Quit Rockbox (Client Quit) 23.15.48 # <[Saint]> Yeah, that's the one. 23.16.08 Join Saratoga [0] (ac66091a@gateway/web/freenode/ip.172.102.9.26) 23.16.42 # there were issues because with a component like , it no longer cares about the "ExternalThing" part, just the number 23.16.53 # All that commit did was make any ambiguous path point to the volume containing the m3u file 23.17.36 # Without it default is the first volume, which tends to be wrong if the m3u is on external storage 23.17.45 # <[Saint]> Saratoga: ...how the fuck do you do that? 23.17.47 # <[Saint]> That's sure as shit not coincidental. 23.18.03 # Bored in an airport and checked the logs 23.18.18 # <[Saint]> You just appear every time. It's weird as shit. prof_wolfff does it too. 23.18.38 # <[Saint]> Wow, so it /was/ a coincidence. Man. You've really good timing lol. 23.19.18 # I meant to fix that playlist thing but I'm insanely busy right now 23.19.51 # Saratoga: it's actually trying to "fix" things by rewriting the absolute part of the path 23.20.20 # *was* 23.20.32 # <[Saint]> The tagcache in RAM stuff is a pretty pressing concern for quite a few people. 23.20.56 # now, it's considering only relative paths to be relative to the playlist's location and not altering anything absolute 23.20.57 # Yeah, but the system always rewrites relative paths, so might as well make a good guess when it happens 23.20.59 # <__builtin> Bilgus: atan2 handles it I believe (re. acos()) 23.21.02 # <[Saint]> I've had people drop using the database entirely because of performance loss, or use 3~4 year old builds to regain the functionality. 23.21.31 # * [Saint] probably shouldn't have supplied those binaries in any good conscience. 23.21.32 # I'm surprised cashed makes such a difference for building the database 23.21.37 # Cache 23.21.59 # <[Saint]> it's actually using it as well that is problematic. 23.22.14 # <[Saint]> for HDD devices with very large databases it is basically unusable. 23.22.21 # <[Saint]> unbearably slow. 23.24.36 # Saratoga: if the paths are absolute to something on primary storage, the playlist on external storage shouldn't matter 23.25.29 Quit paulk-collins (Remote host closed the connection) 23.25.33 # * pamaury thinks this "feature" is completely natural because no dev can explain how it works 23.25.45 # Iirc it only changes ambiguous paths like c:\file.mp3 23.26.21 # It deals with the fact that windows paths don't translate into rockbox mostly 23.26.27 # that would become /file.mp3 23.26.38 # strip drive letter, fix separators 23.27.19 # at that point it's absolute, so should find it in the primary storage root 23.28.40 # It just changed the mapping from ambiguous to unambiguous paths, so mostly windows drive letters 23.33.18 Quit Saratoga (Ping timeout: 260 seconds) 23.34.59 # chrisjj: I complain about the patch but not the bug fix (please read closely and you don't have to quote me completely). As I said combining it with another change is what I don't like 23.35.09 # change the "greedy" parameter to "true" and the path_strip_drive will strip a drive letter plus all sepators 23.35.31 # c:\file.mp3 => file.mp3 23.35.45 # c:file.mp3 always become file.mp3 23.38.14 # "walking across internal and external storage for relative links in playlists got busted." Coo. Never knew that. Thanks for the alert. 23.38.19 # is that what we want? just treat drives as irrelevant? 23.39.02 Quit pamaury (Ping timeout: 246 seconds) 23.40.22 # <[Saint]> chrisjj: just a heads up, because we're all talking about it anyway, so you might as well know - your quoting style is really driving people insane. 23.40.32 # <[Saint]> Quite a few people resorted to just muting you outright. 23.42.32 # If I'm reading it right, the old code leaves the slash after the colon if there is one 23.43.34 # and now the fs code just handles all the "." and ".." components 23.44.18 # __builti: "does it really matter?" Better to ask the complainant, I think. 23.46.28 # <__builtin> it's really a waste of all of our time to nitpick on such a minor error 23.46.42 # pixelma: "combining it with another change is what I don't like". I thought Gerrit allowed such objections to be registered before such changes took effect. Am I wrong? 23.47.22 # <__builtin> chrisjj: devs can do a direct push or +2 their own patch 23.49.34 # jhMikeS: I believe treating drives as irrelevant was invented for our treating external cards as etc. so that Rockbox searche d 23.50.04 # on both volumes, unless I misunderstand what you're talking about 23.50.20 # __builtin: OK, so then why is there a complaint that jsMikeS used a priviledge that he has, and presumably has earned? 23.50.26 # pixelma: the old code didn't though. it's still doing the same thing, just replaced with a function call instead of parsing in the playlist code 23.51.22 # chrisjj: I thought it is common etiquette to not do this 23.51.29 # [Saint]: Sad to hear the sanity of some people here is so fragile! :-) 23.51.52 # pixelma: "I thought it is common etiquette to not do this" So why did you think Gerrit permits it? 23.51.54 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 23.51.59 # chrisjj: Like I told saint, I'm a shithead :) 23.53.42 # chrisjj: because gerrit can not understand the code to know if the change affects to things at once? And it's not what gerrit is for 23.53.53 # two thing 23.53.54 # s 23.54.07 # * [Saint] hovers over the +m button 23.57.10 # pixelma: Neither addresses the question "So why did you think Gerrit permits it?" And your "it's not what gerrit is for" sounds like you are suggesting direct push in an abuse. 23.57.15 Join Saratoga [0] (ac3a6e80@gateway/web/freenode/ip.172.58.110.128) 23.57.31 # chrisjj: experience says: 1) upload patch, waiting for test, a couple people test, push, some problems are reported anyway 2) thorougly check everything on all your devices, jam it into repository so everyone tests it whether they like it or not, problems get reported 2) tends to work things out a bit more effectively, and if you've tested enough yourself, the problems tend not to be insurmountable 23.58.12 # JhMikes: I don't have much preference, I originally committed that just because I was tired of explaining how m3u paths work 23.58.57 # chrisjj: unless we changed the rules when I was away, no one ever considered a direct push an abuse