IRC channel logs
2026-01-05.log
back to list of logs
<gabber>cow_2001: never used it but i guess this goes in the general direction you're looking for <umanwizard>If I created a profile (e.g. with guix package -p -i foo), what's the correct way to delete it such that it will no longer be a gc root? <Rutherther>umanwizard: yes, but make sure to delete the "-x-link", that is the gc root <Rutherther>the guix-daemon remembers where gc roots are put and checks them, if they do not exist, they are no longer gc roots <umanwizard>Is there a way to create a new GC root and inform the daemon about it? (Other than with `guix package') <Rutherther>yes, definitely, there is also guix build -r, guix shell -r and you could also just register it on your own using the add-indirect-root procedure from (guix store) <PotentialUser-74>I'm starting out with Rust programming. I'm currently in the business logic engineering stage. I'm looking to work on a minimalist OS to implement namespaces and run software in Rust. <PotentialUser-74>I don't think I know how to use this IRC chat system. Can someone guide me? <identity>PotentialUser-74: well, Guix has QEMU and a Rust tool-chain, so i would expect it to be suitable <identity>and, IRC stands for Internet Relay Chat, so ‹IRC chat› is ‹Internet Relay Chat chat› <PotentialUser-74>Thanks for replying. QEMU is an emulator; I'm trying to work at the bare level, interacting with the Linux kernel. <identity>…why did you put my nick in quotation marks? <PotentialUser-74>I don't know how to use IRC; this is the first time I've used this communication method. <PotentialUser-74>I hope that putting your nickname in quotation marks doesn't mean anything bad. If it does, I apologize. <identity>PotentialUser-74: on IRC, when you are answering to somebody, you just prefix the message with their name and a semicolon, like this message does <identity>putting a nickname in quotation marks is just silly, not bad <mroh>PotentialUser-74: If you play with namespaces, it might make sense to test them outside your host kernel, so qemu might help. <identity>sorry, not a semicolon, just a colon, though that is also fine. some people use a comma <PotentialUser-74>What I intend is for Rust to run minimally on an operating system where namespaces can be applied without any major tools other than coretools. <ieure>Ola, bom dia. I am visiting Lisbon this week. <efraim>isc-dhcp depends on debianutils for the run-parts script, which in turn depends on po4a, and I think is the only reason po4a is needed for a minimal system <efraim>building debianutils without po4a removes 85% of the nodes from the guix-graph of isc-dhcp <yelninei>efraim: There is also a po4a-minimal that is used for the guix package <efraim>yelninei: thanks, I'll try that too then <efraim>yelninei: I like that solution better <cbaines>efraim, I think there's an issue with default-guile-json in (guix build-system cargo), should it be cargo-guile-json? <cbaines>efraim, you can reproduce the error by attempting to cross build something rust related, e.g. guix build -d --target=aarch64-linux-gnu zrythm <efraim>cbaines: `grep guile-json guix/build-system/*scm` looks like a poor copy-paste job from one of the other build systems <efraim>s/default-guile-json/cargo-guile-json/ switches the error to waf does not support cross builds <cbaines>that sounds good, I just picked zrythm as it's the first error the data service comes across <efraim>at least it's only in cargo-cross-build, we can toss the fix into master <efraim>do you want to do the honors? since you found it <Rutherther>cbaines: I have also seen that, but even after fixing it to default-guile-json, I was unable to cross compile anything, so I just gave up <Rutherther>I suppose the recent changes to the build system have broken cross compilation <cbaines>I'm not sure its a very recent change, but I think the fix in this case was to rename it to cargo-guile-json, which is defined in the module <yelninei>efraim: yeah I dont think you gain anything from completely removing po4a as po4a-minimal is already required for guix and mostly just some perl things <efraim>try zoxide, it's a fairly simple rust package. before it errors, with the change it builds <Rutherther>cbaines: yes, that fixes the initial issue, but what I am saying is that there are more issues <cbaines>you just missed the exciting discussion of cross derivations with the cargo build system... <efraim>After deciding I don't want to build full po4a for isc-dhcp I'm adjusting the linter for USE_THE_MINIMAL_VERSION!! checker and deciding if emacs and python/python-wrapper should also be in the list <efraim>'lint-hidden-non-minimal-package is long <civodul>efraim, apteryx: Rutherther mentioned on the mailing list that they’re waiting on you regarding ftp.gnu.org upload access; relaying the message in case you missed it :-) <nmeum>does `guix size` also take the size of propagated dependencies into account? <nmeum>hm. either i am holiding it wrong or it does not account for them. for example: in the `guix size python-scikit-misc` output python-numpydoc does not show up even though it is a direct propagated dependency <cbaines>nmeum, propagated inputs are a thing, propagated dependencies aren't <nmeum>yes, I meant propgated inputs <cbaines>this is important here because a package can have a propagated input, but the output can contain no references to it <cbaines>I think guix size is looking at outputs and "requisites" (see guix gc), so it's quite possible it doesn't include the propagated input <cbaines>since it might not actually be required to have the output in the store <cbaines>when guix comes to include it in a profile though, that's when the propagated input will be pulled in <nmeum>yes, that's probably why it isn't included in the `guix size` output. makes sense <nmeum>but that's a bit unfourtunate as `guix size` will not report the size of the entire closure then <cbaines>as far as guix size is concerned, propagated inputs aren't in the closure unless they're also referenced by the package output <nmeum>it would be good to have some way to determine the size including the propagated inputs though <nmeum>I just ran into this while building a docker container using `guix pack`. somehow my container ended up being 4 GiB in size, looking at the `guix size` I didn't see anything that would cause that. until I discoverd that python-scikit-misc pulls in texlive-bin via its propagated-input on python-numpydoc <cbaines>guix size could probably be improved to allow for this <Rutherther>in the meantime you can use guix size $(guix build --expression="((@ (guix profiles) profile) (content ((@ (gnu packages) specifications->manifest) (list "python-scikit-misc"))))") <nmeum>Rutherther: oh yea, that's a good workaround. thanks! <nmeum>I think I will open a codeberg issue for this, an option which forces `guix size` to include propagated inputs would be very useful. i will also sends some patches to move python-numpydoc from propagated-inputs to native-inputs (it's a sphinx package only needed for documentation generation and shouldn't be propagated) <jacklayton>Hello, I'm new into guix coming from gentoo. I need to use remote desktop into a workstation where I installed guix. I used x2go and xpra in the past. X2go server doesn't seem to be available in guix. I've tried xpra but it appears to be broken ("cannot execute: required file not found"). I tested two versions available in guix channel. Any help would be appreciated. <identity>jacklayton: i would expect VNC to work, or even RDP <identity>it seems you are on X11, so ssh -X should also work <yelninei>hmm a cross compiled guile 3.0.11 is completely unusable with wrong settings for word size (and endianness?) <efraim>I guess I should try again building it on ppc, and hopefully I won't lose power again before it finishes <jacklayton>identity: yeah, I think VNC is the way to go. RDP and ssh -X can be problematic in terms of latency in case you need access outside your local network. (I'll dig into xpra error. Maybe it's a simple issue with the wrapper) <yelninei>jacklayton: the shebang for .xpra-real looks very wrong with only "#!python" , this looks like an issue with the package <chipb>jacklayton: for xpra, there’s probably a client-side option to specify the executable to run on the remote host which may get it working for you. <yelninei>is 32bit ppc the only big endian target we have? <chipb>yelninei: I can’t check the source at the moment, but I expect that should not matter if the wrapper is specifying the interpreter. <Rutherther>yelninei: note that there were some issues with wrong shebangs on python-build-system packages after python updates <Rutherther>if xpra is python-build-system package, it should be moved to pyproject-build-system and it could fix the shebang <jacklayton>yelninei: my guess was in that line too. As I said I'm new in guix. I've trying with difference shebangs lines but I need to dig into how to guix manage the python thing.. <yelninei>i feel like bootstrapping guile 3.0.11 is even slower than 3.0.9, after 1h it is still in stage0 compiling srfis <ekaitz>people, how do you deal with default applications? like: i have two browsers, i want one specific browser to run by default <Rutherther>I think we should make some kind of a checker for deletion of modules to see if there are no usages of that module and put that to pre-push hook. It's been multiple times in the past few months where Guix got broken due to a removal of a module that is still referenced somewhere <janneke>ACTION just pastes the url in the browser they want <cbaines>Rutherther, I don't think deleting modules is special, there's lots of other changes that cause breakages as well <cbaines>I think Cuirass doesn't test much, but I think even Cuirass should be able to detect problems with removing modules <Rutherther>cbaines: I think they're special, for two reasons: 1. if you do not use pure shell/container, make will succeed even if you do clean-go prior to the run, 2. you do have to manually remove the .go file of the removed module, again, otherwise make will succeed <cbaines>I mentioned Cuirass because that's what's testing Pull Requests currently <cbaines>and I think there's much more scope for doing testing against Pull Requests than there is using Git hooks <cbaines>I frequently end up fighting the Git hooks we already have, often when I'm trying to fix existing problems <Rutherther>I think it's quite easy to get around the hooks when you really want to, ie. "git config core.hooksPath /dev/null". While in regular usage I think they're saving us quite some trouble ie. with the verification of authentication & news entry verification that in turn does run make that compiles all scm files <Rutherther>so to me personally I don't really see having to fight them as a compelling argument, since it's so easy to get around them. While on the other hand maybe we would save those couple of times a year when Guix is broken due to a removed module that still has references somewhere. I wouldn't consider adding that to a hook if it wasn't a problem that actually does occur in Guix <cbaines>haha, case in point, I tried to push a fix for the idris removal, but the hook failed and I didn't notice it hadn't been pushed <cbaines>I hadn't updated my local keyring branch <yelninei>ouch: phase `build' succeeded after 9643.2 seconds <Rutherther>cbaines: hm, have you considered setting the branch authenticate checks to origin/keyring? <cbaines>I haven't, I'm not sure it's configurable with the default hook <Rutherther>cbaines: it is, it uses what you have in your ~/.git/config and that is in turn determined by what you initial guix git authenticate invocation has been to configure it <cbaines>ah, I think I just have keyring = keyring in the repository .git/config <Rutherther>yeah, it's the default when you do guix git authenticate <commit> <signer>. Maybe it would be worth it changing the default <FuncProgLinux>Is it possible to "debug" further a GTK program not finding Guix paths? <FuncProgLinux>I think I patched something wrong. Or I missed to upload more fixes (?) <ekaitz>FuncProgLinux: i have had success just executing programs in the command line and looking at the errors or using strace <FuncProgLinux>But once upstreamed I removed changes from my channel and used the upstreamed solution and it doesn't work which is kinda weird. <FuncProgLinux>what's even stranger is that, you CAN force it to work by running: caja -q && CAJA_DEBUG=y CAJA_EXTENSION_DIRS=~/.guix-profile/lib/caja/extensions-2.0/ caja <FuncProgLinux>(both $HOME/.guix-profile and /run/current-system/profile/ work). I don't know why it's behaving that way if everything looks fine to me ._. <yelninei>is the environment variable set and a correct value? "guix shell caja caja-extensions --search-paths" does not set a search path for me. <elb>Hi all, I'm working on removing deps on go-1.23 (PR 5318 and 5358), and I'm running into some issues where go checks fail only because they're running in parallel; in general, this is a problem with the go testing framework (often related to trying to use the same port number in multiple tests at the same time). Is there a way to ask the guix daemon to build things _serially_ when doing a given build? <elb>(or is that what -M does?) <mthl>Hello, any committer interested in reviewing a Clojure related PR today ? <yelninei>elb: in the package arguments set #:parallel-tests? to #f <elb>yelninei: nice, thank you <elb>yelninei: oh; I think that's actually something osmewhat different <elb>what I mean is, two different go packages shouldn't be tested in parallel <ckewi>Looks like when guix.gnu.org is feeding into planet.gnu.org, the donate button will lose the accept-lang context I suppose; and on my own exp, the donating button would default back to ar (maybe because it is the first in the language list when clicking through planet.gnu.org <Rutherther>elb: but the package builds are carried on in a container, unless you've disabled it (which you shouldn't typically do) that is isolated from your host, even when speaking about network. So are you certain the issue is that the two package builds are somehow conflicting? It would be very strange, I don't think they have capability to open a port at your host's interface <elb>Rutherther: I'm not 100% sure, no, but I know that the builds fail when they're part of a dependency tree (reliably) but succeed when run individually <Rutherther>and you aren't starting guix-daemon with --disable-chroot, right? <elb>uh not intentionally, it's whatever guix does when installed on debian foreign system <elb>looking at the process table it does not have that option <elb>but for example, the package kubo depends on go-github-com-pion-transport-v2 and go-github-com-pion-transport-v3; if I `guix build --no-substitutes kubo`, it will fail (from guix 93e4c03 in this case, but it generalizes as far as I can tell) on those two packages, but if I build th those two packages and _then_ kubo, all three succeed <elb>and looking at the build log errors (without digging super deeply, I'm trying to update dozens of packages and mostly just skipping over ones taht are too problematic) it looks like the kind of errors I normally see when, e.g., ports are unavailable or similar <nmeum>one more question regarding python packaging: how are references for python packages generated? my understanding was that python dependencies required at runtime should be listed in propagated-inputs. however, python-numpy doesn't have any propagated-inputs but nonetheless it has references to several python packages (python-mypy, python-pytest, …) which are pulled into the closure. how <nmeum>does that work? are these added by the scanForReferences function? <ckewi>is there a way to restrict guix pull to ipv4-only stack? looks like one singaporean and several PRC people were experiencing git pulling codeberg through v6 failure <Rutherther>ckewi: have you considered just putting ipv4 to point to codeberg.org in /etc/hosts? <ckewi>yes that's a quicker fix( you are right; I will use this method as for now (thanks <cbaines>ckewi, you should raise an issue for this as well, as Guix usability on IPv6 only systems is important <cbaines>and any specific error messages and information on what exactly isn't working with Codeberg would help <Rutherther>is this really a Guix issue or is it that Codeberg currently had some issues that presented only through ipv6? <ckewi>I think it is codeberg-related only <Rutherther>and is it a transient issue, or does it happen regularly/always? <ckewi>it happens regularly recent days <nmeum>is there a good way to determine *why* package A has a reference to package B? e.g. which file in the store path for package A contains a reference of a package B store path? <ckewi>yeah I'd better report the issue on codeberg-infra related first <Rutherther>ckewi: maybe also confirm that the issue happens when you use codeberg.org and not just guix.gnu.org. Just in case. I would not expect a redirect to be problematic, but it should be easy check I hope <ckewi>looks like timeout both in git clone guix pull and website access for codeberg; and guix.gnu.org website v6-only access is darn good for me <Rutherther>FuncProgLinux: I don't know, I have never seen that. And it doesn't match what you've shown before - you've sent CAJA_EXTENSION_DIRS=~/.guix-profile/lib/caja/extensions-2.0/. But even if ** got expanded, it would be expanded to the subdirectories, not this base directory <nmeum>re my questions from 2 hours ago: apparently python-numpy has a giantic closure because the 'wrap phase inserts a scripts which lists all packages from the search-path in the GUIX_PYTHONPATH environment variable. thereby, scanForReferences() (when encountering that script) inserts a reference for each of those packages and they get pulled into the closure <nmeum>very interesting how that 'wrap phase interacts with scanForReferences() <zenmaya42>hi i have a curious issue i cannot seem to google around, none of the graphical terminal and sudo work, always failing with the variation of "Failed to open PTY: No such file or directory" <zenmaya42>i tried to crossref it to the default's installer config but it seems i have everything the same <zenmaya42>oh you actually must not forget to mount %base-file-systems