<fossy>working through the mescc-tools set <oriansj>fossy: what do you thing about adding support for set -eux to kaem, as it would just be a mapping to enabling verbose and strict? <oriansj>That way matching behavior with bash <fossy>oriansj: oh I left it for an hour and 31 crashes :O <fossy>ok, i've fixed the (single) bug causing all of them so far <fossy>is was a buffer overflow when the line is too long. <fossy>will include the patch with all the other kaem improvements coming <Hagfish>i'm wondering if some static analysis tool could have detected the buffer overflow too <Hagfish>(not that that's a reason not to do fuzzing as well) <fossy>found another segfault but this one is very strange <fossy>so leaving it until tomorrow ***dongcarl6 is now known as dongcarl
<oriansj>Hagfish: you are correct static analysis could detect several classes of bugs that we want to avoid. Would be nice if someone would help us by performing that analysis and sharing their results... <Hagfish>yeah, if i knew someone who had ever done static analysis before, then i'd definitely point them this way <janneke>vagrantc: i prepared a 0.22 on monday but found the sha256sum had changed... <janneke>hah, not even a mes 0.22 release out :-/ <janneke>i just found out; need to discuss with vagrantc what to do about it <fossy>hrm I need to check my tcc binary's checksums <vagrantc>janneke: so the question becomes: do we get the same checksum for the new binary :) <vagrantc>haven't heard from xwvvvvwx since the summit <janneke>vagrantc: i am pretty sure we will -- because i found why it changed <janneke>include/mes/config.h: #define MES_VERSION 0.22 <janneke>running sed on the binary s/0.22/0.21/ yields the same checksum again <janneke>now i wonder what is best to do (v0.23 will see so many changes to the C core anyway that the checksum will change) <janneke>vagrantc: but i don't want to break your (our) press release; we did all build the 9*fb thing :-) <vagrantc>i would expect the checksum to change when you change the underlying source <vagrantc>janneke: well, the package in debian right now contains the 9*fb hash, and presumably the mes-rb5 package in guix does, so i think we can still make a press release about it, and re-verify <vagrantc>janneke: i guess, what are the concerns you're having? <janneke>ah, right; i could keep the mes-rb5 package on 0.21 <janneke>i was updating that too, to 0.22 and i got this 'checksum-failed' backtrace <janneke>the concern is "only" cosmetic, wrt the press release and the fun with that <janneke>i thought i would release 0.22; then you would publish our checksum results (pointing to 0.22) -- and that has become a bit tricky; that's all <janneke>vagrantc: btw, i'm typing this on a pinebook pro...but it seems my guix build is stuck now at 94% building /gnu/store/bhd3s50xyw1iz38kwmj2kv3iapl04k78-guix-1.0.1-13.50299ad.drv... <vagrantc>janneke: i had a binary install of guix on a way-too-small partition and wasn't able to get as far as reconfigure <janneke>vagrantc: still on the default debian <janneke>ah, yeah i learned some things after i ordered it ... oh well, still a very nice device *vagrantc is a little creeped out by usb-upgradable firmware for the keyboard <vagrantc>actually, getting a not-bit-for-bit identical binary where the only change is entirely explainable is a pretty nice achievement :) <vagrantc>for a version bump, i'd expect more changes :) <janneke>yeah, i was thinking to keep checking for 9*fb; and just add a sed curse before doing so <vagrantc>janneke: alternately, the test could strip out the current version, and we get a hopefully more stable hash? <vagrantc>janneke: although if 0.23 is going to change, maybe that isn't so realistic <janneke>vagrantc: yeah -- i was thinking that about the installation prefix too (too late) <janneke>it would have been handy to check with --prefix=/usr ... now you have to run mes using MES_PREFIX=/usr -- or add a wrapper to get 9*fb -- oh well <vagrantc>for a test suite, it's interesting ... for reproducible builds ... less "proper" :) <janneke>okay, then i'll just go ahead and release 0.22; prolly add the sed trick for mes-rb5, based on that mes v0.22 <janneke>hopefully i get to that somewhere tomorrow <vagrantc>i probably won't get a chance to work on it till end-of-month ... though *maybe* tomorrow <janneke>it's been a very hectic 2 weeks for me, and still is until fosdem -- no worries *vagrantc just wants to drop most/all of debian/patches/* :) <janneke>yay! yes, that was mostly what 0.22 was about *janneke was hoping to get some arch linux patches to put in -- wink wink <vagrantc>i think that might require proper x86_64 support <vagrantc>since they don't really support 32-bit x86 <janneke>that would explain why it was (almost?) impossible to build mes <fossy>tcc dosent give the same checksum on 2 systems <oriansj>Hagfish: sounds like a great excuse to learn how to do static analysis <oriansj>fossy: with the exact same binary and the exact same options? <oriansj>(you can use kaem's nightmare-mode to strip out possible environmental causes as well)