Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-08-10

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] (
02:07:35***Saving seen data "./dancer.seen"
03:39:59 Join ZincAlloy [0] (
04:04:34 Nick mendel_munkis is now known as munkis (
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:49bluebrother^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:33bluebrother^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:34speachyyeah, newer pdflatex needs the latter, older needs the former.
06:58:03speachyIIRC I committed that change when the server's version got updated to one that needed the latter syntax.
07:00:21bluebrother^too bad the commit message isn't really clear about that ...
07:00:52speachyit was discussed in IRC but yeah, I should have asked for a more verbose commit message.
07:00:52bluebrother^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:06speachycharacter encoding issue?
07:01:41bluebrother^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:57bluebrother^oh. Seems our strips that, so no issue with LaTeX.
07:05:39bluebrother^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:14rb-bluebotBuild Server message: New build round started. Revision 4fb5aeb096, 303 builds, 8 clients.
07:38:06rb-bluebotBuild Server message: Build round completed after 952 seconds.
07:38:07rb-bluebotBuild Server message: Revision 4fb5aeb096 result: 4 errors 0 warnings
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:12braewoods_bilgus_: what'd you chnage?
07:41:58 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019)
07:43:56_bilgus_its tight apparently
07:44:32braewoods_bilgus_: why'd you cast the void*? that's usually unneeded.
07:45:33braewoodsso what changed? code size? stack size? both?
07:46:01braewoodsi'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@
07:47:19_bilgus_I'll try messing with the m5 direct
07:47:50 Join dys [0] (~dys@user/dys)
07:47:55speachyyeah, the m5 has given us plenty of grief before
07:48:05braewoods_bilgus_: did you consider trying something a bit different?
07:48:21 Join emacsoma1 [0] (~emacsoman@
07:48:31braewoodsnevermind, probably wouldn't help
07:48:51_bilgus_a bit different ranged from 10-30 more instructions
07:49:11braewoodsi wonder what would happen if you tried changing the optimization level
07:49:17_bilgus_open to suggestions
07:49:22braewoodsi've sometimes found -O2 actually beats -Os in some cases
07:49:36speachy_bilgus_: IIRC the last time this happened we "fixed" it by shrinking the stack slightly.
07:49:36braewoodsbut 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:41braewoodsspeachy: sounds like most coldfire is a royal PITA.
07:50:56braewoodsspeachy: and only the iriver ones are common these days to find availablbe
07:51:18speachybraewoods: due to crappy caches we have to put critical code into IRAM if it has a hope of being performant
07:51:32braewoodsso IRAM is basically coldfire's fast ram
07:51:35speachyand 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:04speachyIRAM is usually memory that's capable of running at full processor speed; ie no wait states
07:52:06speachyvs external RAM that's a lot slower
07:52:06braewoodsugh. net split.
07:52:22speachycaches hide that latency a lot
07:52:45braewoodsis that the main reason linked lists have turned into performance dogs today?
07:52:51braewoodsthey're not very cache friendly.
07:53:14 Join benjaoming [0] (~benjaomin@
07:53:14 Join markun_ [0] (
07:53:18braewoodsat least on systems where cache misses are a serious issue
07:53:28speachythey don't scale up well, but all data structures are exercises in tradeoffs
07:53:42braewoodsindeed, i usually use arrays today where i can.
07:53:57speachyyou can't slice and dice elements into/out of arrays though
07:54:05braewoodsi know. it's a tradeoff.
07:54:16braewoodsspeachy: well, you can in sparse arrays. but yea.
07:54:28speachysparse arrays aren't exactly cache friendly either. :D
07:54:49braewoodsi know, mostly just convience of having a global lookup table of sorts you can access quickly
07:55:24braewoodsarrays of pointers are also problematic but they are good for quick rearrangement of data
07:55:38braewoodscost of copying is greatly reduced
07:56:08 Quit kadoban (Ping timeout: 272 seconds)
07:56:11speachywhen it comes to sorting... heh, entire academic careers have been based on optimizing that
07:57:00braewoodsi'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@
07:57:49 Join tomato [0] (~tomato@user/tomato)
07:57:49 Join Piece_Maker [0] (
07:57:49 Join ufdm [0] (
07:57:49 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
07:57:49 Join danwellby [0] (~danwellby@
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] (
07:58:00 Join gevaerts [0] (~fg@user/gevaerts)
07:58:00 Join michaelni [0] (
07:58:00 Join spork [0] (
07:58:00 Join TorC [0] (~Tor@fsf/member/TorC)
07:58:00 Join pixelma [0] (
07:58:00 Join ats [0] (
07:58:00 Join Xeha [0] (
07:58:00 Join vup [0] (~~~~@
07:58:03braewoodsspeachy: 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:12braewoodsoptimization reasons basically.
07:58:22rb-bluebotBuild Server message: New 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:58braewoodsi 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:48braewoodsiirc, that would only benefit desktop builds.
08:02:06braewoodsdoes the ingenic x1000e even have a branch predictor?
08:02:12braewoodsour newest target to date
08:02:17braewoodsthat 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:27speachycode compactness matters most; the more that fits in the instruction cache the better
08:02:46_bilgus_sorry its a file apparently
08:03:17_bilgus_I usually do arm bc i'm most familar with the instructions
08:03:31speachybraewoods: it's an 8-stage pipeline, so missed branches definitely hurt
08:03:56braewoodsspeachy: we could replace some macros with branchless alternatives. e.g., min/max
08:04:16_bilgus_dio it with ifdefs please
08:04:19braewoodsbut i don't know how helpful it'd be
08:04:30speachyit has a branch predictor
08:04:44braewoodsso eliminating branches we don't really need could help
08:04:57speachyI'm sure it could help, but how much vs the effort?
08:05:12braewoodsno idea. as it stands MIN/MAX branchless isn't that complex.
08:05:17speachyand if it makes the code larger, it might hurt more than it helps on less cache-heavy targets
08:05:30braewoodsi'll look into it later.
08:05:55braewoodsi suspect only targets with branch predictors benefit
08:06:48braewoodsit's a project for another time
08:07:03braewoodsbut some of the newer ports might benefit from this; i'd put these behind a branchless macro
08:07:13braewoodssomething we can enable for CPUs known to benefit
08:07:40***Saving seen data "./dancer.seen"
08:08:55braewoodsWhen did ARM gain branch prediction?
08:09:38speachyI think the ARM9xx series of processors
08:09:58braewoodsi suspect PP and ColdFire wouldn't benefit from this.
08:11:03rb-bluebotBuild Server message: Build round completed after 761 seconds.
08:11:05rb-bluebotBuild Server message: Revision ee6b737b65 result: All green
08:11:23speachyARM11 definitely had it, ARM9 maybe, but I don't think so now. ARM7 nope.
08:11:45speachycoldfire actually does have some branch rpediction
08:11:48braewoodsSo where do these fit in the armv4, etc, labels?
08:12:00speachyarmv4/v5/etc are the instruction sets
08:12:22braewoodsOh. Nothing to do with the actual ARM core.
08:12:37speachywhereas ARM7/9/11/etc are the implementations in silicon
08:13:03speachyARM7 implements armv4, ARM9 implements armv5, ARM11 implements armv6
08:13:35speachycortex-a* implements armv7 (newer ones are armv8 and now armv9)
08:14:34dconradwho on earth thought that was a good naming convention??
08:14:39speachycortex-m0/m0+ is armv6m (truly cut down!) but most cortex-ms are v7m. newest ones (just becoming generally available) are v8m.
08:14:52speachy"it seemed like a good idea at the time" :D
08:15:19speachyWhat's fun is that you could get the ARM ARM ARM
08:15:48speachyARM (the company) ARM (architecture) ARM ("architecture reference manual")
08:16:10speachyI think someone else managed to tack a fourth ARM on to that right around the time I left
08:16:17dconradat that point they're clearly just being jokers
08:16:58dconradthey need something thats the LEG, and maybe FOOT
08:17:16speachydconrad: 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:27braewoodswhen AMD was toying with their dual architecture boards, i used to joke they could change their name to AAA now.
08:17:31braewoodsAMD, ATI, ARM
08:17:40speachydconrad: oh, it's been done (internally)
08:18:05speachyone of the few external examples of that is the "thumb" instruction set.
08:18:26braewoodswhat was the point of those? reducing the size of instructions?
08:18:38speachyyeah, 16-bit vs 32-bit instruction size
08:18:43speachymakes your code a _lot_ more compact
08:18:57braewoodsare those still used on modern designs?
08:19:01speachyyou lose some performance (because you can't access as many general purpose registers)
08:19:15speachybut when you're memory/cache-constrained it can make a big difference
08:19:36_bilgus_only reason the clip+ fit..
08:19:44speachyoutside of the embedded (ARMxTDMI and Cortex-M) processors that require it, it's not used much.
08:20:30braewoodsis it my imagination or does x86 have fewer GP registers than other architectures of its time did?
08:20:35speachyIIRC armv8 (ie 64-bit) did away with it, re-working the entire instruction set encoding
08:20:48speachyx86 was infamously register-constrained.
08:21:01braewoodsdoes 64 bit do enough to address that?
08:21:31braewoodsx86 was pretty late to the 64 bit party but arm was even later assuming my timelines are right
08:21:34speachyx86_64's main performance benefit was the expansion of the register file
08:21:43braewoodsmips64 existed (on paper) much earlier
08:22:05speachymips existed in silicon at least a decade before x86_64
08:22:11speachymips64, I mean
08:22:23braewoodsseems most of the mips implementors stick to 32 bit though
08:22:49bertrikI remember there being a lot of talks on arm64 at fosdem when that was a new thing
08:22:56braewoodsyou know what would be funny to see?
08:22:57speachythe R4000 PCU (MIPS III instruction set) was announced in 1991.
08:23:00braewoodsthe bogomips of a mips processor :D
08:23:42speachydue 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:01speachy(solely due to the larger memory footprint of 64-bit stuff)
08:24:16speachythe MIPS instruction set had 32 GPRs
08:24:21braewoodsonly performance powerhouses probably need 64 bits in general
08:24:49braewoodsthere's a few cases where 64 bits is helpful for supporting large files or so though.
08:25:14speachywhat typically happened is that the kernel was 64-bit, but most userspace was 32-bit
08:25:16braewoodsspeachy: isn't that part of why x32 was a thing?
08:25:22speachysame with sparc actually
08:25:46braewoodsit was a special amd64 ABI.
08:25:56speachybraewoods: 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:35braewoodsi actually had to correct people that dropping x32 didn't mean losing 32 bit x86 support.
08:26:38*braewoods facepalms.
08:27:09speachyx32 used 32-bit pointers but gained access to all of the other x86_64 improvments like the expanded register set and instructions
08:27:41braewoodsit also meant you couldn't memory map larger stuff
08:27:47braewoodsor similar
08:28:35braewoodsfor rockbox though there's little point to 64 bit since most of our main stuff wouldn't benefit
08:28:39speachyyeah, the larger address space was the real benefit, even in the 90s
08:29:19speachymade for far, far, far simpler code.
08:29:23braewoodswe can't handle files larger than 2GB anyway (assuming my code analysis is correct)
08:29:28braewoodssince our file offsets are signed
08:29:52braewoodsis that correct?
08:30:03speachythere's no reason we couldn't go to 64-bit file offset pointers tomorrow
08:30:21speachywe don't have to maintain binary compatibiltiy with anything else
08:30:29braewoodsthe only point would be supporting 4GB files on FAT32
08:30:45speachyyeah, but who's going to use a >2GB audio file? :)
08:30:55braewoodswhen i work on MTP, i plan to factor the size into my code.
08:30:57speachy(if we handled video that would be another matter...)
08:31:08braewoodsif they try to pass a value larger than our off_t can store, it'll be rejected.
08:31:34braewoodstechnically MTP only supports up to 32 bit unsigned stuff
08:31:37speachyuse 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:41braewoodsno point in supporting the 64bit etensions
08:32:01braewoodssince our underlying FS can't handle it anyway
08:32:10 Join massiveH [0] (
08:32:30speachywhat would benefit us the most isn't 64-bit instruction sets, but rather SIMD/DSP stuff.
08:32:54braewoodsjust stating it does have some limits but it's a very short list.
08:32:55speachyenabling our codecs and other computtionally-heavy stuff to go much faster.
08:33:01braewoodsmainly time and file sizes.
08:33:06braewoodsfor our stuff.
08:33:08speachybut utilizng that effectively is a _lot_ of work
08:34:01braewoodsspeachy: a lot of port specific code.
08:34:02speachyheh, the ingenic parts we're using have a pretty rich SIMD engine that's arguably more powerful than the main mips core
08:34:55speachywell, not "port specific" so much as "processor architecture specific"
08:35:07braewoodsthe x1000e has a lot of potential for architecture specific optimizations
08:35:13braewoodssuch as branchless
08:35:32braewoodswhether they amount to anything is another question
08:35:33speachyhoestly that level of optimization will be a rounding error
08:35:58braewoodsat least my new workstation is nearly done
08:36:15braewoodsi was long overdue for an upgrade
08:36:18speachywhich 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:40braewoods64GB of ECC RAM, an 8 core APU
08:37:32speachythe single largest bang-for-buck optimization on our MIPS code would be to implement nested/preemptible interrupts.
08:38:41speachyI 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:24speachythough It did occur to me that we might benefit now from ditching our custom OS in favor of (eg) FreeRTOS.
08:39:48braewoodsso we'd become an application?
08:40:26speachywell, we already are an application, albeit bolted to our own OS instead of someone else's.
08:41:12speachybut our OS interface is pretty much the same as every other RTOS; ie threads, mutexes, semaphores
08:42:12braewoodsspeachy: do you have any advice for IP cameras? seems like they're all stuck with proprietary firmware doing who knows what.
08:43:41speachythey'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:40braewoodsi thought so. i was hoping to find one that already had an openwrt port but no such luck.
08:44:46speachythere are several pure-FOSS surveillance systems out there that will work with any camera that supplies an RSTP feed
08:45:04braewoodsi know, but what i'm currently looking at is the actual cameras.
08:45:13braewoodsthe management system is a different story
08:45:40speachyyou could always just use an RPi with its native camera or with a USB-attached webcam or something
08:45:57braewoodscan you weather-proof that?
08:46:05braewoodsor custom case required?
08:46:07speachysure, but not cost-effectively vs just buying one already put together
08:46:29speachyespecially if you want things like PoE, IR LEDs, rotation control, etc etc
08:48:22braewoodswell to me what matters most is retaining software control
08:48:39braewoodsi don't trust proprietary stuff not to betray me so to speak
08:48:53braewoodsespecially since most of them require a network connection to do anything
08:49:27speachyeven 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:24braewoodsspeachy: 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@
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] (
10:43:18blbro[m]Tried to make the manual build with old and new versions of KOMAscript: g#3689
10:43:20rb-bluebotGerrit review #3689 at : manual: Add workaround for older KOMAscript versions. by Dominik Riebeling
10:44:08speachyseems sane
10:44:42blbro[m]cannot try with a newer installation right now, would be nice if someone could confirm this isn't breaking things :)
10:46:56speachyjust the regular 'make manual' ?
10:47:11speachyoof, big boom.
10:48:09speachyyeah, it's badly broken
10:49:43blbro[m]was half expecting that. It does work for me ...
10:50:00blbro[m]guess I need to give it another look later
10:50:26 Join bigman60y [0] (~bigman60y@
10:52:21bigman60yHello. Trying to use SonyNWDest Tool on a NW-A45 on a Windows10 PC and getting error: Cannot open device.
10:54:51blbro[m]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:34speachyre-running capturing the full output
10:58:52blbro[m]in preamble.tex, if you add \typeout(blah) before the \else, does that make a difference?
11:22:00speachyblbro[m]: nopw
11:35:20 Quit bigman60y (Quit: Connection closed)
11:43:56 Join bigman60y [0] (~bigman60y@
11:52:48 Quit bigman60y (Quit: Connection closed)
12:00:18 Quit Moriar (Ping timeout: 268 seconds)
12:05:05 Join bigman60y [0] (~bigman60y@
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@
15:04:53rb-bluebotBuild Server message: New build round started. Revision 614b189f7a, 303 builds, 9 clients.
15:16:34rb-bluebotBuild Server message: Build round completed after 702 seconds.
15:16:36rb-bluebotBuild Server message: Revision 614b189f7a result: All green
15:23:18 Join Moriar [0] (
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:06rb-bluebotBuild Server message: New build round started. Revision a8063054f9, 303 builds, 9 clients.
17:58:35rb-bluebotBuild Server message: Build round completed after 689 seconds.
17:58:37rb-bluebotBuild Server message: Revision a8063054f9 result: All green
17:59:39rb-bluebotBuild Server message: New build round started. Revision 69420e796c, 303 builds, 9 clients.
18:07:53***Saving seen data "./dancer.seen"
18:13:11rb-bluebotBuild Server message: Build round completed after 812 seconds.
18:13:13rb-bluebotBuild Server message: Revision 69420e796c result: All green
18:13:58rb-bluebotBuild Server message: New build round started. Revision b103b07503, 303 builds, 9 clients.
18:27:22rb-bluebotBuild Server message: Build round completed after 804 seconds.
18:27:23rb-bluebotBuild Server message: Revision b103b07503 result: All green
18:38:11rb-bluebotBuild Server message: New build round started. Revision cdd1f90131, 303 builds, 9 clients.
18:51:10rb-bluebotBuild Server message: Build round completed after 780 seconds.
18:51:12rb-bluebotBuild Server message: Revision 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@
19:28:17dconrad g#3696 if anybody wants to take a look
19:28:19rb-bluebotGerrit review #3696 at : Eros Q Native: Make Mute logic channel-independent by Dana Conrad
19:28:36dconrada pretty simple patch for pretty basic oversight on my part haha
19:45:21rb-bluebotBuild Server message: New build round started. Revision 77a98ada12, 303 builds, 8 clients.
19:47:43 Quit ZincAlloy (Quit: Leaving.)
20:04:25rb-bluebotBuild Server message: Build round completed after 1143 seconds.
20:04:26rb-bluebotBuild Server message: Revision 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] (
21:22:30 Quit dconrad (Remote host closed the connection)
21:23:37 Join dconrad [0] (~dconrad@
21:36:33rb-bluebotBuild Server message: New build round started. Revision c9e9558044, 303 builds, 8 clients.
21:42:37speachynice, load average of 39. :D
21:51:37rb-bluebotBuild Server message: Build round completed after 903 seconds.
21:51:38rb-bluebotBuild Server message: Revision c9e9558044 result: All green
21:51:59_bilguswhat was the previous average?
21:54:34speachythat's was builder here
21:54:38speachymy builder here, I mean
21:54:56speachyit was already pushing 30 on an unrelated job prior to this build round
21:56:21_bilguscoverity doesn't do stdin processing apparently
21:56:25_bilgusError: compilation via stdin '-' unsupported. All other compilations will proceed as normal
22:01:58_bilgusall these safety bytes keep adding up
22:02:31_bilgusbeen trying to keep code increase minimal...
22:04:52speachyof course.
22:05:44speachydon't see any real alternative though; bad data can lead to all sorts of odd behavior
22:06:40speachy(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_bilgusoh the number of real bugs found outweighs all the strife
22:10:33speachyif we have to we can drop-kick the 2MB targets. :)
22:10:41_bilgusnow we just need to wait and see what else we broke
22:11:01_bilgusall those assumptions
22:11:40_bilgusthere has to be even fewer
22:11:47_bilgusof the 2mb targets
22:15:54speachyonly the clipv1, m200v4, and c200v2
22:26:05speachycant' be too many of those left in working order
22:27:05speachyhave 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@
23:19:47_bilgusand for less power I presume
23:23:45 Quit dconrad (Ping timeout: 248 seconds)

Previous day | Next day