IRC channel logs
2024-12-06.log
back to list of logs
<sonolin>how do I prevent guix-daemon from writing to disk? Seems like its constantly writing <sonolin>NM was just a misconfiguration, wasn't guix's fault <twashing49>find the "manifest->packages" symbol. `guix describe` shows that both guix and nonguix are part of my current generation. `guix show linux-libre` shows that it's available in the current profile... What am I missing? <mange>Have you run "which guix" to check what you're actually executing, as suggested by Tobias? <mange>I also doubt you want to be using manifest->packages. I think you probably want specifications->packages (rather than going via a manifest), and to avoid the things at all (your other case tries to convert a list of packages into a manifest and back, seemingly for no reason). <look>I don't think manifest->packages exist in guix (except for an unexported proc in guix-refresh) <mange>Another reason why I doubt they want to use it. :-) <twashing49>Riiight. Trying a simplified "package" definition now... <twashing49>And `$ which guix` gives me: `/home/me/.config/guix/current/bin/guix` <twashing49>Ah, it looks like `guix system reconfigure ./system.scm` is working after the clean up. Thanks guys! <look>Is there a way I can modify the build-inputs of the build-system itself without rewriting the build-system? <mange>Can you be more specific about what you're trying to do? <jason>cross posting from #systemcrafters: hello! I'm trying to get guix going using the <jason> sway+guix configuration a la <jason> but keep having trouble getting gdm to start sway. <jason> When logging in the screen goes black but then <jason> immediately logs out. As I understand it this should <jason> be handled by the package like it is for other wm <jason> packages. Do I need to make a desktop entry? <look>mange: Sorry, I should've been more specific, but I figured it out after looking at source, the answer was using the #:native-inputs key to overwrite the build-system's hard-coded build-inputs, thanks anyways for your willingness to help, really appreciate it :) <mange>jason: I don't know the answer to your question, but that sounds a bit like Sway could be crashing. Have you tried running Sway directly from a tty or something? <jason>mange: running sway directly from a tty works <mange>Hmm. Sorry, I don't know the answer and I don't have time to experiment with it now. :( <jason>np, I bet you're right and am looking into it <mange>GDM sources environment variables differently for Wayland (maybe it doesn't source profiles, or something?). I don't know the details, but that could be a direction to check. <mange>Can you also show us the command that you're running, and the full output that you get? <homo>guix shell -f inferno.scm <homo>code license is not a problem anymore, it changed from LPL to MIT <homo>never mind, the problem is fixed after replacing (invoke "cp" ...) with (copy-recursively) in unpack phase <PotentialUser-6>Hi. I'm new to Guix. However I ran into some issues with the installer. I'm trying to do a UEFI setup, and I think I've tracked the problem down to `gnu/bootloader/grub.scm`. Grub is passed the `--target=i386-pc` flag, which fails. Is that flag supposed to be hard-coded? Should I just create a fake bootloader? <mange>The two places that pass that argument are in install-grub-efi32 (which sounds 32-bit, and thus i386-pc?), and install-grub (which had the i386-pc line added in a commit talking about legacy BIOS, and thus not relevant for UEFI?). Which one do you think is causing your problem? <mange>Notably, install-grub-efi doesn't have a hard-coded --target value. <mange>What are the symptoms of your problem? Are you getting an error message? A non-bootable system? <PotentialUser-6>I think the issue is occuring in `install-grub`? I'm not *that* familar with Guix so I'm not 100% sure. Also, I can't find `install-grub-efi`, even with a recursive grep. <mange>Oh, right. I'm looking at master, but I expect you're using the last release (1.4.0 or something?). <mange>I just took a look at 1.4.0 and it seems the same. I can still see install-grub-efi. Are you using the grub-bootloader, or grub-efi-bootloader? <mange>Yeah, so that should be using install-grub-efi, which should not be passing a --target at all, according to the commit tagged v1.4.0 in my checkout (8e2f32cee9). I'm looking in gnu/bootloader/grub.scm at the forms starting on line 795, and line 608. <PotentialUser-6>Oh, I think I pulled the latest commit on my current device, and I have 1.4.0 on the soon-to-be-Guix device. <mange>It looks like it was added in 2017, so that's wild. <PotentialUser-6>gnu/bootloader/grub.scm:889:(define-deprecated/alias install-grub-efi-removable <mange>Ha, turns out *my* checkout was out of date. <mange>So then grub-efi-bootloader uses (make-grub-efi-installer), which only sets a --target if it's called with a truthy #:efi32? argument (which it's not). <mange>But the conclusion is the same: it shouldn't be adding --target if you are using grub-efi-bootloader. <PotentialUser-6>Oh I'm sorry I think I've been mis-reading the error this whole time. <PotentialUser-6>It errors out *because* there is not a `--target`, and tries to read from some i386-pc directory <PotentialUser-6>`/gnu/store/<some hash I refuse to type out by hand>/sbin/grub-install --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /mnt/boot` <mange>You could try grub-efi32-bootloader? <PotentialUser-6>I'm running Guix through Ventoy, which seems to only boot through legacy, but I don't know if that is the problem here <mange>Have you tried using grub-bootloader? (I really don't understand any of this, so I'm just hoping that we either stumble onto the solution, or someone more experienced than me shows up. :) ) <PotentialUser-6>Grub-bootloader works, but it's legacy mode only. Unless I'm just losing my mind x3 <mange>Right, I have no idea what ventoy is or how it works. I use dd to copy my things onto a disk. :) <PotentialUser-6>You just drag and drop ISO files into the folder and it has a nice boot screen for them <mange>Naa, not a waste of my time, just I don't really understand all this boot stuff, so I can't help much. I hope you manage to figure something out. :) <basicnpc>Hello! Trying to install guix system on target machine (lenovo yoga). Currently missing a free firmware for wifi, but I don't have eny ether cable either. Any thought? <basicnpc>Some suggest to try download the non-free firmware, and put it via another usb stick. But I don't know if the (libre~) kernel will refuse to load it even if I force it with a manual `modprobe`. <mccd>Heya, if I understand the manual correctly, guix archive --generate-key is automatically run on a guix system <mccd>So I'm trying to set up jobs for the laminar CI. It says that jobs (which are script files) should be put in a folder /var/lib/laminar/cfd/jobs. Is there a way to script guix to simply copy a file over and run chmod +x on that file? <mccd>is the right way then to make a package that symlinks the file over to that location? <mccd>or maybe a service extension? <Rutherther>sneek: later tell mccd: package is not the way to put something to /var. Packages can output something only to their output path in the store. The right way is a service. I am not sure which one would be the best. There is special-files-service-type, but it doesn't really allow you to chmod it and it is just a symlink. I don't think there is one that would copy files to arbitrary locations in guix channel, so you would probably have to go with... <Rutherther>... extending activation service type directly, and making a script that copies it. But maybe I am missing information about a service that already does that. <gabber>how can i build only the guix cookbook? <Googulator>Is there a known breakage of "guix shell" with the latest guix? I'm trying to do "guix shell ghc@4.08.2", but it's pulling the latest GHC instead <divya>Is it just me or ./pre-inst guix build [package] usually takes this long. I've been trying it with my new machine (8 cores, 16 threads) and looks like it's building everything and it's already been 4-5 hours. <gabber>Googulator: does it help if you pass a `--pure' flag? <divya>Yes, and also Googulator try passing this through a manifest.scm <gabber>divya: which package? depends on what checkout you're on and whether there's substitutes available for the dependends (and the package) <divya>gabber: I'm trying to build `lean` from a patch that was sent some time ago (7275). <gabber>Googulator: i think i've seen similar behaviour but i am not sure whether i managed to work around the issue <Googulator>even worse, it isn't trying to pull the latest GHC in addition to the version specified, but rather it wants to pull the latest one *only* <Googulator>also "guix shell -D ghc@4.08.2" just gives a plain guix shell without installing any prerequisites for manually building GHC <Googulator>I also tried `guix shell -e '(@@ (gnu packages haskell) ghc-4)'` - still gets 9.2.8 instead <Googulator>divya: is that with latest guix (d75d1fe6ac7ded7e61322d18b07d347beb609aa0)? <divya>Its from d97a67d41de142c0fbdba55e96bfc147482bfae2 <divya>But I doubt that would have anything to do with this. <divya>Also finally I can use the latest rust, thanks efraim for all the hardwork. Once I get over my illness and finish some burdens, I'll try to help you out more :) <Rutherther>"guix time-machine -- shell ghc@4 -- ghc --version" prints me "The Glorious Glasgow Haskell Compilation System, version 4.08.2" <Googulator>unfortunately time-machine doesn't help here, still trying to download the substitute for 9.2.8 <Rutherther>so what is it. Does the shell have 9.2.8 or does it try to pull ghc 9.2.8? because yes, it does pull ghc 9.2.8 even for me, but the shell has 4.08.2 that I requested <Rutherther>ghc doesn't. The profile with ghc does. Specifically, the package cache file is built when you create a profile with ghc packages. And the ghc under ghc symbol is used for that <Googulator>except in this case, it's a bit worse than just an additional download (as with 8.4), because it also introduces a trust issue (4.08.2 to 7.0 are semi-bootstrapped from intermediate C quasisource, while the newer ones depend on a binary) <Rutherther>Googulator: so that is excluding 7.0, right? because if I am looking correctly, ghc-7 depends on a downloaded ghc-binary, and then the rest is built off of ghc-7 and following <podiki>ACTION pushed some updates to mesa-updates to build <Googulator>Rutherther: ghc-7 is 7.10, which is after the 7.6 gap <Googulator>ghc-7.0 is the last one to build from the 4.08 semibootstrap <weary-traveler>users of guix who use debbugs.el, your view will now be less cluttered when invoking M-x debbugs-gnu-usertags . i went ahead and closed some spurious tags (typos, test tags, tags that were inapplicable) <User-42>anyone else have issues with librewolf? `guix shell librewolf`on freesh pull gives me "guix shell: error: librewolf-neuter-locale-download.patch: patch not found" <lynn_sh>hello, im interested in using bochs for debugging. it normally ships with a bios and vga bios binary that is used for running it. am i correct in thinking that those bios files are not distributed with guix? <frollamma>Hi everyone, I'm a beginner with GUIX. I'm trying to delete a profile in guix but I didn't find a solution online yet. I created the profile by running `guix install [something] --profile=guix-dev`. I have two symlinks now in my directory now but I don't think that deleting them is enough to completely delete the profile <homo>hi, is there any example package that involves fetching git submodules? <podiki>homo: look for the "recursive" keyword in the git-fetch source <homo>amazing, github gives ssl error when trying to download recursively <lynn_sh>is guix shell --container --emulate-fhs always going to be in a 'pure' state? or do i need to include pure <rekado>frollamma: "guix package --delete-generations[=PATTERN]" is what you need to delete generations <podiki>lynn_sh: yes a container is always "pure" since it is in a separate namespace <podiki>is anyone able to check on Berlin's status? i would expect many x86_64 builds (from mesa-updates I pushed) but most workers idle <lynn_sh>hello, i am using guix shell qemu --container --emulate-fhs. running qemu-system-i386 says "gtk initialization failed." when doing this in guix shell qemu --pure, no such issue occurs. is this a bug in the emulated fhs, or am i misunderstanding something? <homo>there appears to be bug in git-reference, if first recursive? was not specified, it downloads non-recursively, but then when recursive? is set to #t, it doesn't try to download repository recursively, instead it uses already non-recursively cloned repo <podiki>lynn_sh: "pure" and "container" are very different, pure if I remember just makes a clean environment, but container is running separately (like a docker container, though not quite a vm) <lynn_sh>is it expected for a package to not have what it needs to run in a container context? podiki <podiki>homo: it is a known...limitation? not sure what, but it is how things are hashed and looked up. there was some discussion on guix-devel at some point, i don't remember the details <podiki>lynn_sh: a container has nothing but what you specify; e.g. no "ls" command if you didn't provide coreutils <podiki>lynn_sh: so you must specify everything <lynn_sh>i guess i should start with qemu inputs for build and see if that runs then. it isn't exactly forthright with what it is missing ol <podiki>lynn_sh: regarding your earlier question: we ship no binary files whatsover, everything is built from source (okay, some bootstrapping exceptions) <lynn_sh>it builds from source it seems, i managed to find it. i had to do --emulate-fhs to get a clean path to it :) thank you though! podiki <lynn_sh>fortunately we also have seabios and sgabios available in guix even if i didn't have the bochs ones <homo>ok then, I guess I have to run guix gc <Rutherther>if you give it the same hash, it just picks the file that matches that hash. Because, why not. You told it it's that file <janneke>ACTION fixes offloading to chilhurd's again <podiki>re: berlin: do we have i686 as higher priority now than x86_64 or something like that? still seeing nearly only i686 jobs from mesa-updates <[>podiki: what kind of namespaces does --container use? <[>it's at least using a user namespace and a network namespace <podiki>[: I don't know these details, but I think the technology is just linux namespaces...i don't really know <[>the answer seems to be '("user" "ipc" "uts" "net" "pid" "mnt") (from gnu/build/linux-container.scm) <roptat>I'm building the kernel on aarch64 (no substitutes) and it fails with "FAILED: load BTF from vmlinux: No data available" <roptat>maybe it was fixed in the meantime, it takes days to upgrade the system... <podiki>were there other parts to the message? saw something similar on another channel, issue was user needed more memory <roptat>I had disk space issues before, I freed a few GBs <roptat>and the one taking the most memory is... shepherd :/ <roptat>can't kill PID 1 to get more memory ^^' <roptat>I should probably reboot though, it has almost 1 year of uptime <mccd>Does anyone have any examples of a simple service extension that copies a directory of files over to a location? <sneek>Welcome back mccd, you have 1 message! <sneek>mccd, Rutherther says: package is not the way to put something to /var. Packages can output something only to their output path in the store. The right way is a service. I am not sure which one would be the best. There is special-files-service-type, but it doesn't really allow you to chmod it and it is just a symlink. I don't think there is one that would copy files to arbitrary locations in guix channel, so you would probably have to go wi <podiki>i mean you could kill it....would solve more than the problem :) <Rutherther>mccd: just see special files service type and replace symlink with copy <roptat>podiki, it failed to shutdown :p <podiki>ha so you had to do it anyway....or sysrq magic keys? <PotentialUser34>hello, I'm trying to package some software for the first time, and I'm wondering if there is a git importer? There are other importers, and some even take a git URL (`guix import cran --archive=git`) and there is also `guix refresh --type=github`, but I guess no generic git(hub) importer? <divya>PotentialUser34: You can just do `guix download` for a git repo though, the last time I packaged an app from Github I used that to generate the hash and everything else. <PotentialUser34>everything else? At the moment, I'm handcrafting the whole package record, and indeed using `guix download` to generate the hash, but I don't think a package definition is created? <divya>Well PotentialUser34, a git repository can be structured like anything :) It can be a rust crate, or a meson build. Guix has no way of knowing that. The specific importers, whether for CRAN or Rust's crates are able to do so because those pakages are distributed in a unified manner from a single repository/source. This is not the case with all git(hub) repositories. <divya>And indeed, unless your package of the git repository is available also as a package in any of these specific package repositories (CRAN, crates.io, stackage etc.) manually handcrafting the package is the way to go. <PotentialUser34>alrighty! I thought already that a generic git importer would be barebones (I thought maybe getting a description from github and/or searching for a LICENSE file), but the little amount of information and the large variety probably don't make it worth :) <eikcaz>Anyone been able to run WASM stuff on Guix? I tried newest ungoogled-chromium and icecat and the programs say my browser doesn't support WASM. I ensured the icecat version was above the required firefox version for WASM support, yet it still complains <divya>PotentialUser34: No worries, if you need any help with the packaging, feel free to ping me and if I'm offline shoot an email (divya@subvertising.org). Thank you for your efforts on packaging, much appreciated <3 <divya>eikcaz: The ungooglec-chromium hasn't been updated in a long time, have you tried librewolf? Icecat, to my knowledge, blocks all external JavaScript interfacing, and some of it is necessary to run WASM. I tried last time in librewolf and it was working. <divya>Is it a local WASM project you're trying to test or a WASM website? <stochastic>I'm still unable to pull from the Guix repository because of some meson issue <divya>stochastic: Which commit? I pulled earlier today and it seemed fine. <homo>I managed to build and run inferno, but it's not yet ready for submission <divya>homo: Nice, do you wish to publish an accompanying channel for this as well? <homo>no, I want to upstream it <homo>these 2 files are for "guix shell -f" <divya>Oh, sorry its a package. I confused it for a guix channel or something. <stochastic>> stochastic: Which commit? I pulled earlier today and it seemed fine. <stochastic>Apparently version `4127992ff7c3b2aa0c3dfd1760ee4d7379b9f1db` <ekaitz>we could try to upstream that, sure <divya>Looks like a classic Plan9-based distro <ekaitz>divya: it's the next iteration of plan9 by bell labs <homo>divya: it is created by same people who created plan9 <ekaitz>same way plan9 is the next iteration of unix, it's a new thing that came next <ekaitz>homo: could you try to separate the modified freetype library to a package? <homo>ekaitz: maybe, but the biggest priority right now is to make inferno use at least 1 font available in guix, as fonts license problem was the original reason inferno was rejected <ekaitz>homo: yeah... i saw your comment there <divya>ekaitz: Quick question: there's no way out of `./pre-inst-env guix build [package]` andlong hours of waiting? <ekaitz>divya: it depends on the package you are building, some take hours always <divya>I'm trying this patch (72755) to build a newer (4.10) version of Lean. <divya>Guix has a really old version of Lean, and I've been recently involved with Lean development, so yeah. <ekaitz>idk, it be because some package is broken <ekaitz>or because you don't have substitutes of some dependency <divya>No worries, I'll check further. Thanks. But yeah, even last time ./pre-inst-env guix build tries to build everything from GNU Mes, to some versions of gcc, gash and what not. <homo>ekaitz: modified freetype uses #include "lib9.h", and only provides static libfreetype.a, so a separate package is easy to do as subpackage <divya>ekaitz: I don't know, I just know that it went for 6 hrs and wasn't enough. Maybe I'll leave it running overnight <ekaitz>divya: but what do you have in the screen? what's the last log you have? <divya>ekaitz: I thing my power went down and I didn't see the log hash. Let me see if it builds again, if anything doesn't work I'll let ya know. <Rutherther>divya: why aren't you building from a guix revision that has substitutes available? <divya>Rutherther: How do you mean? Can you link to something <homo>I need better look at the source code, maybe it's possible to use freetype provided by guix and just rename everything that inferno redefines <divya>Rutherther: What exactly should I do with this... <xerty-tempo>I have emailed to gnu.org webmasters for the purpose of updating Guix System Screenshot with KDE Plasma on the "try GNU/Linux" section on the main page, and they told me I need to ask guix people first so here I am(I know nowadays factions of gnu people does not want to associate with fsf-owned www.gnu.org (so I was a little afraid of making this