<FennecCode>Hey, so I noticed that it's been a while since GZDoom has been updated. It's a few versions behind now. Is that because of some licensing issue that I'm not noticing, or is it because of a technical issue that's being avoided?
<nckx>ruffni: You're writing a package; you probably want ‘gcc’. And yes (it should be a native-input because it runs during the build; imagine you're cross-compiling to see why).
<nckx>FennecCode: I don't think it was for licencing reasons. You can diff the old and new code to make sure.
*nckx vaguely remembers looking at updating gzdoom but has no idea what happened next…
<dstolfa>nckx: would there be any interest in guix + distcc?
<oriansj>dstolfa: guix is a scheme program, compiled by the scheme interpreter/compiler guile. Or do you mean something along the lines of enabling one to one to select an alternate C compiler when compiling packages?
<dstolfa>oriansj: the latter, so one could deal with updates when substitutes are not available on old laptops
<vagrantc>dstolfa: it woudl kind of kill the functional package management model to have some packages built one way and some built another...
<dstolfa>vagrantc: why? if you have 3 guix machines just building C or C++ files?
<dstolfa>for example, at home i have 3 computers i could leverage for distcc builds of certain things, which i already do for some things but not in guix
<oriansj>dstolfa: it is more to do with given a package definition and a known guix commit, the resulting binary should always be exactly the same.
<nckx>dstolfa: It certainly complicates matters. There's currently a blanket ban on network access from within the build environment. That doesn't make everything magically reproducible, but dropping it would open some interesting floodgates. You'd have to ensure that only distcc can communicate. Then there's the fact that Guix already supports offloading entire builds, so you'd be introducing all that complexity for a relatively minor bump in granularity from
<dstolfa>i guess it's more of a niche thing. it kind of depends on how often you build something like chromium :)
<nckx>At least Guix would be able to ensure some sanity compared to the average distcc farm: you can actually enforce that each node builds packages with the exact same GCC store item, not merely the same version.
*nckx trying hard to be ‘balanced’; probably shows.
<zacchae[m]>I'm going through the docs setting up my system config from scratch (first install). How do I find the value of variables like %base-services? The docs just say it include "a list of basic services one would expect from the system"
<vagrantc>ixmpp: somewhat depends on which bootloader ... but guix system reconfigure typically will reinstall the bootloader every time
<nckx>It's OK GRUB itself already has dangerous levels of magick.
<lambdalove-sadvi>Hi, folks! Installed guix a few days ago and I'm still trying to make it boot... mounted the fs at /mnt/guix and was grepping through the /var/log/* files, but couldn't find any hint besides some ntpd resolving error; any further tips on how to check it up?
<lambdalove-sadvi>Oh, and this: log/gdm/greeter.log:/gnu/store/ypij6xc3i9a5ksa20y44m5528jcs5a29-xorg-server-1.20.10/bin/X: symbol lookup error: /gnu/store/ix394p9k56kvfk8vzsxggrglm25szznr-xf86-video-ati-19.1.0/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate ; does that mean my GPU isn't compatible?
<lambdalove-sadvi>It goes like this: my guix only has xf86-video-amdgpu which is loaded by default. the kernel driver is blacklisted by linux-libre and won't work with linux-libre even if you install the firmware
<lambdalove-sadvi><terpri>(or maybe "blacklisted" is the wrong word, but it definitely refused to load any firmware last time i tried)
<lambdalove-sadvi><terpri>for recent amd gpus to work, you'd have to use the (non-libre) linux kernel and the standard linux-firmware repo (both of which are insufficiently free by guix standards)
<apteryx>did you do 'herd start cow-store /mnt' as mentionned in the manual?
<apteryx>it's at the top of 3.6.2 Proceeding with the Installation
<chaos`>Perhaps I didn't do it when trying with manual installation (I only did so that I could copy paste the log), but I do get the same error when trying the graphical interface (I assume the cow-store is explicitly performed there)
<florosGPL>I am on some Yocto build and I need gtk+. I installed it and there are multiple /gnu/store/<hash>-gtk+-2.24.24/ installations and .../gtk+-2.24.24-bin/. The binaries are not available via the $PATH after installation. Is there a command to reconfigure things? I tried to run garbage collection and it deleted more than it should
<urawnn>Hi all, I'm coming from gentoo, and been trying guix out. It's pretty amazing, I'll likely be migrating over the next few weeks
<urawnn>I hit a question though, if I want to compile everything from source, using my custom-built build farm, is there a way to build packages with distcc?
<urawnn>from reading the docs, I realized one can offload builds to other machines, but from my understanding, one can offload each package build to each machine, instead of using multiple machines to build one package
<dstolfa>urawnn: in short: not without some work, but you can offload builds of packages
<dstolfa>civodul: well "useful" is relative. it would be useful to me, but it's not exactly a must have
<dstolfa>basically, would be nice, but can live without kind of thing
<nckx>After a brief walk around the house, I should say that I'm not sceptical of adding distcc/ccache-like functionality to Guix (I'm not interested but it would be an awesome hack) — I'm sceptical of cutting distcc/ccache-shaped holes in the build environment isolation.
<nckx>Yes, basically rewriting their features in Guile, yes :)
<civodul>right, that's what i meant by "practically impossible" :-)
<nckx>It would be very cool, because you could use Guix features to get very close to transparent builds, but civodul is right, we can't actually buy interns by the dozen.
<dstolfa>nckx: yeah, i agree that doing this in guile would be way better
<raghavgururajan>nckx: Do you know how to make polkit-auth work for user installed packages? For example. if your try installing and running bitmast (https://issues.guix.gnu.org/48729 - v4), the polkit-auth fails. The policy file installed in correct location.
<nckx>I'm afraid I'm really not into the whole Freedesktop stack. I think it's important to support and am glad you help do so, but I don't actually *use* it.
<apteryx>one 'guix pack -f deb' current limitation: you can only install one such package at a time, otherwise they conflict. Solutions are: 1) -RR with a unique install prefix (chosen automatically?) 2) one deb per dependency. Option 2 is really cool but doesn't really fit the current 'guix pack' model.
<apteryx>longer term we could imagine option 2 directly populating the metadata files of an apt repository with the various single .deb archives. The whole of Guix collection available for apt users!
<itismyfirstday>However, I did change native-inputs to be the already existing cabal-doctest package, and can see in the build that the GHC package directories includes the one for cabal-doctest, yet still doesn't see it for some reason
<rekado_>somebody changed some Python packages to use python-distlib/next instead of python-distlib.
<jackhill>Has anyone else observed periodic crashes with sway? I am, but not sure how much energy I want to put into investigating since I see there is a sway/wlroots/wayland update on core-updates.
<jackhill>nckx: weird. At first it really seemed like ungoogled-chromium-wayland was causing it, so I switched to the X11 version, but the last couple of times not chromium was running at all. Fingers crossed that it's fixed in core-updates :)
<cbaines>vagrantc, I've often taken that approach. I'm probably going to try installing Guix on this system via Ubuntu. I can't get it to power on with the nVME drive installed though :/
<apteryx>seems our openssl only looks at its configured --openssldir (a subdirectory of its gnu store location) for certs, else SSL_CERT_DIR
<apteryx>which means people are forced to install nss-certs and have openssl installed to make it usable on foreign distributions
<rekado_>apteryx: is this a problem? It’s covered at length in the manual.
<apteryx>it's kind of suprising when you use an application that relies on openssl without the user being necessarily aware of it. For 'guix pack' it also forces me to come up with some wrapper so that the can be sourced to get the correct variables.