<oriansj>nckx: it looked like someone was having an issue booting a luks volume via grub to me. Which as grub only supports luks1 format, then the remaining issue is lack of cryptsetup being installed to the actual decryption needed to actually boot
<nckx>Cryptsetup doesn't need to be installed to boot.
<oriansj>as it does kinda break rollback without some ugly hooks if I remember correctly
<nckx>My current solution (not worthy of the name) is a bash script that copies as many recent bzImages+initrds to /boot/gnu/store until it's full. So the last N generations are bootable and the rest silently broken. With N depending on how many initrds are shared across recent generations.
<oriansj>and how easily guix changes could break it
<nckx>Mh, less that, it's so stupid that it's relatively robust. Until Guix decides not to use kernels & initrds in a grub.cfg I'm good. I well hope my script will be obsolete long before that happens.
<nckx>Either by Guix supporting separate /boot or GRUB supporting bcachefs.
<PurpleSym>Do we have any way to declare a “preferred” version of a package? I.e. if I run `guix environment --ad-hoc ghc`, is there any way to tell it to use email@example.com and not firstname.lastname@example.org (which is the most recent one).
<qzdlns[m]>the reason I ask, is because I'm having driver and Xorg trouble, and I'm just enumerating all possible problems.
<qzdlns[m]>geex3: thanks for ruling one such problem out :)
<civodul>hmm GC has been running on berlin for 5.5h it seems
<brendyn>I've noticed I can't use the yasnippet's any more. they don't appear when i do yas-insert-snippet. they are in the yas-snippet-dirs though
<gagbo>Hello, I'm having a weird issue with Guix on Fedora 34 (no SELinux), where guix package returns `guix package: error: unsupported manifest format`. I updated both my user's guix and root's guix with guix pull and sudo -i guix pull, and I restarted the guix-daemon service as well. I thought it would fix it but it didn't. Is there anything else I missed ?
<gagbo>Is it possible that a custom channel messes up that "manifest format" ? I don't see how, given that root's guix channels are only default
<civodul>gagbo: hi! could you paste the first few lines of ~/.guix-profile/manifest ?
<efraim>mine have all died over the years, I currently own an ibook G4, debian + giux, and a pinebook pro, manjaro + guix
<civodul>gagbo: the empty ~/.guix-profile/manifest suggests something's broken; it's not possible to generate an empty file there
<civodul>or perhaps it's a Guix Home bug or something?
<dhruvin>I use 8 years old hp pavillion 15-n011tu with generic AR-9271 external wireless adapter.
<gagbo><civodul> "gagbo: the empty ~/.guix-profile..." <- Maybe yeah, thanks for the hint. Is there a command to generate a manifest forcefully ? I'm trying `guix package --export-manifest` but it doesn't work, Otherwise I'll probably try to forge an empty manifest and check that. I wonder whether Andrew has a nick on libera I can ping, otherwise I'll prepare a mail later for the ML
<civodul>gagbo: you can get around that by stashing away your current profile
<maximed>(for now, I've switched to an earlier system generation with a functioning xorg-server)
<ardon>Hi, I'm having an issue setting up virtualization. When I configure the `libvirt` service on my system configuration and try to create a new virtual machine through `virt-manager`, I get a `Failed to find suitable default network` error. I've tried querying for the existing networks with `virsh net-list --all` and then `ifconfig`, and it seems like no `virbr0` bridge interface is being created automatically. I've also tried installing
<ardon>`bridge-utils`, but I'm out of ideas of what to do at this point, should I create the interface manually?
<civodul>maximed: hi! that's on master? was elogind running?
<maximed>So you need to write (or native-inputs inputs)
<ardon>To further expand on my above issue, I also get this issue when clicking on `Begin Installation` on `virt-manager`: `libvirt.libvirtError: internal error: No <source> 'bridge' attribute specified with <interface type='bridge'/>`
<jpoiret>maximed: thanks, didn't know about that (is there anywhere this is documented?). by the way, what is the best way to find out where a binding comes from? geiser cannot seem to find append-map
<maximed>jpoiret: It's not documented anywhere afaik
<maximed>I think 'native-inputs' should be set when compiling natively as well
<maximed>(though due to complications, when compiling natively, 'native-inputs' would include regular inputs as well)
<dstolfa>civodul: based on that, i would assume that there are a few things that take a while to start up that can normally started in parallel, but in this case shepherd just waits for 1 before starting the rest
<shoshin>hello! i have an issue i keep bumping into where emacs-guix craps out with an unknown variable when i'm trying to search packages. i can't seem to pinpoint what causes it. i'm currently trying to run a multi user server with GuixSD and had Emacs and emacs-guix installed at the system level. i'm wondering if this is the wrong way to go? should each user have their own profile with emacs and emacs-guix?
<civodul>maximed: ouch; i don't have any relevant change in mind, perhaps bisecting is the way to go
<apteryx>by whom (which tool) are runpath baked in our C/C++ binaries? Is it done by ld directly? I'm trying to update 'ldc', and some of its binaries (ldc2, ldc-profdata and ldmd2) are lacking runpaths to the LLVM libraries it is linked with.
<civodul>apteryx: hi! it's done by the linker wrapper, in gnu/packages/ld-wrapper.in
<apteryx>hi! and thanks! I'll have a look this way :-)
<apteryx>neat, I hadn't realized our ld-wrapper script was Guile
<shoshin>package/output-sexps: unbound variable is the error i'm getting more specifically
<shoshin>i have a sense its some profile conflict but i'm not sure how to resolve it
<roptat>I remembered someone talking about bootstrapping kotlin recently on the bootstrappable mailing list. I looked at what they did, and although they didn't bootstrap other dependencies, they managed to get up to kotlin 0.12.470, which is awesome. I tried to replicate that in guix, using some of my previous work to remove the other prebuilts, and it seems I only need a less recent version of protobuf to make kotlin-0.6.717 (maybe 786 could
<roptat>oh yes, I tried to answer to that... twice I think
<roptat>I already explained the issue with the mismatched hash, at some point the build system generates classfile files that contain a hash of their content. It's generated from a java code, and the result is identical to the classlists from master, so no problem on that side
<civodul>efraim: BTW, it was to avoid a rebuild that i had left the deprecated texlive package names in two places on core-updates-frozen
<civodul>but i'm glad you made the change anyway :-)
<muradm>pineapples: yes i know tested master before release, tested released.. :)
<muradm>will be submitting updated patchset soon, maybe with gtkgreet
<muradm>we did few fixes in greetd/seatd/wlroots to have more or less seamless eye candy login experience.. :)
<apteryx>how can i override an implicit input at the package level?
<roptat>by changing the build system (or, sometimes they provide an argument, like dune-build-system has a #:dune argument to override that specific implicit input)
<roptat>or, if you don't mind having multiple versions, you can pass the replacement as input, it should be picked up before the implicits
<apteryx>ah yes, that should work for my case (simply adding the input), i think what is happening is that the binutils-gold/bin/ld.gold is overriding my ld-wrapper-gold/bin/ld.gold in the PATH (both are passed as native-inputs)
<apteryx>seems the order under which they appear in PATH is reversed from the order given in native-inputs
<apteryx>nevermind, they aren't reversed, and i'm an idiot :-)
<apteryx>meh, I can just provide the ld-wrapper-gold too.
<apteryx>civodul: creating a wrapper for ld.gold worked :-)
<drakonis>you can either use the installer or write the config yourself
<crazychicken>I've never done it, otherwise I'd probably opt into doing so
<cbaines>crazychicken, I believe that's a known issue with the installer for the current release
<crazychicken>cbaines, I tried the stable release first, and then tried the latest and both had the same problem
<cbaines>Ok, I could be wrong, it's been a while since I used the installer
<crazychicken>I guess most of you guys here already have your own config files then, and thusly don't need the graphical installer? I've not touched guix before and wanted to jump into guix since I librebooted my x200 recently
<cbaines>crazychicken, out of interest, where did you download the "latest" installer from?
<crazychicken>The guix official website. I made sure not to exit the domain
<crazychicken>I've actually tried both but I'll try the latest version again
<geex3>i had issues with a few isos. but the 1.3.0 release is good (use no remote during install) -- the issue was with the deprecated 'target' field in bootloader, which is now 'targets' .. and during the scheme compilation error it returns to the beginning of the installer. super annoying but ended up getting it installed
<geex3>and if the iso uses 'target' and doesnt know what 'targets' is, and then the guix pull stage updates the guix and now doesn't allow target but only targets.. aaahhhhh
<crazychicken>Yeah I just tried using the latest version and no luck, I'm getting the same bug
<sailorCat>Hi, I have a firmware related question. There is my wifi: "Network controller: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapte" that doesn't work.
<sailorCat>I have packages b43-tools and openfwwf-firmware installed
<sailorCat>also I put manuall "(firmware %base-firmware)" into config.scm
<geex3>anyways if you fetch remote substitutions during the 1.3.0 installer it upgrades guix and the default configuration is busted i think
<roptat>sailorCat, guix ships with linux-libre, which doesn't support your wifi chip. Although there is a free driver, it depends on being able to load a proprietary firmware inside your wifi chip, which linux-libre won't do (hence the name)
<crazychicken>I assume that means I'll have to compile everything on this core 2 duo then no?
<roptat>crazychicken, could you send a bug report to email@example.com, reporting what you've tried, what kind of hardware/partitions you have and how it's failing?
<roptat>also say it's failing with stable and latest if that's the case
<pineapples>muradm: Nice! Thanks for letting me know. While we're at it, would you remove my copyright header/notice from freedesktop.scm and add it to admin.scm?
<htsr[m]>Hi guix! I've managed to get a static dropbear inside my initrd but I can't connect to it in the repl, can someone help me? I launch dropbear like this in the bournish shell `dropbear -R -B -E -p 2222` and `ssh -p 2222 ...` hang forever.
<zacchae[m]>I just got a weird error trying to init a system with an efi-grub bootloader saying "/gun/store/...-grub-efi-2.06/lib/grub/i386-pc/modinfo.sh dosn't exist. Please specify --target or --directory"
<zacchae[m]>it prints the grub install command used above it, and that print definitely includes a "--efi-directory /boot/efi", so I'm not sure what it could be complaining about
<zacchae[m]>The only possible weirdness about my setup that I can think of is that I'm initing an efi-based system from a legacy-grub install
<htsr[m]>--efi-directory doesn't seems to be equivalent to --target or --directory
<zacchae[m]>That seems to be what it is complaining about, but this is (supposed to be) an efi grub install, so should only need the EFI mount point
<zacchae[m]>which is why I'm thinking the error could be that I'm trying to init an efi-based system booted into a legacy-bios-based
<zacchae[m]>Just wanted to see if anyone here knew what was up before I made a bug report
<pkill9>does qemu-minimal fail at test phase on arm for anyone else?