IRC channel logs

<reyman>I have some problem with stub and typed packages in python, i apply similar packaging from other types-xxx packages in python-xyz, but that fails in my channel with a ValueError: invalid pyproject.toml config: `tool.setuptools.package-data`

<reyman>any tip for this type_*** package and python-setuptools ?

<reyman>for example types_webencodings-0.6.0.20260827

<reyman>the spec returned by guix import pipy -r types_webencodings don't compile

<apteryx>jlicht: o/

<untrusem>reyman, you might need to add python-setuptools in native-inputs

<reyman>this is the case untrusem

<untrusem>can you share your package defination

<untrusem> https://bpa.st

<reyman>yep i share that

<untrusem>^ here is a pastebin

<reyman> https://bpa.st/FRWWE

<reyman>this is the module i try to build

<reyman>guix build python-papis

<reyman>-L . python-papis

<untrusem>reyman, you will need to add a phase to include setup files

<untrusem> https://setuptools.pypa.io/en/latest/userguide/datafiles.html

<untrusem>search for `tool.setuptools.package-data` in guix repo

<untrusem>and you shall find such cases and adapt it

<untrusem>what helps in these cases is `guix build -K -L . <package>` -K will keep build tree in `/tmp` folder and you can go check it

<untrusem>also when you find the similar cases in guix repo, visit their repo and see what the phase is actually changing the codebase, it will make adapting it for your phases a lot easier

<reyman>thanks untrusem, i will look on this path

<reyman>into pyproject.toml of type_pygments, the "include-package-data = false", so i probably need to patch

<reyman>something that i don't understand untrusem, for example type_dateutils into python-xyz is a stub, with pyproject.toml declarated in the same form than webencodings, and it works without patch of .toml

<reyman>python-types-python-dateutil more exactly

<reyman>contain the same form of [tool.setuptools.package-data] in guix python-xyz.scm, this is very strange

<mwette> di

<mskiptr>=guix shell= is so good that I can't live without it! I've recently installed Guix on my $foreign_distro main laptop just to have it available there too. However, I'm being bombarded with hints to install =glibc-locales= which is kinda annoying. (Do they even matter in Guix shell containers?) I do not want to use or manage any profiles for my user where I could install this package, so is there some other clean solution to this locale

<mskiptr>problem?

<stallman1>hello #guix does anybody know if there is a meta-package for Gnu Development

<untrusem>gnu development?

<untrusem>can you elaborate?

<mskiptr>as in "development of GNU software"?

<stallman1>well not development but building specifically

<stallman1>like glibc gcc and so forth

<stallman1>make

<stallman1>binutils

<stallman1>the essentials

<mskiptr>I beliebe gnu-build-system provides those typically

<stallman1>ah that must be the one thank you

<stallman1>non-existent

<mskiptr>it's not a package tho

<mskiptr>so yeah

<stallman1>gcc --version

<stallman1>bash: gcc: command not found

<ieure>stallman1, Write a manifest with everything you need, then `guix shell -m manifest.scm' to get a subshell with everything.

<ieure>Guix doesn't really have metapackages like Debian etc.

<stallman1>okay

<ieure>You could make one, if you really wanted, but a manifest is the right way to do this.

<stallman1>I don't really want a container, I want it installed

<ieure>Manifests are not containers.

<stallman1>so I guess Ill just install it manually

<untrusem>guix package -m manifest.scm then

<ieure>And yes, you can install packages from a manifest, too.

<mskiptr>See the "Build Systems" chapter of the Guix info manual. It explains how more-or-less that gnu-build-system pulls in the typicall depenencies.

<stallman1>okay thank you I will do that

<ieure>Guix lets you run stuff without installing it, it's a pretty good way to do stuff.

<untrusem>I use my emacs in guix shell

<untrusem>:P

<stallman1>thats cool

<untrusem>ieure: see this

<stallman1>I was wondering if we could have multiple versions, for example, of firefox

<untrusem> https://codeberg.org/coopi/emacs-guisel

<stallman1>but I understand it would have to be packaged basically

<untrusem>one of my friend made guix emacs package manager

<stallman1>so it's a little misleading to say, we can simply rollback, unless guix actually maintains older software

<stallman1>luckily guix has firefox 140

<untrusem>you can definately have older version

<stallman1>before they introduced AI, in version 141

<ieure>stallman1, You can't install multiple Firefox versions, because the paths clash. But since you don't need to install them to run them, you can easily `guix shell firefox@154 -- firefox' and `guix shell firefox@153 -- firefox' etc.

