IRC channel logs
2025-03-15.log
back to list of logs
<lactose>hello, is the guix channel on savannah down? <wakyct>I was able to guix pull --news lactose, don't know if that's helpful <lactose>i ended up switching my channel to the codeberg mirror, savannah would just time out <ulfvonbelow>is there a way to have a pkg-config file specify a search path for other pkg-config files, sort of like rpath but for .pc files? <ulfvonbelow>currently it seems that libarchive can't be used as a dependency because it has Requires.private: libcrypto <ulfvonbelow>I'm most likely only running into this because I'm using an ungrafting transformation <meati>I really wish there was a way to do a 'guix reconfigure' without requiring network access or having all configured channels up and not broken. It's the one thing stopping me from moving more of my configuration into guix-space <hako>You can use --no-substitutes if you're sure all derivations requiring network were already in store. <ulfvonbelow>ideally there would be a saved profile for the guix used to reconfigure, so that you can use that to make modifications without bringing in package updates. <ulfvonbelow>my understanding is that guix-service-type adds a guix to /run/current-system/profile, but installing with it will downgrade your system to an older guix <luca>Pretty sure it isn't. Just grepping for that URL should return a homepage, but nothing <apteryx>What should the "vendor" for GNU Guix be in the osinfo-db files? It's currently 'Guix Contributors'. <apteryx>Perhaps 'GNU Guix Project' would be better? <Rutherther>janneke: yeah the claims in the commit deleting it seem outright false to me and I have given it only a few seconds to check. But from what I see the deletion was reverted like 30 minutes afterwards. So all should be fine <janneke>Rutherther: i was [over-]reacting without looking yesterday <janneke>ACTION is preparing another email with more explanation <janneke>in short, the bug was filed july 2024, long before the resurrection of guile-emacs in december <janneke>so all was done in good faith (of course), just some vital information was lacking <tae>I don't fully understand propagation of package versions. Are all packages that you get via guix pull, i.e. current versions, compatible with each other, or not? <tae>For example, here: https://paste.debian.net/plain/1363248, this doesn't mean that python-numpy and python-xgboost are not compatible on the latest revision of Guix? Or does it? Or does it mean somewhere I locked an incompatible version? <Rutherther>tae: there doesn't have to be 100% compataibility. But most packages are compatible. In this particular case it is indeed an uncompatibility between packages that are in guix. But guix doesn't use python-numpy@2.2.2 for any other package as dependency. So why do you have it? Did you maybe do guix install python-numpy at one point? If so, just unintall it and you are fine to go. It will get installed as propagation from the other packages. If you... <Rutherther>... really wanted to explicitly install it, you will need to install the python numpy @1 version. Though note that after at some point guix upgrades numpy to 2, you will get an error again, because of pinned package <tae>Rutherther: Which version of numpy is the one I should use? <Rutherther>the 1.x is the only one used as dependency of other packages, so that one if you want to be able to use pythran, scipy, xgboost <tae>Rutherther: Thanks. I see. I am not sure why I have 2.x, I have experimented in the past so could be anything. Let me check and see. <tae>So I can leave out python-numpy, given that the others will install it anyway? <tae>Rutherther: Thanks, that didn't occur to me :) <erik``>As part of packaging numen voice, I need to package multiple go packages, subdirectory of the same repository. What would be the correct way to declare these multiple packages using the same source? When trying to create a procedure that generates packages for the different subdirectories, I run into issues in the unpack phase. I think this is because there are internal dependencies between these subdirectories, causing the unpack <erik``>phase to attempt to unpack into an already existing directory from the inputs. <Rutherther>erik``: so do I understand correctly you're making multiple packages, each with same source, but different import path? it's strange to me that you would get an error like that, bvecause what is copied to the guix store is only what is under import-path, so there shouldn't really be clashes <erik``>Yes, correct. I am guessing on the cause of the issue. The error I get is `error: in phase 'unpack': uncaught exception: system-error "copy-file" "~A" ("Permission denied") (13)`, and I am not sure how I would test my hypothesis or if my approach is correct to begin with. <Rutherther>s/whole error/whole log including stacktrace etc <erik``>Yes, give me a sec and I'll upload package+invocation+log <Rutherther>erik``: for 'verifying the hypothesis' you could use --keep-failed flag on guix build and observe the directory created, to see what would be the reason for not being able to write there. I wouldn't be surprised if it was just missing write permission. On the other hand the unpack phase should be unpacking to $GOPATH/src, while the inputs are unpacked to $GOPATH itself, so it's strange you would be affected by the inputs here <erik``>Where do I best upload the logs? debian paste disallows >150kB files <Rutherther>erik``: I don't know. But probably like last 1000 lines are fine <Rutherther>erik``: btw if it really turns out to be the hypothesis you said, you have at least two options: 1. set install-source? to #f in arguments, 2. add phase before unpack phase that will remove the folder and let it unpack it <Rutherther>erik``: okay I am pretty sure it is what you described. I haven't realized the install source will go to src/ folder in the output. So indeed it's all going to be unpacked to the same place as from the inputs <moksh>how to test your sytem before runnin `guix system reconfigure`? <moksh>it didn't showed any error nor did it take me to [env] shell <Rutherther>moksh: it doesn't do that, it just gives you script to start the container <moksh>I should run the command again then <erik``>Rutherther: Okay, then I will try your proposed options. Thank you for taking a look. <moksh>Rutherther: I am in the shell <moksh>it gives segmentation fault, <moksh>the reason I want to test is, I added the tor service to my system config, wanted ot make sure it worked well <Rutherther>some stuff just can't work right in container, so for some stuff you can use the vm option, that supports everything even stuff like gui etc.. sudo is one of them <moksh>I see it can't run /boot/efi, and device mapping <Rutherther>(or to be more specific it is pam that is causing the issues with sudo, so even stuff like switching user is problematic) <moksh>seems because, I am in container <Rutherther>moksh: right, the container has its own filesystem, it doesn't mount your actual disks <Rutherther>you cannot mount your full disk, you're using it, it would clash <Rutherther>ie. stuff in /etc/ would get replaced by the newer generation, so it would no longer be 'testing' it, it would be actually partially activating the system generation <moksh>is your guix config beginner friendly <Rutherther>if you really need some parts of fs to test something, like service creating logs, files etc., just --share / --expose them to the container <moksh>getting git erro 502 when running configure <moksh>`sudo guix reconfigure <file> <Rutherther>moksh: can you send the output of guix system reconfigure so it's clear at what part of the process this is happening? <moksh>but there is just blank screen, in the view menu there is vga, compat_monitor0, serial0, parallel0 <moksh>how do I actually get a screen <hako>untrusem: Is your file system encrypted? (Not sure why but there's no display on a kexec reboot. You'll need to input password without display.) <old>hako: interresting. I had the same issue where kexec just leave me with a blank screen <old>and my fs is indeed encrypted <ieure>Working on some patch review, if anyone has emacs or web browser stuff that's gotten lost, ping me and I'll take a look. Have been working through the backlog of that stuff for a while, though, so I think it's in pretty good shape. <ieure>Happy to look at other stuff as well! <janneke>ieure: thanks for reviewing and pushing my patches! <ieure>janneke, You're very welcome! <jean0t>I am a guy that is interested in guix <jean0t>Ive been reading parts of the docs these last days and I am interested in contributing to the project <jean0t>my experience with lisp is related to common lisp <jean0t>but I got the scheme guide and I am reading it slowly <jean0t>how is the experience of developing apps/scripts with guile? <jean0t>by what I saw, you arent supposed to install dev libraries or dependencies for them, only the apps itself <futurile>jean0t: I'm not sure what you mean? For Guix itself we package apps, configure services and have things like Guix Home - these all involve guile modules <futurile>jean0t: is there a specific reference you're looking at? <janneke>jean0t: fwiw, i dropped python for guile scheme some 10y ago and have bees loving it <jean0t>I was thinking something like third party modules in python <janneke>there's many guile-xyz library packages (guile-fibers, guile-git, guile-gnupg, guile-gcrypt, guile-ssh, ...) <jean0t>I dont use javascript, but node also is a tool to install packages and all <jean0t>if you ever need third party code, guile can take care of it? <futurile>jean0t: one perspective would be that Guix is the 'package manager' for Guile projects ;-) - I think there are other options - but as Guix uses Guile it's pretty natural to use it <janneke>there's the ffi (foreign function interface), there are some guile-ffi packages <janneke>ACTION is not much of a 3rd party code person tho <jean0t>I prefer to write myself but some code like tkinter in python is third party <futurile>jean0t: there's some good ways you can specify a list of packages/modules that you want to use - and load them from guix <janneke>jean0t: as far as graphical toolkits go we have guile-gi and guile-golf, afaik <janneke>there's most probably a tk interface somewhere out there <oluminol>For the sixth time, please fix this god damn distribution it's already hard asf to debug one's own f-ups >:L <jean0t>after I see it pinging google servers <Rutherther>so there is an issue with xfce that can be even on Arch because it has a fix on archwiki for people, but it's guix system distribution fault and it should somehow be 'fixed' okay makes a lot of sense xD <janneke>ACTION would love for guix to be bug-free! <janneke>and we could certainly need some help esp. from people who "get" what's important and nice about guix <rekado>I'm a bit unnerved by the fact that "guix copy $OUTPUT_OF_GUIX_HOME_BUILD" does not in fact copy all the things that are required by "guix home build" on the target machine. <Rutherther>jean0t: not saying that it's good that golang is going through google proxy, but it's fairly easy to turn off, so I don't really see it as a reason for 'dropping off' <rekado>I have used "guix copy" to copy Guix itself, and the used "guix copy" again to copy the output of "guix home build". Then on the target I've run the very same Guix on the very same home configuration ... only to see it attempt to download and build almost all the things. <rekado>these are all different derivations. <janneke>rekado: i almost don't dare to ask, but it's got nothing to do with grafts? <rekado>I thought so, too, but even with "--no-grafts" the target will download/build almost everything. <Rutherther>rekado: and you're 100% sure you're using the same guix instance, yes? <rekado>perhaps it's the other way around and I should copy over the "--no-grafts" output to the target. <janneke>i had something like that once (not guix-home specific) and it turned out that my store was corrupt <janneke>the drv of "hello" differed on both machines, iirc <rekado>(according to "guix describe" and because the store item of the guix pull profile has the same name) <Rutherther>rekado: yes, exactly, you need to copy the --no-grafts, because only grafted derivations will be copied over if you don't do that. The target machine's guix has no way of knowing the derivations that lead to creation of the grafted versions <rekado>Rutherther: you're probably right (I'm trying this right now), but this is a pretty unsatisfactory state of affairs. On the target "guix home" knows that it should eventually build the graft derivations, and it also knows that it already has the results of those derivations. <constfun>hello all. i would like to drop into the build environment for a package AFTER the build succeeds, but before the install phase is executed. is that possible? i can achieve the desired effect by intentionally "breaking" the build as the last step in the build phase and using --keep-failed, however this is not very ergonomic for packages that I am <constfun>not actively developing. another way to frame the problem is that I would like to intentionally "break" a build (so i can use --keep-failed) for a working package, but i would like to do so on the command line. i would appreciate any ideas, this is a common use case for me when debugging existing package that may not be installing properly, for <constfun>example when not all needed resources are copied during an existing install phase... <jean0t>I started it since the morning and it is still running <jean0t>sometimes I thought it had crashed <rekado>jean0t: it should not take so long. Is it building something? <ieure>Rutherther, I think the telemetry is opt-in, but that only happened after sustained outrage from the community over the initial opt-out proposal. <Rutherther>constfun: there is unfortunately no other way than what you described. If you are finding yourself in this situation often it should be fairly easy to just make a procedure that will add this phase to arbitrary package you want <rekado>jean0t: do you get binary substitutes from ci.guix.gnu.org and/or bordeaux? <ieure>constfun, Add a build phase to the package that fails just before the install phase. (/ 1 0) is an easy way to break the build. <Rutherther>constfun: should be fine even with packages you're not making, modifying an existing package is possible, you just inherit from it and use substitute-keyword-arguments to change the phases <ieure>jean0t, Did you install the 1.4.0 release? <constfun>thank you for the ideas, i was hoping for some --expression magic that would do this for me, i'm not skilled in guile/guix enough to do that yet <ieure>jean0t, That is years old at this point, so the first pull will be very slow. <ieure>jean0t, Guix updating is much slower than other Linux distros, in my experience. But the first one is brutal. <ieure>(First one from 1.4.0 -> current) <ieure>jean0t, Guix is a rolling distro. <jean0t>it was the last one in the website <ieure>1.4.0 is the most recent release. <jean0t>I thought guix only shipped outdated software because of that <jean0t>because in the version of the binary 1.4 there ships a gnome 42 <ieure>jean0t, It's a known issue that the last release is old. Work is underway to do a new release. <dariqq>is anyone familiar with guile-1.8 (testing how my project works with older guile versions? When I build my project from a guix shell everything is fine but when I try to let guix do it the snarfer produces an incomplete .x file <jean0t>midori still in version 9 is due to its status of being owned by a company or havent any patch sent to update? because I can do it <ieure>jean0t, I don't know why midori is outdated, as long as the license hasn't changed and it doesn't have non-free dependencies, patches are welcome. <ieure>jean0t, Probably a good idea to search debbugs / guix-devel to see if there's been some effort to update it or patches you can use as a starting point. <constfun>Rutherther: this is hugely helpful, thank you! <jean0t>something happen yesterday with guix? it wasnt acessible <ieure>jean0t, What wasn't accessible? <jean0t>ieure: the git repository of guix <ieure>jean0t, Yes, Savannah had an outage yesterday. Guix is hosted there, but it's not run by Guix. <ieure>jean0t, It looks like 9.0 is the most recent stable release of Midori, even though it's ~5 years old. <ieure>jean0t, If you want to package an unrelease snapshot, that should be a new package, midori-next. <csantosb>janneke: thanks for packaging guile-emacs ! I just noticed we use the lyrra/guilemacs repo, instead of guile-emacs/guile-emacs at codeberg.org, is that correct ? <ieure>erik````, Please fix your client. <csantosb>Good news, stage0-posix 1.8.0 release is out <csantosb>"It bootstraps all these from a single 256 byte seed", 357 byte binary seed right here ? <jean0t>damn the package is installing 5Kb/s <csantosb>jean0t: do you know that one ? `guix weather midori` <ieure>jean0t, The substitute servers are in the EU, there's one in North America you can use which is faster if you're also there... except I see it's 502ing, sigh. <janneke>csantosb: yeah, istm that larry is doing most of the work currently <meati>What's the package for glibc++? <meati>I'm trying to get a binary to run and the latest error is '.../libstdc++.so.6: version `GLIBCXX_3.4.30' not found' <Rutherther>meati: what's glibc++? you mean libstdc++? it's in gcc:lib <meati>Rutherther: I'm not sure myself, that's just what the error mentions. There's no glibc@3, it seems, fwiw. <Rutherther>meati: that glibcxx 3.4.30 doesn't map to glibc version 3. That's api version. Different things <lilyp>anyone know how one can debug cyclic store references?