IRC channel logs

<nomike>identity, I've looked through the info page back and forth but there is no mention of a CLI client at all. I assume I have an outdated version or something? (I'm on Ubuntu 24.10 foreign distro btw.).

<nomike>But thanks nontheless for the hint.

<identity>nomike: then see <https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html#Command_002dLine-Interface>

<nomike>I think itś outdated due to the info page coming from the 1.4.0 release debian package, which is over 2 years old.

<nomike>But thanks, the link works of course.

<istrabalagina>i wrote a question on the devel mailing list that did not arrive to the archive yet, but i think i have a proper solution to it now

<istrabalagina>i wonder how long an email takes before it arrives to the archive

<istrabalagina>the question was about writing texinfo documentation for package definitions whose source is not mine, but the package definition was written by me. the solution i thought of was just writing an extra package definition foo-manual and put it in the inputs of package definition foo

<istrabalagina>now i just need to actually write the texinfo / skibilo source

<nomike>We have version 7.6.2 of opencascade-occt in guix. It is a dependency of prusa-slicer, which I'm trying to upgrade. The issue is, that the folks at Prusa downgraded opencascade-occt from 7.6.2 to 7.6.1 stating that the "newer versions are triangulating chamfers incorrectly.".

<nomike>I assume just downgrading that library on our end isn't a good solution, or is it?

<nomike>Dependencies on opencascade-occt currently are: freecad@1.0.0 prusa-slicer@2.7.4 librepcb@1.2.0 kicad@9.0.0 f3d@3.0.0 openfoam-com@2212 openfoam-org@10.20230119 python-pygmsh@7.1.17

<identity>nomike: maybe create a prusa-slicer-7.6.2 package?

<identity>err, .1

<identity>or rather opencascade-occt-7.6.1

<nomike>Yes. that's what I wanted to get at and would have been my next question.

<identity>ACTION should probably go get some sleep now

<nomike>But when I do that, what's the convention for the variable name? I found nothing in the docs about that. But maybe that's just too specific.

<nomike>identity, sweet dreams! And thanks a lot!

<ieure>nomike, opencascade-occt-7.6.1 or opencascade-occt-for-prusa-slicer.

<nomike>ieure, thanks

<evan>Hi all, I don't know if anyone has seen this yet, so I'd just like to bring some attention to this patch: https://issues.guix.gnu.org/77251. It solves 3 open issues (https://issues.guix.gnu.org/68561, https://issues.guix.gnu.org/61379, and https://issues.guix.gnu.org/77487). It's important to get this merged because when 1.4 million symlinks are being created on every version of the profile it causes huge slowness on every package operation and quicky eats up inode

<evan>s. I know first hand how frustrating that can be because I used to use guix and quit because of the issues I now know were caused by this issue. And a regular user who isn't super familiar with the internals of guix would have no idea how to fix it. I only identified the issue several months after the fact with the help of a guix wizard. It's important to iron this issue out so that nobody will have to deal with the same frustration me and other users had to deal w

<evan>ith. Thanks for your time, everyone.

<meaty>Are there any facilities available for installing shell completions? e.g. something like a 'shell-completion-data' table with common shells and completion prefixes

<ieure>meaty, For packaging stuff with programmable completoin?

<ieure>*completion

<meaty>yes i think

<ieure>meaty, See the bat package for an example. Including the bundled completion files into the package output is all you need to do, they'll get picked up when Guix builds the profile containing the package.

<meaty>roger

<hako>You can search 'install-extras' phases for more examples. Copying is not usually the case.

<hako>Some code to deduplicate the logic can be written, adding in (guix build utils) maybe

<nomike>`git checkout master && git pull && ./pre-inst-env guix build nano # or any other package` currently produces this: https://paste.debian.net/1369864/ I think somebody did an oopsie...

<ieure>nomike, Your build environment is stale, `make clean && ./bootstrap && ./configure && make -j8', then retry.

<ieure>(substitute some reasonable number of parallel makes to spawn for "8")

<ieure>Also, are you in a `guix shell -m manifest --pure' when running that?

<krepalakh>wrote a package definition for the topological sorting SRFI-234 https://issues.guix.gnu.org/77818

<peanuts>"SRFI 234: Topological Sorting" https://srfi.schemers.org/srfi-234/srfi-234.html

<krepalakh>and now editing the SRFI document into Org-Mode so i can export it into an Info file

<krepalakh> https://codeberg.org/flamebovine/guile-srfi-234-manual

<peanuts>"SRFI 234: Topological Sorting" https://srfi.schemers.org/srfi-234/srfi-234.html

<krepalakh>the lengths to which i go so i will not have to learn Texinfo ~;~

