IRC channel logs
2025-09-08.log
back to list of logs
<GalaxyNova>I've been getting an error when I run `guix pull` <GalaxyNova>namely this: `guix pull: error: Git error: SSL error: received early EOF` <apteryx>hako: any idea why the ordering in #:cargo-package-crates is sensitive for a workspace dependency? <apteryx>I need to list the package itself last, e.g.: #:cargo-package-crates ''("salsa-macro-rules" "salsa-macros" "salsa") otherwise it would fail to find 'salsa-macro-rules'. <hako>apteryx: There's dependency between these crates, the packgae phase makes them available to others one by one, so the ordering matters. <apteryx>OK. Is this documented something? It sent me wondering for a bit. <apteryx>I think my 'ruff' package may start building now, but it needs rust 1.87. I'm trying to switch rust to 1.88, but hitting some test failures <apteryx>maybe easy to fix: looks all related to Failed to invoke program "git-upload-pack" <apteryx>ah yes, that's already covered then, thanks. <apteryx>for the rust 1.88 test failures, I guess I just need to register a few new gitoxide tests to exclude <hako>thanks, I think we can start a new rust-team cycle to update the default rust, will take a look soonish <apteryx>failed on some checksum check failure: unable to verify that `cranelift-object v0.118.0` is the same as when the lockfile was generated <apteryx>I tried reordering the check phase after the install phase just in case, but it didn't help <trannus_aran>simendsjo: ew, wtf? Loser shit to ddos codeberg over basic human decency <csantosb>Ey Guix, I have a strange behaviour here ... <csantosb>When I add "#:use-module (gnu packages commencement)" to (gnu packages fpga), any package build fails <civodul>csantosb: ¡hola! yeah, don’t do that :-) <civodul>as a rule of thumb, that module must not be imported anywhere <civodul>or the daemons of cyclic dependencies will show up <csantosb>Thing is, I need cc in a package; so I need gcc-toolchain <csantosb>And the message is "hint: Did you forget `(use-modules (gnu packages commencement))'?" <civodul>another rule of thumb: never use ‘gcc-toolchain’ as a package input :-) <civodul>because the default build env already contains something equivalent <civodul>usually your options are to either convince the build system to use ‘gcc’ instead of ‘cc’ <civodul>(by setting a configure flag or env var) <csantosb>I'm using pyproject-build-system, but I need cc for the tests <csantosb>... ok, I guess this is it, now I need to convince a binary to use CC env, thanks ! <efraim>civodul: I see the cross-gcc-build-phases error, using axoloti-runtime as the test package <Rutherther>dariqq: you seem to be involed in cross compilation on guix... do you happen to know why python/pyproject build systems do not support it? Are there any specific blockers or is it just that no one has taken time to do it? <efraim>civodul: I've fixed it locally, I'm trying to make sure it doesn't break more things <efraim>whoops, suddenly made it so that no packages support powerpc64le-linux <efraim>when did gcc gain powerpc64le support? <c0co>i generated an iso by invoking guix system against my system.scm, and dd'd it to a usb stick, but can't boot from it on another device. I'm probably missing some obvious step here, does anyone have any suggestions please <Rutherther>c0co: you mean guix system image, right? If so, I don't think you're missing an obvious step, it should usually work. What bootloader do you have in the system configuration? <c0co>rutherther - just grub, nothing special <c0co>USB formatted MBR and partition is FAT32 <c0co>and yeah, guix system image <c0co>ok, i re-ran dd against the USB and it worked this time <c0co>well it booted but kernel panicked (not syncing: VFS: Unable to mount root fs on unknown-block(0,0) <frankie>I tried a couple of times to subscribe lists.gnu.org guix lists without success, do they require manual approving? <identity>frankie: iirc subscribing does not require approval, only sending mail to the list <adanska>efraim: are you able to build gcc 4.9.4 successfully? <Rutherther>c0co: since you seem to have got a corruption the first time, I wouldn't be able if this was another corruption. Did you try verifying if the data you wrote to the flash drive are the same as what is in the iso? <frankie>identity: let me try again, this time also specifying a password... <Rutherther>frankie: does it show an error when you try subscribing, or does it succeed, but you don't receive an e-mail to confirm it? <c0co>rutherther: might it be because of the drive/fs UUIDs in my system.scm being included in the iso? <Rutherther>c0co: probably not, that is replaced, if you mean the root fs under file-systems <efraim>adanska: I'll check. My main concern was that nothing in (gnu packages commencement) changes <adanska>efraim, thats okay. It hasn't been building since at least 3 months ago, I was just curious if the aim of your recent patches was to try and fix some builds. <efraim>It was mostly to make it less fragile to make changes. I'm not sure when it stopped building <frankie>Rutherther: it succeed but I do not receive any confirmation. <frankie>Rutherther: even setting a password and using another email I got the same result on info-guix <Rutherther>frankie: when did you first try to subscribe? especially lately I am not sure if the mailman is in a good shape so it can take some time <frankie>Rutherther: days ago and apparently it was up, not I see some missing responses from time to time <Rutherther>frankie: oh.. I thought you weren't subsribed at all. Those responses, are they directed to you? (are you in To/Cc header?) <efraim>TIL grub has a devicetree command <frankie>Rutherther: I think so, but even with an explicit password currently I'm resulting not subscribed when trying to login to change options. <dariqq>Rutherther: Is there anything to cross compile for python? shouldnt it be mostly system independant .py files? We would still need a way to set CC,CXX,etc in case of native extensions but a lot probably works without any changes. <Rutherther>dariqq: exactly, it's simple, but you cannot use --target on packages that depend on python packages because of it <Rutherther>so I don't really understand why the state is like that, it seems to me I might just be missing an obvious blocker somewhere... <Rutherther>I will probably try to align with people from the python team some other day and I would probably like to bring support to the build system for this, it's far from ideal, a lot of packages do depend on python packages <dariqq>my guess is that nobody had the need before <Rutherther>neither do I, but I am willing to help that situation :D <HexMachina>Hi all - I'm trying to "guix package -u" to update my system after a guix pull. I have a dependency on gtk+3.24.49 that is being built locally b/c there is no subsitute, but the check phase failed. I built manually with "guix build --without-tests=gtk+ gtk+" and it successfully built /gnu/store/HASH1-gtk+-3.24.49 but when I try to "guix package --without-tests=gtk+ -u" it still keeps trying to build a different derivation, <HexMachina>/gnu/store/HASH2-gtk+-3.24.29 which again fails the check phase <HexMachina>Is there a way to get "guix package -u" to use a gtk+ I built locally without tests? <HexMachina>I can post more about the specific gtk build error (failure in the gtk:reftest / reftest linear-gradient.ui test) but my real question is more generally how to get "guix package -u" to use a transformed package I built locally <HexMachina>when that package (e.g. gtk+) isn't explicitly in my profile but is a dependency of several others (e.g gimp, wireshark, etc) <dariqq>HexMachina: The i686 gtk+? There is a bug for for it guix/guix#2195. the without-tests won't help because it is for a graft <HexMachina>dariqq: no this would be 64-bit. I'm on a foregin distro, amd64 Ubuntu 18.04 <dariqq>do you use wine? because then youd depend on a 32bit gtk <HexMachina>And it's in my profile and one of the things I'm trying to upgrade. That is probably where the dependency comes from <dariqq>As a temporary workaround you could try using wine with --no-grafts. You probably dont want that for your entire profile though <HexMachina>I can `guix build --without-tests=gtk+ -s i686-linux gtk+` successfully but I don't know how to get `guix package -u wine` to use it <awth13>hi! So I set up the environment for working on Guix using `guix shell -CPW` and made some changes to a package definition and the package has been built successfully. Is there a convenient way to pull this package out of the container so I can test that it works in my actual environment? <Rutherther>awth13: just don't run a container shell, run 'only' a pure one <Tadhgmister>copy paste from the output of the terminal to another terminal not in a container? (and not use -C next time) <Tadhgmister>actually if the package files get interned to the store you could probably smuggle files out that way, like `guix build -e ((@ (guix gexp) local-file) <Rutherther>yeah, in case you didn't know this this already: the container shares your store, so whatever you build in it is built in your normal environment. So you can definitely just start it in another terminal <Tadhgmister>guix build -e '((@ (guix gexp) local-file) "./file_i_want")' would give you a path in the store that would exist outside the container I think <awth13>hm, `guix shell --pure` doesn't automatically pick up the build dependencies of Guix <ieure>awth13, I usually just copy the path (from the package build output) and run it in a local shell. <Rutherther>awth13: yes, you would need to add -m manifest.scm for whatever reason it doesn't imply that argument <ieure>awth13, If you drop the `-C' to your dev environment, you can also `./pre-inst-env guix shell updated-package-name' and run it normally. <awth13>ieure: the path doesn't exist outside of the container though <ieure>awth13, Don't build in a container then. <Tadhgmister>awth13 `guix build -e '((@ (guix gexp) local-file) "./file_i_want")'` will smuggle the file out of your current container to the store <Rutherther>ieure: I would still advise to use a pure shell otherwise you are risking picking up the system guix for example if you don't have everything compiled <awth13>Tadhgmister: that's interesting, thanks! I think I need the entire directory though <awth13>I think I like `--pure` the most <Tadhgmister>local-file has a #:recursive? #t option but I can't figure out how to get it to work as a one off in the terminal <FuncProgLinux>I see. I'm deciding what missing package on the MATE side I can contribute next. Thank you! <FuncProgLinux>futurile: just saw your username, thanks for those package transformation blog posts in your website! Those helped me a lot when doing my channel :) <futurile>FuncProgLinux: cool, always good to know what's useful - positive feedback gives me a lot of energy heh :-) <futurile>FuncProgLinux: you could potentially take that patch and redo it as a PR - check it works - update as necessary - it looks like it just got mixed <FuncProgLinux>futurile: I'll test that, I haven't left the comfort of the default gdm service. Last time I tried to use lightdm I got a duplicate xorg-service error I don't remember it well <Rutherther>either because you haven't removed gdm out of desktop-services, or you use set-xorg-configuration that adds gdm by default <futurile>if we had an FAQ - this would be in it heh heh <Rutherther>honestly I think it's unfortunate how set-xorg-configuration is named, it isn't clear it will bring in a login manager <ieure>Yes, I understand why it's like that, but IMO it's all backwards, and the DM and display server should be configured separately (with a dependency from dm->server). <FuncProgLinux>Rutherther: So far reading the docs I think I should move the one that comes from default inside the lightdm-service-configuration AFAIK. <Rutherther>or change the argument going to set-xorg-configuration from gdm to lightdm <FuncProgLinux>I only have (set-xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout))) it's the installer (March) default <FuncProgLinux>I can wait for this though :) I still need to get 5 official MATE packages upstreamed to Guix. So at least the desktop is complete in it's vanilla state. <dariqq>FuncProgLinux: add lightdm-service-type as second argument to set-xorg-configuration. It defaults to gdm for x86_64 or sddm else) <FuncProgLinux>dariqq: I'll save that and try it with my laptop today :) thank you for the info! <awth13>trying to commit a change in my fork of guix but Change-Id: is not inserted automatically, what could be the issue? <awth13>I have followed all the stops in 22.2 Building from Git and assumed this will be done automatically <identity>awth13: running ‘make’ should add a commit-msg hook to .git/hooks/ (or wherever it goes), not sure why it did not work for you; you can put it there yourself, it is in etc/git/commit-msg <awth13>does it insert it AFTER I have written the commit msg perhaps? <jhoch>Hi! I am a NixOS user who wants to try GNU Guix. I tried to set it up in a QEMU following the manual, but the manual and/or the image published on the Guix website seem to be out of date or broken. Does anyone know how to get this to work? <jhoch>I tried this: https://guix.gnu.org/manual/en/html_node/Getting-Started.html and then I ran `guix pull` (which ran for hours, but ok). When I then tried `sudo guix system reconfigre /etc/config.scm` that didn't work, since the path seems to be different (I think /run/current-system/configuration.scm but ok). I could work around that by copying the file somewhere else, but then I got a bunch of error messages culminating in "Git error: <jhoch>Which I found kind of concerning since this is basically an unmodified image published on the Guix website with 0 modifications by me. <awth13>how do I authenticate after signing a commit? it is obviously missing my key <identity>jhoch: /run/current-system/configuration.scm is for the configuration with which the current system was created; you want /etc/guix/config.scm instead, though i would expect it not to matter <jhoch>ls /etc/guix/config.scm: No such file or directory <identity>you are also probably using a really old image (1.4.0 is a few years old), unless you downloaded latest <jhoch>No, even with sudo that file does not exist. Perhaps I need to find a newer QEMU image. <ieure>1.4.0 is both old and also the latest release. <Rutherther>it's definitely fine to do what you did - copy configuration.scm ot of /run/current-system and use that. I don't think the qemu image has /etc/config.scm nor /etc/guix/config.scm by default <FuncProgLinux>I did get confused as well the first time I installed guix. I thought it was a rolling-release distribution, but with it stepping out of the common distros I don't know if such labels fit in here <Rutherther>what are the full errors in regards to that unsupported url protocol? <jhoch>Let me see if I can copy and paste that from the VM. <ieure>It is rolling release, which is why the versioned release is so old. :) <awth13>do I even need to authenticate my commits to a fork? <jhoch>guest@gnu ~$ guix system reconfigure /run/current-system/configuration.scm <jhoch>guix system: warning: cannot determine provenance for current system <jhoch>Updating channel 'guix' from Git repository at '/home/ludo/src/guix/+version-1.4.0/'... <jhoch>SWH: object swh:1:rev:989a3916dc8967bcb7275f10452f89bc6c3389cc could not be fetched from the vault <jhoch>guix system: warning: revision 989a3916dc8967bcb7275f10452f89bc6c3389cc of /home/ludo/src/guix/+version-1.4.0/ could not be fetched from Software Heritage <jhoch> 1382:11 19 (map/accumulate-builds #<store-connection 256.99 7f43f…> …) <jhoch> 1300:8 18 (call-with-build-handler #<procedure 7f43f3fe3870 at g…> …) <FuncProgLinux>awth13: If you wish to use your forked guix channel as your main, I think so. <jhoch> 2170:25 17 (run-with-store #<store-connection 256.99 7f43f3f86cd0> …) <Rutherther>awth13: you cannot really authenticate your commits, someone who is authenticated already would have to authorize you, even in a fork <Rutherther>jhoch: please don't send multiple lines here, use paste site <jhoch>In guix/build-system/channel.scm: <les>use a pastebin of some sort in the future please. <jhoch> 2042:38 8 (_ #<store-connection 256.99 7f43f3f86cd0>) <jhoch> 48:26 6 (fold2 #<procedure 7f43f3a3e300 at guix/channels.scm:5…> …) <jhoch> 542:29 5 (_ #<<channel> name: guix url: "/home/ludo/src/guix/+v…> …) <awth13>I am just trying to open a PR on the Guix codeberg repo. I forked the repo and I cannot push to it <jhoch> 413:17 4 (latest-channel-instance #<store-connection 256.99 7f4…> …) <jhoch> 475:29 3 (update-cached-checkout "/home/ludo/src/guix/+version-…" …) <jhoch> 405:19 2 (_ git-error #<<git-error> code: -1 message: "unsupport…>) <jhoch> 1685:16 1 (raise-exception _ #:continuable? _) <jhoch> 1685:16 0 (raise-exception _ #:continuable? _) <jhoch>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <jhoch>Git error: unsupported URL protocol <jhoch>Yeah sorry not a regular IRC user... <Rutherther>I see, this is a bug that's present in 1.4.0 that ludo's home ended up in the repository, you should first pull from the correct url, ie. "guix pull --url=https://codeberg.org/guix/guix.git", and only then do reconfigure. After pulling / if you did already, don't forget to source the profile in ~/.config/guix/current/etc/profile, as the guix pull output should tell you via a hint (or relog, that will source it) <awth13>Rutherther: I am trying to open a PR in the Guix codeberg repo. I forked the repo and I <luca>Do forks require GPG signing? That seems wrong <Rutherther>to verify the guix pull succeeded, run "guix describe" and see if you see the url instead of /home/ludo... <awth13>FuncProgLinux: there is no error, it tries to authenticate when I push and fails <Rutherther>awth13: are you sure you're pushing to your fork? The pre-push hook should be effective only when you push to codeberg.org/guix/... / git.gnu.org etc. <jhoch>Thanks Rutherther, I was thinking something along that line. Weird that this has survived there for years but oh well, will pull that now. This might take a few hours judging from how it went yesterday, so I will try your suggestions later... <awth13>I guess I can disable the pre-push fork <awth13>Rutherther: yeah my remote is set to my fork <Rutherther>jhoch: it has survived for years because the argument is that artifacts cannot be changed after they were released. This will not happen in the next release as the code was adapted to prevent this potential user error <Rutherther>awth13: and your pre-push hook has those checks for gnu.org / codeberg.org/guix urls? Because if so, it really seems to me like you're pushing to the main repo and not to fork <awth13>that is interesting, why do I have a wrong pre-push? <awth13>yeah but I pulled and built today <Rutherther>and "make .git/hooks/pre-push" tells you it's up to date? <Rutherther>I guess the issue could be that something touched your .git/hooks/pre-push after the last update to it in the repository <Rutherther>so removing it and making it again should resolve that issue <awth13>but rm and make did solve it, thanks Rutherther <ieure>jhoch, You can remove the mentions of nss-certs in your config, they became required after 1.4.0. <Rutherther>jhoch: hehe, nss-certs has been moved recently, but yeah, you can just remove it, they are already added to system by default for some time now <Rutherther>you can even see the hint telling you the new module it's been moved to <jhoch>yeah... I removed it, now it seems to be building. Thanks! I guess this will take a while. <c0co>using guix system vm, what's the correct way to remove the `*-run-vm.sh*` files from the store when you're done with them? <FuncProgLinux>Do we support building C# libraries? Are "mirror://" url's better than git forge ones? <Rutherther>FuncProgLinux: the mirror urls can go to multiple mirrors, so they are better in that regard. On the other hand when someone makes a release to tarball/zip they usually do not just copy the git checkout, so because of those differences git forge could be better <ArchaicLord>Hi. I've installed guix on pop os with apt. Installed emacs 27 but I wanted higher version. I've ran guix pull to update but its stuck. Do i need to explicitly set a URL or should it pull from a default channel automatically? <les>ci.guix.gnu.org seems deeply upset today. that may be related. <Rutherther>FuncProgLinux: there isn't a build system for C#, but there is mono packaged, so it should be possible to package them. There is at least one application packaged using mono - keepass. <ieure>ArchaicLord, Where is it stuck? Can you put the output in a pastebin? <jhoch>Do I need to run `guix system reconfigure` with sudo? I got a permission denied error, however the manual seems to run everything as the regular user. <Rutherther>jhoch: definitely, it's changing the system, regular users cannot change the system, that would be a privilege escalation <jhoch>yeah makes sense to me. Strange that the manual does not mention this. <FuncProgLinux>Rutherther: I see. I wanted to package gtk-sharp as it's needed for the not-so-newer ayatana-indicators. But I found like 4 "upstream" url's. One from gnome, one from mono (archived), one from a GitHub Organization and one from a developer repo lol <Rutherther>ArchaicLord: that means it's stuck pulling guix repo. Since you are using 1.4.0, it's pulling from savannah and savannah is not doing well lately. Use "guix pull --url=https://codeberg.org/guix/guix". After you pull like that first time (and make sure to use the new guix), correct url will be used on "guix pull" without url argument <ArchaicLord>ah ok thank. I am using 1.3.0 But guess that is because ubuntu repos. Ill do as you suggest you thank you!! <Tadhgmister>can the bootloader's installer function get access to the boot parameters / menu-entry data or is it totally expected that the configuration file procedure deals with that and the installer should not depend on that info at all? <Rutherther>Tadhgmister: since it's mainly for grub it is expected to not have that information. But you can hack around it, by putting that info to the config file and reading from it. Well that is until you want to build an image out of it when you might need to also hack around the partition builder function to call the config function first and only then the installer :) <Tadhgmister>hmm... I just managed to boot directly to the linux kernel by making a boot entry with efibootmgr and would like to figure out the best "guix-y" way to manage that in guile <Tadhgmister>but my main hope is to inherit the grub-efi-removable-bootloader, not touch it's config file at all, when installing also run the removable installer, then also copy over the kernel and initrd and make a boot entry. if the only way I can get at the parameters is by making use of the config file that workflow doesn't really work <Rutherther>yup, the installer doesn't get that info, you need to make yourself a way to read it (or read it from the same source as reconfigure does /var/guix/profiles, though I am not sure if the generation you are currently reconfiguring to is going to be included at that point) <Tadhgmister>why is the bootloader designed to have multiple devices? what case do you want to install the same bootloader in multiple places? <c0co>Another message from me, another teething pain. current config uses networkmanager, and I can't figure out how to declaratively specify default DNS Nameservers to use <ieure>c0co, I don't think you can declaratively configure connections for network-manager, only the NM service itself. <Tadhgmister>wouldn't you specify (dns 'none) and then write the resolv.conf based on the data you want? <Tadhgmister>where the resolv.conf would be specified in the etc-service-type or what ever it is called to put more files in /etc <ieure>Tadhgmister, No. network-manager handles that stuff for you, because the correct values to put in them depend on what connection you're using. <c0co>the specific problem I'm having is using `guix system vm`, any VMs I spawn this way can only resolve domains in the host's known hosts <c0co>so I wanted to configure their DNS resolvers in the configs used for the VMs <jhoch>@Rutherther I was successful in so far that the build completed, and I was prompted to reboot. However, I could not reboot successfully since the (virtual) hard disk is not apparently not working anymore. I think the same happened to me on one of my first attempts on Saturday... https://pasteboard.co/sN4zmREIy6HY.png I don't have much hope you will be able to help me with this... must be some weird issue with QEMU? I guess I will <jhoch>have to install from scratch. <Tadhgmister>jhoch does your system config say that the filesystem for /dev/vda1 has `(type "vfat")`? <jhoch>Actually now I remember - the original image has /dev/vda1 as a boot partition as vfat IIRC and /dev/vda2 is /, but now for some reason the syste tries to mount /dev/vda1 as ext. Quite strange. <jhoch>I suspect the configuration.scm is differently set up than the actual drives in the image? <Rutherther>jhoch: ohhh... this is problem with the /run/current-system/configuration.scm, I forgot about this as it's been long I tried to use this. The thing is that when you make guix system image, the root partition and everything is replaced, but the configuration written to /run/current-system/configuration.scm is the original one and there is probably a mistake in it <jhoch>Apparently not a lot of people use the QEMU image lol... I guess I can boot the old configuration and try to forward fix from there. <jhoch>Ok I will try that tomorrow. Thanks for your help and good evening. <c0co>really not sure what to do with this networking issue. If i can't configure NS via networkmanager, what else can i do? statically defined networking isn't going to work for my usecase <ieure>c0co, Why doesn't static work for a VM image? <c0co>ieure: I guess i spoke too soon. I wrongly assumed that qemu wouldn't handle two VMs having the same ip, but just tested and it works fine. Thanks <c0co>yeah I had assumed qemu would emulate a network layer shared by VMs, I was (thankfully) wrong <Rutherther>you would have to be explicit about that to make a shared network <ieure>Yes, it supports both isolated and host networking, depends on the VM configuration. <c0co>yeah I thought Qemu defaulted to bridging everything together (i'm very glad it doesn't) <ieure>I don't think any VM software I've used defaults to that. <Tadhgmister>is it unsafe to set gnu.system=/var/guix/profiles/system? <Tadhgmister>it means /run/current-system points to /var/guix/profiles/system which seems fragile but I'm not sure if that would be totally breaking <eikcaz>the worst has come to pass. After updating my machine, grub fails to boot ANY system generation <eikcaz>I may have messed up my file-system OS field on the most recent reconfigure. could this cause old generations to fail as well? 