--- Log for 10.08.121 Server: lithium.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 14 hours and 0 minutes ago 00.07.31 *** Saving seen data "./dancer.seen" 01.35.50 Quit j-r (Ping timeout: 252 seconds) 01.36.57 Join j-r [0] (~j-r@p20030006215aee45404207fffefd0a65.dip0.t-ipconnect.de) 02.07.35 *** Saving seen data "./dancer.seen" 03.39.59 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 04.04.34 Nick mendel_munkis is now known as munkis (~mendel_mu@ool-ae2cb218.dyn.optonline.net) 04.04.58 Quit tomato (Ping timeout: 272 seconds) 04.07.36 *** Saving seen data "./dancer.seen" 05.49.43 Join tomato [0] (~tomato@user/tomato) 06.03.29 Join pablocastellanos [0] (~pidgin@user/pablocastellanos) 06.07.39 *** No seen item changed, no save performed. 06.14.49 # ok, so I tried to build the manual. Fails because 332433eb3d9 changed \ifpdfoutput to \Ifpdfoutput -- what is that package? Couldn't find anything about \Ifpdfoutput, only \ifpdfoutput 06.41.33 # ok, found some info on it. It's been changed in KOMAscript. Debian buster ships 3.25, while this was changed in 3.28. 06.57.34 # yeah, newer pdflatex needs the latter, older needs the former. 06.58.03 # IIRC I committed that change when the server's version got updated to one that needed the latter syntax. 07.00.21 # too bad the commit message isn't really clear about that ... 07.00.52 # it was discussed in IRC but yeah, I should have asked for a more verbose commit message. 07.00.52 # anyway, came across another issue: in the credits list at least one name is missing (the same I had issues with when looking into Sphinx) 07.01.06 # character encoding issue? 07.01.10 # yes. 07.01.41 # with Sphinx I get lots of warnings from LaTeX about encoding, with our current setup I don't see any warnings. But looking into the pdf the name simply doesn't exist 07.02.57 # oh. Seems our credits.pl strips that, so no issue with LaTeX. 07.05.39 # yep, that's it. The first character isn't ASCII, so the regex doesn't match it. Turns out to also apply to some more names. 07.22.14 # Build Server message: 3New build round started. Revision 4fb5aeb096, 303 builds, 8 clients. 07.38.06 # Build Server message: 3Build round completed after 952 seconds. 07.38.07 # Build Server message: 3Revision 4fb5aeb096 result: 4 errors 0 warnings 07.39.25 # <_bilgus_> :/ 07.40.36 # <_bilgus_> uh oh /home/rbbuild/x-tools/rockbox/lib/gcc/m68k-elf/4.9.4/../../../../m68k-elf/bin/ld: /home/rbbuild/rockbox/build-iaudiom5/rockbox.elf section `.stack' will not fit in region `IRAM' 07.41.12 # _bilgus_: what'd you chnage? 07.41.58 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) 07.42.49 # hm. 07.43.56 # <_bilgus_> its tight apparently 07.44.32 # _bilgus_: why'd you cast the void*? that's usually unneeded. 07.45.16 # hm. 07.45.33 # so what changed? code size? stack size? both? 07.46.01 # i'm leaning towards code size since the compiler is probably using registers 07.46.31 # <_bilgus_> yep its the same size but not.. 07.47.01 # <_bilgus_> I've been checking asm and this is as close as I got 07.47.03 Join yang-idl1 [0] (~yang@199.189.205.50) 07.47.19 # <_bilgus_> I'll try messing with the m5 direct 07.47.50 Join dys [0] (~dys@user/dys) 07.47.55 # yeah, the m5 has given us plenty of grief before 07.48.05 # _bilgus_: did you consider trying something a bit different? 07.48.21 Join emacsoma1 [0] (~emacsoman@136.60.128.68) 07.48.24 # hm 07.48.31 # nevermind, probably wouldn't help 07.48.51 # <_bilgus_> a bit different ranged from 10-30 more instructions 07.49.11 # i wonder what would happen if you tried changing the optimization level 07.49.17 # <_bilgus_> open to suggestions 07.49.22 # i've sometimes found -O2 actually beats -Os in some cases 07.49.36 # _bilgus_: IIRC the last time this happened we "fixed" it by shrinking the stack slightly. 07.49.36 # but that's probably a big hack on its own 07.49.45 # <_bilgus_> I can probably find 16 bytes 07.50.08 # <_bilgus_> if not they will start sharing code 07.50.18 # <_bilgus_> which maybe I should do 07.50.24 # <_bilgus_> anyway.. 07.50.41 # speachy: sounds like most coldfire is a royal PITA. 07.50.56 # speachy: and only the iriver ones are common these days to find availablbe 07.51.18 # braewoods: due to crappy caches we have to put critical code into IRAM if it has a hope of being performant 07.51.32 # so IRAM is basically coldfire's fast ram 07.51.35 # and the X5 has a bit more than most, due to its features 07.51.54 Quit emacsomancer (*.net *.split) 07.51.55 Quit benjaoming (*.net *.split) 07.51.55 Quit markun_ (*.net *.split) 07.51.55 Quit advcomp2019__ (*.net *.split) 07.51.56 Quit tomato (*.net *.split) 07.51.56 Quit Piece_Maker (*.net *.split) 07.51.57 Quit ufdm (*.net *.split) 07.51.57 Quit blbro[m] (*.net *.split) 07.51.57 Quit danwellby (*.net *.split) 07.51.57 Quit hook54321 (*.net *.split) 07.52.00 Quit gevaerts (*.net *.split) 07.52.00 Quit michaelni (*.net *.split) 07.52.00 Quit yang-idle (*.net *.split) 07.52.00 Quit spork (*.net *.split) 07.52.00 Quit TorC (*.net *.split) 07.52.00 Quit pixelma (*.net *.split) 07.52.00 Quit ats (*.net *.split) 07.52.00 Quit Xeha (*.net *.split) 07.52.00 Quit vup (*.net *.split) 07.52.02 Quit rudi_s (*.net *.split) 07.52.03 Quit kirvesAxe (*.net *.split) 07.52.03 Quit jschwart (*.net *.split) 07.52.03 Quit reductum (*.net *.split) 07.52.03 Quit Arsen (*.net *.split) 07.52.04 # IRAM is usually memory that's capable of running at full processor speed; ie no wait states 07.52.06 # vs external RAM that's a lot slower 07.52.06 # ugh. net split. 07.52.22 # caches hide that latency a lot 07.52.45 # is that the main reason linked lists have turned into performance dogs today? 07.52.51 # they're not very cache friendly. 07.53.14 Join benjaoming [0] (~benjaomin@37.139.19.237) 07.53.14 Join markun_ [0] (~markun@178-84-100-63.dynamic.upc.nl) 07.53.18 # at least on systems where cache misses are a serious issue 07.53.28 # they don't scale up well, but all data structures are exercises in tradeoffs 07.53.42 # indeed, i usually use arrays today where i can. 07.53.56 # <_bilgus_> woot 07.53.57 # you can't slice and dice elements into/out of arrays though 07.54.05 # i know. it's a tradeoff. 07.54.16 # speachy: well, you can in sparse arrays. but yea. 07.54.28 # sparse arrays aren't exactly cache friendly either. :D 07.54.49 # i know, mostly just convience of having a global lookup table of sorts you can access quickly 07.55.24 # arrays of pointers are also problematic but they are good for quick rearrangement of data 07.55.38 # cost of copying is greatly reduced 07.56.08 Quit kadoban (Ping timeout: 272 seconds) 07.56.11 # when it comes to sorting... heh, entire academic careers have been based on optimizing that 07.57.00 # i've sometimes concatenated a bunch of strings all into a contiguous memory region. used an array of pointers to manage access. this is only practical for read-only strings though. 07.57.09 Join Arsen [0] (~arsen@managarm/dev/Arsen) 07.57.38 Join dconrad [0] (~dconrad@208.38.228.17) 07.57.49 Join tomato [0] (~tomato@user/tomato) 07.57.49 Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) 07.57.49 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 07.57.49 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) 07.57.49 Join danwellby [0] (~danwellby@88.97.8.245) 07.57.49 Join hook54321 [0] (sid149355@user/hook54321) 07.57.53 Join rudi_s [0] (~simon@user/rudi-s/x-7673890) 07.57.53 Join kirvesAxe [0] (~kirvesaxe@user/kirvesaxe) 07.57.53 Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) 07.57.53 Join reductum [0] (~reductum@2603-8000-b400-8764-dea6-32ff-fe16-a622.res6.spectrum.com) 07.58.00 Join gevaerts [0] (~fg@user/gevaerts) 07.58.00 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 07.58.00 Join spork [0] (topic@31-151-2-135.dynamic.upc.nl) 07.58.00 Join TorC [0] (~Tor@fsf/member/TorC) 07.58.00 Join pixelma [0] (marianne@p200300ea874bea00305e95fffec66ff3.dip0.t-ipconnect.de) 07.58.00 Join ats [0] (~ats@cartman.offog.org) 07.58.00 Join Xeha [0] (~Xeha@dynamic-82-220-88-142.ftth.solnet.ch) 07.58.00 Join vup [0] (~~~~@46.101.193.235) 07.58.03 # speachy: correct me if i'm wrong but is the main reason memcpy is undefined for overlapping memory regions due to the fact that the copy mechanic is not defined? 07.58.10 # correct. 07.58.12 # optimization reasons basically. 07.58.22 # Build Server message: 3New build round started. Revision ee6b737b65, 303 builds, 8 clients. 07.59.21 # <_bilgus_> funny thing is I had done this with one of the patchsets but it didn't change the emitted code size so I figured the compiler out smarted me 08.00.58 # i was considering using branchless versions of some operations in inflate but it occurs to me most of our targets don't have cpus sophisticated enough to benefit from branch elimination 08.01.02 Quit blbro[m] (Ping timeout: 256 seconds) 08.01.28 # <_bilgus_> when it gets like that I do stuff to view the asm 08.01.48 # iirc, that would only benefit desktop builds. 08.02.06 # does the ingenic x1000e even have a branch predictor? 08.02.12 # our newest target to date 08.02.17 # that isn't a desktop system 08.02.20 # <_bilgus_> compiler explorer makes it more fun but just need to /home/bilgus/Desktop/RockboxDev/PLUGINFLAGS += -g -Wa,-adhln.txt 08.02.27 # <_bilgus_> compiler explorer makes it more fun but just need to /home/bilgus/Desktop/RockboxDev/PLUGINFLAGS += -g -Wa,-adhln 08.02.27 # code compactness matters most; the more that fits in the instruction cache the better 08.02.46 # <_bilgus_> sorry its a file apparently 08.02.54 # <_bilgus_> lol 08.03.17 # <_bilgus_> I usually do arm bc i'm most familar with the instructions 08.03.31 # braewoods: it's an 8-stage pipeline, so missed branches definitely hurt 08.03.56 # speachy: we could replace some macros with branchless alternatives. e.g., min/max 08.04.16 # <_bilgus_> dio it with ifdefs please 08.04.19 # but i don't know how helpful it'd be 08.04.30 # it has a branch predictor 08.04.44 # so eliminating branches we don't really need could help 08.04.57 # I'm sure it could help, but how much vs the effort? 08.05.12 # no idea. as it stands MIN/MAX branchless isn't that complex. 08.05.17 # and if it makes the code larger, it might hurt more than it helps on less cache-heavy targets 08.05.30 # i'll look into it later. 08.05.55 # i suspect only targets with branch predictors benefit 08.06.48 # it's a project for another time 08.07.03 # but some of the newer ports might benefit from this; i'd put these behind a branchless macro 08.07.13 # something we can enable for CPUs known to benefit 08.07.40 *** Saving seen data "./dancer.seen" 08.08.55 # When did ARM gain branch prediction? 08.09.38 # I think the ARM9xx series of processors 08.09.58 # i suspect PP and ColdFire wouldn't benefit from this. 08.11.03 # Build Server message: 3Build round completed after 761 seconds. 08.11.05 # Build Server message: 3Revision ee6b737b65 result: All green 08.11.23 # ARM11 definitely had it, ARM9 maybe, but I don't think so now. ARM7 nope. 08.11.45 # coldfire actually does have some branch rpediction 08.11.48 # So where do these fit in the armv4, etc, labels? 08.12.00 # armv4/v5/etc are the instruction sets 08.12.22 # Oh. Nothing to do with the actual ARM core. 08.12.37 # whereas ARM7/9/11/etc are the implementations in silicon 08.13.03 # ARM7 implements armv4, ARM9 implements armv5, ARM11 implements armv6 08.13.35 # cortex-a* implements armv7 (newer ones are armv8 and now armv9) 08.14.34 # who on earth thought that was a good naming convention?? 08.14.39 # cortex-m0/m0+ is armv6m (truly cut down!) but most cortex-ms are v7m. newest ones (just becoming generally available) are v8m. 08.14.52 # "it seemed like a good idea at the time" :D 08.15.19 # What's fun is that you could get the ARM ARM ARM 08.15.48 # ARM (the company) ARM (architecture) ARM ("architecture reference manual") 08.16.10 # I think someone else managed to tack a fourth ARM on to that right around the time I left 08.16.17 # at that point they're clearly just being jokers 08.16.58 # they need something thats the LEG, and maybe FOOT 08.17.16 # dconrad: but in all seriousness, that confusion is a big part of why they started calling using the "cortex-A/M/R" designation for the actual cores 08.17.27 # when AMD was toying with their dual architecture boards, i used to joke they could change their name to AAA now. 08.17.31 # AMD, ATI, ARM 08.17.33 # :D 08.17.40 # dconrad: oh, it's been done (internally) 08.17.47 # lol 08.18.05 # one of the few external examples of that is the "thumb" instruction set. 08.18.26 # what was the point of those? reducing the size of instructions? 08.18.38 # yeah, 16-bit vs 32-bit instruction size 08.18.43 # makes your code a _lot_ more compact 08.18.57 # are those still used on modern designs? 08.19.01 # you lose some performance (because you can't access as many general purpose registers) 08.19.15 # but when you're memory/cache-constrained it can make a big difference 08.19.36 # <_bilgus_> only reason the clip+ fit.. 08.19.44 # outside of the embedded (ARMxTDMI and Cortex-M) processors that require it, it's not used much. 08.19.46 # <_bilgus_> thumb 08.20.30 # is it my imagination or does x86 have fewer GP registers than other architectures of its time did? 08.20.35 # IIRC armv8 (ie 64-bit) did away with it, re-working the entire instruction set encoding 08.20.48 # x86 was infamously register-constrained. 08.21.01 # does 64 bit do enough to address that? 08.21.31 # x86 was pretty late to the 64 bit party but arm was even later assuming my timelines are right 08.21.34 # x86_64's main performance benefit was the expansion of the register file 08.21.43 # mips64 existed (on paper) much earlier 08.22.05 # mips existed in silicon at least a decade before x86_64 08.22.11 # mips64, I mean 08.22.23 # seems most of the mips implementors stick to 32 bit though 08.22.49 # I remember there being a lot of talks on arm64 at fosdem when that was a new thing 08.22.56 # you know what would be funny to see? 08.22.57 # the R4000 PCU (MIPS III instruction set) was announced in 1991. 08.23.00 # the bogomips of a mips processor :D 08.23.42 # due to larger integer and pointer sizes, unless your code needed to work with 64-bit stuff natively it was faster to stick with 32-bit code 08.24.01 # (solely due to the larger memory footprint of 64-bit stuff) 08.24.16 # the MIPS instruction set had 32 GPRs 08.24.21 # only performance powerhouses probably need 64 bits in general 08.24.49 # there's a few cases where 64 bits is helpful for supporting large files or so though. 08.25.14 # what typically happened is that the kernel was 64-bit, but most userspace was 32-bit 08.25.16 # speachy: isn't that part of why x32 was a thing? 08.25.22 # same with sparc actually 08.25.46 # it was a special amd64 ABI. 08.25.56 # braewoods: yep, that's the idea behind x32. but it wasn't better enough than "normal" x86 to overcome the penalty of losing binary compatibility. 08.26.35 # i actually had to correct people that dropping x32 didn't mean losing 32 bit x86 support. 08.26.38 # * braewoods facepalms. 08.27.09 # x32 used 32-bit pointers but gained access to all of the other x86_64 improvments like the expanded register set and instructions 08.27.41 # it also meant you couldn't memory map larger stuff 08.27.47 # or similar 08.28.35 # for rockbox though there's little point to 64 bit since most of our main stuff wouldn't benefit 08.28.39 # yeah, the larger address space was the real benefit, even in the 90s 08.29.19 # made for far, far, far simpler code. 08.29.23 # we can't handle files larger than 2GB anyway (assuming my code analysis is correct) 08.29.28 # since our file offsets are signed 08.29.52 # is that correct? 08.30.03 # there's no reason we couldn't go to 64-bit file offset pointers tomorrow 08.30.21 # we don't have to maintain binary compatibiltiy with anything else 08.30.29 # the only point would be supporting 4GB files on FAT32 08.30.45 # yeah, but who's going to use a >2GB audio file? :) 08.30.55 # when i work on MTP, i plan to factor the size into my code. 08.30.57 # (if we handled video that would be another matter...) 08.31.08 # if they try to pass a value larger than our off_t can store, it'll be rejected. 08.31.34 # technically MTP only supports up to 32 bit unsigned stuff 08.31.37 # use size_t and offset_t in your code and it's trivially changed with a recompile later. (except of course the over-the-wire stuff, which is fixed) 08.31.41 # no point in supporting the 64bit etensions 08.32.01 # since our underlying FS can't handle it anyway 08.32.10 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 08.32.30 # what would benefit us the most isn't 64-bit instruction sets, but rather SIMD/DSP stuff. 08.32.54 # just stating it does have some limits but it's a very short list. 08.32.55 # enabling our codecs and other computtionally-heavy stuff to go much faster. 08.33.01 # mainly time and file sizes. 08.33.06 # for our stuff. 08.33.08 # but utilizng that effectively is a _lot_ of work 08.34.01 # speachy: a lot of port specific code. 08.34.02 # heh, the ingenic parts we're using have a pretty rich SIMD engine that's arguably more powerful than the main mips core 08.34.55 # well, not "port specific" so much as "processor architecture specific" 08.35.07 # the x1000e has a lot of potential for architecture specific optimizations 08.35.13 # such as branchless 08.35.32 # whether they amount to anything is another question 08.35.33 # hoestly that level of optimization will be a rounding error 08.35.58 # at least my new workstation is nearly done 08.36.15 # i was long overdue for an upgrade 08.36.18 # which is good if you're at the point where even rounding errors matter (eg a lot of what went into the PP code) 08.36.40 # 64GB of ECC RAM, an 8 core APU 08.37.32 # the single largest bang-for-buck optimization on our MIPS code would be to implement nested/preemptible interrupts. 08.38.41 # I have some half-started code on that front but I think it would take a rework of our core threading/os code to actually be viable 08.39.07 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) 08.39.24 # though It did occur to me that we might benefit now from ditching our custom OS in favor of (eg) FreeRTOS. 08.39.48 # so we'd become an application? 08.40.26 # well, we already are an application, albeit bolted to our own OS instead of someone else's. 08.41.12 # but our OS interface is pretty much the same as every other RTOS; ie threads, mutexes, semaphores 08.42.12 # speachy: do you have any advice for IP cameras? seems like they're all stuck with proprietary firmware doing who knows what. 08.43.41 # they're all more or less the same junk. so unless you want to roll your own (which will also be junk, just differently so) you're best off sticking to things that don't require cloud integration and have the physical features you need. 08.44.40 # i thought so. i was hoping to find one that already had an openwrt port but no such luck. 08.44.46 # there are several pure-FOSS surveillance systems out there that will work with any camera that supplies an RSTP feed 08.45.04 # i know, but what i'm currently looking at is the actual cameras. 08.45.13 # the management system is a different story 08.45.40 # you could always just use an RPi with its native camera or with a USB-attached webcam or something 08.45.57 # can you weather-proof that? 08.46.05 # or custom case required? 08.46.07 # sure, but not cost-effectively vs just buying one already put together 08.46.29 # especially if you want things like PoE, IR LEDs, rotation control, etc etc 08.48.22 # well to me what matters most is retaining software control 08.48.39 # i don't trust proprietary stuff not to betray me so to speak 08.48.53 # especially since most of them require a network connection to do anything 08.49.27 # even if you take an untrusted camera, you can always firewall the crap out of it so it can only send data to your designated system(s). 08.53.24 # speachy: i see that. i'm just weighing my options for now. 08.56.56 Quit dconrad (Remote host closed the connection) 09.09.19 Join dconrad [0] (~dconrad@208.38.228.17) 09.13.59 Quit dconrad (Ping timeout: 252 seconds) 09.21.08 Join kadoban [0] (~kadoban@user/kadoban) 10.07.41 *** Saving seen data "./dancer.seen" 10.16.21 Quit _bilgus_ (Remote host closed the connection) 10.20.19 Quit skipwich (Quit: DISCONNECT) 10.20.31 Join skipwich [0] (~skipwich@user/skipwich) 10.21.11 Quit massiveH (Quit: Leaving) 10.37.17 Quit yang-idl1 (Changing host) 10.37.17 Join yang-idl1 [0] (~yang@fsf/member/yang) 10.37.42 Nick yang-idl1 is now known as yang-idle (~yang@fsf/member/yang) 10.40.05 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) 10.43.18 # Tried to make the manual build with old and new versions of KOMAscript: g#3689 10.43.20 # 3Gerrit review #3689 at https://gerrit.rockbox.org/r/c/rockbox/+/3689 : 3manual: Add workaround for older KOMAscript versions. by Dominik Riebeling 10.44.08 # seems sane 10.44.42 # cannot try with a newer installation right now, would be nice if someone could confirm this isn't breaking things :) 10.46.56 # just the regular 'make manual' ? 10.47.11 # oof, big boom. 10.48.09 # yeah, it's badly broken 10.49.30 # :/ 10.49.43 # was half expecting that. It does work for me ... 10.50.00 # guess I need to give it another look later 10.50.26 Join bigman60y [0] (~bigman60y@136.144.33.92) 10.52.21 # Hello. Trying to use SonyNWDest Tool on a NW-A45 on a Windows10 PC and getting error: Cannot open device. 10.54.51 # speachy: is there anything hinting to why it goes boom? Wondering if that \ifdefined doesn't like the if clause to be empty. 10.55.34 # re-running capturing the full output 10.56.38 # blbro[m]: www.shaftnet.org/~pizza/boom.txt 10.58.52 # in preamble.tex, if you add \typeout(blah) before the \else, does that make a difference? 11.22.00 # blbro[m]: nopw 11.35.20 Quit bigman60y (Quit: Connection closed) 11.43.56 Join bigman60y [0] (~bigman60y@136.144.33.92) 11.52.48 Quit bigman60y (Quit: Connection closed) 12.00.18 Quit Moriar (Ping timeout: 268 seconds) 12.05.05 Join bigman60y [0] (~bigman60y@136.144.33.92) 12.05.11 Quit bigman60y (Client Quit) 12.07.45 *** Saving seen data "./dancer.seen" 13.02.05 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:8d5f:ebab:9329:1ae8) 14.07.46 *** No seen item changed, no save performed. 14.39.45 Join _bilgus [0] (~bilgus@162.154.213.134) 15.04.53 # Build Server message: 3New build round started. Revision 614b189f7a, 303 builds, 9 clients. 15.16.34 # Build Server message: 3Build round completed after 702 seconds. 15.16.36 # Build Server message: 3Revision 614b189f7a result: All green 15.23.18 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) 15.36.26 # dmesg 15.36.27 # err 16.07.49 *** No seen item changed, no save performed. 16.37.20 Quit edhelas (Read error: Connection reset by peer) 17.07.55 Quit lebellium (Quit: Leaving) 17.44.53 Join amachronic [0] (~amachroni@user/amachronic) 17.47.06 # Build Server message: 3New build round started. Revision a8063054f9, 303 builds, 9 clients. 17.58.35 # Build Server message: 3Build round completed after 689 seconds. 17.58.37 # Build Server message: 3Revision a8063054f9 result: All green 17.59.39 # Build Server message: 3New build round started. Revision 69420e796c, 303 builds, 9 clients. 18.07.53 *** Saving seen data "./dancer.seen" 18.13.11 # Build Server message: 3Build round completed after 812 seconds. 18.13.13 # Build Server message: 3Revision 69420e796c result: All green 18.13.58 # Build Server message: 3New build round started. Revision b103b07503, 303 builds, 9 clients. 18.27.22 # Build Server message: 3Build round completed after 804 seconds. 18.27.23 # Build Server message: 3Revision b103b07503 result: All green 18.38.11 # Build Server message: 3New build round started. Revision cdd1f90131, 303 builds, 9 clients. 18.51.10 # Build Server message: 3Build round completed after 780 seconds. 18.51.12 # Build Server message: 3Revision cdd1f90131 result: All green 19.03.28 Quit Natch (Remote host closed the connection) 19.18.57 Quit amachronic (Quit: amachronic) 19.19.06 Join dconrad [0] (~dconrad@208.38.228.17) 19.28.17 # g#3696 if anybody wants to take a look 19.28.19 # 3Gerrit review #3696 at https://gerrit.rockbox.org/r/c/rockbox/+/3696 : 3Eros Q Native: Make Mute logic channel-independent by Dana Conrad 19.28.36 # a pretty simple patch for pretty basic oversight on my part haha 19.45.21 # Build Server message: 3New build round started. Revision 77a98ada12, 303 builds, 8 clients. 19.47.43 Quit ZincAlloy (Quit: Leaving.) 20.04.25 # Build Server message: 3Build round completed after 1143 seconds. 20.04.26 # Build Server message: 3Revision 77a98ada12 result: All green 20.07.54 *** Saving seen data "./dancer.seen" 20.15.10 Join F3l1x_10m_ [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) 20.18.58 Quit F3l1x_10m (Ping timeout: 240 seconds) 20.32.51 Join F3l1x_10m__ [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) 20.36.06 Quit F3l1x_10m_ (Ping timeout: 258 seconds) 20.41.49 Join F3l1x_10m_ [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) 20.44.55 Quit F3l1x_10m__ (Ping timeout: 258 seconds) 20.53.26 Quit tchan (Read error: No route to host) 21.08.34 Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) 21.22.30 Quit dconrad (Remote host closed the connection) 21.23.37 Join dconrad [0] (~dconrad@208.38.228.17) 21.36.33 # Build Server message: 3New build round started. Revision c9e9558044, 303 builds, 8 clients. 21.42.37 # nice, load average of 39. :D 21.51.37 # Build Server message: 3Build round completed after 903 seconds. 21.51.38 # Build Server message: 3Revision c9e9558044 result: All green 21.51.59 # <_bilgus> what was the previous average? 21.54.34 # that's was builder here 21.54.38 # my builder here, I mean 21.54.56 # it was already pushing 30 on an unrelated job prior to this build round 21.56.21 # <_bilgus> coverity doesn't do stdin processing apparently 21.56.25 # <_bilgus> Error: compilation via stdin '-' unsupported. All other compilations will proceed as normal 22.01.58 # <_bilgus> all these safety bytes keep adding up 22.02.31 # <_bilgus> been trying to keep code increase minimal... 22.04.52 # of course. 22.05.44 # don't see any real alternative though; bad data can lead to all sorts of odd behavior 22.06.40 # (I'm not too worried about outright crashes, and it's not like there can be any security implications, but let's not risk trashing random memory/stack...) 22.07.57 *** Saving seen data "./dancer.seen" 22.09.11 # <_bilgus> oh the number of real bugs found outweighs all the strife 22.10.33 # if we have to we can drop-kick the 2MB targets. :) 22.10.41 # <_bilgus> now we just need to wait and see what else we broke 22.11.01 # <_bilgus> all those assumptions 22.11.40 # <_bilgus> there has to be even fewer 22.11.47 # <_bilgus> of the 2mb targets 22.15.54 # only the clipv1, m200v4, and c200v2 22.26.05 # cant' be too many of those left in working order 22.27.05 # have to say the server's definitely snappier with respect to post-round activities 22.34.41 Quit Moriar (Ping timeout: 248 seconds) 23.11.58 Quit dconrad (Remote host closed the connection) 23.19.25 Join dconrad [0] (~dconrad@208.38.228.17) 23.19.47 # <_bilgus> and for less power I presume 23.23.45 Quit dconrad (Ping timeout: 248 seconds)