IRC channel logs
2025-03-24.log
back to list of logs
<orahcio>Hello, today I could to compile in a fhs shell the pyenv package for python versions management, and also to install the python 3.12 on thus guix shell, maybe like the conda package on guix, we could have also a pyenv package on official repository. Is there some discussion about that kind of package management inside guix? <coyotes4ys>anyone having problems with torbrowser slowing to an inchworm pace after some minutes of use/ every single session? <Sorsak>Anyone got a Dell latitude with guix on it? Or anyone just happen to know anything about a dell e6420 and trying to get guix on it <Sorsak>Trying to figure why it wont boot from my usb <meaty>it turned out I just had to put the package name at the end of the file <meaty>is there a way to build a package from a channel specified on the command line? <lilyp>ieure: not an exhaustive one, sadly; you can use the emacs-manifest to generate a bunch of failing derivations with the rarely used '-k' switch to guix build <lactose>Is Emacs 30.1 available? Can't seem to find it other than emacs-next which is some prerelease <Rutherther>lactose: It is on emacs-next branch, but there might still be some packages not building, not sure about the exact state <Kabouik>Is there a way with `guix import` to automatically get the use-modules block too? <Kabouik>Okay, thanks. I understand it may not be extremely useful when submitting patches because the .scm files holding all the packages may already have most of the modules, but for individual package files in a private channel, it takes a lot of trials and errors to get the modules right. <futurile>worth creating an issue - with an example - someone might pick it up! <decfed>futurile: is there a calendar with guix social events that one could subscribe to? <futurile>meet-up is better because it sends reminders to you - but it's proprietary service <df>so as a long time debian user, I keep finding myself typing dpkg when I mean guix package <df>would there be any interest in a patch to allow people to use 'gpkg' (and possibly other shortcuts) and if so what would be the best way to implement it (preserving autocompletion) <df>I guess one issue is that there are already a load of shortcuts like 'guix install' so yet another set might be over the top <Rutherther>Doesnt alias solve this? Or does it lack autocompletion? Not sure how it is expanded by the shell specifically <futurile>yeah, in general the cli needs standardising - we already have a lot of different options and confusions - I think there was an intention to do that by someone <df>Rutherther: it lacks autocompletion, at least by default <redacted>df: Can you create a shell function to wrap Guix and attach Guix's completion to that function? I'm not clear on the steps, but I think it's possible. <attila_lendvai_>civodul, i'm trying to run the shepherd tests to add a new one (daemon exits and shepherd doesn't know about it, believes it's running). but i'm getting this from configure: "configure: error: Fibers creates POSIX threads behind our back; aborting." <attila_lendvai>autoreconf -vfi gives: "Can't exec "autopoint": No such file or directory at /gnu/store/7fwpafsh1bf4pfhsaikz3lwp55w2a9w1-autoconf-2.71/share/autoconf/Autom4te/FileUtils.pm line 293." <attila_lendvai>bah, i forgot to invoke `guix shell` (not mentioned in Getting Started) <attila_lendvai>AFAIU the daemon just quits normally. i don't see how it's different than what's tested in respawn.sh <df>redacted: quite possibly, I have no idea :) I'd be up for researching it if I were writing a patch for use by everyone, but I think as futurile says the cli could do with some serious thought <df>I guess the problem is not gratuitously breaking backwards compatibility <df>git is a good example, it has new more intuitive stuff like 'git switch' but still has to support all the old stuff <attila_lendvai>`guix build llvm` prints multiple lines... what shall i use instead of $(guix build llvm)? <attila_lendvai>i solved it as LLVM=$(guix build llvm | sed -n '2p'), but that smells... <servio>Hi, I just installed GUIX and I am learning how to use it, I would like to change the keyboard layout from English to Latin. <servio>I would like to change the keyboard layout from english to latin, any recommendations <servio>Hi, I just installed GUIX and I am learning how to use it, I would like to change the keyboard layout from English to Latam. I would like to change the keyboard layout from english to latin, any recommendations any recommendation please? <Rutherther>servio: depends on where you want to change it at. See the Keyboard-layout field of operating-system in your config for tty. See the same field in set-xorg-configuration for xorg configs <futurile>Quick Note: Guix.social on Wednesday has a talk by Giacomo about self-hosting using OCI / Docker containers - using Forgejo as an example - should be interesting! <futurile>Or on the Meet-up which links from the Wiki <podiki>where are we on ungrafting? i think we need to prioritize that (and base all branches on an ungrafting one), really is a lot of grafts <Rutherther>futurile: to clarify, oci containers managed by guix system config or just generally? <icepic1984>Hey guix! I am trying to packet a software which requires cmake in version > 3.25. However the cmake-build-system uses 3.24.2. Is there a trick to use a new cmake version or do i have to bump the version of cmake-bootstrap in order to build my package? <Rutherther>icepick1984: set the cmake argument to a newer cmake. There is one already in guix. Not sure about the name <podiki>icepic1984: you can specify #:cmake cmake-3.30 in build arguments <Rutherther>servio: so in your set xorg configuration in your config, if you are using that <servio>Rutherther: creo que mejor voy a reinstalar con Xfce u otro WM <ieure>icepic1984, Ooh, I see, the build-system defaults to cmake-minimal, which is 3.24.2. That's kind of confusing. <icepic1984>ieure: afaik cmake-build-system uses cmake-minimal which is older <ieure>icepic1984, podiki has the answer you seek. <podiki>also, i have an fresher cmake-minimal (not default though) on mesa-updates <podiki>welcome! (i had added newer cmake for some projects, so i happen to know) <redacted>Is there a good example of a python package that builds a rust dependency that lives in the same source tree? I've been copying from some packages that blend cargo-build-system and pyproject-build-system, but I know little enough about the build phases of each build system that I'm not sure which phases I should preserve from each system. <Rutherther>redacted: I dont know of such package and havent packaged something like that via Guix. But I am thinking, won't it be easier to first build the rust only in a package and then force the python part to reuse what was built instead of letting it build it? <podiki>CI on berlin hasn't evaluated in 1.5 days if someone can nudge it appropriately <podiki>(hasn't evaluated commits on master at least) <servio>Rutherther: I got it with setxkbmap, I had to install that package. Thanks <simendsjo>I'm writing a complex system service, and the turnaround time for reconfiguring the system is very long. What is an easier way to developing an activation-service-type? <PotentialUser-91>Hello. I just tried the music player gst123 and it does not work for mp3 nor for FLAC files. <PotentialUser-91>I was wondering if the package is broken, it is some significant upstream error or simply my system that has a problem. <identity>PotentialUser-91: it seems to work fine on my end, does it say anything about what assertion fails? <PotentialUser-91>"(gst123:13834): GStreamer-CRITICAL **: 17:26:45.985: gst_element_get_bus: assertion 'GST_IS_ELEMENT (element)' failed" <PotentialUser-91>Actually, before starting to repeat the above, it does say "sh: line 1: tput: command not found" <identity>PotentialUser-91: it does complain about tput for me too, so i don't think that's the problem (though it probably is *a* problem) <PotentialUser-91>I also see "gst_element_get_bus: assertion 'GST_IS_ELEMENT (element)' failed" "gst_bus_set_sync_handler: assertion 'GST_IS_BUS (bus)' failed" "gst_bus_add_watch_full: assertion 'GST_IS_BUS (bus)' failed" and "gst_object_unref: assertion 'object != NULL' failed" <ieure>PotentialUser-91, Just tried, I see the same problem as you. Complains about tput and repeats the GST_IS_ELEMENT stuff. No audio plays. <ieure>Hard to say if this is a package bug, upstream bug, or both. <Rutherther>if you try adding ncurses to your path, ie. guix shell ncurses does it 1. solve tput, 2. solve the assertion? <PotentialUser-91>On one hand, I don't want to be too spammy with the bug reports. But on the other, if no one reports an error, it might never get addressed. <ieure>Rutherther, Does stop the tput error, doesn't stop the assertion errors, doesn't produce any audio. <identity>Rutherther: it does seem to fix the tput complaint, but, again, i don't think that's the root of the problem (it works for me without tput) <ieure>Testing with a FLAC file, since my music library is FLAC. <identity>testing with mp3/ogg vorbis, might be a FLAC-specific problem <Rutherther>identity: I missed that it works for you without tput <PotentialUser-91>I get the same behavior with mp3, ogg and FLAC: just a stream of assertion errors. <ieure>Dug up a MP3, same result, lots of assertion errors, no audio. <efraim>gst123 worked for me, `guix shell -C gst123` didn't, `guix shell -C gst123 gstreamer gst-plugins-good` "worked" but not audio came out (likely needed to share the socket <PotentialUser-91>By the way, one more question: is it still necessary to enter "hash guix" after running "guix pull"? <PotentialUser-91>My tests say that the new guix executable is still found by bash after the pull. <Rutherther>I don't know if it had sense in the past, but definitely not today <PotentialUser-91>Rutherther That is what I thought. It still shows up on the documentation. <identity>Rutherther: Section 4. Getting Started in the manual mentions 'hash guix' <Rutherther>identity: right, there it makes sense, because you've just sourced the profile, that's the reason the hash is done <Rutherther>if you already have the profile sourced, there is no reason to do that <PotentialUser-91>Oh. So you do the hash because of the source, not because of the pull. Got it. <Rutherther>yes, it is because the path from which to take guix changes, but on subsequent pulls it doesn't change, it's always "~/.config/guix/current/bin/guix" (although that is a symlink that will change the target after pull, but I've never encountered shell caching where the link evaluates) <Rutherther>yes, it is because the path from which to take guix changes, but on subsequent pulls it doesn't change, it's always "~/.config/guix/current/bin/guix" (although that is a symlink that will change the target after pull, but I've never encountered shell caching where the link evaluates) <msavoritias>so it seems the operation time-out bug i had a few weeks ago returned on a freshly installed server. guix download works, guix pull does not, guix system reconfigure does not. <podiki>i would just retry, that is likely only related to networking and/or the host, all looks up on my end <podiki>and you can check you can reach that server regularly, e.g. in a browser <msavoritias>podiki i have :) for the past 20 minutes. i also tried restarting <msavoritias>this is reproducible with guix and with other channels btw <podiki>i see you are using static networking so maybe something is misconfigured <msavoritias>i wonder if the nameservers block specific sites. but that doesnt make any sense <futurile>msavoritias: can you install a vpn - tailscale - something that takes the network out of the question? <msavoritias>not right now no. especially because any and all reconfigures fail with <msavoritias>git clone from codeberg also works. but guix pull from codeberg does not <futurile>guix pull failing from both codeberg and GNU seems weird to me <futurile>and you get nothing useful from the guix pull when you try codeberg <ieure>I pulled (from regular Savannah) earlier today. <csantosb>Hi Guix ! I wonder if it is possible to build a package, based on cmake-build-system, using cmake 3.5 instead of the default 3.24.2 <ieure>csantosb, This came up earlier today, "you can specify #:cmake cmake-3.30 in build arguments" <futurile>csantosb: some of the build-system's let you specify the binary you want to use <csantosb>futurile: out of curiosity, where exactly in cmake-build-system.scm may one figure this out ? <futurile>msavoritias: not useful really. I'd at least try removing all those different channels, and just try plain _only_ guix channel first - I don't know why that would make a difference - just trying to simplify <futurile>csantosb: oh you need my build-system notes, uhhh that I haven't published yet. Or have a look in guix/build-system/cmake.scm and build/cmake-build-system.scm <futurile>csantosb: one is the build side, and one is the other side - but I always forget which is which <Rutherther>csantosb: as first 'clue' you can always check out the private-keywords of the build system in guix/build-system/xx.scm (in lower procedure) <csantosb>Ok, thanks, I'll try to study this part of the code <nomike>I'm having an issue running `guix home -L "${PWD}" reconfigure home-config.scm`. It does what it's supposed to do and at the end it get's stuck forever (I had it wait for a few hours already). I'm experiencing this since I started running guix two montsh ago. <futurile>nomike: Hours! And your system isn't loaded with anything else that's deprioritising it? It just sits there? Good logs! <grtcdr>Hey folks! I've got a weird little locale bug on my hand (the usual), this time it's not Guix! I've set up an inferior for Elixir 1.14 and when I run `iex', I get the following error "the VM is running with native name encoding of latin1 [...]", setting LC_ALL to `en_US.UTF-8' causes setlocale to freak out about me not being able to use that locale. I don't have any locale issues with my user, or root. I also don't have any issues <grtcdr>running the latest version of Elixir. <grtcdr>I'd ignore this if it didn't completely break most of iex's useful functionality (like tab-completion for example). <moksh>So whenever I close my laptop lid or whatever its called, my machine goes into deep sleep or hiberation (I am not sure what it is <grtcdr>I have essentially scoured the internet and tried all sorts of "fixes", but I can never get that error to go away. I even tried installing the version of `glibc-locales' made available through that same inferior (so 2.35), thinking that an old version of Elixir must have been compiled against a very old glibc. <moksh>How can I debug this, is this related to guix or the de I am using i.e XFCE <grtcdr>OH WOW! All I had to do was install guix-locales-2.35 for my user (so outside guix shell) <grtcdr>I no longer get that annoying warning, gonna see if tab completion works now :D <grtcdr>Thanks, I was getting a bit scared that it wasn't going to work. <grtcdr>Makes me think glibc is probably hurting backwards compatibility (at least it doesn't make it easier), but what do I know. <RavenJoad>I have a locked manifest with Python packages where pandas does not work. "ValueError: numpy.dtype size changed, may indicate binary incompatibility. Expected 96 from C header, got 88 from PyObject". I'm using guix time-travel to Guix commit 5bf7d80535720077aec104a9904480d08b9b4f2b. I don't see any recent changes to Guix that would make this happen (This manifest worked last week.). <grtcdr>Dang it, auto-completion isn't working, what does Elixir want from me now? <RavenJoad>Oh. It's because I specified python-numpy in my manifest.scm as well. Curious how those two are not lining up... <Rutherther>untrusem: sleep on lid close is default option of elogind. Are you using elogind? and if so, lookup its options in elogind-configuration, it has option handle-lid-switch (also -docked and -external-power) <grtcdr>untrusem: To be brutally honest, I'm starting to believe that. <grtcdr>I'm going to undo the mess I made with locales, I'll be right back. <untrusem`>Rutherther: the thing is I don't mind sleep on lid close, but it just won't open after it. <Rutherther>untrusem: that happens sometimes for some laptops, probably better to search based on your model <Rutherther>or look in dmesg if it has something interesting <orahcio>Hello, guix has some way to print to a pdf file? I could not find cups-pdf. <acrow>orahcio: If you've installed cups you can probably just say lpr <my.pdf> <acrow>Having created a guix system container on a PID is there a polite way to shut it down? <orahcio>acrow: l have cups service, I need also the cups package? <acrow>orahcio: I don't recall where lpr resides... I think the service provides what you need... but I could be mistaken.. Did you give it a try? <orahcio>I couldo not find lpr on terminal just with cups service, I am installing the cups package to see what happen, but I need to print a web page into a pdf file <acrow>orahcio: My lpr is in cups-minimal, so you may need to install that package as well. <orahcio>acrow: Now I see, lpr send a document to the printer, I want a pdf printer which print any documents as a pdf file, I think the cups-pdf can do it, but guix has no cups-pdf <orahcio>acrow: Thank you for your help. I think we need to wait for the cups-pdf on guix repository <futurile>orahcio: you're trying to *create* a pdf document from some other document? So open-office and tell it to export as pdf? <futurile>orahcio: e.g print a text document -> convert to pdf ? <orahcio>hi futurile, openoffice can concert document to pdf, but I want to print a webpage directly from qutebrowser for example. like ctrl+p -> print to pdf file <orahcio>futurile: Thanks, I could do that now with firefox. Maybe qutebrowser have some issue about print to pdf