<stallman1>I think it's important, to maintain firefox 140

<ieure>Well, Firefox isn't in Guix at all.

<stallman1>so that is a capability that will be lost to many people, running standard distributions, and update cycles

<ieure>Is 140 a pre-slop version?

<stallman1>its just before they released AI into 141

<stallman1>you can see it's release notes, it's prominently at the top

<stallman1>so guix has icecat 140

<stallman1>debian bullseye has firefox-esr 140

<stallman1>and that's the end of the road for firefox, it's my understanding

<stallman1>It will probably help people, to have 140, for maybe 5-10 years, until mainstream websites start explictly banning it

<stallman1>right now they can get away with firefox 132-135

<ieure>Well, again, Firefox isn't in Guix and can't be.

<stallman1>or their bank/email will ban them

<stallman1>yes its icecat...

<stallman1>firefox-icecat

<ieure>You can use LibreWolf, it has the AI features permanently disabled. But obviously there's slop in the code. But there's slop in the Linux kernel now, so, yeah.

<ieure>Dire times for the slop objectors.

<ieure>(I am a slop objector)

<stallman1>well I just thought I'd share it with you guys...

<stallman1>but I hope you realize, that systems operate in parallel, based on the local systems operations (through for example firefox-icecat/libreworld

<stallman1>librewolf*

<stallman1>AI systems

<ieure>No idea what you're talking about.

<untrusem>time to ramp up hurd dev

<stallman1>so in other words, people are still interacting with remote AI, despite choosing firefox 140

<stallman1>very confused old people contemporarily

<stallman1>systems operate in parallel to each other in time

<stallman1>so while you control your local system, and do the best you can, to maintain autonomy

<stallman1>remote systems, simultaneously, operate, relative to the local system

<stallman1>its called the matrix

<stallman1>at least since 1999

<ieure>ohhhhh kay

<stallman1>(ive got it on blueray)

<ieure>I saw it in the theater.

<stallman1>which is your, favorite matrix movie...

<untrusem>#guix-offtopic :P

<stallman1>local behavior, will alter the behavior, on remote systems, in real time.

<stallman1>they are all connected

<mskiptr>btw, librewolf is a closely tracking fork, right?

<mskiptr>(as in, it aims to keep up with any upstream updates but patch out undesirable behavior)

<stallman1>I've got a Gnu/Linux TV actually

<stallman1>with streaming services that recommend, subject matter relative, to contemporary events

<ieure>mskiptr, It tracks the Firefox rapid release channel and there is no ESR.

<stallman1>that's AI

<ieure>stallman1, Take it to #guix-offtopic or another channel, please.

<stallman1>alright well it was just an aside briefly...

<ieure>mskiptr, And yes, it disables most of the Firefox antifeatures, the Guix package disables some other stuff (ex. Widevine).

<stallman1>you guys seemed confused, so I thought I would help you.

<mskiptr>oh, nice!

<ieure>Honestly, wish LibreWolf tracked ESRs.

<ieure>I have considered making a fake ESR version, just using the LW release for whatever became the ESR and swapping out the new release under that.

<folaht>Hey there, I'm unable to start my display manager when I want to reconfigure my guix system

<folaht> https://forum.systemcrafters.net/t/unable-to-reconfigure-my-system-anymore-gdm-hangs/2105

<folaht>when I want to -> whenever I

<mskiptr>do the contents of =/var/log/gdm/greeter.log= offer any hints?

<ieure>folaht, FWIW, I reconfigured a machine yesterday (commit 4c863218967e6372127bc38a750991bd6d7843d6) and I am able to log into both GNOME and EXWM using GDM.

<folaht>mskiptr, it contains several errors. Would it be best to delete in and reboot?

<yelninei>folaht: Do you have gnome-desktop-service-type ?

<folaht>yelninei, xfce-desktop-service-type

<folaht>I'll reboot normal and reconfigured and see what errors I'll get.

<yelninei>folaht: There is an open issue that the new gdm does not work without gnome-service

<folaht>Ahhhh....

<folaht>That explains it then

<yelninei> https://codeberg.org/guix/guix/issues/10929

<folaht>I'll wait for the problem to resolve then.

<sham1>Is it safe to pull today or will everything break

<ieure>sham1, I reconfigured a machine yesterday, commit 4c863218967e6372127bc38a750991bd6d7843d6, everything seems to work for me.

<mskiptr>does anyone know why --with-version= completely falls apart for libfprint?

<ieure>No updater for it?

<mskiptr>even bumping it from 1.94.5 to .6 gives me =| 'validate-runpath' phasebuilder for `/gnu/store/hjfqvridnkmav31isgi9az8g2hiymsan-libfprint-1.94.6.drv' failed with exit code 1= right away

<mskiptr>the buid log contains a ton of lines like =find-files: /gnu/store/vg0bmh98kwgksb53fad4hj6hb96zixwz-meson-1.9.0/sgml: No such file or directory=

<mskiptr>is that common with Meson/CMake?

<yelninei>this is unrelateded and harmless

<ieure>mskiptr, Sounds like the package update has added stuff which the current Guix package recipe doesn't handle.

<ieure>mskiptr, Sounds to me like the actual update succeeded, but the build of that update is failing, right?

<mskiptr>yelninei: ah, good to know

<mskiptr>ieure: by "actual update" do you mean downloading the sources?

<yelninei>mskiptr: "-libfprint-1.94.6/libexec/installed-tests/libfprint-2/test-fpi-device: error: depends on 'libfprint-2.so.2', which cannot be found in RUNPATH"

<mskiptr>yelninei: Are all the warning and errors up to that point entirely harmless then?

<ieure>mskiptr, "Actual update" = editing the package definition in Guix.

<mskiptr>ieure: right now I'm trying to just get it in a guix shell

<mskiptr>including it in my operating-system turned out too difficult for me when I last tried it (a few months ago)

<yelninei>mskiptr: There is a configure option to not install the installed-tests, I dont know what they are and if they are neded for something. If you need them youd need to find out how they are built and why they dont have have the correct RUNPATH

<mskiptr>yelninei: would the --without-tests package transformation be equivalent to that?

<mskiptr>I guess not – with it it fails in the exact same way

<ieure>mskiptr, The problem here is the same. `guix shell --with-version' points the existing package at the new upstream source; if the upstream source has changed in a way the package for the current version doesn't know about, the package may fail to build or not work. This is what you're seeing.

<sham1>ieure: alright, I think it should be fine then

<mskiptr>right. I was hoping these errors are something common with updates to certain packages and that there may be some easy work around

<ieure>mskiptr, No, --without-tests transforms the package so tests aren't run, it does not change the configure options.

<ieure>mskiptr, The general problem is common, the specific problem is specific to that package, neither can be addressed with automation (I guess you could use an LLM, but, gross).

<mskiptr>Yeah. It does look like package-specific rabbit hole. I guess I will have to leave this be for now and revisit it once some newer version lands in Guix.

<ieure>You could send a patch to update the package.

<mskiptr>in case anybody's curious: I was trying to test an MR against {lib,}fprint{,d} which would hopefully make the fingerprint reader in my laptop not suck. The patches do not apply on the version currently packaged in Guix tho.

<mskiptr>ieure: I would love to, but I don't expect myself to find a fix in any reasonable time

<mskiptr>I'm still too inexperienced in Guix packaging I guess

<ieure>mskiptr, Well, you gotta get the experience somewhere.

<mskiptr>true – though I think I have better chances with build systems I actualy know how to use

IRC channel logs

2026-08-31.log