IRC channel logs
2026-10-28.log
back to list of logs
<Icy-Thought>I just realized compiling stuff manually takes ages.. how do people with gentoo cope? <Icy-Thought>I wonder if it has been 40 mins or more since I started the build... lol <sham1>There's a reason why even Gentoo has some binary packages. Like you can install libreoffice, chromium, firefox etc. as a binary package. But you also don't get the USE flags <Icy-Thought>I wonder how long the total build time took... 1 hour? But it works just fine <Icy-Thought>I wonder if we have something like nix-review pr post-results <morte>hello, I've been getting an error message while trying to use my Atheros AR9271 wireless card on guix <morte>it keeps failing to load the firmware <morte>and if I unplugg the usb cable it kernel panic's <gnufairy>Hi, I'm doing a clean install on my Dell Lat E6400 on working wifi, but when I run guix pull to update my system, I am running into a git error syscall failure. Is there a fix for this? (GNU Guix System). Using only the default git.guix.gnu.org channel <cnx>Thanks, snihil, I've push the revert for the time being. If that's the wrong thing to do, it's always possible to revert again. Breaking people's audio seemed bad enough to warrant it. <apteryx>is it a bug that 'herd status dhcpcd -n100' does not show 100 lines, even when there are more lines in the log file? <apteryx>err, 'herd status networking -n100' in my above example <mra>hey! is there a way to configure Guix to store the kernel and initrd on the boot partition, instead of in the store? <ieure>mra, There isn't a turnkey way to do that. You could write a system service that copies them from the store to /boot, but you'd also have to do something to make grub look there. I've never read the bootloader code, so not sure how hard that is. <mra>ieure: hm, I see. the problem I'm having is that currently grub is trying to refer to the kernel in /gnu/store, but this is on a ZFS dataset, and grub... doesn't seem to speak ZFS very well <mra>in particular, it can't seem to figure out how to read the zpool/gnu dataset that I have the store living on <apteryx>does AR9271 have free firmware? otherwise that's the issue <apteryx>sneek: later tell morte does AR9271 have free firmware? otherwise that's the issue <mra>apteryx: related question, is there a way to tell guix to ignore missing firmware? i'm currently running into some issues with bluetooth, but i'm just trying to get the system to boot, so i don't really care if it works or not <mra>but right now if i boot i just get a never-ending sequence of kernel log messages complaining about missing bluetooth firmware <apteryx>I'd disable the chip in UEFI, that'll be the most reliable way <mra>apteryx: hm, i've tried a few UEFI settings, but i haven't managed to disable it. is there another option? maybe add it to the modprobe.blacklist argument when i load the kernel or something? <apteryx>OK; it worked on mine. I haven't tried the modprobe.blacklist route, but it must be doable too. <hako>apteryx: re herd status log: the logs shepherd outputs are stored in memory, there's a default-log-history-size parameter and by default it's 20. <apteryx>but thanks, I'll bump it on my systems <mra>apteryx: I just can't seem to find the setting in my motherboard's UEFI. I'll take another crack at it tomorrow <abrenon>what handles paths in .desktop files? xfce4-file-manager.desktop provided by xfce4-settings has Exec=exo-open (so, not patched to refer to a specific version inside the store) while xfdashboard, also a gnu-build-system package, has Exec=/gnu/store/…/bin/xfdashboard <abrenon>I see no obvious difference in their package definitions, both passing flags to configure but I don't see anything that reads like 'guix, please go ahead and patch the Exec values inside the .desktop provided by these packages`, so I don't understand why xfce4-settings did it and not xfdashboard <hako>abrenon: the patching procedure uses commands installed by the current package. `exo-open` is from `exo` and not part of the `xfce4-settings` package. <wingo>what's the usual way to install rust 1.95 on guix? <wingo>the one in main is 1.93, it seems there are some 1.95 packages but they are not available for installation via guix shell <jlicht>which gives me rustc 1.98.1 right now, not 1.95 <untrusem>guix shell -e "(@ (gnu packages rust) rust-1.89)" -e '`(,(@ (gnu packages rust) rust-1.89) "cargo")' <yelninei>is someone here familiar with libparted/guile-parted? <bjc>i'm not, but i'm willing to look <yelninei>bjc: For context https://codeberg.org/guix/guix/issues/12141 it says hurd in the title but i feel like the issue with with-tmp-device resuing the same filename is also problematic on linux .I tried debugging it but libparted is full of global state that never gets cleared <bjc>oh man, i wonder if this is similar to the cache/object invalidation issues we had with guile's libgit <bjc>worked on linux, too, but not hurd. no idea why it worked anywhere <yelninei>i dont think so, the guile version has its own cache that it never frees. all the tests pass when using unique test directories <bjc>if it reuses memory under the hood it might explain it. the other issue was, iirc, that the weak object ref wasn't being held as expected, causing a memory free <bjc>i dunno, i'm guessing, but it has the same smell <yelninei>but my C example is shows an extra partition at the end that should not be there where no guile is involved. (both the guile-parted hash table and libparted linked list cache are never cleared) <abrenon>(+ thanks a lot for the pointers to solve the thing with guix shell + containers, I'll try and write a fix soon) <abrenon>is the 'patching procedure' part of gnu-build-system? 2 build-phases have 'patch' in their name but if I understand correctly they deal with the shebang and not executables <abrenon>(as in, executable names found in scripts or .desktop files) <bjc>oof. the libparted docs are pretty anemic <bjc>at least the ones on gnu.org. are there better ones? <yelninei>yeah the manual is mostly only for parted(8) but not the library part <bjc>i am a little concerned that these pointers are all (bs:pointer uint8), but that may be me misunderstanding the bytestructure library <bjc>alrgiht, this is gonna take more than a little bit of time. i'll update the ticket if i can figure anything out that's worthwhile <bjc>haha, i just realized who i'm talking to. i was reading your nick as youpi. sorry =) <yelninei>bjc: Ill see if i can find something out myself as well (right now I would lean towards guile-parted misusing libparted by reusing the test file path without clearing the libparted cache but idk) <nckx>abrenon: Bit late but no, patching the source is not part of any build system but handled earlier, by <origin>. ‘guix build -S’ runs no build system must always return patched source. It happens in patch-and-repack in (guix packages). <nckx>Though one might say it has… build system ambitions, judging by its size :) <nckx>s/runs no build system/runs no build system but/ <decfed>how does one influence what is written to /etc/profile in gujx system? I want to change the umask. <ieure>decfed, Use etc-profile-d-service-type. <decfed>ieure So all those .sh files then get concatenated? Will that overwrite the existing entry then? <ieure>decfed, It works the same as /etc/profile.d on other distros. <ieure>The files are not concatenated, they get sourced. <juli>anyone have experience getting openvpn running? I was handed a config for work and told to use openvpn3 which is not in Guix... this network requires a webauth flow <ieure>juli, Pretty much every shop I've interacted with has moved to Tailscale or something else WireGuard-based or -like. <juli>allegedly this shop will move to wireguard one day. i am reliably informed this means sometime shortly after the heat death of the universe XD <abrenon>nckx: indeed, that function is massive <abrenon>but I think I'm confused about 'patching' and didn't use the right word for what I'm looking for <abrenon>I see no '/gnu/store/…' anywhere in the source directories output by `guix build -S`, neither for `xfce4-settings` nor for `xfdashboard` <yelninei>abrenon: You might be looking for patch-dot-desktop-files in gnu buuild system <abrenon>for real? how could I miss it with such a name?! thanks! <abrenon>(and so that would be linked to these packages using gnu-build-system and not copy-build-system like the thing I'm trying to package) <ieure>The upstream source can change at multiple points in the build process: Package developers may apply patches directly to the upstream source; they can also programmatically manipulate source in build steps; and the most common programmatic changes (like `patch-source-shebangs') are driven by the build-system. <abrenon>and I suppose there is no equivalent phase to edit executable scripts within packages (to resolve statically what the shell would do with PATH at runtime) because the example of grep given in the manual calls (substitute* …) to achieve this <ieure>abrenon, Correct. It's safe and reliable to automatically patch shebangs, but neither safe nor reliable to try replacing program paths in blobs of arbitrary files. <abrenon>how would one go about distributing a package consisting of a script calling executables from other packages? I know it works with propagated-inputs, but it's been pointed to me that I tend to overuse it. Would one simply (substitute* …) the script to insert the absolute paths to the required executables? Would they still need to appear in the inputs in that case? <ieure>abrenon, Yes, include the paths. The packages have to be in your package's inputs, but don't need to be (and should not be) in propagated-inputs. <ieure>abrenon, The distinction here is closure vs. profile. Including a store path in your package adds the package owning that path to your package's closure -- which is more or less the graph of dependencies needed for your package to work. <ieure>abrenon, Propagated inputs put the dependent package into the *profile* including your package. This is the only way most other Linux distros work. <abrenon>it edits a Makefile but that exactly what I need to do my shell script <ieure>What Guix lets you do is, if you have a package foo which needs findutils, you reference its store items from your package. That puts it in the closure, and your package can call /gnu/store/.../bin/find -- but find isn't included in the profile itself. ex. `guix shell --pure foo -- find' will not work. If findutils is propagated, it is included in the profile and that command will work. <abrenon>(yeah, that's what I tested this morning, realizing that my great script wasn't really ready for release, when I entered a containered shell to test it and could call zenity directly) <ieure>This is confusing when coming from other distros, which don't have this distinction. If your package depends on findutils, it's installed on the system and usable to all users. <abrenon>I understand the distinction, but I lack the experience in packaging so I tended to do what just worked <cnx>they're not strictly required, but you should include the inputs and use search-input-file so that modify-inputs and --with-input would work for the dependant <cnx>oh boy i didn't scroll <abrenon>cnx: do you mean if I manually resolved the path to zenity the default version would always be used even if someone built my package with `modify-inputs`? <abrenon>(I mean, I would've probably just used search-input-file by copy-paste-modifying the example I found in the build-phase manual page, but it's scary that I might've introduced such a bug in my package if I had tried not to be lazy) <cnx>if you use something like (string-append #$hello "/bin/hello"), then it doesn't matter what hello you have in the inputs <abrenon>(also, impressed by the speed with which you retrieved the relevant issue ^^') <cnx>i referenced it quite often <cnx>browser history search good <abrenon>thank you so much for all the help everyone <abrenon>I think I have everything I need to finally package that thing and put it on codeberg <Icy-Thought>lilyp: thank you for getting font-mono merged into guix!! <sneek>Welcome back lilyp, you have 1 message! <lilyp>sneek later tell haugh I'd look at proxy-formals.scm:5:5 <wingo>hey again :) after an upgrade, in gnome, auto screen lock doesn't work for me. locking manually does work tho. any ideas? <civodul>vagrantc: twas that terrible EMFILE again :-/ <vagrantc>yeah, bordeaux is chugging along at least ... great we have two largely different build farm implementations ... for this and other reasons <vagrantc>seems like bordeaux managed to build the linux-libre updates and make substitutes available in less than 12 hours for multiple architectures <vagrantc>ci seems to take at least two or more days before substitutes are available <vagrantc>classic homogeneity vs. diversity ... takes more work to have diversity, but overall healthier in the long term <ieure>civodul, I just reconfigured yesterday, so not sure if Cuirass is still wedging, but it was still happening for me with the last generation. <ieure>Last generation was ac20589f7f35a46c76d55288a1ebed645b797587 (around 6 October) and it was still failing in the same way I reported. <Kabouik>I got Guix system running natively on my qwerty-slider phone, with the mainline kernel (Linux, not libre). I'm so excited. :< It's still not end-user ready but it's already running Sway, foot, icecat, and hardware bring up is progressing. It's heavily LLM assisted but these tools are good to do what no one else would ever do manually. <sneek>Welcome back Kabouik, you have 1 message! <sneek>Kabouik, stampede_ says: I think what you are looking for then is the `--keep-failed`, which keeps the build tree of failed builds, so you can check any logs that were left there <Kabouik>later tell stamped_: Thanks stamped_! I've progressed after that issue I was having (the project being this Guix system porting above) <Kabouik>sneek: later tell stamped_ Thanks stamped_! I've progressed after that issue I was having (the project being this Guix system porting above) <pdpnw>apologies if this is the wrong venue for this. I've been packaging asm-lsp for myself, and was considering trying to upstream it. I've patched what I believe is a deviation from the LSP protocol in the package (otherwise it's broken with Eglot), but I cannot with confidence say my understanding of the protocol is correct. the maintainer is unresponsive. Given this, is this a better candidate for a <pdpnw>channel, or should I seek confirmation of the patch and it's validity and try to upstream? coincidentally, would anyone be willing to validate/correct my assumption? <ieure>pdpnw, I would validate that your patch is legit. You might also consider forking the repo and committing the fix there. <ieure>pdpnw, Ultimately though, it's the discretion of whoever reviews the PR to decide what is or is not acceptable. <pdpnw>ieure: thats fair, I guess next steps would be to try a few IDEs and see how they behave before getting too far ahead of myself <pdpnw>essentially, the patch modifies the response when no information about a symbol exists. the current state is an RPC error which I feel is incorrect (I feel it should simply be empty). With my rationale being that the spec seems to suggest an empty response without some actual error (like inability to process a valid request). My own rationale being that there are so many random keywords and symbols <pdpnw>in assembly land it's impossible to always have information.