<bdju>did anyone else hit that blender build failure yet? the log was too big for me to paste anywhere I think. I haven't been able to do a successful guix upgrade in ages because of all the build failures lately
<risu>Hi, I've some problems to get guix booting on the liveusb due to grub failing to start properly. Could someone tell me how to build a bootable image with extlinux/syslinux from a foreign distro? I've been fiddling with install.scm but I always end up building an image with grub :(
<jpoiret>sneek, later tell dlowe: are you trying to use u2f from your browser? If so, you might need to help it find the libraries it needs by hand, since i don't think they're included in the browser packages
<jpoiret>yarl: i think it is, and while i also think that adding it as a phase to gnu-build-system is a bit unsatisfactory, it's still the best way currently
<jpoiret>there are still many people hitting these kinds of issues
<risu>jpoiret: yes, that's what I tried first. By replacing `grub-bootload' https://github.com/lfam/guix/blob/master/gnu/system/install.scm#L455 by `extlinux-bootloader' and adding the corresponding module import. But `guix system image -t iso9660 ...` kept producing image with grub. I think I am not selecting the good os-definition in the file but I don't really know what additional option I should give
<jpoiret>yarl: as ludo said, you wouldn't be able to selectively remove that behavior, and gexp->derivation doesn't look like the place for it
<risu>jpoiret: I am not completly sure why it is failing. It stops at "Welcome to GRUB" and hangs. I think it can't properly set up a resolution for my screen. I've tried to blindly navigate the menu. Assuming that even though I don't see it might be working nonetheless. But that does not seem to work either.
<risu>I've tried to change the option passed to grub by modifying the bootloader options. It works and the modifications are correctly reflected in the grub.cfg found on the image but for some reason, GRUB continues to get stuck on the welcome screen
<risu>despite hard coding a screen resolution in the grub.cfg
<risu>That's why I would like to try with syslinux
<yarl>jpoiret, sorry, have been disconnected. I might have misunderstood you. You said "i also think that adding it as a phase to gnu-build-system is a bit unsatisfactory, it's still the best way currently" but this is not currently implemented, right? What I have seen in package declarations that need children reaping is a combo of tini and
<risu>I've tried them before (except native) and it was still stuck on the welcome screen which was very strange
<risu>it's like the grub.cfg does not have any influence (I need to check if grub really reads that file or that file is merely a configuration file that is used to generate a more low-level representation)
<risu>oh, and while I am it, could you tell me where did you see that `guix image -t iso9660` default to (and override the bootloader to) grub. I've missed this info in the manual.
<jpoiret>risu: people have complained about that time and time again but uhm..... by reading the source :p
<jpoiret>gnu/system/image.scm and gnu/build/image.scm are what you're looking for
<jpoiret>risu: what grub.cfg are you talking about?
<jpoiret>it's generated from your config.scm file, and then put in /boot/grub/, and grub directly reads that file
<jpoiret>i think the issue arises with insmod gfxterm, not just with terminal_output gfxterm, so you'd need to remove all that if you're directly modify grub.cfg (although i don't recommend it, you should modify your config.scm instead if you're using that)
<risu>yes, i'm editing the install.scm which generates grub.cfg
<risu>i'll try to get rid of insmod gfxterm when i'll try again tonight
<jpoiret>risu: iiuc the code that generates the grub.cfg, if you have (terminal-outputs '(console)) it shouldn't add insmod gfxterm at all
<yarl>jpoiret (and maybe others), sorry about these questions but 1/ is "#ifdef __linux__" necessary? Guix is supposed to run and be compiled only on linux, right? 2/ Is guix daemon still pulling from nix? I understood it is completely on its own now? There is this "rewriting daemon in guile" goal in roadmap.
<afr>Hi! I'm trying to install Guix on the Acer Aspire One a repair org has lent me, but I can't go to the graphical installer (using ctrl+alt+F1), it doesn't bring me to TTY; the F1 key, however, is detected by the default TTY (Guile prompt)
<jgibbons[m]>There should be a fs service you need to stop as well.
<jgibbons[m]>I forgot what it's called. Look for services with "guix" or "gnu" in the name
<jgibbons[m]>unmatched-paren: I disabled some of the external features, and I'm running it in a container without network so it can't get the garbage it's designed to say it needs. I think it can use the current version of mono as a compiler. I'll see if that's enough.
<nckx>jpoiret: I already have, I'm just terrified of breaking somebody's boot by having missed one…
<nckx>I wanna match on ext[0-9]+ — clearly we need to switch to extended regexps in the initrd.
<nckx>What I think we *should* do is drop this fragile mess in check-procedure, make sure the initrd includes all fsck.TYPE symlinks that upstreams already maintain for us, and simply invoke those that exist. Doesn't that make more sense jpoiret?
<nckx>That way, if fsck.vfat ever does support exfat (it won't), upstream will add a symlink and we'll magically DTRT. Same for fsck.ntfs4.
<nckx>Although on the flip side, names like xfs_repair/btrfs/… are deliberately non-standard because they don't want to be invoked lightly. We don't, but it still breaks my proposed scheme.
<jpoiret>but still, fsck.btrfs won't do us any good
<nckx>I want to be able to force a btrfs check in the initrd, because btrfs is a fragile mess, and btrfs upstream can't convince me otherwise.
<nckx>No, we'd keep the custom check procedures for btrfs and such. It was more about automatically growing support for *unknown* types when they appear upstream, which is the only motivation I can think of that guix has all these string-suffix/prefix matches in the first place.
<dirtcastle>how to make guix use substitutes instead of building. I ran guix build emacs --dry-run. and it said downloading which means guix uses substitutes by default. but when I run guix pull it is building. some stuff of the stuff.
<davidl>dirtcastle: "guix pull" builds your local "guix" ifself. guix build <package>, builds a package defined by guix. You can have a look at guix build --help, and/or info guix
<dirtcastle>can I use substitutes instead of building everything myself
<jpoiret>note that `guix pull` will also use substitutes
<risu>and if you're on a foreign distro, not forget to enable the nsswitch service
<davidl>jpoiret: so you can say (I think) that the seed required to build guix is an earlier version of guix itself, by default this earlier version is whatever local version you already have installed. IF that is true - maybe Im wrong - then why can't this be served as a binary still?
<jpoiret>it is served (not as a binary, but as multiple derivation substitutes)
<jpoiret>but those derivations need to be created first
<jpoiret>you can't substitute something that's not a derivation
<jpoiret>(and you will also locally build a profile at the end, but that's because all profiles should be locally built and they're not costly anyways)
<davidl>jpoiret: why does it take so long to run the step "compute-guix-derivations"? There's the term "fixed-output-derivation" - which I suppose "guix" is not, or maybe at least not when you run guix pull? Is guix not a fixed-output-derivation - if so why isn't it?
<davidl>jpoiret: also, Im sorry for my lack of general guix knowledge. I am reading and rereading what you already wrote to figure this out and understand you better.
<jpoiret>fixed output derivations are a way to say: "okay, I know what the end result should be (ie the download of some source code), so let me use the network/non-stateless methods to fetch that and you'll check that it does result in what I claimed"
<jpoiret>those derivations contain the hash of the end result, which isn't the case for all derivations at all
<jpoiret>other derivations, you don't know beforehand what they'll build to, but you can still download their result if it's already built
<jpoiret>theoretically, we could make everything in guix a fixed-output-derivation, that would download prebuilt binaries with the proper hashes, but then guix would not be reproducible and source-based
<davidl>"other derivations, you don't know beforehand what they'll build to, but you can still download their result if it's already built" - right, so comparing a package with guix itself - why can't you know beforehand that if you run guix pull --commit=XXXXXX that it should build to "SOMETHING", while, when running guix build X for some package with a git-download source you would know what SOMETHING is?
<civodul>apteryx: i've pushed the 'guix' package update so i'm ready to reconfigure berlin; lemme know how to proceed!
<civodul>if there's nothing special, i'm fine doing it myself
<jpoiret>davidl: well, the result of building guix depends on the guix source, right?
<jpoiret>ah, the difference with a usual package is that the source is not fixed, ie when you `guix pull` you fetch the latest commits, so you need to compute the derivation based on that, whereas packages come from fixed-output-derivations
<jgibbons[m]>guix shell --container -D mono --export-manifest should give me a manifest including everything required to develop mono, correct?
<jpoiret>no need for --container with --export-manifest
<jgibbons[m]>I think it should output something like (package->development-manifest (specifications->package "mono"))
<jgibbons[m]>It outputs that in the call (concatinate-manifests) if I add another package to the list to include
<davidl>jpoiret: "the result of building guix depends on the guix source, right?" - i suppose it may affect the derivation hash, since you build guix with guix (and it's dependencies), though if ur user is on guix commit 123456 and runs guix pull --commit=234567 then building 234567 from 123456 should be a "known situation" that you can provide a substitute for IIUC. While packages - well they have inputs that would ruin the output by linking (or
<davidl>referencing) to other packages all the time - so any single package may have a different build derivation output differing based on the current guix commit.
<apteryx>was there updates needed to cuirass as well?
<davidl>jpoiret: In my understanding: If all combinations of guix pull "from commit=ABCDEF to commit=123456" were pre-calculated (their output derivations and corresponding binary substitutes), then new versions of guix could be substituted during a guix pull - but all those combinations (from commit=ABCDEF to commit=123456) are too many and thats why it can't be substituted
<apteryx>civodul: ah, that'd be captured in the guix updated package right
<jpoiret>davidl: what i am saying is that, we do have substitutes for the derivations that need to be built
<jpoiret>but we need to create the derivations first, and that takes a bit of time
<civodul>apteryx: right, so we just need to "guix pull && guix system reconfigure"
<jpoiret>unless you've pulled 1 min after someone committed, in which case CI most likely won't have built the substitutes
<jpoiret>civodul: i've just finished working on my grub/luks2 patches, i'll be looking at the installer issues now
<apteryx>civodul: do you remember how to do that? I can do it, but it's trivial now: 'guix pull' on berlin as your user, checkout the latest commit of guix-maintenance, cd hydra and 'sudo guix system reconfigure -L modules berlin.scm'
<apteryx>and finall 'herd restart postgres' should take care of restarting postgresql and cuirass
<apteryx>thanks for debugging and fixing the issue!
<cbaines>apteryx, I think using the maintenance checkout within the root user is better than individual checkouts, this is also what the motd says
<civodul>apteryx: yup, i'd usually run "guix pull" in the root account and work from there, but yes
<civodul>i have to go afk for a bit but i can do that later today
<apteryx>cbaines: why? it encourages people to leave uncommitted cruft which the next person has no way to know if it worthy of being committed or not
<apteryx>if we work as our users I see two benefits: 1. important bits get committed 2. we can keep track of who did what if you use sudo instead of root
<cbaines>apteryx, I guess everyone using the same checkout allows for some coordination, especially regarding the uncommitted cruft. While it's not ideal to have things not committed, there's usually a reason why changes are made.
<cbaines>anyway, I don't usually touch the berlin configuration, so this isn't an issue for me at least
<apteryx>civodul: with the latest Guix, when I try reconfiguring berlin I get: error: sysadmin-service-type: unbound variable
<apteryx>I'm guessing some change that added required description for the service records perhaps, and a badly reported failure
<risu>i've rebuild the image with (terminal-outputs '(console)), it does indeed start in console mode, but it is still stuck there, haha, I guess I'm gonna use guix on funtoo for a while rather than installing it fully .-.
<risu>funny thing though, I had not paid attention on that before but after the timeout my fans go all out, so I think that guix is starting even though the screen keeps printing "welcome to grub"
<risu>maybe i'ma try, configuring an image with ssh, and ssh into it
<unmatched-paren>btw, does anyone know how well guix system does on a framework laptop? i'm considering it as my next computer once this one goes (I know that the wifi probably wouldn't work, but I can easily work around that)
<cehteh>hehe i just came from the GPN and spotted some frame.work laptops there, still dunno how it works with the linux libre kernel
***lukedashjr is now known as luke-jr
<dlowe>I'm running guix on a framework and I'm pretty pleased
<sneek>dlowe, jpoiret says: are you trying to use u2f from your browser? If so, you might need to help it find the libraries it needs by hand, since i don't think they're included in the browser packages
<davidl>lembrun[m]: "is everyone running guix on ssd? it feels so painful on an hdd": I feel you man. I used HDD for years and it sucks. Then I finally got a librem for puri.sm with and nvme, and it's a different life. I was putting my x200 laptops out in the snow for the guix pull and guix package -u because the webkit-gtk wasn't building on the CI so I had to build locally and stuff. It was horriblea.