--- Log for 15.08.116 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 10 days and 8 hours ago 00.00.07 # in oscilloscope 00.00.30 # when you launch it and the bar will went to max right and goes away from the screen, the whole e384 freezes 00.00.34 # i dont know about other devices 00.00.40 # after menuconfig i unset then export 00.01.29 # robertd: I am not sure I understand what you mean 00.01.43 # anyway I found the problem 00.01.47 # I needed gcc-multilib 00.02.46 # pamaury just before running ./ct-ng build 00.03.05 # you misunderstand, my problem is when running ct-ng build 00.03.42 # haha, this time it was successful, ct-ng managed to build the kernel headers :) 00.04.08 # my mistake, i am at a much early stage 00.05.11 # hum this is odd, now stage 2 gcc fails, because it needs kernel headers, but I have them !! 00.05.47 # <[Saint]> saratoga: yeah - that's a messy one, and the historical answer appears to be yes, but... 00.06.11 # <[Saint]> It is really unclear how far one should go there with credits and contributors. 00.06.24 # i thought contributors means svn/git access? 00.06.37 # <[Saint]> Like, if it's just a third party submission, for instance - do we follow the chain of attribution? Give attribution to the original author? 00.08.10 # ahhh, apparently the glic version I chose is too recent, it does like the 2.6.23 kernel 00.08.15 # Build Server message: 3Build round completed after 600 seconds. 00.08.16 # Build Server message: 3Revision 9868da4 result: All green 00.10.03 # glibc 2.19 is latest one to support kernels before 2.6.32 00.11.15 # <[Saint]> It hasn't really happened to often, but if Johnny submits something that he cloned verbatim from Timmy, which Timmy cloned verbatim from Tommy, who did so from Billy - does Billy get sole attribution? 00.11.19 # <[Saint]> *too 00.11.27 Join __builtin_testin [0] (~franklin@cpe-75-177-76-62.triad.res.rr.com) 00.12.08 # I am not sure we usually give credits for translation 00.12.09 # pamaury in the source code is 2.7 glibc 00.12.22 # robertd: I know but ct-ng does not support glibc 2.7 00.12.43 # my plan is to build another glibc statically so that it does not interfere with the system one 00.12.58 Quit __builtin_testin (Client Quit) 00.13.01 # <[Saint]> pamaury: it certainly seems to be the case that we credit all contributors. 00.13.11 # <[Saint]> I would hope we hadn't missed any but it is certainly possible. 00.13.19 Join __builtin_testin [0] (~franklin@cpe-75-177-76-62.triad.res.rr.com) 00.13.47 # <[Saint]> Only case I can think of offhand where we didn't do so directly was the weird real name dance with with the one individual I won't call attention to. 00.15.36 # [Saint]: yeah maybe you are right, that makes sense, my statement was most probably inaccurate 00.16.17 Quit __builtin_testin (Client Quit) 00.21.38 Join __builtin_testin [0] (~franklin@cpe-75-177-76-62.triad.res.rr.com) 00.23.04 # can anyone here read Chinese and double check that this translation is ok? I would like to commit 00.23.05 # http://www.rockbox.org/tracker/task/13071?getfile=25054 00.23.31 # robertd: here are my notes and config so far: https://gist.github.com/pamaury/a517610e0c53a64dd3a8de06220c9c0c and https://gist.github.com/pamaury/57ea56b8251d157291baa065eb6e87b3 00.23.31 # it's not finished and I don't know if it builds everything yet 00.23.34 # <[Saint]> The eternal struggle with translations. 00.24.02 # <[Saint]> Deep down, I like to think people smuggled in dick jokes and other people just roll with it because the find it hilarious. 00.24.03 # robertd: so far, I've made it to cc_core_pass_2 00.24.47 # pamaury thanks just in one day ! 00.28.28 # <[Saint]> If this is your first, or an infrequent, encounter with pamaury - then prepared to be continually amazed. 00.28.28 # <[Saint]> He's ever so modest, and likes to downplay the fact, but the man is ab absolute savant at pulling things apart. 00.28.33 # <[Saint]> *an 00.28.46 # <[Saint]> He's like the Rain Man of reverse engineering. 00.30.18 # well I still feel humiliated by the yp-r0 toolchain adn amazed that TheSeven managed to build it 00.31.10 # ha 00.31.24 # it is really amazing. I have been trying to build the cross compiler to use with the nwz for months 00.31.52 # if you get it built, add to a virtual machine and upload it somewhere? 00.32.22 # <[Saint]> saratoga: I have a prebuilt version of it - likely the same version we've all been carrying around for years. 00.32.57 # <[Saint]> shedding all the useless cruft in it would be really nice, though. 00.33.45 # found another bug, snake1 freezes input 00.33.54 # oh gosh 00.34.51 # <[Saint]> Hoshi: one thing you'll perhaps learn pretty quickly is that for a lot of ports, especially the more recent ones, plugins were developed to the extent that they had keymaps and compiled. 00.35.18 # ok, im just reporting 00.35.21 # <[Saint]> I really don't think anyone except __builtin would be disappointed if all the non-viewer plugins disappeared, to be honest. 00.35.24 # found three bugs today under e384 00.35.37 # most of them are useless 00.35.41 # especially demos 00.35.59 # <[Saint]> Uselss /now/, yes. But remember this project predates smartphones by a good measure. 00.36.02 # they are only good for benchmarking 00.36.08 # <[Saint]> That stuff used to be _amazing_. 00.36.46 # <[Saint]> Now it is regarded as common place, kitchy, and just weird. 00.37.04 # but its stiil nice hobby 00.37.14 # i found my old mp4 and joined that channel yesterday 00.37.40 # Hoshi: i think if you're not interested in working on the plugins, its probably not necessary to try and test them 00.37.51 # <[Saint]> The audio side of Rockbox is still very much relevant, and even some of the viewer plugins are a lot better than their modern counterparts. 00.38.04 # <[Saint]> The jpeg/png viewer is an obvious example. 00.38.10 # <[Saint]> amazingly fast and efficient. 00.38.37 # <[Saint]> Convenience is a tradeoff though. 00.39.42 # youhou, /me has reached the state where the cross gcc is built ! Fingers crossed 00.40.21 # of course this will all be pointless if the builds don't work on the target because of 00.40.36 # [Saint] what player do you have? 00.40.51 # <[Saint]> Hoshi: probably easier to list the ones I don't have. 00.40.53 # i remember that you was there... i helped pamaury debug e384 two years ago 00.40.59 # oh nice 00.41.49 # if i could try to search i should find an maybe 10, but actually im here because i have e384, e474, ipod nano 5g, some other not really important 00.42.01 # <[Saint]> My go-to devices are a couple of solid state converted iPods, though. Classic, Video, and 4G/Colour. 00.42.28 # <[Saint]> iPod Nano 5G is really really really unlikely to happen. 00.43.55 # <[Saint]> An individual would need to really love that device, and have a deep seated loathing for themselves, to persue that avenue. 00.45.37 # bluebrother: did you get a chance to look at the rockbox utility ipod classic stuff? 00.45.46 # <[Saint]> Freemyipod has execution on the Nano 4G, but we're limited to poking around in the RAM area because there's no way to get storage access without a LOT of work. 00.46.12 # prof_wolfff: were you going to commit the AMSv2 USB support? I think it can safely go in now 00.46.28 # yeah that seems kinda of really hard, especially given that each generation has less documentation than the previous one 00.46.35 # <[Saint]> In theory there's most of a port for the iPod Nano 3G sitting in the Rockbox tree already, but that suffers the same issue as the Nano 4G in that it would take a lot of work to address the storage. 00.46.59 # [Saint]: you are referring to the flash and FTL ? 00.47.02 # <[Saint]> The actual exploit and execution method used for the initial Classic work was actually discovered on the iPod Nano 3G 00.47.04 # <[Saint]> pamaury: yeah 00.47.14 # <[Saint]> The FTL is a real showstopper there. 00.47.23 # OMG, I did it !! I built a cross compiler for the sony :) Admitely not the one from sony but hey ;) 00.47.25 # <[Saint]> But I don't watch the iPhone communities closely. 00.47.37 # <[Saint]> Perhaps they've made advances. 00.47.55 # I think on iphone they aim at jailbreaking 00.48.07 # <[Saint]> I still feel sorry for the poor guy who found the exploit that allowed the Classic/6G port to happen. 00.48.21 # http://translate.rockbox.org/edit.php?lang=francais 00.48.21 # why ? 00.48.30 # the french translation could also use some help 00.48.33 # <[Saint]> His poor little almost-universally-hated Nano 3G never actually saw any love from the exploit he found. 00.49.13 # saratoga: ok I'll have a look tomorrow 00.49.29 # <[Saint]> The Nano 3G is like a weird transitional device, in many regards. It was never very popular at all, and internally it is all over the show. 00.49.45 Quit paulk-collins (Quit: Leaving) 00.49.54 # anyway, sonce USB is working on AMSv2 and the ipod classic has an installer, i really want to do the 3.14 release 00.50.17 # <[Saint]> It is like an iPhone, a iPod Nano, and an iPod Video had a 3-way and their child was deformed because they were all closely related. 00.50.37 # robertd: the ct-ng config I posted compiles 00.50.46 # tomorrow I'll try to test on device 00.51.04 # * pamaury doesn't know why people would hate the nano 3G 00.51.54 # <[Saint]> It didn't appeal to anyone who actually liked the Nano form factor at all. 00.52.17 # <[Saint]> Nor anyone who liked the iPod form factor, because it was flash based and as such had a tiny storage space. 00.52.20 # ah I see, it's the kinda of deformed one 00.52.41 # <[Saint]> right, like almost literally a baby Video. 00.53.31 # <[Saint]> Then they went all weird again with that square touchscreen Nano 6G and then just nuked the Nano program altogether. 00.53.40 # it's a bit of shame, I mean the nano 7G has a nice form factor, it could be a good small device, but it's just unthinkable to crack it at this point 00.54.08 # <[Saint]> Oh - huh, yeah, you're right. I forgot the Nano 7G even existed. 00.54.15 # the 6g is very weird 00.54.33 # <[Saint]> It made a nice watch. 00.54.44 # <[Saint]> I kinda saw it as a gateway to smart watches. 00.55.03 # <[Saint]> it was a really awful DAP though. 00.55.05 # pamaury i was just trying to compile it with your instructions 00.55.09 # i wonder how many of our users would even want a 16GB player though 00.55.56 # robertd: I am going to bed, good luck, just post on the channel if you have any problem, I read the logs 00.56.22 # <[Saint]> the audio on it was laughably bad, so if you just crushed everything down to speex or 28k opus, you probably would'nt even notice! 00.56.26 # <[Saint]> (/s) 00.56.36 # robertd: don't forget to the read the README ! 00.57.16 # pamaury thank you for all the effort. this is the only place that could acomplish that. Even for the ereader I had to use a generic compliler 01.07.27 Quit pamaury (Ping timeout: 252 seconds) 01.10.36 Join krabador [0] (~krabador@unaffiliated/krabador) 01.14.10 # so, there is nice adventure to someone who would mind ipod nano 5g 01.14.52 # its very likely to happen this system is exploitable, but how? buffer overflow? 01.15.46 # i dont remember an ipod nano 5g filesystem architecture but maybe way to load an game as an entry 01.15.55 # interesing so far 01.18.11 # but i hate the freemyipod released the exploit before 5g... but i can mind that its not really big market like sony/nintendo devices while every exploit is released with really thought way, because of software/hardware update 01.20.57 # <[Saint]> Basically the only way a Nano 5G port is going to happen is if someone like yourself gets the skill and determination required to do so and makes it happen. 01.21.19 # <[Saint]> I assure you no one in the Rockbox project direct is working on it, nor have they ever expressed any desire to do so. 01.21.41 # <[Saint]> Far too much work for very little gain. 01.27.26 # <__builtin> Hoshi: a bunch of plugins appear not to work 01.27.45 # <__builtin> but that's a feature ;) 01.28.00 *** Saving seen data "./dancer.seen" 01.28.45 Quit ZincAlloy (Quit: Leaving.) 01.37.33 Quit __builtin_testin (Quit: ZNC 1.7.x-git-631-88a8675 - http://znc.in) 01.38.50 Join __builtin_testin [0] (~franklin@cpe-75-177-76-62.triad.res.rr.com) 01.39.25 Quit __builtin_testin (Client Quit) 01.50.05 # __builtin i would say it's crazy feature, because it lets my player stupid or stuck like my sister does often :P 01.50.10 # "joking" 01.51.09 # <[Saint]> Did someone let their Markov chain bot out to play in the real world? 01.56.10 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 47.0.1/20160623154057]) 01.57.31 Quit idonob_ (Ping timeout: 240 seconds) 02.01.30 # Anyway, I think the ipod nano 5g can be an pure black box. It's so basic device, we don't know so much about an software, the persons from freemyipod didnt hack anything (because they cant or because they are lazy, this is an question) 02.10.53 # <[Saint]> It is absolutely not "so basic device". 02.11.09 # <[Saint]> It's that type of thinking that detracts from the work people actually do here. 02.11.46 # <[Saint]> That (wildly incorrect) statement devalues the work of those who made efforts to gain execution on these devices. 02.14.21 # <[Saint]> And it isn't about not being able to, or being "lazy". This is a hobby. People work on the devices they own personally and are interested in working on. 02.14.39 # Anyway, I know, its an bad word. 02.14.53 # <[Saint]> If you want Rockbox on the Nano 5G, and believe it to be easy to achieve - by all means, do so. 02.15.01 # I dont mean its easy 02.15.44 # But you know, they found vuln in the simplest way to load an code, in the simplest application that can handle files - notes. 02.16.39 # <[Saint]> that method hasn't been used in years and was never viable on the 5G to begin with. 02.16.40 # I mean, is there an other way to load code from filesystem than bufferoverflow? If yes? Maybe will gonna interest in it. 02.17.16 # There is no bugless programm, until its linux lol :P 02.17.31 # I would mind they MUST somewhere broke the implementation of code. 02.17.39 # (Apple) 02.18.27 # <[Saint]> Linux kernel is bugless huh? 02.18.27 # <[Saint]> Interesting theory... 02.18.32 # the ipods usually have extremely complex hardware 02.18.40 # <[Saint]> http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 02.18.48 # so porting anything to them tends to be extremely complex 02.18.49 # linux kernel is not bugless in terms of security, but its still blackbox 02.19.01 # <[Saint]> No. 02.19.19 # <[Saint]> Actually, I'm not even sure what you think you mean by that. 02.19.48 # ah gosh i was learnt the way linux is really secure 02.20.31 # and coders patch the every hole in the security day after, and kernel ships in the same week 02.20.46 # probably a ton of much, much easier devices to work on unless someone really likes the Nano 02.21.06 # and wants to spend a very long time working on it 02.21.08 # nwz-e474 is interesing 02.21.33 # it runs linux, and pamaury with robertd taked an idea of hacking the nwz line 02.21.39 # <[Saint]> And, yes, in general the Linux kernel has a fast update path for vulnerabilities - but that is pretty much entirely meaningless to the concept of enbedded devices. 02.21.56 # i know 02.22.18 # so we could use somehow old exploits on mp4 that run linux? 02.22.47 # <[Saint]> I can't think of any that do run a pure Linux kernel. 02.22.56 # its like android, i know 02.23.04 # but they have parts of it 02.23.09 # why it would be not possible? 02.24.29 # <[Saint]> You seem to think this is vastly less complicated than it is. 02.24.30 # <[Saint]> Lets say, for the sake of conversation, that there are devices out there running a mainline linux kernel... 02.24.43 # <[Saint]> How do you intend on getting a payload to the device in the first place? 02.24.54 # you can use any exploit that exists in your device, but first you have to find one... 02.25.02 # <[Saint]> Bingo! 02.25.48 Quit nlogex (Quit: WeeChat 1.5) 02.25.49 # <[Saint]> If there's no update path for the device, or if there is, and it only accepts signed images and the key ins't known - there's your best chance out the window immediately. 02.26.34 # <[Saint]> So then you need to resort to finding some esoteric device-specific vulnerability just so you can deploy /another/ exploit. 02.28.17 Quit Hoshi (Ping timeout: 252 seconds) 02.31.58 Quit krabador (Quit: Leaving) 02.38.49 Quit NathanV (Ping timeout: 264 seconds) 02.43.35 Join NathanV [0] (68dc3297@gateway/web/freenode/ip.104.220.50.151) 02.56.27 # Build Server message: 3New build round started. Revision 6a1644c, 255 builds, 15 clients. 02.58.18 # saratoga: i just committed the designware patch for AMSv2, the only problem that could happen is that AFAIK there has never been tested in fuzev2 and clipv2, should work well or need small changes in configuration if the USB designware core on these devices is not exactly the same as the clipzip and clipplus, i think it is not the case but do not know much about Sansa HW 03.01.56 # <[Saint]> prof_wolfff: I think that, because we have an exist plan available via dual-boot, that forcing users to confront this is the "right" way to handle it. 03.02.24 # <[Saint]> We'll know very quickly if it presents issues. 03.03.44 # sure, in addition it could be easily disabled for each specific target 03.07.11 # Build Server message: 3Build round completed after 643 seconds. 03.07.12 # Build Server message: 3Revision 6a1644c result: All green 03.28.03 *** Saving seen data "./dancer.seen" 03.30.04 Join soap_ [0] (~soap@rockbox/staff/soap) 03.32.38 Quit soap (Ping timeout: 252 seconds) 04.03.17 Quit Moarc (Ping timeout: 244 seconds) 04.04.21 Join Moarc [0] (~chujko@a105.net128.okay.pl) 04.26.18 Quit NathanV (Quit: Page closed) 04.28.39 Quit __builtin (Ping timeout: 265 seconds) 04.30.04 Join __builtin [0] (~zulu@unaffiliated/franklin) 04.35.01 # pamaury http://pastebin.com/C6AjJent 04.35.08 Quit robertd (Quit: Page closed) 05.28.07 *** Saving seen data "./dancer.seen" 05.30.07 Quit bp0 (Remote host closed the connection) 05.32.18 Join treaki__ [0] (~treaki@p5B11C155.dip0.t-ipconnect.de) 05.32.48 Join bp0 [0] (~bp@unaffiliated/bp0) 05.35.57 Quit treaki_ (Ping timeout: 244 seconds) 05.45.42 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 06.15.31 # prof_wolfff: I tested the clipv2, I think the only device we didn't try was fuzev2, but it should work 07.08.25 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 07.12.08 Quit JdGordon (Ping timeout: 276 seconds) 07.28.10 *** Saving seen data "./dancer.seen" 07.56.02 Join JanC_ [0] (~janc@lugwv/member/JanC) 07.57.04 Nick JanC is now known as Guest35265 (~janc@lugwv/member/JanC) 07.57.04 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 07.59.35 Quit Guest35265 (Ping timeout: 276 seconds) 08.09.12 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.12.36 Quit JdGordon_ (Ping timeout: 276 seconds) 08.43.51 Quit Moarc (Ping timeout: 240 seconds) 08.44.45 Join Moarc [0] (~chujko@a105.net128.okay.pl) 08.47.23 Quit jtdesigns01 (Ping timeout: 250 seconds) 09.09.23 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 09.12.23 Quit JdGordon (Ping timeout: 276 seconds) 09.28.13 *** Saving seen data "./dancer.seen" 10.00.42 Join elensil [0] (~edhelas@2001:1c02:1903:d800:3845:3e8e:c62e:638d) 10.03.16 Join JdGordon [0] (~jonno@210-84-43-27.dyn.iinet.net.au) 10.03.16 Quit JdGordon (Changing host) 10.03.16 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.06.10 Quit JdGordon_ (Ping timeout: 244 seconds) 10.14.13 Join jtdesigns01 [0] (~quassel@2601:400:8000:34f5:208:54ff:fe4f:26f) 10.48.36 Join Boltermor [0] (~Boltermor@subscr-46-148-174-140.dhcp-docsis.net.tomkow.pl) 11.05.39 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 11.07.20 Join idonob [0] (~Owner@S0106602ad08ec3dd.vs.shawcable.net) 11.12.03 Join lebellium [0] (~chatzilla@89-93-176-213.hfc.dyn.abo.bbox.fr) 11.12.46 Quit Boltermor (Quit: Leaving) 11.28.14 *** Saving seen data "./dancer.seen" 11.43.25 Join fs-bluebot_ [0] (~fs-bluebo@xd9beefa4.dyn.telefonica.de) 11.45.20 Quit fs-bluebot (Ping timeout: 244 seconds) 11.45.54 Quit athidhep (Quit: athidhep) 11.46.00 Quit bluebrother (Ping timeout: 252 seconds) 11.47.50 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 12.23.07 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 12.30.40 # prof_wolfff: congrats on the usb, you really did an amazing job from what I hear :) 12.58.17 Quit ruskie (Excess Flood) 12.58.27 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 13.13.01 Join petur [0] (~petur@rockbox/developer/petur) 13.15.00 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:688a:4e1:1c8b:d767) 13.19.09 Join Hoshi [0] (~Hoshi@dlv98.neoplus.adsl.tpnet.pl) 13.28.16 *** Saving seen data "./dancer.seen" 13.46.12 # robertd (logs): are you sure you started from a clean directory ? this looks like a persmission problem 13.47.18 # did anyone notice that on YP-R0 or Sansa Clip (I expect all devices with the same DAC), there is a huge volume gap between FM radio and music playback? If you switch from FM radio to music playback, you almost get your ears damaged. 13.47.56 # It could come from the early 2015 commit reducing noise and distortion at high volume. 13.48.16 # lebellium: can you bisect the problem ? 13.48.34 # Yeah I could try 13.48.44 # I read it from here: http://www.anythingbutipod.com/forum/showthread.php?t=58642&page=61 13.48.47 # it is quite possible that some rework commit forgot that the FM input does not go through the DAC amplifier 13.48.50 # and I just checked myself 13.52.13 # I bet this comes from http://git.rockbox.org/?p=rockbox.git;a=commit;h=42219b6 13.52.16 # but I'll bisect it 13.52.58 # * pamaury has a look 13.53.53 # you also fixed another related problem here http://git.rockbox.org/?p=rockbox.git;a=commit;h=6f54a86 13.56.04 # yeah I remember, that was another problem, the previous commit forgot that the as3514 driver in fact handles as3543 which has a different volume range 13.59.34 # lebellium: ok I need to read the AS3543 doc carefully again, I'll do that this afternoon 14.00.05 # Do you still need me to bisect it and confirm this comes from this commit? 14.00.24 # yeah please 14.00.40 # just to confirm I am not chasing a ghost in this commit ;) 14.00.48 # okay 14.00.52 # it's easy though: try the commit before and after 14.01.03 # yeah 14.01.05 # no need to do a real bisect if you are confident this is the one 14.06.22 # lebellium: do you get weird noise on sansa clip during recording periodically 14.06.53 # don't know, I never record voice or fm 14.06.58 # http://timecop.mine.nu/strange.wav < like this 14.07.11 # its always there on rockbox with various intervals :) 14.07.19 # and I have mayn, many sansa clips 14.07.38 # oh yeah this one, I guess it's just the famous CPU noise on Clip 14.07.43 # o yea? 14.07.48 # is that in playback too? 14.08.05 # when skipping to next track I guess 14.08.19 # hmm this is in continuous mic recordings 14.08.32 # every i donno.. 30+mins i gues,s i never really counted how often it happens 14.09.27 # mkay 14.09.31 # at least im not going insane. 14.09.42 # i just thought all my clips were cursed or something 14.10.15 # well I'm not that surprised. There are many noises here and there in Clip 14.10.34 # I can't reproduce this one right now but for example when changing the volume down or up, there is one 14.15.06 Quit ZincAlloy (Quit: Leaving.) 14.17.37 # IIRC there's also noise in Sansa Clip recordings when the display is on 14.24.21 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 14.40.16 # aren't the clip/fuze infamous for their cpu noise ? 14.58.01 # pixelma: display is off on these 14.58.38 # noise comes up randomly, i should really stick one in a quiet place and record for ~hours and see if the pattern of this clicking is intermittent or consistent 15.28.19 *** Saving seen data "./dancer.seen" 15.37.33 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.47.20 # pamaury: it's not the commit I thought. In 42219b6 there wasn't such a volume gap 15.48.12 # the problem is that bisecting on Clip Zip is a pain. USB almost never works in Rockbox and using the OF takes also so much time because of the slow "refreshing media" after each disconnecting from the PC 15.49.07 # lebellium: it's likely the bug comes from a commit in the as driver 15.49.12 # there are only 4 recents of those: 15.49.18 # http://git.rockbox.org/?p=rockbox.git;a=history;f=firmware/drivers/audio/as3514.c;h=167dd85abbecc6c0139141eb3fb8996140092f1e;hb=HEAD 15.50.21 # lebellium: can you check if 3e5e9cf7 is the culprit ? 15.51.03 # yes 16.03.15 # 3e5e9cf7 is bad. Now checking the commit just before to be sure 3e5e9cf7 introduced the issue 16.03.41 Join munkis [0] (4ba18acf@gateway/web/freenode/ip.75.161.138.207) 16.04.17 # is there a limit on the number of viewers in the open-with menu? 16.06.02 # munkis: I think you asked yesterday and the answer is "none that I know about", but unless you describe a specific problem it's to say more 16.07.44 # im sorry i thought it was missed due to my other question. after adding 10 entries to viewers.config my fuze+ open with system started dropping viewers 16.08.19 # what do you mean by "dropping viewers" ? 16.09.45 # pamaury: ok confirmed 3e5e9cf7 is the culprit 16.10.09 # lebellium: ok I'll have a closer look 16.11.14 # munkis: ok you are right, there is a hard limit of 56 viewers total on most targets 16.12.34 Quit Ivoah (Quit: Connection closed for inactivity) 16.14.45 # pamaury: is that viewers or filetype entries? 16.15.08 # from what I understand, there can be at most 56 viewers and 192 filetypes 16.15.24 # you can have a look at the code in apps/filetypes.c 16.15.32 # the code is not super clear to be honest 16.16.12 # lebellium: can you test a theory for me ? 16.16.39 # ? 16.17.03 # in a culprit build, set a volume with DAC, then switch to line in (radio I guess ?): the volume should be very loud now. Then change the volume slightly. If my theory is right, it will be back to a normal level 16.23.30 # pamaury: so 17 viewers should work fine 16.24.17 Join Ivoah [0] (uid49352@gateway/web/irccloud.com/x-haunsneumwsweryp) 16.24.38 # munkis: I am not sure how the code works, it may be that the array is also partially filled with builtin viewers 16.24.57 # the best way to know is to do a custom build of the firmware with some debugging to know 16.25.44 # I'll try that, thanks. 16.26.08 # pamaury: I'm not sure I understood properly: the volume is higher in music playback than in FM radio. So if I set a volume in music playback and then switch to radio, the volume won't be high 16.26.45 # lebellium: ah ok, and if you change the volume after that, does it stay low or does it "jumps" back to a normal level ? 16.26.53 # (in radio) 16.30.30 # I guess you found out something but I'm a bit lost, I try to understand the behaviour 16.31.35 # looks like that for the same displayed volume, the volume may chang 16.31.36 # e 16.32.03 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:2dcd:eb54:1534:596b) 16.32.06 # I am trying to understand the code logic, I am not sure I am on something, but my test is simple: 16.32.07 # * play a file 16.32.07 # * set a volume that is reasonable (call it volume A) 16.32.07 DBUG Enqueued KICK pamaury 16.32.07 # * switch to radio 16.32.07 # * now volume is low (let's call it B) 16.32.10 # * now change volume slightly (press volume up or down once) 16.32.12 # * is the new volume (what you hear, not see) still almost the same as B or is it back to A ? 16.34.14 # well I have a problem here because both volumes are more or less identical 16.34.28 # I'm wondering if the gap is not increasing from a certain level 16.34.55 # ah yes sorry, you need the initial DAC volume to be pretty high 16.35.11 # I am not sure the bug exists at lower levers 16.36.06 # the threshold must be somewhere around ~2dB, so that's very loud for the DAC, keep your headphones far your hears ! 16.37.40 # pressing volume up or down doesn't make it back to normal 16.38.02 # ok, but you confirm there is a huge gap between DAC and radio ? 16.40.03 # yes, when I'm at a normal volume in radio (let's say -38dB), switching to music playback is very loud. I have to lower the volume up to -48dB to get a similar volume as the radio 16.40.52 # all right, I *think* I know what the problem is 16.53.17 Quit Hoshi (Read error: Connection reset by peer) 16.54.19 Quit petur (Remote host closed the connection) 17.02.44 # back 17.04.31 # I am not sure yet I found the bug, I might need you to run a custom build with some logf debugging if I cannot confrm it by reading the code 17.05.11 # ok 17.06.13 Join Hoshi [0] (~Hoshi@dlv98.neoplus.adsl.tpnet.pl) 17.09.52 # lebellium: does the bug manifest itself it you use the radio and use a normal listening level and then switch to DAC (but without changing the volume) ? 17.10.17 # *if you 17.11.36 # ahhh, I think I understand the problem now, so yeah clearly if you switch from a low radio level to DAC, you hear might explode 17.11.46 # *ears 17.19.21 # problem just dissapeared im guessing it was an issue in my config file. thanks pamaury 17.20.47 # lebellium: I almost have a fix (I think) 17.20.59 # great 17.26.19 # this is odd, either there is dead code or some pp/amsv2 target have broken radio/recording /me thinks 17.26.25 # *pp/amsv2 17.28.21 *** Saving seen data "./dancer.seen" 17.32.04 Quit __builtin (Quit: ZNC 1.6.3 - http://znc.in) 17.32.58 # lebellium: can you try with g#1369 ? 17.33.00 # 3Gerrit review #1369 at http://gerrit.rockbox.org/r/1369 : 3as3543: fix audio gap when switching from dac to line-in/recording by Amaury Pouly 17.33.34 # yep 17.34.13 # lebellium: for testing, can you try each four transitions below, with the old and new build: 17.34.13 # 1) low volume: radio -> dac 17.34.13 # 2) low volume: dac -> radio 17.34.13 # 3) high volume: radio -> dac 17.34.13 # 4) high volme: dac -> radio 17.35.10 # I think only 1) was really broken/dangerous 17.38.06 # /home/ubuntu/rockbox/apps/usb_keymaps.c:52: error: ‘LANG_MULTIMEDIA_MODE’ undeclared here (not in a function) 17.38.07 Quit krnlyng (Ping timeout: 258 seconds) 17.38.24 Join __builtin [0] (~zulu@unaffiliated/franklin) 17.40.10 # lebellium: make clean 17.46.38 Quit munkis (Quit: Page closed) 17.51.17 Join krnlyng [0] (~liar@178.112.176.236.wireless.dyn.drei.com) 17.57.38 # I think we have a problem :D 17.57.51 Quit __builtin (Quit: ZNC 1.7.x-git-unknown - http://znc.in) 17.57.53 # with the patch, the FM radio stops working at some time 17.58.13 Join __builtin [0] (~zulu@unaffiliated/franklin) 17.58.38 Quit treaki__ (Ping timeout: 264 seconds) 17.58.41 Join Hoshi_ [0] (~Hoshi@aceh198.neoplus.adsl.tpnet.pl) 17.59.53 # well, the radio works (RDS is working) but no sound at all 18.00.19 # looks like it sometimes occurs when switching from DAC to radio 18.02.02 Quit Hoshi (Ping timeout: 240 seconds) 18.02.31 # lebellium: you mean when switcing sometimes it does not work ? 18.02.39 # and if you change the volume after that ? 18.03.49 # lebellium: ok I see why, my mistake 18.04.38 Quit __builtin (Quit: ZNC 1.7.x-git-unknown - http://znc.in) 18.04.54 # lebellium: I have updated g#1369 18.04.55 # 3Gerrit review #1369 at http://gerrit.rockbox.org/r/1369 : 3as3543: fix audio gap when switching from dac to line-in/recording by Amaury Pouly 18.05.29 # hum wait 18.05.43 # there is still a bug 18.07.51 # pfff I'm getting those ATA errors again on my clip zip :( 18.09.38 # lebellium: I have updated again g#1369, hopefully this should work 18.09.39 # 3Gerrit review #1369 at http://gerrit.rockbox.org/r/1369 : 3as3543: fix audio gap when switching from dac to line-in/recording by Amaury Pouly 18.10.15 Quit elensil (Ping timeout: 250 seconds) 18.14.48 # home/ubuntu/rockbox/firmware/drivers/audio/as3514.c:314: error: expected ‘)’ before ‘;’ token 18.14.59 # home/ubuntu/rockbox/firmware/drivers/audio/as3514.c:326: error: expected ‘,’ or ‘;’ before ‘}’ token 18.15.59 # ah I should have tried to compile it 18.16.30 # I have updated the gerrit task 18.26.10 Join __builtin [0] (~zulu@unaffiliated/franklin) 18.26.40 # hum in fact I am dumb, I just realized I have a clip zip, I could have tested it myself! Though my zip is probably taking dust somewhere 18.27.04 # not better, no sound in radio all the time now 18.28.30 # huh, really ?? 18.29.10 # yeah 18.29.26 # I think it would be a good idea to find and charge your Clip Zip /p 18.29.28 # :P 18.29.32 # I must have forgotten something 18.30.34 # it's charging, but the battery is super low right now 18.30.35 # but still, even with patch v1, I didn't have the impression it really helped. Indeed, the problem is more for high volume than low volume. 18.30.54 # at low volume, it's quite similar between DAC and radio 18.32.06 # the problem seems to be around from -40dB 18.34.05 # ah fuuuuck, this code is crap, I just spotted another problem 18.40.11 # I am going to make this code MUCH clearer 18.41.34 # lebellium: what's the key to boot to OF ? 18.41.43 # volume down 18.51.00 # <__builtin> how would I reformat an ipod classic properly? 18.51.07 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 18.51.07 # * __builtin knows that fdisk can cause issues 18.59.24 # __builtin: don't ipod have a factory reset thingy ? 19.00.08 # <__builtin> hmm, I found it 19.00.15 # <__builtin> https://www.freemyipod.org/wiki/Restore_iPod_without_iTunes 19.00.19 # <__builtin> thanks pamaury 19.02.26 # hum, my clip zip jack seems to be flaky, this is not good 19.02.56 # <__builtin> Ivoah: about chex quest with doom, I haven't gotten it to work 19.03.04 # indeed... 19.03.18 # __builtin: bit of a late reply there :P 19.04.03 # <__builtin> perhaps I should spend some more time on it 19.04.12 # <__builtin> there's no reason why it shouldn't 19.06.00 # lebellium: the new version of g#1369 works on mine now 19.06.02 # 3Gerrit review #1369 at http://gerrit.rockbox.org/r/1369 : 3as3543: fix audio gap when switching from dac to line-in/recording by Amaury Pouly 19.06.16 # at least I can switch between dac and radio without a problem, either at high or low volume 19.06.26 # ok 19.06.58 # there is a small volume difference between radio and dac on mine but I believe this one is simply due to the radio chip 19.07.12 # it would be nice if you can confirm though 19.08.39 # no work at nwz today :P? 19.09.43 # well technically it's a working day... so not until I am finished at work 19.10.15 # pamaury: we spent the whole afternoon on this thing though. Strange working day :P 19.11.09 # well I have not been very reactive though, I would be quite useless if it took me the whole afternoon to ack ten lines of code 19.11.48 # you did most of the bisecting work :-p 19.15.13 # and testing work 19.20.04 Quit paulk-collins (Remote host closed the connection) 19.20.56 # hum 19.21.10 # yes the switching problem is fixed 19.21.26 # but I don't really see a difference with before the patch 19.23.29 # well I haven't tried, but before the patch if you switched from dac to radio and back, you could end up with an incredibly high volume 19.24.31 # isn't this the problem you initially mentioned ? 19.27.17 # well, yes I guess it's a bit better. It's confusing because now at the same displayed volume, it's louder in radio than before the patch. That means I have to lower the volume with patch to compare better 19.27.54 # -37dB without patch is about -42dB with patch 19.28.13 # this is strange, I haven't changed any volume 19.28.22 *** Saving seen data "./dancer.seen" 19.29.03 # there is clearly a noticeable difference 19.30.49 # ok I'll have a close look later 19.30.55 # but that's good 19.31.04 # since there isn't a difference for DAC 19.31.19 # that means that automatically, the volume gap with patch is smaller 19.32.18 # In radio: -37dB without patch = -42 with patch. But clearly in DAC -37dB without patch is much louder than -42dB with patch 19.35.14 # lebellium: so you think the problem is fixed ? 19.37.27 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 19.40.31 # I'd like to replicate the original bug just to make sure though 19.40.43 # can you point me to the exact head-fi post that describes it ? 19.41.22 # I think the problem is fixed but it's embarrassing you didn't fix it intentionally :P 19.41.29 # lebellium: also I'd like to make sure this didn't break any other device, in particular the amsv1 devices. Do you have any of those to test ? 19.41.30 # http://www.anythingbutipod.com/forum/showthread.php?p=656460#post656460 19.43.53 # I have a Fuze v2 19.43.56 # v1* 19.44.10 # that's my only AMSv1 device I guess 19.44.54 # well I am a bit confused, because the bug I fixed is that when switching from radio to dac in certain occasion might yield an incorrect, very high volume. What this post describes could be an instance of it (basically because he's lucky, the very high volume only exists for a fraction of time but still). 19.45.13 # I cannot explain why my patch changes the the volume between radio and dac though, it doesn't make any sense 19.45.37 # difference between dac and radio are to be expected, it would be naive to think you can just magically match them 19.46.11 # well I tried on Clip Zip only. I should try on my R0 too 19.47.06 # it would be interesting to have a look at the radio code though, because the radio probably has an amplifier that can be tweaked 19.55.38 Quit Rower (Ping timeout: 264 seconds) 19.59.08 # I confirm the volume difference in radio on YP-R0 20.00.08 Join petur [0] (~petur@rockbox/developer/petur) 20.02.30 # lebellium: how much is the difference ? does the patch makes a difference ? 20.02.48 # about 5dB 20.03.23 # with patch, the difference between DAC and radio is acceptable 20.03.28 # it won't hurt your ears 20.04.05 # and without the patch, is there a problem ? 20.04.16 # yes 20.04.18 # I told you 20.04.20 # 10dB 20.04.44 # did you try it at other levels ? Like -30dB or -20dB ? Because I expect the problem gets bigger at higher volumes without the patch 20.06.50 Join Hoshi [0] (~Hoshi@aceh198.neoplus.adsl.tpnet.pl) 20.06.51 # * pamaury is trying to understand the 5dB vs 10dB difference, I believe this magic number could be 10-5 ~= -35-(-40.5) where -35 is your volume and -40.5 is the threshold volume at which something happens in the code 20.07.30 # probably its made like that for hardware 20.09.01 # pamaury: that's not accurate figures. It's not easy to match 2 volumes on different devices. It's only my perception 20.09.46 # I know, I am just saying that with my patch, it makes sense that there is a fixed volume difference between radio and dac. But that without my patch, the problem should get worse with volume 20.10.00 # now on a different radio frequency, -25dB without patch sounds like -30db with patch too 20.10.18 # of course all of this depends on the radio channel and the song 20.10.33 # the difference is fixed at fixed channel and fixed song 20.10.58 # yeah, I did all my tests with the same song for DAC and same frequency for radio 20.11.08 # Build Server message: 3New build round started. Revision 5a673d6, 255 builds, 16 clients. 20.12.13 # the problem is that now at -25 or -30db I can't hardly test the switch to DAC 20.12.20 # it would destroy immediately my hears 20.12.55 # so it's possible the problem gets worse but not easy to test 20.13.00 # I have sensitive IEM 20.13.33 # keep your ears at a safe distance from the headphones ;) 20.13.54 # but yeah not easy to test 20.13.54 # yes but if there is a distance, the test is not reliable 20.15.03 # I know, but my "test" would somehow manage to differiante between "sound is loud" and "sound is incredibly super duper high". Something like 20dB should be possible I think 20.15.40 # a proper test would involved recording with another device though 20.15.46 # I may try that 20.15.57 # prof_wolfff: a general note: I would rename mk6gboot to mkipod6gboot -- mk6g is a bit ... ambiguous, even though there's only a 6g ipod :) 20.17.17 # its hard to compare FM volume to DAP volume since FM tends to be both compressed and low pass filtered 20.17.30 # it'll sound louder even at the same peak to peak value 20.17.58 # I'll try to give the other rbutil bootloader related changes a look the next couple of days 20.19.03 # by the way, did we ever agree on dropping HWCODEC from the next release? I believe people thought newer builds were not better than older but i'm not sure 20.19.06 # saratoga: we are talking about a bug that would create a potentially huge difference, like 20dB or more 20.19.31 # yea i'm sure that is a bug, but if he said it sounded a few dB louder (after your patch), that could be normal 20.19.50 # Build Server message: 3Build round completed after 521 seconds. 20.19.51 # Build Server message: 3Revision 5a673d6 result: All green 20.19.52 # Build Server message: 3New build round started. Revision 40ce2b4, 255 builds, 15 clients. 20.20.12 # oh yeah, sure :) Re HWCODEC I don't remember, we may have agreed that if won't object if someone do the work of removing HWCODEC 20.20.13 # ;) 20.20.43 # i don't think we need to remove it, just don't release 3.14 for it 20.21.04 # since most people seemed to think older builds were better than current git 20.21.27 # if someone wants to work on it more i'm all for doing future releases again, just not sure it makes sense now 20.22.03 # ah yeah we agreed to potentially not release anymore for hwcodec and create a branch for the last released/known working version with hwcodec 20.22.43 # pamaury: can you add any additional devices you want to make stable: http://www.rockbox.org/wiki/ReleaseNotes314 20.22.51 # also hwcodec somehow includes the SH CPU and LCD_CHARCELL 20.23.01 # saratoga: yes 20.23.49 # saratoga: ping me again in one hour if I'm not done, I'm trying to finish some work tonight 20.24.11 # oh sure, whenever you get a chance, its not critical 20.28.03 # Build Server message: 3Build round completed after 492 seconds. 20.28.04 # Build Server message: 3Revision 40ce2b4 result: All green 20.55.38 Quit paulk-collins (Remote host closed the connection) 20.58.46 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 21.01.14 Join shane [0] (~shane@ana.rch.ist) 21.01.49 Join smoke_fumus [0] (~smoke_fum@188.35.176.90) 21.02.34 Quit soadkombucha (Quit: https://fnordserver.eu) 21.12.59 Join rela_ [0] (~x@p200300764D418400F0A827DC69400648.dip0.t-ipconnect.de) 21.17.13 Quit rela (Ping timeout: 260 seconds) 21.21.29 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 21.28.23 *** Saving seen data "./dancer.seen" 21.29.35 Join nlogex [0] (~filip@dhcp-108-168-15-53.cable.user.start.ca) 22.03.08 # pamaury: I found a classical music frequency where high volume is bearable. -10dB without patch, 0dB with patch to get similar volume 22.04.13 # the reverse, sorry 22.05.57 # if the 5g is reconnecting in loop on windows, its cable or driver fault? 22.06.10 # i have windows 10, nano was turned into disk mode so it should work anyway 22.32.55 # lebellium: I am confused now. I did some tests on the device and basically the problem I had in mind does not really exists because luckily the radio code set the volume when the radio starts. This means that my patch should in theory not change any volume, but rather reduce the volume of a potential "pop" when switching 22.40.03 # did you notice the volume difference? 22.40.26 # if you don't have 2 devices it may be hard to test though 22.40.39 # that's hard to test, I only have one device 22.40.53 # so basically without the patch, I cannot trigger any bug 22.41.17 # because the bug only exists for a fraction of a second and is apparently not enough to produce a huge pop 22.43.41 # well I don't hear a "pop" nor the hissing the ABI user was referring to. 22.44.07 # for me the bug was only the volume gap between dac and radio 22.44.56 # so your compare with two devices in parallel ? the same device ? 22.45.13 # 4 devices 22.45.17 # 2 Clip Zip, 2 RO 22.45.29 Join athidhep [0] (~afoakf@unaffiliated/athidhep) 22.45.51 # R0* 22.50.25 Join edhelas [0] (~edhelas@145.133.43.230) 22.55.58 Quit lebellium (Read error: Connection reset by peer) 22.56.53 Join lebellium [0] (~chatzilla@89-93-176-213.hfc.dyn.abo.bbox.fr) 23.03.58 # lebellium: when you tried with and without the patch, did you apply the patch on current HEAD ? 23.04.09 # yes 23.04.29 # you can provide me a patched build if you want to make sure 23.06.59 # I sometimes make local changes in the rockbox directory without applying a proper patch, which might remain even after git reset --hard origin/master 23.07.02 # don't know 23.09.56 Quit idonob (Ping timeout: 244 seconds) 23.10.03 # I trust you, I am just scratching my head, because I can't really hear the difference and I don't see how the code could create one 23.13.40 # ah wait I think I found out 23.14.30 # the old code may overwrite some initial audio setup whereas my patch keeps them 23.15.13 # in particular this mixer has an AGC feature 23.15.40 Join robertd [0] (c9f2b970@gateway/web/freenode/ip.201.242.185.112) 23.15.49 # robertd: hey :) 23.16.14 # lebellium: ok, I almost have a new patch a new patch to submit, just to check I am not crazy 23.16.35 # hi pamaury, thanks for your answer. Due to a libc6-dev-i386 bug i havent been able to test today 23.16.50 # lebellium: hum maybe not in fact, arggg this is driving me crazy 23.17.04 Join idonob [0] (~Owner@S0106602ad08ec3dd.vs.shawcable.net) 23.17.20 # robertd: I saw your message in the log but this doesn't look like a 32-bit error, it was something about build.log permission 23.17.36 # pamaury: lol, don't get crazy for that :) 23.17.36 # what is your error now ? 23.18.42 # pamaury the libc6-dev-i386 required for compiling are conflicting with the amd64. That and a locale error in glibc 23.19.23 # robertd: what is your distrib ? 23.19.47 # pamaury debian 64 23.19.52 # which version ? 23.20.10 # pamaury jesse 8.5 23.20.21 # I am running debian unstable and libc6-dev-i386 and libc6-dev are not conflicting here 23.20.47 Quit edhelas (Remote host closed the connection) 23.21.45 # Pamaury the libg-dev i386 is bug which conflicts with the i386 linux gnu 23.22.14 # can you repeat that, I didn't understand 23.23.31 # pamaury when I try to install the libc6 "trying to overwrite '/usr/include/bits', which is also in package libc6-dev-amd64:i386 2.23-4@ 23.24.05 # ah, so it's not a package conflict, it's simply a bug in the package 23.24.40 # hum 23.24.52 # but on my system, I don't have libc6-dev-amd64 installed... 23.24.59 # pamaury: I just checked to be sure. Without your patch, my local as3514.c file is exactly the same as in the Rockbox tree. 23.24.59 # I only have libc6-dev 23.26.25 # Pamaury, exactly my mistake was to try and install the i386 package with the libc6-dev 23.27.19 # it's confusing, debian has libc6-dev, libc6-dev-amd64, libc6-dev-i386 and libc6-dev-amd64:i386 23.27.53 # libc6-dev-amd64:i386 is particularly hilarious 23.28.06 # robertd: have you tried compiling with just libc6-dev-amd64:i386 ? 23.28.26 *** Saving seen data "./dancer.seen" 23.28.36 # pamaury: going to bed now, I'm available tomorrow night if you get something 23.28.42 # pamaury, yes but then in glibc there is a locale/subdir_install error 23.28.45 # ok thanks for the testing 23.28.56 # robertd: what is the error ? 23.29.18 # libBrokenLocale.so', needed by 'install-lib-nosubdir' 23.29.33 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 48.0/20160726073904]) 23.31.21 # robertd: can you pastebin the last lines of build.log ? hopefully I can make some sense out of it 23.31.31 # did you use the same ct-ng config as me ? 23.32.20 # pamaury yes. It is my machine config I have to sort it out. One sec please 23.33.43 # pamaury here it is http://pastebin.com/NY5puUng 23.36.20 Quit Hoshi_ (Read error: Connection reset by peer) 23.36.21 Quit Hoshi (Read error: Connection reset by peer) 23.36.35 # robertd: the internet says it might be a race condition in the makefile 23.37.42 # I would simply try again. The config I sent you is restartable, so you can execute 23.37.42 # ct-ng + 23.37.42 # and to find the step, look at the build.log or the output ct-ng build, you can get the list of steps by running 23.37.42 # ct-ng list-steps 23.38.01 # maybe disable parallel jobs 23.38.09 # I thought I did in my config but maybe not 23.39.06 # Pamaury thanks, let me give it a try. I will keep you posted 23.39.10 # hum wait this is strange 23.39.25 # the output contains very strange paths 23.39.32 # /usr/local/directory/--exec-prefix=/usr/local/directory/--host=x86_64-unknown-linux-gnu/include/xlocale.h 23.39.51 # did you tweak something somewhere or changed a prefix ? 23.40.24 # pamaury not at all, just the ../glibc-2.19/configure --prefix=/usr/local/directory/--exec-prefix=/usr/local/directory/--host=x86_64-unknown-linux-gnu --target=sony-arm-linux 23.41.09 # why/how did you change that ? didn't you forget some spaces there ? 23.42.36 # pamaury i was going for a standalone glibc 23.43.04 # what do you mean ? 23.43.50 # i aimed at a separated cross compiler 23.44.40 # I still don't understand. So first, are you using crosstool or not ? 23.45.14 # pamaury yes, the same cross-tool 23.45.53 # so you just ran ct-ng build and it failed with this error ? 23.46.05 # and you didn't change *anything* in the configuration ? 23.46.30 # pamauy in the configuration. no not at all 23.47.04 # can you send me the .config generated by ct-ng menuconfig ? 23.47.23 # pamaury sure one sec please 23.48.00 # <[Saint]> Bah - why can't people just idle on IRC when they ask a question? 23.48.23 # <[Saint]> The amount of people that treat IRC as a realtime support network in unfathomable. 23.48.38 # <[Saint]> It certainly /can/ be one... 23.52.08 Topic "Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please stay! You may need to wait some time to get your answer, DON'T leave after a few minutes because you think nobody is there! | If you can't stay and wait, please post your question to the mailing list | This channel is logged at http://www.rockbox.org/irc" by ChanServ (ChanServ@services.) 23.52.23 # <[Saint]> Thanks, freemyipod /topic 23.52.56 Join robertd_ [0] (c9f2b970@gateway/web/freenode/ip.201.242.185.112) 23.53.07 # Pamaury sorry got dc 23.53.15 # <[Saint]> Though it isn't like anyone actually reads the /topic anyway. 23.53.17 # <[Saint]> :-S 23.53.34 # [Saint]: I was about to say it, people who do that don't read the topic 23.53.34 # <[Saint]> But I feel mildly better about myself now. 23.54.24 # <[Saint]> The guy earlier, with the Video. 23.54.24 # <[Saint]> That's a pretty classic symptom of deep discharge. 23.55.02 # <[Saint]> I suspect he's plugging it into a host port on his PC, when it needs to touch the oficial charger (preferably if he can force disk mode) for a while. 23.55.26 # <[Saint]> That's actually a feature I would like to backport to all the iPods from prof_wolfff's bootloader. 23.55.29 # robertd_: actually you can send me the .config or the diff between .config and my sony-arm-linux.config, whatever is more convenient 23.55.50 # <[Saint]> His iPod Classic bootloader detects deep discharge and forces a charge before boot. 23.55.53 # I think he had a nano 5g not a video 5g, but it may be the same problem 23.56.02 # <[Saint]> As opposed to a constant string of failing to spin the disk up. 23.56.04 # pamaury this http://pastebin.com/tsxxnta6_ 23.56.05 Join ulmutul [0] (~chatzilla@x5d837252.dyn.telefonica.de) 23.56.27 # robertd_: your link is wrong 23.56.30 # sorry http://pastebin.com/tsxxnta6 23.56.53 # huh, this doesn't make any sense 23.56.59 # <[Saint]> saratoga: ahhhh, shit, yeah - you're right. 23.56.59 # <[Saint]> Dammit, I assumed '5G' in context of targets we support. 23.57.12 # robertd_: the configuration looks like this: https://gist.github.com/pamaury/57ea56b8251d157291baa065eb6e87b3 23.57.18 # are we talking about the same thing ?