IRC channel logs


back to list of logs

<orneb>Hi! I installed Guix following the
<orneb>manual process and I succeded. After rebooting and setting the root and user password, when trying
<orneb>to login as user I fail and always get prompted to re-enter my credentials. I can only login as root. I'm experiencing something similar:
<orneb>My config:
<orneb>Also, Sway has some issues starting: “XDG_RUNTIME_DIR is not set in the environment. Aborting.”.
<mbakke>jonsger: done! :)
<mbakke>orneb: did you try to 'guix pull && guix system reconfigure config.scm' and rebooting? if it's the same issue it should be fixed after an upgrade.
<orneb>mbakke: Yes, I did that logged in as root after running `passwd user` and failing to login as user.
<boud>Minor updates on relation between Guix and Maneage -
***puff` is now known as puff
***ChanServ sets mode: +b *!*M6piz7wk*@*
***M6piz7wk[m] was kicked by ChanServ (User is banned from this channel)
***ChanServ sets mode: +o litharge
***litharge sets mode: -o litharge
<semente>hi guys, I'm new on guix and I'm having an issue trying to setup a second encrypted disk. I've added it to mapped-devices, and to file-systems (see The command `guix system reconfigure' works but after reboot I get the error: pre-mount actions failed.
<semente>am I missing an option to mount this file system after the root fs is mounted?
<atka>sneek: botsnack
<FlaminWalrus>What's the syntax for adding a (shepherd-service...) to the services field of an (operating-system) declaration?
<NaturalNumber>how does one create their own xwindows sessions without using ~/.xsession? I'm guessing this requires creating a custom package and channel?
<lechner>Hi, this week's LWN features an article entitled:
<lechner>"The trouble with symbolic links: Jeremy Allison's SambaXP talk on why symbolic links were a mistake."
<efraim>jonsger[m]: I've just arrived in Kosovo for debconf and have been awake for about 24 hours. you're asking for permission or hoping that by asking I'll fight the merge conflicts? :P
<FlaminWalrus>lechner: I've long had a vague thought that the file tree was a mistake---symbolic links seemed an indication that what users really wanted were sets (in the mathematical sense) of inodes on which to perform queries, and links were a feeble attempt at deforming the tree of inodes into the graph of a set-inclusion poset
<FlaminWalrus>Haven't given it much technical thought though. Maybe someday I'll have a psychotic break and implement all my half-baked OS ideas in my very own TempleOS...sounds fun
<roptat>hi guix!
<jonsger[m]>efraim ah okay, Marius did it already. It was more asking about the permission as I wasn't involved with staging lastly
<attila_lendvai>is anyone here using syncthing-gtk? it stopped working for me in the past couple of months.
<NaturalNumber>i am having a difficult time installing xmonad. i thought i could add it to system packages and everything would work, but it seems like i have to manually install every dependency. i'm going to try building it from source now, but any help is appreciated
***toluene3 is now known as toluene
<sneek>atka: Greetings!!
*attila_lendvai reports that syncthing-gtk has been fixed meanwhile
<weidtn>Is installing mesa and opencv for cv2 in python enough to get it working? It can´t find when I try importing cv2
<PurpleSym>weidtn: This works for me: `guix shell mesa opencv python python-numpy --pure -- python3 -c 'import cv2'`. How did you install them/load cv2?
<weidtn>just guix install. without a shell
<PurpleSym>Hm, maybe reload the profile via `source ~/.guix-profile/etc/profile`?
<weidtn>does not help
<weidtn>But there is no in .guix-profile/lib/
<PurpleSym>Can you post the exact error message?
<unmatched-paren>orneb: you need elogind or seatd+greetd to create XDG_DIRRUNTIME_
<PurpleSym>weidtn: Does it work in the `guix shell` above? I can’t see any dependency of opencv on mesa/OpenGL.
<weidtn>same error in the guix shell
<PurpleSym>What’s your Guix version (via `guix describe -f channels`)?
<weidtn>where is the version in that?
<weidtn>you mean the commit of the 'guix channel?
<weidtn>(commit "c8045fa0526774a6b1da979baee2f98a7185dbad")
<unmatched-paren>anyone know what the replacement for (assoc-ref %build-inputs "...") in gexp style be?
<unmatched-paren>would be
<PurpleSym>All of it. You can use that output to feed it into `guix time-machine -C` to get the exact environment again.
<weidtn>`guix describe -f channels`gives:
<PurpleSym>weidtn: That’s alot of channels. I cannot reproduce the error with only the 'guix channel. Does your `opencv` package come from a different channel maybe? (You could try `guix show opencv` and look at the location.)
<aramus>It's from the original 'guix channel. I think I also installed it before I added the other channels
<PurpleSym>aramus: I see. Not sure what the problem might be, sorry ☹️
<aramus>Is my laptop the problem maybe? ThinkPad T420 has intel HD3000 GPU.
<aramus>Sorry for name change btw, im online on the phone
<PurpleSym>I don’t think the hardware is the problem. The question is: Who is trying to load libGL?
<weidtn>well from the error message it seems like python is trying to load , doesnt it?
<andrzejku>can someone hint me
<andrzejku>I am trying to reuse it
<andrzejku>but it complains that remove is unboud variable
<andrzejku>gdm doesn't work by default with sway
<nckx>andrzejku: Did you forget to import (gnu)?
<nckx>That snippet looks... weird.
<nckx>If it's trying to do what I think it is, don't forget to import the other modules shown, as well.
<nckx>But it's weird.
<andrzejku>I am new
<andrzejku>but now I am tryign to back configuration
<andrzejku>and created manually sway.desktop
<andrzejku>in /etc
<andrzejku>maybe gdm will recognize it
<nckx> Possible. I use SDDM for it myself.
<andrzejku>nckx, did SDDM recognize sway automatically?
<nckx>I would not like my display manager to have +1 the number of JavaScript engines of my desktop.
<nckx>andrzejku: I told it to run sway.desktop, IIRC.
<nckx>Let me check.
<andrzejku>ohh it doesn't work =/
<andrzejku>maybe in guix the path is different
<andrzejku>that one: /usr/share/wayland-sessions/sway.desktop
<nckx>Guix doesn't use file names like that at all.
<nckx>I always forget that my 'sway.desktop' setting is actually part of the auto-login I have set up. Not sure how useful this is, probably not much, sorry: — but, if you have sway installed as a system package, it should show up in an sddm menu of some kind, no?
<nckx>I thought that's how all this was supposed to work and be all friendly and stuff.
<andrzejku>what's the difference between system package and just a package
<andrzejku>ya I see the path is wrong
<nckx>System packages is what we call packages you add to the (packages ...) field of your operating-system. You can also install packages with 'guix install', per user, but these end up in a different profile and I'm not 100% sure that a user-installed sway would work without additional configuration. It should, but...
<jpoiret>nckx: it won't get picked up by the DM, but if you're launching sway manually it will work
<jpoiret>DMs in general don't look at user-specific stuff
<nckx>Thanks for the confirmation. Updated to 0%.
<andrzejku> adding them to the system-wide set of packages automatically makes them available at the log-in screen.
<jpoiret>re the js engine, are you using DBus + polkit? if so, you're already using mozjs (the engine behind gjs)
<jpoiret>computers were a mistake
<jpoiret>andrzejku: the thing is, most DMs in Guix are hardwired to look into the system-wide profile's dirs to find the .desktop files
<jpoiret>that's why the WMs should be installed there
<nckx>The (modify-services ...) snippet on that page you link to, under slim-service-type, can be repurposed to add (sddm-serwice-type (sddm-configuration (display-server "wayland"))) instead of the 2 slim- services. I'd start there.
<jpoiret>ideally, we should instead have DMs that simply let you login, and then you chose the session you want
<nckx>Mind the typo; I am revoltingly mobile.
<nckx>andrzejku: ^
<nckx>jpoiret: Not by default, but I do sometimes start dbus under duress.
<jpoiret>oh, neat. that makes one more person that doesn't run dbus by default
<jpoiret>maybe i'll end up doing that as well
<nckx>So... two? Or more?
<jpoiret>networkmanager and udisk are too useful though
<jpoiret>well, at least 3 i think
<nckx>I don't miss either, but I don't care about the d-bus 'clique' (as they are called somewhere in Guix) as one might expect from my previous message. I'm not anti-.
<nckx>*as mucm.
<jpoiret>right. I just don't like its tight integration with systemd, and some of its design choices
<jpoiret>dbus is pretty mandatory on wayland though unfortunately
<nckx>Which is why I'm already publicly hedging my bets, since I expect to just give up on not running it a soon as it becomes work :-p
<nckx>If you're reading this in logs from ~the future~, about to ask me how I avoid the eebil D-Bus, the answer will almost certainly be 'I don't, join us.'
<andrzejku>hmm I listed now sway in packages
<andrzejku>but gdm doesn't recognize it
<nckx>D-bus is less evil than X.
<andrzejku>however I see the desktop file is in wayland-sessions
<andrzejku>maybe I have to configure gdm to use wayland
<nckx>See the manual.
<nckx>It is still #f by default.
<andrzejku>nckx, what's #f? :D
***toluene0 is now known as toluene
<andrzejku>The desktop environments in Guix use the Xorg display server by default. If you’d like to use the newer display server protocol called Wayland, you need to use the sddm-service instead of GDM as the graphical login manager. You should then select the “GNOME (Wayland)” session in SDDM. Alternatively you can also try starting GNOME on Wayland manually from a TTY with the command “XDG_SESSION_TYPE=wayland exec dbus-run-
<andrzejku>session gnome-session“. Currently only GNOME has support for Wayland.
<andrzejku>it seems from manual that I have to switch to sddm
<cbaines>it is possible to use wayland with GDM
<andrzejku>cbaines, ok so the clue is how to configure gdm-service-type
<cbaines>yes, see the wayland? setting in the gdm-configuration
<andrzejku>ahh that's the newest
<andrzejku>gdm configuration
<andrzejku>in non devel there is no such option
<nckx>You're running devel.
<nckx>Still, you're not the first to be confused, and I'll be getting rid of /devel real soon now™.
<andrzejku>can someone help me (services gdm-service-type (gdm-configuration wayland? #t) %desktop-services)
<andrzejku>invalid field specifier
<nckx>You're writing (field-name value1 value2), it should always be (field-name value). You'll have to use modify-services on %desktop-services to modify gdm-service-type.
<andrzejku>ahh true
<nckx>(modify-services %desktop-services (gdm-service-type config => (gdm-configuration (inherit config) (wayland? #t))))
<unmatched-paren>jpoiret: is it dbus that uses mozjs or polkit?
<andrzejku>%desktop-services hold gdm
<nckx>That is from memory and may be bugsy.
<unmatched-paren>because i'm using dbus but not polkit
<unmatched-paren>Context for my %build-inputs question:
<unmatched-paren>I'm writing the quoted arguments -> gexped arguments formatter
<unmatched-paren>and converting %outputs to #$(package-outputs this-package)
<unmatched-paren>but i'm not sure how i'd transform %build-inputs similarly
<jpoiret>unmatched-paren: i think polkit
<jpoiret>it's used to specify rules
<unmatched-paren>ah good
<jpoiret>because yes, you WILL need a whole javascript engine for that
<unmatched-paren>that's insane
<andrzejku>nckx, shit you are very strong
<jpoiret>and it's something that was added at a later stage
<andrzejku>nckx, big thanks
<jpoiret>ie not an initial bad design decision
<unmatched-paren>I'm sure it gets them lots of users though.
<nckx> 💪
<nckx>I am, though.
<unmatched-paren>Specifically the "let's use react vue and angular with babel and typescript and async nodejs!!" kind of user.
<unmatched-paren>Well, that's what they thought would happen. Maybe they wanted to cause a mass migration of web developers to linux from mac ;)
<nckx>(Thought process: pfft how would you lot react if it were Guile instead -> guix size guile, mozjs -> ) hmm why does mozjs hold a reference to perl?
<unmatched-paren>Guile would also be overkill, methinks
<unmatched-paren>Especially since it's not exactly a _small_ scheme implementation.
<andrzejku>hmm that's strange but gnome-terminal stopped to work
<nckx>I don't disagree, but 'extensibility' only roils the #guix crowd when it's a language young people speak.
<unmatched-paren>tinyscheme could be acceptable i guess
<unmatched-paren>nckx: true
<nckx>lawn.get(off) // help I do not actually the JS good
***wielaard is now known as mjw
<dirtcastle>I built stumpwm from source and was using on ubuntu before. now I installed it from guix. (guix is on artixlinux right now). my config doesn't work anymore what should I do.
<andrzejku>hello, can I ask someone to check whether the gnome-terminal is working in wayland/sway?
<andrzejku>the default terminal emulator for sway is foot
<pashencija[m]>I have found out the problem that causes my system not to boot. It's `FDTDIR` in extlinux.conf (check extlinux.scm)
<pashencija[m]>Once I remove that line, the FDT passed by bootloader is in use and it boots fine. What would be the best way for me to get rid of it? Should I somehow overwrite `menu-entry->gexp entry` in my bootloader definition? Should I edit extlinux.scm (and send a patch) to make this line optional? How do I pass parameter if I do that?
<bud>hello guix folks!
<nckx> Sup bud.
<bud>i am in the middle of a identity crisis regarding my btw, Arch linux thing. And is considering a hop (have not hopped once in 7 years).
<bud>and i have been draw to this guix thing. I need to get some hardware shenanigans sorted out before doing the jump.
<nckx>Also, happy baguette day to our French buds, I just realised.
<bud>wait, isn't every day happy baguette day??? uh oh
<nckx>bud: Come. Our bugs and infuriating frustrations are new and shiny.
<bud>i also have a confession to make, i have been a sublime text user for 10 years, and as i understand, programs like that, binary blob closed source, simply doesn't jam with guix, is that right?
<unmatched-paren>yes, correct :)
<unmatched-paren>guix does emacs mostly
<unmatched-paren>though there are some vim users here (including me)
<bud>but, is it possible even to install something like sublime text (in a unofficial manner)?
<nckx>Socially ('ethically' just sounds too insufferable) we don't support them here or anywhere official. Technically, they can sometimes be made to work, but it can be tedious. There's no FHS compatibility layer (yet).
<bud>thanks nckx
<unmatched-paren>and i'm sure there are several --inefficient-- mouse-based text editors in guix
<unmatched-paren>geany is one i think
<nckx>Emacs another.
<nckx>Does vim not support mouses?
<bud>yeah, i saw emacs even got a tab bar now :D
<unmatched-paren>nckx: it does
<unmatched-paren>but nobody uses it
<unmatched-paren>vim has an 'easy mode' iirc
<nckx>Original point taken, though, I don't think mousing emacs does quite what people expect.
<bud>no one text edit with a mouse, not having mouse support for the ui though is just stupid and backwards. i always enable vi-mode if its available.
<unmatched-paren>bud: you do? then why use sublime if vim has mouse support?
<bud>i don't understand why i would run a graphical application like a text editor, inside a terminal emulator.
<nckx>Don't take the bait 🧀
<unmatched-paren>bud: me neither tbh :D
<unmatched-paren>seems like nobody has bothered, in all those years, to make a better UI system apparently
<bud>but trying to get sublime working on guix, is not the first thing i should do, it will be tricky, and maybe possible.
<unmatched-paren>you'd need to use patchelf
<nckx>Tricky in that you'll have to front-load a few Guix concepts and implementation details that usually come much later, if at all.
<bud>as i understand guix can replace package managers for python, ruby, emacs etc. and i guess it could be used to replace sublime package management as well (that stuff is open source, python based).
<unmatched-paren>i guess you could talk to nonguix about implementing that
<bud>i just want to be convinced not to try to install sublime the first thing i do. i do know vim, so i use that initially.
<unmatched-paren>Well, clearly there's no point in trying to convince you to drop Sublime. I think if you go to #nonguix they'd be willing to help you get it working :)
<bud>do you guys have a recommended video introduction to guix?
<andrzejku>Hey, do you know how can I provide terminfo
<andrzejku>in guix?
<unmatched-paren>i think there is a video
<jpoiret>andrzejku: did you manage to get gnome-terminal working?
<jpoiret>i'd say you need to log-out then log-in for it to work
<jpoiret>since it's a dbus service
<bud>there are lots on youtube. just opened a playlist with 6 hours craft your system with guix (system crafters)
<jpoiret>(and you need to use dbus)
<unmatched-paren>but it showcases what is (in my opinion) a suboptimal system for installing packages
<andrzejku>nah it doesn't work but I installed foot terminal
<jpoiret>for terminfo, you'll need to install ncurses in the same profile as the terminal
<andrzejku>and now I see that 'foot': unknown terminal type
<bud>just thought, maybe there is a "recommended" "watch this first" video thing.
<andrzejku>what does it mean in the same profile as the terminal
<andrzejku>on the same account?
<jpoiret>you used `guix package -i foot`, right?
<jpoiret>then just `guix package -i ncurses`
<unmatched-paren>bud: Well, the manual is okay but sometimes not that great as an introduction
<jpoiret>basically, guix installs packages in profiles, and the default one for users is ~/.guix-profile
<jpoiret>but all commands that operate on a profile can be made to operate on other ones, with -p PROFILE
<jpoiret>there's also the system profile at /run/current-system/profile/ (it's read-only since the system generation as a whole is in the store)
<jpoiret>that means that you can do `guix package -p /run/current-system/profile/ -I` for example to see the packages installed in the system profile
<unmatched-paren>and another builtin profile is ~/.guix-home/profile
<jpoiret>you can't install things in that system-wide profile with those commands though, only `guix system reconfigure` with a proper config.scm would work
<andrzejku>jpoiret, ohh interesting I was looking for explanation how it works actually system nad just profile
<unmatched-paren>which is used for `guix home` obviously
<bud>another thing i was thinking about is initsystem, guix use sheperd right? i am one of the weird few who actually likes systemd. i guess that is even more complicated to set up, but maybe, there are others with guix+systemd?
<unmatched-paren>bud: nope
<unmatched-paren>virtually impossible
<jpoiret>well, for guix system you'll likely have to rewrite the whole thing
<unmatched-paren>shepherd is wired in
<jpoiret>just packaging systemd will be a beast i think
<unmatched-paren>you'll like it more, i bet ;)
<jpoiret>and systemd will likely not want to cooperate with Guix's shenanigans either without some modifications
<unmatched-paren>jpoiret: it's been done, albeit as an april fools joke :)
<jpoiret>oh no :(
<unmatched-paren>"what have you done?!"
<jpoiret>guix's own pandora's box
<unmatched-paren>there's no way to actually use it though :) just a package
<jpoiret>bud: do you rely on some systemd-specific features, or is it just convenience?
<unmatched-paren>Shepherd is awesome though, it's configured in Scheem® naturally
<bud>it was more asked out of curiosity, obviously i would not do that no "day 1". but i have a neat setup where i use systemd as a "user xorg session manager".
<jpoiret>oh, you could definitely replicate that with user shepherd
<unmatched-paren>bud: wdym user xorg session manager?
<jpoiret>that is, you just autolaunch xorg with a user systemd service file right?
<jpoiret>and set the right env variables
<bud>kinda, the last version of i3-wm added the ability to "notify" systemd when it is "ready" so you can setup a reliable x startup with systemd: before-i3 -> i3 -> after i3.
<jpoiret>as for video introductions to guix, unfortunately I can't recommend any. imo we're still missing a good technical overview of what guix does and how that would help users
<bud>and it is nicer than doing this with shell scripts or whatever since systemd (and i bet shepherd as well) auto restarts crashed application etc.
<bud>jpoiret: i am watching the one i mentioned in the background, and it seems really good.
*unmatched-paren still can't figure out how to convert %build-inputs to gexp style :(
<jpoiret>the one gripe I have with these kinds of videos is that it's not "technical" enough, ie how and what activating profiles mean
<jpoiret>even the manual is evasive about that :p
<bud>jpoiret: and that i3-wm systemd notify thing, only works with systemd (it is hardcoded for systemd in the i3 source).
<jpoiret>like the system vs. user profile distinction, search paths and all. I think it should be part of the mandatory reading for new users so that they're not surprised when something doesn't work how they expect it to
<jpoiret>bud: arf, i was looking at the source to see if it was configurable
<jpoiret>that's patchable though
<jpoiret>we could carry a downstream patch (that we could upstream) to be able to customize the notifier
<bud>jpoiret: <- this is the PR, it is basically a single line
<bud>sd_notify(1, "READY=1");
<jpoiret>you're telling me i3 unconditionally depends on systemd?
<jpoiret>worse, it uses copy pasted code from systemd?
<jpoiret>that src/sd-daemon.c file hasn't been touched since 2016
<bud>i can't imagine that, i don't know if that "sd_notify" is a macro expanding to nothing if systemd isn't installed.
<bud>i can't imagine it hard depend on systemd
<jpoiret>actually, sd_notify is defined in all cases, but when systemd isn't present, it just returns 0
<jpoiret>it's quite ugly though, I wish they'd just #ifdef the sd_notify usage instead
<andrzejku>jpoiret, one more question what if there is the same package in profile and system which one would be preferable?
<andrzejku>because to update the system i hve to run command system blabla
<andrzejku>so the package version might be different
<jpoiret>andrzejku: depends on the order in which they're activated. Generally, if you use a DM, the system profile is sourced first, then the user profile, so the user profile takes precendence
<jpoiret>my suggestion though would be to include only a WM in your system packages
<andrzejku>jpoiret, oh ok
<jpoiret>most programs should either: have service definitions in the system configuration, or end up as user-installed packages
<bud>jpoiret: this is a "new" addition to i3 and an improvement would be to have build option "notify-initd=systemd|shepherd|none" or something.
<jpoiret>right, or maybe systemd|script|none
<jpoiret>i can't imagine upstream accepting a patch only for shepherd
<bud>they did it for systemd?
<jpoiret>i'd wager 95% of their user base runs systemd
<jpoiret>the maintenance burden/user% ratio matters a lot when you manage a project
<bud>not so sure, since it do works perfectly on non linux unices
<jpoiret>ah right, i always forget about those :p
<jpoiret>well, why not
<jpoiret>but, I think we'll need some custom code to make such callbacks work
<jpoiret>ie we don't have a (exec-and-wait-for-callback ...) shepherd procedure
<jpoiret>but it'd be great!
<jpoiret>it's something i've wanted to implement myself
<bud>i really know nothing about how guix actually works, but you are saying that it wouldn't be a big deal to create a custom "package?" with a "simple" patch to support shepherd in the same way systemd is now supported in i3.
<jpoiret>and, to be honest, we could even turn it up a notch and add a way for those callbacks to transmit their environment values
<jpoiret>one thing i hate with systemd is that the environment variables aren't scoped, ie if one service says "okay update the activation environment", every starting service will inherit that environment, whereas i'd rather have only services that rely on the one that modified the activation environment inheriting it
<unmatched-paren>bud: nope
<jpoiret>bud: yes, it's really simple to do such a thing
<unmatched-paren>inheriting packages is easy :)
<jpoiret>i've ran modified versions of packages in the past
<unmatched-paren>(I meant nope as in "no, it wouldn't be a big deal")
<unmatched-paren>silly ambiguous human language ;)
<andrzejku>jpoiret, this is also intresting because when I am showing guix package -I
<andrzejku>then it shows only the application which I installed but where the dependencies
<andrzejku>and how it is managed
<jpoiret>for an example i know: GRUB 2.06 currently has issues with LUKS2, so while the patches make their way to upstream, some people carry in their config.scm a definition of a modified grub with additional patches applied, and it works for them :)
<andrzejku>I think there shall be much more packages
<jpoiret>and it takes just a couple of lines to modify the bootloader you use
<unmatched-paren>(package/inherit i3 (source (origin (inherit (package-source i3)) (patches (search-patches "i3-notify-shepherd.patch"))))) i think
<jpoiret>andrzejku: so, guix does 2 things differently compared to other traditional distros. One is to hardwire dependencies into the packages themselves, meaning that you don't need to also install the other dependencies: they'll still exist in the store, but not in your profile
<unmatched-paren>wrapped in (define-public i3/notify ...) or something
<andrzejku>jpoiret, aa ok
<andrzejku>a what's the second one?
<unmatched-paren>i guess you'd also want to override (name "i3-notify")
<jpoiret>and sometimes, we don't have a proper way of doing that, so we fall back to installing them alongside with the package in the profile, (they're called propagated-inputs) in which case you'll be able to see them by looking at the /manifest file in the profile
<jpoiret>-I only lists installed packages, not their propagated dependencies (i think)
<jpoiret>unmatched-paren: you're forgetting (patches (append (origin-patches (package-source i3)) (search-patches "i3-notify-shepherd.patch")) i think
<unmatched-paren>propagated inputs must be eliminated wherever possible, for they are the eldritch spawn of --SCO Group-- Satan
<unmatched-paren>jpoiret: sure, if i3 already has patches
<jpoiret>andrzejku: guix puts built packages into /gnu/store. Then, some guix commands allow you to link some of these out of the store, into for example profiles
<andrzejku>jpoiret, but is that mean that it can smartly manage dependencies: suppose A --> depends B and C --> depends B and D so when I will try to uinstall C then D (a hard wired dependency will be removed) and B left untouched
<jpoiret>you'll see that if you `ls -ld ~/.guix-profile`, it links to somewhere else, which is itself also a link, etc., ending up somewhere in the store
<andrzejku>jpoiret, I mean is any additional command to clean up dependencies needed
<andrzejku>both runtime and compile time deps
<jpoiret>you don't need to clean-up dependencies
<andrzejku>jpoiret, nice
<jpoiret>guix will always keep what is needed and remove what is not
<andrzejku>jpoiret, thank you
<jpoiret>also, there are no "build time" and "run time" dependencies in Guix if you will
<andrzejku>I will go through cookbook later
<singpolyma>jpoiret: mostly true, though arguable propagated shit is "runtime" if it lands in your profile
<jpoiret>we have a distinction of "native-inputs" and regular "inputs", whose meaning is related to cross-compilation: the former will be built for (and presumably to be run on) the host machine (the one building), while the latter will be built for the target machine
<jpoiret>singpolyma: right, but there's no such clear distinction in guix, some inputs might be used at runtime as well
<singpolyma>jpoiret: yes, for sure
<jpoiret>propagated-inputs is more like bandaid for when we don't really achieve clear separation
<singpolyma>And propagation is a 🙈
<jpoiret>yeah, it's the source of so many bugs
<jpoiret>that and search-paths which is a pain point for the users
<unmatched-paren>jpoiret: but native-inputs are never used at runtime, right? since they might be built for a different machine to the package that depends on them
<jpoiret>well, right.
<jpoiret>but still, that doesn't mean native-inputs == build-time and inputs == runtime
<nckx>They shouldn't be, but there's no hard mechanism to ensure that or disallow references to them (because there are legitimate uses, I guess).
<jpoiret>what kind of legitimate uses though i wonder
<singpolyma>More likely accidental uses that happen to work
<singpolyma>With the current ruby packaging *all* native inputs end up in references if you have any scripts for example
<singpolyma>You probably don't want them, but it doesn't break anything
<nckx>This handgun has legitimate uses, give it back to my child this instant.
<andrzejku>I tried to do swaylock but it seems that I need a PAM module
<andrzejku>however looking into packages there is no PAM
<andrzejku>anyone here who is using PAM authentication?
<unmatched-paren>andrzejku: iirc the only requirement for swaylock is that it is setuid...
<jpoiret>hmmm, we all use pam authentication
<jpoiret>your system declaration contains some services that pull in pam
<andrzejku>maybe that's because I am not using gnome
<unmatched-paren>i'm not using gnome
<unmatched-paren>it works for me
<andrzejku>well in my case swaylock complain that I have to set setuid
<jpoiret>oh, right
<unmatched-paren><unmatched-paren> andrzejku: iirc the only requirement for swaylock is that it is setuid...
<jpoiret>since swaylock needs permissions that you can't grant as a normal user, it'll have to end up in your system config
<jpoiret>you'll need to put it in your (setuid-programs ...) in your operating-system declaration
<andrzejku>jpoiret, and wha's file-append profile path?
<andrzejku>ahh no
<andrzejku>it will be a different path
<jpoiret>ah no, you're not trying to just modify the binary in your user profile to become setuid. What this does is just install some specific binaries into /run/setuid-programs/, which should be in your PATH if you use guix system
<andrzejku>ok but as the parameter
<andrzejku>program is the path
<andrzejku>what the path will be I don't know
<andrzejku>it is swaylock package
<jpoiret>so you should (use-package-modules wm) at the top to import the swaylock variable, and then do (file-append swaylock "/bin/swaylock")
<jpoiret>(file-append swaylock "/bin/swaylock") represents the path to /bin/swaylock inside the built swaylock package in the store
<jpoiret>guix will end up "lowering" that to /gnu/store/XXXXXXXX-swaylock/bin/swaylock
<jpoiret>you will need to remove swaylock from your user profile though, otherwise it'll use the user-profile-installed swaylock which is not setuid instead of the special one in /run/setuid-programs/
<andrzejku>jpoiret, ok wait I will check first maybe it works without modification
<andrzejku>cuz I really got it installed locally
<andrzejku>(use-modules (gnu system setuid)) doesn't import setuid
<jpoiret>what do you mean? you get an error while running `guix system reconfigure`?
<nckx>DYM setuid-program?
<andrzejku>jpoiret, yes
<jpoiret>what's `guix describe` and `command -v guix`?
<jpoiret>setuid was added after 1.3
<andrzejku>guix 6ed5b49
<andrzejku>I am running guix from my home .config directory
<nckx>jpoiret: What's the 'setuid' you both mention?
<jpoiret>the gnu/system/setuid.scm modlue
<nckx>andrzejku: What error do you get, exactly? (See pastebin in topic for >2 lines.)
<jpoiret>am i just now noticing that the dev manual has clickable code that leads to the relevant part of the manual??
<andrzejku>nckx, it tells me to (use-modules (gnu system setuid))
<andrzejku>so let me add this line
<unmatched-paren>would i just have to use #$%build-inputs?
<unmatched-paren>Hmm, #$% doesn't appear in the source anywhere
<nckx>andrzejku: Despite already doing so?
<andrzejku>ohh it works
<andrzejku>I made a typo :D
<nckx>Ah :)
<andrzejku>but anyhow I have to use modules
<jpoiret>the bane of all programmers in existence
<jpoiret>unmatched-paren: there's no uniform way for build-systems to signal their implicit inputs
<andrzejku>swaylock works!
<nckx>andrzejku: It's like #include in C; if you want to use cool-feature, you need to use the (cool feature) module.
<andrzejku>shit I hope my workstation is ready for next self-learning :D
<andrzejku>no more serious issues
<unmatched-paren>(cool feature) may be found in cool/feature.scm somewhere in $GUILE_LOAD_PATH
<jpoiret>unmatched-paren: for gnu, you could use #$(assoc-ref (standard-packages) "your-input")
<unmatched-paren>jpoiret: hm
<unmatched-paren>well, i'm trying to figure out a general solution :(
<jpoiret>unfortunately, implicit inputs are part of the build system, and each has their own way of adding them
<jpoiret>what's the rationale for implicit inputs though?
<nckx>Convenience, that old hag.
<unmatched-paren>so would rewriting %build-inputs in the gexpifier be impossible in the general case?
<jpoiret>but %build-inputs still works :)
<unmatched-paren>I guess :)
<unmatched-paren>kinda ugly though.
<jpoiret>you could also simply #$package-you-want-to-use
<jpoiret>wouldn't shock me
<jpoiret>i don't think there'd be any downsides, but the derivations wouldn't look the same
<jpoiret>it would add a input to the derivation builder itself, rather than re-use the derivation's inputs
<unmatched-paren>would it make sense to look up the assoc-reffed label in the package's direct inputs and use that ungexped?
<unmatched-paren>it's already going to change the derivation, i think
<unmatched-paren>so -.o.-
<unmatched-paren>Oh, wait: wouldn't package-direct-inputs be equivalent anyway?
<unmatched-paren>#$(package-direct-inputs this-package)...?
<jpoiret>direct inputs don't contain the implicit inputs 🤡
<jpoiret>basically, implicit inputs are *never* present at the package level
<jpoiret>i think they get added to the bag
<jpoiret>have a look at the lower procedure of (guix build-system gnu)
<unmatched-paren>sad :(
<unmatched-paren>so i guess build-inputs stays...
<andrzejku>do you know what this can be? it is happening to my friend who is manually partitioning during installation
<jpoiret>i'd suggest using the latest installer rather than 1.3 first
<unmatched-paren>unfortunate realization:
<unmatched-paren>some arguments like #:make-flags treat quoted arguments as code
<unmatched-paren>others as data
<unmatched-paren>there is no way to tell between the two
<unmatched-paren>i guess i'll just add special cases for each keyword type
<unmatched-paren>nckx: guix style formatter converting `(#:foo bar #:baz quux) to (list #:foo #~bar #:baz #~quux)
<unmatched-paren>i've just realized it's impossible generally :P
<unmatched-paren>so i'll bail out on unrecognised keywords
<apteryx>rekado_: re routing to berlin idrac from node 129, still: "open failed: connect failed: No route to host" anyone at the datacenter? :-)
<f1refly>is anyone here able to have thunar work with gvfs? I installed thunar, thunar-volman and gvfs globally but when I open the advanced settings of thunar it tells me gvfs couldn't be found so thunar-volman can't manage removable media. It's really annoying to mount every flashdrive I insert by hand..
<singpolyma>Would be nice if guix had some way to do "optional store references" maybe...
<singpolyma>I guess it would be hard to get them to line up
<singpolyma>Hmm. And probably shipping a package and package+plugin1 and package+plugin2 and all combinations is about the same. Could probably do it with a macro
<singpolyma>Would need search paths less often
<lilyp>what would be an "optional store reference"?
<pashencija[m]>I have a package as defined here:... (full message at
<raghavgururajan>singpolyma: Regarding, shipping package, package+plugin1 etc., I think lilyp did something like that for gstreamer plugins.
<nij->I'm on archlinux for years and have attempted to join guix. However, packages missing is a problem, and I found it hard to package by myself.
<nij->Recently I learned about docker, and see how it can import an image of archlinux in it..
<jetomit>pashencija[m]: there’s no "DEST =" in that Makefile, so I don’t think that substitution does anything
<nij->Does that mean I can *always* fall back to archlinux whenever an arch package is not made for guix?
<raghavgururajan>nij-: You can start with packaging something small and go from there. Ask away, here, when you get stuck. :-)
<nij->I had a very bad experience back in the days.. it took me 2~3 days and I wasn't sure how I succeeded.
<jpoiret>nij-: well you definitely can use docker, but you're going to lose guix's advantages for those packages
<nij->Actually, I remembered you helping me back then.
<pashencija[m]>jetomit: There is DEST
<jpoiret>ie no rollback, no tracking of dependencies , etc.
<nij->jpoiret what will I miss?
<raghavgururajan>nij-: FYI, Guix can be used on top of any GNU+Linux System, without conflict with system's native package manager.
<jpoiret>and getting docker apps to work properly with the rest of your system isn't easy as well
<pashencija[m]>DEST here
<jpoiret>there are permission issues, you need to share some files with the container, etc.
<nij->that's fine.. I hope I'd use docker for only a few packages.
<nij->jpoiret :(
<jpoiret>it's definitely doable though!
<nij->Cool :)
<unmatched-paren>i'm surprised you found it particularly hard
<jetomit>pashencija[m]: I see. Is that directory supposed to be used independently?
<jpoiret>i think the effort would be better spent on packaging for guix though
<unmatched-paren>maybe that was quite a complex package
<jpoiret>do you have an example of such software that you found hard to package?
<pashencija[m]>jetomit: Yes
<jpoiret>maybe it's rust/go/friends.
<nij->jpoiret ibus-chewing
<pashencija[m]>I don't quite understand why package dir is missing in the store
<bud>nij-: sounds like you want flatpack
<pashencija[m]>Is make install supposed to create it?
<jpoiret>seems pretty straightforward
<jpoiret>well, when you're already a packaging veteran though
<jpoiret>it's always the first step that's the hardest
<jpoiret>pashencija[m]: no, but the build daemon should have created it before starting the build script
<raghavgururajan>nij-: Also, you could ask about the package of interest in guix-devel mail list, to see if any one is working on that already and collaborate.
<bud>docker is more for creating a sandboxed full system environment using containers. flatpacks is (afaik, never used it) containers for single applications.
<jpoiret>maybe it's the source of the cp that doesn't exist
<pashencija[m]>jpoiret: But it does not!
<unmatched-paren>seems like the ibus-* things have minor gimmicks
<jpoiret>flatpak is docker for desktop usage :p
<unmatched-paren>except for ibus-theme-tools they all do something with custom phases
<unmatched-paren>nij-: it took me ages to make my first package taa
<jpoiret>pashencija[m]: can you add a phase before install that would (system* "ls" "-la" "out")?
<apteryx>raingloom: the farthest I've gotten with 'gio mount sftp://[...]' is "fusermount3: mount failed: Operation not permitted "
<apteryx>full log:
<pashencija[m]>jpoiret: I can try
<jpoiret>apteryx: gio is trying to use the store fusermount that's not setuid, right?
<apteryx>ah, perhaps that's it, since I'm testing from a 'guix shell'
<nij->unmatched-paren I can package hello.o, no problem
<jpoiret>do you know if gio tries to use udisks for mounting or does it directly?
<nij->but soon out there are many monsters that require you to dig into what's happening
<jpoiret>if it uses udisks then the fix's going to be hard
<weidtn>In case anybody also has the same cv2 and problem I had in the morning, try pip uninstall opencv-python. Not sure why I had it installed with pip, but now cv2 works!
<nij->and it could take forever..
<apteryx>jpoiret: although, command -v fusermount -> /run/setuid-programs/fusermount
<jpoiret>it could :) but at the end you've got your very own shiny package that works well with guix (maybe i'm embellishing a bit)
<apteryx>in my 'guix shell glib:bin gvfs dbus fuse gnome-keyring -- dbus-run-session bash' environment
<jpoiret>apteryx: right, but i'm thinking that either `gio` or `gvfs` was patched to use direct store references rather than look in the PATH
<raghavgururajan>What is the software/program of interest, nij-? May be that'll help us to guide better.
<jpoiret>that or it's udisks running the command, so it doesn't inherit your env variables (it's a dbus service)
<nij->raghavgururajan back then it was ibus-chewing
<nij->at the end someone helped me for the key five lines
<nij->and it was clear to me that I couldn't have come up with those five lines at all
<pashencija[m]>phase `check' succeeded after 0.0 seconds
<pashencija[m]>starting phase `ls-la'
<pashencija[m]>ls: cannot access 'out': No such file or directory
<apteryx>jpoiret: it should inherit here since I'm testing from a 'dbus-run-session' D-Bus session in my shell
<jpoiret>but udisks runs on the system bus, not the session one
<jpoiret>(at least i think it does)
<jpoiret>it needs root privileges to mount, so the session bus would be too late to get them
<nij->The result was here, raghavgururajan
<pashencija[m]>Oh I think it should be not "out"
<nij->I never published it to the official.
<nij->actually I tried, and the process was also very hard and unpleasant
<jpoiret>you should try looking at /proc/<pid>/env
<raghavgururajan>" it was clear to me that I couldn't have come up with those five lines at all" <-- Totally normal. That's why we work and be as a community. :-)
<pashencija[m]>jpoiret: why should there be out directory at all?
<apteryx>jpoiret: so the only way to test this is installing the gio related stuff at the level of my operating-system packages, reconfigure & relogin?
<nij->raghavgururajan I see.. maybe I had the wrong goal.
<jpoiret>pashencija[m]: well, (assoc-ref outputs "out") rather
<jpoiret>i was just lazy to type out the full thing
<raghavgururajan>We help and learn from each other.
<jpoiret>apteryx: tbh, I would rather strace udisks for some execve("fusermount"), to see if it's the one responsible for that
<jpoiret>if not, then it's not the issue
<nij->got it..
<nij->raghavgururajan also, I use emacs.
<pashencija[m]>phase `check' succeeded after 0.0 seconds
<pashencija[m]>starting phase `ls-la'
<pashencija[m]>ls: cannot access '/gnu/store/cpa5cha56gs4gskxma12w2syb1f1j8js-seeed-reterminal-dtoverlays-1.9': No such file or directory
<jpoiret>the process is pretty annoying at first, i agree
<nij->And there are many packages of emacs out there. In fact, I'm using a popular distrobutio that's called doomemacs.
<pashencija[m]>jpoiret: store dir does not exist
<nij->It has its own logic for its package, so I find it hard to have my emacs env in guix.
<nij->Is there any way out?
<jpoiret>maybe i'm wrong and the store dir isn't created by the daemon ☠️
<raghavgururajan>nij-: Nice!
<raghavgururajan>Ah, about the env, not sure.
<pashencija[m]>jpoiret: Soooo
<pashencija[m]>How is it supposed to be created?
<jetomit>pashencija[m]: I've never had to do that with gnu-build-system, but apparently you can (mkdir-p out) in some phase, that seems to work
<apteryx>jpoiret: udisks does "execve("/gnu/store/dmjbgh90mnbykwfdszpkxymjl0cc4lhz-profile/bin/gio", ..."
<apteryx>that profile is that of the guix shell I'm working from
<jpoiret>pashencija[m]: well, manually then, you can add a phase before install that just does (mkdir-p (assoc-ref outputs "out))
<jpoiret>can you trace the child for the execve as well?
<Air4x>Was some of you able to use the arc theme on wayland? I installed the arc-theme package but lxappearance doesn't find it
<pashencija[m]>jetomit: mkdir-p worked! Thank you!
<raghavgururajan>apteryx: May be this snippet is no longer working for current versions?
<apteryx>raghavgururajan: I verified, that part of the code hasn't changed since 2019, should still work the same
<apteryx>FUSERMOUNT_DIR is correctly set to /var/empty per our substitution snippet
<apteryx>jpoiret: nevermind about the execve of gio I reported above, this was PEKCAK, this isn't executed by udisks
<unmatched-paren>nij-: yeah, there is the occasional stupid package
<unmatched-paren>loaks like you got unlucky with that one
<unmatched-paren>it seems really complex
<apteryx>jpoiret: ah! it could be that it's using fusermount3, not fusermount
<apteryx>fusermount is in my setuid-programs but not the later
<lisplif>Is there a way to install Golang v1.18 using GNU/Guix?(Sorry this is my first time in IRC channel)
<nij->unmatched-paren Yeah.. how often did that happen to you in your experience? unmatched-paren
<apteryx>hm, aren't /run/setuid-programs supposed to be updated upon reconfiguring the machine?
<rekado_>apteryx: nobody is at the data centre this week
<apteryx>OK, thanks for the info
<unmatched-paren>nij-: most packages are well behaved ime
<unmatched-paren>but some are tedious because of dependency count
<apteryx>nckx: I tried this diff:, and reconfigured with sudo -E ./pre-inst-env guix system reconfigure my-config.scm, and fusermount3 still isn't in /run/setuid-programs
<apteryx>ah, probably because 'fuse', the variable, has no fusermount3
<apteryx>I would have preferred it to error out
<jpoiret>fusermount3 is in fuse@3 i think
<jpoiret>which is not the default version methinks
<nckx>Erroring out is terrible at boot.
<apteryx>a grep of 'fuse' in the 'sudo sudo strace -p31970 -s600 -ff -odbus-daemon.strace' produced strace files on dbus-daemon
<nckx>Is the problem, I ttink.
<apteryx>nckx: oh, I hadn't thought about this code has to dynamically run at boot
<apteryx>I thought it'd persist on disk until the next reconfigure
<nckx>I have a setcap patch I still need to submit, and managed to break my boot because it *didn't* ignore errors.
<apteryx>forgot the link:
<nckx>apteryx: I don't think that's good either, but nothing feels great here TBH.
<apteryx>indeed /run doesn't sound like a safe place persist
<apteryx>to persist*
<apteryx>OK, putting fusermount3 in setuid-programs got me closer
*nckx has /run on a tmpfs; Guix is already odd for not(?) doing so by default.
<nckx>But aside, I think Guix should persist nothing across boots like that.
<nckx>Reconfigure should not be magic.
<apteryx>yes, I agree with being as stateless as possible
<apteryx>I think I got the gio mount to work, but where does it mount? it doesn't accept a mount point
<apteryx>'mount' says on /run/user/1000/gvfs
<apteryx>yep, something odd like "/run/user/1000/gvfs/sftp:host=raisin,port=6666/"
<apteryx>shocking thing is that it was working without it when using GNOME
***mark_ is now known as mjw
<tex_milan>Hello all, does vlc works for you? It crashes for me always when I try to play any video:
<tex_milan>libva info: VA-API version 1.13.0
<tex_milan>libva info: Trying to open /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8/lib/dri/
<tex_milan>libva info: Found init function __vaDriverInit_1_13
<tex_milan>Segmentation fault
<tex_milan>VLC media player Vetinari (revision 3.0.13-8-g41878ff4f2)
<podiki[m]>works for me (just tried)
<podiki[m]>also on amd hardware, though not using linux-libre, in case that is mattering here (since it is trying hardware decoding)
<tex_milan>I am on amd hardware too, not using linux-libre too.
<tex_milan>Thread 56 ".vlc-real" received signal SIGSEGV, Segmentation fault.
<tex_milan>[Switching to LWP 24472]
<tex_milan>0x00007ffeed7cea47 in read_var_list () from /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8/lib/dri/
<podiki[m]>hmm... I don't think I did anything special for libva or anything like that, just tried vlc now through guix shell vlc and it worked for the random video I had
<tex_milan>maybe something withe mesa?
<podiki[m]>same mesa hash here too, so should be the same
<podiki[m]>I haven't guix pull'ed or reconfigured in a few days, but am pretty current
<tex_milan>i did just now
<tex_milan>i remember it worked some time ago
<podiki[m]>perhaps some vlc options? like I said, I haven't done any configuration so it is all the defaults for me
<tex_milan>I have no special configuration for that too
<podiki[m]>perhaps try some other video files for comparison? or if there is one publicly accessible that gives this error I could also test
<tex_milan>mplayer works fine, just installed and tested it
<tex_milan>problem won't be in the video file. i tried couple with same result
<tex_milan>anyway thanks for try, I guess I'll stick with mplayer until that solves itself after some update (hopefully).
<podiki[m]>mplayer also using libva?
<podiki[m]>sorry we didn't figure out anything, could always submit a bug report
<tex_milan>good question about libva. I don't know how to check it.
<podiki[m]>or maybe something else that uses libva
<tex_milan>milan@t14s ~/guix-config [env]$ vainfo
<tex_milan>libva info: VA-API version 1.13.0
<tex_milan>libva info: Trying to open /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8/lib/dri/
<tex_milan>libva info: Found init function __vaDriverInit_1_13
<tex_milan>Segmentation fault
<podiki[m]>yes, was just going to suggest that
<podiki[m]>while that works for me
<podiki[m]>you said you did a guix pull recently, and also a reconfigure? and reboot/relogin?
<tex_milan>well, i did update yesterday and restarted and crash was there. today i just did update and no restart. well, yes, will try what happens after restart
<tex_milan>the same crash after restart
<podiki[m]>not sure what changed very recently, xorg server maybe?
<podiki[m]>you could always roll-back or use timemachine to narrow down what commit did it
<nij->I got disconnected.. anyone here uses guix in daily machine?
<rekado_>nij-: many of us.
<drakonis>many of us.
<drakonis>could've snuck some "we are legion" joke
<nij->What do you do when you need a package right now, but it's just too hard to package?
<nij->(and suppose that it's packaged for arch or debian)
<drakonis>i think someone was doing some fhs thing
<mlan>Hello Guix.
<nij->Hmm how about "many of us" here? What did you really do to overcome the situation?
<jpoiret>usually, either I try packaging it, or just toss it aside if it's too complex to package
<nij->But if you *need*, do you go to another machine that has, arch, for example?
<jpoiret>well, I had a dual boot arch for a bit
<jpoiret>but guix is too good
<jpoiret>I even stopped using protonmail because of this (the IMAP bridge is in Go, and is too annoying to package)
<nij->jpoiret Does dual boot mean that both OS can be running at the same time?
<nij-><3 <3 > guix is too good < I'd like to be capable of enjoying that too!
<jpoiret>no, you would choose at boot which os you'd like to boot
<jpoiret>but if those packages are too important for you, i'd suggest running guix on top of arch
<jpoiret>you won't have the benefits of guix system, but then you'll be able to use arch
<jpoiret>(un)fortunately, another solution would be to use flatpak on guix
<jpoiret>if your application is packaged in flatpak
<nij->or docker?
<nij->yeah, I'm actually curious how feasible that would be
<nij->at least as a fallback
<jpoiret>or docker, although that's a little bit harder to use for desktop apps i'd say
<nij->in the long run I expect I'd learn how to package
<jpoiret>more manual fiddling involved, but it's doable too
<nij->Why is it harder?
<nij->Isn't anything running in a container? WHy would docker be harder?
<jpoiret>flatpak was made with the idea of a "universal packaging and sandboxing solution, distro-independent" while docker is more of a developer CI and isolation solution
<jpoiret>ie apps packaged for flatpak should work out of the box, whereas with docker you'll have to configure the containers so that they can access what they need (and it'll create more friction compared to flatpak)
<nij->!! Does that mean I can run an app for windows on guix?
<jpoiret>flatpak is used by some distributions as an alternate package manager (a shame really)
<jpoiret>no, we're still talking linux-only
<jpoiret>for windows, you'll need wine or a whole VM
<jpoiret>both flatpak and docker use the same OS technologies, linux namespaces, that create isolation
<jpoiret>guix also uses them to isolate builds
<jpoiret>on top of that, docker and flatpak have some kind of "layer filesystem archiving" technology, to be able to store distributions efficiently
<nij->I see. I think it's about time for me to try guix (once) again
<nij->has failed for several times xD
<jpoiret>I had to force myself at the beginning, and I started really using Guix when I forbid myself from using arch
<jpoiret>the learning curve is pretty steep, even compared to some other distros like Gentoo
<jpoiret>arch is quite simple compared to them
<nij->Why is it harder than Gentoo? There you need to package all of your stuff, right?
<jpoiret>at least, the distro-specific part
<jpoiret>you need to package all of your stuff in every distro though? I don't understand
<jpoiret>unless you're talking about the distros that are trying to switch to flatpak+flathub as default
<nij->I don't package at all in arch. I use pacman and yay.
<jpoiret>well, someone else has packaged it for you then
<jpoiret>in gentoo it's the same, and nix, arch, debian, etc... too
<jpoiret>the difference is just the distro size, number of users and hence number of packages
<nij->Yeah. On the day guix having a large community, what difficulties will remain?
<nij->(I'm trying to see if there's any intrinsic difficulties.)
<jpoiret>well, packaging requires more work than for traditional distros
<jpoiret>but if distros like guix and nix gain some more traction, they could influence upstream packages themselves so that they're easier to package
<nij->But once a guix package is packaged successfully, it will work *forever*, right?
<AhmedNabil[m]>The download latest iso page didn't work
<rekado_>nij-: only if you stick to that particular version of Guix.
<nij->After upgrading guix, we need to repackage all packages?!?!
<jpoiret>no, just that something _might_ break, for example if the dependencies are updated, or the build systems, etc.
<jpoiret>the same as on other distros
<jpoiret>although on Guix the problems appear more readily
<nij->However, in the definition of a package, the dependencies are also fixed right?
<jpoiret>well, the dependencies are fixed to some other Guix packages
<jpoiret>so if we update the packages that are used as dependencies to another one, the latter might break
<nij->The older versions of packages do not stay in the registry?
<jpoiret>there's no "registry" in guix
<AhmedNabil[m]>The download latest iso page didn't work
<nij->uh.. sorry. Channel?
<jpoiret>AhmedNabil[m]: you can use
<nij->The older versions of packages do not stay in the official guix channel?
<jpoiret>nij-: guix packages are simply a part of the guix source code. Everything is declared in scheme. We don't have something similar to a database of packages
<AhmedNabil[m]>Thanks for your help
<jpoiret>sometimes, guix keeps around older versions of some packages (often only major versions, ie python 2 and python 3, although python 2 is being phased out now) because those often differ greatly
<jpoiret>like gtk3 and 4
<nij->jpoiret: I see, so if I keep the older guix source code, the package will work forever..?
<nij->I see.
<jpoiret>but if say gtk4 gets updated from 4.1.2 to 4.1.3, 4.1.2 will disappear from guix. But guix has the ability to roll-back its source and even time-machine to other commits
<jpoiret>so basically, you don't even have to keep the older guix source code, as long as you have the commit, you can `guix time-machine --commit=<sha> -- do something with old guix`
<jpoiret>i mean, most other distros don't keep around older versions of packages either
<jpoiret>i'm thinking about other rolling release distros, like arch
<jpoiret>downgrading a package there is a nightmare
<nij->Say I want to downgrade a package A in guix, after time machining, can I still use the latest version of B?
<jpoiret>since guix packages are (mostly) isolated from each other, you won't have conflicts like on other distros
<nij->How does that work (version mixing)?
<jpoiret>you may have to be a bit careful with where they're available, if they don't conflict with each other, etc...
<jpoiret>i'd suggest you look at the manual, especially
<nij->Hmm.. I once thought a package will work forever once packaged in guix..
<nij->used to*
<nij->What are some nightmares in other distros that are not the case in guix then?