<SamSam>Hey guys just finished with fresh install, didn-t mess with config yet so I tried opening terminal but couldnt, does guix come with any terminal installed? <trevdev>SamSam: Really depends on how you went about installing it. If you chose a desktop flavor, you may have the shell that comes with it. <trevdev>I installed initially with the gnome-desktop-service-type, and thus got gnome-terminal out of the box <trevdev>On another note, I am looking at contributing an update to sbcl-stumpwm-screenshot and discovered that *all of these contrib modules* depend on the current upstream checkout of stumpwm-contrib. I'm not the best at common lisp (yet), so I'm nervous about just updating stumpwm-conrib willy-nilly. <trevdev>As this would cascade to all of the other modules and if things break, I won't see it and I am not prepared to test every single module. <trevdev>Should I think about contributing each module as its own check-out version of the original source instead? <SamSam>trevdev: I installed it with awesome <trevdev>I don't think there's an awesomewm-home-service yet, so nothing would bundle with it? Feel free to correct me if I'm wrong <SamSam>Yup all pretty much empty, so without terminal got no clue how to proceed <trevdev>CTRL+ALT F1-F10 might drop you out of the display manager <trevdev>Nice, now you might be able to fix something <trevdev>Kitty is great if you haven't tried it yet ;) <SamSam>Thanks a bunch will check it out :D <trevdev>No prob. Not that it's too terribly useful, but you can get images in the terminal with kitty which feels nuts. `kitty +kitten icat /path/to/image.jpg` <trevdev>But the winner for me is the dead simple configuration file <kaelyn>Has anyone here used kexec with guix, e.g. for fast reboot? <nckx>kaelyn: Well, on Guix, but not with Guix. There's no OS integration or graceful shutdown of file systems or services. <nckx>It's no substitute for normal reboots (yet). ***rekado_ is now known as rekado
<SamSam>Guys how do I shift from awesome to lets say gnome or other managers after install? :D <MikeDelago>For packages in the main guix channel, is Guix strictly source based? There's a program I'm interested in installing, but unfortunately the version of rust required to build it from source (1.60 or above) hasn't been merged yet <vagrantc>MikeDelago: yup, has to be built from source <vagrantc>MikeDelago: there might be newer versions of rust on the core-updates branch <MikeDelago>vagrantc: rgr that. It looks like core-updates has 1.60 so that should be fine. Worst case scenario I <MikeDelago>vagrantc: rgr that. It looks like core-updates has 1.60 so that should be fine. Worst case scenario I'll throw the binary in my personal channel <vagrantc>MikeDelago: core-updates may not have much in the way of substitute coverage ... i don't think core-updates is actively being worked on right now, but happy to be demonstrated incorrect :) <MikeDelago>vagrantc: all good. I'm not 100% familiar with switching the branch, but I did a `guix build rust --with-latest=rust` and it using 1.58, which isn't in master yet <SamIaM>Where are the files from command like guix install package stored on hdd? <nckx>The actual data (build results) of each package is stored in /gnu/store/<hash>-package-name-version/, as is source code for paccckages you built locally. The hash is not humanly predictable. Commands like ‘guix install’ also create a number of symlinks in /var/guix/{profiles,gcroots} but most importantly ~/.guix-profile — this is what variables like $PATH actually point to, and what makes a c <nckx>ommand suddenly available after you install it. <nckx>Basically, 99.999%* of Guix files are in /gnu/store, and most that aren't are just symlinks to it. <nckx>* super scientific number. <SamIaM>Thanks again, helps out to figure things out <SamIaM>Just a curiosity would it be able to put all files to user specific folder on portable hdd so as in when you plug out hdd everything is gone aka host is completely clean :D <vagrantc>you could put the entire /gnu/store there, and then you'd just have a bunch of dead symlinks <nckx>Completely clean? No. If you're not using Guix System but a different distribution, you could mount /gnu separately, and unmount it when you're not using any Guix software, but the symlinks would still be in those other locations I mentioned. <vagrantc>you'd have to be careful to not run commands while /gnu/store wasn't present <nckx>If you're running Guix System, unplugging /gnu would crash your system, since every system file on your system would suddenly vanish. <nckx>Yeah, I didn't even mention the horrible horrible fun that happens if /gnu and /var/guix/db/db.sqlite get out of sync. Guix will happily trust the bogus DB, say ‘whelp this glibc directory obviously shouldn't be here’, and totally hose your system. Even when you're not running GC. <nckx>I might have been there. I'm not telling. <nckx>(That it happens on basically any store operation, even those you thought are append-only, was a surprise.) <SamIaM>Oh haha thats quite a sceneario, so if thats the case could it be possible to run guix from external hdd, any hits on performance? <nckx>Whatever the speed difference is. If you're connected over eSATA it won't be slower than internal SATA. Since you'd probably be using USB, I think seek times would suffer even on high-speed links. <nckx>But the chance of accidental disconnection would be the real problem. You wouldn't even dare look at that cable whilst the system was running. Linux doesn't just pretend nothing happened if a drive disconnects even for a fraction of a second; the mount is just gone. I wouldn't do it. <nckx>But there's nothing technical stopping you from doing it, and even bind-mounting the store & DB to different places from the same HDD. *nckx is out of words, the room sighs with relief. <SamIaM>Damn you are like a library :D Thanks nighty night <SamIaM>vagrantc: When nckx mentioned accidental cable disconnect and saying that mount is gone, does it mean all is deleted on eSATA? <vagrantc>if it gets unmounted, not deleted, per se, but Bad Things(tm) might happen <vagrantc>bind-mouting various things so it's all on the same media sounds pretty smart. <SamIaM>Oh thats cool didnt know about it, thanks a bunch :D <yuu[m]><nckx> "yuu: Did you start cow-store..." <- by that you mean `mount --bind /gnu /mnt/gnu`? or something else? <trevdev>yuu[m]: They are probably referring to the copy-on-write store (cow-store) *iyzsong sent lxqt update patches ***wingo_ is now known as wingo
***Dynom_ is now known as Guest8814
<yuu[m]>nckx: oh you meant`herd start cow-store /mnt`. i forgot this step after too much restarting vm (i did took note but i just forgot about it). anyway, i upgraded the vm to 6GiB, and 3GiB / was enough: it took ~2.6GiB <yuu[m]>"guix system: bootloader successfully installed on /efi" 🎉 <abrenon>how bad is it considered to clutter the shell environment with search paths ? <abrenon>can that mechanism be used to pass the path to static resources (typically in share/) to a script (typically in bin/) ? <abrenon>or would it be better to simply have a regular gnu-build-system, passing the output prefix to hard-code it directly into the script ? <abrenon>because I have this package which is essentially stuff to copy, except that I need the script to know where to find the data <rekado>got this message from IT: “Due to unexpected problems with today's network maintenance, MDC IT services continue to experience disruptions.” <rekado>if there are problems with ci.guix.gnu.org this would be the most likely cause <yuu[m]>i chroot like in the troubleshooting guide and `/gnu/store/ywshrqcyj76dqjkrbqlj0x7564q34h0n-guix-1.3.0-28.c23e0aa/bin/guix-daemon --build-users-group=guixbuild --disable-chroot &`. but then `/gnu/store/ywshrqcyj76dqjkrbqlj0x7564q34h0n-guix-1.3.0-28.c23e0aa/bin/guix system reconfigure /etc/yuuguix/yuuguix.scm`: `accepted connection from pid 550, user 0`\n`guix system: error: the group `guixbuild' specified in `build-users-group' does not exist`. <yuu[m]>hm probably because i didn't source `source /home/USER/.guix-profile/etc/profile`, and `source /home/USER/.config/guix/current/etc/profile`? but guix system init didn't create anything in /home <rekado>FYI: “The cause of the network disruption has been found and the problem has been fixed. All IT Services are available again.” <rekado>yuu[m]: the error says there is no group named “guixbuild”, but you’re asking the daemon to use that group. <rekado>that’s nothing to do with environment variables. <Msavoritias>This is during the initial guix pull. When I am running guix describe it shows: guix describe: error: failed to determine origin <Msavoritias>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.3.0. <Msavoritias>I would just like to know if this is a known issue that happens in guix or if its a ubuntu specific problem <yuu[m]>rekado: using guixbuild is just what the Guix manual toubleshooting with chroot says. well i was able to find the profile in the store directory and source that, but didn't make a difference just as you say <yuu[m]>rekado: and the guix-daemon in the live image uses guixbuild, so i don't see why in chroot it cannot. <tschilptschilp23>What's confusing me, is that this code runs on Debian-11 with gcc-10.2, guile-3.0.5, and gnuplot-5.4 without any problems. Running it on guix (~guix shell gcc-toolchain gnuplot make~) results in an empty gnuplot window, that dies on running ~(tortoise-reset)~ though. <yuu[m]>rekado: probably because in guix init system it doesn't create the group guixbuild by default; maybe the manual is assuming the user installed from the usual graphical installation which probably creates that? <abrenon>MSavoritias: I haven't managed to reproduce because there are substitutes for openssl <abrenon>yeah, if this guix has never been updated and is still on 1.3.0, there aren't any substitutes any longer <abrenon>as in, guix, the command itself and its packages definitions <MSavoritias>well now i installed it with the shell script from the guide <MSavoritias>that should give me the latest one from what I can see <abrenon>which guide ? (I'm not familiar with all the documentation) <MSavoritias>I used the shell installer script now so hopefully it will be able to pull <abrenon>so you've followed all the guide, and guix seems to be properly installed, but then you can't install openssl because your old version is missing binary substitutes and apparently the compilation fails for that version ? <MSavoritias>i installed the guix 1.3 package from ubuntu. and the initial guix pull fails with the openssl error i showed <MSavoritias>i am thinking maybe the problem is the ubuntu package <abrenon>ohhh so you're not trying to install openssl directly, I understand now <MSavoritias>yeah. its the initial git pull so i can get up to date. but it fails :( <abrenon>I don't know how to solve this, there must be a way to bypass this but I don't know how <yuu[m]>is there a way to force guix/guix-daemon running as root? <yuu[m]>(context `guix perform-download: error: refusing to run with elevated privileges (UID 0)`) <abrenon>I'm confused, though: how did you get a more recent version ? if guix couldn't update itself ? <MSavoritias>yeah :) I removed guix from ubuntu and did the shell script install from the page I sent you. <abrenon>ohh, you mean the script mentioned at the top of the page gets a more recent version than the step-by-step explanations on the same page ? <MSavoritias>then I had substitutes. I wonder if the issue with openssl was only for me or if it actually fails tho <abrenon>we could determine that by trying to rebuild on another machine if we knew the exact version your old guix was at <abrenon>if you had typed "guix describe" before reinstalling with the script <MSavoritias>it didnt work. I tried guix describe but it showed an error. <abrenon>I don't think guix is supposed to be able to perform a pull to describe itself <abrenon>and I still don't see how the script can retrieve a more recent version that 1.3.0 according to what's on the "ftp" <abrenon>so you installed following the step-by-step process which is supposed to retrieve the same 1.3.0… <yuu[m]>guess i'll have try installing from scratch again, but if then it errors to boot again i'll won't be able to chroot just like now... there's 2 major issues i found so far: guix system with isn't able to mount btrfs `partition` on `/` using noatime, and no guixbuild group for chroot if installing with `guix system init` <abrenon>that's still a problem if people deciding to follow the process step by step end up stuck because of some mysterious difference with the script <tschilptschilp23>I've seen this 'no origin' error at 'guix describe' as well when running guix system vm a while ago. <abrenon>I'm going AFK but I'll check the logs when I'm back <pkill9>tfw you fix broken icons through a simple installation of a package *tschilptschilp23 watches texlive-texmf being redownloaded after changing system locale... *tschilptschilp23 thinks about reading up on guix gc again *tschilptschilp23 will not run 'guix gc' without arguments again <rekado>tschilptschilp23: just add a GC root for texlive-texmf and it won’t ever be collected <rekado>also: consider using the modular texlive <tschilptschilp23>rekado: thanks. I should certainly go for the modular texlive, as I'm using latex pretty much only for rendering org-files to pdf... <nckx>yuu[m]: ‘noatime’ isn't a valid option. Remove it from options and add it to flags, or you'll end up in the exact same place a day poorer. <nckx>cnx: If there's been no progress for a week or two, pinging here is fine, as is sending a follow-up to 56705@. <nckx>yuu[m]: Since there are only a fixed number of hard-coded mount flags (whilst mount options are free-form strings), we can detect when the conventional name for a flag is passed as an option and raise a warning/error. I'll take a look. <yuu[m]>nckx: i see. but i'm confused about options and flags. what is the difference? does mount itself makes a difference? man 8 mount just call it `FILESYSTEM-INDEPENDENT MOUNT OPTIONS` <yuu[m]>nckx: guix info/manual says `for details and run ‘man 8 mount’ for options for various file systems` <nckx>It could add ‘and mount(2) for flags’. <nckx>Flags are literal bit flags that are or'd together when calling mount(). Options are just strings with no formal standardisation; each file system parses them and interprets them freely. <nckx>…except 'shared, which is of course a special snowflake :-/ <drakonis>nckx: noatime is a valid filesystem flag iirc <drakonis>probably not on guile but what it does is not update when a file was last accessed <nckx>Oh is that how it works? 😛 <drakonis>it has unintended consequences for dealing with applications that look up this kind of file metadata <nckx>noatime (Guix: no-atime)? Yes. relatime has been the default since kernel $forever though, so the relative advantages aren't what many people think. It saves a few writes, sure, but only in specific cases. <drakonis>the majority of distros still default to it when generating fstab files <nckx>And applications are right not to support noatime, it's the -funroll-loops of mount options, so it's always a gamble. <nckx>drakonis: Because SPEEEEEEEED. <nckx>Also they read it in a wiki once. <nckx>(I'm not referring to anyone here; I use no-atime myself, but I also write software that assume atime isn't broken. Caveat admin, that's your job.) *abrenon checks her mount options for noatime <abrenon>apparently, my arch days are well over <abrenon>(also, why do you use no-atime yourself if you write software that relies on it ?) <nckx>Hullo (all, I forgot to say good morning). <nckx>abrenon: Ah! Because I am a wonderfully complicated human bean. <nckx>But mainly because it's set only on a specific file system that actually noticably benefited from it, and which is only used for a specific thing. <abrenon>I used to have noatime on pretty much everything, without any specific reason, never having noticed any specific bottleneck to fix… ^^' <nckx>The context might've got lost (and I didn't stress it enough myself), though: there's nothing wrong with noatime, it makes perfect sense for a human to set. Not distributions abusing their position of power over defaults. <abrenon>yeah, if said human is using it as a solution to a problem and can expect an improvement from it <mrvdb>Is someone working on rust for the powerpc64le platform? rustm (bootstrapping compiler) is apparently not supported and everything upwards for rust depends on it. (and many things seem to depend on rust) <nckx>mrvdb: Did you ask on the ML as well? <nckx>It's up to you, but I think that it will increase the odds of receiving an answer. <nckx>Nothing wrong with asking here too. <mrvdb>will do. rust not building is now a holdpoint for quite a few packages for me. I think I'll start with a bug report on the build and take it from there. Thanks. <nckx>And thank you for making me idly glance at guixp9, see it was idle, and restart the cuirass-remote-worker. <nckx>(.service, because it still runs Debian. Madness.) <mrvdb>is that the powerpc64 builder? <nckx>It's provided for free by OSUOSL. I think we could ask for more, but it wouldn't make much sense yet. <mrvdb>i need to study cuirass a bit, the web pages dont make much sense to me yet. <nckx>If anyone disagrees and finds that the lack of CI hardware is slowing down the porting effort, do let me know, we can always talk to them. It just doesn't look like that to me. <apteryx>mrvdb: info cuirass is a good starting point <nckx>mrvdb: Anything specific you need? Note that Cuirass doesn't present that much data. ‘No’ may well be the answer. <mrvdb>nckx: my main need for the moment is just a status page for things that /should/ build and things that break on the builds, so I have some reference for things that break locally. most of the things happening turn out to be some local issue <nckx>apteryx: I'm probably not going to be able to restart berlin today, but I still want to do it before Shepherd locks up again. <mrvdb>apteryx:after i solve my guix related info issues, no doubt ;-) (some path problem I guess) <nckx>I don't get the ‘should build’ nuance. <rekado>I’m trying to let shepherd launch a generated /gnu/store/…-run-container script. It doesn’t return the right PID, though. Any ideas on how to launch a container script from shepherd? <mrvdb>there are things that break on my machine which I suspect are my own fault, if I see the builde succeed, I know its very likely I did something wrong <nckx>I wish status: supported ‘newly-failed’ or something, but maybe there's another way to query that. <mrvdb>nckx: that list I have looked at, but I see everything fail there?, which doesn't make sense, or? <nckx>There should be a pop-down when you focus the search box. <nckx>I see everything being either scheduled (pending) or succeeded. <mrvdb>which has all yellow things,which indicate? waiting? now there are two successes, that's because you restarted the builder? <mrvdb>ah, ok. yes, that page is then useful for me. are all packages queued automatically? <nckx>If a package from upstream Guix would fail on your machine, you could search for ‘PACKAGE-NAME system:powerpc64le-linux’ and click on the most recent (top) build ID for the right package (in case multiple packages match the name. <mrvdb>right,that makes sense, especially with the list of what is building. I dont think I ever saw that <mrvdb>a column with 'queued since' would be useful i think <nckx>Cuirass pulls the upstream repository every N minutes, and calculates all packages. That's an ‘evaluation’. Each evaluation will spawn new builds for each new or changed package. So the time of the evaluation is when all its builds were scheduled. <nckx>You'll eventually get used to most of Cuirass' UI quirks. <nckx>It's better than what preceded it. *nckx took the opportunity to give guixp9 a long overdue dist-upgrade. <nckx>If PPC64 builds start randomly breaking, ping me. <apteryx>turbovnc appears to be easy to package, good <nckx>Tiger- not work out for you? <apteryx>tigervnc-client's vncviewer only captures all keyboard keys in full-screen mode, which doesn't work on ratpoison for some reason <apteryx>turbovnc's vncviewer is supposed to do input capture even in windowed mode <orneb>Hi Guix! Sorry to bother you again with this but waybar and sway are still buggy with my configs and I recently figured out this happens after a guix pull && sudo guix system reconfigure. After rebooting and logging into the system, waybar does not start and sway can't launch a few programs (icecat). At this point I can't also reboot or shutdown with loginctl reboot/poweroff. My system gets stuck on a black screen and to make <dgcampea>I have a (git) repo that uses m4/autogen to generate some nginx.conf files, how can I pass them to guix to use them as operating-system configuration? Do I need to create a custom package to first run m4/autogen on the source files? <jackhill>Tips on getting pipewire screen sharing to work with sway? I've manually started pipewire and wireplumber, but both obs and ungoogled-chromium don't see pipewire as an available source. Is there an environment variable that needs to be set? <examors_>jackhill: have you started xdg-desktop-portal-wlr? (I haven't tried sway screen sharing on guix yet but I remember having to start this program in other distros.) <Cairn>So I'm using a string-append statement in a wrap program statement. Seems pretty normal. How do I specify an output though? ***examors_ is now known as examors
<Cairn>Like, one of my inputs is `(,icedtea "jdk"). <ericson2314><yuu[m]> "John Ericson: although i'm not..." <- @yuu I have been in lots of smaller meetings on this but it is still a hard sell. People are like like "why do you care so much about how the sausage is made? You're slowing things down and getting us off track for goals that do not matter" <antipode>Cairn: That is independent of wrap-program. <antipode>Have a look at #~EXP as documented in the manual. <nckx>I still don't understand the Matrix bridge. Here, your nick is ericson2314, but other Matrixers clearly see you as ‘John Ericson’. <nckx>Or search-input-file if you can. <ericson2314>nckx: yes I don't fully get it either :) what you wrote has my nick displays to me as "<icon> John Ericson" highlighted text <antipode>orneb: See the 'file' field of 'nginx-configuration'. <antipode>You can combine it with a 'computed-file' that runs autogen, no need to wrap it in a package. <ericson2314>if it is round-tripped, then my @yuu would become a matrix ping with nick search I think <ericson2314>but I have a feeling that matrix-originated messages are not converted to IRC and back <antipode>Presumably all file-like objects are accepted (including computed-file), not only local-file or (file-append package "/..."). <ericson2314>in which cause if or some reason the @name didn't become a rich-text @-mention, it won't become one <nckx>But when I write ericson2314 (that's me writing ‘ericson 2314’, no space), you do get pinged? <jackhill>examors: yep, i have xdg-desktop-portal-wlr. I thought it worked for me in the past, but not really sure how I had it set up. <nckx>That's something, even if seeing others in the same IRC channel address you by a different name could get confusing if both names were less similar <nckx>Did you chose the 2314 or is it random? <Cairn>nckx: but from the matrix side, if I always make sure to use the tab complete name, does it show up like the nick? John Ericson <ericson2314>well, most IRC clients just do nickname search right? same as the IRC -> Matrix conversion does? <examors>jackhill: Hmm. XDG_CURRENT_DESKTOP=sway environment variable is also needed, apparently, did you try that? I'll see if I can get it to work on my Guix machine. <Cairn>Wow, I tab completed your name John Ericson, but it didn't convert it to your IRC nick (from the looks of the chat logs) <ericson2314>nckx: I chose it in 1st grade :), it is arbitrary but 2 3 1 4 0 5 -1 6 etc. there is a small pattern <Cairn>I'm glad my IRC name and my Matrix name are the same. <nckx>ericson2314: Yes, but when (say) yuu is talking to you, we see ‘John Ericson: blah blah’. If your IRC nick didn't contain ‘ericson’ we'd have no idea who they were talking to, even if that's not strictly our problem, it's confusing. <nckx>It would help if Matrix would add " (ericson2314)" to yuu's message before sending it over the bridge. <ericson2314>nckx: oh wow I had no idea it stored "how" the ping was mdae <nckx>Anyway, enough Matrix geekery from me. <ericson2314>tab completion remembering what was entired prior to tabbing is weird as hell <orneb>antipode: were you referring to me above? <antipode>dgcampea: See the 'file' field of 'nginx-configuration'. You can combine it with a 'computed-file' that runs autogen, no need to wrap it in a package. <antipode>dgcampea: You can combine it with a 'computed-file' that runs autogen, no need to wrap it in a package. <nckx>I'd confused the two nicks as well :-x <orneb> :nckx :antipode ok no problem. <nckx>orneb: Wish I could answer your question to make up for it, but I have no clue what's going on there.. <nckx>I've never had such problems, although I don't start Sway from a VT, but from SDDM. (Why do you have an SDDM service?) <nckx>‘From SDDM’ being (auto-login-session "sway.desktop"). <orneb>nckx: Isn't it supposed to be there? I use that service to autologin. Maybe I should ask the mailing list, there might be some Sway users which prefer other means of communication. <examors>jackhill: OK, I have it working in OBS, but not ungoogled-chromium where I just get a black screen with a cursor. I had to run xdg-desktop-portal which automatically started the -wlr portal. I also had to reload my Guix profile as installing these portals added a new env var (XDG_DESKTOP_PORTAL_DIR) <nckx>orneb: I just mean that I don't have that if-tty1 snippet in my .bash_profile. I presume that it's there for a reason and you start Sway differently from how I do. <nckx>If you're already auto-logging into Sway through SDDM, /me no comprendo. <dgcampea>this 'computed-file' procedure, do the tools need to be already available or is it possible to pass a dependency list <orneb>I added that to automatically start Sway on tty1 since I thought (display-server "wayland") only enabled some wayland compatibility. <orneb>nckx: I don't remember why I added both, maybe with the declaration in Scheme the autologin was not working. <nckx>The good news is that if you do use SDDM, it should log to ~/.local/share/sddm/wayland-session.log. Maybe there's more info there. <Cairn>Gosh, no. I'm not getting it. If I'm using assoc-ref to reference inputs, and one of the has an output, I'm not sure how I'm supposed to write that string. Using the old (inputs) style, you just reference the assigned name, but I don't know what that would be with the new (inputs) style. <Cairn>(inputs (list `(,icedtea "jdk"))) the input I'm having trouble with. I can't just type (assoc-ref inputs "icedtea:jdk"). <nckx>It would be (assoc-ref inputs "icedtea"), but I still don't think you need assoc-ref here. <Cairn>nckx so I just don't distinguish outputs? <nckx>Is there an icedtea:out input as well? <nckx>Then, yes, otherwise, enjoy, they're both called ‘icedtea’. <Cairn>Nah, but I was just curious about if there was <nckx>(inputs (list icedtea `(,icedtea "jdk")) creates an alist with 2 "icedtea" keys IIRC. <nckx>No reliable way to distinguish them. <Cairn>Why use the new (inputs) style then? <nckx>Did you check out search-input-file yet? <nckx>This is one of the reasons I recommended it. <nckx>Instead of matching by package NAME strings, you search for a particular file you expect the package to contain. <Cairn>Sorry, I missed where you recommended that. I'm confused though, cause even the example under that uses assoc-ref to select the input "coreutils" <nckx>I guess here "bin/java"isn't an option, so er, "bin/hsdb" or maybe whatever. <Cairn>I pulled up search-input-file in the guix manual. There's an example <Cairn>Sorry, I can't link since I'm using Info <nckx>(We tend to share them as ‘(guix)Build Utilities’ by the way.) <Cairn>Is that a reference to a man page, then? <nckx>Anyway. I say (dirname (search-input-file inputs "bin/hsdb")) is better than that assoc-ref, fight me. <nckx>I'm not terribly happy about the random choice of binary, but the point is you select a file that occurs only in that package, and ideally is relevant. <nckx>I chose this at random though. <nckx>orneb: OK, but is this Sway in normal state or in I reconfigured and everything has gone to hell state? <Cairn>nckx I guess it's just confusing since practically every package I can find uses assoc-ref. I'll stick with it for now, since my hypothetical doesn't apply here, but I'll keep it in mind to figure out search-input-file later. <Cairn>Thank you, though. Taking me a while to learn all this 😅 <nckx>It's true, the code base is a bit all over the place at the moment. And there are still things that are hard to express with the new style. I expect that to eventually settle down. <nckx>(I think a few values of ‘hard’ are even ‘impossible’.) <Cairn>Fair enough. I'm not sure how lispy this is, but I'd love to be able to express outputs using the same format you express them when using the cli. <Cairn>Like just icedtea:jdk instead of (,icedtea "jdk") <nckx>(The desire, I mean, less so the code.) <Cairn>Darn. I guess cause that would be one symbol on its own? <orneb>nckx: I have to try again with a guix system reconfigure but I think some relevant errors are in that link, like ((waybar:400): dbind-WARNING **: 16:10:50.696: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown). <nckx>‘:’ isn't a special character (Scheme has a tiny number of those). <nckx>orneb: Nah, that's beyond harmless & common I'm afraid. <nckx>There's a way to fix it but I don't suspect it. <Cairn>So like with the license list, each license (e.g. license:gpl3+) is its own symbol? Would it be too much of a mess to make package outputs provide their own symbols? <apteryx>so hm, I'm running this vncviewer Java application and it displays an empty X window without any message. any tip? <orneb>nckx: ok, let me run a guix pull and sudo guix system reconfigure and I'll let you know. <yuu[m]><nckx> "Also they read it in a wiki once..." <- haha i actually originally read about it on hacker news, https://news.ycombinator.com/item?id=31293129 is it worse or better in this case? i'm using it because i'm using COW file system, otherwise I wouldn't bother. i have separate subvolumes like for home which i don't apply that. <mgd>Hello, Managed to get GUIX working on my laptop using the System crafter installer. Coming from Arch, updating and installing seems to take ages. Am I doing something wrong? I've had an update stuck on 'build' phase for 40mins <vagrantc>if you don't have substitutes configured, you would build everything from source. <mgd>As part of the graphical installer, I enabled substitute server discovery. Are you referring to something else? <mgd>looks like it's the Linux Kernel (5.18.16) <nckx>yuu[m]: If you snapshot it might be a very good idea to use noatime on those volumes. But I'm not the atime guru. <abrenon>I'm packaging nonfree data for the internal needs of a research project <abrenon>is there a way to handle authentication in an (origin …) declaration ? <nckx>mgd: Why would Guix build a third-party kernel? :) You'll have to ask System Crafters for support. <nckx>Guix meaning the project meaning CI. <abrenon>I wonder what would be a convenient way to bypass this <Cairn>vagrantc: They might not be using the libre kernel, since they're using the system crafters installer. Although a certain other substitute server also seems up to date <nckx>*Your* Guix is working as designed. <nckx>The whole point of the SC installer is to provide that kernel (and maybe some other things we don't support) AFAIK. *vagrantc has no idea about the System Crafter Installer <abrenon>I'm tired of being asked the same question, over and over: "where's the latest version of the data ?" and I wish the answer could be "guix" <mgd>Fair enough. I needed nonguix to get my wifi working unfortunately but ask in their channel. <Cairn>Yeah, gotta keep it libre in this channel. <mgd>Thanks for the help anyway, I would love to just use the libre stuff but on an X220. Take care all <nckx>We (guix.gnu.org) don't build substitutes for any other libre channels either, but some do have their own substitute servers. <nckx>In your case, the lack of a substitute is not directly related to freedom. <Cairn>nckx: I believe the SC installer comes with a substitute server for that stuff, though. So it is a little confusing. <nckx>Oh, sure, that would be. But there's still nothing we can do if it's behind or malfunctioning. <mgd>So just to confirm, in Guix proper, if there are no libre drivers available for my wifi card, I won't be able to use it? <nckx>We offer only the finest auditable code. Also the crappy auditable code, for balance. <Cairn>mgd: Matrix is weird, but I sent you a DM. Did you get that? <mgd>Cairn no, sorry. I didn't get anything <nckx>sneek: later tell abrenon: I think this is supported by git-checkout (which would replace your entire origin). <nckx>sneek: later tell abrenon: This ‘just’ checks out the repository on the host side, using any SSH authentication information present there. Kind of like local-file. That said, the functional store model doesn't play well with some kinds of huge data sets. <MSavoritias>so I tested the ubuntu guix again. I installed guix with apt install guix and guix describe wouldnt run <MSavoritias>message was guix describe: error: failed to determine origin <MSavoritias>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.3.0. <nckx>guix describe only works once you have run ‘guix pull’. <vagrantc>MSavoritias: sounds like it's working as intended <MSavoritias>somebody a couple of hours ago told me it wasnt needed that is why i run it <nckx>The guix installed by Ubuntu is not meant to be your main Guix, but a ‘bootstrap Guix’ for each user to run ‘guix pull’ once and get the bleeding-edge version in ~/.config/guix/current. <MSavoritias>makes sense. the thing is it doesnt work. openssl fails to build <MSavoritias>i reported that earlier here. just wanted to test for describe so i can get what has i have <nckx>So this has already been discussed here? Sorry, I didn't participate. <MSavoritias>but if it doesnt work before guix pull there is no way for me to know <nckx>But yes, what you've described just now is all ‘normal’. <nckx>guix --version should work. <nckx>If Ubuntu (via Debian) only packages releases, it will be 1.3.0, full stop. <MSavoritias>my thinking is that for some reason the ubuntu package is broken <nckx>Right, so very old, and for some unknown reason you're not getting a substitute for openssl (which is odd because it should be pinned on the CI). <nckx>I assume someone already told you this, just recapitulating my understanding. <MSavoritias>yeah. I tried with the shell script from the docs and it worked after <vagrantc>well, i've been thinking of packaging a git snapshot, as guix isn't in a great state in Debian right now <vagrantc>if we don't get it fixed in the next 3-4 months, it might not be in debian's release (for better or worse) <nckx>MSavoritias: What's odd is that, from reading guix-install.sh, it downloads that exact (if Debian/Ubuntu isn't lying) 1.3.0 release. So… it does actually seem Ubuntu/Debian-specific at first glance? <nckx>vagrantc: Do you have any hints? <nckx>Does the package authorise the substitute ACL? <vagrantc>should authorize substitutes, but only ci out of the box <nckx>MSavoritias: Again, sorry if I'm retreading ground from your previous convo. <nckx>guix_install.sh doesn't seem to do that either, but I'm skimming it. <vagrantc>i can say that i tested guix pull from debian package in guix just a day or two ago, and it worked fine <MSavoritias>first one is with the shell script, second one is with the ubuntu package <vagrantc>MSavoritias: looks like you at some point did a binary install? <MSavoritias>I did the binary install. Then uninstall removed everything and tried the shell script <nckx>MSavoritias: What do you mean by ‘first one’? There is only one copy of Guix in that paste. <nckx>/gnu/store/0iii8i1lc4wg3wccs1db7y7d8lg80i04-guix-1.3.0 <vagrantc>MSavoritias: looks like your package is broken, there should be /usr/bin/guix <nckx>Right, but if you were able to run guix and start building openssl, there's a file missing below the line. *nckx is making this face: 🤨 <vagrantc>MSavoritias: dpkg -L guix ... and paste the results <acrow>Can anyone point me to some of the wisdom surrounding guix build troubleshooting with a patchset? I didn't know that the guix build -K option doesn't preserve any of the patch sources. I'm not sure it even succeed with decompressing the .xz patch package after downloading them. <nckx>I'm sure you know that neither /var/guix nor /etc/guix are binaries that would show up in $PATH, yet you had guix in $PATH, so something is missing also from that find result. <vagrantc>MSavoritias: to paste.debian.net or whatever <nckx>I'd guess /usr/bin/guix but vagrantc is the expert on that. <vagrantc>MSavoritias: i'm interested in the packaged version <nckx>No, type guix or command -v guix. <nckx>Or hashing will eat your pets. <nckx>acrow: Patches can't be a tar file. <nckx>They need to be a list of .patch files. <nckx>Easiest fix here is to add the patches.tar origin as an input, and manually extract and invoke ‘patch’ on each in a new custom phase. <nckx>Bit of work, but the magical Guix-does-it-for-you ‘patches’ field isn't clever enough to start unpacking tar files by far. <nckx>If it doesn't create /etc/guix/acl, that would explain why you're rebuilding things from source that shouldn't need to be. <nckx>Also, you need to make sure that you don't keep the daemon running during attempts, or you might be running the shell-script daemon with the Ubuntu command or vice versa. This is usually fine, the protocol is extremely stable, but we're debugging packaging here and the command-line options in both .service files might differ. *vagrantc should probably make the package remove EVERYTHING on guix package purge <nckx>OK, but systemd might still have the old .service file cached. I'm no expert. I think daemon-reload makes sure it doesn't. <vagrantc>a bit nervous, but purging /gnu/store and /var/guix ... seems like it should happen on purge ... but purge is not typically the default action when removing packages <nckx>MSavoritias: You can copy the /etc/guix/acl file somewhere safe, purge all guix_install.sh-installed files, install the Ubuntu package again and put /etc/guix/acl back from your back-up (make sure you preserve the permissions!). <nckx>If this was the problem, you should start getting substitutes, and the fix to the Debian package is clear. <nckx>vagrantc: It's stretching the definition of ‘purge’ a bit yah :) <nckx>cat purge_mpv.sh → find / -name \*.mp4 -delete <acrow>nckx: Thanks that's key info. IIUC, I reposition that patch.tar.xz origin in my list of inputs and create a (add-before-phase 'configure ... section to manually apply the patches. I will make that happen. <nckx>Use add-after 'unpack 'foo. There's a built-in 'bootstrap phase between the two. <nckx>It doesn't do anything on already-bootstrapped sources, but still. <nckx>MSavoritias: Did you ever paste those ‘dpkg -L guix’ results? <nckx>acrow: Bit late, but I see that xvfb-run has a rough example. Rough though. I see no reason to replace 'unpack. <MSavoritias>this doesnt matter which version i have right? from what I get it just gets the packages? <nckx>Yeah, it doesn't matter what's currently installed if that's what you mean. <nckx>Actually, I know nothing about Debian, it just broke after uninstalling. Never you mind me. <nckx>MSavoritias: …too big for Debian? What? <nckx>There's our new tagline. <nckx>Do you mean paste.debian.net? <nckx>I can't speak for vagrantc but I only care whether it mentions /etc/guix/acl anywhere. <nckx>A grep + yes/no is fine for me. <nckx>You were supposed to say ‘no it doesn't’ and I would say ‘ah well there's you're problem, another job well done’ and we could have gone for drinks. This sucks. <MSavoritias>now I am guix pull with the ubuntu package and the acl from the script <nckx>I'm so confused I can't spell. Sorry. <nckx>MSavoritias: OK, at least that is normal & expected. <vagrantc>MSavoritias: does "dpkg -L guix" list /etc/guix/acl ? <nckx>That was my understanding. <nckx>E: Unable to locate package guix <nckx>Pity that the only Debian machine within my grasp is PPC64. <john>I am having a problem compiling GUIX. I have a guile-git which it can't find despite the fact that it has been downloaded from the repository. Anyone have a solution? <nckx>I know LE. Is the name of the platform itself an endian joke? That's meta. <vagrantc>MSavoritias: so, something removed the /etc/guix/acl <nckx>Anyway, yes, LE of course, the best E. <nckx>Otherwise stuff breaks because humans are just monkeys in pants. <nckx>Linux guixp9 5.10.0-0.bpo.8-powerpc64le #1 SMP Debian 5.10.46-4~bpo10+1 (2021-08-07) ppc64le GNU/Linux <nckx>Also, old Debian is old. <vagrantc>MSavoritias: my guess is switching back and forth between binary and packaged install removed the /etc/guix/acl file at some point, and then when you re-install the package, it will not re-install that as the administrator "decided" to remove that file. <nckx>I would upgrade but that would require ‘knowing how’ and ‘expertise’. Peh. <vagrantc>nckx: guix is available for your architecture in bookworm/testing :) <nckx>unmatched-paren: Guix uses -le so I was the confuse. <MSavoritias>but I tried it the first time like that? hmm. well if it cant be reproduced I dont see a point wasting our time on this <vagrantc>nckx: yeah endianess is surprisingly flip-floppable <nckx>vagrantc: I understood that sentence up to ‘bookworm’. How would I switch to that? Also, is it safe? This is the P9 build machine. <nckx>unmatched-paren: LGTM, ship it. <nckx>But how do I opt into the bleeding-edge of Debian. <nckx>‘This package is only 2 years old, tremble in fear.’ <unmatched-paren>it's not bleeding-edge, it's cutting-edge :) I believe bleeding-edge is called sid <vagrantc>nckx: mangle /etc/apt/sources.list* to swap out ... bullseye and/or stable and/or etc. apt update && apt full-upgrade ... more-or-less ... is it safe? i dunno, you seem comfortable with routine breakage in guix ... should be a little less wild-west than that. :) <nckx>unmatched-paren: There's a think-of-the-children metapackage that blocks those. <vagrantc>nckx: or you can just append more sources.list entries, and upgrade individual packages until something breaks <nckx>My only remaining idea re: MSavoritias' issue is: is there some kind of configuration management/diffmerge/whatever framework in Debian, that could get confused? <john>unmatched-paren, GUILE_LOAD_PATH: It is empty <nckx>And for some reason keep /etc/guix/acl staged for admin approval? <nckx>Right, I should say Ubuntu, not Debian. <vagrantc>nckx: if someone manually removes the /etc/guix/acl configuration file, debian will respect that as an administrator decision and not re-install it unless the new version is different, then it prompts about what to do <nckx>See, that sounds almost like what could well have happened, apart from the prompt. <vagrantc>fairly sure ubuntu behaves the same in that regard <nckx>$somehow it got removed, now it's a ghost as far as apt is concerned. I dunno. <vagrantc>nckx: except if it was no change, then it should not prompt <nckx>Well, presence is a change, no? <john>fount git.go in /usr/lib/x86_64-linux-gnu/guile/2.2/site-ccache/git.go, but I am using guile 3.0.7.. <nckx>I assume some files are marked as configuration, others not. You wouldn't want to run a three-way diff on /usr/bin/ls each time. <vagrantc>e.g. /etc/guix/acl v1 was installed, somehow got removed (binary package uninstall?), apt install guix ... checks if /etc/guix/acl was different from previous /etc/guix/acl (which it hasn't changed, so no) ... defaults to current state (removed file) <john>Could i just copy it into /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/git.go? <apteryx>vagrantc: one thing I found confusing about guix installed from apt was that the 'guix pull' as root no longer updates the daemon <vagrantc>nckx: debian respects manual changes to configuration files as a matter of policy, including file removals. <nckx>I don't see why /var/guix existing would contradict my hypothesis though. <MSavoritias>oh well. thanks for your help. at least i figured what was at fault <vagrantc>apteryx: and it's documented in the README.Debian more-or-less <unmatched-paren>Also, ${PREFIX}/lib/guile contains object files, so it goes in ${GUILE_LOAD_COMPILED_PATH}. <vagrantc>apteryx: weather it makes any sense is up for review :) <nckx>MSavoritias: /var/guix isn't in the file list, so I guess it's just some hook ensuring it exists. Running mkdir -p wouldn't interfere with any existing contents so it doesn't need to be managed. <unmatched-paren>GUILE_LOAD_PATH=/usr/share/guile/site/3.0 GUILE_LOAD_COMPILED_PATH=/usr/lib/guile/3.0/site-ccache <vagrantc>yeah, /var/guix is created on an as-needed basis by guix <MSavoritias>this seems like a ridiculous decision without prompt imo <nckx>I agree, and also wonder where you could view the list of what Debian thinks it should (not) do. <vagrantc>sounds like it was likely working as designed. weather you agree with those design decisions is another matter. <vagrantc>but, debian isn't going to change that behavior after 29 years... <nckx>It's definitely confusing and not super nice for upstreams (like Guix in this case) that waste a good chunk of collective time figuring out what the hell happened. <vagrantc>still have no idea what actually removed the file in the first place ... i'm only guessing the guix binary uninstall process? which is ... reasonable, i guess. <nckx>Yeah. ‘Oh, I'll be nice and clean up what is surely my own mess.’ <vagrantc>installing multiple implementations of the "same" packages is just not a strength of most distributions <nckx>And if it doesn't do that, people complain (has happened). <vagrantc>similar crazy happens when people reasonably guix install guix :) <vagrantc>and guix is pretty good at handling multiple concurrent things <nckx>I'm still sitting on a patch to prevent guix install guix because it hArD cOdEs ToO MuCh. <vagrantc>at some point, it is difficult to figure out what is "right" <vagrantc>i also suspect, this went wrong something along the lines of "apt install guix && apt remove guix && $guix_binary_install_process && $guix_binary_uninstall_process && apt install guix" <vagrantc>i also suspect, this went wrong something along the lines of "apt install guix && apt purge guix && $guix_binary_install_process && $guix_binary_uninstall_process && apt install guix" <vagrantc>basically, using "purge" instead of "remove" should have avoided the issue <vagrantc>nckx: right, it's ... a subtle difference that bits debian-based installations now and then <nckx>Sure, and Guix has just as many, it was a sympathy groan. <vagrantc>MSavoritias: yup, "remove" leaves behind configuration files and whatnot, "purge" is supposed to return it to the same state as before the package was installed. <nckx>Why can't users stop trying to use things in unexpected ways and just watch the pretty blinkenlights from afar. <nckx>Because hardware vendors removed all the blinkenlights. I blame them for this. <vagrantc>yeah, all UIs should just be a single button that says "do things" <apteryx>no one is having "guix substitute: error: connect*: Connection timed out" on repetition? I only get it on a particular machine. <nckx>I got the ‘is a bit slow’ warning earlier today but that was mid-maintenance. <apteryx>I'm running with like 20 build jobs though on that machine, so perhaps I'm stressing things in unusual ways <nckx>apteryx: So it happens only to guix substitute? Not any client? <apteryx>I've been retrying for at least 10 times <nckx>Maybe some new clever firewall finds you suspicious, but that's an unlikely stretch. <apteryx>yeah, I asked my friendly IT colleague and they said there's no throttling <nckx>Unrecognized keyword: #:asd-files <apteryx>I'll turn the machine config to 'build-locally? #t', restart guix-daemon thereafter, and see if it helps for next time <nckx>Does anyone else get that above error running guix weather near current master? <nckx>Happens very early in the computing derivations phase. <podiki[m]>pulled a couple of hours ago and guix weather seems fine for me <reza[m]>hi guix, does sombedoy work on updating texlive to version 2022? <apteryx>(in other words, feel free to give it a go :-)) <unmatched-paren>nckx: What do you think about this solution for `guix install guix`: Add a `post-install-hints` field that contains a list of `<post-install-hint>`s, which are constructed with something like (post-install-hint ID MSG [#:not-in-shell? #f]) or (post-install-warning ID MSG [#:not-in-shell? #f]) <unmatched-paren>so then we can add (post-install-hints (list (post-install-hint #f "Don't install Guix by any other means than `guix pull'!" #:not-in-shell? #t) <unmatched-paren>(ID is the hint id for `record-hint`, which would be extracted from (guix scripts shell); if #f, the hint is shown every time instead of just once) <unmatched-paren>Then we could reuse this for other packages, if necessary; e.g. you might want to warn about known issues, or tell the user that they need to set an environment variable or set up a configuration file for the package to work (see GUIX_EXTENSIONS_PATH) <podiki[m]>does guix as a package need to be user accessible in the first place? (I have no idea how it is used exactly) <unmatched-paren>the former gives access to modules from guix for regular guile scripts, i think <Cairn>How can I check if a tool has a test suite? I'm working with a cmake package, but I'd love general tips for figuring this out anyway. <Cairn>I don't wanna just set #:tests? to false without knowing why <Cairn>unmatched-paren, alright. I see only brief reference to it. Do you know of a cmake-built repo I could compare against that would justify leaving #:tests? true? <Cairn>Yeah, I only see it mentioned once <Cairn>If the tool I'm using does the bare minimum to leave tests on, should I just go ahead and leave tests on in the guix package? <Cairn>Fair enough. I guess I'm leaving them on <Cairn>The package I'm basing this one on set tests to false because they "required network access" <Cairn>But in the repo of that package, "ctest" isn't mentioned a single time <Cairn>How does Guix know about them then? <Cairn>Sorry, I guess I'm unclear on what #:tests? even does. I'll read more about it. <unmatched-paren>#:tests? can be used as one of the keyword arguments to a phase proc <unmatched-paren>the default implementation of `check` phases is always wrapped in a `(when tests? ...)` <unmatched-paren>and custom implementations should be too, to allow --without-tests to work <Cairn>Would I find a custom implementation in the makefile? <Cairn>And that only happens if ctest is enabled, I guess? <unmatched-paren>i think the default implementation of check might be (when tests? (apply invoke "make" test-target make-flags)) or something <unmatched-paren>Cairn: Not necessarily; they might be using some custom-built test target <Cairn>I don't wanna go in circles, but I'm curious then how toggling #:tests? would interact with a custom-built test target <Cairn>Or I guess, not even my first time, since I'm just doing modifications to an existing definition <unmatched-paren>guix runs a list of phases in order; i think it might be represented by (alist <symbol> <procedure>) <Cairn>This is what %standard-phases is, right? <unmatched-paren>since guix doesn't need to do any build output caching, it can just do sequential phases <Cairn>Well, I'm a little confused. I'll just have to read more. <Cairn>If I leave #:tests? true, is it normal to write that explicitly, or should I just leave it out if I'm not setting it false? <Cairn>Thanks for helping. Taking me a little while to wrap my head around most of this stuff. *unmatched-paren rebooting <unmatched-paren>Cairn: You should read "Code Staging in GNU Guix" and "Functional Package Management with Guix" <Cairn>Thanks for the recommendations. I'll check them out <Cairn>I'm a good amount of the way through the Guix manual, but I'll check them out once I'm happy I know where everything is in the manual. <Cairn>After those, it's onto the Guile manual =) <Cairn>Also, it seems like tests work without network access, so I'll definitely leave them on. <podiki[m]>question about guix tests, I'm running with pre-inst-env tests/guix-environment-container.sh is that all there is to it? and if it exits with 0 all good? <vagrantc>well, it is time to run "guix challenge --diff=diffoscope" on all the not-matching packages again... <vagrantc>only about 826 more since the last time i ran it <vagrantc>this seems like something a bot should be doing <vagrantc>sneek: you know any good bots who'd be into that sort of thing? <Cairn>Alright, trouble: how might I install multiple versions of java to the same profile? <KiranShila[m]>What is the "correct" way to get the path to one of the outputs of a package from bash <Cairn>Kiran Shila: Sorry, do you mean if it modifies PATH? <Cairn>If not, the way I've learned is to just open the package in guix shell and look at what it adds to the profile <KiranShila[m]>No like, normally `guix build` will return the path to the package, except for multi-output packages in which case there isn't a clear way to get the `out` output <KiranShila[m]>More specifically, a rust crate (bindgen) needs `LIBCLANG_PATH` set but the `clang-toolchain` package has three outputs so there isn't a clear way as to how to export that var to the right location <Cairn>I'm a little confused. I just tried guix build with a multi-output package, and the location of all three outputs in the store <Cairn>*and it gave me the location... <nckx>Yes, but there's no 100% reliable way to pick one (especially :out). <djeis>I feel like that's the sort of thing it'd be fairly easy to add to the CLI, but perhaps that's just wishful thinking on my part. <nckx>One could extend ‘guix build’ to support ‘package[:output]’ without issue. <djeis>Presumably adding that would also make guix build only try to download substitutes for that one output, like the other cli commands? <nckx>That would need to be discussed :) (I'd say that makes sense, and that anybody relying on the contrary right now is making quite an assumption.) <KiranShila[m]>The other option here is that we eval a gexp but I can't seem to find a way to invoke `guix repl` with an arbitrary expression <djeis>Well, you can't just eval a gexp like that per se... <djeis>But the right bit of guile would do the trick, yea. <nckx>KiranShila[m]: WDYM? That's its whole reason for êtring. <djeis>He means from bash, without like piping something to it. <djeis>We're trying to write an envrc which exports an env var to a location in a package's output. <nckx>It's a bit of an arbitrary limitation to cater to, although we could. <djeis>Could, but I suppose... Need to run it in that mode which disables printing the prompt or such... <nckx>So the issues not the pipe but the extreme output noise. <djeis>Yea, and it'd make the envrc that much uglier. I <djeis>*I'm beginning to suspect that's unavoidable though. <nckx>There isn't, but you'd use a pipe for that, but indeed there's no way to make it skip all the noise. <nckx>Might as well add an -e (or -c or whatever) that implies that, two birds & all. <djeis>Ideally we'd just "export FOO=$(guix build bar)/baz", but the package has three outputs and even if we were willing to grep for the right one we don't want to build the -static one. <nckx>But wait, you said this was bash. <nckx>I'm still confused, sorry. Why do you need -c? <djeis>To pass a single expr to run. <KiranShila[m]>In attempts to get the path to a single output of a multi-output package <nckx>It won't print the noise then. <nckx>No need for a new option. <djeis>I... guess? Could... Could use a command substitution with cat... <nckx>You could just use echo, which is built in, no need to spawn cat. <djeis>Ideally this wouldn't need yet another file to be added to the repo, just to hold a single expression. <djeis>Yeah... "guix repl <(echo "expr")" would do it, I guess. <nckx>guix repl <(echo '#~(some-gexp #$I-guess:or-whatever)') <djeis>Now the question is, what's the simplest guile expression to get one of the outputs of a package? <djeis>Yeah but returning the gexp won't print the result of running it. <nckx>TBC: by all means file a feature request for -c (although -e would be more consistent with the rest of Guix), but just use <() until then. <djeis>-e would be more consistent with guix, -c is what guile uses tho. <djeis>Not that I really care either way. <nckx>That's what I just said? 😛 <nckx>Meh, there are some ,commands for building things, but I never remember what they are… <djeis>I was just pointing out that we didn't just get -c from bash :p <nckx>Oh, I wouldn't dare accuse you of that.