<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>Also, Sway has some issues starting: “XDG_RUNTIME_DIR is not set in the environment. Aborting.”. <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. ***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 https://paste.debian.net/1247149/). 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? <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 <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
*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 libgl.so.1 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>But there is no libgl.so.1 in .guix-profile/lib/ <PurpleSym>weidtn: Does it work in the `guix shell` above? I can’t see any dependency of opencv on mesa/OpenGL. <PurpleSym>What’s your Guix version (via `guix describe -f channels`)? <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? <PurpleSym>All of it. You can use that output to feed it into `guix time-machine -C` to get the exact environment again. <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 libgl.so.1 , doesnt it? <andrzejku>but it complains that remove is unboud variable <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> 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. <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: https://paste.debian.net/plainh/54725c60 — 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 <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>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>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 <jpoiret>networkmanager and udisk are too useful though <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-. <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.' <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>It is still #f by default. ***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 <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) <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. <nckx>(modify-services %desktop-services (gdm-service-type config => (gdm-configuration (inherit config) (wayland? #t)))) <nckx>That is from memory and may be bugsy. <jpoiret>because yes, you WILL need a whole javascript engine for that <jpoiret>and it's something that was added at a later stage <jpoiret>ie not an initial bad design decision <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? <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. <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>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? <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). <unmatched-paren>and i'm sure there are several --inefficient-- mouse-based text editors in guix <nckx>Does vim not support mouses? <bud>yeah, i saw emacs even got a tab bar now :D <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. <bud>i don't understand why i would run a graphical application like a text editor, inside a terminal emulator. <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. <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). <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? <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 <bud>there are lots on youtube. just opened a playlist with 6 hours craft your system with guix (system crafters) <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 <jpoiret>you used `guix package -i foot`, right? <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 <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 <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? <jpoiret>well, for guix system you'll likely have to rewrite the whole thing <jpoiret>just packaging systemd will be a beast i think <jpoiret>and systemd will likely not want to cooperate with Guix's shenanigans either without some modifications <jpoiret>bud: do you rely on some systemd-specific features, or is it just convenience? <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 <jpoiret>that is, you just autolaunch xorg with a user systemd service file right? <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>we could carry a downstream patch (that we could upstream) to be able to customize the notifier <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 <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 <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>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>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>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 <jpoiret>bud: yes, it's really simple to do such a thing <jpoiret>i've ran modified versions of packages in the past <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 <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 :) <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 <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 <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 <jpoiret>you don't need to clean-up dependencies <jpoiret>guix will always keep what is needed and remove what is not <jpoiret>also, there are no "build time" and "run time" dependencies in Guix if you will <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 <jpoiret>propagated-inputs is more like bandaid for when we don't really achieve clear separation <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>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>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>your system declaration contains some services that pull in pam <andrzejku>well in my case swaylock complain that I have to set setuid <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? <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 <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>(use-modules (gnu system setuid)) doesn't import setuid <jpoiret>what do you mean? you get an error while running `guix system reconfigure`? <jpoiret>what's `guix describe` and `command -v guix`? <andrzejku>I am running guix from my home .config directory <nckx>jpoiret: What's the 'setuid' you both mention? <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)) <nckx>andrzejku: Despite already doing so? <jpoiret>the bane of all programmers in existence <jpoiret>unmatched-paren: there's no uniform way for build-systems to signal their implicit inputs <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 <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") <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>you could also simply #$package-you-want-to-use <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? <jpoiret>direct inputs don't contain the implicit inputs 🤡 <jpoiret>basically, implicit inputs are *never* present at the package level <jpoiret>have a look at the lower procedure of (guix build-system gnu) <jpoiret>i'd suggest using the latest installer rather than 1.3 first <unmatched-paren>nckx: guix style formatter converting `(#:foo bar #:baz quux) to (list #:foo #~bar #:baz #~quux) <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>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 <lilyp>what would be an "optional store reference"? <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. <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 <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. <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 <jpoiret>do you have an example of such software that you found hard to package? <pashencija[m]>I don't quite understand why package dir is missing in the store <bud>nij-: sounds like you want flatpack <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 <jpoiret>flatpak is docker for desktop usage :p <unmatched-paren>except for ibus-theme-tools they all do something with custom phases <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 " <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 libgl.so.1 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 <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>it needs root privileges to mount, so the session bus would be too late to get them <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. :-) <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 <jpoiret>apteryx: tbh, I would rather strace udisks for some execve("fusermount"), to see if it's the one responsible for that <nij->raghavgururajan also, I use emacs. <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. <nij->It has its own logic for its package, so I find it hard to have my emacs env in guix. <jpoiret>maybe i'm wrong and the store dir isn't created by the daemon ☠️ <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 <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 <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>ah, probably because 'fuse', the variable, has no fusermount3 <apteryx>I would have preferred it to error out <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. <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>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>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: Trying to open /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8/lib/dri/radeonsi_drv_video.so <tex_milan>libva info: Found init function __vaDriverInit_1_13 <tex_milan>VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2) <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>0x00007ffeed7cea47 in read_var_list () from /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8/lib/dri/radeonsi_drv_video.so <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 <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 <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]>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. <tex_milan>libva info: Trying to open /gnu/store/lcqz4q3834bjd3dlc8zsr95mvzz9n006-mesa-21.3.8/lib/dri/radeonsi_drv_video.so <tex_milan>libva info: Found init function __vaDriverInit_1_13 <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 <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? <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 <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>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->yeah, I'm actually curious how feasible that would be <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->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>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>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? <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>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? <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 <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 <nij->jpoiret: I see, so if I keep the older guix source code, the package will work forever..? <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... <nij->Hmm.. I once thought a package will work forever once packaged in guix.. <nij->What are some nightmares in other distros that are not the case in guix then? 