IRC channel logs

<graywolf>Did the amount of grafts increased recently? I do not recall last reconfigure being as slow as today's one

<ieure>Is there a way to run `guix shell --container' and set the memory limit? Don't see anything in the manual or --help output, but figured it'd worth an ask.

<bdju>Is anyone working on updating the Rust package? I noticed it's older than the version used/recommended in the book, The Rust Programming Language. We have 1.77.1 (last time I pull'd at least) and the book recommends 1.81.0.

<bdju>btw the guix package web search keeps 504ing

<bdju> https://guix.gnu.org/en/blog/2024/hurd-on-thinkpad/ found a typo here, "simpfilied"

<bdju>disregard the Rust question, I see we have 1.82.0 now! nice!

<apteryx>janneke: I pushed some slight changes to the comments of the hurd images yesterday (s/qemu@7/qemu/ and the git clone instructions which had some typos)

<sneek>Welcome back apteryx, you have 4 messages!

<sneek>apteryx, janneke says: hah, you already made two of the same fixes to the hurd examples as i made locally, thanks! i've pushed a comment about the login prompt not showing

<sneek>apteryx, janneke says: i've tested these exact instructions and they work for me

<sneek>apteryx, civodul says: we’d need to check with janneke, but i think 118d6429c8e7d4fce19da569da959ca753edb087 is incorrect

<sneek>apteryx, janneke says: the login prompt only/still appears on the 32bit hurd, so apparently it's just broken for the 64bit hurd

<apteryx>janneke: ah, so you can at least reproduce the problem for the 64bit hurd variant?

<apteryx>(no login prompt -- how about ssh'ing in, does it work for you?)

<apteryx>anyone could tip in regarding #73416? It seems exoctic that it'd matter, but I had found a case where it did, dramatically

<apteryx>e.g. cling would segfault without it

<podiki>woah, a ton of cves in gstreamer: https://github.blog/security/vulnerability-research/uncovering-gstreamer-secrets/

<podiki> https://gstreamer.freedesktop.org/security/

<podiki>i see gnome-team has a more recent gstreamer, we should bumpt that to 1.24.10

<podiki>(i don't know if that's something we can graft on master or what, with all the various gst-plugins and stuff)

<janneke>apteryx: yes, ssh

<janneke>grmbls

<janneke>ssh-ing works as decribed for me

<apteryx>hm. I'll retry soon.

<janneke>(y)

<apteryx>ah, an empty shellcheck output on etc/guix-install.sh. That's refreshing.

<unmush>well, I think I've managed to get pnet building portably (the dependency on libjit is now optional) in my local checkout, but now I am discovering that by mono-1.2.6 mono's interpreter had already bitrotted away (they never fixed it, removed it in 2014, then reintroduced it it in 2017). Which means that for the vast majority of mono's existence, the only runtime it supported was the (platform-specific) JIT compiler

<efraim>now test it with codespell :)

<efraim>unmush: I briefly tested mono-1.2.6 with the interpreter, is it still missing a header? that might've been a race condition though with too many cores

<efraim>apteryx: codespell says etc/guix-install.sh is clean

<unmush>it is missing headers, yes, and when they are added it says: interp.c:2668:55: error: ‘MonoVTable’ has no member named ‘interface_offsets’

<unmush>among other errors and many warnings about implicit declarations

<apteryx>codespell! didn't try that one, is it better than shellcheck?

<unmush>e.g. interp.c:4329:17: warning: implicit declaration of function ‘mono_debug_init_1’; did you mean ‘mono_debug_init’? [-Wimplicit-function-declaration]

<efraim>codespell checks for typos, but already has a dictionary of words to ignore

<apteryx>ah, spelling!

<apteryx>ACTION uses aspell from within emacs

<efraim>unmush: I guess we could try it with c99

<efraim>I've run codespell against bits of guix before, the codebase is littered with typos

<unmush>what would that change?

<efraim>c99 was a lot more lenient with what was allowed, and it might allow the build to pass

<apteryx>efraim: oof!

<efraim>I don't even know how to apply fixes. by word across the codebase? by module? by package?

<unmush>oh wait a minute, I didn't scroll all the way up to the first error, there was a problem with my substitute* to add a header

<efraim>oh, also CFLAGS+= doesn't actualy work with make-flags in guix

<unmush>weird, I distinctly recall it fixing a complaint about ARG_MAX not being defined

<unmush>but I could be misremembering

<unmush>hm, I fixed my substitute*, it's still complaining about the same stuff

<unmush> https://www.mono-project.com/news/2017/11/13/mono-interpreter/

<unmush>"When generics were introduced, the engineering cost of keeping both the interpreter and the JIT engine was not worth it, and we did not see much value in the extra work to keep it around, so we removed the interpreter."

<unmush>so even if we managed to fix up the interpreter in 1.2.6 to work properly, it would require further fixing up all the way until 2017

<efraim>so it sounds like we're using libjit

<unmush>and it's not like we can use pnet's ilrun, because mono's standard library is tightly coupled to the mono runtime through icalls

<unmush>libjit is only used in pnet

<efraim>check configure.in, all our targets have JIT_SUPPORTED=yes jit_wanted=true

<unmush>right, but to be clear, mono doesn't use "libjit", it uses its own jit

<efraim>oh, really?

<efraim>I didn't check that as closely

<unmush>I suspect that we may find that the range of possible matches for arm*-linux* has changed since 2007

<unmush>but I don't know if they all maintain backward compatibility

<efraim>early arm and armv7 are almost 2 separate architectures

<efraim>so it's not likely it still works

<unmush>plus of course no risc-v, though I don't know if that's on our list yet

<efraim>like haskell or other languages, first one architecture, then we'll expand it as we can

<unmush>alright

<unmush>also, currently as late as mono-pre-5.10.0 still fails without #:parallel-build? #f

<unmush>I didn't run into this during my initial work because I used --keep-failed which disabled offloading

<divya>Can one extend guix a bit to replace build tools proper (make, meson etc.)? If we could have a option such that the developer provides a build.scm where a declarative build-system is provided, and then it's used during the `guix build` of the package's definition?

<homo>at least haskell is available through hugs and hopefully it's possible to bootstrap haskell further by bootstrapping microhs

<divya>homo: Hugs is from 1998, you'd be missing out on a lot.

<janneke>jas: bootar (or gash-boot) in commenement?

<homo>divya: I checked that hugs supports almost all extensitions that microhs requires, so there is hope by either reducing microhs or expanding hugs

<luca>What for?

<homo>hugs supported haskell2010 before haskell2010 was released

<dariqq>even with disabling the guile jit guix pull can run oom on guix-packages-base , retrying again and it was able to finish. Is there a way to make guix-packages-base not require gigabytes of ram?

<efraim>how much ram do you have?

<janneke>dariqq: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=15c5f1a2c20b21de0f19f42db1ccab4c42117ebb comes to mind

<dariqq>efraim: An i686 machine with 2GB (not that much i guess) . But even running 'guix pull -s i686-linux -p /tmp/whatever' fails regularly hwne running from x86_64 (and then using that to serve substitutes). Disabling guile jit with the environment variable in guix-daemon helps but i would say that 3GB+ is a bit excessive

<janneke>as files have gotten only bigger, maybe even 10 files is too much in some cases on 32bit

<efraim>part of me thinks we should do some makefile magic and do each package scm individually

<efraim>or at least each letter

<efraim>I know that doesn't help with c, but it should with every other letter

<janneke>aiui, this is for guix/self.scm, not make?

<homo>it /tmp mounted as tmpfs? tmpfs consumes RAM in order to store files, so large files are a disaster on 32-bit

<homo>s/it/is/

<dariqq>I have a bit ome more info in #74381 . All the other parts of guix pull are fine it is usually only packages-base

<homo>if you use tmpfs for builds, then it's reasonable to allocate 64 GB of SWAP, as it gets filled up quickly

<homo>sometimes even 64 GB SWAP is not enough...

<dariqq>The thing that confuses me even more is why it was succeeding the second time after ooming first. Is guile caching things somewhere?

<homo>dariqq: probably because second time there were less files on tmpfs, as half of the work has already been done and cached in /gnu/store

<dariqq>homo: /tmp is not on tmpfs for me

<homo>if there is no memory leak from previous builds, it's really strange

<luca>Hi, when building a home configuration on a new machine I am getting an error "correupt input while restoring archive from #<closed: file 7fa3bd490a10>". On another machine this config builds just fine. Anyone got any tips?

<efraim>restart guix-daemon

<efraim>also on any machine you're running guix-publish on

<luca>no dice, same error (just different file hash thingy)

<luca>oh I guess I might have forgotten to set the guix locale thingy. Imma do that really quick

<Deltafire>I think I had that error once, I removed the package that was causing the problem then tried again a day or so later (after a guix pull) and everything was good again

<Deltafire>sometimes there are hash mismatches also

<luca>In my case it seems like the GUIX_LOCPATH and LC_ALL were missing. New machine, easy to forget. It got further this time :D

<homo>oh my, just installed freedroidrpg and... colors are inverted, main menu is very red and game itself is very blue

<nutcase>Hi all, if a package definition from guix's master fails to build, isn't this something that should be detected by QA before? (it seems the package 'trash-cli' does not build: https://paste.debian.net/1340511/ )

<cbaines>QA isn't really working at the moment

<nutcase>if it is working again, will it reveal that issue?

<cbaines>not really, QA is meant to flag breakages before they reach master

<cbaines>I think there's some version issues with quite a few Python packages in Guix currently

<cbaines>from the build log you posted, there could be an incompatability between python-flexmock and pytest

<luca>What exactly creates the /var/guix/profiles/per-user/$USER/guix-profile folder?

<luca>It seemes like my `guix home reconfigure file.scm` didn't make that folder (though guix-home was created)

<Rutherther>luca: guix-profile folder under there is for stuff installed through guix install/guix package. home has guix-home in /var/guix/profiles/per-user/$USER

<luca>ahhhh ok. Got it, thanks!

<homo>err, that color inversion is not specific to freedroidrpg, it seems my laptop itself is damaged and produces inverted colors

<Rutherther>luca: profile of guix home can be found at guix-home/profile if you were after that. This allows using both home and guix install

<luca>Yeah, I suppose I just need to source $HOME/.guix-home/profile/etc/profile

<Rutherther>luca: right, but guix home should create .profile for you that will do that, so you should rather source your ~/.profile

<nutcase>cbaines: thanks for the explanation. I'll post an issue

<nutcase>(because I'm not very familiar with building python packages at all)

<luca>Rutherther: hmmm yeah maybe. Right now I have my own .profile file which I assume overwrites guix's. So maybe the correct approach here (without me learning too much lisp) is to source my .profile from guix's .profile

<amano>How do I get a list of /gnu/store directories required by an application?

<amano>For example, I want to get the list of /gnu/store directories required by icecat.

<cbaines>amano, guix size icecat will give you a list

<Rutherther>additionally see also guix graph command, specifically with --type=references

<dariqq>janneke: I tried reducing the size for guix-packages-base even further from 10 to 5 and pulled from my local checkout with -s i686-linux (is it using the self.scm of the current guix or new guix?) and things seemed a bit more reasonable with guile using around 1-2 GB (even with guile jit)

<amano>cbaines: Can I get the list in guile scheme?

<amano>I want to turn the list into a file?

<janneke>dariqq: good info for #74381

<janneke>it's quite probable that the 32bit hurd will also suffer from that bug

<janneke>ACTION hasn't pulled on the hurd for quite some time

<dariqq>janneke: Will add that later , thanks for the initial hint

<janneke>dariqq: (y), thanks for bringing it up

<cbaines>amano, yep, I think you're looking for the requisites procedure from (guix store)

<dariqq>tried on a childhurd of mine and guix pull was segfaulting :(

<amano>cbaines: 💙

<janneke>dariqq: yeah, figures :-(

<janneke>dariqq: don't forget to mention that too

<luca>Is it possible to use a guix locker (swaylock for example) on a non-guix system? Without a screen-locker-service-type

<luca>Oh I guess all it really needs is https://github.com/swaywm/swaylock/blob/master/pam/swaylock

<homo>unlikely, such functionality requires suid, and only "sudo guix system" will give you suid

<luca>Oh suid? Not just pam?

<Rutherther>it doesn't require suid, it requires pam

<homo>interesting, that's unusual

<luca>Seems like if you compile with the pam library then pam is used, otherwise you could suid the binary

<luca> https://github.com/swaywm/swaylock/blob/fbc5a8136187491e5ee3071e8a60e6593ca9b90b/meson.build#L116

<homo>there was an idea to replace both suid and pam with authentication mechanism of plan9, which would also eliminate suid from su, sudo and doas, but it got quickly removed from the linux kernel because maintainer suddenly disappeared

<homo>it was p9auth driver if I remember correctly

<janneke>ACTION is still a bit disappointed about https://ci.guix.gnu.org/jobset/core-packages-team

<janneke>and keeps on building core-packages-team locally...

<luca>Using guix home when using curl I am getting "curl (60): server certificate verification failed. CAfile: none CRLfile: none". How can I get those files it wants?

<apteryx>should '^guix/scripts' be a regexp in the scope of the core team?

<apteryx>I'm preppinga change to guix/scripts/refresh.scm, and it was surprised it has no team coverage

<apteryx>I was*

<janneke>apteryx: seems a good idea

<janneke>ACTION building mosh on a remote machine because ssh keeps dropping the connection and builds fail and nohup is inconvenient

<janneke>...but forgot to use nohup, and at 80% the connection drops

<efraim>sounds like the type of thing mosh would help with

<efraim>or screen/tmux

<janneke>yeah

<janneke>efraim: do you have an idea why https://ci.guix.gnu.org/jobset/core-packages-team doesn't seem to to what i would have hoped it to do (build lots of packages...)?

<efraim>I guess we can check the logs, either on curias's webpage or on berlin

<cbaines>janneke, I think all the evaluations have failed

<janneke>i'v just built llvm-11,13,17 and currently building 18

<efraim>have you built guix itself?

<cbaines>there's something in the log about /gnu/store/f8cr6vnjkc2hxy9qyjlyrkprfg2naws3-guile-3.0.9.drv failing to build

<janneke>cbaines: efraim not just yet, 18 more packages to go

<janneke>cbaines: ugh, that built for me

<janneke>=> /gnu/store/x4jad6vaaj0z2vgvxvjx401nbxcin8m7-guile-3.0.9

<efraim>time GUIX_DAEMON_SOCKET=ssh://berlin ./pre-inst-env guix build --no-grafts --system=x86_64-linux --no-substitutes guix -n and then on berlin I tell it to build that package

<efraim>it's how I normally test powerpc64le builds

<janneke>efraim: nice

<efraim>I got it started building /gnu/store/qs22xll4h4dvm8niz42y8rn98dy7ldky-guix-1.4.0-30.790c9ff.drv

<janneke>efraim: thanks!

<janneke>ACTION is at 88% of qs22x locally but it's great if we have substitutes and could decide to add architectures or increase the scope

<janneke>89%

<janneke>ACTION has been focussing on reconfigure'ing their machine on core-packages-team, and apparently guix gets built later than the llvms and rusts

<ekaitz>hi! anyone? guix pull: error: Git error: invalid content-type: 'text/plain; charset=UTF-8'

<ekaitz>it's when pulling using https from cgit, but it works with a plain git clone

<efraim>perhaps the url is wrong?

<luca>How can I use third party substitute servers when using guix home? (where I can't configure an operating-system)

<janneke>=> /gnu/store/xjy2cvwvlqfa651lll27wymsnvgfz2bd-guix-1.4.0-30.790c9ff

<divya>ekaitz: I just did a successful `guix pull`

<ekaitz>divya: yeah but not from my repo hehe

<ekaitz>efraim: hmmm might be, i'll try again

<divya>Oh, you're setting up a mirror?

<ekaitz>no, i have a channel

<ekaitz>efraim: tested, the url is ok

<ekaitz>efraim: could you try with https://git.elenq.tech/guix-packages

<ekaitz>i can clone from there but it doesn't work with guix

<janneke>yeah, so clang-18.1.8 really doesn't build with gcc-14 (which now i believe has been built correctly...)

<janneke>trying again with gcc-12, which was previously used to build clang-18.1.8

<janneke>all these odd quirks and dependency relations, do you think any of the upstreams ever learns (or cares) about them?

<janneke>maybe some people should blog more

<homo>sounds like bootstrap nightmare on arches other than x86_64

<ekaitz>oh i found the issue, it's because i'm using dumb http and libgit doesn't let you use that

<janneke>...so building gcc-12 now...

<divya>efraim: Did you close #74432? QA says ``issue not found''.

<cbaines>it's still open https://issues.guix.gnu.org/74432

<cbaines>QA is currently not up to date, as the Patchwork database is being rebuilt

<divya>cbaines: Indeed I saw it open there. Thanks for the heads up on QA.

<janneke>hmm, so /gnu/store/p3cja994xk5hi6kq1qd1lqr69xcf279i-llvm-18.1.8.drv builds with gcc-14, but clang-runtime-18.1.8 doesn't; isn't that weird?

<janneke>aaargh

<janneke>/tmp/guix-build-clang-runtime-18.1.8.drv-0/source/build/lib/fuzzer/libcxx_fuzzer_x86_64/include/c++/v1/__type_traits/is_convertible.h:28:77: error: there are no arguments to ‘__is_convertible’ that depend on a template parameter, so a declaration of ‘__is_convertible’ must be available [-fpermissive]

<janneke>how is this possible, before clang-runtime-18.1.8 was compiled with gcc-12 too?

<janneke>grmbl

<janneke>ah no, gcc-13

<janneke>what a disaster...

<homo>orahcio hi, if you managed to get wlgreet working, I actually need that config, as I want to try to replace pulseaudio with pipewire-pulse, so I can't afford rebuilding bloated packages

<homo>I still experience error when trying to build custom kernel as documented by handbook, this config https://paste.debian.net/1340555/ results in this error https://paste.debian.net/1340556/

<meaty>Does anyone know where I could find clean hi-res/vector images of the guix logo?

<homo>$ ls /gnu/store | grep guix-artwork

<cbaines>meaty, https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/logo

<luca>Anyone know what package provides some sort of pinentry program to decrypt gpg keys? My personal choice would be pinentry-curses, but really anything goes

<RavenJoad>Just a quick check, is Shepherd 1.0 in Guix and are services are using it? I haven't pulled in a while and want to get the best and greatest on this next pull.

<efraim>I think all the pinentry packages provide pinentry-curses

<luca>oh damn. That's what I get for using `guix locate` instead of `guix search`. Thanks!

<janneke>RavenJoad: yes

<janneke>git log --oneline | grep -Ei 'gnu: (shepherd|guix):' | head

<janneke>942942ee75 gnu: guix: Update to 1.4.0-30.790c9ffe59.

<janneke>376d957291 gnu: guix: Update to 1.4.0-29.30322214d4.

<janneke>8966bd6c06 gnu: guix: Update to 1.4.0-28.285f0862d8.

<janneke>050d9f5158 gnu: shepherd: Add 1.0.0.

<michzappa>I'm trying to package a pyproject.toml file that needs python 3.12, but running into issues with the pyproject-build-system being based on the 3.10.7 `python` package. It cannot find the module 'setuptools' - my belief being the python-setuptools is compiled for 3.10 not 3.12. Doing the rewriting succeeds in evaluation but not building, with the

<michzappa>same setuptools not found error.

<michzappa>```

