IRC channel logs

2025-01-17.log

back to list of logs

<apteryx>hello! What would I use to get a 'powerpc-elf-gcc' compiler in Guix?
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, ArneBab says: did I miss a patch from you that I should still review? (I remember something but am not sure what)
<apteryx>perhaps I can instead build a GCC cross compiler for such target?
<apteryx>I guess I'd use cross-gcc with the powerpc-linux-gnu
<apteryx>ACTION tries to confirm GNU triplet is correct
<apteryx>it is, thanks 'guix build --list-targets' !
<elb>Hello all! I'm packaging fuzzball MUCK, which is GPL3+ with an exception to allow linking to OpenSSL, and that particular license doesn't appear in (guix licenses). What is the appropriate way to go about resolving that issue?
<apteryx>I'd use license:gpl3+ and add a comment ;; with linking exception
<apteryx>or similar
<apteryx>actually, ;with linking exception as a margin comment
<elb>is that something that might fly for upstreaming?
<elb>(now that OpenSSL is GPL-compatible, this seems somewhat academic)
<apteryx>I believe it'd be fine to include in Guix
<apteryx>other things to consider: it is packaged in Debian? Does the Free Software Directory has an entry for it?
<elb>it is not packaged in debian
<elb>(I'm guessing that's due to lack of interest, not license, though)
<elb>it is however also not in the free software directory
<apteryx>OK; well, we're on our own to evaluate if it meets the FSDG guidelines, but it seems it does a priori
<elb>there are definitelyi programs with equivalent license exceptiosn in the FSD though, at a glance
<elb>e.g. https://directory.fsf.org/wiki/Deluge
<elb>OK, once I get it working I'll propose it for inclusion, if it doesn't fly, it doesn't fly
<elb>I doubt anyone is breaking down the door to install it :-)
<elb>thank yoU!
<elb>actually that deluge license is word for word identical to fuzzball's
<elb>so I think there's prior art
<elb>deluge doesn't even have a comment, but I'll include one
<elb>it seems like good practice
<PuercoPop>dariqq: That seems to work. But it would be nice to be able to define a 'patch-directory' for the channel similar to gnu/packages/patches for the guix monorepo https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages.scm#n172
<PuercoPop>fwiw guile has define-parameter, which is dynamically bound, for those scenarios
<x4d6165>is there a DNS over tls option for guix? I know systemd has one but is there an option for guix (and other non-systemd distros)
<podiki>PuercoPop: you can, see https://gitlab.com/nonguix/nonguix/-/merge_requests/591/diffs?commit_id=558edf46c6d625e9ff4839b1248968d640b15925 for example
<podiki>(well sort of just copying/reusing the guix procedures)
<PuercoPop>podiki: Thanks!
<podiki>thank apteryx for that nice bit of code, handy :)
<wakyct>hi Guix, is there a common reason for error "gtk namespace not available". This is running Solfege. My Guix and packages are up to date
<zamfofex>Hello, Guix! I’ve noticed /dev/stderr is unusable from within a build container. Is that normal/expected?
<zamfofex>I get: /dev/stderr: Permission denied
<wakyct>yeah I don't think you have FS access unless you pass it explicitly in shell options
<zamfofex>No, I mean within a build container (e.g. ‘guix build’).
<wakyct>oh sorry, I don't know then
<zamfofex>It is fine, thank you anyway!
<lfam>Some documentation about the build environment, which is set up by the daemon in 'nix/libstore/build.cc': https://guix.gnu.org/manual/devel/en/html_node/Build-Environment-Setup.html
<lfam>I'm not sure if it's supposed to be usable or not, but I notice several packages that work around it not being usable
<lfam>I think it's weird that the daemon sets it up if it isn't usable
<lfam>zamfofex: I see the same thing. No permissions for /dev/stdout or /dev/stderr. No idea if that's okay or not
<zamfofex>lfam: My suspicion is that there might be an issue with how they relate to /proc (since I’m pretty sure they are meant to be symlinks to /proc/self/fd/{0,1,2} or some such).
<lfam>Yes, and they are
<zamfofex>I’m trying to figure out how to test it reasonably myself
<lfam>zamfofex: I used this: <https://paste.debian.net/1345600/>
<lfam>I added it as a build phase to my favorite "try something" package, dvtm
<lfam>You'll see it works if you output to a regular file and then do (invoke "cat" "file")
<lfam>Do you know invoke? You can run simple shell commands
<zamfofex>Yeah, I was just trying to figure out if there is a “proper” way to run something within a build container, but I guess not.
<lfam>I'm sure there is, but I don't know how to do it
<lfam>Just using a tiny package works fine
<zamfofex>You say “I’m sure there is”, but I’m not so sure myself. :-) Yeah, using a package work fine.
<lfam>The API is pretty comprehensive and you can use it from the Guile REPL. But I'm not much of a Schemer
<lfam>I would look at 'build-aux/compile-as-derivation.scm' if I had to figure it out
<podiki>hmm...berlin is doing some builds but none from e.g. https://ci.guix.gnu.org/eval/1998989
<podiki>noticed that x86_64 is often not doing much building, despite having the most capacity (in the past month or 2)
<zamfofex>lfam: Just a little update on my findings: I believe that the issue is that the files in /dev/std{out,err} are pipes that the build user doesn’t have permission to open. See e.g. https://unix.stackexchange.com/questions/748948
<lfam>podiki: I agree it seems to be idle a lot of the time. I think it actually finishes the jobs super fast
<lfam>This specific case does look suspicious though
<podiki>yeah, just takes time to get to them. i think it is fairly recent, for bigger jobs (like mesa-updates recently) i saw lots of i686 activity first, still with plenty of workers available though
<lfam>Hmph
<podiki>lfam: thanks for pushing the pydevd fix btw (though i haven't tried it yet)
<lfam>It works for me
<podiki>well CI did build (successfully) pydevd now, so that's a start!
<podiki>night guix
<abbe>apparently there are lot of empty files, which aren't supposed to empty in /gnu/store :(
<abbe>let's hope it's only /gnu/store
<abbe>not so lucky :(
<dariqq>is there currently a python world rebuild on master?
<dariqq>appearently da69a9e15115d6acc7e4a95cc6295f97c97f827e is causing 2000 packages to rebuild? https://ci.guix.gnu.org/eval/1997972
<peanuts>"gnu: Add python-pathspec. - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=da69a9e15115d6acc7e4a95cc6295f97c97f827e
<Deltafire>anyone know why options set in modprobe.d aren't taking affect?
<Deltafire>i'm having a similar problem to this guy: https://lists.nongnu.org/archive/html/help-guix/2022-05/msg00129.html
<lilyp>I don't think modprobe.d is queried at all – kernel-arguments might be the way to do things
<lilyp>might depend on your kernel module
<abbe>I guess high time to move off btrfs :/
<rekado>dariqq: this should not have been committed. We already have a package definition for this.
<rekado>and it's pretty fundamental, to.
<rekado>too*
<rekado>I'm reverting it.
<rekado>ACTION cancels the evaluation on ci.guix.gnu.org
<dariqq>rekado: thank you
<rekado>thanks for the report!
<rekado>guix lint would have caught this.
<Deltafire>abbe: some issue with btrfs?
<hako>abbe: What command did you use to power off the system?
<cbaines>Following the revert I've added the affected commits to the ignore list for the bordeaux build farm https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=48e4579f1482a13f19db02cca8386374abdc183f
<rekado>cbaines: thank you!
<UncleRRR>Hi, does anyone know if there is anyway to reset the guix generation number to count from 1? After many times of guix gc -d <duration>, my generation number has gone quite large which I would be more than happy to see that count from 1 instead of incrementing forever!
<the_tubular>Chechkout guix system delete generations
<elb>I don't think that reclaims the generation _numbers_
<elb>it just allows the resources from the old generations to be garbage collected
<dstolfa>2
<dstolfa>oops :)
<simendsjo>I'm packaging a program I only have binaries for. Looks like it has a hardcoded path in an executable, trying to launch /opt/foo/bar, but I have placed bar in /run/privileged/bin/bar. What is a good way to solve this? Is it possible to add a symlink in /opt/foo/bar?
<simendsjo>I'm trying to create a dummy file system for the program using proot, but I get "shopt: progcomp: invalid shell option name". This is correct inside the proot shell, but it's there in my regular shell. Any idea what's going on here?
<podiki>looks like https://ci.guix.gnu.org/eval/1998989 got canceled too? i think that needs to be restarted
<podiki>(i'll do it, but need to figure out why it isn't asking for my certificate...)
<podiki>i started using the arkenfox config for firefox and not sure what the permission is to allow certificate sending to a site
<podiki>wasn't that, just had to import it into my certificates in settings
<PotentialUser-40>My upgrade fails when trying to build a derivation. I am a bit confused by that. Wouldn't this situation happen and be detected on some package building farm or testing event due to the reproducible builds? Or is there some variation on each machine involved?
<podiki>oh but that eval was with the python-pathspec commit that is now reverted. hrm
<podiki>so those should be built on current eval but once again berlin's cuirass isn't doing much building of x86_64
<podiki>can someone give it a gentle nudge if it needs it?
<dariqq>PotentialUser-40: what exactly is failing?
<lechner>Hi, my Guix can no longer guix build -D -f guix.scm It outputs a list of store paths and quits
<lechner>Also, how can it take several minutes to list all my Guix generations?
<lechner>two seconds per generation
<wakyct>lechner what is -D?
<lechner>wakyct / https://bpa.st/RL7A
<dariqq>lechner: isnt this the expected behaviour i.e. that things dont get rebuild if they are already in your store?
<wakyct>thanks I thought that was only for guix shell
<lechner>whoops!
<lechner>dariqq / thanks! I got confused between build and sheell
<vup>anybody else getting `fatal: unable to access 'https://git.savannah.gnu.org/git/guix.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.` ?
<PotentialUser-63>hi there :) anybody knows how to force guile to load a module? I'm really not into asking my tools if they want to work. GUIX is resolving my packages directory files but for lib and utils it keeps telling me that I forgot to import such modules, I even pasted the imported module like 100 times but the interpreter doesnt load it. Pasting the
<PotentialUser-63>contents inside the main configuration file does work so I know this is guile just not wanting to work.
<ieure>PotentialUser-63, Don't think you can "force" Guile to load anything, but if you paste whatever you're doing / errors you're seeing, you might get some help fixing whatever's wrong. May also want to ask in #guile as well.
<PotentialUser-63>Guile is complaining about "guix-bashrc" being unbound (which is false). This only happens when I separate such variable into a module, doing things as a monolith throws no error. I tried changing the directory name but only things inside packages/ and services/ work. It gives me a pretty much useless hint that "I forgot the module"  when clearly,
<PotentialUser-63>guile is in the wrong.
<PotentialUser-63>Did you forget to include `(use-modules (home lib common))'?  I've pasted (home lib common) like a thousand times in the source file. So why is it telling me that I forgot to include it? Can't it do something so simple like telling me where am I messing up? :/ many languages do so.
<ieure>PotentialUser-63, You're going to need to paste your code to get any help.
<PotentialUser-63> https://pastebin.com/T1dpEepy I've used this service to paste my code. The error goes away only if I delete the common.scm file and paste it alongside the srfi module in the main home file.
<PotentialUser-63>there was a mistake I made pasting.  A module in there is "graphics" the correct one is "mail" I deleted the wrong line.
<dariqq>PotentialUser-63: What happens if you put the srfi use-modules in your define-module? with the #:use-module keyword ? (this seems to work for me). But I agree that the error is not really helpful
<dariqq>in your (home lib common)
<PotentialUser-63>I'll try it :)
<dariqq>i think the issue is that you do things before define-module
<PotentialUser-63>whaaaaat!? it worked! 🤯
<PotentialUser-63>please help me being  less ignorant. Do you know why this happens?
<dariqq>PotentialUser-63: Sry, dont know. The guile manual just says that define-module has to be at the top of the file
<PotentialUser-63>I'll read the friendly manual once again then :P
<lfam>Does anyone fail to connect to the Git repo at Savannah?
<freakingpenguin>Yep, mix of 500 errors and SSL errors for me.
<the_tubular>Same
<lfam>Thanks for confirming freakingpenguin. I've mentioned it on #savannah, where the people that can help hang out
<freakingpenguin>All in a days work for your friendly neighborhood penguin.
<lfam>I think I just got through to the Git servers
<lfam>It seems to be up and down
<PotentialUser-40>dariqq I'm sorry, you asked me a while ago what was failing on my system upgrade. I get "builder for `/gnu/store/mbaaq7mw8qflh5wmx0ypmpsnrkwsjy70-python-scipy-1.12.0.drv' failed with exit code 1".
<dariqq>PotentialUser-40: some python stuff got reverted earlier today, maybe it is fixed if you guix pull again (if savannah is fine again)
<lfam>A large number of Python packages were completely broken on the master branch, due to the build failure of the package python-pydevd. We fixed python-pydevd, and now it's possible to attempt building all the dependent packages again. Some may work, some may not
<lechner>Hi, from a reproducibility perspective, it is bad practice to embed store paths in an output, right?
<lfam>Why would that be? Store paths are deterministic and thus reproducible
<lechner>lfam / great!
<lechner>thanks!
<lfam>Unless I misunderstand your question :) But I would consider that okay
<lechner>today is my confused day
<lfam>The reality is that build outputs are stuffed full of store paths
<lfam>That's how the built software finds libraries, etc
<lfam>And a big part of what Guix does is managing that graph of store references
<lechner>yeah, i just realized that. i am deep in the weeks in several levels of shared libraries with Guile-PAM and lost it for a moment
<lechner>weeds
<PotentialUser-40>Thank you, dariqq and lfam.
<lfam>I think that major python upgrades should land very soon. It's the next topic branch due to be merged
<PotentialUser-40>I am glad to hear.
<PotentialUser-40>I can wait. I just was afraid it was "unnoticed" or some sort of bad thing.
<yarl>Hello!
<PotentialUser-40>Please, pardon my ignorance, but I have an idea about GNU and the FSF. Yet, I am afraid I cannot draw a very solid line between them. GNU is a *project*, the FSF is a *foundation* that seems to support GNU, among other things (the GPL? I think that is part of GNU).
<lfam>It's always helpful to mention it PotentialUser-40, even for a major packages like scipy
<lfam>Do you have a question PotentialUser-40?
<PotentialUser-40>I was looking at the results for the survey, posted at the website. In one of the write-in options, linked from the post, I read things like "That its leadership denounced Stallman and the FSF", "100% free software yes, FSF no (FSFE are fine)", "Strong commitment to Free Software priciples (not FSF!)" and I am quite confused about it. Is this some
<PotentialUser-40>RMS hate?
<lfam>GNU is an informal collection of people and projects that don't really coordinate with each other. However, they do have private communication channels where the direction of the overall project can be discussed. In those private areas, there has, for many years, been a lot of disagreement about the direction and leadership of the project
<lfam>Sometimes those disagreements are made public, and that happened a few years ago, with a lot of Guix people making their dissatisfaction known
<lfam>And then there was a big kerfuffle
<lfam>So, some people joined Guix because of this, and some people left. It's reflected in the survey responses
<ieure>Oh, I must have missed the survey responses, where can I find those?
<lfam> https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/
<lfam>Maybe we should put it in the IRC topic
<freakingpenguin>Hehe, wish I remembered some of my responses. It'd be fun to compare.
<lfam>I know that I'm one of the Debian users. The silent majority
<lfam>;)
<ieure>I'm still daily driving Debian for a lot of stuff, until I get around to fixing some QoL issues I'm still having, like lack of autofs service and fixing my xkb setup.
<ieure>I had xkb working properly on Debian, but it was horrible, had to concatenate my stuff onto the end of the system xkb rules, install that as a new file, and point X at it instead of the stock rules. Because there's no rules.d and Xorg can only get pointed at one ruleset. Just awful.
<PotentialUser-40>lfam Do you have an idea when that happened?
<ieure>Not sure how to even approach fixing that in Guix.
<lfam>PotentialUser-40: The nature of the disagreement?
<rekado>ieure: this is what I do for autofs: https://elephly.net/paste/1737146201.scm.html
<ieure>rekado, Yeah.... I've considered that as a stopgap, but then I won't be motivated to make a proper service for it.
<ieure>I have one maybe 80% done.
<lfam>ACTION g2g
<rekado>PotentialUser-40: on the python-team branch there is python-scipy@1.12.0 and lots of fixes and upgrades to Python packages.
<rekado>I hope it will be ready early next week.
<rekado>we are still lacking an overview on just how many broken packages remain, and I'd only like to go ahead with this merge when we are clear on the overall impact.
<freakingpenguin>I'm been getting a "Could not allocate block in ext2 filesystem while writing file db.sqlite" error when building guix vms. Anyone see something similar? I have almost 2TB of space free on /. https://paste.debian.net/1345672/
<freakingpenguin> Sound similar to https://issues.guix.gnu.org/53194 but that says fails to allocate inode.
<podiki>can someone nudge/kick/convince berlin to build? https://ci.guix.gnu.org/eval/1999943?status=pending has been sitting for half a day already
<rekado>podiki: there are hundreds of python-team builds waiting as well.
<podiki>any idea what's up? i've been noticing x86_64 builds waiting a lot (for a few months now?) but i can't be sure when/how different from before
<podiki>still, this seems to be much longer than expected, especially on master which has priority i think
<rekado>I fixed a problem earlier today where a lock file had been blocking updates for the past 48 hours.
<rekado>so I think it's still trying to catch up.
<rekado>the bad commit certainly didn't help
<nathan-web>Hi. In https://guix.gnu.org/manual/en/html_node/Desktop-Services.html it says ```   ;; We need to give the greeter user these permissions, otherwise
<nathan-web>   ;; Sway will crash on launch.
<nathan-web>   (greeter-supplementary-groups (list "video" "input" "seat"))``` But also ```Note that this example will fail if seat group does not exist. ```. What service is meant to provide the `seat` group, or is it meant to be added manually?
<rekado>podiki: the logs say that there have been thousands of builds in the past 24 hours.
<rekado> https://ci.guix.gnu.org/metrics
<podiki>yet the x86 workers are mostly idle
<rekado>yes, weird.
<podiki>processing from db or gc?
<rekado>dunno.
<rekado>unfortunately, I can't investigate now.
<podiki>no worries, thanks for the earlier fix, maybe that will unstick it
<PotentialUser-40>rekado What would be the best way to contact the python-team? I have some questions related to Python packages and tools.
<Deltafire>guix system doesn't use modprobe, as far as I can tell
<Deltafire>yet it adds a modprobe.blacklist to the kernel cmdline
<Deltafire>and has examples in the manual using it