--- Log for 09.10.118  Server: barjavel.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 2 days and 7 hours ago

00.00.43 Quit    benedikt93 (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
00.00.54 Join    benedikt93 [0] (~quassel@unaffiliated/benedikt93)
00.07.47 Quit    fs-bluebot_ (Ping timeout: 246 seconds)
00.09.15 Quit    bluebrother (Ping timeout: 268 seconds)
00.14.30 Join    fs-bluebot [0] (~fs-bluebo@port-92-193-42-223.dynamic.qsc.de)
00.15.24 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
00.16.02 Quit    alexweissman (Ping timeout: 268 seconds)
00.16.28 Quit    foolsh (Ping timeout: 250 seconds)
00.24.15 Join    foolsh [0] (~foolsh@2601:249:4100:c338:1ce3:977f:3eaa:f29a)
00.29.31 ***     Saving seen data "./dancer.seen"
00.31.07 Quit    amofiuhr_ (Remote host closed the connection)
01.01.43 #       * Bilgus wonders if speachy is aware he broke a bunch of targets with his opus patch
01.10.10 #       <foolsh> yep lots of red looks like two problems one is an undeclared instruction two looks like some targets don't have enough ram to fit the stack
01.32.51 Join    this_is_a_nick [0] (~amofiuhr_@ip23-132-50-179.ct.co.cr)
01.48.20 Join    Soap [0] (~Soap@rockbox/staff/soap)
02.29.34 ***     Saving seen data "./dancer.seen"
02.41.22 Quit    krabador (Remote host closed the connection)
03.30.26 Join    alexweissman [0] (~alexweiss@c-73-102-58-200.hsd1.in.comcast.net)
03.36.07 Quit    alexweissman (Ping timeout: 252 seconds)
04.29.37 ***     Saving seen data "./dancer.seen"
04.32.33 Quit    foolsh (Read error: Connection reset by peer)
05.38.46 Join    alexweissman [0] (~alexweiss@c-73-102-58-200.hsd1.in.comcast.net)
05.43.25 Quit    alexweissman (Ping timeout: 260 seconds)
06.23.05 Join    alexweissman [0] (~alexweiss@c-73-102-58-200.hsd1.in.comcast.net)
06.29.41 ***     Saving seen data "./dancer.seen"
06.56.16 Quit    pR0Ps (Ping timeout: 268 seconds)
07.01.28 Join    pR0Ps [0] (~pR0Ps@216.154.8.105)
08.26.38 Quit    mikroflops (Ping timeout: 252 seconds)
08.28.50 Join    mikroflops [0] (~yogurt@83.255.23.64)
08.29.43 ***     Saving seen data "./dancer.seen"
08.43.29 Join    petur [0] (~petur@91.183.48.77)
08.43.29 Quit    petur (Changing host)
08.43.30 Join    petur [0] (~petur@rockbox/developer/petur)
09.21.42 Quit    this_is_a_nick (Remote host closed the connection)
09.44.15 Join    this_is_a_nick [0] (~amofiuhr_@ip152-132-50-179.ct.co.cr)
09.57.27 Join    dandels [0] (~dandels@unaffiliated/dandels)
10.15.32 Quit    defterade (Ping timeout: 252 seconds)
10.29.46 ***     Saving seen data "./dancer.seen"
11.00.45 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
11.20.40 Quit    this_is_a_nick (Read error: Connection reset by peer)
11.23.18 Join    this_is_a_nick [0] (~amofiuhr_@ip152-132-50-179.ct.co.cr)
12.04.27 Quit    dandels (Ping timeout: 244 seconds)
12.29.49 ***     Saving seen data "./dancer.seen"
13.01.54 Join    defterade [0] (~defterade@82-197-194-53.dsl.cambrium.nl)
13.32.57 Join    defterade_ [0] (~defterade@82-197-194-53.dsl.cambrium.nl)
13.33.19 Quit    defterade (Ping timeout: 244 seconds)
13.58.13 Join    defterade [0] (~defterade@82-197-194-53.dsl.cambrium.nl)
13.59.09 Quit    defterade_ (Ping timeout: 244 seconds)
14.24.31 Quit    petur (Read error: Connection reset by peer)
14.24.59 Join    petur [0] (~petur@91.183.48.77)
14.24.59 Quit    petur (Changing host)
14.24.59 Join    petur [0] (~petur@rockbox/developer/petur)
14.29.50 ***     Saving seen data "./dancer.seen"
14.55.05 Join    dandels [0] (~dandels@unaffiliated/dandels)
15.09.25 Quit    dandels (Ping timeout: 244 seconds)
15.17.56 Join    dandels [0] (~dandels@unaffiliated/dandels)
15.39.29 Quit    michaelni (Ping timeout: 252 seconds)
15.41.48 Quit    petur (Quit: Connection reset by beer)
15.46.41 Quit    defterade (Read error: Connection reset by peer)
15.51.35 Join    michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at)
16.02.27 Join    defterade [0] (~defterade@82-197-194-53.dsl.cambrium.nl)
16.29.53 ***     Saving seen data "./dancer.seen"
16.38.51 Join    speachy [0] (d98c6f87@gateway/web/freenode/ip.217.140.111.135)
16.39.36 #       <speachy> Bilgus:  nope, I wasn't aware that it broke anything
16.41.53 #       <speachy> had a clean review and was only supposed to affect targets with RAM to spare.  Was the test wrong?
16.42.56 #       <gevaerts> speachy: http://build.rockbox.org/dev.cgi has the build results
16.43.19 #       <speachy> yeah, it's.. taking a long time to load.
16.43.45 #       <gevaerts> It's quick for me. Yay for the internet :)
16.43.46 Join    TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
16.43.56 #       <gevaerts> Well, wait
16.44.41 #       <gevaerts> no, everything is quick, but some logs are empty
16.45.30 #       <speachy> yeah.. it's coming up now, but no build logs that I can see
16.45.48 #       <speachy> everything I look at is empty, including successful ones
16.46.05 #       <gevaerts> http://build.rockbox.org/shownewlog.cgi?rev=046cc49;type=iriverh120 is one that works for me
16.47.16 #       <speachy> we also need to update the mips toolchian used by the builders
16.49.05 #       <speachy> hmm.  so we're overflowing IRAM due to the bumped stack size.  \
16.49.28 #       <gevaerts> well yes, someone needs to add the new version to rbclient.pl in rockbox-www first so the build clients can actually declare that they support the new version, and then the builds file (same repo) can be updated to require it
16.50.47 #       <speachy> is that something I can do?
16.51.27 #       <gevaerts> Should be. It's the rockbox-www repo on the same server as rockbox, with the same access rights
16.52.02 #       <gevaerts> Then a quick mail to the build clients mailing list (that people running a client should be on...) so people know about it
16.52.21 #       * gevaerts tries to remember the address
16.53.47 Quit    dandels (Ping timeout: 272 seconds)
16.54.11 #       <Bilgus> speachy some of those targets are down to the wire (clearly) :)
16.55.28 #       <speachy> rockbox-www kicks me back with a "make sure you have correct access rights and the repository exists"
16.56.10 #       <gevaerts> oh, wait, it's plain www, not rockbox-www
16.56.38 #       <speachy> so.. is there a sane way to determine which targets have IRAM down to the wire?   I guess the underlying problem is that opus is still too stack hungry when seeking..
16.57.23 #       <speachy> but putting in a pile of #ifndefs around that stack bump seems wrong.  as does simply reverting it altogether
16.57.51 #       <gevaerts> Ah, rockbox-rbclient at cool.haxx.se. Not sure if everyone can send to that, but we'll see
16.57.59 #       <speachy> cool, cloning it now.
16.59.18 #       <gevaerts> Build stuff in in the buildserver/ directory in there
17.01.32 #       <gevaerts> The toolchains are "defined" in there in rbclient.pl, around line 550. In the old days we just used "m68k" or "arm" as the name, which is not very handy if updates are involved, so for newer toolchains we try to add some sort of version in there
17.02.02 #       <gevaerts> oh, wait
17.02.09 #       <gevaerts> the new mips may already be there
17.02.19 #       <gevaerts> mipsel-rb-gcc494?
17.03.17 #       <gevaerts> In which case, only the "builds" file needs to be updated to actually use it for all relevant targets. That's the first column (: separated) in there
17.04.06 #       <speachy> no.. that's a linux toolchain
17.04.26 #       <gevaerts> right
17.04.43 #       <speachy> I added 'mipsel-gcc494'
17.04.58 #       <gevaerts> sounds reasonable
17.05.08 #       <speachy> maybe it sould be called 'mipsel-baremetal-gcc494' or something like that instead
17.05.46 #       <gevaerts> I'd say mipsel-gcc494 is fine
17.05.50 #       <speachy> the naming converion is a bit of a historical mess.  :)
17.05.54 #       <gevaerts> It gets long otherwise :)
17.06.17 #       <speachy> in the builds file, what's the number after rockbox.zip?
17.06.44 #       <speachy> and before the configure line
17.07.05 #       <gevaerts> The estimated build cost, used for build allocation to clients
17.07.20 #       <speachy> larger number is more, essentially?
17.07.54 #       <gevaerts> It's milliseconds on my laptop when I last calibrated, with guesses for newer targets
17.10.36 Join    dys [0] (~dys@2a01:598:b001:93db:226:5eff:fee9:68d2)
17.11.38 #       <speachy> okay, add the toolchain, bump the version to 59..
17.11.55 #       <gevaerts> Great!
17.11.59 #       <speachy> commit, and ping the mailing list?
17.12.32 #       <gevaerts> yes. Actually, also ping zagor to update the server. I'll try to catch him in #rockbox-community
17.12.39 #       <speachy> then wait for a day or two, and commit the updated mips builds?
17.13.27 #       <gevaerts> Well, wait until at least one client is updated, preferably more. I'm trying to update mine now, so hopefully it's quicker than two days
17.14.20 #       <speachy> pushed
17.15.28 #       <gevaerts> ok, I pinged zagor
17.19.12 #       <gevaerts> If the toolchain builds properly, I'll update the clients manually so they won't depend on zagor. Just two clients for mips might be a bit slow, but it's workable
17.19.44 #       <speachy> mail sent to rockbox-rbclient
17.19.48 #       * gevaerts never expects toolchains to build properly first time. There's always something missing :)
17.20.21 #       <speachy> yeah, I remember the first time I compiled a rb toolchain.  I was impressed that it just worked.  :P
17.21.43 #       <speachy> I guess I also need to create/define an X3 simulator build too
17.23.43 #       <gevaerts> Ideally yes I think. Not sure how important it really is, but we do have a tradition to have a sim build for all targets
17.26.03 #       <speachy> there;s also that ihifi 770/770c/800 megapatch sitting in gerrit.
17.27.02 #       <speachy> not motivated enough to spend nearly $300 to test it out.
17.27.37 #       <gevaerts> Yes, that's one common issue
17.28.28 #       <speachy> my reverse-engineering-printers habit is already expensive enough.
17.28.44 Quit    pamaury (Ping timeout: 250 seconds)
17.29.06 #       <gevaerts> If you find one with something resembling audio, put rockbox on it :)
17.31.23 #       <speachy> it's nice that the Chinese market is seeing such a DAP resurgence.
17.32.03 #       <speachy> but getting meaningful info out of them is worse than pulling teeth.
17.38.53 #       <Bilgus>  those old dot matrix form feed printers would have something resembling audio :p
17.40.21 #       <speachy> I remember some 8-bit atari games (on floppy) mucked with the data on disk so it would be quasi-melodic
17.40.52 #       <speachy> so, suggestions on how to fix this build b0rkage from the opus patch?
17.41.25 #       <speachy> beyond just reverting it completely, I mean
17.44.34 #       <Bilgus> you are going to either need to find add a section in the crt file to decide if you have enough space; make something else smaller;add a tag to the config file for the targets that work; or fix opus
17.45.01 #       <Bilgus> thats find/add not find & add
17.45.47 #       <Bilgus> wodz and pamaury are far better at the low level stuff
17.48.03 #       <speachy> hmm.  the file siZe deltas on the build page seem a little wonky.   like a 1K bump from a commit that did nothing more log the creation of the zipfile when building.  :)
17.48.15 #       <Bilgus> the tag in the config file is nearly as bad as the ifdefs but works you could do something like OPUS_BIG_STACK for example and then the idea would be to make targets that don't have it skip the opus files that crash
17.48.47 #       <speachy> it's seeking in that crashes, not normal playback.
17.49.40 #       <speachy> IRAM is fixed on indivual targets, so I don't think there's anything to be gained by mucking with crt0 or the linker scripts.
17.56.29 #       <Bilgus> assuming you have a baseline minimum amount of IRAM just check that there is enough with IRAMSIZE
18.06.50 #       <Bilgus> It is defined in firmware/target/???/???/app.lds
18.21.30 #       <gevaerts> speachy: both my clients should have the new toolchain, so feel free to update builds
18.29.57 ***     Saving seen data "./dancer.seen"
18.31.24 Join    foolsh [0] (~foolsh@2601:249:4100:c338:142a:33ad:2a51:5246)
18.56.47 #       <speachy> oh, another question -- any special mojo to generating a player pic?
18.57.31 #       <speachy> just take a pic and scale it down?
18.59.20 #       <gevaerts> They're svg, usually drawn by someone who knows what they're doing (i.e. not me!)
18.59.28 #       * gevaerts doesn't remember the details
19.01.25 #       <speachy> the ones in the www directory are tiny pngs, 80px at the long axis.
19.03.18 #       <gevaerts> Yes, I think they're generated from the ones in manual/rockbox_interface/images/ in the main repo
19.03.20 #       <speachy> ....generated from the svgs.  yuck.
19.03.35 #       * gevaerts hasn't really contributed to new ports, so he isn't too sure about these things
19.04.43 #       <speachy> that much inkscaping with my hand is going to be an exercise in frustration.  typing is bad enough
19.05.36 #       <gevaerts> IIRC most of those were drawn by other people than the ones who did the code side of the port. Maybe ask the dev ML for volunteers?
19.06.12 #       <speachy> pushed new builds.
19.07.17 #       <gevaerts> Now we just wait for the next regular commit to see what that does for us :)
19.08.40 #       <speachy> also fixed a FTB regression on the jz4740 targets.  could have sworn I build-tested before pushing the commit that broke it..
19.09.58 #       <speachy> hmm.  I can host a builder if that will help.
19.10.25 #       <gevaerts> That's always helpful. We naver have too many of them!
19.11.06 #       <gevaerts> https://www.rockbox.org/wiki/BuildClient has the documentation
19.12.22 #       <speachy> might as well keep those idle cores doing something useful
19.13.30 #       <speachy> so the toolchains need to be installed manually.  okay.
19.14.19 #       <gevaerts> Well, depends
19.14.32 #       <gevaerts> The client doesn't install them for you, if that's what you mean
19.20.15 #       <speachy> would be really cool if this could be tied into gerrit.
19.29.18 Join    lebellium [0] (~lebellium@89-92-69-7.hfc.dyn.abo.bbox.fr)
19.35.06 Join    terminalator [0] (terminalat@gateway/vpn/privateinternetaccess/terminalator)
19.36.15 #       <Bilgus> its hard enough to keep the status quo let alone add more :p
19.36.32 #       <speachy> aye..
19.41.01 Quit    speachy (Ping timeout: 256 seconds)
19.43.31 Join    dandels [0] (~dandels@unaffiliated/dandels)
19.53.51 Quit    mikroflops (Ping timeout: 250 seconds)
19.55.51 Join    mikroflops [0] (~yogurt@c83-255-23-64.bredband.comhem.se)
19.58.01 Quit    lebellium (Quit: Leaving)
19.58.59 Quit    dandels (Ping timeout: 252 seconds)
20.13.18 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
20.15.22 Join    lebellium [0] (~lebellium@89-92-69-7.hfc.dyn.abo.bbox.fr)
20.20.07 Quit    TheLemonMan (Quit: "It's now safe to turn off your computer.")
20.25.35 Join    speachy [0] (d98c6f87@gateway/web/freenode/ip.217.140.111.135)
20.26.14 #       <speachy> http://gerrit.rockbox.org/r/#/c/1931/
20.26.39 #       <speachy> here's a rather ugly patch that I think should fix all of the FTBs due to the codec stack size bump.
20.27.08 #       <speachy> blanket exclude coldfire, and anything that has small IRAM.
20.27.46 #       <speachy> build tested on a couple of arm (some formerly working, some broken) and mips
20.29.58 ***     Saving seen data "./dancer.seen"
20.40.03 #       <Bilgus> speachy why not just #if defined(IRAMSIZE) && IRAMSIZE > (32 * 1024)?
20.47.27 #       <Bilgus> or even #if !defined(CPU_COLDFIRE) && (MEMORYSIZE < 8) && defined(IRAMSIZE) && IRAMSIZE > (32 * 1024)
20.47.27 #       <Bilgus>     #define WORKAROUND_FS13060 0x800
20.47.27 #       <Bilgus> #else
20.47.27 DBUG    Enqueued KICK Bilgus
20.47.27 #       <Bilgus>     #define WORKAROUND_FS13060 0
20.47.27 #       <Bilgus> #endif
20.47.46 Quit    foolsh (Remote host closed the connection)
20.47.57 #       <Bilgus> I still don't like it but its not as ugly
20.51.23 #       <Bilgus> ..(MEMORYSIZE >= 8)
20.55.50 #       <speachy> I had soemthign similar earlier but iirc if IRAMSIZE wasn't defined it generated a warning
20.56.56 Quit    this_is_a_nick (Remote host closed the connection)
20.57.27 #       <speachy> will try that again
20.57.36 #       <Bilgus> parens then (defined(IRAMSIZE) && IRAMSIZE > (32 * 1024))
20.58.57 #       <speachy> building...
20.58.58 #       <speachy> ...
21.00.22 #       <speachy> so far so good.  I think that will work.
21.00.34 #       <Bilgus> mm pamaury gave me a build script that builds all or select targets for building against all targets when I was messing with the action system
21.00.59 #       <Bilgus> that way I could run it on my end before pushing it to the build system
21.01.34 #       <speachy> I don't have the m68k toolchain built yet
21.02.03 #       <speachy> the limitation here is cpu cores.  doing this on my laptop.
21.02.16 #       <speachy> so it just takes time to do the builds I want.
21.02.28 #       <speachy> updated patch pushed
21.03.02 #       <Bilgus> ahh well here it is anyways its been altered a bit https://pastebin.com/tAFRAkax
21.05.00 Quit    lebellium (Read error: Connection reset by peer)
21.05.03 #       <speachy> I keep build trees for all hardware I own, plus a couple of problematic builds
21.05.17 #       <speachy> heh, whether or not the hardware still _works_.
21.05.31 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
21.05.31 #       * speachy glares at the pile of broken dreams.
21.05.56 #       <Bilgus> same it comes in handy from time to time
21.07.50 #       <Bilgus> my beast quad core rig died a few weeks ago so I went back to a core2 quad I had lying around so builds take ages now or at least what feels like ages
21.12.28 Join    krabador [0] (~krabador@unaffiliated/krabador)
21.15.38 #       <speachy> so the patch looks sane, for what it is?
21.16.24 #       <Bilgus> oh I hate it but yeah I mean one way to know for sure right?
21.18.05 #       <Bilgus> I tried looking into opus a while back and other codecs for that matter they have a steep learning curve to say the least
21.18.26 #       <Bilgus> so I guess a hack is better than crashing..
21.20.47 #       <speachy> yeah, it seems to be the last worst option
21.20.53 #       <speachy> er, least
21.22.07 #       <speachy> codec code is its own special kind of hell.
21.33.03 #       <speachy> a lot of places in the opus code where gcc claims stack usage could be unbounded
21.38.46 Nick    tomb is now known as tomf (~tomflint@unaffiliated/tomflint)
21.42.28 Quit    krabador (Remote host closed the connection)
21.43.18 Join    krabador [0] (~krabador@unaffiliated/krabador)
21.51.05 #       <speachy> there are 648 bytes of stack usage that can be easily saved.  shouldn't hurt performance by an apprciable amount either as it's not in hot code paths
22.00.29 #       * Bilgus wonders whats changed in opus since 2012
22.05.59 #       <speachy> well, for one opus has gone through IETF standardization..
22.07.01 #       <speachy> our snapshot was at the opus 1.0.1 timeframe.
22.07.22 #       <speachy> shortly after the libopus 1.0.1 release
22.09.05 Join    this_is_a_nick [0] (~amofiuhr_@201.206.191.80)
22.29.59 ***     Saving seen data "./dancer.seen"
22.33.24 #       <speachy> hmm.  looks like we really didn't change much in libopus.  partially done with a re-import.
22.33.28 #       <speachy> anyway.  gotta scoot.
22.33.31 Quit    speachy ()
22.47.48 Join    foolsh [0] (~foolsh@2601:249:4100:c338:142a:33ad:2a51:5246)
22.57.59 Quit    krabador (Remote host closed the connection)
22.58.47 Join    krabador [0] (~krabador@unaffiliated/krabador)
23.16.31 Quit    pamaury (Ping timeout: 252 seconds)
23.17.45 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
23.18.21 Join    lebellium [0] (~lebellium@89-92-69-7.hfc.dyn.abo.bbox.fr)
23.23.22 Join    pamaury_ [0] (~pamaury@rockbox/developer/pamaury)
23.23.32 Quit    pamaury (Ping timeout: 268 seconds)
23.24.52 Quit    lebellium (Quit: Leaving)
23.44.05 Join    dandels [0] (~dandels@unaffiliated/dandels)
23.46.35 Quit    pamaury_ (Ping timeout: 244 seconds)