<michzappa>(use-modules

<michzappa> (gnu)

<michzappa> (guix packages))

<michzappa>(use-package-modules

<michzappa> python

<michzappa> python-build)

<michzappa>;; SUCCEEDS

<luca>yeah try using a pastebin instead of pasting here directly

<michzappa>gotcha: https://pastebin.com/2RYPK5Bm

<luca>What do you need python-pip for?

<michzappa>I overall am trying to package something else with python3.12 as the overall version - i do the same package-input-rewriting strategy and python-pip is the first thing to fail. It's my minimal failure case at the moment

<luca>afaik python-pip is only needed if there are missing dependencies, which you should specify manually instead of letting the program install them itself

<luca>There's also a guix import pypi command which might help out

<michzappa>interesting - I think I have a handle on all the dependencies... I think python-pip is being pulled in as a dependency of the rebuilt python-toolchain

<meaty>Is there anything in the works to filter the output of 'guix search' for when you're looking for end-user programs and not libraries/middleware?

<RavenJoad>janneke: Awesome! Thanks!

<gabber>does `guix home container` lack the symlink .guix-profile -> .guix-home/profile by design or is this a bug?

<gabber>or am i doing it wrong?

<luca>I don't have it either on a system I've never ran guix install on. So yes I think it's by design

<meaty>also how can I make 'less' behave the way the guix commands use them? I like how I can keep what I was looking at around for reference and the output is only paged when necessary

