<OriansJ>senzilla: if you think that will be fun; go for it. <OriansJ>oh thank god. I finally got guix v.1.2.0 to finally successfully complete guix pull <yt_>OriansJ: that's horrifying <OriansJ>yt: what is even worse is when I tried to just build gnutls-3.6.12; it just kept building gnutls-3.6.14; which is utterly useless in getting guix pull to work as it needs exactly a very specific build of gnutls-3.6.12 to work. <OriansJ>hence why I waited a month; hoping someone else might do the work required but looks like nope. <fossy>janneke: i'm trying out wip-m2, but the resulting binary mes is segaulting. i'm going to try an older version of m2-planet, which commit hash exactly did you use? (1.4.0 fails to compile because of no long) <vagrantc>OriansJ: you had to adjust your clock to even be able to time travel, nice! <OriansJ>vagrantc: well the cert expired and guix doesn't fake the time <OriansJ>fossy: adding long support is a single line diff <plasma41>oriansj: Wait, what's the issue? That solution looks gnarly. <OriansJ>plasma41: guix depends on gnutls-3.6.12 to be built but that version of gnutls includes a cert that expired in october of this year and thus the test will always fail <OriansJ>as one can not disable tests and get the same guix path; you have to do the ugly time change to get it to successfully build again. <OriansJ>now that means guix v1.2.0 was released broken for those who don't enable substitutes (like me) and stayed broken until I figured out the solution to getting guix to build from source again. <plasma41>So guix should start adding a date and time to package inputs going forward? O_o <OriansJ>plasma41: no but if they simply include qemu build isolation;; then these sorts of bugs simply vanish <OriansJ>as qemu allows one to arbitrary set time <OriansJ>specifically -rtc [base=utc|localtime|date][,clock=host|vm][,driftfix=none|slew] <vagrantc>OriansJ: yes, i recall the issue. good job with a workaround :) <OriansJ>and I emailed in the fix as well as posting on #guix so hopefully other people can also begin able to challenging the guix builds <plasma41>Should this workaround get built into guix time-machine somehow? <OriansJ>plasma41: that is for guix developers to choose but if I had to guess. probably a hard no as they have better solutions available that don't take systems offline for hours. <janneke>fossy: what version of guix are you on? <janneke>fossy: on wip-m2 [ 1f56ef6c339c9d82052730d82c1401dcfc25d0b5, do: <janneke>CC=i686-unknown-linux-gnu-gcc ./configure <janneke>the exact are defined in guix/git/mes.scm <fossy>i'll try your commands anyway :) <janneke>without guix (or nix) to manage dependencies properly, computing always stays a big roulette <janneke>of course, we have seen a kernel dependency once or twice here ;) <janneke>fossy: that's mescc-tools-1.1.0 and m2-planet-1.7.0 <janneke>although m2-planet identifies as 1.5.0 <vagrantc>oh, new upstream mescc-tools ... i can finally drop all the patches against 1.0.1 :) <OriansJ>janneke: technically we have seen a kernel behavior change once. <OriansJ>But that was because I abused the shit out of the ELF spec in the original ELF headers I hand wrote and needed to clean up my act. <OriansJ>vagrantc: I guess I really need to work on my communication skills if you are missing the release announcements I make. <vagrantc>OriansJ: might be through no fault of yours :) <OriansJ>well lets see my announcement on reproducible builds about bootstrapping of haskell from hex fell flat (literally no response at all) <janneke>OriansJ: behaviour change or not, it was bits in the environment (i.e. in the "not-program") that changed the program behaviour <janneke>people don't seem to grasp that you only need to change one bit in the environment (choose wisely), and your program breaks ("works for me") <nimaje>haskell as in ghc or in some other stadnard haskell implementation or in a pretty large subset of haskell? <nimaje>what bash features does that go.sh use? (currently trying with a /bin/sh shbang, lets see if it fails) <OriansJ>nimaje: well honestly it could use a kaem shell if you really want to strip down to the 737byte shell core <siraben>nimaje: yeah it's quite a large subset of haskell, too <nimaje>currently just trying if it compiles here; using make didn't work because of some problem(s) with generated/marginally.c <siraben>nimaje: did you have M2-Planet installed? <siraben>make also works but it uses the system C compiler <OriansJ>nimaje: the first step is use mescc-tools-seed to build M2-Planet, M1, blood-elf and hex2 from the hex0 seed <OriansJ>make test-x86, or make test-amd64 will also check to ensure their checksums are correct after the bootstrap <nimaje>well, I just use one previoslly build in mescc-tools-seed; why should I install it if I can just use PATH=$PATH:../mescc-tools-seed/bin <nimaje>I don't think M1 should segfault (on compiling bin/marginally.M1) <OriansJ>nimaje: that would be a big problem if it did <OriansJ>did you build the x86, Arch64 or AMD64 version of M1 with mescc-tools-seed? <nimaje>it was x86, but it seems like lldb on amd63 freebsd can't debug x86 linux binaries, so I will build again using amd64 versions <OriansJ>nimaje: and just in case; I'll begin a fuzzing run on M1 --architecture x86 to see if I can find anything that can cause a segfault on my size in hopes to replicate your issue. <siraben>nimaje: are you using the latest commit of mescc-tools-seed? <nimaje>I wasn't, so just rebuilding everything <nimaje>ok, updating and using amd64 M1 got past bin/marginally.M1 <nimaje>build fine, but ./bin/precisely <test/mandelbrot.hs gives missing: fromInteger for some reason <nimaje>(./bin/precisely <test/hello.hs >hello.c also worked fine) <OriansJ>hmm looks like the type changes in M2-Planet caused a regression in regards to toleration of arbitrary inputs. I'll have to figure out some requires to fix that. <OriansJ>(I really need to get back into the habit of ritual fuzzing on personal projects) <OriansJ>oh and FYI new GPG key is up for my git commit signatures for 2021-2022. <siraben>happy new year everyone! may 2021 be prosperous and fruitful! ***ericonr- is now known as ericonr
<janneke>bah, our bootstrap untar (bootar) cannot unpack savannah snapshot tarballs *janneke re-rolls mescc-tools-1.1.0.tar.gz for now <janneke>well, tar is basically real simple; all files rolled together <janneke>there's all these new options and stuff that made it difficult ***ChanServ sets mode: +o rekado
<janneke>hmm, updating the guix wip-full-source-bootstrap... but kaem-optional-seed has been [re]moved? <janneke>ah, but of course we should build kaem ourselves! <fossy>janneke: yeah you can just use gash <fossy>OriansJ: a release for bootstrap-seeds would be nice <janneke>=> /gnu/store/kjqf1p09yszy4d6lz743398j51r1qckn-m2-planet-boot-1.7.0 \o/ <OriansJ>fossy: sure; I'll make a v1.0.0 release of bootstrap-seeds <OriansJ>I might as well fixup the x86 NATIVE bootstrap seed while I'm at it