<Kozo>I am writing in CL using Emacs + Slime. Sometimes I have to close emacs and open it to clear it's loaded buffer as it remembers previous values from C-c C-k. Is there a way to clear it on each compile?
<nckx>raghav-gururajan: With some luck I am starting the last wpewe build (now with #:tests? #f).
<jonsger>mbakke: that's crazy. But why does take chromium sooo much longer then icecat?
<mbakke>jonsger: I think the Chromium codebase is much larger than IceCat/Firefox, and it makes heavy use of C++ templates, to the point where it can only build with a bleeding-edge Clang :/
<jonsger>ah those c++ templates are pretty nice for debugging (sarcasm off) ^^
<mbakke>up until version 80 chromium had a flag called "jumbo_build" that drastically improved build times by compiling multiple targets in one go, but they removed it, almost doubling the number of compilation steps :/
<mbakke>for my current chromium 83 build, there are 39100 steps, and with jumbo_build it was ~23k
<raingloom>vagrantc: but if $PATH and others are set, why not $MANPATH? it's weird and confusing...
<vagrantc>raingloom: just saying what i recall observing, i hear you
<raingloom>vagrantc: it looks like this works: guix environment --ad-hoc socat man-db -- man socat
<vagrantc>raingloom: i guess man-db package, not man ... but yeah, basically what i mentioned
<apteryx>raingloom: the search-path specification definitions are usually made on the packages that make use of those paths. In the case of manpages, that's man-db (which is the man reader). So unless you install man-db in a profile, MANPATH is not set.
<raingloom>apteryx: i see. i guess that makes sense, since `guix environment` doesn't know that man is installed in the calling environment. still, this is quite suboptimal. this is where a union file system would be better than this search path trickery.
*raingloom crawls back into the Plan 9 VM it's tinkering with
<apteryx>raingloom: there's already a union fs view of the profile, but you still need to get the tools to find them, which requires environment variable unless you use the FHS.
<apteryx>perhaps you mean that there should be a mechanism to set variables based on the presence of files in this union... that could work but would set a plethore of things that might not be relevant, which seems dirty.
<raingloom>apteryx: or the host environment could contain some kind of hint for what variables should be updated
<mothacehe>civodul: because creating a partition image requires a raw directory (with mke2fs for instance). I think I also tried with a directory only containing symlinks but it didn't make the trick, can't remember why.
<cbaines>does register-items need to happen in a transaction? Or would it be OK to just register things individually?
<cbaines>(and by "in a transaction", I mean does it need to use call-with-retrying-transaction)
<civodul>mothacehe: perhaps we could do both in one derivation, such that there's never a derivation that produces such a big directory
<civodul>cbaines: not sure, call-with-retrying-transaction was added a few days ago
<mothacehe>yes but then the files will have guixbuilder user & group
<mothacehe>instead of root:root when using two distinct derivations
<civodul>cbaines: see the comment of 8971f626f2e69987bea729307adb93a0be243234
*raghav_gururajan edits gtk+ and whole bunch of packages rebuild. *sigh*
<mothacehe>unless we could override them from mke2fs command line, hmmm
<civodul>mothacehe: does ownership matter? can't we specify UIDs/GIDs for use by mke2fs?
<cbaines>I guess if the presence of the id was being used to do something, then you might want to use a transaction to prevent it from being deleted... but absence seems to be the only thing that matters in the code currently
<civodul>hmm i was thinking we want to avoid TOCTTOU issues
<civodul>but call-with-transaction doesn't help with that
<apteryx>raghav_gururajan: if it's just for testing, make your own my-gtk+ package and use it with what your trying to fix
<cbaines>Yeah, TOCTTOU would be a good argument for a transaction, but the value is not being used in this case
<cbaines>Anyway, just wrapping path-id and sqlite-register in a transaction would still be an improvement
<cbaines>The commit which introduced the transaction to register-items (a4678c6ba18d8dbd79d931f80426eebf61be7ebe) does give a reason (which is great :D ), saying it's to: prevent broken intermediate states from being visible.
<cbaines>register-items say the items must be ordered "leaves first", assuming leaf packages are the ones with nothing referencing them, I can't see how that would work...
<nixfreak>OK i'm getting the error /tmp/tmp.9JLClbjPCM/rustup-init: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory , I researched the file service variable `(("/bin/sh" ,(file-append bash "/bin/sh"))) for this example, but I have the /lib in my path now but still doesn't work because its a shared object but using `(("/lib"
<nixfreak>,(file-append gcc "/lib"))) doesn't seem to work , what else can I do ?
<cbaines>civodul, ok, will this only be used for a handful of store items then at any one time?
<civodul>currently yes, it's used by finalize-store-file
<civodul>so just for the outputs of one derivation
<civodul>thus typically between 1 and 3 store items
<cbaines>nixfreak, I don't really follow your message. Are you trying to use a program not built through a Guix package on a system running Guix as an OS?
<cbaines>providing the nightly rust would be something a Guix channel might be a good fit for as well
<nixfreak>wasn't me what I'm sure that would work , just need cargo to upate
<nixfreak>ok so is that ready then rust-nightly --with-source ?
<nixfreak>so I still have libgcc issues when building nixfreak@GNU-ChaOs ~/build/rustc-nightly-src$ python3.8 x.py build
<nixfreak>/home/nixfreak/build/rustc-nightly-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
<mothacehe>civodul: managed to remove the "image-root" derivation from the ISO build. Will push when the tests are done.
<mothacehe>Then I need to do the same thing for raw disk-images.
<civodul>mothacehe: woow, that was super fast, nice!
<cbaines>civodul, going back to register-items, I don't know how to test it, but I can give writing a patch a go.
<MSavoritias>the build log says basically nothing. just that generating the package cache. value and the it fails
<nckx>MSavoritias: You should be able to ‘guix pull --rounds=2 --keep-failed’ to keep the offending copy in the store (as /gnu/store/…-check). You can then compare the two with diffoscope or so, or attach them to a bug report (no idea how big the cache is).
<nckx>raghav_gururajan: I thought wpewebkit depended on gtk+ (as in: the first time I built your wpewebkit package, it first built gtk+), but maybe I'm mistaken.
<jeko>vagrantc: thank you for your help, I will try !
<nckx>MSavoritias: I'm guessing you're looking at hex representation of binary files, plus ANSI colour codes and formatting. If the diff contains basically the contents of each file -/+ (so 10 MiB), as hex (each byte → 2 bytes), it can easily exceed 20 MiB.
<apteryx>chromium creates lots of IO activity from some thread call ThreadPoolForeg, slowing down my machine (visible from iotop). Is this happening to someone else? Seems to occur mostly when using sound (video playback, video conference)
<nckx>civodul: How is the dmitri/sergei tunnel started now? It seems not to be running.
<apteryx>Nthe activity came to a halt now, but I could see this in iotop: chromium --type=utility --field-trial-handle=13676461428315526438,444005121~c-apm-in-audio-service --shared-files=v8_snapshot_data:100 [ThreadPoolForeg
<nckx>I say seems because I'm not sure what to look for, but ‘sudo guix offload test’ fails to connect to localhost which is a pretty big hint.
<nckx>And there used to be ssh processes running in civodul's screen which are gone now.
<Bryophyllum>I managed to boot Guix on my production machine! There was a hiccup caused by my system firmware not honoring the boot display device setting, but it was solved by enabling the legacy boot compatibility mode, in which the said setting is honored. In short, on the output, to which my AMD GPU is connected, a static screen, with early boot messages was displayed, and on the other one, to which my iGPU is connected, the ncurses ins
<Bryophyllum>taller screen, which, on the other hand, would freeze upon selecting "Install using the shell based process".
<apteryx>lfam: OK, managed to find out what files it's trying to use
<apteryx>many files, but one example: [pid 4577] openat(AT_FDCWD, "/home/maxim/.config/chromium/Default/Cookies-journal", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0600) = 176
<mbakke>bad news, Magit with TRAMP just locked up my emacs :P
<mbakke>ooh, killing the SSH process brought it back to life
<MSavoritias>I am trying to close my bug report by send an email to firstname.lastname@example.org but for some reason the email cant be sent. It keeps says that TLS is required but it wasn't provided by debbugs
<lfam>It could also be a problem with debbugs but I figure we would have heard of it before
<MSavoritias>I will see if it happens with the other email. Otherwise it may be the client
<MSavoritias>I don't think so either. Maybe posteo doesn't like something. I will see with the other email
<efraim>well, if I skip cgo then go-1.13 builds natively for aarch64
<ATuin>trying to run nix-channel --update i get the following: while setting up the build environment: executing '/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash': No such file or directory