<jmes>home-xdg-base-directories-service-type dosen't expose XDG_DATA_DIRS, so I tried extending home-environment-variables-service-type to add Flatpak's share directory (for desktop entries), but I only get the default value. Is there a better approach or something I'm missing? Here is the simple-service I'm using: https://bpa.st/5Z7A

<luca>meaty: less -F? (aka --quit-if-one-screen)

<meaty>luca: that's it, thanks

<luca>Is there a way for guix locate to search stuff that I don't have locally?

<ieure>luca, No. From the manual: "For now, ‘guix locate’ builds its database based on purely local knowledge—meaning that you will not find packages that never reached your store."

<luca>And I suppose no alternative exists?

<ieure>luca, Don't think so. There's https://packages.guix.gnu.org, but that doesn't search package contents as far as I know.

<vagrantc>is it just me, or is it frustrating to only get CCed on *some* of the patches in a patch series? I actually have to bother to go dig out the whole patch series anyways to actually review it in an meaningful way...

<ieure>vagrantc, Very.

<ieure>vagrantc, I wish there was some way to get cc'd on bugs/patches based on what package it was filed against.

<vagrantc>yeah, etc/teams.scm is only at the file level of granularity, but i would love to be able to get CCed on specific packages ...

<vagrantc>but even then, if only one of the patches in a patch series touches that package ... i still would like to see the whole patch series...

