IRC channel logs


back to list of logs

<nckx>ss2: Did you stop cow-store and unmount all file systems before rebooting? (It ‘should’ do so for you, sure, but…)
<bjc>ss2: and you're currently booted from a recovery usb stick with the old install mounted in /mnt?
<ss2>It chickens out saying: chroot: failed to run command "/bin/sh": Exec format error
<ss2>bjc: yes
<bjc>there should be old grub.cfg files sitting around in the store from your existing install then. try ‘find /mnt/gnu/store -name grub.cfg’
<ss2>nckx: can't tell at which spot the system crashed.
<bjc>might take a bit, but hopefully you'll get one you can work with
<ss2>hm, good idea!
<bjc>i'd be worried that other stuff has gone wrong, but if you can get it booted you should be able to roll back to a previous system
<nckx>ss2: ‘Exec format error’ is different from ‘No such file or directory’. Not that I know what it means here.
<bjc>32 vs 64 bit?
<ss2>ups, I need to boot with more bits ^^
<bjc>i'm just guessing. it's the only thing that comes to mind that would return that error
<nckx>Oh… is gparted live 32-bit?
<nckx>That would definitely throw that error 😃
<ss2>no, it can be 64 and what not. Must have needed 32-bit recently..
<apteryx>what's up with Cuirass?
<apteryx>FATAL: remaining connection slots are reserved for non-replication superuser connections
<nckx>Oh, that **** again.
<nckx>Are you on guix-sysadmin@?
<nckx>See Mathieu's latest reply, although there's no answer yet.
<apteryx>yes, I'll have a look after the evening family routine
<nckx>Should I leave it hanging for you or restart cuirass/psql to make it run for another while?
<ss2>Okay, I've got a chroot running now. But now I've only got an sh. Nothing else.
<bjc>everything else is going to be loaded from a profile
<bjc>is there an /etc/profile in the chroot?
<ss2>sure, just sourced it.
<bjc>groovy. you should the system installed stuff then
<bjc>or what nckx said ;)
<nckx>Don't forget to (bind-)mount stuff like /dev, /proc, /sys, … if you haven't yet.
<nckx>Tools will go nuts without them.
<ss2>nckx: did that.
<bjc>if you intend to try to roll back from the chroot, you need the guix daemon started
<ss2>But now I've got to inpersonate my user profile to access my pull generations. No/
<ss2>I'd need to have /boot repopulated again.
<bjc>the guix daemon does all the actual work of interacting with the store and setting up symlinks etc
<ss2>bjc: btw, find /mnt.. -name grub.cfg didn't find anything.
<nckx>You should be able to directly invoke ~user/.config/guix/current/bin/guix.
<nckx>As well as -daemon btw.
<bjc>ss2: oh right, of course it won't. the file is generated so it'd have a hash prepended. sorry. ‘find -name \*grub.cfg’
<nckx>‘find /mnt/gnu/store -name \*grub.cfg’, note the *.
<nckx>Or what bjc said I guess that will *probably* work.
<bjc>no, you need the path, i think
<nckx>(Not if you're in /gnu/store already, but I wasn't serious anyway.)
<nckx>Just laggin'.
<bjc>really? we move further from god^H^H^Hposix every day
<nckx>No, you're right.
<nckx>The . is muscle memory at this point.
<nckx>Let's test…
<nckx>…it works without it but I'll keep wastefully typing it until I die.
<nckx>Or use a BSD system I guess?
<drakonis>nckx: there is one caveat regarding the drivers, the ones nvidia published only function with turing and beyond
<drakonis>it doesnt support older hardware
<drakonis>there might actually be a punchline
<ss2>eh, easy way out: randomly copied grub.cfg from the store to /boot/grub. Booting again. Thx! :)
<drakonis>the why? the gpus it supports are actually using specific hardware where all the proprietary juice is
<ss2>Could be smarter though to check which one was the most current.
<drakonis>and this proprietary juice is not in hardware on the older gpus
<bjc>ss2: once you're up, i'd roll back and reconfigure just to be safe
<nckx>Now because more proprietary.
<nckx>Meh, not a discussion I want to flare up, sorry, ignore me.
<bjc>although, thinking about it: one of the things the grub.cfg does is specify which generation you're on (from the cmdline option to the kernel). so you should /already/ be rolled back at boot time
<ss2>bjc: yes.
<nckx>If this were my system I'd run a fsck on it, just to be safe(r).
<ss2>I've no idea at which generation I am right now.
<bjc>it should check on boot, but it doesn't hurt to do it again
<bjc>guix system list-generations
<nckx>bjc: Depends on the fs type.
<bjc>iirc all the currently supported ones that can be checked are being checked
<bjc>looks like the only one that isn't is nfs, for the obvious reason. maybe some of the check-*-file-system procedures are stubs, though
<nckx>Not unconditionally, and not—well, I rewrote most of the fsck calling code, it's… complicated. Messy. Yech. I'd always recommend booting with fsck.mode=force after fs weirdness, but it's just me.
<ss2>somehow the most current generation is quite broken: guix system list-generations throughs an error there.
<horizoninnovatio>Good morning! I'm trying to set up evolution with gmail accounts. I've install evolution-data-server and glib-networking & rebooted. The error I'm getting is "TLS support not available". How do I fix this? or is there a better email client that works well with gmail?
<ss2>rolling back, then rebooting.
<bjc>good luck
<ss2>I can't. I get that same error again.
<bjc>missing grub.cfg?
<bjc>the guix pull should be safe
<bjc>you may be able to ‘guix gc’ to clean up unreffed generations and get rid of the newer ones as well
<ss2>I can't. Even when trying to delete the most current generation fails. Rolling back fails too. Booting an older generation is fine though.
<ss2>I'm pulling now.
<nckx>The only ‘guix gc’ command I would dare run at this point is ‘guix gc --verify=contents,repair’. I see no advantage in deleting things.
<ss2>I was just reading that!
*nckx -> zzz. Good luck ss2.
<ss2>thx, I shouldn't be doing these things late at night too.
<nckx>apteryx: I've restarted the service anyway, just to (hopefully) get things moving for now.
<bjc>i think these issues wait for late at night to appear
<nckx>ss2: They always have a sense of timing don't they? Bed bugs, for sure. Night!
<bjc>"bed bugs" i'm going to have to remember that
<ss2>Good call though. Gc is found two corrupt items. One is grub.cfg and a raw-initrd file.
<ss2>*just found..
<ulfvonbelow>I had to 'kill -9' my X server, but now when I try running 'sudo herd start xorg-server' it outputs to /var/log/Xorg.0.log '(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)'
<ulfvonbelow>I already did rm -rf /tmp/.X11-unix
<ulfvonbelow>well, strictly speaking, I didn't 'kill -9' my X server, it crashed and died, and I had to 'kill -9' slim after that over ssh
<ulfvonbelow>I'd like to resolve this without rebooting if at all possible
<ss2>ulfvonbelow: are you sure that you've got no dangling xsession left over?
<ulfvonbelow>I'm not sure what that means, and how would I check that?
<ss2>look at your process list. Have you got htop available?
<ulfvonbelow>'ps auxww | grep xorg' yields nothing
<ulfvonbelow>ran htop in guix environment, apparently slim is running at 100% cpu usage
<ulfvonbelow>and strace isn't reporting any system calls from it whatsoever
<ss2>Have you killed it yet? Its childprocesses too?
<ulfvonbelow>if htop displays processes as a tree, it had no child processes
<ulfvonbelow>yes, I killed it and attempted to start it under strace
<ulfvonbelow>but it looks like I need to set some environment variables
<bjc>did killing it actually kill it?
<ulfvonbelow>kill -9 did
<bjc>you checked? i'm only asking because drm can make some things not work that used to always work
<ulfvonbelow>ps auxww | grep slim reported a new pid that was autostarted by shepherd, so I assume the old one died
<bjc>have you tried to ‘herd stop slim’?
<ss2>bjc: it isn't looking good actually. Several items are are corrupt. Mostly system-activation, grub.cfgs, no idea how I managed this. Gonna have to start from fresh then.
<ulfvonbelow>herd: service 'slim' could not be found
<bjc>ss2: well, at least you have your system config and home config to work from?
<ulfvonbelow>(I believe the shepherd service goes by the name 'xorg-server')
<bjc>ulfvonbelow: it may not be called slim. try xorg-server?
<ulfvonbelow>yes, I tried that
<ss2>yes. It's no loss.
<bjc>ulfvonbelow: if you can't stop xorg-server, and slim keeps restarting i'm not sure what to do
<ss2>ulfvonbelow: maybe stop the service first?
<ulfvonbelow>it worked to stop xorg-server, I'm currently trying to manually start it under strace
<bjc>oh, so slim isn't running anymore?
<bjc>ok. that's somewhat sane then
<ulfvonbelow>it seems to pass the slim config file name through an environment variable so I need to go hunt down the proper value for that
<ulfvonbelow>[pid 9424] bind(8, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = -1 EADDRINUSE (Address already in use)
<bjc>can you lsof it?
<ulfvonbelow>lsof: status error on /tmp/.X11-unix/X0: No such file or directory
<bjc>oh right, you deleted the file
<bjc>huh... this is a situation you find yourself in
<bjc>it's really weird that you can delete the file and the x server is still returning eaddrinuse
<lechner>Hi, is there a way to speed up guix pull -l ?
<ss2>bjc: I did manage to roll back. To a much older generation. Which is good. So I might just clear the generations, do a gc, and reconfigure afterwards?
<ss2>that should work.
<bjc>yeah, if things are looking ok
<bjc>good luck!
<ss2>Gonna do it tomorrow instead. Getting much later than expected. :)
<bjc>at the very least, your trials today have convinced me that zfs-on-root is still a good goal to work towards. being able to simply roll the whole filesystem back to a previous snapshot would have solved all of your problems almost instantly
<ss2>maybe. I'm also suspecting that this mainboard is going a bit crazy unfortunately. It has shown some odd freezes, and now this.
<bjc>it does seem like something bad happened when writing to the disk. might want to check your smart stats
<bjc>(but zfs protects you from that too)
<ss2>Read Error Rate is at a very hight value..
<ulfvonbelow>is there some sort of weird containerization happening with slim or the X server?
<bjc>ss2: eep
<ulfvonbelow>that's the only explanation I can think of for why my test program gets ENOENT while the X server gets EADDRINUSE
<bjc>ulfvonbelow: not that i know of, no
<ss2>the disk is old. The whole thing is old.
<bjc>and for random x clients to work, the socket needs to be available in the normal file system, so there'd have to be a bind mount from a hypothetical container to the host to make it available
<bjc>as a last resort, you could do something like: for i in ps axugww; do; lsof -p $i; done
<bjc>just dump everything and see who's got it open and where
<ulfvonbelow>hmm... I think I may have found a bug in our slim-shepherd-service (gnu/services/xorg.scm line 587). Specifically: (false-if-exception (delete-file lockfile))
<ulfvonbelow>this takes place within a gexp that doesn't have a definition for lockfile
<ulfvonbelow>the exception raised from evaluating an unbound variable gets suppressed by the false-if-exception though
<ulfvonbelow>so the lock file doesn't actually get deleted there
<ulfvonbelow>bjc: I ran: for i in $(sudo ps axo pid); do sudo lsof -p $i; done
<ulfvonbelow>then searched through the entire output for .X11
<ulfvonbelow>no results
<ulfvonbelow>I ran sudo /gnu/store/dhxiv0d8n04sa5z6z88ggwnw41fsjh0p-inotify-tools- /tmp/.X11-unix/ while starting slim, and it said "No events occurred."
<emacsomancer[m]>I'm having trouble updating, 'mutter' seems to get stuck on the 'check' phase. I see some older irc mentions of this issue, but nothing about how to work around it.
<mekeor[m]>emacsomancer[mx]: maybe mention the nick here and also clearly define your issue here, e.g. with logs
<bjc>ulfvonbelow: i'm out of ideas. you may need to reboot =(
<bjc>emacsomancer: i had that issue yesterday. ^C and restart seemed to fix it
<bjc>happened two or three times (i was testing things, so did a bunch of reconfigures)
<horizoninnovatio>What's the best time of day to ask questions?
<mekeor[m]>quite some guixers live in europe, so maybe don't ask the most difficult question at 3am utc
<bjc>seems to be around noon utc things are fairly active, but a lot of people read scroll-back when they get back to their computer, so you can ask any time
<bjc>you'll probably want to stick around, though, since it can take hours to get an answer for some things
<bjc>there's also the mailing list
<Aurora_v_kosmose>> I was at the 5th RISC-V Workshop in 2016, and heard Eric Grosse, then Google's VP of Security and Privacy, say that a future without risc-v was too scary to consider. | Considering the counterproductive attitude of the RISC Foundation, this seems oddly optimistic to me.
<bjc>i get that license fees are a problem, but honestly i don't see what the big deal is with the riscv isa. it doesn't seem particularly revolutionary
<Aurora_v_kosmose>That's part of the issue. It's insufficient without extensions.
<littlebobeep>Aurora_v_kosmose: The author of that post has claimed there are potential patent infringements with RISC-V but I am not sure which
<ulfvonbelow>inotifywatch /tmp *does* report the creating and unlinking of the "/tmp/.X0-lock" file, for whatever it's worth
<Aurora_v_kosmose>littlebobeep: Honestly, I'm more concerned by the documentation & NDAs aspect.
<Aurora_v_kosmose>NDAs have no place in Libre development.
<bjc>i'm confused as to how riscv can even *have* an nda
<Aurora_v_kosmose>Proprietary extensions are basically necessary to make the ISA useful for a number of things.
<Aurora_v_kosmose>Or alternatively you have to make your own.
<littlebobeep>Aurora_v_kosmose: Are there actual NDAs for the ISA spec?
<bjc>i haven't done a tremendous amount with risc-v, but the published (mostly lettered) extensions seem to cover the standard use cases
<oriansj>and the lambda core is good enough to do everything (perhaps not as fast or as energy efficient as extensions may be)
<Aurora_v_kosmose>littlebobeep: For core RISC-V no.
<Aurora_v_kosmose>oriansj: That might be a stopper for a project that intends to create Libre (and effective) general computing hardware
<littlebobeep>oriansj: Searx returns nothing on risc-v lambda core, what is that? should be a LISP processor lol
<oriansj>Aurora_v_kosmose: Depends on how hard core the people are
<Aurora_v_kosmose>I wish we'd get Lisp processors again.
<oriansj>littlebobeep: the lambda core of anything in software/hardware is variables [storages], conditionals [jump if zero], iteration and recursion [call/return]
<Aurora_v_kosmose>Using general logic units for GPU work would be horrendously inefficient.
<oriansj>Aurora_v_kosmose: we can and we probably have some for FPGAs (if not that would be surprising)
<littlebobeep>Aurora_v_kosmose: someone in #fsf claimed they were much less efficient than Von Neumann chips with software LISP interpreters, but when I asked why or how they did not answer
<littlebobeep>oriansj: I have not found any HDL code for such designs in my searches
<bjc>in terms of extensions, i thought it was explicit that the point of risc-v was to have an open general purpose isa that corporations could build vendor extensions on
<Aurora_v_kosmose>littlebobeep: Yeah... I think outside of asking someone who worked with them, few might know.
<oriansj>Aurora_v_kosmose: well a framebuffer isn't very complex in terms of hardware and definitely outside the scope of any patents (that haven't already expired)
<bjc>risc-v was only ever made to eat arm's lunch, but otherwise preserve the status quo
<bjc>google, apple, et al were tired of paying the arm tax. so we got risc-v
<oriansj>littlebobeep: tragic, FORTH chips are a dime a dozen
<oriansj>also people have made graphics chips that run on the iCE40 FPGAs
<oriansj>so might not be able to do 4K streaming video but it appears good enough for a productive computer
<littlebobeep>oriansj: Yeah not 4K but 480p is pretty terrible
<the_tubular>builder for `/gnu/store/asi7iylmam00w8hrh7bpxmifcszyylx6-guix-package-cache.drv' failed to produce output path `/gnu/store/n83dqnbagkcg5f7829sq8kc107f03yjk-guix-package-cache'
<the_tubular>I'll investigate, but guix pull is erroring for me
<apteryx>the_tubular: that seems a problem in the current guix
<apteryx>the CI is stumbling on that error as well:
<the_tubular>Any idea why it's happening ?
<the_tubular>I can't read that traceback at the end :/
<kitty1>ayyy nice to hear the news from nvidia ; wonder what made them do that? small step but a cool one
<the_tubular>Lapsus behind the scene /s
<kitty1>still not nearly enough, hope whoever is responsible keeps up the heat!
<Aurora_v_kosmose>littlebobeep: According to folks over in #lispcafe, LispMs have nothing that dooms them to be slower, newer CPU generations just weren't made as fast as the rest of the industry and didn't catch up.
<kitty1>what advantages did/do lisp machines have when working with lisp, apart from presumably being more elegant for systems designed around lisp?
<kitty1>err or rather would anyone know a good source to read more about that?
<Aurora_v_kosmose>Processor-wise, a lot of the type checks & GC operations were directly assisted in hardware.
<Aurora_v_kosmose> For an unsatisfyingly short overview.
<littlebobeep>kitty1: Did you see they are moving a lot of driver functionality into proprietary firmware, and all user-space code is still proprietary dealing with OpenGL, Vulkan, OPenCL, and CUDA?
<Aurora_v_kosmose>Ah, so that's the other boot dropping.
<littlebobeep>and it does not affect most of the GPUs without this sketchy "GPU System Processor" which allows them to offload a lot of functionality into proprietary firmware (to run on the GSP)
<Aurora_v_kosmose>Of course Nvidia being scum is par for the course.
<kitty1>littlebobeep: yeah, thats why I very much hope that people hold their feet to a fire instead of *just* celebrating.
<littlebobeep>ja #donotwant
<littlebobeep>kitty1: Most people on Phoronix are celebrating but meh
<kitty1>not really expecting it, but people really need to.
<kitty1>lmao yeah
<Aurora_v_kosmose>Are GPUs still incapable of properly working behind IOMMU?
<bjc>a lot of them do work, but the functionality is locked behind vendor drivers
<bjc>i've seen people make gamer-level nvidia cards work on windows in a vm at the same time as a linux host for relatively mild performance losses, but it required a bunch of driver hacking
<bjc>i think amd is similar. the new intel cards are supposed to support it out of the box, from what i've heard
<Aurora_v_kosmose>Then so long as Nvidia requires reprogrammable firmware, they're a potential malware risk.
<bjc>oh, sorry, brain fart. i'm talking about virtualizing a gpu which has some acronym i can't remember off the top of my head
<bjc>iommu works fine these days with most gpus. amd had some issues for a while due to pci reset bugs, but newer cards seem fine, and there's workarounds for older ones
<littlebobeep>bjc: apparently Intel Arc GPUs require nonlibre firmware now, which is just when they might've starting to be competetive in any remote way and maybe available as discrete cards
<bjc>*if* they support virtualization without hackery and have a decent price point, the intel gpus will have at least a small market
<Aurora_v_kosmose>bjc: Multiple virtualization is a fancier feature.
<Aurora_v_kosmose>My first concern was containability.
<bjc>if your motherboard can split iommu groups in a sane way for you, you're probably going to be fine these days
<bjc>oh.. it's just called "vgpu" apparently
<littlebobeep>if I can't have a discrete Intel GPU with libre software I do not buy more Intel shit cuz that forces me to use their CPUs
<bjc>a discrete gpu should work anywhere there's a pci bus
<Aurora_v_kosmose>littlebobeep: Wait for real? They locked them in to their processors?
<Aurora_v_kosmose>What a dumb move.
<kitty1>yknow, just a dumb showerthought ; how well would FPGAs handle most GPU tasks assuming the software was also made with it in mind?
<kitty1>err, certain notable tasks, rather
<littlebobeep>Aurora_v_kosmose: Well obviously the vast majority of GPUs ever made my Intel are locked into the processors because they are different blocks of logic on the same package: iGPUs (very few had horrid PowerVR GPUs but let's forget those), and last I checked the "dedicated" Xe intel GPUs are mobile only so again you cannot use them without being locked on a motherboard with Intel chipsets and CPUs. But
<littlebobeep>given what little I have read about it, once a dedicated Intel GPU PCI-e card is made, it will probably require nonlibre firmware to run so it won't work in GNU Guix
<apteryx>the_tubular: OK, I've validate that Guix itself is healthy (make as-derivation)
<apteryx>I'm now trying to build the same derivation that failed on the CI with 'guix build /gnu/store/kmngv93i710fdpdqhl5rydzh68pxviv3-profile.drv'
<apteryx>yeah, it fails the same
<apteryx>where does this guix-package-cache come into play
<Aurora_v_kosmose>littlebobeep: How lame.
<Aurora_v_kosmose>They could make an effort to get with the times and liberate their own firmware.
<littlebobeep>well ja most Intel GPUs are the freest options on x86
<Aurora_v_kosmose>To lock down their PCIe GPUs would be a step backward.
<littlebobeep>note that I am not read up on the details of Intel PCIe GPUs, but if they are "Arc" cores then it won't work in Guix
<littlebobeep>Hmmm Lxqt is old
<littlebobeep>Someone online claimed nvidia's GSP.bin firmware is 34 MB hahaha whoops
<emacsomancer[m]>I'm getting an error when trying to do `guix pull`:
<apteryx>working on it
<the_tubular>How big is AMD's one littlebobeep ?
<littlebobeep>the_tubular: Hmmm I don't have AMD GPUs
<the_tubular>What is guix-package-cache exactly ?
<littlebobeep>the_tubular: maybe this answers your question:
<apteryx>sorry, no dice and it's late. I was trynig to figure out how to run the 'package-cache-file' procedure on the current checkout guix as a way to automatically bisect, but I'll need more time/energy. Hopefully someone else can fix it before me :-)
<apteryx>the_tubular: it's the profile hook used when building guix itself (not clear on *when* it's invoked by the CI exactly still)
<apteryx>but the purpose is to produce a cache file of all the current guix packages
<the_tubular>I see
<apteryx>and it fails on some unbound gexp related variable, so something at the level of packages definition most likely
<apteryx>we just need to figure out how to build just that derivation for a given guix revision, then run git bisect on it to find out the culprit
<apteryx>"just" :-)
<apteryx>good night!
<the_tubular>So a simple package definition can cause guix to stop being able to update anything ?
<apteryx>yes. luckily most problems are caught at compilation time... so it'll be interesting to know how this one slipped in.
<the_tubular>Is there a way to make it fail-safe ?
<the_tubular>Sorry, goodnight apteryx!
<emacsomancer[m]>where are the gdm configuration/cache files located? was trying out sddm and I can't get gdm to work afterward (even reverting to an older derivation) - I assume some configuration file for gdm got altered when running sddm
<zamfofex>Hello, Guix! I always hate to ask so bluntly, but is there any chance someone could take another look at <> ?
<horizoninnovatio>How do i update grub.cfg with os-prober? Thank you.
<civodul>Hello Guix!
<civodul>bjc: just saw your comment about gdm on the fediverse
<civodul>looks like we have some debugging to do :-)
<maximed>horizoninnovation: What does "echo $SSL_CERT_FILE, $SSL_CERT_DIR" say?
<maximed>For TLS things, you usually have to install a certificate root.
<maximed>Usually that means installing "nss-certs" (= Mozilla's certificate root)
<maximed>In principle you could use another root, but no other roots are currently packaged in Guix.
<PurpleSym>It seems that due to CI issues this URL (for downloading the latest Guix binary) is failing too:
<PurpleSym>Is there any way to actually get the latest successful build?
<PurpleSym>Without `/archive` it correctly redirects to the last successful build.
<civodul>PurpleSym: weird; do you know when it started failing?
<civodul>the latest result looks fishy, with zero dependencies:
<civodul>and no "Build outputs", unlike the previous one:
<civodul>lots of crosses too:
<PurpleSym>No idea, civodul. But the CI is literally on fire right now.
<civodul>that said, you could run "guix time-machine -- pack guix -C xz --localstatedir --profile-name=current-guix"
<civodul>that'll give you the same Guix tarball
<civodul>or maybe you install a fresh Guix as part of your CI process and you want the latest one?
<PurpleSym>Yes, it’s a fresh Guix install with the latest tarball, so I don’t have to run a slow `guix pull`.
<jpoiret>has the package cache issue been fixed?
<PurpleSym>jpoiret: I believe efraim pushed a fix:
<civodul>i took a look at the Cuirass logs and all on berlin and can't figure out what's wrong with those evaluations
<civodul>what's super weird is that things do get built
*civodul -> meeting
<jpoiret>i was git grepping for gexp, seems like there are two (guix gexp) use-modules in commencement.scm :p
<phodina[m]>does somebody know how to correctly build linux kernel module in Guix? I ran into some issues here
<PotentialUser-42>Hello. I am getting a hash mismatch when building my own package. What might be the difference to checkout hash during guix package -i and guix hash -rx . inside my local dir?
<PotentialUser-42>in package definition I use sha265 base32
***zeta is now known as zeta_
<davidl>PotentialUser-42: does your packages bundle one or more git submodules? Do you specify a git commit in your source or a filepath?
<bjc>emacsomancer: seems like we're all running into the same issues. see:
<bjc>do a quick check on /var/lib/gdm and make sure it has the right ownership
<bjc>civodul: i just saw your response, thanks! i'll try to debug it further once i get some time later today
<zeta_>Hello. I can't install GNU Guix System because I can't connect to Guix's servers. Are Guix's developers blocked it for russian users? And can I install this distribution without internet connection? Thank you
<bjc>zeta_: the substitutes servers (where the binaries are downloaded from) have been having intermittent issues the last few days, so it may not be that you're from russia
<PotentialUser-42>davidl I specify a commit and version - no submodules though - but I use an access token in the git-reference https url
<bjc>an yes, you can install it without internet, but it's more complex than what you're likely doing now
<PotentialUser-42>davidl If I just replace the actual with the expected hash it works, but that does not sound right. guix hash -rx . should give me the right hash. I do something wrong
<bjc>sorry - i misspeak - you can install it without access to the substitutes servers, but you'll still need internet to get the source files for packages
<davidl>PotentialUser-42: just note that guix hash -rx works on current files not whatever files are in the commit. If you have a .gitignore file for example that might create a difference.
<zeta_>bjc: ok, thank you for help. I'll try install this on holidays
<zamfofex>civodul: I hate to ask this again, but since you weren’t online when I asked it earlier today, do you feel like it’d be possible for someone to take a look at <> ?
<PotentialUser-42>davidl .gitignore is there. Good catch
<zeta_>bjs: but it's seems strange when I can't connect to without VPN
<bjc>ah. it may be that russian ips are being blocked after all, then. i think i heard something about gnu services doing that because of ddos attacks or something. but that was a month or two ago
<zeta_>bjs: thank you for this information. I'll try do something
<littlebobeep>bjc: we actually had a discussion in this channel about offline installation with local source building everything and it seems the tooling is not 100% there unfortunately
<qzdlns[m]>howdy guix
<Tirifto>Hello! I notice that the ‘glibc-utf8-locales’ is now gone, and the manual advises defining a custom locales package instead, even telling me what the definition should look like. I think that’s awesome, but how exactly should I make use of that definition? The first example of packaging in the cookbook suggests putting the definition in an arbitrary file and asking Guix to read that (guix package --install-from-file=my-hello.scm
<Tirifto>); would that be a good idea for a custom locales package?
***f1reflyylmao is now known as f1refly
<user_oreloznog>Hi guix!
<user_oreloznog>Seems like zamfofex can't get answers from its ?
<fvio[m]>hey everyone! I'm currently trying to install guix from a sytemrescuecd live usb. Is there a way I can install guix from here?
<fvio[m]>i've so far installed the package manager, but can't figure out what to do with the cow-store service
<zamfofex>user_oreloznog: Yes. 🙁
<allana>Hi #guix! Anyone here use libvirt-service-type? I am using it for the first time and wondering how people interact with it. For example, I installed the virt-manager GUI application and it seems to want to talk to the wrong socket "/var/run/libvirt/virtlogd-sock" instead of the existing "/var/run/libvirt/libvert-sock"
<maximed>Tirifto: Maybe install "glibc-locales" instead.
<maximed>It has all the locales.
<maximed>If you want a custom locale package, I think using manifests ("guix package -m") instead of "guix install" would be more practical
<maximed>otherwise you'll get the problem that "guix package -u" doesn't know about your custome locale package
<maximed>horizoninnovatio: I don't think Guix uses os-prober.
<maximed>Is this about Guix System?
<Tirifto>maximed: Thank you; I’ll see if manifests are workable for me, since I’d prefer to spare some space.
*allana figured it out, selected a "QEMU/KVM user session" option :-)
<civodul>zamfofex: hi! you're right to ask, no problem
<civodul>in theory there are 40 people who could review and push the changes
<civodul>in practice though, that's a much narrower set of people
<civodul>anyway, i'm walking up the patch list and i'll get to this one real soon i guess
<civodul>sorry for the delay, i know it's frustrating!
<mekeor[m]>would it be possible to run guix in a container on mac os, to install packages which would be used on mac os natively, i.e. without containers?
<maximed>mekeor: Guix currently does not support that OS.
<maximed>A VM might be possible though.
<zamfofex>civodul: Thank you for getting back, I really appreciate it! I know people are oftentimes busy and I don’t want to sound demanding, is all. Other than that, I’ve just been a bit eager to try to get networking functional for the Hurd again! (Which depends on that patch.)
<PotentialUser-42>mekeor[m] You can install Guix into vmware fusion.
<zamfofex>mekeor[m]: If you have a different computer where you can install Guix, maybe you could try to use ‘guix pack’: <>
<zamfofex>I don’t know whether such a tarball work on Mac OS, though.
<zamfofex>*would work
<civodul>zamfofex: oh! networking on the Hurd does work on master though, right?
<civodul>i have a childhurd i can talk to at least :-)
<zamfofex>civodul: I mean on real hardware! Apparently the builtin Mach drivers are not sufficient in my hardware, even though they work fine on QEMU.
<civodul>oh, got it
<civodul>we need to switch to net-dde
<zamfofex>Yes! See: <> Though it doesn’t quite work, I assume because I didn’t update Mig (which depends on glibc >= 2.34).
<cbaines>civodul, something else that unfortunately require your input is
<civodul>zamfofex: oh my bad, that one slipped through as well
<civodul>cbaines: you have great debugging & programming skills though :-)
<zamfofex>civodul: No, it’s fine! As I said, it doesn’t quite work yet. I was planning to post an update once I figured out whether my assumption is correctafter the glibc patch.
<cbaines>civodul, I have had a look, but I think addressing it would require somehow changing the inetd stuff to support listening on multiple sockets, one for IPv4 and another IPv6 one
<civodul>cbaines: ok; could you share your findings in the issue, including perhaps a preliminary patch?
<horizoninnovatio><maximed> "horizoninnovations: I don't..." <- I've installed os-prober so assumed it was used! Anyhow, is there a way to automatically update grub.cfg with other linuxes partitions?
<lechner>Hi, should Guix's default installation of ssh disable ECDSA?
<apteryx>civodul: I feared the Btrfs array may have filled up, but no, it still has about 2.5 TiB to go
<civodul>apteryx: yes, sounds good; so these are the new SSDs?
<horizoninnovatio>Evolution email client error: Could not connect: Network is unreachable - any solution please (this is driving me nutts!
<cehteh>you have network on the machine at all?
<cehteh>dunno about evolution, but could be firewall in that case
<rekado_>apteryx, civodul we also have 100TB on the SAN that I think we should start using.
<horizoninnovatio>cehteh: Yes, I'm here!
<apteryx>rekado_: agreed, and I'd like to continue my btrfs boot experiments on node 129
<apteryx>I'll have a similar 5 RAID10 array soon to test at home too
<apteryx>rekado_: question about the new SAN; there are many drives exposed to the OS; but we can use a single one of them in the config correct?
<apteryx>(why is it exposed as multiple drives?)
<apteryx>civodul: the SSDs are currently hosting mostly /var and /home, which include the Cuirass database and cached NARs
<civodul>apteryx: oh got it
<civodul>and yes, using the 100 TB sounds like a good idea :-)
<civodul>apteryx: is there a problem specifically due to booting on btrfs?
<apteryx>I've not seen it outside of the build farm setup, but there is one there yes
<apteryx>our initrd lacks udev support, and btrfs relies on it to wait for the drives to be online before assembling the array, so it's probably down to this
<apteryx>I haven't see the issue in our new Btrfs RAID10 system test
<apteryx>but these aren't real drives
<civodul>ok, interesting
<civodul>our initrd has code to wait for devices, similar to udev; could it be that it's missing something for these devices in particular?
<civodul>or that kernel modules are missing?
<civodul>(normally the checks that "guix system reconfigure" makes would catch this, but who knows)
<apteryx>civodul: where is this synchronization code waiting for devices readiness?
<apteryx>canonicalize-device-spec, perhaps?
<apteryx>this probably does it for regular file systems that simply appear under '/dev/sdxN', but Btrfs is special in that it uses its own means to detect the file system arrangement ('btrfs device scan')
<apteryx>I suspect that if 'btrfs device scan' runs before the devices are ready it will cause the array to be degraded (missing drives)
<apteryx>the Btrfs udev rules meant to be used in the initrd are define in: /gnu/store/8c136063irrx9hig6dmf1xqli6rgibkk-btrfs-progs-5.15.1/lib/udev/rules.d/64-btrfs-dm.rules
<PotentialUser-42>Hi. I created my own python package. I can install it via guix package -i and afterwards start a python3 interpreter and import it. If I create a docker image with that package I can see it in the store but I can not import it. How can I tell python to look at the right place?
<apteryx>you need to include python in your image; this will cause the GUIX_PYTHONPATH environment variable to be defined and your package should be importable
<apteryx>rekado_: I saw a new public IP being registered in berlin; I guess what remains to be done is to assign it to some (non-berlin) machine to provide access to iDRAC when berlin is down?
<PotentialUser-42>apteryx This is my build command: guix pack -f docker -S /bin=bin python-ammosreader bash coreutils python grep ffmpeg findutils which
<apteryx>ah and yes, you'll have to source teh profile
<apteryx>so expose /etc to, and connect via 'bash -l' or something or manually 'source /etc/profile'
<PotentialUser-42>apteryx I am sorry. What do you mean by expose /etc
<apteryx>-S /etc=etc
<PotentialUser-42>GUIX_PYTHONPATH is set. I am getting closer
<rekado_>apteryx: we have two public IPs. .40 and .41. We haven’t assigned .41 to anything yet.
<rekado_>the other IP on berlin is a private IP on the management network, allowing you to access the iDRAC of all nodes.
<rekado_>we’d have to assign one like that to whichever node will get the second public IP.
<rekado_>apteryx: re SAN: there are four devices, because the SAN exports four paths to the SAN slice. Ideally we would be using multipathd to benefit from this redundant connection.
<apteryx>rekado_: would it be possible to assign the .41 to one of the running build nodes already?
<apteryx>and thanks for explaining the SAN thing
<PotentialUser-42>Are you aware that ambrevars home page is down for at least two days?
<apteryx>PotentialUser-42: not sure which page you are talking about, but consider reporting it to them
<PotentialUser-42>apteryx - It is a really good learning ressource
<apteryx>OK. The Guix project has no control over such site, so the best we can do is report it to its author :-)
<rekado_>apteryx: yes, we could assign .41 to one of the other nodes. I just need to know which so I can arrange for that node to be hooked up to the public switch.
<apteryx>is there another build node (apart for the currently foobar'd 129) which is newer or otherwise deemed more reliable than others? we should use that one
<rekado_>we have a few more of them
<rekado_>when I’m in the data centre again I’ll hook one of them up
<apteryx>OK, neat! I'm looking forward to be autonomous in sorting out the mess I sometimes create ;-)
<rekado_>speaking of mess: have you been able to network-boot node 129?
<rekado_>we use cobbler here, and I have no idea how it works
<apteryx>I think I was stumped on something basic last time I tried, but I forgot what... let me try again.
<apteryx>civodul: re current CI failures, so we do not know why building the package cache fails?
<apteryx>I can reproduce the failure by 'guix build /gnu/store/kmngv93i710fdpdqhl5rydzh68pxviv3-profile.drv' locally
<apteryx>I wanted to run git bisect with an invocation of guile attempting to build the package cache for the current guix checkout, but I'm not sure how to do that
<civodul>apteryx: where do you see that building the package cache fails?
<civodul>apparently there was a typo in a commit yesterday that led to that
<civodul>but it was fixed shortly after
<civodul>or is there still a problem?
<apteryx>the last failed derivation on master:
<apteryx>I wonder how we could catch this problem before it reaches the main branch
<civodul>apteryx: that's commit b33ebc22fb, fixed right after that
<apteryx>I see
<apteryx>OK, I see the latest commit built fine
<civodul>"make" should have reported it as an unbound variable already
<apteryx>uh. so the commit was made without the pre-push-hook
<apteryx>was pushed*
<apteryx>or is that just a warning that doesn't fail the build?
<apteryx>rekado_: so, how I was expecting to be able to try a PXE boot was: 1. connect to serial of node 129; 2. go to the iDRAC page of node 129 and request a reboot; 3. at the serial, see the boot options and choose to PXE boot from some IP address
<apteryx>so far, succeeded at 1 and 2
<apteryx>F12 == PXE boot, OK
<apteryx>hm, it still reached GRUB
<apteryx>yeah, can't seem to enter F11 (Boot Manager) or F12 (PXE Boot). It always end up on the GRUB screen.
<apteryx>I think the reason node 129 isn't bootable is because I had forgotten to clear the inherited swap device field
<apteryx>a rescue boot GRUB menu that boots our install image would be handy
<rekado_>does PXE boot fail early and then it moves on to the local disks? Or does it boot from disk directly?
<rekado_>if it’s the latter then you should be able to change the boot order in iDRAC.
<apteryx>I tried pressing F12 to select it (or F8 to enter the Boot Manager) at boot without effect
<rekado_>if it’s the former then it’s likely my incompetence with cobbler or some network setting that prevents our nodes from seeing the cobbler server.
<apteryx>good idea to set only one boot device to PXE in iDRAC and retry
<rekado_>I don’t want to waste your time. I really hope I accidentally got everything right when setting up the Guix image on cobbler.
<rekado_>lots of hoops to jump through; quite disorienting.
<apteryx>I don't feel like I'm wasting my time, no worries :-)
<apteryx>next time you visit the datacenter, if you could leave a Guix install USB device plugged in, that would probably be useful
<apteryx>(on node 129)
<apteryx>I've now enabled only PXE in the boot devices (after entering setup with F2)
<apteryx>rekado_: ah! at first I saw that:
<apteryx>then it retried and apparently it works:; it allows booting the images via GRUB
<rekado_>oh, that’s good
<rekado_>the Guix entry is mine; the others were configured by my colleague.
<apteryx>although now it seems stuck Loading initial ramdisk ( /images/Guix_System_1.3.0/initrd.cpio.gz ) ... for rather long
<rekado_>this reminds me of the early iPXE days when I tried to install the build farm nodes over PXE
<rekado_>it never worked…
<rekado_>let me see the cobbler settings for that record again; maybe I did something stupid
<rekado_>it’s actually supposed to load /var/www/cobbler/distro_mirror/Guix_System_1.3.0/gnu/store/6gqlkmklgvqks6nqf6bc39vj044pjvjd-raw-initrd/initrd.cpio.gz
<rekado_>but in any case: /images/Guix_System_1.3.0/initrd.cpio.gz also exists (under the cobbler prefix)
<rekado_>I just feel that Guix System is a bad fit for the assumptions cobbler makes about distros
<rekado_>I would expect all the locations to be wrong, because /gnu doesn’t actually exist, nor does the partition that our image expects to appear.
<rekado_>I see this in the logs: Client ::ffff: finished /images/Guix_System_1.3.0/initrd.cpio.gz
<rekado_>so it looks like kernel and initrd have been served to the machine
<apteryx>trying another image for the kicks
<yarl>make cscope does not work?
<apteryx>rekado_: same result with ubuntu. perhaps serial related
<rekado_>apteryx: oh. Unexpected.
<rekado_>the rocky live stuff should work, tohugh
<rekado_>if it does work then you could install Guix with the installer script at and then “guix init config.scm /”
<emacsomancer[m]><bjc> "do a quick check on /var/lib/gdm..." <- what is the right ownership? I see:
<bjc>emacsomancer: it should be owned by ‘gdm:gdm’
<emacsomancer[m]>bjc: hmm. I wonder why it got changed. installing sddm? or unrelated?
<bjc>there's a bug somewhere in either the user management or the gdm activation code
<bjc>or maybe both!
<bjc>but if you remove the gdm service, then add it back later, this happens
<emacsomancer[m]>right now I get "chown: invalid user: ‘gdm’" - probably have to reinstall gdm first?
<pashencija[m]>There's a function in image.scm... (full message at
<pashencija[m]>I'm generating an image, so both correct FS type and boot flag are important to me
<maximed>horizoninnovatio: not that I know of, but for manual configuration, have a look at "info '(guix)Bootloader Configuration'"
<maximed>In particular, the "The Other Distro" example
<maximed>It's not something I've previously done myself.
<maximed>paschencija[m]: IRC doesn't support multi-line messages.
<maximed>For multi-line code, I recommend <>
<maximed>The full message wasn't directly available to people on IRC
<maximed>On the IRC side, it was ‘There's a function in image.scm... (full message at https://a-long-url)
<maximed>Also, how is it used in the script??
<apteryx>rekado_: the wip-pyyaml branch can be deleted, correct?
<maximed>Would anyone like the WIP antioxidant code to be available in a channel?
<maximed>So people can do "guix install antioxidated-hexyl" and such.
<maximed>And maybe built by for substitutes and a red/green / FTB/builds dashboard.
<apteryx>maximed: perhaps as a wip-* branch? I don't see how using it as a channel would be more convenient; what is this antioxidated-hexyl package?
<maximed>It's currently developed outside Guix itself
<maximed>It's also not just a build system, it also needs to rewrite package definitions a bit
<apteryx>ah, I had forgotten the goal is to have it as a standalone tool
<apteryx>oh. How does it rewrite package definitions, and for what purpose?
<maximed>basically, (define-public antioxidated-hexyl (vitaminate/auto hexyl)), where 'hexyl' is a rust app and 'vitaminate/auto' is the package definition rewriting procedure
<maximed>Purposes: (1) break package cycles (often caused by test dependencies, sometimes by optional features)
<maximed>(2) Set the required ‘features’ for each package (basically Cargo's equivalent of ./configure --enable-foobars)
<maximed>(3) resolve version conflicts -- usually by picking the newest version.
<apteryx>it seems like 2 could be handled at run time in the build system perhaps; I'm curious about the other 2
<ulfvonbelow>is there a way to tell 'guix pull' to only authenticate some channels? For example, if I have a channels.scm with a channel from a remote host and a local customized guix I'm working on personally, I'd like to be able to pull without having to commit and sign everything I'm currently working on.
<ulfvonbelow>alternatively, is there a way to use multiple channels from pre-inst-env?
<maximed>(4) fix build failures caused by using different versions from what Cargo does (see, e.g., "rust-x509-parser"'s #:phases in guix.scm)
<maximed>(4) can probably avoided but the packages will need to be updated anyway
<maximed>(2) is mostly done by the build system.
<maximed>antioxidant-build-system enables all the "default" features by default. Or if there are no default features, all the features.
<maximed>However, you can have situations where "rust-foo" requires the "baz" feature of "rust-bar", but "baz" is not a default feature.
<maximed>So it needs to be added manually. That's one of the things that vitaminate/auto does (there's a mapping of package names -> extra features somehere)
<maximed>cargo-build-system avoids (2) by compiling "rust-bar" with the required feature again when building "rust-foo".
<maximed>But that's rather costly, so the idea is to avoid that in antioxidant-build-system.
<maximed>apteryx: By making it a channel instead of a branch (for now), you can still use 'master'.
<maximed>It's also a bit easier to develop it as a channel, no need for ./pre-inst-env, make, make clean, ./configure or "guix shell -D guix"
<apteryx>it seems like we'd probably want to move to use this antioxidant-build-system for most packages, so it'd be nice if the extra rewritting procedure boilerplate could be avoid to keep things simple
<apteryx>for most/all rust* packages
<maximed>The idea is to move the rewriting code into "guix style"
<apteryx>OK, nice! Do we already apply guix style when importing packages?
<maximed>$ ./pre-inst-env guix style -S antioxidate --> all rust packages now use antioxidate
<apteryx>powerful stuff
<maximed>apteryx: I don't think so, though the contributing guidelines ask somewhere to run "guix style"
<maximed>I suppose "guix import crate" could be modified to emit 'antioxidate-build-system' packages?
<apteryx>OK, thanks for explaining the rationale for the channel, it makes sense
<apteryx>yes, or we could take care to make every importer use guix style to format by default
<maximed>Also, with a channel, I could just push the changes without having commit access to Guix itself :p
<maximed>I don't know if Cuirass does containerisation though
<apteryx>we can fix the commit access bit, if you like!
<maximed>But then I need to be responsible!
<maximed>though maybe later
<apteryx>whenever you are ready
<apteryx>rekado_: also stuck on Loading initial ramdisk ( /images/Rocky-8.5-x86_64/initrd.img ) ...
<emacsomancer[m]><bjc> "yeah" <- bjc: thanks! (recursively) changing the ownership of /var/lib/gdm fixed it (after a reboot).
<lechner>Hi, what's the right way to fix unknown or invalid certificate issues, please? Installing nss-certs does not help.
<bjc>emacsomancer: glad to hear it
<apteryx>lechner: it depends. if you are using openssl based applications, install openssl along nss-certs
<apteryx>if you are using gnutls-based applications, you need to ensure the certs are availabel under /etc/ssl/certs
<rekado_>apteryx: wip-pyyaml can be deleted, yes
<rekado_>apteryx: did you try the “Rocky LIVE” entry?
<rekado_>(my colleague wrote a cryptic “try now”, so I’m guessing something was borked.)
<apteryx>it gets stuck the same, at least from my serial console
<apteryx>the build farm is also again stuck
<apteryx>raghavgururajan: the wip-gnome3.34 and wip-gnome3.36 branches can be deleted, correct?
<apteryx>rekado_: Rocky-8-x86_64-LIVE or Rocky-8-x86_64-LIVE-GuixFarm ?
<apteryx>I get the same result with Rocky-8-x86_64-LIVE-GuixFarm
<mekeor[m]>lechner: are you on guix system? if so, did you add nss-certs to your system package list?
<apteryx>rekado_: oh, the 'Rocky-8-x86_64-LIVE' one boots!
<apteryx>what's the setup difference? perhaps it can be applied to our Guix image menu
<mekeor[m]>is cubes os any more poweful than a guix system where you launch programs in guix-shells? also, is it possible to e.g. start chromium inside a guix-shell while giving it read+write access to a browser profile?
<mekeor[m]>*qubes os
<lechner>mekeor[m]: i did on the first few installs, but not on this one while adapting the first file here
<lechner>mekeor[m]: now 'reconfigure' fails with a git error on savannah, but i can get substitutes
<apteryx>rekado_: it booted but I can't login ^^'
<mekeor[m]><ulfvonbelow> "is there a way to tell 'guix..." <- you can maybe just use guix package -f file.scm?
<mekeor[m]>> <> There's a function in image.scm... (full message at
<mekeor[m]><yarl> "make cscope does not work?" <- whats the context?
<ulfvonbelow>mekeor[m]: trouble is I want to reconfigure my system using code from my guix checkout as well as remote channels
<ulfvonbelow>oh, also, anyone know why whenever I reconfigure, the permissions on /var/run/dovecot and /var/run/knot get messed up? /var/run/dovecot ends up owned by knot:knot and /var/run/knot ends up owned by root:root
<pashencija[m]><mekeor[m]> "> <> There..." <- Of course it does!
<pashencija[m]>It's `(initializer (gexp initialize-efi-partition))`
<pashencija[m]>I wonder why I clipboard did that
<pashencija[m]>So it works fine with gexp unless I copy and rename function
<pashencija[m]>I spent the whole day trying to figure why the boot partition is ext4 and the system partition lacks boot flag... (full message at
<mekeor[m]>> <> Of course it does!
<mekeor[m]>> It's `(initializer (gexp initialize-efi-partition))`
<mekeor[m]>> I wonder why I clipboard did that
<mekeor[m]>maybe paste both files completely in a pastebin
<mekeor[m]>i'm not sure how your messages are displayed on irc. please use pastebins instead
<pashencija[m]>It's like this right now
<pashencija[m]>I have added and deleted `(inherit esp-partition)`
<pashencija[m]>I have also tried both (partition-table-type 'mbr) and (partition-table-type 'gpt)
<pashencija[m]>It's ext anyway
<pashencija[m]>I have tested the system run on Raspberry. It's up to the image now.
<pashencija[m]> * I have tested that the system runs on Raspberry. It's up to the image now.
<lechner>Hi, my issue is fixed now, but should nss-certs perhaps be a prerequisite for Guix system?