IRC channel logs
2025-04-20.log
back to list of logs
<vagrantc>i am seeing at least one failure to build ... magic-wormhole-mailbox-server ... it seems like a problem with python-setuptools maybe, so might affect quite a few other packages? <kyoji>Hey #guix, is there a way I can specify exactly what mainline linux kernel version I would like to use? I am not using linux-libre, so I'm unsure if the kernel options work <ieure>kyoji, You'll need to ask questions about non-free software in #guix-offtopic (or #nonguix, if you're using their stuff). <ieure>However, it holds for all packages in Guix that you can choose between versions which have Guix packages available by using specifications or referencing the variable holding the package. If you need a different version, you'd have to create a package variant for that, which requires compiling it. <vagrantc>kyoji: there are a number of transformations that might prove useful ... guix build --help-transform <vagrantc>kyoji: notably --with-version ... though it does not always work with all packages ... and kernel packaging is sometimes complciated <vagrantc>seems like there are a fair number of phases and whatnot that basically do: (substitute* "SOMEFILE" (("'rU'") "'r'")) ... <vagrantc>and doing so fixes magic-wormhole-mailbox-server ... so ... <cobra_>a bunch of my packages have empty binaries for some reason <vagrantc>cobra_: there have been a few reports of this recently ... <vagrantc>cobra_: guix gc --verify=repair,contents might help ... <cobra_>vagrantc: that didnt fix anything <cow_2001>sent a patch for (@ (gnu packages guile-xyz) guile-srfi-133) <cow_2001>this one runs the tests (all pass) and has some checks added <meaty>is there anything you guys do to make guix error messages more useful? <meaty>almost always the errors i get are 95% boilerplate at the lowest and report errors in ice-9 when the actual issue is buried somewhere in the stack trace full of 'raise-exception' and 'call-with-prompt' and '(_ _)' <ruther>meaty: I read more of them to start understanding what each of them means :D <meaty>ruther: teach me your ways plz <meaty>these traces are nothing like comon lisp or elisp traces <meaty>idek where to start with comprehending them <meaty>let alone getting useful info out of them <ruther>meaty: I don't think I can teach this. Also it involves a lot of guessing. It depends on the code I wrote. <ruther>meaty: you're right that the traces are very cryptic especially if it's something happening on the build side <csantosb>Hi Guix ! I just did a fresh 'guix pull' and got a conflict with unbound python-contextlib2, anyone else ? <csantosb>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python-contextlib2)) (value #f)) <ruther>csantosb: from which channel are you getting that error? <csantosb>ruther: one of electronics (my own) guix-science guix-hpc guix, how can I know where exactly the issue originates ? <csantosb>There is no python-contextlib2 in electronics, guix-science, only in guix <ruther>csantosb: python-contextlib2 has been removed from Guix, so that is where it originates. One of the channels is using it, but it doesn't exist, anymore. <csantosb>Right, ... the problem comes from guix-hpc, in python-cs. <ruther>If the list of chanels you sent before was like a complete list you use, that's not what I was asking for initially. I was asking for where the error is coming from. That should be obvious from which derivation failed to build from the log <ruther>csantosb: that is the log itself, but of what derivation is it a log? That's not going to be mentioned inside of it <ruther>csantosb: it's in the name of the log <csantosb>f30kjn8lkarqf23ddfqxmlak42davn-guix-package-cache.drv.gz ? <meaty>does anyone here use emacs-guix? is there a more recent version out there? the upstream is four years old at this point <csantosb>meaty: I'm using it; in emacs-xyz, I see emacs-guix compiling from 455272c revision, which dates back from one year ago, right ? <ruther>csantosb: sorry I am misremembering. The channel it's coming from is visible in the log then. native-inputs #<package python-cs@3.3.1 guix-hpc/packa…> <ruther>In guix-hpc/packages/ci-tools.scm: <csantosb>Yeah, python-cs refers to missing python-contextlib2. <csantosb>Guix-hpc is hosted in a (private) Inria forge, no issues then; I mention the issue in irc channel <meaty>anyways has anyone been using the guix-load-path variable from it? Every time I set it it just breaks the package <meaty>i just want to be able to iterate on package definitions within emacs <csantosb>I confirm, I need to `(setq guix-load-path nil)', otherwise it breaks <csantosb>ruther: another broken package, guix-science, python-tslearn, requires python-cesium in gnu/package/astronomy <ruther>csantosb: yeah that one has been moved from python-xyz to astrononmy <cow_2001>sent patch adding guile-srfi-234-manual, the srfi document mindlessly adapted to org-mode format and for exporting to texinfo <ruther>If I want to send new version of just one patch in patch series, can I send just that one, or should I send the whole series? <csantosb>I'd say the easier for the reviewer to apply the new version of the patch series. <ruther>Yeah, I am thinking the same thing, but was wondering that maybe mumi has got this covered <ieure>ruther, You need to send the whole series. <n|Phreak>I installed guix on Arch because of guile packages, but my emacs <n|Phreak> instance is from pacman, do I need to install emacs from guix or is <n|Phreak> there a way to use guix guile modules on my emacs instance? <n|Phreak>Sorry copy and paste from another chan didn't format very well. <ieure>n|Phreak, I think you can add the Guix profile's lisp directories to the load-path of your pacman Emacs. <n|Phreak>Basically I install guix pkg manager to install guile modules, my emacs instance was install from pacman and not guix. Is this going to be a problem? <ieure>n|Phreak, You may encounter issues if the version of Emacs obtained from pacman is different from the one the Guix emacs-* packages are built with. <csantosb>n|Phreak: By the way, using emacs-team branch you'll get emacs 30, same as Arch. <csantosb>Udiskie (which depends on python-keyutils), is broken ... 🥺 <ieure>ruther, Hmm, the patch seems reasonable to me, but I don't quite follow your last message in that bug. <ruther>ieure: just ignore it for now :D It's actually not relevant to that bug, I don't know why I sent it <ruther>(I really don't like the current approach of Guix to have everything related to cross compilation under /lib instead of under /lib/ARCH/. It makes it impossible to work with native and cross toolchains in one environment..., but it's not something relevant to that bug) <ruther>I doubt Guix will switch to using /lib/ARCH, at least not any time soon, I already started working on a utility that will fix/workaround this issue for me, by making sort of 'cross' shell environments. <ieure>ruther, I'm on the fence about pushing this, solely because I don't know the domain well. <ruther>ieure: I understand, yeah. As far as I can tell the only place cross-gcc-toolchain is used is in (gnu packages cross-toolchain). You can put those packages in your shell, like the gcc-cross-i686-w64-mingw32-toolchain. But you won't be able to compile much without setting CROSS_C_INCLUDE_PATH and CROSS_LIBRARY_PATH manually. <ruther>So I don't really see any way this would break something, but gains the possibility to *just* use those toolchains <ruther>I actually set the library path here wrong, it's not necessary for glibc anyway, so it doesn't matter <ruther>ieure: also you can see comment in the (gnu packages cross-toolchains) that purpose of those toolchains is to use them in a shell. But currently they are unusable on their own... :/ <ieure>ruther, Okay, yeah, I poked around and think this is unlikely to cause other issues. <ieure>And multiple people commenting to say the patch fixed real issues is also compelling. <ieure>ruther, I'll try to push this today, though I have some stuff going on and it won't be until later. <lfam>As of now, the system doesn't build for me, but somebody said that it did work for linux 6.14 (not linux-libre). It would be great to get more data points <lfam>If you try it, please chime in on the patch ticket! <n|Phreak`>Is it normal for guix pull && guix -u is taking a awefull long time? No this is a fresh install just installed yesterday. <ruther>n|Phreak`: The first pull is always much slower than subsequent ones. But even generally guix pull can be quite slow <ruther>It all depends on whether there is already a substitute for guix or not. And the same goes for guix package -u, where it's important if the packages you're using already have substitutes <ruther>If they don't, they are built on your machine and that can take up quite a lot of time <n|Phreak`>hmm intresting I only have the core packages and 2 third party packages <n|Phreak`>Still trying to decide if I should install guix-system again or just use guix pkg manager on Arch <n|Phreak`>guix pull: error: Git error: unexpected http status code: 502 <csantosb>n|Phreak`: Yes, this happens sometimes, savannah has problems <n|Phreak`> ]builder for `/gnu/store/2vf0jy5ym2xj60rzxjiqdn5r89nq87bv-guix-cli-core.drv' failed due to signal 11 (Segmentation fault) <n|Phreak`>build of /gnu/store/2vf0jy5ym2xj60rzxjiqdn5r89nq87bv-guix-cli-core.drv failed <n|Phreak`>yeah but the pull yesterday worked just fine <n|Phreak`>yeah something with savannah , cause I received 502 again. I'll try the codeberg mirror , but that one is really slow. <csantosb>I'm running guix foreign on top of arch, too <csantosb>The codeberg mirror is probably slow just once, until you have it in the cache <csantosb>You need to pull the whole history; then, you'll be pulling only since latest pull <n|Phreak`>do you run guile repl in geiser-guile on a guix shell ? <csantosb>I open a term, cd to guix clone, run `INSIDE_EMACS=1 guix repl --listen=tcp:37146' <csantosb>Then, M-x geiser-connect in a scm buffer <csantosb>Check manual, 8.13 Invoking ‘guix repl’ <n|Phreak`>wait .. so you clone everytime you run the repl ? <csantosb>Just checked, no need to launch guix repl from a guix copy, sorry (this is just what I use to do) <csantosb>8 Programming Interface -> 8.13 Invoking ‘guix repl’, as for Info <csantosb>So after geiser-connect, this should do it, for example: `,use (gnu packages fpga)' <n|Phreak`>great .. builder for `/gnu/store/2vf0jy5ym2xj60rzxjiqdn5r89nq87bv-guix-cli-core.drv' failed due to signal 11 (Segmentation fault) <n|Phreak`>build of /gnu/store/2vf0jy5ym2xj60rzxjiqdn5r89nq87bv-guix-cli-core.drv failed <n|Phreak`>View build log at '/var/log/guix/drvs/2v/f0jy5ym2xj60rzxjiqdn5r89nq87bv-guix-cli-core.drv.gz'. <n|Phreak`>cannot build derivation `/gnu/store/1h615zj52rz6jal9m1qzg2cp9vpavwl7-guix-cli-core-modules.drv': 1 dependencies couldn't be built <csantosb>'/var/log/guix/drvs/2v/f0jy5ym2xj60rzxjiqdn5r89nq87bv-guix-cli-core.drv.gz' <csantosb>Not that useful. In my case I have 100%. <ruther>n|Phreak`: are you using anything like an antivirus or protection/security app? <ruther>n|Phreak`: if not, can you try `guix gc --verify=contents` to see if anything in your guix store is corrupt? <ruther>It doesn't matter if it worked yesterday or not. Just answer the question <ruther>Apps like AppProtection from Citrix will take a while to corrupt Guix in a way to make it unusable. That it works one day doesn't mean it will work the next one. <n|Phreak`>Yep I understand but I don't run services like that <n|Phreak`>path `/gnu/store/1diw7582x0bdi41mwwjp00imbgbkksb8-guix-packages-base' was modified! expected hash `842186f4e3d0f7137fea37c91fc9c18df8f4dec8a6639c92affacbe5c7a692a2', got `0b1b888fe0eb7ba42b1569105f9d94fb24b93efa062242092aa3d595e02acd2a' <n|Phreak`>something is wrong with base packages is seems <ruther>n|Phreak`: That could be the issue then. You can rerun with --verify=contents,repair to repair it as well. Probably should've recommended that in the first place. <coyotes4ys>thanks csantosb i already got it working just by trying guix pull 4 times or so <ieure>Sigh, my cuirass instance is super horked. <ieure>It's been evaluating build changes for 5 hours. <ieure>No clue what it's doing or why this is taking so long.