00:01:46 | lebellium_z3c | 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 | pamaury | 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 | lebellium_z3c | 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 | fulon | __builtin: just disassembled |
00:07:09 | fulon | it has the same JT (or pi) chip |
00:07:10 | | Quit paulk-collins (Read error: Connection reset by peer) |
00:07:23 | fulon | 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 | fulon | 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 | fulon | :) |
00:42:28 | | Quit ZincAlloy (Quit: Leaving.) |
00:47:00 | | Quit pamaury (Ping timeout: 248 seconds) |
00:47:08 | builtin | have you poked around the firmware already on there? |
00:47:19 | fulon | maybe its just a generic mp3 decoder IC, there should be another one for mcu |
00:47:24 | fulon | I cant dump it |
00:47:29 | fulon | no tool so far accepted it |
00:47:45 | builtin | 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 | fulon | 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 | fulon | hum |
00:49:32 | fulon | 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:00 |
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 | fulon | __builtin: on the street. No manual, no brands, nothing :P |
01:12:16 | fulon | __builtin: https://www.youtube.com/watch?v=t-YiUbu406k |
01:12:19 | fulon | ^this one |
01:15:45 | fulon | 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 | chrisjj | 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 |
02:00:51 | | Join idonob_ [0] (~Owner@S010610c37b922980.vs.shawcable.net) |
02:05:12 | | Quit skapazzo (Quit: leaving) |
02:06:33 | fulon | __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 | fs-bluebot | Build Server message: New build round started. Revision 3190728, 255 builds, 16 clients. |
02:37:09 | __builtin | all green, just watch ;) |
02:47:06 | fs-bluebot | Build Server message: Build round completed after 629 seconds. |
02:47:07 | fs-bluebot | Build Server message: Revision 3190728 result: All green |
02:47:34 | __builtin | \o/ |
03:00 |
03:12:39 | | Quit TheSeven (Ping timeout: 245 seconds) |
03:14:31 | fs-bluebot | Build Server message: New build round started. Revision 1464cb9, 255 builds, 16 clients. |
03:24:09 | fs-bluebot | Build Server message: Build round completed after 579 seconds. |
03:24:10 | fs-bluebot | Build Server message: Revision 1464cb9 result: All green |
03:24:11 | fs-bluebot | Build Server message: New 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 | fs-bluebot | Build Server message: Build round completed after 627 seconds. |
03:34:39 | fs-bluebot | Build Server message: Revision 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:00 |
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 | Bilgus | __builtin: I thought aCos = aTan(sqrt(1-x^2)/x) or is the atan2 function doing the last div? |
04:26:44 | Bilgus | IIRC atan2 only does sign? |
04:27:12 | Bilgus | maybe i should say 'Quadrant' |
04:29:03 | Bilgus | 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 | Bilgus | do some extrapolation for the values in between |
04:34:13 | Bilgus | 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:00 |
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:00 |
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:00 |
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 |
09:00:33 | | Quit Bray90820_ (Ping timeout: 256 seconds) |
09:02:02 | fs-bluebot | Build Server message: New build round started. Revision 6c83739, 255 builds, 16 clients. |
09:13:01 | fs-bluebot | Build Server message: Build round completed after 659 seconds. |
09:13:02 | fs-bluebot | Build Server message: Revision 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 | pixelma | 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 | fs-bluebot | Build Server message: New build round started. Revision bc4c13e, 255 builds, 15 clients. |
09:33:48 | fs-bluebot | Build Server message: Build round completed after 578 seconds. |
09:33:50 | fs-bluebot | Build Server message: Revision 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 |
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:00 |
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:00 |
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:00 |
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:00 |
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 | Yogurt | hey all |
14:12:09 | Yogurt | I've noticed an uptick in activity related to the sony walkman devices |
14:12:25 | Yogurt | is there any word on which ones will probably supported and which ones wont? |
14:13:38 | Yogurt | specifically the E585 |
14:14:25 | pamaury_ | Yogurt: potentially all the ones that run linux. Although the port is currently in progress, the list in this file: |
14:14:25 | pamaury_ | https://git.rockbox.org/?p=rockbox.git;a=blob;f=utils/nwztools/upgtools/upg.c |
14:14:25 | pamaury_ | gives a rough idea. The E580 Series will be supported |
14:14:41 | pamaury_ | (this list is not complete by the way) |
14:15:03 | Yogurt | awesome |
14:15:08 | Yogurt | thanks for the link |
14:16:08 | Yogurt | any word on a schedule or is just a "when it's done" kind of thing? |
14:18:02 | pamaury_ | 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:00 |
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 | pamaury_ | 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:00 |
16:08:35 | pamaury_ | arg, why is attribute packed broken on mingw32 ?? |
16:13:49 | Marex | heh |
16:17:52 | pamaury_ | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 |
16:18:24 | pamaury_ | 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 | funman | pamaury_: you should use mingw-w64 |
16:23:48 | pamaury_ | funman: I am |
16:24:09 | pamaury_ | i686-w64-mingw32, straight out of debian repo |
16:24:44 | funman | ok then you can pester ktietz on #mingw-w64 :) |
16:30:30 | pamaury_ | 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 | fs-bluebot | Gerrit review #1454 at http://gerrit.rockbox.org/r/1454 : Add 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:00 |
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 | chrisjj | 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:00 |
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:00 |
19:17:16 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
19:21:49 | pixelma | 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 | pixelma | 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 | lebellium | 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 | lebellium | 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 | lebellium | who gives git access? |
19:59:06 | gevaerts | Not [Saint] :) |
19:59:44 | [Saint] | ...duh. |
19:59:52 | lebellium | IIRC he doesn't even have access and doesn't want it |
19:59:54 | lebellium | right? |
19:59:58 | [Saint] | correct. |
20:00 |
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 | gevaerts | 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 | gevaerts | 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 | lebellium | [Saint] may review every patch |
20:04:55 | lebellium | 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 | lebellium | 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 | gevaerts | That and people without direct commit access |
20:10:27 | [Saint] | flyspray's still up... |
20:10:31 | [Saint] | (lol) |
20:11:21 | pamaury | 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 | pamaury | [Saint]: I also use as a personal draft ;) |
20:12:57 | gevaerts | [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 | gevaerts | :) |
20:13:36 | [Saint] | At that point, it's like a cross between a local git stash and a bragging list. ;) |
20:13:57 | pamaury | 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 | gevaerts | [Saint]: even in such cases people *can* comment |
20:14:25 | pamaury | and if someone finds it interesting, he/she can comment |
20:14:28 | gevaerts | And such comments are valuable |
20:15:35 | gevaerts | Anyway, I'm not very attached to gerrit, but it *is* the status quo |
20:16:08 | pamaury | 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 | pamaury | 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 | pamaury | I would be mostly fine with a holding period. A build system hook would be very nice indeed |
20:41:28 | pamaury | 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 | Bilgus_ph | 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 | pamaury | bootloaders are always tested before releasing them anyway |
20:47:31 | Bilgus_ph | 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 | pamaury | gerrit provides you more tools than git-gui though, you can track the history of your changes |
20:49:55 | pamaury | 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 | pamaury | not really |
20:51:28 | [Saint] | how so? |
20:51:40 | pamaury | unless you have one branch per version of your patch, you can do it |
20:51:49 | pamaury | 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 | pamaury | 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 | pamaury | I still my branch with the changes |
20:56:08 | pamaury | the latest version |
20:57:39 | | Quit idonob_ (Ping timeout: 248 seconds) |
21:00 |
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 | pamaury | 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 |
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 | jhMikeS | [Saint]: was setting stuff up on a new machine and had to re-register my nicks too |
22:16:10 | bluebrother | pamaury: pong |
22:16:32 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
22:26:15 | pamaury | bluebrother: I'm trying to make my tools work on windows for scsi |
22:26:33 | pamaury | I can do scsi if I give paths like \\.\PhysicalDriveX but this is horrible and it's not obvious |
22:26:44 | pamaury | is there a way to map something like C: to PhysicalDriveX ? |
22:27:01 | bluebrother | good question ... |
22:28:59 | bluebrother | see resolveDevicename in base/utils.cpp in Rockbox Utility sources |
22:29:45 | bluebrother | there is an implementation for something like that |
22:30:54 | pamaury | bluebrother: okay that's what I was trying actually but I have a problem |
22:31:08 | pamaury | CreateFile fails with access denied if I try to open something like "F:" |
22:31:46 | bluebrother | is the application running elevated? |
22:31:58 | pamaury | unless there is some magic involved and F: doesn't work but \\.\C: would ? Yes I'm running an admin terminal |
22:32:04 | pamaury | or is that not enough ? |
22:32:20 | bluebrother | that should be enough |
22:32:30 | pamaury | (I was assuming that run for elevated terminal => run programs elevated) |
22:32:32 | bluebrother | when looking at that code the UNC version does work |
22:32:45 | bluebrother | 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 | pamaury | hum that's weird, indeed \\.\C: does work |
22:34:39 | pamaury | for some reason |
22:34:46 | bluebrother | Windows is weird ;-) |
22:35:25 | bluebrother | 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 | pamaury | yeah... thanks for the tip |
22:35:38 | bluebrother | so it's not really surprising to me that using a UNC path works |
22:35:50 | bluebrother | 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 | pamaury | bluebrother: I just installed Win 10 in a VM for that |
22:38:59 | pamaury | much better ;) |
22:39:36 | bluebrother | hehe. I have a Win7 VM running on Linux on my personal machine for that :) |
22:40:06 | bluebrother | but work ... well, can't decide that. Companies are pretty bound to Windows |
22:41:10 | bluebrother | 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 | bluebrother | anyway, I'm off for today. |
22:48:50 | pamaury | bluebrother: actually, it seems that you can send SCSI pass-through directly to \\.\F: |
22:50:07 | pamaury | 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 | jhMikeS | [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 | pamaury | jhMikeS: tagcache in ram is an often requested feature, for hard drive |
22:59:54 | pamaury | it has been disabled in your commit iirc |
23:00 |
23:00:07 | [Saint] | and from memory there was another...errrr...shit. |
23:00:07 | pamaury | I don't know why, is that an oversight or is there a fundamental reason for that ? |
23:00:15 | jhMikeS | 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 | jhMikeS | the new dircache code just plain wasn't compatible. |
23:01:09 | pamaury | I would TC in ram is high priority because it makes those device unusable apparently |
23:01:12 | jhMikeS | [Saint]: Just now? |
23:01:22 | jhMikeS | when? |
23:01:24 | [Saint] | jhMikeS: no, since. |
23:01:40 | [Saint] | the filesystem rework. |
23:01:46 | pamaury | 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 | jhMikeS | 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 | pamaury | maybe [Saint] remembers the commit in question. I didn't even know we had this feature ;) |
23:02:26 | pamaury | (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 | jhMikeS | [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 | pamaury | jhMikeS: it's something completely different |
23:04:05 | pamaury | I think it's commit af6ceba2a3b857ca03d1db548830e29d478ee788 |
23:04:09 | jhMikeS | [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 | pamaury | or maybe not, no it's another commit |
23:06:45 | pamaury | jhMikeS: commit b30edcd62f2e16525bc9c6fe0b52769ae30b0dc8 I think |
23:06:56 | jhMikeS | 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 | pamaury | I think it's about relative paths in external storage |
23:07:38 | pamaury | that's what the commit says |
23:07:44 | pamaury | 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 | jhMikeS | 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 | chrisjj | [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 | pamaury | [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 | chrisjj | 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 | pamaury | 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 | pamaury | so this code checks if the playlist file in on an external drive and if so, adds /<microSD1> to the paths, something like that |
23:14:24 | pamaury | I might be wrong, the code if that commit is unclear to me... |
23:14:27 | pamaury | *of |
23:14:30 | jhMikeS | [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 | jhMikeS | => /*check if the playlist is on a external card, and correct path if needed */ |
23:15:36 | jhMikeS | 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 | jhMikeS | there were issues because with a component like <ExternalThing1>, it no longer cares about the "ExternalThing" part, just the number |
23:16:53 | Saratoga | All that commit did was make any ambiguous path point to the volume containing the m3u file |
23:17:36 | Saratoga | 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 | Saratoga | 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 | Saratoga | I meant to fix that playlist thing but I'm insanely busy right now |
23:19:51 | jhMikeS | Saratoga: it's actually trying to "fix" things by rewriting the absolute part of the path |
23:20:20 | jhMikeS | *was* |
23:20:32 | [Saint] | The tagcache in RAM stuff is a pretty pressing concern for quite a few people. |
23:20:56 | jhMikeS | now, it's considering only relative paths to be relative to the playlist's location and not altering anything absolute |
23:20:57 | Saratoga | 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 | Saratoga | I'm surprised cashed makes such a difference for building the database |
23:21:37 | Saratoga | 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 | jhMikeS | 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 | Saratoga | Iirc it only changes ambiguous paths like c:\file.mp3 |
23:26:21 | Saratoga | It deals with the fact that windows paths don't translate into rockbox mostly |
23:26:27 | jhMikeS | that would become /file.mp3 |
23:26:38 | jhMikeS | strip drive letter, fix separators |
23:27:19 | jhMikeS | at that point it's absolute, so should find it in the primary storage root |
23:28:40 | Saratoga | 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 | pixelma | 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 | jhMikeS | change the "greedy" parameter to "true" and the path_strip_drive will strip a drive letter plus all sepators |
23:35:31 | jhMikeS | c:\file.mp3 => file.mp3 |
23:35:45 | jhMikeS | c:file.mp3 always become file.mp3 |
23:38:14 | chrisjj | "walking across internal and external storage for relative links in playlists got busted." Coo. Never knew that. Thanks for the alert. |
23:38:19 | jhMikeS | 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 | jhMikeS | If I'm reading it right, the old code leaves the slash after the colon if there is one |
23:43:34 | jhMikeS | and now the fs code just handles all the "." and ".." components |
23:44:18 | chrisjj | __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 | chrisjj | 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 | pixelma | jhMikeS: I believe treating drives as irrelevant was invented for our treating external cards as <microSD1> etc. so that Rockbox searche d |
23:50:04 | pixelma | on both volumes, unless I misunderstand what you're talking about |
23:50:20 | chrisjj | __builtin: OK, so then why is there a complaint that jsMikeS used a priviledge that he has, and presumably has earned? |
23:50:26 | jhMikeS | 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 | pixelma | chrisjj: I thought it is common etiquette to not do this |
23:51:29 | chrisjj | [Saint]: Sad to hear the sanity of some people here is so fragile! :-) |
23:51:52 | chrisjj | 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 | jhMikeS | chrisjj: Like I told saint, I'm a shithead :) |
23:53:42 | pixelma | 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 | pixelma | two thing |
23:53:54 | pixelma | s |
23:54:07 | * | [Saint] hovers over the +m button |
23:57:10 | chrisjj | 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 | jhMikeS | 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 | Saratoga | 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 | jhMikeS | chrisjj: unless we changed the rules when I was away, no one ever considered a direct push an abuse |