--- Log for 27.07.120  Server: tolkien.freenode.net  Channel: #rockbox
--- Nick: logbot_  Version: Dancer V4.16  Started: 12 days and 13 hours ago

00.13.52 #       <fs-bluebot> Build Server message: Build round completed after 1074 seconds.
00.13.54 #       <fs-bluebot> Build Server message: Revision a898f36 result: 2 errors 0 warnings
00.15.53 #       <mendel_munkis> Strife89: you may want to check saanaitos' logs.
00.23.06 ***     Saving seen data "./dancer.seen"
00.25.22 Quit    jdarnley (Ping timeout: 260 seconds)
00.27.08 Join    J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
01.18.05 #       <speachy> I'm mostly done with a partial rewrite of genlang; I've split out the "update" code to be a lot smarter
01.19.11 #       <speachy> a lot of tooling relies on the update code to flag errors; this will result in more accurate error flagging and smarter deletions of old stuff.
01.20.36 #       <speachy> a few more things to fix up before I can commit it and update the other tooling (most notably the translate site) to key off things
01.56.50 Join    advcomp2019_ [0] (~advcomp20@65-131-149-233.sxct.qwest.net)
01.56.50 Quit    advcomp2019_ (Changing host)
01.56.50 Join    advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
02.00.06 Quit    advcomp2019__ (Ping timeout: 260 seconds)
02.17.02 #       <mendel_munkis> speachy: I think I hit the rtc bug so I will test the fix now.
02.23.07 ***     Saving seen data "./dancer.seen"
03.00.12 Join    APLU [0] (~mulx@eva.aplu.fr)
03.00.38 Join    S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
03.01.26 Join    ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
03.09.53 #       <mendel_munkis> speachy: looks like the bug cause is PERSISTENT0 getting reset for some reason.
03.10.58 #       <mendel_munkis> I'm working on a set of sane initialization values, and wondering does it make sense to shutdown if the clock stops?
03.25.03 Quit    pixelma (Quit: .)
03.25.03 Quit    amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
03.26.27 Quit    S|h|a|w|n (Read error: Connection reset by peer)
03.26.28 Join    pixelma [0] (marianne@rockbox/staff/pixelma)
03.26.29 Join    amiconn [0] (jens@rockbox/developer/amiconn)
03.26.56 Join    S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
03.50.56 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
03.54.49 Quit    sakax (Remote host closed the connection)
03.59.14 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
04.23.08 ***     Saving seen data "./dancer.seen"
05.48.58 Quit    S|h|a|w|n (Read error: Connection reset by peer)
06.08.11 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
06.23.11 ***     Saving seen data "./dancer.seen"
06.34.32 Quit    TorC (Ping timeout: 260 seconds)
06.35.23 Join    TorC [0] (~Tor@fsf/member/TorC)
06.35.35 Join    Marqueteur [0] (~Tor@fsf/member/TorC)
06.35.35 Quit    TorC (Killed (orwell.freenode.net (Nickname regained by services)))
06.35.36 Nick    Marqueteur is now known as TorC (~Tor@fsf/member/TorC)
06.35.52 Nick    TorC is now known as Guest6745 (~Tor@fsf/member/TorC)
06.35.53 Join    Marqueteur [0] (~Tor@fsf/member/TorC)
06.35.53 Quit    Guest6745 (Killed (egan.freenode.net (Nickname regained by services)))
06.35.53 Nick    Marqueteur is now known as TorC (~Tor@fsf/member/TorC)
06.36.05 Join    Marqueteur [0] (~Tor@fsf/member/TorC)
06.36.06 Nick    TorC is now known as Guest17474 (~Tor@fsf/member/TorC)
06.36.06 Nick    Marqueteur is now known as TorC (~Tor@fsf/member/TorC)
06.48.33 Nick    TorC is now known as marqueteur (~Tor@fsf/member/TorC)
06.48.51 Nick    marqueteur is now known as Marqueteur (~Tor@fsf/member/TorC)
06.51.29 Nick    Marqueteur is now known as regain (~Tor@fsf/member/TorC)
06.51.37 Nick    regain is now known as TorC (~Tor@fsf/member/TorC)
06.54.22 Quit    Guest17474 (Ping timeout: 260 seconds)
08.04.52 #       <Strife89> mendel_munkis: Sorry, I'm not sure what I should be looking for.
08.05.48 #       <Strife89> But here's a paste of rbclient.log for the time range of that build round. https://www.irccloud.com/pastebin/rAb7XHyb/
08.23.13 ***     Saving seen data "./dancer.seen"
09.16.52 Quit    St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
09.27.13 Join    St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
09.35.24 Quit    __Bilgus_ (Remote host closed the connection)
09.58.59 #       <speachy> Strife89, the point being that your builder process can't successfully do the NDK-based build in whatever environment it uses.
10.01.25 Quit    massiveH (Quit: Leaving)
10.09.37 #       <speachy> okay!  So.  all rockbox.org services are going to be offline for a couple of hours tomorrow to do an OS update on the server.  I finally have permission to physically access $dayjob lab.
10.10.44 Quit    JanC (Remote host closed the connection)
10.11.06 Join    JanC [0] (~janc@lugwv/member/JanC)
10.13.44 #       <speachy> still waiting on confirmation of the time.
10.23.17 ***     Saving seen data "./dancer.seen"
10.25.04 #       <speachy> sorry about the short notice, but I've been trying to get access for a month now.
10.37.31 #       <speachy> okay, starting about 1200 EST (GMT-4)
10.52.49 #       <Strife89> speachy, mendel_munkis: Ahh, sorry about that! Will fix when I return home.
10.55.03 Join    __BIlgus_ [0] (41ba23be@65.186.35.190)
10.57.14 #       <__BIlgus_> I think some day we should work on putting key mapping into core
10.57.30 #       <speachy> Bilgus, oh god yes.
10.57.32 #       <__BIlgus_> thatd get rid of a lot of complexity
10.59.51 #       <mendel_munkis> __BIlgus_: are you saying something along the lines of making pla a core library?
11.00.14 #       <speachy> I just need to get my head out of this multilingual hell first.
11.01.17 #       <__BIlgus_> mm no more like a list of rockbox keys and either specifying a key in a cfg file or have the user press the button(s) on the player they would like to use
11.01.53 #       <__BIlgus_> so say play i want to be up and select on my device
11.02.26 #       <__BIlgus_> i go into the menu find PLAY select it and it gives me 3 seconds to do a key combo
11.04.11 #       <__BIlgus_> you could have it on first start too Thanks for choosing Rockbox please take a few moments to set up key mapping for your device
11.04.25 #       <speachy> welll.. I'd like there to be sane-ish defaults for a given player.
11.04.37 #       <__BIlgus_> of course
11.04.45 #       <speachy> where IMO this really will help is in the plugins.
11.05.01 #       <__BIlgus_> but what you do is start it with no key mapping and make the default cfg file
11.05.29 #       <__BIlgus_> then its its current setting in the button files
11.05.55 #       <__BIlgus_> bootstrap your button maps
11.07.07 #       <__BIlgus_> hmm if you can't read from disk you can't read a cfg file though
11.07.19 #       <__BIlgus_> so yeah it'd still have to be static in core
11.07.24 #       <mendel_munkis> although that would lose the ability to set buttons on a per device usage basis.
11.07.53 #       <__BIlgus_> explain more plz.
11.10.00 #       <mendel_munkis> right now it's easy to change for example which key shoots in doom on the clipzip. with this change I can change which key shoots+does other stuff on the clipzip or which key shoots in doom on every target.
11.12.03 #       <__BIlgus_> wouldn't be too hard to make a prompt pop to ask user to map keys on plugin entry
11.13.12 #       <mendel_munkis> but at that point you are losing a bunch of the benefit by having all the keymaps for all the uses again, except now they have to be read from file instead of being static.
11.13.40 #       <__BIlgus_> everything is in ram anyways..
11.14.15 #       <__BIlgus_> once you load or save a key map its file is not used again till next reboot
11.15.20 #       <mendel_munkis> __BIlgus_: if I stop playing doom move to quake and then go back to doom it won't need to reload the keymap?
11.15.55 #       <__BIlgus_> oh most assuredly but its already loading the plugin from disk so nbd here
11.16.16 #       <__BIlgus_> its not a big file either
11.16.33 #       <mendel_munkis> I just think you're replacing existing complexity with different complexity is all.
11.16.55 #       <__BIlgus_> perhaps but it makes it easier for users
11.17.22 #       <mendel_munkis> ok I would think it makes it harder but that's just me.
11.17.26 #       <__BIlgus_> we ask people to download a toolchain and compile their own for changing what keys do
11.17.44 #       <mendel_munkis> fair enough.
11.18.00 #       <__BIlgus_> or roll it into rbutil
11.18.12 #       <__BIlgus_> build them into the install
11.19.44 #       <mendel_munkis> If I have a register that needs to be initialized after a power loss (totally dead battery) does it make sense to stick the value into the initialization function for the relevant hardware or put it somewhere o the debug screen?
11.21.46 #       <__BIlgus_> i'm not seeing the equivalency between those two options but if its needed for the hardware then keep it close to the init
11.23.05 #       <mendel_munkis> __BIlgus_: the hardware will run without it just suboptimally and putting it in init means  more startup delay.
11.24.01 #       <__BIlgus_> phones take 2 minutes to start-up how much start-up delay are we talking
11.24.50 #       <__BIlgus_> and define suboptimally, that should be reason enough
11.25.10 #       <mendel_munkis> I personally notice delays on the order of 50 ms and am a firm believer that the more delays you add the more noticable the total is.
11.25.34 #       <__BIlgus_> is this in a plugin or in core?
11.25.39 #       <mendel_munkis> core.
11.25.48 #       <mendel_munkis> rtc driver to be exact
11.26.40 #       <__BIlgus_> at startup you have a boot logo, you don't need rtc to do a boot logo so do it after the boot logo?
11.27.19 #       <__BIlgus_> if it takes 30 seconds do a progress bar if its less tahn that no one will notice after a week
11.28.11 #       <mendel_munkis> sure but it takes 31 seconds people will still be complaining years later.
11.29.05 #       <__BIlgus_> depends on what the sub optimal part is
11.32.27 #       <mendel_munkis> mostly the clock stopping when powered off. (also possibly a slight affect on audio pops)
12.08.12 #       <__BIlgus_> both of those are worth 31 seconds
12.23.21 ***     No seen item changed, no save performed.
12.30.28 Join    advcomp2019 [0] (~advcomp20@65-131-149-233.sxct.qwest.net)
12.30.28 Quit    advcomp2019 (Changing host)
12.30.28 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
12.32.04 Join    advcomp2019__ [0] (~advcomp20@65-131-149-233.sxct.qwest.net)
12.32.04 Quit    advcomp2019__ (Changing host)
12.32.04 Join    advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019)
12.33.40 Quit    advcomp2019_ (Ping timeout: 256 seconds)
12.35.25 Quit    advcomp2019 (Ping timeout: 240 seconds)
13.08.53 #       <speachy> so, I have g#2596 ready.
13.08.55 #       <fs-bluebot> Gerrit review #2596 at http://gerrit.rockbox.org/r/2596 : updatelang:  New tool to update language files. by Solomon Peachy
13.09.50 #       <fs-bluebot> Build Server message: New build round started. Revision aee6459, 280 builds, 10 clients.
13.12.44 Join    lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr)
13.13.04 #       <speachy> the new tool properly cleans up deleted phrases or targets from kept phrases
13.15.47 Join    MrZeus_ [0] (~MrZeus@4e6942be.skybroadband.com)
13.23.23 #       <fs-bluebot> Build Server message: Build round completed after 813 seconds.
13.23.27 #       <fs-bluebot> Build Server message: Revision aee6459 result: All green
13.23.28 #       <fs-bluebot> Build Server message: New build round started. Revision c81e1e1, 280 builds, 9 clients.
13.23.59 #       <speachy> and properly warns about many more potential problem areas that the existing one misses
13.27.57 Join    rey [0] (~reymond@unaffiliated/reymond)
13.28.32 #       <rey> nice. didnt know rockbox was here
13.37.12 #       <fs-bluebot> Build Server message: Build round completed after 825 seconds.
13.37.13 #       <fs-bluebot> Build Server message: Revision c81e1e1 result: All green
13.51.45 #       <__BIlgus_> I think the Voice plugin is pretty much finished, I'm going to add another patch that allows assigning plugins to the WPS hotkey
13.52.25 #       <__BIlgus_> I think it needs a different name though
13.54.36 Quit    michaelni (Quit: Leaving)
13.55.05 Join    michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at)
13.55.27 Join    krabador [0] (~krabador@unaffiliated/krabador)
14.23.25 ***     Saving seen data "./dancer.seen"
14.41.30 #       <rey> Whenever you enable/disable the "shuffle" option in rockbox, does that reshuffle the folder completely every time or is it just a one time shuffle?
14.49.37 #       <mendel_munkis> rey: it's a new shuffle every time
15.03.26 #       <fs-bluebot> Build Server message: New build round started. Revision 2305966, 280 builds, 9 clients.
15.10.40 #       <fs-bluebot> Build Server message: Build round completed after 434 seconds.
15.10.41 #       <fs-bluebot> Build Server message: Revision 2305966 result: 1136 errors 0 warnings
15.10.42 #       <fs-bluebot> Build Server message: New build round started. Revision 632385a, 280 builds, 10 clients.
15.11.32 #       <speachy> well, <expletive>
15.16.28 #       <fs-bluebot> Build Server message: Build round completed after 347 seconds.
15.16.30 #       <fs-bluebot> Build Server message: Revision 632385a result: 1076 errors 0 warnings
15.19.05 #       <fs-bluebot> Build Server message: New build round started. Revision 8159c95, 280 builds, 10 clients.
15.19.38 #       <speachy> had to rework that a little to not rely on non-core perl modules.
15.21.00 #       <rey> thank you @ mendel_munkis
15.21.04 Part    rey
15.21.24 Quit    sakax (Remote host closed the connection)
15.24.45 Quit    __BIlgus_ (Remote host closed the connection)
15.26.10 Quit    nihilazo (Quit: authenticating)
15.26.29 Join    nihilazo1 [0] (nihilazoma@gateway/shell/matrix.org/x-mgkzgpytpxzgrnzj)
15.33.57 #       <fs-bluebot> Build Server message: Build round completed after 892 seconds.
15.33.58 #       <fs-bluebot> Build Server message: Revision 8159c95 result: All green
15.36.57 #       <mendel_munkis> speachy: I am assuming we want power off on rtc crystal failure on applicibale devices?
15.37.13 #       <mendel_munkis> "the most likely cause being brownout"
15.37.32 #       <speachy> I suspect in that case the rest of the player would have crapped out by then
15.38.09 #       <mendel_munkis> so turn it off so that if just the crystal fails the device still works?
15.43.47 #       <speachy> generally the RTC isn't critical to normal operatio
15.44.20 #       <mendel_munkis> I agree. I  just assumed that a rtc failure is generally symptomatic.
15.50.08 #       <Strife89> mendel_munkis: It was just saanaito with the ndk failures, right?
15.50.28 #       <mendel_munkis> that's the only one that I noticed.
15.51.04 #       <mendel_munkis> I just checked because there waw one failed build and I wanted to make sure it wasn't my machine.
15.51.08 #       <Strife89> eefi and ranpuraa should also be set up for ndk building
15.51.12 #       <Strife89> Ahh, okay
15.51.51 #       <Strife89> I apologise for that, because I'm sure it held up the build round
15.52.19 #       <Strife89> +s
16.21.38 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
16.23.26 ***     Saving seen data "./dancer.seen"
16.49.41 #       <mendel_munkis> speachy: do you mind taking a look at g#2601?
16.49.43 #       <fs-bluebot> Gerrit review #2601 at http://gerrit.rockbox.org/r/2601 : imx233:  rtc:  Initialize PERSISTENT0 register by Moshe Piekarski
16.56.34 #       <fs-bluebot> Build Server message: New build round started. Revision cda5b05, 280 builds, 11 clients.
16.57.37 #       <speachy> mendel_munkis, why set that persistent register?
16.58.26 #       <speachy> aaand once this commit finishes working its way through, the translation site should be working again, with much moar better-er functionality.
17.02.46 #       <mendel_munkis> because their values when reset aren't what rockbox expects. the most important field being bit 4 which controls wether the rtc runs while the device is powered down.
17.03.11 #       <speachy> ah, okay.  I thought it was just an arbitrary data register
17.03.50 Join    jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
17.03.55 #       <mendel_munkis> as far as I can tell its a control register which is meant to be persistent across power cycles.
17.05.58 Quit    J_Darnley (Ping timeout: 265 seconds)
17.06.49 #       <speachy> or at least as long as there's a power source.  :)
17.08.14 #       <fs-bluebot> Build Server message: Build round completed after 701 seconds.
17.08.16 #       <fs-bluebot> Build Server message: Revision cda5b05 result: All green
17.08.17 #       <fs-bluebot> Build Server message: New build round started. Revision 7f282b9, 280 builds, 11 clients.
17.20.29 #       <fs-bluebot> Build Server message: Build round completed after 733 seconds.
17.20.31 #       <fs-bluebot> Build Server message: Revision 7f282b9 result: All green
17.22.47 #       <fs-bluebot> Build Server message: New build round started. Revision b9d13b8, 280 builds, 10 clients.
17.34.54 Quit    lebellium (Quit: Leaving)
17.35.10 #       <fs-bluebot> Build Server message: Build round completed after 744 seconds.
17.35.13 #       <fs-bluebot> Build Server message: Revision b9d13b8 result: All green
17.42.57 Quit    sakax (Quit: Leaving)
17.58.10 Quit    jdarnley (Ping timeout: 265 seconds)
18.01.17 Join    J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
18.23.30 ***     Saving seen data "./dancer.seen"
18.24.36 Join    S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
18.29.52 Quit    ac_laptop (Quit: WeeChat 2.8)
18.30.12 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
18.33.59 #       <speachy> __Bilgus_, commit bf546fbfcb is breaking sound settings from being saved.  And possibly others too.
18.37.23 Join    cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
18.42.38 #       <fs-bluebot> Build Server message: New build round started. Revision 3f828e9, 280 builds, 10 clients.
18.43.17 #       <speachy> I'm more or less reverting it, because there are surely other intsetting icebergs that similarly lack limits configured
18.55.39 #       <fs-bluebot> Build Server message: Build round completed after 781 seconds.
18.55.41 #       <fs-bluebot> Build Server message: Revision 3f828e9 result: All green
19.21.50 Quit    krabador (Remote host closed the connection)
19.35.23 Join    __BIlgus_ [0] (41ba23be@65.186.35.190)
19.35.58 #       <__BIlgus_> speachy that doesn't surprise me at this point tbh
19.48.59 Quit    MrZeus_ (Ping timeout: 240 seconds)
20.03.32 #       <speachy> still need to figure out why my player panic'd when I tried to hit a directory larger than the configured limit
20.03.44 #       <speachy> it's supposed to error out gracefully
20.04.29 #       <speachy> anyway!  The translation page is working well now; many more errors/issues are now properly flagged, and stuff that can easily be corrected is automagically handled.
20.06.17 #       <speachy> oh, again, the server's going offline from roughly noon tomorrow (GMT-4) for an hour or two.  overdue OS updates.
20.23.34 ***     Saving seen data "./dancer.seen"
20.31.29 #       <__BIlgus_> i'm going to push announce_status.c if someone would test it out and give some feedback it'd be appreciated
20.33.25 Quit    J_Darnley (Ping timeout: 240 seconds)
20.37.04 Join    J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
20.42.12 #       <speachy> probably won't be able to do so until tomorrow but sure
20.43.06 #       <__BIlgus_> i'll work on the hotkey integration next I have some plans for that one
20.44.39 #       <__BIlgus_> after that I think it should open the door to cutom wps plugins and all kinds of neat things
20.46.45 Quit    ZincAlloy (Quit: Leaving.)
20.51.07 Quit    Strife89 (Ping timeout: 240 seconds)
20.51.18 Join    Strife89 [0] (sid399903@gateway/web/irccloud.com/x-jufepegjoeamjhuc)
20.51.27 #       <fs-bluebot> Build Server message: New build round started. Revision be04c4b, 280 builds, 12 clients.
21.10.25 Quit    ac_laptop (Ping timeout: 240 seconds)
21.11.02 #       <fs-bluebot> Build Server message: Build round completed after 1175 seconds.
21.11.04 #       <fs-bluebot> Build Server message: Revision be04c4b result: 271 errors 0 warnings
21.11.05 #       <fs-bluebot> Build Server message: New build round started. Revision 5e72616, 280 builds, 12 clients.
21.18.41 #       <speachy> __Bilgus_, I pushed a change to fix the red.   But there's a build or still queued up
21.20.13 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
21.20.28 #       <speachy> what I find more worrisome is that most of the builds succeeded.
21.25.36 #       <__BIlgus_> How in the hell did that not show errors when I built it??
21.26.01 Quit    ac_laptop (Ping timeout: 264 seconds)
21.26.44 #       <fs-bluebot> Build Server message: Build round completed after 940 seconds.
21.26.46 #       <fs-bluebot> Build Server message: Revision 5e72616 result: 261 errors 0 warnings
21.26.47 #       <fs-bluebot> Build Server message: New build round started. Revision fbe557d, 280 builds, 11 clients.
21.27.00 #       <speachy> some targets succeeded, strangely enough.
21.27.47 #       <speachy> this build will fail too, but the one after this will succeed
21.32.06 #       <__BIlgus_> ok I'll wait and see, still weird that blur between core and plugins worked on my end
21.34.16 #       <speachy> for hosted targets, sleep() is a standard syscall.  but that doesn't explain all of the ones tht worked.
21.40.20 Quit    cockroach (Quit: leaving)
21.42.04 Join    Huntereb [0] (~Huntereb@174.226.12.194)
21.43.49 #       <fs-bluebot> Build Server message: Build round completed after 1024 seconds.
21.43.52 #       <fs-bluebot> Build Server message: Revision fbe557d result: 264 errors 0 warnings
21.43.52 #       <fs-bluebot> Build Server message: New build round started. Revision e168134, 280 builds, 9 clients.
21.45.10 #       <speachy> this one should make the board green
21.58.58 #       <fs-bluebot> Build Server message: Build round completed after 907 seconds.
21.59.01 #       <fs-bluebot> Build Server message: Revision e168134 result: All green
22.18.44 #       <fs-bluebot> Build Server message: New build round started. Revision f30f1bb, 280 builds, 9 clients.
22.18.56 #       <__BIlgus_> yay! \o
22.23.36 ***     Saving seen data "./dancer.seen"
22.34.45 #       <fs-bluebot> Build Server message: Build round completed after 961 seconds.
22.34.46 #       <fs-bluebot> Build Server message: Revision f30f1bb result: All green
22.37.14 #       <fs-bluebot> Build Server message: New build round started. Revision 9e2ecee, 280 builds, 9 clients.
22.48.27 #       <Strife89> Seems like my clients have been timing out more often, lately
22.49.32 #       <Strife89> saanaito appears to be stuck on "Unpacking objects:  60% (3/5)"
22.49.52 #       <fs-bluebot> Build Server message: Build round completed after 758 seconds.
22.49.54 #       <fs-bluebot> Build Server message: Revision 9e2ecee result: 0 errors 133 warnings
22.50.41 #       <Strife89> Yep, it stalled
22.51.29 #       <Strife89> I have this sinking feeling that my clients are all doing more harm than good
23.04.14 Quit    __BIlgus_ (Ping timeout: 245 seconds)
23.26.12 #       <fs-bluebot> Build Server message: New build round started. Revision 7f27d2d, 280 builds, 10 clients.
23.27.53 Quit    [7] (Ping timeout: 244 seconds)
23.28.23 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
23.37.02 Quit    Huntereb (Read error: Connection reset by peer)
23.40.40 #       <fs-bluebot> Build Server message: Build round completed after 868 seconds.
23.40.41 #       <fs-bluebot> Build Server message: Revision 7f27d2d result: All green