IRC channel logs
2024-03-05.log
back to list of logs
<qecep>is it normal for guix refresh to to run a whole 10 hours? and it's just for listing, it doesn't actually upgrade anything right? <bdju>why is my ping command missing the -6 option? <bdju>ah I have a ping6 command <Altadil>Hi, I tried adding the plasma-destkop service but I get a build failure for plasma-desktop-5.27.7.drv. Should I report this ? It is a test failing according to the build log. <thaenz>Hello, Is there a package that provides git-prompt.sh? <mgd>Hello all. I'm trying out Guix after using Arch Linux for a few years. The install went well but the `guix pull` command is painfully slow. I've seen this was an issue a few years ago on Reddit but I was wondering if this is still an issue? <hapst3r>mgd: if you installed from the original image and this is your first pull, that's expected <hapst3r>Because AFAIK `guix pull` resolves ALL differences between your Version of guix and the current one in order to ascertain what needs to be changed for guix to be up to date. <hapst3r>Later pulls will be quicker though the "ascertaining differences" step will always take some time. <mgd>hapst3r Yes, I expected this but the same happens every time I try to install something. I left the `pull` command over night and tried to install nyxt this morning <mgd>I did in the TUI installer. I'm guessing I can check for this in one of the config files? <mgd>Also, I plan to use EXWM but I noticed that the installed added gnome as well. is this for any reason? I may try a manual install later and see if I can just use a .xinitrc <thaenz>mgd: Idk where to check for substitutes other than I used `guix weather <somepackage>` and it told me I had no authorized keys so it compiled everything instead because of a typo in my config <mgd>thaenz No worries, thanks for your help. Back to the docs for me then :) <thaenz>Also check your /etc/guix/acl maybe, I think you should have about 20-30 lines of scm in there <jpoiret>hapst3r: `guix pull` doesn't "resolve differences", it just builds guix from scratch at a new commit <jpoiret>the only differential part is updating your git checkout of guix, but that's usually much faster than the "Computing derivation" step. <hapst3r>@jpoiret thanks for the differentiation! <hapst3r>jpoiret: But this does not explain why the first pull takes ages in comparison to all later pulls. Why is this? <jpoiret>well, maybe checking out the whole Guix repository was slow for you <jpoiret>it's been a while since I've had to check it out from scratch <Altadil>jpoiret: hapst3r: There is also the part where guix pull authenticates every commit. Wouldn’t it explain the slow first pull ? Since there are many commits since the installer was made. <jpoiret>Altadil: when you install guix using the installer, you don't have the local Guix checkout in .cache/guix/checkouts/ so it's not even "since the installer was made", it's since the introduction commit <jpoiret>but I would guess that it's slower to clone the git repo than to authenticate <civodul>jpoiret: it’s since the installer was made :-) <jpoiret>civodul: not on the installed system? <civodul>the ‘guix’ binary knows its provenance, so it starts authentication from there <civodul>but like you wrote, i suspect the longest part is cloning the repo <civodul>(at any rate, we should release someday :-)) <jpoiret>hah, regarding that, I booted the desktop.tmpl vm yesterday on c-u, it seems to work properly <civodul>i completely lost track of the core-updates work (apologies!) <jpoiret>I'll need to merge master into it, adapt some *cough* other channel *cough* and then try it on bare metal <civodul>i’m glad you folks have been working on it <civodul>well there might be quite a few channels needing work actually? <civodul>depends on the kind of breaking change you have in mind <civodul>maybe for nonguix it’s related to linux-libre packaging? <civodul>i’m wondering what could be a problem <jpoiret>I don't think so. I think that part of the channel should be quite robust <jpoiret>except for symbols disappearing when linux versions are removed ofc :) <jpoiret>no, I'm thinking mostly of missing libxcrypt, icu4c for firefox, stuff like that <civodul>i guess libxcrypt is going to haunt us for years to come :-) <jpoiret>nothing major, although I don't remember all of the earlier changes that went into c-u <jpoiret>main puzzle piece was building it from a tarball instead of source, to avoid git <jpoiret>now it's just a matter of adding it where it's needed <civodul>is the tarball at ftp.gnu.org/gnu/guix/mirror ? <jpoiret>yeah I guess one annoying thing is that dependents often take it for granted and don't use dependency discovery tools to find it <jpoiret>also avoids an autotools cycle because of its use of guile-3.0 <jpoiret>but it could also use guile-final instead <qecep>is anybody working on packaging firewalld? I see it is in the wishlist <qecep>signal-desktop is also not packaged yet? the signal messenger <futurile>qecep: sometimes worth checking in issues.guix.gnu.org and the mailing list to see if someone has had a go at it <futurile>qecep: it's basically searching any channel that has been registered <Altadil>futurile: wow, that’s really nice, thanks for sharing! <qecep>oh i see, it's in nonguix, haven't dwelve into that yet, until I have a stable and complete(in my taste) desktop I'm not dwelving into non supported channels <qecep>that should be added somewhere...it really super cool <futurile>Altadil: it's a really nice way of finding things <qecep>I'm still struggling to understand if I have installed everything correctly and if I have updated the system properly <jpoiret>qecep: signal will probably not be built from source there, since iirc they use electron or something similar <qecep>i'm migrating my personal apps to tauri, electron it's giving migranes, thank you for reminding me about electron <reyman>Do you know if some tutorial exist to better manage dependency cycle at build step that occur when you try to package python things ? I found a way to solve my problem by cutting the .scm in two parts, but that's not very elegant ... <reyman>and i search another example to install correctly python binary in PATH : /gnu/store/n7bpp2wvdxyszj7yw9bxas7mcjij1807-python-mkdocs-1.5.3/bin/mkdocs to mkdocs <rekado>pkill9: on the topic of selinux: we offer a guix-daemon.cil file with an SELinux policy that a sysadmin can install. <jpoiret>qecep: tauri will also be complicated because of Rust <qecep>jpoiret, of course, i was just talking out loud, pardon me my bad <qecep>is there a website like that "toy" for sharing and cloning recipes for config.scm? <hapst3r>festerdam: you might want to check ~/.config/guix/current, IIRC it contains an /etc folder <hapst3r>qecep: If you stumble across this, please let me know, that's a genius idea - or something like an awesome-guix documenting best practices (maybe that's already covered by the cookbook) <qecep>hapst3r, now that you mention, I might be looking in the wrong place atm, but I can't find mention on how to contribute to the cookbook beside the part that states that it includes articles published on the guix blog <qecep>yeah i mean is there no "guix-studio" config.scm, pardon the comparation with ubuntu-studio, it's just to have a clear-cut example I'm in no way saying "it should be like that", just to explain the content i'm expecting, did I miss some documentation <qecep>that was a question mark, *config.scm? pardon me <festerdam>hapst3r: ~/.config/guix doesn't exist on my normal user account and /root/.config/guix/current/etc doesn't contain a guix-daemon.cil file. <hapst3r>festerdam: in that case, my apologies. It does on my guix machine. <festerdam>hapst3r: But I think ~/.config/guix is supposed to exist on my user account, as that's where the guix profile goes. Not sure if I somehow have to tell guix to be aware of my user, but first I want to get SELinux properly working with Guix. <futurile>seems like a scientific computing kinda thing <jpoiret>festerdam: I take it you haven't `guix pull`d yet? <jpoiret>btw futurile: can't guarantee it but I'll try to be there for the patch review session <festerdam>jpoiret: No, because selinux prevents it from remounting /gnu/store as writable. <festerdam>And I'd like to not set selinux to permissive. <futurile>jpoiret: that would be brill - the more the merrier - and no worries if you don't make it - I'm going to email out the links today <rekado>festerdam: the cil file is part of the Guix repository. I don't think it's actually installed with "guix pull". <jpoiret>festerdam: hm, that's quite annoying <rekado>you can clone the git repo, configure it, and then import the cil file. <jpoiret>rekado: `guix pull` has almost all extra files, it's the guix package that doesn't necessarily install them <jpoiret>i have ~/.config/guix/current/share/selinux/guix-daemon.cil <festerdam>jpoiret: Thanks! I will copy root's guix-daemon.cil and try it out! <festerdam>The docs then say to "Then relabel the file system with restorecon or by a different mechanism provided by your system". Would that mean running «restorecon /»? <rekado>another option on RHEL is to touch /.autorelabel and reboot <festerdam>yelninei: Huh. Weird. It says that guix_install.sh was supposed to already have dealt with selinux. I installed guix through that script. <yelninei>when i installed guix to play around in a fedora vm some months ago i ahd problems with the selinux from the installer. But today i reenabled selinux and added the latest version of the policy and it works now <festerdam>But after having followed the instructions on that page it works fine now, despite the note that says «The guix-install.sh binary installation script offers to perform the steps below for you (see Binary Installation).» <yelninei>civodul: Could it be that the install script installs the selinux policy from 1.4 and not the latest where the remount is allowed? <festerdam>guix pull fails for me with «In procedure getaddrinfo: Temporary failure in name resolution». The application setup page says I need to be running nscd dæmon, or suffer with errors regarding name resolution. It seems NSCD is deprecated on fedora and has been removed back in Fedora 35. The replacement supposedly is systemd-resolved. I tried running «sudo sssd». That command finished without any <ebrasca>Hello, when I try to run something from guix shell it says "qt.qpa.xcb: could not connect to display :1" <ebrasca>I have add tryed to add some expese and preserve but it did not help <ebrasca>hepe are the Display options I added --expose=$XAUTHORITY --preserve="^DISPLAY$" --preserve="^DBUS_" --preserve="^XAUTHORITY$" --expose=/var/run/dbus <futurile>ebrasca: what's the application - and do any other GUI apps work? <qecep>weird question, does anyone know how much space it take a basic foreign installation <qecep>would a basic foreign install to add a dozen of apps take more than 4 gigs? <jpoiret>ebrasca: don't you also need to expose the socket in /tmp/.x11-unix? <jpoiret>qecep: if they are GUI apps then yeah it definitely can <ebrasca>jpoiret: I don't know , I am trying to make it work <jpoiret>X11 applications connect to the X server through a Unix socket, usually located in that directory <ebrasca>jpoiret: guix shell: error: statfs: /tmp/.x11-unix: No such file or directory <jpoiret>sorry, it's .X11-unix, with a capital <futurile>guix shell --container --nesting --development guix --network --preserve='^DISPLAY$' \ <futurile> --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \ <futurile> --preserve='^DBUS_' --expose=/var/run/dbus --expose=/etc/ssl/certs/ \ <futurile> --share=/run/user/"$(id -u)"/ --preserve='XDG_RUNTIME_DIR' nss-certs coreutils <jpoiret>sharing the .X11-unix socket directory should be enough for qt to connect to X11 <futurile>jpoiret: ack - literally just because it's right out of my notes - and I'm currently in my dev notes - and I just wanted to quickly test it worked <ebrasca>jpoiret: Thanks it works for vlc , now I get "Could not initialize GLX" <jpoiret>hmmmm, you might want to share the directory $XDG_RUNTIME_DIR and also preserve that var <ebrasca>Do you mean "--share=/run/user/"$(id -u)"/ --preserve='XDG_RUNTIME_DIR'" ? <jpoiret>$XDG_RUNTIME_DIR should point to the former so "--share=$XDG_RUNTIME_DIR --preserve='^XDG_RUNTIME_DIR$'" should work too <ebrasca>Is it better to use expose of share? <ebrasca>jpoiret: I added that line and I still get the same error, I tryed to add mesa, mesa-utils and mesa-headers and it is the same. <futurile>ebrasca: you will need to adapt it - but it might be a helpful place to start <ebrasca>futurile, jpoiret: Thanks , guix promisses a loot but then you can't run anything on it. <futurile>ebrasca: I'm not sure why you're trying to run something in a container? if it's code you trust just run it normally (e.g. install it) or run it in a shell (but without container) <futurile>ebrasca: containers are hard - I like them a lot - but they're definitely at the messier end of things / harder to get stared with :-) <ebrasca>Because the binary can't find its dependencies because Guix is not FHS <futurile>ebrasca: oh well rread through that blog post - it covers fhs <ebrasca>I like to go back to programming soon but nothing really works here <futurile>ebrasca: maybe start by doing simple things - then progress from there - Guix is definitely a project where you have to 'invest' time to figure it out - see if teh blog posts help you <oriansj>ebrasca: everything in guix works if you have the source code. If you only have binary blobs, well you will definitely not find much help. <ebrasca>oriansj: I have not have luck running my window manager from source code. I like to start with startx not some loggin manager. <ebrasca>There are good things un Guix but it is hard to understand this thing <futurile>ebrasca: ack! for sure - promise it get's easier ;-) <Zzull>ebrasca Have you tried something like: `xinit $HOME/.guix-profile/bin/<your-wm> -- /usr/bin/startx :0 vt1` <Zzull>Hello everyone, I have a `guix container` question! I'm trying to install Calyxos (https://calyxos.org/) on my phone through a script given by them. Unfortunately, the script installs its own adb and fastboot executables so it requires the FHS to work. I managed so far to have its own adb almost working with the invocation "guix shell --container <Zzull>--network --emulate-fhs --preserve='^XAUTHORITY$' --preserve='^DBUS_' --expose=/var/run/dbus --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri --expose=/dev/usb --expose=/dev/bus/usb android-udev-rules libusb usbutils coreutils --expression='(list (@@ (gnu packages gcc) gcc) "lib")' but its adb fails to detect my device with `List of <Zzull>devices attached: (no serial number) device`. Does anyone know how to have the container and the usb device communicate better? <futurile>Zzull: oh tough one - nothing on the mailing lists? <Guest4623>Hello, how can I modify a package that is included as a dependency pretty deeply in the system? I have defined my own package variant of this package, but it is several steps down a dependency chain (and I don't even know which packages actually depend on it) <Guest4623>The actual package I'm patching is xkeyboard-config in case this makes any difference. <futurile>Guest4623: what do you mean it's a dependency, but you don't know where it is? so you're trying to build xkeyboard-config but with a different input? <Guest4623>So, the problem is I can build and install this modified version of the package, but it is not being used in place of the original package. <ebrasca>Zzull: I have not, I will try it soon. <Guest4623>No, I'm building a patched version of xkeyboard-config <futurile>Guest4623: OK, and you have a custom 'input' to xkeyboard-config? <Guest4623>And I'm pretty sure that there are several layers of dependencies, so it is probably not feasible to modify every package that depends on xkeyboard-config. No, I only added a patch phase using modify-phases. <ieure>Guest4623, I also tried to do this and found it was too complex; I think the simplest thing is to upstream what I need. :/ <Guest4623>I can't upstream this, since this is a custom keyboard layout to suit my personal preferences <futurile>ieure: you jumped in on the Clojureverse discussion about byte-compiling Clojure in Guix right? <ieure>Guest4623, You don't have to submit a full layout, just the symbols and rules to make it work, which you can then activate. xkeyboard-config is full of this kind of stuff. <futurile>ieure: if you were up for it - it would be great if you would summarise what you got from the discussion on the thread in guix-devel <ieure>futurile, Hmm, I can maybe take a stab at that. <podiki>mrh57: i wasn't able to reproduce <podiki>i was going to add that doing it in a container one should make sure to pass --no-cwd because if doing this from your $HOME that could include some config <mrh57>podiki: it's been pretty inconsistent when it happens, I can't find any similarities between the package definitions where it does and doesn't, but it's always in the same guix shell env <podiki>there was a suggestion in the thread, did you try it? <mrh57>podiki: I'll try a couple more things <mrh57>podiki: yeah I tried that but it made no difference as far as I could tell <podiki>not sure if there is a cache involved, could clear out any cache like ~/.cache? or yeah, in a container would be really isolated then <podiki>i just tried again (the guix shell --pure version) and it still works <mrh57>podiki: I can no longer reproduce the issue with clx-truetype, but I still get the same error when trying to locally build a package I wrote myself (not upstream) <mrh57>podiki: even with --container <podiki>as for your own package, presumably need something to say where compiled files get written, not to the store <mrh57>podiki: right right, just wondering.... <podiki>that i can confirm: builds, but trying to load in sbcl errors on "read-only file system" <podiki>i don't know enough about our packaging and details of CL compiling to know what is happening <podiki>i would chime in on that thread, if you could (make sure the cc is to everyone) <mrh57>Yeah me neither, I don't seen any obvious .asd discrepencies between this package and others, nor obvious package definition differences <mrh57>I tried to look into the guix asdf build system but didn't really understand it <Guest4623>podiki: I'm the one that started that thread, and for me it seems the problem was related to something I had in ~/common-lisp. I've been meaning to post an update in the thread, but I forgot about it <festerdam>jackhill: Is there some workaround? Can I somehow get guix running on fedora, despite nscd no longer being provided by fedora? <podiki>i'm guessing when you tried in a container it picked up your home dir (if you ran it there, or in ~/common-lisp) but i also forgot to suggest there trying with --no-cwd or in a different directory <podiki>sorry i didn't say so earlier but glad you got that figured out! and now we have a new mystery <mrh57>strangely I ran guix shell --container --no-cwd in none of ~, ~/common-lisp, or ~/.cache/common-lisp, yet still received the same error <mrh57>though I haven't tried clearing out my ~/.cache yet, and sbcl does seem to still write things there when compiling <podiki>mrh57: i tried your example also in container and pure shell and each time failed with that error (sometimes with less other compiling/loading before though) <jackhill>festerdam: it's not clear to me. Currently Guix's libc needs to talk the nscd protocol to something. nsncd might fit do it? <Guest4623>festerdam: When I was running a foreign distro without nscd the only way I got Guix working was to build libc (or glibc? can't remember) from source with nscd enabled <Guest4623>For me that was just the final push I needed to migrate to a full Guix system though ;) <festerdam>Guest4623: I did already try to run a full Guix system before, but I found guix pull to always be very slow and error-prone and the default install had some weird quirks (though I don't remember which), and neither did the guix package repository provide everything I needed (because no one had yet found a way to bootstrap those packages) (And I think may have messed my boot selection back then somehow, I <festerdam>now always have to manually select the grub efi on startup (but the problem remains even after reinstalling grub from another disto, so I don't know if it's really guix's fault)). So I really would like to stay on a system that I know will just work and not require a lot of customization, but I still want to play around with guix. <futurile>does anyone run Guix within a docker container? or know of an example of someone doing it? <nanounanue>How to create the public definition of an emacs package that is not in elpa or melpa, but it has a git repository? <roptat>nanounanue, I'm not an emacs user, but I suppose you would do the same as other emacs packages, but for the source, you would use a the git-fetch method <roptat>ah, emacs-totp would be an example of that, I think <nanounanue>Also how to calculate the sha256 number (most of the time I just put some number there, it fails the compiler(?) tells me the correct number and I modify my `define-public` definition with the propose number, doesn't feel like the correct way of doing it) <ieure>I got very, very tired of having the barrier to entry in MELPA being "strangers review my own code for me and make me change it." <Altadil>nanounanue: if you have a local copy of the git repo, you can also run guix hash -rx . (after git checkout of the tag you want). <Altadil>you’re welcome, but the failing and copy-pasting method might be just as fast I guess :) <dkxr>hello guys, does anyone know a graphical package manager? i tried installing athenaeum, which is like a libre steam but i couldnt get it working <dkxr>like im looking for one with games or other applications, u know the drill <ieure>dkxr, IMO, there's not much point running GuixSD (which, presumably, you're doing) and then using a bolt-on package manager thing. <dkxr>im thinking its because package managers in general contain non-free apps? <dkxr>or is it because of some other reason? <dkxr>like, terminal usage preference? <ieure>It's mostly because those types of things -- I'm thinking of the stuff that apes various "app store" interfaces here, like GNOME Software -- serve a completely different usecase than Guix offers, or what the majority of its users seek. <ieure>And since whatever mechanism they use to install (presumably Snap, Flatpak, or something like those) are crappy systems even by the standard of other Linux distro package managers. <ieure>At least, in my opinion. I *really* do not like Snap/Flatpak/anything even remotely like them. <ieure>I'm sure there's some way to do it on GuixSD! I have no idea what it is, because one of the major appeals of Guix is that being a rolling distro and relatively easy to package stuff for means I never have to resort to those systems. <dkxr>i was thinking of a steam alternative <dkxr>like so i can browse for games <ieure>Sorry, one of the major appeals of Guix *to me* is never having to deal with those kinds of things. <dkxr>ieure, how do you go about browsing for a genre of applications? <ieure>dkxr, I don't, I'm old and boring, already know all the stuff I want to use, and don't often change those. <ieure>I'm more inclined to use a search engine to find the name of a thing, then `guix search name-of-thing'. Sometimes `guix search vague-notion-of-thing' over a search engine, since they've gotten much worse over the last few years. <dkxr>beautiful, you're very helpful dude not gonna lie <dkxr>sorry, that sounded sarcastic <ieure>No problem, good luck with your search for games. <dkxr>lmao i dont think its gonna be easy, i use libregames for now <dkxr>but im longing for something better <ieure>I gave up on PC gaming a long time ago, I collect arcade games now. <ieure>I got another Asteroids cabinet recently, and two pinball machines: Black Hole, and Bride of Pin-Bot. <ieure>Yeah, I've literally lost count. I think it's 70-something total. <dkxr>where do you store all of them? <dkxr>you can set up an arcade bruh <ieure>I have a second house with about half the games in it, the rest are in a warehouse. <dkxr>ieure: i have a second house just for arcades <ieure>dkxr, This is surprisingly common, actually. I know two other local guys with the same setup, and one who built a dedicated building on his property for his arcade. <dkxr>arcades arent like, amazing? <ieure>We're, ah, medium-big fish in this game, there are people with real amounts of money to throw around. <ieure>These are all private collections, but the other two guys are both part owners of Ground Kontrol; that's like the original retro arcade, they've been around since the early 2000s. <ieure>There's almost always a division between the stuff good enough for your personal collection and the stuff that goes on route for the public to play. <ieure>Stuff on route gets thrashed, so you don't really want to put anything super rare out. <dkxr>by put out what do u mean <ieure>Set up in public for strangers to play in exchange for money. <dkxr>its mainly for personal and commercial with some of your homies <dkxr>havent you built an arcade? <ieure>Most people are in it because they like the games. A few try to make some money off that hobby by putting games on route. Hard way to make money, these days. <ieure>Easier money fixing games for others, if you've got the skill. I very occasionally do that, or buy something broken, repair it, and resell. But mostly buy to keep, for my own enjoyment. <ieure>Keeping my own stuff running is more than enough of that kind of work. <dkxr>its a beautiful collection <dkxr>you got something beautiful goin on