IRC channel logs


back to list of logs

<mvnx>RE: my above message... Maybe it was just a mirror issue? I ran `guix pull` as my user, it updated from `` instead of `` and then I ran the same `sudo guix system reconfigure ~/.config/guix/system.scm` and it still gives the provenance warning but updates guix channel from a working mirror, I guess?
<mvnx>Is the first `guix pull` not necessary? Anyway, I didn't change the configuration file, just copied to a new file and tried a `guix system reconfigure` with it and when I reboot I get an e2fsck bad magic number in superblock error - . It's tough to keep testing this because the guix system reconfigure takes like 30 minutes. Any suggestions?
<rekado>“guix pull” will always fetch from, because that’s where the “guix” channel itself is hosted
<rekado> is only ever used as a fallback when source code origins cannot be reached
<rekado>“guix system reconfigure” without changes should be pretty quick. < 1 minute.
<mvnx>Thanks, that's helpful. Maybe just bad timing because all my guix pulls were going to softwareheritage. So my bigger issue is the `guix system reconfigure` using the configuration file found at `guix system describe` (copied to a new file) took a long time and put the VM in an unbootable state
<sammm>hi, relative guix newb here. has anyone built a guix system for an odroid xu4 sbc? i am playing around with defining images/bootloaders etc...
<mekeor[m]>sammm: there is this commit which removes uboot bootloader for odroid c2:
<yummy-sandwich>"gnu: u-boot-odroid-c2: Remove variable. · guix-mirror/guix@2bb915e · GitHub"
<mekeor[m]>idk anything else
<sammm>thx mekeor[m] , looks like the upstream u-boot doesn't have a board definition for xu4.. but there is for xu3, etc.. will play around
<mekeor[m]>what would be a good approach to implement a feature for guix-search to search for a package within the whole git-revision-history of a channel?
<mekeor[m]>the goal would be that you find out where to time travel in order to install the specific package with the specific version you want
<mvnx>`sudo guix system reconfigure $config` reliably reaches out to the fallback, and subsequently fails, on the 1.4.0 QEMU VM. Is this expected?
<johnabs[m]>Hey all! Anyone here happening to use sbcl-coleslaw on guix? I've run into a funky issue that seems to stem from the read-only file system when I try to create the Clack server to preview my edits.
<the_tubular>How do I stop gdm from starting ?
<oriansj>the_tubular: disable the service or not even install it in the first place
<the_tubular>Can i call shepherd for now and stop it ?
<the_tubular>pkilling it restarts it
<bdju>wlr-obs build failure and mako build failure. here's mako's log:
<oriansj>the_tubular: you need to do herd stop as root
<oriansj>herd stop ${service_name} to be more precise
<bdju> wlr-obs log
<the_tubular>Thanks oriansj that worked
<the_tubular>I always think of shepherd and not herd ...
<apteryx>rekado: you are right, it's because of fluidsynth/lash
<apteryx>python2 as well...
<apteryx>lash: Building the following 434 packages would ensure 832 dependent packages are rebuilt
<apteryx>a bit of a stretch for master, but we can do it on staging, it seems?
<apteryx>seems there exists something called ladish which is a drop in, actively maintained replacement
<apteryx>I could build fluidsynth without lash fine
<yewscion>Hey all, anyone know why GNU Cuirass would be reporting that its schedulers are blocked when no one else is using the system? I have an instance that has both of its schedulers blocked for 4000+ seconds at this point.
<apteryx>sounds like a bug
<apteryx>you can report it to bug-guix with a [cuirass] prefix
<yewscion>Copy that, will do. Thanks!
<Lumine>Good morning #guix
<CoinCoinME[m]>is cuirass a system like jenkins?
<attila_lendvai>this tripped me up just now: the variable 'fontconfig' holds a package named 'fontconfig-minimal'
<pjals>Hey, has anyone attempted to make a NanoPi M4 image with/using Guix? I tried to make one based off RockPro64 but it didn't go so well.
<pjals>I skimmed over the sources and it looks free (libre).
<oriansj>pjals: Well Pi Systems in generally require a GPU blob to boot the processor if I remember correctly but there is work being done to liberate that.
<yummy-sandwich>"GitHub - librerpi/rpi-open-firmware: Open source VPU side bootloader for Raspberry Pi."
<futurile>anyone watching the Guix talks at FOSSDEM:
<klm_>The font rendering / layout is a bit strange when I'm using `evince`. What could be causing that, a missing font? I did not install all of gdm, just evince (I'm using just xorg-server and i3-wm).
<jonsger>klm_: could you post a screenshot somewhere?
<klm_>jonsger: of course: <> As you can see, the spacing is a bit off. I don't know where to start looking
<yummy-sandwich>"ss-2023-02-04-12-41-15 hosted at ImgBB — ImgBB"
<klm_>and some of the icons on the side-menu are missing. So I'm missing a package somewhere, I'm pretty sure - but which one?
<whereiseveryone>sneek: later tell roptat: this might be a nice one to package, a weblate CLI
<sneek>Will do.
<yummy-sandwich>"~whereiseveryone/guixrus#1210: wlc
<klm_>jonsger: sorry about the bombardment, but here's the same secion rendered in mupdf, which looks much better:
<yummy-sandwich>"ss-same-secion-rendered-in-mupdf hosted at ImgBB — ImgBB"
<jonsger>klm_: the font rendering inside evince is some issue of itself, AFAIK. It can be much worse for some PDFs. The missing icons is some Guix stuff
<jonsger>are you using Guix on a foreign distro or as Guix System?
<whereiseveryone>jonsger: thanks again for all the stickers! ;()
<klm_>But I'm starting x11 using `sx` which means I need to add fonts and all sorts of things to get basic functionality working.
<klm_>I suspect `evince` would have worked properly if I'd had `gdm` and all its friends.
<jonsger>whereiseveryone: your welcome :)
<Parnikkapore_m>I'm trying to run uxnemu (a basic SDL2 app) in 'guix shell -C' for funsies; it says it couldn't find the display. What flags should I pass to get it working?
<jonsger>klm_: I know it was an issue for myself, but don't ask me how I fixed it (maybe by using SDDM)...
<jonsger>ACTION using `guix build --system=aarch64-linux hello` on a foreign x86_64 distro still feels like magic...
<klm_>jonsger: ok, thanks anyway :-) I'm actually trying to learn how to use MuPDF instead.
<pjals>oriansj: isn't that only for the rpi?
<oriansj>pjals: well it supports the following pi systems:
<yummy-sandwich>"Test other models · Issue #31 · christinaa/rpi-open-firmware · GitHub"
<apteryx>rekado: I have a patch series removing lash; jami no longer depends on python2, sizes is reduced by about 50 MiB
<apteryx>next target to remove would be gtk+@2
<dcunit3d>how do i get straight to clone repos properly if i?
<dcunit3d>if I'm starting emacs from within a guix shell?
<dcunit3d>i'm getting certificate verification failed CAfile: none CRLfile: none
<dcunit3d>magit also fails to fetch for the same reasons
<apteryx>dcunit3d: try adding nss-certs and git or another package that causes SSL_CERT_FILE to be set
<apteryx>are you working from a --pure guix shell? otherwise it should pick SSL_CERT_FILE from your environment and juts work, if your environment already does
<dcunit3d>i've added nss-certs to the manifest
<dcunit3d>yeh, i'm launching from within an xsession on arch
<dcunit3d>it seems to work when i back out to a vty
<dcunit3d>no, it's just `guix shell -m manifest.scm --check`
<dcunit3d>one sec, i didn't copy the manifest over
<apteryx>OK, but this being launched from a foreign distro's xsession it probably lacks a pre-configured SSL_CERT_DIR/SSL_CERT_FILE
<apteryx>so add git or curl or whatever has a search path for it to your profile
<dcunit3d>git is in the profile. i think once i run `guix pull` for the profile, it will work
<dcunit3d>i'm trying to mix straight and guix dependencies, following the guix-home branch on
<dcunit3d>ok yeh, there it goes
<a12l>Is rustfmt supposed to be part of the rust component? Unsure how to interpret the guile code.
<yummy-sandwich>"rust.scm\packages\gnu - guix.git - GNU Guix and GNU Guix System"
<mirai>what's causing this error?
<yummy-sandwich>"Untitled - Pastebin Service"
<mirai>is there a way to troubleshoot why this file-system herd service fails
<mirai>is it possible for /etc and / to reside in different partitions?
<lfam>Any plans for dinner in Brussels tonight?
<sneek>Welcome back lfam, you have 1 message!
<sneek>lfam, nckx says: Using the patented debugging technique of ‘hopelessly dig around for relevant logs; give up and herd restart the world’, evaluations have been resumed.
<lfam>Heh, thanks nckx
<mirai>it's not your usual setup but I'm suspecting the file-system-service runs before account-service-type and this doesn't work if both the account and file system are created as service-extensions
<mirai>the uid=...,gid=.... options will make the mount fail?
<mirai>what provides lua-http ain guix?
<Obikawa>Hi. Is it possible to use git-fetch to use a >local< GIT repository?  I have been blindly trying to install a patched version of emacs-org-fc without any further success after hitting a "fatal: '/home/marek/src/org-fc' does not appear to be a git repository".
<yummy-sandwich>"Document git-checkout"
<Obikawa>Thank you.  I had the feeling I was on a wrong track.  I can work with this.
<mirai>alternatively, you can spin a git-daemon-service-type instance
<Obikawa>mirai, will I be able to call localhost in the git-fetch + git-daemon-service-type solution?
<mirai>sure, why not?
<mirai>as long the host can be resolved, it can point to anything
<Obikawa>mirai - I am a programming noob, so I would rather ask first before diving in.
<tedium>is there a way to configure guix system to attempt to decrypt every hard drive with a given password? I don't want to put in the same password 4 times for my root drive and 3 RAID drives.
<a12l>I've a question about rust development on Guix, but I suspect that the people that knows how to do that isn't active on IRC when I'm. Where is the best place to send such questions? The general mailing support list?
<a12l>Also can't find any relevant information when I search on Google, so I suspect that there isn't a big guix-rust ecosystem out there. :(
<mvnx>Fresh 1.4.0 QEMU VM. I try `guix system image --image-type=qcow2 $(find /gnu/store/ -type f -name vm-image.tmpl | head -n 1)` it consistently tries to pull from `` and then fails with a giant stacktrace. Any way to force it from `` instead?
<unmatched-paren>evening guix :)
<unmatched-paren>is there anyone around who could review dissecting guix part 2 v3? :)
<mirai>I'd be interesting if guix could get some sort of opt-in telemetry
<mirai>data points of immediate interest would be: services and packages used (naturally, it should only report the ones distributed with guix)
<mirai>This could be used as some sort of early warning for potential bitrot in services/packages
<tasankovasara>btw. is there a repository of packages (compiled or not) that I could rsync to have a local mirror (like with Arch and Arch ARM presently)?
<unmatched-paren>tasankovasara: guix doesn't really have a repository of package sources
<unmatched-paren>every package is built from source (or downloaded from the CI, which compiles them automatically)
<unmatched-paren>using the package definitions in the Guix source code, which is locally downloaded every time you do ``guix pull'
<unmatched-paren>i'm not sure whether you'd be able to do something like that for the compiled packages on the CI, but even if there was i don't really see the point
<unmatched-paren>because they'll become outdated really fast and anyway it's probably less work to just compile things when you're offline
<unmatched-paren>wait, when you're offline you wouldn't be able to build things...
<unmatched-paren>because you need to be able to download the tarball/git repo from the original source...
<unmatched-paren>cloning every single ``source'' object into your store is, needless to say, A Bad Idea :)
<tasankovasara>unmatched-paren: I'm kind of prepping here for the big Internet down event, as you figured out :D
<tasankovasara>but guix is really sexy, might be tempted to switch even if there's no easy way to have a selection of software locally available and updated
<unmatched-paren>tasankovasara: i'm afraid there's nothing much you could do other than maybe set up your own Cuirass (the CI infrastructure we use)
<unmatched-paren>if you have a server
<unmatched-paren>that is currently not being used
<unmatched-paren>which is, admittedly, unlikely :)
<tasankovasara>unmatched-paren: cheers, I'll take a look
<tasankovasara>the server shall abide :D
<unmatched-paren>tasankovasara: well, if you do have an unused server lying around, then you can just set up Cuirass on it (disclaimer: i have no idea how to do this) and make it build only the master branch
<unmatched-paren>that way, it will download and build everything on master
<unmatched-paren>and then you can set that server as one of your Guix's substitute sources
<tasankovasara>unmatched-paren: that's pretty much perfect
<unmatched-paren>not entirely sure how you'd get your Guix to treat it as a "local" thing, not just as any other substitute server accessed through the internet :(
<unmatched-paren>but if you can get over that hurdle, i'm pretty sure it should work
<unmatched-paren>i *think* there might be something you can do with the Avahi LAN daemon, which Guix supports in some way?
<unmatched-paren>Not sure whether using that requires an Internet connection though
<unmatched-paren>disclaimer: i may be talking complete nonsense. it's possible none of this will work
<unmatched-paren>but, hey, it's worth a shot :)
<tasankovasara>good pointers, I'm grateful
<tasankovasara>I haven't got a Guix system to play around with yet, but I'll be looking into hosting a package source and such
<unmatched-paren>and if it does work, maybe you could add a "Setting Up a Local Substitute Server" section to the cookbook <> :)
<yummy-sandwich>"GNU Guix Cookbook"
<unmatched-paren>oh, hmm. "cookbook"
<unmatched-paren>"the cookbook"?
<unmatched-paren>okay. the cookbook
<tasankovasara>absolutely :D
<unmatched-paren>hmm. i wonder how you trigger that yummy-sandwich link.
<unmatched-paren>oh, does it just provide the <title> of any page you link to...?
<yummy-sandwich>"Wikipedia, the free encyclopedia"
<unmatched-paren>ah, yeah, cool
<vagrantc>tasankovasara: there is *some* sort of mirroring possible, i know it was/is done with at least one mirror in china
<vagrantc>another option would be to run "guix build --source" on all the stuff you are interested in while you're still online ... then you would at least be able to build any of those things
<vagrantc>while offline ... although there are probably some surprises along the way
<vagrantc>similar with a caching proxy ...
<gabber>i'm trying to bump sway but it refuses to acknowledge my update of wayland to 1.21.0 and keeps saying it only finds 1.20.0
<gabber>*wayland-server that is. is that not part of the package `wayland`?
<unmatched-paren>gabber: it is part of it
<mirai>can someone test if `guix build lua-cqueues` succeeds?
<gabber>mirai: fails for me
<mirai>so this is to be reported as a non-reproducible bug?
<two[m]>also fails
<gabber>mirai: why non-reproducible?
<gabber>or does it build on ci.guix?
<mirai>ah, my bad, I meant to say broken package
<gabber>unmatched-paren: is that supposed to be a binary? i cannot find it within `guix build wayland`
<unmatched-paren>gabber: there is no such thing as a wayland-server binary
<gabber>mirai: :) so i guess yes, reporting seems appropriate (if it hasn't been reported already)
<yummy-sandwich>"Search results"
<gabber>wow yummy, that's hella helpful /s
<tasankovasara>gabber: wlroots is what sway depends on
<unmatched-paren>yeah, you'll need to update wlroots too
<unmatched-paren>pretty sure you also need to update libdrm... lots of fun all round :)
<gabber>the funny thing is: i think i checked all sway's dependencies for anything matching version 1.20.0 (the one it complains about no being 1.21.0) -- only package wayland matched. so i updated that and am able to build it but sway just... ignores that fact?
<unmatched-paren>gabber: build log s'il vous plait :)
<unmatched-paren>what is the output of ``cat $(guix build your wayland here)/lib/pkgconfig/wayland-server.pc?
<unmatched-paren>what's the build command?
<gabber>./pre-inst-env guix build wayland
<gabber>the really weird thing is, though, that i *only* updated the version field in the wayland definition.
<unmatched-paren>of course it doesn't work :)
<unmatched-paren>you need to change the source hash too...
<gabber>it is built successfully, though
<neshamon[m]>Does anyone else have issues adding sddm to their config?
<unmatched-paren>well, yes, it doesn't recognise that it even needs to be rebuilt
<gabber>and i honestly don't know what to change it to if guix doesn't tell me the expected hash value
<unmatched-paren>because you didn't change the hash :)
<unmatched-paren>you need to download the source and hash it with ``guix hash -rx''
<gabber>this usually suffices
<unmatched-paren>or if it's a tarball you can just ``guix download URL''
<neshamon[m]>I keep getting an error saying xorg-server is provided more than once when I add it with set-xorg-configuration
<gabber>weird.. i did as you said, unmatched-paren but the hash wasn't correct. but altering the hash made guix re-download the source, check the hash and tell me that the one i entered was wrong
<gabber>shouldn't guix try to download new sources when i change the version field (which changes the download url)?
<gabber>sway seems to build fine now, so thanks to all'yall
<gabber>neshamon[m]: did you add more than one xorg-service? would you mind sharing your config (or at least the (services ..) s-exp)?
<neshamon[m]>My services looks like:... (full message at <>)
<neshamon[m]>My services look like:... (full message at <>)
<gabber>maybe lxqt and sddm both provide an x-server? i guess providing the sddm server ought to be enough and just adding lxqt to the system wide packages might make it available within sddm
<gabber>never tried any of that, though
<gabber>the new sway needs wlroots version >=0.16.0 but only 0.14.1 has been released?
<gabber>ACTION just realized they moved *all their repos* to gitlab
<vagrantc>gabber: if a matching hash is already in the store, guix will in some cases just use that regardless of the version field
<vagrantc>i've definitely been tripped up on that beffore
<vagrantc>the version numbers in guix are more for the user interface ... when it comes down to it, guix really just relies on hashes
<gabber>it's still weird. the other packages i'm updating rn trigger a source re-download... is it possible there's a bug because the new source (with the version-string in the url) cannot be found?
<vagrantc>maybe you don't have the exact hash of the other sources in your store already?
<vagrantc>and so it triggers a re-download...
<vagrantc>and then checks the hash...
<gabber>would you mind trying just setting the version string of the package wayland to "1.21.0" and see whether guix asks for a better hash?
<vagrantc>don't have it handy at the moment
<unmatched-paren>gabber: how guix works is that each package is compiled into a derivation <> and this is used to tell the daemon how to build the package. the daemon checks to see if the derivation needs to be rebuilt by checking if the hashes of any of the inputs have changed
<unmatched-paren>here "inputs" means ``inputs'' plus ``native-inputs'' plus ``propagated-inputs'' plus the source code plus the builder script
<gabber>thanks! haven't read that one, but i'm looking forward to! but: changing part of the recipe of the build usually also triggers a rebuild (bc the hash of the package itself changes), right? maybe i found a bug -- would you mind checking for me what happens if you alter your wayland package version string to "1.21.0"?
<nckx>gabber: If the file exists upstream, guix will download it, using the 'basename' of the URL, which won't exist yet; then it will check the hash and fail (suggesting the right one). If the file does NOT exist upstream, guix will also use the upstream URL's basename BUT download from a content-addressed mirror--it will create a new file with the old contents.
<nckx>No real way around that with only a CA mirror AFAIK.
<unmatched-paren>gabber: the version string is **not** part of what goes into the derivation
<unmatched-paren>it only affects the ``guix'' ui
<unmatched-paren>(along with binding the string to the ``version'' symbol)
<nckx>Why would it not be part of the derivation?
<nckx>In wayland's case I mean.
<nckx>It's not a git repo with forgotten file-name.
<gabber>unmatched-paren: but the source of the package does, right? and when the version's a part of that (which it often is)
<nckx>If it's part of the basename (part after last '/') yes.
<nckx>It's true that the 'version' as a discrete value does not get hashed. The file-name does, and since it includes the version, the effect is the same.
<nckx>Anyway TL;DR you did not find a bug.