<katco>and 2 of these scripts are invoking builds utilizing cgo
<katco>which is bringing gcc and linux headers into the build
<katco>is it acceptable to just disable these two tests?
<lfam>katco: I think it's okay if GCC and the kernel headers are required for the test suite. Ideally they won't bring new run-time dependencies into Go itself. What happens when you try to run the tests with GCC and the headers?
<katco>i'm slowly getting there. i _just_ got the scripts to recognize the headers
<katco>each script is run in its own little sandbox, so i've had to learn this little scripting language to figure out how to inject the deps
<lfam>It could definitely be useful to disable the tests for now and then see if Go works. The tests can be re-enabled later
<katco>so the thing it's complaining about now: `ld: cannot find crt1.o: No such file or directory`
<lfam>I'm sure you noticed we already disable lots of tests that simply won't apply in the Guix build container. We prefer not to disable tests for other reasons but sometimes it's worth it if making them work seems like a poor use of our time
<katco>lfam: these two tests are just a pain. i've gotten to the point where they can find the headers they need, but i can't seem to point them to the glibc directory with the crt1.o files they need. which is to say i have done what should work, but they're still complaining
<katco>lfam: i'm going to submit having removed these tests. but how can i communicate what i've tried in case i've missed something?
<lfam>katco: You could send the patch to <firstname.lastname@example.org>. You'll get a message back with the bug ticket number, including a reply address specific to the patch. You can reply to that address to keep your notes and patch together
<thorwil>i just learned that with `guix build --log-file gimp-resynthesizer`, i get just the same result as without --log-file. it's only with `guix build --log-file /gnu/store/r0x4nyd2vfd802nzipp6q5cbssbiq4qa-gimp-resynthesizer-2.0.3.drv` taht i get the path to a logfile
<thorwil>oh. build tells me "./configure: line 9047: /bin/sh: No such file or directory", but in config.log, i find: "conftest.c:27:42: fatal error: CoreFoundation/CFPreferences.h: No such file or directory"
<thorwil>seems CoreFoundation is osx business. a bit odd to read "compilation terminated" several times, when that apparently wasn't the actual failure
<roptat>the ocaml importer is broken with the release of opam 2.0 :/
<rockandska>wanna ask something before submitting an issue, is it consider as a bug to not have GUIX_LOCPATH into "/etc/profile" when using relocatable ? (example: guix pack -R -S /bin=bin -S /etc=etc hello glibc-locales)
<thorwil>will any use of /bin/sh in a configure script lead to problems? (with a shebang like #!/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh)
<snape>mbakke: I can't see evaluations failing on Berlin
<jonsger>samplet: stackage and hackage do both have recursive importers :) thanks to rekado :)
<samplet>janneke: I saw your post and am thinking about it. I need to finish a major Haskell update that I took on first, though.
<d1rewolf>nckx: ok, thanks. And is there some security policies/procedures published and followed? I'm using nix currently and trying to push adoption at work, but no published policy basically makes it a non-starter
<janneke>samplet: great -- there's no hurry, i'm not ready to start hacking on it...but it could be the next big thing
<janneke>removing gcc,glibc,binutils from the bootstrap binaries reduced their size from 250MB to 130MB; guile is only 10MB -- the rest could potentially be replaced by gash/geesh + some work ;-)
<d1rewolf>anyone running guix on ubuntu or debian here?
<janneke>d1rewolf: i think most of us started that way, some collegues of mine are still doing it that way
<d1rewolf>janneke: and you switched to guixsd since?
<janneke>d1rewolf: about two years ago, ran guix on debian for ~4 months
<d1rewolf>I'd really like to try guix, and I've found the nix interface/myriad of commands intimidating, and I'd rather lisp than nix-lang. However, I don't necessarily want the strong libre opinions of guixsd...for example, I'd like my proprietary nvidia drivers to work, and I don't mind systemd tbh
<d1rewolf>wondering if guix on top of debian or ubuntu would give me the best of both worlds?
<janneke>what i did, was slowly move more and more of my computing/developing needs into guix while running debian, and uninstalling packages from debian until i made the "jump"
<janneke>debian+guix has not always been seamless for me, certain setup things that were difficult for me worked ootb after switching to guixsd -- but ymmv
<d1rewolf>janneke: any luck with proprietary drivers like nvidia?
<janneke>d1rewolf: you possibly shouldn't ask me, i'm a pretty software freedom extremist ;-)
<janneke>ng0: txn, yeah -- just praying that build farm results of a rsn core-updates-next won't present us with too many difficult failures...oh well
<jabranham>When running guixsd to update "root" packages (i.e. not ones I've installed into my user's profile) all I need to do is "guix pull" and then "guix system reconfigure /etc/config.scm", right?
<lfam>jabranham: Every user has their own profile, including root. You can update root's packages in the same way you update your user's packages. `guix system reconfigure` updates packages that are listed in config.scm, and available for all users
<jabranham>lfam: so to fully update root packages (e.g. the kernel) I have to do "guix pull", "guix package -u", "guix system reconfigure /etc/config.scm"?
<lfam>jabranham: No. There is a difference between root's packages (installed by root with `guix package -i`) and global packages such as the kernel (from config.scm)
<lfam>To update the kernel, do `guix pull && guix system reconfigure /etc/config.scm`
<lfam>To update the packages that the root user has installed for themself, do `guix pull && guix package -u`
<jabranham>lfam: ah, OK I think that was the part I was misunderstanding. So as long as I've never "guix package -i" something as root then I don't have to worry about "guix package -u" as root.
<lfam>katco: There are a few ways people keep track of the patch queue. I just use email, some people use emacs-debbugs, there is also a new thing called 'mumi' which works with this alternative interface: https://issues.guix.info/
<samplet>nckx: IIRC, Guile does the right thing when calling “system*” with “current-output-port” set. So you could probably use “with-output-to-file”.
<samplet>(As long as the output port is file-based.)
<nckx>samplet: Ah, thanks. I actually looked at with-output-to-file but it didn't seem appropriate, but I didn't try it...
<lfam>ivegotasthma: I downloaded the QEMU image from our download page, renamed it like you did, and used your QEMU invocation to launch it. I'm using QEMU 3.0.0. Once it booted, I logged in as root and did `guix package -i cowsay`. It failed but because I hadn't set up networking. Once I did that, it proceeded as normal, although I cancelled it before it was done
<lfam>ivegotasthma: Are you sure the file you downloaded is not corrupt (did you validate the signature)? Which version of QEMU are you using?
<jonsger>so will there be more stuff to build, when build guix from source janneke?
<lfam>Something to note is that it might take a few seconds for the DNS resolver to start working after using `dhclient`... this always trips me up
<lfam>The messages about repartitioning are probably too obscure, now that I read them more than a year later. They are really specific to the situation where you use the image on a VPS provider with console access but no advanced out-of-band storage management tools
<lfam>In general, you will have better results building a fresh VM image with tools like `guix system vm` (immutable VM) and `guix system vm-image` (mutable VM)
<lfam>Any QEMU experts here? I'm wondering what format our VM image actually is. `qemu-img info ...` says qcow2, but `file` says qcow3. It would be nice to keep our documentation correct