<krepalakh>would have used skribilo if it was on my computer, but i am on a phone

<krepalakh>and termux does not have ANYTHING

<PotentialUser-88>I see its now possible to use the guix-daemon rootless, but the installer still requires root, will it be possible to setup Guix without root access in the "near" future ?

<PotentialUser-88>like setup a user-only store in for example ~/.local/gnu/store

<apteryx>hm. I've lost all my toolbox/dialog in gimp and can't figure out how to have them reset

<apteryx>that's with the shiny new gimp 3

<apteryx>choosing 'windows -> toolbox' does nothing (it's not shown)

<apteryx>hm, 'Preferences -> Reinitialize' did it

<civodul>Hello Guix!

<user_oreloznog_>\o

<nckxv2>sneek: later tell istrabalagina: For the first message of any new address to each mailing list, the answer is 'whenever nckx gets around to their ~daily moderation purge'.

<sneek>Got it.

<nckxv2>sneeck: have this botsnack I found stuck under my car seat.

<nckxv2>Drat.

<jonsger>does someone know how to pay the Guix Foundation membership fee? Is it possible to pay it via SEPA to the new bank account? I don't know it's IBAN...

<nckxv2>jonsger: It's 'not a real bank' last I recall so best talk directly to Tanguy. I think you can transfer euros just fine, without triggering the authorities, but better to ask first.

<hanker>Is there a transform that _adds_ a package to the dependencies of another?

<meaty>How can I test that a package's shell completions work correctly? just 'guix shell $package' doesn't do it

<PotentialUser-93>why when I do a `guix remove <pkg>` it starts downloading from substitute etc., why it just doesnt remove the entry from the store or from the profile ?

<hako>It's transactional, you'll need the new profile ready first, and then switch from the old profile.

<PotentialUser-93>I am not sure to understand, its simply removing an element from the store, why still need to download things ? I dont understand what it has to "add" to remove something

<identity>PotentialUser-93: it doesn't remove anything from the store, it just removes it from the environment. it's still in the store, and you can rollback the change with guix package --roll-back

<PotentialUser-93>then even more, why isnt it instantaneous ? just need to remove the link from the profile

<identity>it is not just "remove a link from the profile", it is "make a new profile with a package removed"

<PotentialUser-93>but so everything should already be there locally, why need to download to "make a new profile with a package removed" ? my package here as a test is a simple hello world c binary

<civodul>friends, it’s that time of the day when Savannah is 502

<civodul>i wonder how many people are still pulling from it at this point

<dthompson>🙏 RIP savannah

<lockbox____>Do we point to codeberg in the manual yet?

<PotentialUser-93>how long does a guix pull take for you all ?

<PotentialUser-93>with guix and nonguix it takes at least ~8-12 minutes, but on the mailing list I see some it only takes 50 seconds, how is that possible ?

<civodul>lockbox____: not in the manual no; it was announced on info-guix

<civodul>PotentialUser-93: duration depends on how far you need to travel, so to speak; it typically takes ~5mn on my laptop, running it roughly once a week, sometimes up to 20mn or so if I’m unlucky and the target revision hasn’t been built on the build farm

<PotentialUser-93>I see, I guess once a week is okay xD

<acrow>Just curious -- is the daily savannah load cycle just bc more users do their pulling at this particular time of day or does it have more to do with the activity of the bad-faith community?

<PotentialUser-93>I just switched from savannah to `https://codeberg.org/guix/guix-mirror`

<rynn>acrow: Bad-faith community?

<futurile>afternoon all, hope you've all got great guix easter holiday plans ;-)

<acrow>rynn: eg.. AI-scrapers, DOS attackers, others lacking an ethical compass.

<rynn>Ohh, gotcha

<vagrantc>hrm. shepherd 1.0.4 failing to build on aarch64-linux ... tests/pid-file is failing

<untrusem2>whats your keyring setup for guix, folks?

<vagrantc>interesting, shepherd 1.0.3 also fails to build on this same machine ... does shepherd have an issue with /tmp using tmpfs ?

<untrusem2>has anybody switched to https://lix.systems on guix os

<vagrantc>building shepherd with tmpfs on /tmp on x86_64-linux seems fine ... hrm.

<untrusem>ohh read about the migration to codeberg

<vagrantc>untrusem2: what keyring are you referring to?

<untrusem>sytem keyring

<untrusem>I am using keepassxc as my password keyring

<vagrantc>ah. i was wondering about the keyring used by guix pull ... but yeah, do not use such a keyring

<untrusem>you mean, you don't use a password keyring?

<vagrantc>not on guix ... i use pass on debian

<vagrantc>a.k.a. password-store

<untrusem2>I see, I am using some application like fractal for matrix and gajim for xmpp and the require you use a keyring

<ieure>`guix pull' doesn't use a keyring, in nearly every case, the repos are public.

<vagrantc>so that keyring branch it uses... is not a keyring? :)

<vagrantc>so, the shepherd test failure is https://paste.debian.net/1370001

<vagrantc>guess this is bug report material

<vagrantc>always perplexed why my system configuration needs to build inkscape twice ... at the same version ... my wild guess is there are several inkscape variants and different other packages depend on different inkscape variants? kind of expensive to build, let alone build it twice

<singpolyma>Yeah inkscape is the reason I can't use guix in my kids' computer. Would take weeks to compile

<singpolyma>They don't even use it just everything seems to depend on it

<vagrantc>to generate some icon or something

<vagrantc>most of the time there arre substitutes available, so only get burned by it episodically

<vagrantc>ah, it is presumably the hidden inkscape/pinned vs. inkscape package

<vagrantc>surprisingly few references to inkscape of either variant ... so clearly somewhere low on the dependency graph

<vagrantc>after all those builds, did not expect shepherd to be blocking me from a system reconfigure

<vagrantc>ACTION tries to figure out how to specify an older shepherd variant

<ennoausberlin>Hello. I try to build a qcow2 image for aarch64 but somehow I get guix system: error: EFI bootloader required with GPT partitioning when I try to build it

<yelninei>vagrantc: there is a snippet in the shepherd README with how you can replace your pid1

<vagrantc>yelninei: thanks!

<ennoausberlin>I use grub-efi-bootloader and set the boot flag in my config

<yelninei>the snippet is for testing the shepherd from git but you can just replace that with your own variant that e.g skips tests

<ennoausberlin>I had to set the partition-table-type to 'gpt. Now it at least starts building. Will see the outcome

<vagrantc>yelninei: hrm. i am struggling to figure out how to add that snippet

<yelninei>vagrantc: essential-services is a field in the operating-system record (like the services field your probably already have)

<yelninei>or could you be more specific what you are having problems with exactly

<untrusem2>is there a sdk manager in guix

<untrusem2>I want to compile and bulid a android apk

<untrusem2>not sdk manager but android-sdbk

<untrusem2>android-sdk*

<ieure>untrusem2, There are some Android dev tools, but they're out of date.

<untrusem2>I see

<yelninei>vagrantc: something like this should work (this is ontop of one of the os examples in guix) https://paste.debian.net/1370007/

<\a>ieure: Some android dev tools, but no android sdk

<\a>untrusem2: I recommend using debootstrap to create a debian bullseye (it was removed in bookworm) chroot and using the android sdk packaged there. Note that it is quite an old version (for android 6.0), but there don't seem to be any free builds of newer versions (google binaries are nonfree) unless you want to build it yourself.

<\a>The problem with building it yourself are the insane build requirements (64GB RAM, 250GB disk space)

<\a>s/are/is/

<\a>debootstrap is packaged in guix

<untrusem2>huh, I don't want to build the android studio

<untrusem2>specifically i want to build this app https://codeberg.org/prav/prav

<gcarlos>Hi guix! I was trying to cross-compile things with gcc-cross-i686-w64-mingw32-toolchain and I've noticed that the plain `i686-w64-mingw32-gcc main.c` give me a lot of errors of libraries not found. Further investigating, it seems that the /gnu/store/...gcc-cross.../lib path is not searched for libraries, and that setting CROSS_LIBRARY_PATH accordingly makes compilation work. It raised me a question:

<gcarlos>is there intended or there is something tha could be configured in the package actually look at this path by default?

<ruther`>gcarlos: how are you trying to build? in a shell? You should have this env var set automatically.

<gcarlos>ruther`: yeah, I've just `guix shell gcc-cross-i686-w64-mingw32-toolchain`

<gcarlos>ruther`: then `env | grep CROSS` returns nothing

<ruther`>gcarlos: Indeed. The package doesn't have the search path. Seems wrong.

<ruther`> https://issues.guix.gnu.org/68058

<gcarlos>ruther`: ahh, thank you for figuring out the issue. It seems to be stalled tho

<gcarlos>ruther`: I was pretending to send a patch to use mingw cross compiler for wine but I think it's better to wait this issue to be fixed

<vagrantc>yelninei: getting error: options->transformation: unbound variable ... but i have (use-module (guix transformations)) which claims to export that variable

<yelninei>vagrantc: not sure, what happens if you try to evaluate your config with guile directly (instead of guix)

<vagrantc>ACTION blinks dumbfoundedly

<vagrantc>i am able to actually build with shepherd-0.10 at least

<vagrantc>(which has substitutes)

<vagrantc>apparently my initial problem was putting (essential-services ... before ... (services

<yelninei>great. maybe you could try a more normal variant instead of inlining a transformation but idk

<vagrantc>hrmpf. fails to build various things with the older shepherd

<vagrantc>e.g. shepherd-log-rotation, shepherd-timer, etc ... things i think depend on newer shepherd

<vagrantc>yelninei: yeah, that was my next attempt

<vagrantc>guess i could spend all day on that... or do something else :(

<vagrantc>guess i had best better report the build failure, as i seem hopelessly unable to workaroudn it

<csantosb>lilyp: Related to emacs packaging, do we privilege git-fetch over file url-fetch from elpa or equivalent ?

<lilyp>same rules as elsewhere: prefer designated upstreams unless it's really inconvenient

<csantosb>I remember reading somewhere that git fetching has advantages in guix, but maybe I'm wrong

<lilyp>in 77836, it currently appears inconvenient thanks to missing tests

<lilyp>if we find that those tests can't be run anyway, there's no harm with using elpa

<untrusem>eventually i ssh'd into my artix linux and built the app there

<csantosb>lilyp: Ok, so we keep elpa unless we have a reason not to

<lilyp>yep

<vagrantc>eesh. simplified shepherd definition by manually cutting and pasting the labrynth of inherrited packages and condensing down to a single (arguments definition...

<vagrantc>so worked around, but still boviously better to fix the tests :)

<ieure>ELPA upstreams suck for reproducability, MELPA deletes old package versions and GNU ELPA renames the file (current version is .tar, older versions are .tar.lz, the current gets renamed when a new one is uploaded).

<ieure>There are mirrors and whatnot, but, those don't always catch things. I have fixed packages where the build broke because the M/ELPA upstream vanished and there was no mirror.

<ieure>I don't think it's worth going through every package to change them, but I really think we should push to have non-ELPA upstreams for new packages.

<csantosb>In the case of #77836, upstream github.com/lewang/ws-butler is obsolete

<peanuts>"[PATCH emacs-team] gnu: emacs-ws-butler: Update to 1.3." https://issues.guix.gnu.org/77836

<csantosb>Development happens in a dedicated branch in git.savannah.gnu.org/git/emacs/nongnu.git

<csantosb>Since 0.7

<nomike>I'm in a local clone of guix. When I run `./pre-inst-env guix lint foo` I'm getting: "guix: lint: command not found\nhint: Did you mean `lint'?". Probably I'm not supposed to run `guix lint` in my foreign shell like that and should run `guix shell` fist, but nonetheless, the error message is confusing and should maybe be improved.

<nomike>Should I file this as a bug?

<csantosb>You have to "guix shell -D guix" first, that's correct

<csantosb>pre-inst-env is useful solely with a shell

<csantosb>s/with/within

<vagrantc>well, now shepherd builds fine after booting into a system with a shepherd built with tests disabled.

<vagrantc>ACTION shrugs, squints, and holds back tiny little tears

<nomike>Yes. But if newbies run that command and get that error message, it will be very confusing I guess.

<nomike>And with running this under `guix shell` I'm having an issue at the moment, but I wanted to not mix those two topics up.

<vagrantc>yeah, using pre-inst-env on a foreign distro is ... troublesome

<vagrantc>lots of weird, confusing ways it can go wrong

<nomike>Maybe pre-inst-env could detect this somehow and issue a warning?

<nomike>I've submitted a patch for this.

<nomike>But another issue I have is this: I've been using `guix shell -D guix --pure` for a while now, as is written in the documentation of the latest release.

<nomike>But since then I have learned that there is newer documentation from the devel branch which recommends using `guix shell -D guix -CPW`. But when I do that and run `./pre-inst-env guix lint nano` for example I'm getting a bunch of DNS related errors. Like e.g.:

<nomike>gnu/packages/text-editors.scm:1014:15: nano@8.4: URI https://www.nano-editor.org/ domain not found: Servname not supported for ai_socktype

<nomike>What am I missing here?

<vagrantc>i wish people would use the longhand option names in documentation. :(

<vagrantc>nomike: i think you need --network

<identity>i wish there weren't shorthand option names...

<vagrantc>identity: that too :)

<orahcio>Hi,

<nomike>What's even more annoying is stuff like this: openssl s_client -connect example.com:443 -servername example.com

<vagrantc>"guix shell --development guix --container --link-profile --nesting --network" ... while some maybe not immediately obvious ... is at least a bit more likely to have a useful guess

<nomike>That's sooo much better. I have a good idea about what's happening here without having to look at man- or info-pages or dig through pages of --help output.

<vagrantc>also searching for single-letter options is much harder

<nomike>true

IRC channel logs

2025-04-17.log