<ggoes>ah, nvm. i read a bit earlier in the log <nckx>:( Better luck tomorrow, jonsger. <nckx>(Reinstall seems a bit heavy-handed though…) <jonsger-laptop>the better idea would be to mimick the creation of the grubx64.efi file. But I don't know how <nckx>Once you boot the system from a rescue GRUB you should be able to reconfigure based on master, no? <jonsger-laptop>it doesn't say much more then "Unknown command cryptomount" and "error: dsik cryptouuid/ad... not found" <nckx>Which GRUB is this? The Guix installer? <nckx>Oh, I don't mean your broken GRUB's rescue> prompt. <nckx>I mean a different boot medium with a working GRUB. <jonsger-laptop>got it. Does that work now? The last time I gave up, because chroot does "not work" <nckx>Automagical ones like Super GRUB 2 Disc exist that try to construct a rescue menu for you. <nckx>No need for chroot, you'd be booting your existing system (which is probably fine). <nckx>Unlock the cryptodisk from within the 3rd-party GRUB, then use ‘configfile (hdX)/blah/grub.cfg’ to load Guix's GRUB menu. It's… always worked for me.“ ***iskarian is now known as Guest2989
<oriansj>jonsger-laptop: sounds like you forgot to include cryptsetup in the list of installed packages <nckx>Walk me through that one. <nckx>It does not sound like that at all to me. <nckx>You don't need to install cryptsetup anywhere. ***iskarian is now known as Guest7372
<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. <nckx>For Guix values of installed. <dstolfa>nckx: has linux-libre been backed up to guix infra fully? <nckx>For example, none of my FDE machines have cryptsetup installed to any profile, user or system. <nckx>dstolfa: I can actually tell you in about half an hour. <jonsger-laptop>nckx: nice trick, it booted my installed Guix. Entered for the second time a password but then it fails to start all the services (file-systems, term, etc) <nckx>The 2 MiB/s slog is almost over. <oriansj>commenting out line 154 results in shepard failing to boot the system when it was tested last <iskarian>oh hey, nckx, for the docker test I got "FAIL load system image and run it" <nckx>Could you share the log? <oriansj>nckx: well grub only supports luks1 not luk2 <nckx>So I am well aware of that limitation, it just does not seem relevant here. <jonsger-laptop>maybe its some hardware/fs stuff. I get the same "faield to start service" thing when I boot into an older generation based on master... <nckx>iskarian: No XFS I/O errors that boggle the mind? <nckx>Because you, say, don't use XFS at all, like me? :) <nckx>jonsger-laptop: I feel your pain. <nckx>This is about the worst layer of Guix to debug IME. Tooling… frankly sucks. <oriansj>nckx: there might be a way to have luks2 for the master volume if /boot had a copy of the required bits <nckx>oriansj: More luks2 commits have been pouring into GRUB so I am optimistic. <nckx>For 2.08 or so, with luck… <nckx>oriansj: But yeah, I definitely agree with you there's almost certainly a way to hack it up if you want it today. <nckx>‘almost’? How did that weasel word get there. <oriansj>nckx: because it requires taking /boot out of the store <oriansj>and we don't encourage that sort of thing *nckx looks at separate /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. <nckx>Perfect for me but not upstream-worthy. <oriansj>and definitely not guixy (written in something other than scheme) <nckx>I think Ricardo wrote a Schemier version. <nckx>It's not even funny how ugly it is. <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. <nckx>XFS (dm-1): log I/O error -5 <nckx>Must be some weird Docker thing to use XFS, because it's not Guix doing that. ***TheCreeper1 is now known as TheCreeper
<dstolfa>iskarian: it does have a working zfs, xfs i haven't tried, but i would assume it does <singpolyma>Guix "services" dont really make sense on a foreign distro, right? Thad and the configuration management stuff are just when using System? <nckx>They don't currently. Indeed. <singpolyma>If I use guix copy to send a build (private) package to another system, how can I install the package into a profile on that system? <singpolyma>Interesting. It seems that guix package -i /gnu/store/... works, though perhaps undocumented? <singpolyma>hmm, any time I try to use guix copy I get something like: guix copy: error: corrupt input while restoring archive from #<closed: file 7fb6a07ad7e0> <bdju>does anyone use qutebrowser and have working sound in it? not sure if the issue isn't hitting everyone or if there are just very few qutebrowser users and they're all dealing with it <bdju>I hit something that mpv + youtube-dl is really not playing well with and so I'm once again annoyed that my browser audio doesn't work <moshy>i think i may have found a workaround for broken pulseaudio in xfce. had to leave pavucontrol open and minimized <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 ghc@8.6 and not ghc@8.8 (which is the most recent one). <qzdlns[m]>sanity check question: should my /tmp have permissions `drwxrwxrwt 6 root root 32768 Sep 14 09:08 tmp` ? <geex3>qzdlns[m]: yea that is good but what about /var/log/*.gz <geex3>for some reason the gzipped of everything is o+r <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 ? <gagbo>So I suppose my issue would be that guix home currently uses a too old version of manifest ? <sneek>efraim, iskarian says: cool, that's what I was thinking. Go builds pretty fast anyway. <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 <civodul>gagbo: so probably "mv /var/guix/profiles/per-user/$USER/guix-profile{,.bak}" <gagbo>I was going to try creating a `(specifications->manifest ...)` file to reset, but that probably works as well ! <gagbo>(the mv worked fine, thanks a lot !) <jpoiret>can you get native-inputs as a key in build phases? it seems to always be #f in my case, even though my package does have (native-inputs `(("something" ,something))) <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>on master (commit 9875f9bca3976bf3576eab9be42164fde454597e) <maximed>fwiw, booting can take long, so sometimes I run "sudo herd restart xorg-server" so shepherd starts xorg-server somewhat earlier <maximed>'gdm-shepherd-service-type' doesn't have 'elogind' in requirements, maybe it should? <maximed>I'll add it locally, to test if that fixes things <civodul>maximed: can you reproduce the issue in a VM? <civodul>also, why shepherd is definitely slow at starting things, it's not slow to the point that i have to manually intervene :-) <civodul>like, it takes maybe 5-10s at most to get to the GDM greeter once i've entered my passphrase <maximed>civodul: I'll try "guix system reconfigure" with the patched guix first <maximed>in my experience, the ‘time-to-greeter’ is longer (I'll measure it tomorrow) <maximed>jpoiret: when compiling natively, native-inputs and inputs are merged into inputs and native-inputs is set to #f <dstolfa>civodul: IIRC, shepherd waits for the service to be started, right? it does a topsort, but starts things sequentially and waits for it <dstolfa>been a while since i looked at shepherd <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) <maximed>That would be for core-updates, tough <maximed>civodul: How long does "guix system reconfigure" usually take? <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 <maximed>(on a spinning disk with encryption) <dstolfa>maybe there could be some instrumentation or "debug" mode in shepherd that could report how long it took to start each service *maximed delays rebooting <maximed>is there a CLI interface for registering GC roots? <civodul>PurpleSym: good news! i just stumbled upon the ca-certificate-bundle.drv failure <civodul>PurpleSym: not sure; rerunning 'guix system vm' led a different-but-correct ca-certificate-bundle.drv, like you described <civodul>the incorrect one has ~81 inputs whereas the correct one has ~230 <civodul>and the incorrect one lacks glibc-utf8-locales.drv <civodul>PurpleSym: do you know if you had "guix gc" running when the problem happened? <civodul>zimoun: oh, i'll take a look, but i need time as i got hit by a number of "urgent" issues :-/ <PurpleSym>civodul: It was running *before*, but not during. <PurpleSym>And I can consistently reproduce it by running `guix gc`. <zimoun>civodul: “urgent” is always relative ;-) <civodul>PurpleSym: yeah, it seems to have to do with the state of the store <civodul>trying to reproduce it through GC... <PurpleSym>I was thinking maybe the items that are missing from the .drv are missing from the store when running it the first time, but that did not seem to hold true. <civodul>i'm desperately looking for a way to reproduce it <zimoun>oh, I attend to meeting about infrastructure… and they speak a lot about GPU, PyTorch & co. Well, we should discuss that for the next GuixHPC roadmap. I guess. :-) <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 <civodul>so in essence you need to make sure the 'ld' that comes first in $PATH is the wrapper, not the "real" ld <apteryx>I see. So the wrapper acts as the real ld, but adds -rpath for each -L it sees in its args <apteryx>I think the ldc build system calls the GCC driver to do the actual link rather than ld directly, perhaps gcc resolves its own ld, not our wrapper <apteryx>(paste.debian.net is increasingly blocking pastes such as that one, due to spam abuse it says) <apteryx>I think the issue is that ldc now links using our binutils-gold linker, which probably doesn't go through our ld-wrapper script <civodul>so paste.centos.org blocks Tor, but i managed to view it otherwise <civodul>ah, so it could be that it invokes "gold" or "ld.gold", in which case it won't use the wrapper <civodul>but you can create a wrapper under a different name <apteryx>I'll pursue that venue! thanks again <efraim>I should put back on my todo list merging binutils-gold into binutils <efraim>oh yes, the bc input, "excessive math" <efraim>the default is ld -> ld.bfd and ld.gold asis, although you can configure it the other way around if you want. So they can coexist <roptat>shoshin, I'm not even an emacs user, but which variable is unbound? Is it a guix variable, or an emacs variable? <apteryx>efraim: I see; so they can just all live next to each other <apteryx>you still have about 5 days to do so on core-updates-frozen before I trigger the mass rebuild with the batched changes ;-) <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>each version builds in ~3 minutes, so it's not too bad, although it's a lot of intermediate versions <roptat>(that's 32 versions in total, including 0.12.470) <shoshin>roptat: its a guix variable. i have a few ideas. i figured everyone was using emacs-guix :P <roptat>it seems in my previous attempt I didn't use the correct version of the intellij SDK, and I'm a bit worried about the version of asm I'm using right now too <roptat>one of the dependencies I had to guess the URL because it's so old it's no longer listed on the website ^^' <roptat>exciting, but even 0.12.470 is from 2015... it's still a long way to get to the latest (and I don't even have the first one yet :p) <roptat>I'll resume that work this evening, hopefully I can get one kotlin compiler working <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 :-) <apteryx>efraim: I've made a ld.gold-wrapper package; should the binutils-gold package propagate it? <apteryx>well, that should probably be 'ld-gold-wrapper' to match our naming convention <apteryx>hmm, that'd introduce a cycle with the current modules layout <apteryx>is there a way to disable the 'unbound symbol' detection used when invoking 'make' ? It's masking another issue, I think. *apteryx is looking an the 2018 input detection code <apteryx>ah, it's at the package input level, not the module level <apteryx>the later should probably be handled by guile anyway <civodul>i wrote a script that picks 10 packages at random and it seems quite good at reproducing the bug <muradm>tests are passing, but something around test is failing <muradm>no idea, after merging master civodul said: thanks for reporting, i will look at it.. :) <civodul>seriously though, make sure there's a bug report open <blackbeard>civodul: ok I am following this steps $ guix environment --ad-hoc nss-certs -n $ guix gc -R /gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv |grep certificate <muradm>sure, no problem, checked issues.guix.gnu.org looks like no reports, i will send soon <civodul>blackbeard: that alone is not enough to reproduce the problem, unfortunately <zacchae[m]>Someone mentioned chainloading as a method to make a normal install able to boot uefi or legacy bios <zacchae[m]>can someone point me to an example? I don't think chainloading is mention in the manual <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 :-) <roptat>well, icedtea@2 is still failing <roptat>ld saying there are multiple definitions, but they come from the same file? <civodul>it's not rare to find code that *defines* (not declares) global variables in header files <roptat>ok, it's part of the fix to icedtea-1, so let's see if the same fix applies and works for icedtea-2 <roptat>ah the patch didn't apply because the whitespace has changed ***daveed is now known as uu
<crazychicken>Anyone else have trouble installing guixos? It repeats after selecting partition for me <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 <cbaines>ah, OK, I've found the relevant page now <podiki[m]>the partitioning in guix installer has some problems <podiki[m]>I had better luck with a more current installer image than 1.3.0 <roptat>try the one you haven't tried yet? :) <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 <sailorCat> bcma0:1: Missing Free firmware (non-Free firmware loading is disabled) <sailorCat>ieee80211 phy1: brcmsmac: fail to load firmware /*(DEBLOBBED)*/ <dstolfa>sailorCat: this seems like a nonguix question, so you should probably ask there <crazychicken>And now I just tried it with the stable release iso and still nothing. geex3 what do you mean by use no remote during install? <geex3>crazychicken: when it asks about remote derivations or something what is that option? <geex3>fetch remote substitutions* ? <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 bug-guix@gnu.org, 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 <roptat>thanks, hopefully people who are more familiar with the installer can then help you and fix the bug :) <geex3>experimenting with minimal base profile and using "guix environment fooprogram -- fooprogram" in desktop panel shortcuts <geex3>not sure what the point is but its nice not having much in $PATH <apteryx>does touching gdb-10 really entails a mass rebuild? guix refresh won't say so <apteryx>(but a comment in (gnu packages gdb) suggests otherwise <geex3>how to get/copy a directory of .scm files (on a channel repo) into a directory (in $HOME/.local/foo) ? <roptat>geex3, can you clone the channel? <geex3>yea but its full of other stuff <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? <cbaines>(at least for the latest guix revision)