<ieure>Yeah, definitely.

<janneke>efraim: i built hello on aarch64

<nutcase>Hi, how do I know, why a package is built that is not explicitly installed? In Debian there was "aptitude why <package>" (when there was a short period of aptitude was intended to replace apt(-get), IIRC). Is there something similar in guix ? I know that you can create a GraphViz for services. Is there something for packages also?

<janneke>and finally: successfully built /gnu/store/8lybhbdjls6h7rhkyhcbj3d0i1lnfb9q-clang-runtime-18.1.8.drv

<janneke>ACTION updates core-packages-team

<janneke>we may have to rebase on master for python fixes, dunno if we are missing any that would prevent system reconfigure

<Rutherther>nutcase: you can use guix graph with its various arguments, you will need to specify from where you want to begin though, like if it's your system pulling it in - /run/current-system, home - ~/.guix-home etc.

<janneke>nutcase: also, if derivation foobar-123.drv is being built, you can do someting crude like

<janneke>find /gnu/store -maxdepth 1 -name '*.drv' | xargs grep -l foobar-123.drv

<janneke>and navigating the drvs is pretty easy using emacs, although it's also easy to get lost :)

<nutcase>Rutherther: "guix graph --type=reverse-package gdm | dot -Tpdf > dag.pdf" answered my question. gdm is installed in my system, because I have (had) arc-theme installed, which has input "gnome-shell", which has input "gdm".

<nutcase>sorry, gdm is not installed in my system, but it needs to be built/present

<nutcase>Rutherther: thanks, once again

<janneke>nice

<janneke>hmm, clang-runtime-18.1.8 gets built in two flavors?

<lechner>Hi, who is in charge of the GNU Guix group on Codeberg, please? I'd like to transfer my mirror repo to you

<lechner> https://codeberg.org/guix

IRC channel logs

2024-12-19.log