| 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:00 |
| 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:00 |
| 02:29:34 | *** | Saving seen data "./dancer.seen" |
| 02:41:22 | | Quit krabador (Remote host closed the connection) |
| 03:00 |
| 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:00 |
| 04:29:37 | *** | Saving seen data "./dancer.seen" |
| 04:32:33 | | Quit foolsh (Read error: Connection reset by peer) |
| 05:00 |
| 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:00 |
| 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:00 |
| 07:01:28 | | Join pR0Ps [0] (~pR0Ps@216.154.8.105) |
| 08:00 |
| 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:00 |
| 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:00 |
| 10:15:32 | | Quit defterade (Ping timeout: 252 seconds) |
| 10:29:46 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 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:00 |
| 12:04:27 | | Quit dandels (Ping timeout: 244 seconds) |
| 12:29:49 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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 |
| 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 |
| 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:00 |
| 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) |
icon identifies that the person is a core developer (has commit access).