<yewscion>Hey Guix, quick question: What's the canonical method for specifying a specifc package output or version inside of a package definition these days? I never memorized the required syntax after the big change...
<cnx>for output it's #$(this-package-*input), not sure about version
<nckx>Hi kkcd. First of all, the ‘base32’ used in Guix package definitions isn't base32 as it's known here on earth. It's a special nonstandard flavour, designated ‘nix-base32’ in ‘guix download --help’. This format is the default so you can omit -f. Secondly, to hash a directory tree (rather than a whole file), run ‘guix hash -rx .’ in a clean git checkout that you obtained with ‘git clone’.
<nckx>(Nix tweaked the alphabet to reduce the odds of hashes containing naughty four-letter words, such as ‘guix’.)
<Altadil>Hi, I’m having a weird bug in Guix System: some clicks related to windows, like trying to move them, cause the whole display to lag. Has anyone else had this ? I’m on Gnome Wayland and it never happened before yesterday (I did an upgrade the day before).
<Altadil>What’s even "funnier" is it seems to be getting worse over time…
<RavenJoad>I can build the installer just fine without the -L flag. On guix 6a91d4b8e, I get 79gmlwqgfvclr40qq96278ya2njpj7r1-image.iso. But as soon as I add -L, I get "Wrong type (expecting resumable continuation): #<vm-continuation 7f32c3283a90>"
<podiki>apteryx: I've used colord, but not gnome and didn't notice any crashes; i'd have to look more carefully at my desktop though
<reed0>Hi all. I'm trying to get the Guix package manager working on a fresh install of Fedora. I installed it through the official "guix-install.sh" script. After install, running any variant of "guix pull" yields the following "error: guix pull: error: remounting /gnu/store writable: Permission denied"
<mirai>lilyp: is there any test/program in particular you want to run that requires a colour calibrator?
<reed0>I've tried "guix pull", "sudo guix pull" and "sudo -i guix pull". All give the same result
<efraim>apteryx: I was hoping to have more built first so I could compare it between the two
<efraim>I hadn't planned on any changes before merging, just wanted to make sure it was "good"
<nckx>reed0: Running ‘guix’ as root won't help, it's the daemon that's throwing that error. Could this be an SELinux problem? I don't know where those would be logged, but I see Fedora and I think of SELinux.
<nckx>(Note that it's just as likely as not to be outdated even if you did; it's not heavily maintained.)
<reed0>From searching, it does seem to be related to SELinux. I used all the default settings for the install script. Looking at the official documentation, it suggests that the script should handle the SELinux policy. I'll be honest, I don't really know anything about SELinux
<nckx>TBH the policy is maintained by one person and I don't think that person likes it very much.
<nckx>A common suggestion is to run ’sudo setenforce Permissive’ to disable it, but that's not a recommendation from me.
<nckx>If you chose Fedora for the NSA's secure SELinux technology, maybe don't do that. But if you do, your system should be no less ‘insecure’ than the majority of distributions which don't enable SELinux at all.
<reed0>Makes sense. I'll just disable it for now, then
<lilyp>mirai: I'd like to have consistent wallpaper colours between different screens
<nckx>reed0: Okido. It's not persistent, so if you decide that you don't like this Guix business one bit you'll be back to Enforcing on the next reboot.
<lilyp>and mere eyeballing the numbers only gets you so far
<podiki>a quick colord test I know is darktable-cmstest (from darktable) which will show what profile is loaded and with x atom
<reed0>nckx: "guix pull" works now. I do see in the documentation that on foreign distros, you need to run "sudo -i guix pull" to upgrade the build daemon. Should I do "sudo -i guix pull" every time before do "guix pull"?
<mirai>well, it can be packaged if you leave any arising firmware issues aside
<gcarlos>hi, can someone point me out how would be a workflow for developing a C program on guix? I'm a bit confused in how should I use the manifests, where to put tools not related to build (like gdb and etc) and what really gcc-toolchain installs
<gcarlos>and if I package, do I need a manifest/profile for it?
<mirai>as to how to precisely determine what should be native-input from input I don't have a precise answer other than "gut feeling" but perhaps others can weight in as to their precise definitions and characteristics
<mirai>gcarlos: having working tests is always good
<mirai>it lets you know that whatever you built was properly built and works as intended
<gcarlos>but all you all are suggesting implies packaging the software, sure?
<podiki>mirai: since I use displaycal directly like once a year (at best) to reprofile, other than using it to load profiles I haven't gotten around to looking at packaging. though it is on that long imaginary list :)
<lilyp>native inputs are inputs that are run at compile time
<nckx>Xmake is a build system that downloads its own binaries at run time. How can you be so bad at building things.
<Hmmf>Sometimes admitting failure is better than just failing :D
<nckx>jackhill: I've seen it mean (1) the path is a fixed-output derivation that contains references, IIRC? (2) $something's changed between your Guix databases' view of the store, and the store. A ‘guix gc --verify=repair’ tends to fix those. You can use ‘repair,contents’ if your storage is fast enough and/or you have the time.
<nckx>Forgot to point out that in this case, it's not (1).
<nckx>I guess it could also be caused by just the right kind of networking error (because those seem able to trigger any bug in Guix), so if you haven't yet: retry.
<jackhill>nckx: haha. Well, I alrady did contents repair, and I'm pretty sure the archive isn't corrupted. I wonder if this is the same reason substitutes aren't available for libjami
<mirai>what does the #:search-paths argument for a build-system do?
<nckx>jackhill: guix archive --export …ffmpeg-jami-6.0 | ~ The Internet 🌈 ~ | guix archive --import worked fine here.
<nckx>I'm not rubbing it in, just pointing it out. I swear there's a difference.
<jackhill>nckx: ok, let me try. The actual things I specified to archive were libjami and jami. I tried both with and without grafts
<jackhill>nckx: when I exported just the full ffmpeg path, I got "guix archive: error: path ‘/gnu/store/6fba2v1qmy9ays43m2pbda5hikwbpi6q-libva-2.19.0’ is not valid" on import. I don't know why my systems are always cursed!
<jackhill>anyway, my original question remains: why, if the build was sucessful on CI can jami not be substituted.
<efraim>jackhill: if you keep on having those issues you should probably repair your store
<nckx>Well, user using the semiautomatic footgun 2000 without watching the 2.5h instructional DVD, more like.
<nckx>I'm building jami on berlin. Often, the problem is ‘just’ Cuirass not feeling like starting any builds today, and there's nothing broken about the underlying packages. But it's still building qtbase@6, much can go wrong still.
<jackhill>usually I just use `guix publish` but these two machines don't have a good networking path between them
<nckx>guix archive + zstd + netcat can be pretty sweet.
<efraim>I never considered compressing the output of guix archive
<jackhill>nckx: thanks! Per earlier discussion, there may be a timeout issue with one of the tests, but it's weird that ci has one of the three outputs available (according to weather)
<apteryx>was there a reason *not* to have /run on a tmpfs on Guix System?
<RavenJoad>Guest28: I am about to migrate my website to Guix system and it will use 1GiB of RAM. Using guix deploy, it is very possible. Initial install and first reconfigures will need to be small though.
<nckx>jackhill: berlin should have a substitute for jami now.
<nckx>If not relevant for you, then perhaps for someone else.
<apteryx>qtwebengine makes it to 23922/27300... suspense
<apteryx>haha, it failed after the main compilation target was done
<mirai>apteryx: other than an extremely obscure issue with GDM&wayland that has long been fixed, no