IRC channel logs

2022-01-03.log

back to list of logs

<jacereda>I've added a package to my config.scm and invoked a reconfigure, but after rebooting the package isn't avaliable anymore, it's as if grub.cfg wasn't updated. Any idea? Can I force an update of /boot/grub/grub.cfg?
<jacereda>I'm using grub-efi-bootloader
<jacereda>looks like it's due to using `execl` in a `simple-service`, if I change it to `system*` it installs the bootloader correctly
*jacereda is puzzled
<opalvaults[m]>Hey there! Does anyone know what package contains the 'gsettings' binary?
<Kolev>opalvaults[m]: [caleb@bender ~]> which gsettings
<Kolev>/gnu/store/yqsj0ncmzxp4llcj74sj23wl11x3vigw-glib-2.70.0-bin/bin/gsettings
<Kolev>Must be GLib.
<opalvaults[m]>i have glib installed but no gsettings Kolev
<Kolev>Hm.
<opalvaults[m]>it comes with gnome as a dep
<opalvaults[m]>but the binary isn't showing up for me unfortunately :(
<opalvaults[m]>running sddm fwiw
<opalvaults[m]>and not gdm, unsure if that changes anything?
<opalvaults[m]>anyone know how I would go about getting the binary??
<Kolev>opalvaults[m]: What about the package `gsettings-desktop-schemas`?
<Kolev>Or `dconf`?
<opalvaults[m]>both of those packages are installed
<opalvaults[m]>Kolev:
<Kolev>opalvaults[m]: Hm.
<opalvaults[m]>Kolev: re-installing any of the packages does not seem to make the binary appear
<opalvaults[m]>I'm using Sway/SDDM. I just want to be able to configure my theme with gsettings.
<Kolev>opalvaults[m]: That sucks. I'm sorry.
<Kolev>opalvaults[m]: Do you use `nmtui` for Wi-Fi?
<opalvaults[m]>I dont use wifi, but if I did I would use nmtui as I have that installed
<opalvaults[m]>nckx: do you have gsettings with sway?
<opalvaults[m]>If anyone knows how to configure GTK applications without gsettings that works for wayland that'd be fine as well
<KE0VVT>I can't type in IceCat in Sway.
***califax- is now known as califax
***anatomicalex is now known as AlexAvon
***AlexAvon is now known as atomizedalex
<nckx>sneek: later tell jonsger: Guix uses both. Use whichever you prefer.
<sneek>Will do.
<lfam>nckx: I'm looking at the kernel configs for 5.16, and it's asking if we want DRM_SIMPLEDRM on i686
<lfam>This is unset in 5.15
<lfam>WDYT?
<opalvaults[m]>Guix home reconfigure doesn't appear to be installing the packages contained within the (home-environment (packages (append (list))) block. It should right?
<opalvaults[m]>It also appears to not be changing the shell. I'm not sure that it's doing anything except symlinking..? How strange.
<avp_>Hello Guixers. Let's suppose I want to test Guix with my version of Guile-SSH. How can I accomplish that?
<avp_>I have Guix source code cloned locally, and I modified Guile-SSH package to use my own version. I built Guix with my changes and installed Guile-SSH to the system, but still I have Guile-SSH 0.13.1 when I try to use it from Guile REPL.
<lfam>I think you need to update the Guix package itself avp_, in gnu/packages/package-management.scm
<lfam>It's tricky but there's an update-guix-package makefile target to assist
<lfam>I seem to remember that you need to add an extra commit between the guile-ssh update and the commit updating the guix package, in order for the guile-ssh update to take effect. But could be mistaken... like I said it's kinda tricky
<lfam>I think I am mistaken about that. The recent update of the package referred to the previous commit
<lfam>opalvaults[m]: If you're still trying ot make it take effect, try starting a new login shell, for example with `bash --login`
***regtur_ is now known as regtur
<opalvaults[m]>sneek: later tell lfam: That worked! Thank you :)
<sneek>Got it.
<dcunit3d>if i'm in the guix system ISO command line, how do i enable DNS without DHCP? i listed my services with `herd status`, but i don't see anything related to DNS
<civodul>Hello Guix!
<ryuslash>Hello civodul!
<dcunit3d>does the guix /gnu/store benefit much from BTRFS copy-on-write? i'm trying to decide b/w running btrfs or extfs on top of LUKS
<dcunit3d>it's somewhat older hardware. does the Guix manual provide a description of /gnu/store internals?
<civodul>dcunit3d: hi! /gnu/store is append-only, so i don't think it'd benefit from copy-on-write
<dcunit3d>thanks civodul
***modula is now known as defaultxr
<efraim_>does anyone have a find-files snippet that only returns directories?
<efraim_>dcunit3d: the store benefits from the native compression, so that's also something
<civodul>efraim_: howdy! i suppose you have to pass a predicate to do that: (find-files dir (lambda (file stat) ...) #:directories? #t)
***w1gz_ is now known as w1gz
<jpoiret>hello guix! and hello civodul
<jpoiret>I see that srfi-34/35 is used for exception handling everywhere, is there a rationale behind that? Does Guix try to be as portable as possible?
<jpoiret>(or maybe Guix predates exception handling being a Guile builtin 🙃)
<civodul>jpoiret: hey! exactly: Guile use to have the key+args exception handling mechanism, which is not as nice as SRFI-34/35
<jpoiret>I see, I've just now realized this could be the reason :) is there any general portability wish otherwise?
<jpoiret>I say that because some of the installer code still uses catch, and my initial patch changed it to use with-exception-handler and exceptions from (ice-9 exceptions) rather than conditions from srfi-35
<jpoiret>so I'm wondering if I should switch to the srfis while rebasing my commits on top of mathieu's
<civodul>for consistency i'd stick to srfi-35 rather than (ice-9 exceptions), and avoid catch/throw
<jpoiret>alright, will do then, thanks!
<civodul>there are a few places that during bootstrapping run on Guile 2.0, so these needs to keep catch/throw
<civodul>that's mostly (guix build utils) and a couple of others
<jpoiret>dcunit3d: FTR, if you're in the command line you can choose which connection method you want, if using connman you can use the `nameservers` command, if not you can just modify /etc/resolv.conf manually
<gnoo>is there a torbrowser package for guix?
<jpoiret>doesn't look like it
<ns12>gnoo: Read the text related to the Tor Browser on https://libreplanet.org/wiki/Group:Guix/Wishlist
<gnoo>thanks
<ns12>Hello Guix, when running "guix pull", I get this error:
<ns12>builder for `/gnu/store/m34mc2p4h5vwhbl1f29jqrgaqrnyhq0k-guix-packages-base.drv' failed due to signal 9 (Killed)
<ns12>build of /gnu/store/m34mc2p4h5vwhbl1f29jqrgaqrnyhq0k-guix-packages-base.drv failed
<ns12>What does that mean?
<jpoiret>wow, i just read that guix can build for windows? incredible
<ns12>My computer has 1G of RAM and 1G of swap.
<jpoiret>ns12: you might be running out of memory
<jpoiret>i suggest increasing your swap
<jpoiret>2G of total memory is pretty low for today's standards
***phf-1 is now known as phf-1[afk]
<ns12>Okay, I'll try to increase the swap to 2G.
<ns12>jpoiret: "2G of total memory is pretty low for today's standards" - What is the typical amount of memory for light desktop work and simple programming? 4Gb?
<jpoiret>i'd say 4G is a minimum, yes. As for simple programming, if you end up building anything yourself that is a proper project, you'll need more than that
<jpoiret>i have 8G mem + 8G swap on this laptop
<jpoiret>and some local builds still eat up most of it
<jpoiret>i had to increase swap because otherwise they would get OOM'd
<furrymcgee>guix on windows?
<jpoiret>well, reading the Tor Browser part of https://libreplanet.org/wiki/Group:Guix/Wishlist does talk about that
<furrymcgee>I would like to have a guix.cygclass file added, https://github.com/cygwin/cygport/tree/master/cygclass
<ns12>jpoiret: Okay. This is the first time that "guix pull" has failed for me on a 1 GB RAM + 1 GB swap computer.
<jpoiret>it looks like you're building the guix derivations locally, but guix pull can also take advantage of substitutes, so maybe this is the first time it's doing so (maybe because the weather is bad)
<ns12>jpoiret: Is there a command line setting for using 100% substitutes without building locally?
<jpoiret>i'm not sure about that. Note though that sometimes the substitutes aren't available, for example if someone just pushed to the repo and CI hasn't built it yet.
<jpoiret>i don't even know if `guix weather` can be used to query about `guix pull` substitutes
<ns12>Poor, poor little computer ...
***phf-1[afk] is now known as phf-1
<ngz>Hmm. guix pull --news => 121 nouveaux paquets : […] gcc, gcc, gcc, gcc, gcc, gcc-cross-sans-libc-arm-none-eabi…
<vivien>Hello guix! When I boot into a newly configured system, I first get: "Driver ’framebuffer’ was unable to register with bus_type ’coreboot’ because the bus was not initialized. Then gdm won’t start with a fatal server error: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
<vivien>I run with a newer amd/ati card that I use with the radeon driver (by blacklisting amdgpu)
<vivien>Does anyone have the same problem? Can I get out of this problem?
<vivien>I tried modprobe-blacklisting left and right, but it doesn’t held
<vivien>help*
<vivien>I tried switching to linux-libre-lts, but it doesn’t help either.
*civodul sent "guix style" patch: https://issues.guix.gnu.org/52974
<civodul>vivien: weird, are you using the LTS kernel?
<civodul>there was a problem with the FB module not being found for that kernel
<vivien>Using linux-libre or linux-libre-lts has the same outcome
<vivien>It’s just on one of my computers, that’s why I’m able to describe the issue here
<avp_>FWIW, I prepared a patch that updates Guile-SSH to 0.15.0: https://lists.gnu.org/archive/html/guix-patches/2022-01/msg00091.html
<ns12>jpoiret: "guix pull" succeeded after I doubled my swap space from 1 GB to 2 GB. Thank you for your help.
<jlicht>hey guix! Does anybody happen to have a working (tiny) example of modular texlive on current master? I can't seem to get it to work without hopping in my timemachine back to May 2021 :-)
<zimoun>hi jlicht, I just had the same issue on past Thursday evening and end to timemachine back too on Friday morning. Maybe rekado_ knows more about a recent change. :-)
<vldn[m]>somebody has an example how to access vector lists in guile by key and get the value?
<jlicht>vldn[m]: What are vector lists? What would be the 'key' in such a vector list?
<Sabry>Hello folks
<Sabry>I tried to install opendoas
<Sabry>after instillation it didn't work
<Sabry>I use guix packager manager over fedora
<jlicht>Sabry: me not knowing the first thing about opendoas, I assume one of the problems will be that the guix-built software is not installed setuid
<Sabry>yes
<Sabry>that's right
<Sabry>OpenBSD doas is minimal alternative for sudo
<Sabry>doas: not installed setuid
<jlicht>I don't believe guix-on-foreign-distro currently supports that use case
<jlicht>you could hack around it manually or with some custom shell scripts, but IMHO that sounds much worse compared to installing it via your distro's packaging system
<Sabry>can you explain for me what will shell scripts do?
<jpoiret>you could also symlink doas to somewhere in your path and manually set the setuid
<jlicht>Sabry: what jpoiret said :-)
<Sabry>sounds good :)
<jlicht>And I assume you would still need to set up your opendoas configuration, probably /etc/doas.conf
<Sabry>chmod: changing permissions of './doas': Read-only file system
<Sabry>unfortunately it didn't work
<jlicht>Sabry: You could try making a copy of the file, instead of a symlink;
<jlicht>At that point, this is becoming a bit of an unmaintainable mess already ;-)
<civodul>jlicht: i think https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/talks/beamer-manifest.scm?id=31eacf80f817f94ca9fa3b2f22dafc5b990f5b07 works
<jpoiret>jlicht, Sabry: that's how guix system does it anyway, copies the program and chmods it
<Sabry>jpoiret WOW
<jpoiret>that's in gnu/build/activation.scm
<zimoun>civodul, I had issues with a similar Beamer manifest past week. Maybe I was missing coffee. :-)
<jpoiret>(specification->package "coffee") maybe?
<civodul>zimoun: ah no you're right, it's broken!
<civodul>something very wrong about fonts
<civodul>i get things like: "grep: nullfont.log: Dosiero aŭ dosierujo ne ekzistas"
<civodul>lost in a sea of obscure messages in pure TeX style
<ngz>I wish there was a Guix's TeXlive packaging for dummies
<jlicht>civodul: does not works for me, for the very same reason
<jlicht>s/works/work, but good to see it's not just me
<civodul>jlicht: could you file a bug? :-)
<ngz>I can build something with that manifest if I add gawk and sed to my environment.
<civodul>ah!
<civodul>that could be the reason
*civodul tries
<civodul>nope, not any better for me
<civodul>(i'm testing the talks in maintenance.git)
<ngz>I tested a minimal tex file
***phf-1 is now known as phf-1[afk]
<jlicht>fwiw, things do work for me when I use the monolithic texlive
<ngz>Nothing fancy
<jlicht>ngz: does it also work with https://paste.debian.net/1225665/?
<civodul>i guess we need to file a bug and see if Thiago and others have ideas
<ngz>jlicht: No, it doesn't, but it does with… (let me paste it)…
<ngz> https://paste.debian.net/1225666/
<ngz>(note: I added texlive-stmaryrd to the minimal texlive manifest)
<jlicht>something seems to have changed with either the ways fonts are built, or fonts are looked up I guess
***zimoun` is now known as zimoun
***Xenguy__ is now known as Xenguy
<ngz>Possible. Besides there seems to have packages from different eras in "tex.scm". I'm not even sure all are working properly.
<rekado_>they should all work (except those for which we have bug reports, such as polyglossia)
<rekado_>do we have a bug report that I could take a look at?
<rekado_>(I’m not particularly good at any of this, but I’ve looked at a lot of texlive logs)
<ngz>rekado_: For example, manifest at <https://paste.debian.net/1225669/> cannot built document at <https://paste.debian.net/1225665/> using guix shell --pure coreutils grep sed gawk -m themanifest.scm and the pdflatex file.tex
<ngz>build*
<ngz>"and then"
<Sabry>jlicht doas worked but it ask me for root password instead of my user password :(
<Sabry>any suggestion?
<ngz>civodul: by looking at %newline-forms, I assume the official style recommends to add a newline between base32 and the hash string. Am I right?
<rekado_>ngz: okay, I’ll try to reproduce this
<ngz>rekado_: Also if you have tips on how to package stuff in tex.scm, I am all ears. I tried to package kpfonts without much success, and I'm not sure my babel-french package is working.
<civodul>ngz: it's more my personal taste than "the official style" (i think it's okay to allow for variants around the main style), but yes, that's what it means
<rekado_>amsfonts does have the expected files
<ngz>What a bad taste! ;) Hmmm I'll have to change habits then… I like uniformity (in code, not in life).
<rekado_>the fact that kpathsea is executed means that for some reason the fonts are not found
<civodul>ngz: heheh :-) i like consistent style too, but i'm fine with 90% consistency or so
<civodul>rekado_: in my case there's the Fira fonts; perhaps something's wrong with these specifically?
<jlicht>Sabry: this is with 'proper' configuration in /etc/doas.conf? Because from my non-existent experience with opendoas, that + proper setuid should be all the places where things can be tweaked
<apteryx>avp_: thanks for the Guile-SSH patch!
<rekado_>I also tried xelatex; also fails
<rekado_>it gives up too soon
<ngz>This does not bode well.
<rekado_>it doesn’t enter the subdirectory containing the font files
<rekado_>this sounds like an error in the generated config
<rekado_>I’ll check
<ngz>Where is located that config?
<rekado_>(BTW: I’m getting weird errors when exiting a ‘guix environment’ shell session)
<rekado_>I don’t know where exactly it is
<rekado_>but it’s called texmf.cnf
<rekado_>and I see in the strace log that the unmodified texmf.cnf from texlive-bin is accessed
<rekado_>not the generated one
<apteryx>rekado_: hi! "the generated one" from who/where ?
<rekado_>(@ (guix profiles) texlive-configuration)
<mothacehe>hey guix!
<yewscion>Good Monring, Guix!
<ngz>Are there examples of packages using new inputs style while having a full origin as an input? IOW, can you refer to this origin without the associated label?
<rekado_>ngz: I’d also like to know
<mothacehe>rekado_: the substitutes rsync from the SAN -> bordeaux is at 700GiB, progressing 100GiB a day roughly
<jonsger>roptat: I'm a bit unsure about your tip at https://issues.guix.gnu.org/52788#1 I guess I will create a branch for that...
<sneek>jonsger, you have 1 message!
<sneek>jonsger, nckx says: Guix uses both. Use whichever you prefer.
<civodul>howdy mothacehe!
<mothacehe>Good afternoon civodul :)
<rekado_>mothacehe: do we just run a server process on berlin and the rsync client is on bordeaux?
<rekado_>do we have a wireguard vpn between the two?
<rekado_>BTW: I made sure to complete the lzip and zstd directories
<rekado_>if they haven’t been copied yet we could attempt to send them over a less expensive protocol (e.g. a tar pipe over wireguard)
<mothacehe>yes we do have an rsync server service on berlin exporting rsync modules and an mcron rsync client service on bordeaux
<mothacehe>however the rsync module is exporting /var/guix/publish/cache on berlin, so I'm running a manual rsync command from bordeaux to grab substitutes from /mnt_test
<mothacehe>sure tar pipe would be better if we do not want to wait another 13 days for the transfer to complete
<civodul>mothacehe: do we have enough space on bordeaux? (i thought we might first need to put additional disks in there)
<rekado_>the /mnt_test directory is 10TB
<rekado_>it’s not even all of the caches
<mothacehe>oh right there's only 763G left on bordeaux
<civodul>yeah
<civodul>i only rsynced the small bits before vacation because of that
<mothacehe>i'm stopping my rsync command on bordeaux
<civodul>alright
<civodul>so i guess i should do something real soon about those disks
<karrq>what are the rules for packaging software as a docker container? maybe I'm not that clear what I mean. I'm interested in trying out boxbilling and the easiest way to use the software is via docker (compose)
<jpoiret>you can use docker on guix system, but you won't be able to package software that is only usable with docker
<jpoiret>although you could say that no software is actually docker-only
<jlicht>you could, with some elbow grease, write a fixed output derivation for the docker image(s) you are interested in. You could perhaps also try your hand at writing a service that would run a specific docker container.
<jlicht>it would be a space-wasting mutable mess though, even if all this code were magically there. Perhaps that time is better spent packaging things 'properly'
<karrq>I mean the software is kinda complicated, much more than I thought. The non-docker way to install from source would be to also have MySQL with a db and have a service like nginx to serve the web interface etc...
<karrq>do in a non-guix environment just using docker directly is much simpler
<jlicht>karrq: easier, definitely. simpler, I doubt it :-).
<jlicht>fwiw, there are already some examples of services using nginx and/or MySQL; with some luck the current configuration knobs exposed by those are sufficient to support a boxbilling service
<asdf-uiop>Hi! I'm trying to set up a local channel, but I get an error that its derivation can't be built: https://paste.debian.net/1225684/
<asdf-uiop>I hope this contains all the relevant information
<mekeor[m]>asdf-uiop: what is "my-tools"? it seems to be missing?
<jlicht>rekado_, ngz: should I open a bug report summarizing the inputs, manifests and (seeming) root cause of the font issues with modular texlive?
<asdf-uiop>After running 'guix describe' I just realized what's probably the problem: since this is a git repository, I obviously have to commit my changes. I'll try again after that...
<asdf-uiop>mekeor[m]: something I tried the last time I wanted to setup this channel
<asdf-uiop>I'm still getting same error, but with 'en-vrac' instead of 'my-tools'.
<jlicht>asdf-uiop: your 'root' is my-packages
<jlicht>asdf-uiop: so your module is actually (en-vrac), not (my-packages en-vrac)
<asdf-uiop>jlicht: thank you!
<jlicht>asdf-uiop: yw :-)
<asdf-uiop>:)
<asdf-uiop>Solutions often seem so easy once you understand them ...
<asdf-uiop>As a wise bird once said: if there's no solution, there is no problem
***spk121_ is now known as spk121
<asdf-uiop>Looks like it wasn't my only mistake. Is there a command to only check the validity of a channel or do I have to run guix pull everytime?
<asdf-uiop>It works now :)
<rekado_>jlicht: yes, please
<rekado_>please also X-Debbugs-CC me
<rekado_>I’ve been meaning to take care of texlive after the core-updates merge
<rekado_>now that I’ve finished the simplification of the Java bootstrap I have few excuses to put it off for longer
<rekado_>I was wrong: our default texmf.cnf refers to the GUIX_TEXMF variable, which should be enough
<rekado_>I wonder why we still bother with the texlive-configuration hook then
<apteryx>I thought I had removed texlive hooks after the refactoring of texmf.cnf in past core-updates
<apteryx>see 04a0b1e09abce99857e7930336421ca6d15ae630
<rekado_>yes, the procedure still exists but it’s no longer among the hooks
<rekado_>we should remove the procedure too
<rekado_>because it’s pretty damn confusing :)
<apteryx>agreed
<rekado_>I looked at that for way too long…
<jlicht>oh oops, just sent the mail with the outdated info :-)
<rekado_>so… we have the default texmf.cnf and it sets the root directory to GUIX_TEXMF and the fonts directory is correctly declared
<rekado_>but it doesn’t recurse even though it should
<jlicht>does it perhaps not like symlinks?
<apteryx>is there nothing to run as profile hooks still, for fonts or other things? I seem to recall there'd still be value in texlive hooks, but not as it was done
<rekado_>weird: I see that it looks at /gnu/store/d1hqna7rqd6y4ahidsha3mwffb891iqr-profile/share/texmf-dist/fonts/tfm/public (which contains a whole bunch of symlinks as subdirs), but it sees 0 entries
<rekado_>jlicht: looks like that may be true
<apteryx>time to patch some perl script ;-)
<rekado_>maybe I’m reading this wrong…
<rekado_>gotta look more closely
<rekado_>it does see the symlinks … and decides not to enter them. Later it only looks at the directories it had reached up to share/texmf-dist/fonts/tfm/public, but not its children.
<rekado_>it’s fine with the symlink at share/texmf-dist/fonts/tfm/jknappen
<rekado_>but not with the plain directory share/texmf-dist/fonts/tfm/public, which contains 9 symlinks
<rekado_>we need to find whatever logic there is to find fonts to see why it goes wrong here
<rekado_>I’m guessing that this is somewhere in libkpathsea
<opalvaults[m]>anyone know why guix home reconfigure would not be installing the packages listed despite running without error?
<opalvaults[m]>or has anyone experienced something similar?
<jlicht>rekado_: I found a comment in texk/kpathsea/elt-dirs.c:189 that perhaps is relevant
<Kabouik_>My attempts to use pkill9's service to run appimages have been vain so far (https://gitlab.com/pkill-9/guix-packages-free/-/issues/3). Sadly two appimages are the only things keeping me from making Guix my main distro at the moment. If anyone has been using pkill9's service successfully, I'm all ears
<rekado_>jlicht: I was thinking that perhaps ‘readable.c’ is at fault here. The search only keeps going if it decides that a directory is readable.
<unmatched-paren>hello guix, i'm trying to package something that requires downloading three different tarballs and merging them together, is that possible?
<rekado_>jlicht: this looks interesting
<unmatched-paren>so basically is multiple sources possible?
<unmatched-paren>*are
<jlicht>unmatched-paren: you can include multiple origins as labelled (old-style) inputs;
<unmatched-paren>like this:
<unmatched-paren>(source `(("origin-one" ,(origin blahblah)) ("origin-two" ,(origin blahblah))))?
<the_tubular>I don't know if anyone cares but after a few days, I'm happy to report back that podman is pretty stable, as root containers. There is still work to be done for rootless containers in the future. I might give it a shot.
<the_tubular>Thanks for the merge civodul :)
<unmatched-paren>i'm trying to do visurf btw, which is a keyboard frontend to netsurf
<unmatched-paren>the build is very primitive at the moment :)
<jlicht>unmatched-paren: put that into `inputs' and it 'should work'. You will probably have to add phases to unpack/copy/link the sources into the right location for your particular build system.
<unmatched-paren>you need to download netsurf's source, delete the 'netsurf' directory, and replace it with the visurf source
<rekado_>jlicht: pdflatex reports: kdebug:dir_links(/gnu/store/d1hqna7rqd6y4ahidsha3mwffb891iqr-profile/share/texmf-dist/fonts/tfm/public) => 2
<apteryx>the_tubular: that's nice; it can be used as a docker drop-in replacement, correct?
<jlicht>rekado_: according to the comment in elt-dirs, that seems to be an issue then
<rekado_>(you get it to print out stat debugging info with export KPATHSEA_DEBUG=1)
<rekado_>yes, it should be >2 for it to recurse
<jlicht>we could add a dummy file into that directory :P
<the_tubular>Yes, although if you are running as a non-privileged users, you might face some errors apteryx
<apteryx>unmatched-paren: it may still suffer the same fate as docker in Guix since it is also written in Go, but until they start requiring go modules, we'll be ok
<apteryx>to guard against this we need to add go module support in Guix.
<apteryx>the_tubular: OK! Have you written an accompanying service for it yet?
<apteryx>I'd be interested in trying it out if so.
<unmatched-paren>so would i create a new visurf-src package with a trivial-build-system, then add visurf-src as an input to a clone of the netsurf package? then add phases to do stuff
<the_tubular>No; I'm still not really familiar with how guix services works yet. IMO if I were to write something, it would be a package definition for podman-compose. It shouldn't be that hard ... right .. right ..?
<rekado_>jlicht: is it just me or does this idea of counting links to determine whether to recurse seem absurd?
<unmatched-paren>apteryx: "since it is also written in go" ? seems like c to me
<rekado_>jlicht: wait, this comment is inside an #if defined (WIN32) block
<rekado_>jlicht: same thing on line 269
<the_tubular>I did it the dumb way and manually wrote my podman commands from my .yaml files. It would probably be more productive to actually try podman-compose on guix though. But I was just interrested in testing podman
<jlicht>rekado_: yeah, sorry for not noticing it earlier. Still, it seems _too_ much of a coincidence for it to be wholly unrelated, no?
<rekado_>no, you’re right. It’s the same at line 269; I suppose we could undefine ST_NLINK_TRICK.
<rekado_>that would disable these link shenanigans IIUC
<rekado_>gotta go
<the_tubular>apteryx What do you want the service to do exactly ? The only thing I can think of is set policy and set registry
<the_tubular>But those are normally written in .yaml and I won't know how to write those with guile
<apteryx>the_tubular: perhaps just run it as a root, so that the usual dockerisms (--privileged) work?
<the_tubular>Didn't even know you could do that with a service, podman doesn't use a daemon like docker does
<apteryx>perhaps by default it could run as the unprivileged, provisionned 'podman' user, and a switch 'privileged?' could have it run as root instead?
<the_tubular>I mean, this is the behavior, it runs as unprivileged unless you "sudo" it ... ?
<apteryx>yes; similar to doing this but as a neat shepherd service for easily setting up a machine with it (as a compatible replacement to our dockerd-shepherd-service)
<the_tubular>But dockerd-shepherd-service starts the docker daemon as root ... There's no such thing for podman
<the_tubular>The point of podman is that there is no daemon ... So that will probably never happen
<apteryx>I see.
<htsr[m]>Hi guix! I need the file X11/X.h, how can I search which package contains it?
<podiki[m]>after a day of hacking away I think I got mangohud working for guix (a vulkan overlay to see framerate, hardware stats)
<apteryx>I thought it was intended as a replacement to docker, and compatible with the docker "clients" (such as docker-cli)
<the_tubular>It's compatible with docker images. The part about the client is more of a marketing point
<the_tubular>Basically you can alias docker=podman and everything should work
<apteryx>I see!
<jlicht>the_tubular: you could have a service that starts podman containers, as a shepherd service
<the_tubular>IMO still a better improvement that using Singularity.
<the_tubular>That's a great idea jlicht.
<the_tubular>I guess improvement is going to get faster when people switch from singularity to podman, if that happens.
<the_tubular>I am but very weak in guile ... :/
<jlicht>the_tubular: can podman instantiate containers from images that are stored as files on-disk? Compared to docker daemon that needs to 'load' an image before being able to start a containter based on it?
<the_tubular>Sorry, I don't understand your question
<the_tubular>podman already supports your first idea though. But it assumes you use systemd ...
<apteryx>did something trigger a rust rebuild on master?
<apteryx>nevermind, something must have been off
<the_tubular>Those errors pop up when you try and use podman rootless though : https://paste.debian.net/1225703/
<apteryx>civodul: hi! would you know if it would be possible to download a nar fully before starting to unpack it to disk? it seems guix substitutes currently decompress as it fetches (using a guile port I guess), and this introduces problems such as timeouts when the disk is saturated with IO (easy to get on old hard drives).
<apteryx>which then causes the transfer to fail
<apteryx>if it could simply fetch the nar without incurring any IO, then proceed to unpack it, we'd avoid the network timeouts
<apteryx>s/any IO/much IO/
<opalvaults[m]>pinging again for help with a strange issue where guix home is not installing packages when running guix home reconfigure
<opalvaults[m]>it's not throwing any errors, and runs the file just fine (https://paste.debian.net/plain/1225704)
<anguixuser>Hi GUIX, I report that I have installed the ixhcvdl9pfbiigvanmqr17yl9rmpm7f2 (latest) image on qemu and I get this warning https://paste.pics/5ecf1a94c588524bb93a5db7007d36ab. It's normal?
<opalvaults[m]>yes that is normal anguixuser
<nckx>anguixuser: All looks good.
<anguixuser>ok, thanks!
<opalvaults[m]>getting WARNING: Use of `load' in declarative module (#{ g56}#). Add #:declarative? #f to your define-module invocation.
<opalvaults[m]>unbound-variable(#f "Unbound variable: ~S" (make-system-contructor) #f) as well? It didn't stop packages installing before but stranger things have happened
<dissent>hello guix and happy new year. i would need some help completing a python package. https://termbin.com/ona6
***Rampoina is now known as ORampoina
<civodul>dissent: hi! apart from "home_page" (should be "home-page"), it looks good to me!
<civodul>does someone manage to get spell-checking in LibreOffice with the hunspell-dict-* packages installed?
<dissent>civodul i see. there were messages about deprecation
***ORampoina is now known as Rampoina
<opalvaults[m]>alright to the bug report it goes ;p
<jlicht>the_tubular: to answer my own question: podman run supports "docker-archive:/gnu/store/...-guix-pack-docker-img.tar.gz" urls :-)
<the_tubular>Ohh that was your question
<the_tubular>Yeah it does
<the_tubular>I plan to use it only for that use case in the future
<the_tubular>When my apps are going to be bundled on guix
<rekado_>jlicht: I’ll update the wip-texlive branch and get a first commit in
<the_tubular>Don't you need to build those first though jlicht ?
<jlicht>the_tubular: you do, but `podman run docker-archive:$(guix pack --format=docker hello)' is still plenty cool for me
<dissent>civodul: failure in the build log: https://termbin.com/o6mr
<jlicht>rekado_: cool. Are you going to set the compile-time constant, or for a dummy file?
<the_tubular>I'll have to test it later, I'm not sure what docker-archive does
<jlicht>the_tubular: it's a way to locate images stored in the 'docker save' format, which happens to be what we can create with guix pack
<rekado_>jlicht: i’ll try ST_NLINK_TRICK first and see if that fixes things
<rekado_>if it does I’d much rather avoid the weird link trick, even if that makes texlive marginally slower
<the_tubular>Got it
<the_tubular>Here's the catch though to build the image you'll probably need buildah, which is not yet in guix
<the_tubular>Guess you could containerize buildah, build your image and move on from there though
<jlicht>the_tubular: guix pack can build images already. As can `guix system docker-image'
<the_tubular>Ohh, well cool!
***Rampoina is now known as ORampoina
***ORampoina is now known as Rampoina
<anguixuser>I report that guix pull ends with the error "guix pull: error: build of` /gnu/store/b0id6qnacdj2rs5wrnvdkdisn09sr5sj-profile.drv 'failed". Do you need the entire register?
<anguixuser>Do you need the full log*
<anguixuser> https://paste.debian.net/1225713/
<nckx>anguixuser: “View build log at '/var/log/guix/drvs/jq/761va9l55842yiw8d5jinr4835rgki-guix-packages-base.drv.bz2'.”
***phf-1[afk] is now known as phf-1
<civodul>dissent: that's a test failure for those packages; looking at "WARNING: The directory '/homeless-shelter/.cache/pip'", i suspect you may need to set the HOME environment variable before the 'check' phase
<civodul>this can be done with 'modify-phases', as discussed at https://guix.gnu.org/manual/devel/en/html_node/Build-Phases.html
<anguixuser>nckx, the tar -jxf command does not work: "This does not look like a tar archive. Skipping to next header. Exiting with failure status due to previous errors". How can I see it?
<nckx>Which tar command?
<nckx>Are you trying to run tar on the .log.bz2? That won't work, as it's not an archive. Use bzcat or bzless or such.
<nckx>tar is for .tar files.
<anguixuser>nckx, ah! sorry :P
<nckx>anguixuser: Meanwhile, I can't reproduce any failure on master. I expect a transient (e.g., network) error or a third-party channel is to blame. Is that possible?
<nckx>Well, we should learn more from the log.
<opalvaults[m]>nckx: do you have the gsettings binary?
<nckx>Uh
<nckx>to what is this relating?
<nckx>Seem I do not.
<opalvaults[m]>okay just wanted to check. I did not have it either and couldn't configure GTK themes
<nckx>gs tab-completes to gst-*
<opalvaults[m]>happy new years btw nckx :)
<nckx>opalvaults[m]: Note that I've never set a GTK theme in my life, I don't think, I'm probably not your man.
<nckx>If this is not gorgeous design perfection I don't know what is: https://www.tobias.gr/temp/themes.png
<anguixuser>the log just says "[440/654] compiling... 34.6% of 327 filesguix". I try to launch the command guix pull again
<opalvaults[m]>nckx: that is quite nice :) I like the simple themes
<nckx>Oops, I didn't mean to capture MPV. At least it was nothing embarrasing.
<opalvaults[m]>okay so none of my gnu/store binaries are showing up
<opalvaults[m]> https://paste.debian.net/plain/1225715
<nckx>opalvaults[m]: It's just the GTK default.
<opalvaults[m]>I added waybar to the configuration file, and it installed waybar, and then no waybar when I do which waybar
<nckx>anguixuser: Nothing else? I'd expect an error message along with that.
<nckx>opalvaults[m]: Don't use guix-home.
<nckx>I mean, ‘I don't’. It was not a recommendation.
<opalvaults[m]>nckx: not ready for stable use?
<opalvaults[m]>Oh
<opalvaults[m]>Ahah
<opalvaults[m]>All good :)
<nckx>Well, it was merged early, for a fact. I don't know if it's up to snuff by now.
<anguixuser>nckx, nothing. If you want to take a screenshot. The next guix pull was successful!
<nckx>opalvaults[m]: Happy new year to you & all Guix.
<opalvaults[m]>I'm mostly asking literally anyone who can help because this is quite frustrating. Filed a bug report about it :P
<nckx>anguixuser: I believe you. It's a bit frustrating that nothing was logged & we'll never know what. You don't have very little (free) RAM, do you?
<dhruvin>guile newbie question: How do I iterate over arg-value pairs of package-arguments?
<anguixuser>nckx, total: 1.9Gi; used: 693Mi; free:782Mi; shared: 8.0Mi; buff/cache: 509Mi; available: 1.2Gi
<nckx>Hm. That might be on the edge of what ‘guix pull’ could use nowadays, I don't know. anguixuser: was anything related to ‘OOM’ logged in ‘dmesg’ (will look like a big table of naughty processes, one of which is about to be killed.)
<anguixuser>nckx, i am not using guix stable version but the latest: ixhcvdl9pfbiigvanmqr17yl9rmpm7f2
<nckx>Good.
<nckx>You should always use the latest (‘guix pull’) version. The stable release is only intended for installation, and even then it's hit or miss.
<nckx>Once installed, you're hardly expected to use the old guix at all.
<opalvaults[m]>nckx: can you think of a reason that binaries built using guix home wouldn't end up in user paths?
<nckx>I am really not familiar with the guix home architecture.
<nckx>I do not understand why it's not in /home/opal/.guix-profile/bin but maybe that's not expected.
<nckx>opalvaults[m]: Have you tried logging out & back in again?
<nckx>opalvaults[m]: Assuming that /gnu/store/b7z6h78kyyvxm7b0cjz83qfs3dkghv11-home contains a bin/, does it have the command you're missing?
<opalvaults[m]>yes
<opalvaults[m]>all of them
<opalvaults[m]>:(
<opalvaults[m]>it contains all of the binaries I've installed via guix home, but none of them are available to my user
<opalvaults[m]>for instance alacritty
<opalvaults[m]> https://paste.debian.net/plain/1225719
***phf-1 is now known as phf-1[afk]
<nckx>opalvaults[m]: Did you do all this? https://guix.gnu.org/manual/devel/en/html_node/Configuring-the-Shell.html
<nckx>Because it's not clear to me what ‘shells are managed by Guix Home’ means.
<opalvaults[m]>my shell is managed by guix home :(
<anguixuser>nckx, dmsg https://paste.debian.net/1225720/
<nckx>opalvaults[m]: And what does that mean?
<opalvaults[m]>but unfortunately it's not even setting that up correctly
<nckx>anguixuser: Out of memory: Killed process 1580 (guile)
<nckx>So Guile was shot because it used too much memory.
<opalvaults[m]>Good question, I assumed that it just meant declaring the configuration files inside of the guix-home.scm configuration file
<opalvaults[m]> https://paste.debian.net/1225721/ nckx
<opalvaults[m]>here is the configuration inside of the guix home configuration file
<opalvaults[m]>related to shell
<opalvaults[m]>otherwise I have no idea lmao
<nckx>You can run guix pull with --cores=1 --max-jobs=1 to run fewer threads at once, which might reduce RAM usage, and I strongly recommend setting up swap. On all systems, but especially if you have only 2G of RAM in 2022.
<the_tubular>apteryx, jlicht, civodul ; Also I totally forgot, podman expects iptables to be in your path, so you need to manually "guix install iptables" is there anyway to do this with the package definition ?
<nckx>anguixuser: ☝
<apteryx>the_tubular: you could patch the references
<the_tubular>I don't even know what references are
<apteryx>(and add 'iptables' as an input to podman)
<nckx>opalvaults[m]: Well, I'm just wondering, if your shell is ‘managed by guix home’, and at the same time your shell is the thing *responsible* for setting up guix home variables to actually activate the environment, could there be some kind of chicken/egg-type situation possible.
<the_tubular>I mean as an input is more like a dependency right ?
<opalvaults[m]>the the_tubular : https://guix.gnu.org/manual/en/html_node/package-Reference.html
<the_tubular>podman complains that iptable isn't in your path even though iptables has been pulled as a dependency for other programs
<opalvaults[m]>nckx: interesting point, I will see what messing with that does
<the_tubular>Anyway it's pretty easy to fix, just wondering if there's a better way to do it.
<nckx>Dependencies and inputs are orthogonal. Here, you'd patch podman to refer to its iptables input by the full file name (invoking /gnu/store/…/bin/iptables instead of searching PATH for "iptables").
***ec_ is now known as ec
<the_tubular>Haa gotcha nckx, I guess that would work
<nckx>‘iptables has been pulled as a dependency for other programs’ sounds like a misunderstanding.
<the_tubular>I don't know how to do it. But the podman package definition would need this
<nckx>Yes.
<the_tubular>Well what I mean by that is Iptable is on my system. but podman can't find it
<the_tubular>Cause It checks my $PATH
<anguixuser>nckx, thank you very much! I'll use it again tomorrow. Goodbye :)
<nckx>the_tubular: Right. With Guix, packages are ‘installed’ into one or multiple (or no :) profiles. Simply being in the store, alive or dead, is not ‘installed’.
<opalvaults[m]>nckx: you gotta get urself a bitcoin wallet my dude
<nckx>I was going to ask you how this is best done.
<nckx>Say I wish to play with magical internet monies, where would I start.
<nckx>On Guix System to be precise.
<nckx>By anguixuser.
<nckx>*e
<the_tubular>Cool kids use monero, that's all I'm going to say :P
<opalvaults[m]>nckx: https://bisq.network/ I used this in the past
<opalvaults[m]>might be a cool packaging project actually
<nckx>Pret-ty sure cool kids use dogecoin.
<opalvaults[m]>the_tubular: monero isn't widely used so bitcoin would be a better way to make sure that nckx can actually exchange either for services in the form of payment, or cashing out however they see fit
<nckx>Packaging a wally is a bit of a high starting curve just to fart around with this bitcoin stuff.
<opalvaults[m]>however i REALLY don't want to get into cryptocurrency conversations lmao
<nckx>Er, I'm not exactly planning on collecting monies, just playing & learning about the future of internet money in 2012.
<opalvaults[m]>but nckx good question, i'll see if there's any good ways to get a bitcoin wallet that is free software and/or hosted in a secure web interface that doesn't require ID/SSN and all that privacy violating jazz
<nckx>As you can tell, I'm rather ambivalent.
<opalvaults[m]>well i meant it more so that I can could tip you for helping me out all the time :)
*the_tubular goes back in time in 2012.
<nckx>the_tubular: Buy some for me.
<nckx>opalvaults[m]: ‘require ID/SSN’ Yes please. How bizarre, though. I thought the whole point of this thing was to… well, I guess I'll find out soon enough.
<lfam>More fallout from that GnuPG bug #52483: <https://issues.guix.gnu.org/52981>
<sneek>Welcome back lfam, you have 1 message!
<sneek>lfam, opalvaults[m] says: That worked! Thank you :)
<nckx>opalvaults[m]: And thanks.
<lfam>I don't use cryptocurrency, but I would say that we have many packages that enable use of it, including bitcoin-core
<lfam>That's a full implementation of a bitcoin node including the wallet
<nckx>But can one run a node without running up one's power bill?
<nckx>I thought it needed proper uptime, hosting & stuffs.
<apteryx>is it acceptable to copy the lib/pkgconfig directory in a "static" output for convenience?
<jlicht>nckx: sure you can! just splice into your neighbour's power line
<nckx>This all based on multiple *minutes* of typing ‘bit coins how’ into a search engine mind you.
***phf-1[afk] is now known as phf-1
<opalvaults[m]>nckx: i'm going to ping you in #guix-offtopic:libera.chat
<apteryx>lfam: 2.2.32 will be in the version 1.4.0 rebuild branch I'm still polishing
<lfam>That's great apteryx
<lfam>I fixed this bug on master in the meantime
<apteryx>thank you!
<lfam>nckx: Lol, it's a proof of work system. You either do the work (that is, kill the planet) or treat it like regular money
<lfam>It definitely doesn't need proper uptime. But it does need a few hundred gigabytes to store the blockchain
<lfam>I used it precisely once to cash out bitcoins I got when they were free. When you could go to a website and get free bitcoins
<lfam>No I did not get a lot of money
<nckx>So, I did that with Ethereum many years back (it was only a few tens of gigabytes IIRC), did the same thing, made some easy money, then kind of wandered off uninterested. Never really understood what I was doing.
<nckx>Was also not much money, few thousand € IIRC.
<lfam>Same here. Until my bank registered the deposit.
<lfam>And much less money than that for me
<apteryx>I'll put 0.0000001 BTC aside for my will
<apteryx>it'll probably be worth 15 trillion by the time I die
<lfam>And a loaf of bread will cost 1 trillion
<lfam>Just in time, you can host lunch for us
<apteryx>hehe
<nckx>lfam: ‘Lol, it's a proof of work system’ Yes. That I know. But whether ‘doing the work’ required to merely be present on the network is not clear.
<nckx>*is
<lfam>nckx: At least, you need to fill up a hard drive
<nckx>I do that naturally already.
<nckx>Had I known one could get paid.
<nckx>Damn.
<lfam>All that you need to get started is a bunch of money
<opalvaults[m]>nckx: I tried making sure that my shell was zsh in config.scm, and then re-ran guix home reconfigure but it did not add any of the binaries to $PATH
<opalvaults[m]>I'm so perplexed
<nckx>Hm, zsh.
<opalvaults[m]>like hey are all in /gnu/store but completely unavailable to me :(
<opalvaults[m]>it even says "building profile with X packages"
<phf-1>opalvaults[m]: The Guix project has a bitcoin address where one can send btc to: 1Cf6YfS7ywEreFeUevvGir1orVMH12MeVs from: https://my.fsf.org/civicrm/contribute/transact?reset=1&id=50
<nckx>opalvaults[m]: (1) does your ~/.profile contain the lines shown in <https://guix.gnu.org/manual/devel/en/html_node/Configuring-the-Shell.html> (2) does zsh source ~/.profile (3) even if you're not sure, does sourcing it manually make things work?
<nckx>☝ s/The Guix project has/The FSF has, and most of your donation will go to the fund it holds earmarked for Guix, which we can get to if we ask nicely/
<nckx>Just to be accurate.
<phf-1>Hooo... Ok, I see.
<phf-1>If I wanted to send a few €, where to send it then?
<phf-1>*them
<opalvaults[m]>nckx:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4a10c2f15e54a8a9fa3f5676ac861f22a3cc09f4)
<opalvaults[m]>it would appear so
<jlicht>opalvaults[m]: what happens if you `source .profile' in a fresh shell?
<opalvaults[m]>I switch
<opalvaults[m]>oops
<nckx>I should really have a good answer ready to go, phf-1, and I apologise for not having one. It would depend on your location & currency, for one. If it's US(D) the FSF is probably the best option, still. I didn't want to dissuade you or anyone from donating, but it's important to know we don't own that address.
<opalvaults[m]>jlicht: I switched to a new TTY and did a source ~/.profile and waybar then showed up in $PATH
<opalvaults[m]>but when going back to Gnome, my shell is not able to find it
<drakonis>oh, swell, installer improvements abound
<phf-1>I see. Thank you for the answer.
<nckx>opalvaults[m]: So the question seems to be ‘how to make GNOME source ~/.profile’, and this seems to be the associated bug <https://bugzilla.gnome.org/show_bug.cgi?id=736660>.
<nckx>And of course GNOME does not wish to source shell scripts and would rather create a new standard just for variables. That's when I zoned out reading inefficient IRC logs.
<opalvaults[m]>FRIGGIN GNOME
<opalvaults[m]>I SWAN TO JON
<nckx>Well, wait up, we might just not be starting things The GNOME Way.
<nckx>Like: Do we do this: https://bugzilla.gnome.org/show_bug.cgi?id=736660#c101
<nckx>GNOME users will need to answer that.
<nckx>And all this is 5 years old, it may well be out of date.
<nckx>And that is where I would fault GNOME; it loves to completely change things like this up every few years.
<opalvaults[m]>nckx: well it's semi a failure on the zsh-configuration-service-type for not adding anything to .zprofile
<opalvaults[m]>especially since the manual specifically states that if guix home is managing your shell then you do not need to add the HOME_ENVIRONMENT manually
<opalvaults[m]>maybe I'll attempt to add some documentation if I can figure out exactly what is going on here
<nckx>phf-1: If you're in Europe or would like to donate in EUR, there's a Guix Europe legal entity that might be more interesting. If you want to get in touch with guix-europe at gnu.org to discuss donations, please do. We should update https://guix.gnu.org/en/donate/ to focus more on ‘I have some money, how can I insert it into Guix’ rather than just hardware, although both are appreciated.
<lfam>Definitely, Guix is a bash-first project, since bash is the GNU shell. It's typical that things work in bash first and only later get fixed for zsh based on bug reports
<opalvaults[m]>upon logging into i3 it appears that ~/.profile is being read?
<opalvaults[m]>lfam: then I suppose the question is why isn't .profile being read by bash either?
<nckx>It would not surprise me if i3 were a bit more traditional in what it sources.
<opalvaults[m]>because I only in the past 30 minutes or so made sure that I was explicitly using it
<phf-1>nckx: Entièrement d'accord. Je ne dis pas que ce sont des fortunes, mais bon, tout de même...
<opalvaults[m]>zsh*
<nckx>opalvaults[m]: Bash won't source .profile if .bash_profile exists, for one.
<lfam>I'm just saying, using zsh on Guix System will require some extra work
<opalvaults[m]>nckx: ah
<opalvaults[m]>lfam: well that's good to know at least. I suppose some edge case behavior is bound to happen on an early component to GNU guix :)
<nckx>Adding zsh, rather than bash, to the mix of an immature feature + a bash-centric distribution is definitely more likely to fail.
<nckx>It's unlikely to be well-tested.
<opalvaults[m]>So I suppose what I'm getting at is that i3/sway/etc. read .profile just fine whether I'm using bash or zsh, but as you pointed out nckx it appears that GNOME does not read .profile at all for some reason.
<opalvaults[m]>bash and zsh both see .profile just fine when not inside of GNOME's environment
<opalvaults[m]>so tldr, GNOME can suck it
<nckx>It's more of an observation. Maybe it's supposed to and we just don't start GNOME the right way of the month.
<opalvaults[m]>lmao
<opalvaults[m]>truly
<opalvaults[m]>thanks again for your help in troubleshooting that. I'm going to never leave i3/sway/etc. ever again.
<lfam>Let's be generous here to projects like GNOME
<nckx>I'm not a fan of GNOME but I don't think they should suck anything. They do their thing. We do ours.
<nckx>They fill an obvious need.
<opalvaults[m]>I'm mostly being jovial in telling GNOME to shove it. I've been using it off an on for around 7 years at this point so I'm fairly comfortable in critiquing their odd way of handling issues that no other DE's/WM have trouble with.
<opalvaults[m]>But what I fear is that anyone using Guix Home with gnome will find that they aren't able to access their packages unless explicitly telling either .bash_profile, or .zprofile to source .profile
<nckx>OK, but I should point out it *is* clearly documented: ‘To make your shell respect ~/.profile, add . ~/.profile or source ~/profile to the startup file for the login shell. In case of Bash, it is ~/.bash_profile, and in case of Zsh, it is ~/.zprofile.’
<nckx>There's clearly room for improvement (‘NOT managed by Guix Home’ seemed to have confused?) but it's hard to find a middle ground to ‘make things work’ and ‘don't clobber my personal set-up’.
<nckx>Well, not always trivial, at least.
<nckx>We can just add ‘source .profile’ to any shell-specific file we find.
<nckx>Er, CAN'T :)
<lfam>I notice that Git seems to have changed how it indents commit messages, in a way that contravenes the Guix style
<lfam>Did anyone else see this?
<nckx>No. How?
<lfam>It's a small thing but... annoying
<lfam>For example: https://issues.guix.gnu.org/52953#3
<nckx>Git proper? So it's taking what it gets from the editor and… mangling it!?
<nckx>Thanks.
<lfam>The lines such as [arguments] would previously be at column 0, but now they are indented
<lfam>This happened in recent weeks
<nckx>I'm running git version 2.34.0 and haven't noticed this. Let me check.
<lfam>It's not mangling things. It just naturally changes the indentation as you type. Maybe it's an $EDITOR change, idk
<nckx>Yes, I don't see how git would be involved.
<nckx> https://issues.guix.gnu.org/52805
<nckx>No [field] though, if that's the trigger.
<lfam>I don't think that triggers it. It indents natural sentences in this way for me too
<nckx>I still suspect a rogue editor.
<apteryx>hmm, what do you do when your memory is fully used, but 'top' doesn't seem to show what is accountable for it?
<lfam>apteryx: Is your /tmp filled up with hidden disk image files?
<nckx>lfam: Does git supply indentation rules for editors?
<nckx>I'd be a bit surprised.
<apteryx>lfam: my /tmp is not in RAM if that's what you were thinking
<lfam>Okay apteryx
<nckx>I don't see any for emacs at least…
<lfam>I use htop to inspect memory usage per-process
<nckx>htop++
<nckx>The ‘RES’ field is pretty close to ‘just gimme the usage’.
<apteryx>does it really provide anything good old 'top' doesn't already in terms of memory usage?
<nckx>Probably not! But you'll have to wait a few days for someone who still uses ‘top’ to answer.
<lfam>Heh
<lfam>Debian bullseye is still using the old top
<lfam>The new top is quite nice
<apteryx>I do! ;-) it's been improved lots in the last few years
<apteryx>most critics have only noticed the color change it seems
<nckx>The colour change was the least of it.
<lfam>Anyways, to dig in more you can try atop
<nckx>apteryx: How is the mystery RAM marked as used?
<lfam>I would also consider use of the sysstat suite
<lfam>Well, going back to the commit indentation thing
*nckx AFK.
<lfam>It seems to be widespread
<lfam>I know, who cares
<lfam>*Something* changed
<apteryx>free -h says 6089 MiB is used
<lfam>But, no other tools corroborate that?
<apteryx>top or htop does
<opalvaults[m]>re: clearly documented. I will add that the documentation also clearly states:
<opalvaults[m]>"This section is safe to skip if your shell or shells are managed by
<opalvaults[m]>Guix Home. Otherwise, read it carefully.". At some point once my system is usable again I'd like to change that to not shirk people off from checking if .profile is being sourced correctly. Especially because I was using a fresh install.
<apteryx>pressing 'M' in top doesn't suggest that much would be used, unless my intuition of numbers is gone
<lfam>What does M do?
<apteryx>sorts by descending RSS memory usage
<apteryx>looks like this (first page): https://paste.debian.net/1225732/
<lfam>It's a "Color-Mapping" command but this section seems to be missing from the man page
<lfam>No section 4d
<apteryx>there's obviously lots going on with some docker container running and both icecat & chromium, but the numbers seem off still
<apteryx>s/RSS/RES/
<lfam>Look at /proc/meminfo
<nckx>opalvaults[m]: I think that sentence is harmful as it stands. I'm not the intended audience but have no idea what ‘managed [not merely installed, but managed, no less] by guix home’ is supposed to mean. And, frankly, it sounds bogus, as evidenced by *GNOME* being in charge here, not zsh or bash, and I'm pretty sure the author didn't intend ‘shell’ in that obscure way.
<nckx>It's all so very muddy.
<opalvaults[m]>nckx: I agree. I'll put it on my list of to-dos to potentially alter that section to be more helpful and less nebulous.
***phf-1 is now known as phf-1[afk]
<nckx>Thank you! It would be very nice if you'd be willing to rewrite it, a user, as opposed to me, a not :)
<sneek>porcupirate: Greetings!!
<apteryx>lfam: ps -eo rss --no-header | awk '{ sum += $1 } END { print sum }' says processes are using 4.8 GiB of RAM.
***phf-1[afk] is now known as phf-1
<apteryx>while top says '6.1 GiB' are used
<avp_>I think the latest Guile-SSH release should fix that problem: https://issues.guix.gnu.org/51391
<lfam>avp_: Were you able to update the Guix package to test guile-ssh in that context?
<avp_>I read your recommendations on the topic but haven't tried it yet.
<lfam>Okay
<podiki[m]>is there any general policy on compiling with/without BUILD_SHARED_LIBS?
<lfam>That's a CMake thing?
<podiki[m]>for instance, spdlog could be built with it, which I need for mangohud, would a hidden package variant be better?
<podiki[m]>lfam: yes
<podiki[m]>mangohud wants a shared lib for linking, at least with default build options
<podiki[m]>it's just a simple change but was curious if Guix has any reasons/conventions on such options more generally
***phf-1 is now known as phf-1[afk]
<avp_>lfam: From my perspective as Guile-SSH developer I can say that there were several sources of non-deterministic errors in Guile-SSH and now they should be fixed.
***phf-1[afk] is now known as phf-1
<yewscion>If a piece of software can be used under the GPL or under a commercial license (dual license, either/or), is it considered free software for the purposes of FSDG?
<avp_>But there should be actual tests of Guix with the new Guile-SSH version indeed, and the tests will speak for themselves.
<jetomit>yewscion: yes, Qt is one example
<yewscion>jetomit: Awesome, don't want to try packaging software if it is going to be rejected from Guix at the end on licensing issues.
<rekado_>avp_: I think you could use “guix build guix --with-source=guile-ssh=/path/to/new-guile-ssh.tar.gz”
<opalvaults[m]>Can someone help me with the syntax of this services declaration? https://paste.debian.net/plain/1225741
<opalvaults[m]>It's saying extraneous field initializers (debug). Am I doing that modify-services incorrectly?
<apteryx>podiki[m]: in Guix each packages should ship as shared libraries, as that's the preferred linkage of the system. Static libraries should be moved to a "static" output if desired.
<apteryx>(as in, if a static library option is desired)
<podiki[m]>apteryx: thanks. so spdlog doesn't have the shared libs option on, but I have no idea if that matters for the ~10 packages that use it
<podiki[m]>so I could submit a patch to enable that cmake option and if anything breaks from that (I can check building against it at least) then a static output would be needed for them?
<apteryx>you'd want to ensure the dependent packages can link to it dynamically, yes. One way is to move the .a out of the way to the static output, then see if its dependent packages still build with just the .so
<podiki[m]>seems spdlog purposely defaults to nonshared, but has on their github wiki about using in shared contexts
<podiki[m]>hrm
<apteryx>if not, investigate why (perhaps some build flags are required); if it's not supported, fallback to link statically with a comment containing the upstream issue requesting the feature ;-).
<podiki[m]>"Because spdlog is header-only, building shared libraries and using it in a main program will not share the registry between them." but has a workaround
<podiki[m]>I don't really want to go down a rabbit hole investigating the dependents, linking is one thing but if it is a subtle change in logging behavior :|
<apteryx>yeah, if there's a good reason upstream does it that way it's ok
<podiki[m]>so for my own purposes I would be fine with a hidden package variant that is built as a shared library with a todo noting this
<florhizome[m]>challenge: take any package declaration that takes a git commit
<florhizome[m]>Change the commit, leave the hash as is.
<florhizome[m]>build (:
<apteryx>for that specific case you could modify the main package adding the shared libraries
<podiki[m]>or would it be weird to add a "shared" output that has this option, so the default "out" is still the static one? is that too confusing?
<apteryx>most users will use the .a since that's how upstream intends it to be, but tinkerers will have .so available.
<podiki[m]>so have both in the default output?
<apteryx>yeah
<florhizome[m]>> <@florhizom:matrix.org> challenge: take any package declaration that takes a git commit
<florhizome[m]>> Change the commit, leave the hash as is.
<florhizome[m]>> build (:
<florhizome[m]>guix doesn’t even try to find a change here.
<apteryx>with a note explaining that this library is to be primarily used as a static archive, for reasons you mentioned.
<podiki[m]>sounds good; lastly do you have an example of a package that builds this way? not sure if it is a cmake thing, but adding the shared option means it only build the .a static lib
<florhizome[m]>I just pasted a sha hash in the commit field and it still just spat out the substitute from the store corresponding to the hash
<podiki[m]>florhizome: something to do with caching/hash/store....I know it has been discussed somewhere
<florhizome[m]>is there at least a bug report?
<florhizome[m]>I mean it’s not a minor thing...
<podiki[m]>your right, should be mentioned in the origin reference or packaging guide; perhaps check the irc logs, I think just the other day it came up
<podiki[m]>you're (damnit!)
<florhizome[m]>I would file a bug report if there is none already
<podiki[m]>for the documentation of this shortcoming (or to have it fixed) I agree
<florhizome[m]>I consider it to be severe
<florhizome[m]>Reproducibility unless you have a substitute with the same hash?
<jlicht>florhizome[m]: that's what the revision is for (among other things)
<florhizome[m]>Really
<jlicht>the hashes that guix uses depend on all 'inputs' (kinda) + the base32 hash of the thing you are working on; since neither of those changed, it happily continues
<florhizome[m]>Then guixes hashes aren’t sufficient. Point blank.
<jlicht>I don't understand that statement
<jlicht>they are fine for what they are supposed to do, and in your specific case, you simply need to adjust your expected hash
<jlicht>pretty easy /w guix download or guix hash, depending on what you are working on
<florhizome[m]>“you have to behave right for the program to work”
<jlicht>You have to adjust the hash, when you want the hash-based caching layer to give you new stuff ;-)
<jlicht>I was wrong w.r.t. the revision being related to this; that's just to make sure you have a version upgrade path for commands such as guix package -u with later revisions of a package. Sorry for the confusion that may have caused
<jlicht>You can also delete the downloaded sources using `guix gc -D': in that case you will be getting the well-known hash mismatch message you might be expecting
<rekado_>florhizome[m]: the authoritative value here is the hash
<podiki[m]>is the point that if just "commit" changes without a change in version (or anything else) there is no change to the hash?
<rekado_>the commit actually doesn’t matter. There are lots of other ways you can obtain the very same sources.
<podiki[m]>eg. "commit" for a git fetch is not part of the hash, only things like version, inputs, etc?
<podiki[m]>(i mean package hash, not file contents hash)
<rekado_>podiki[m]: the source hash is a content hash
<podiki[m]>rekado_: right, but that doesn't get checked if the package hash is already in the store?
<podiki[m]>since the package hash didn't get changed by the commit changing only?
<rekado_>the package is separate from the source
<rekado_>when compiled into work that the daemon understands we’ve got two (or more) different things here
<rekado_>the source derivation, which is a fixed output derivation, is separate from a derivation that builds the package given certain inputs; and it’s different from graft derivations, etc
<florhizome[m]>I guess it's fine for upstream as long as you use definitions from upstream and upstream doesn't do humanly errors ?
<rekado_>?
<florhizome[m]>does guix lint pick it up?
<florhizome[m]>Nobody can point me to a bug report? What's the exact scope?
<florhizome[m]>But you question the complaint?
<florhizome[m]>I'm sorry, i don't think I should need to elaborate.
<KE0VVT>nckx: I could not understand the code examples, to make Swaylock work.
<KE0VVT>Icedove keeps forgetting my settings. :-(
<jonsger>KE0VVT: mine as well :(
<podiki[m]>florhizome: I think it should be noted in defining packages/source origin reference; I feel it can trip you up when trying different commits for something when you don't have other changes (like a package without a clear version or something)
<florhizome[m]><rekado_> "the source derivation, which..." <- But they comply to the same hash?
<rekado_>florhizome[m]: I don’t understand what you mean by “they” and “the same hash”
<rekado_>“./pre-inst-env guix build -S -d biber” gives you the derivation to build the sources of the biber package
<florhizome[m]>The origin derivation and the other one
<rekado_>you can run “guix build” on that derivation; and you can rebuild it with “--check” the deri
<rekado_>s/ the deri/./
<KE0VVT>jonsger: Makes it hard to keep on top of email when you have to reset the client all the time.
<florhizome[m]>You can very easily inject different source code like that into a build, right?
<rekado_>if by “inject” you mean “use source code that is identified by the given hash” then yes
<florhizome[m]>Are you saying as long as contributors check that the hash is the right one everything is fine?
<rekado_>an example is commit cdc0b3fbbdfe0dc1c8c77406e1cd679caa2f0b2a
<rekado_>the hash is that of libmms, not mjpegtools
<florhizome[m]>"as long as something is packaged in a certain workflow"
<rekado_>is this a quote?
<florhizome[m]>This is what I am understanding
<rekado_>I’m failing to see the source of hostility here, so I’m guessing I’m just oblivious.
*rekado_ —> watches Star Trek TNG
<jonsger>KE0VVT: just start it with --ProfileManger and delete all profiles apart from default
<dthompson>rekado_: make sure you watch deep space 9 if you haven't yet!
<nckx>florhizome[m]: The hash identifies the source. I've explained this before. There is no bug.
<nckx>You never change the hash in your example.
<nckx>KE0VVT: Which code examples?
<KE0VVT>nckx: I don't remember. You posted them a day or two ago.
<nckx>Ages, quoi. I'm sorry but then I don't remember either. :)
<KE0VVT>It feels primitive, not having screen lock or suspend. :-(
<nckx>I certainly recommend the contrary.
<KE0VVT>nckx: It seems I will have to modify my system declaration, just to get Swaylock to work, because it is a `setuid` program.
<phf-1>Is there a Guile equivalent to __file__ in Python?
<nckx>All you need on the Guix side is to add (file-append swaylock "/bin/swaylock") to your setuid-programs. Anything else is sway configuration.
<nckx>Yes KE0VVT.
<nckx>Each setuid programme is a security risk, so it is a (root-only) system-wide setting.
<phf-1>Trying to get a path relative to a module.
<nckx>phf-1: It helps if you describe the feature in its own right, not ‘like fuz but for blaghnarg’.
<nckx>Is it (current-filename) by chance?
<phf-1>Haha, ok, sorry.
<KE0VVT>nckx: My sys. decl. has no `%setuid-programs` or anything.
<nckx>Then add it.
<nckx>It's in the manual.
<podiki[m]>failing at cmake to get it to build both static and shared of spdlog https://github.com/gabime/spdlog/blob/v1.x/CMakeLists.txt
<KE0VVT>(setuid-programs #~(string-append #$shadow "/bin/passwd"))
<phf-1>nckx: Yes, it's exactly that. Thanks. This function does not appear in https://www.gnu.org/software/guile/manual/html_node/File-System.html
<KE0VVT>s/passwd/swaylock/
<nckx>podiki[m]: IME Cmake builds either a static or shared output, not both at once.
<nckx>phf-1: No, it's in (guile)Source Properties
<podiki[m]>KE0VVT: and change shadow to the package that has swaylock
<podiki[m]>nckx: you can make it do both it seems by using a separate library name, but that seems complicated (i.e. not a one line change in this case)
<nckx>KE0VVT: No, use the clear example in (guix)Setuid Programs. Actually read it, don't blindly copy the first hunk of code you see.
<podiki[m]>I think I'll just use what I have: a new hidden package that builds a shared library
<podiki[m]>oh right, the manual setuid now uses swaylock as the full example doesn't it?
<podiki[m]>(after a previous discussion on here)
<podiki[m]>KE0VVT: https://guix.gnu.org/en/manual/devel/en/html_node/Setuid-Programs.html#Setuid-Programs
<lfam>I suppose it's a mistake to have two code examples use different packages
<lfam>It's clear that the 'shadow' example was too obscure
<nckx>podiki[m]: So I was going to conclude: you could add separate 'configure:static, 'build:static, 'install:static phases, etc. but what you describe also works.
<lfam>And, `passwd` is setuid on Guix System by default, so the example does not add much
<podiki[m]>nckx: is that shorthand for phases in different outputs (I haven't tried a package with multiple outputs yet)
<nckx>lfam: IMO it's the ‘it’ (in ‘And then it’) that does it, not the choice of package.
<lfam>What would you say?
<nckx>Here's a carrot. You can add it to the stew like so: (add-to-stew onion).
<podiki[m]>I would just add some words. like "you can add a program to ..., for example to add swaylock, ..."
<nckx>lfam: Using swaylock is fine by me, or note that the shadow is an excerpt from the defaults, and then people won't read that, so swaylock is safer for sure.
<nckx>podiki[m]: That isn't shorthand for anything.
<lfam>We should use an example where the package name is different from the name of the program, but not so different that it confuses people who aren't familiar with the program
<nckx>(add-after 'install 'configure:static (lambda …)) ; this might not be better than your ‘hidden package’ idea, I don't know.
<podiki[m]>"To then add a program to your system configuration, for example swaylock from the swaylock package, ..."
<nckx>Long.
<podiki[m]>nckx: right, so another configure, make, etc. for another compilation
<lfam>The example should clearly illustrate that the code first selects a package, and then uses a string to select an executable program from the built package
<lfam>shadow / passwd was not clear
<nckx>Then I prefer lfam's idea and leave off that very long ‘, for example’ part.
<rekado_>dthompson: I rewatched all of DS9 about 8 years ago :)
<nckx>lfam: Why is it not clear?
<KE0VVT>podiki[m]: nckx: This is what I came up with: (setuid-programs (append #~(string-append #$swaylock "/bin/swaylock") %setuid-programs)
<lfam>swaylock / swaylock will seem unnecessarily redundant to the person for whom shadow / passwd was unclear
<lfam>nckx: I'm going based on user feedback...
<lfam>Nothing about this stuff was clear
<podiki[m]>I would say being clear that the first "swaylock" is the package name and the second "swaylock" is the program name in that package would be helpful (not always true, could see a new user just useing the same thing twice)
<nckx>Yes, but I disagree *that* was what made it unclear. Anyway. It's bad for other reasons, so I'll be glad to see it go.
<lfam>Yeah, it's also a problem if the instructions are too verbose
<lfam>Well, now that everyone is in the kitchen I'll wait for dinner
<podiki[m]>so maybe nix (ha) the shadow example and do it all for some program where the package name is different? shows the full extent of what you need to know
<lfam>Yeah, that's my idea
<lfam>The tricky part is choosing the right package / program pair
<nckx>Yes, but I think we're all waiting for an example podiki[m] 😉 I can't think of one off the top of me head.
<lfam>It should be something you would reasonably want to make setuid. And it shouldn't be so obscure, like shadow and passwd
<nckx>network-manager "/bin/nmtui"
<lfam>That's a nice one
<nckx>Is the only vaguely different thing in my own configuration.
<podiki[m]>yar
<nckx>Apart from (from nfs-utils "/sbin/mount.nfs") but that was a ‘try this to see if it helps’, it might not do anything, which would set a bad example.
<lfam>Also, we don't want people to copy it exactly and do the wrong thing. I recently helped somebody make nmtui setuid, and then somebody else replied to say that there's some other mechanism that should be used, besides setuid
<nckx>Yes.
<lfam>Lol
<lfam>Maybe we should just delete the chapter
<lfam>Use sudo
<nckx>Now u trollin'.
<KE0VVT>I don't know how these newfangled G-expressions work. :-(
<podiki[m]>haha
<lfam>So, let's make a list of desired changes. 1) Unify the two examples to use the same program 2) Choose a program that's clear about what is a package and what is a string
<lfam>3) Don't say "it"
<podiki[m]>yes, that sounds more instructive to me
<KE0VVT>That `nmtui` ex. looked good.
<nckx>KE0VVT: You forgot a list. You can't (append something-that-is-not-a-list to-a-list).
<lfam>I'm concerned that there is a "more correct" way to make nmtui work for unprivileged users: <https://issues.guix.gnu.org/52904>
<nckx>(append (list #~(string-append #$shadow "/bin/passwd") %other-stuff)
<lfam>So maybe nmtui is not the very best example
<lfam>Although, it's pretty good
<florhizome[m]><nckx> "You never change the hash in..." <- I think it sucks nonetheless, even if it’s technically not a bug.
<KE0VVT>(setuid-programs (append (list #~(string-append #$swaylock "/bin/swaylock")) %setuid-programs)
<nckx> https://guix.gnu.org/manual/devel/en/html_node/Setuid-Programs.html#Setuid-Programs
<lfam>It's something that every Guix contributor learns in the same way florhizome[m]
<KE0VVT>I'm sorry I can't RTFM well enough. :-(
<nckx>I'm just confused.
<lfam>When using content-addressing, the difference between a URL (locator) and a URI (identifier) become very important
<nckx>I'm starting to think you're looking at a different manual than I am, KE0VVT. Possibly an out-of-date one?
<florhizome[m]>aaah this experience is some kind of ritual
<lfam>Content-addressing is useful but quite abstract from a human perspective
<nckx>florhizome[m]: No.
<lfam>Nobody is trying to put you through a ritual. I'm just saying that you aren't alone in feeling confused about this
<KE0VVT>(setuid-programs (append (list #~(string-append #$swaylock "/bin/swaylock")) %setuid-programs) ;; Will putting this under (operating-system ...) work? From <https://guix.gnu.org/manual/en/html_node/Setuid-Programs.html>.
<lfam>Just yesterday, I even found my own notes on the subject from when I first noticed it, several years ago
<lfam>There's definitely the potential for mistakes in this area
<lfam>It's another reason that code review is so important
<KE0VVT>nckx: Oh, I am. :-(
<nckx>KE0VVT: It should, barring typos/unmatched brackets that I didn't spot.
<nckx>Conceptually, yes it should.
<KE0VVT>Oh, Swaylock is in the example! :O
<nckx>KE0VVT: OK. Do you know how that happened (i.e., how did you reach the old manual)? We should fix that.
<nckx>So this whole thing had nothing to do with ‘clearly the manual is misleading’. It still needs improvement, but it's a lesson on… something.
<nckx>The ‘Help’ menu still pushing peeps toward 1.3.0 perhaps.
<podiki[m]>yes the manual issue
<podiki[m]>did it ever come up on guix-devel or only on here?
<nckx>Yeah but the whole ‘clearly swaylock is a bad example because look at this user’ was bogus.
<nckx>podiki[m]: Well, I thought it *did*…
<nckx>Let me unbork my emacs to search the lists :)
<podiki[m]>I say we do something about the manual before we do 1.4
<podiki[m]>although that's when the 1.4.0 manual will be the same (briefly) as the "devel" one, it would be great to head off this confusion
<KE0VVT>nckx: @duckduckgo guix setuid
<podiki[m]>(and sort out for new users the whole "release" and rolling)
<jlicht>rekado_: I did not find a wip-texlive branch yet, but I'll see it when I see it. Enjoy the Star Trek!
<podiki[m]>yeah, I noted search engines (or ddg at least) always give the "stable" old manual
<lfam>So, back to the text in the manual. What should I write instead of "And then it can be added to your operating system declaration [...]"?
<podiki[m]>so making sure that isn't indexed would be useful too I think
<podiki[m]>lfam: maybe something like "To then add a new setuid-program to your system declaration..."
<lfam>Or, "To then add the new setuid-program to your system declaration..."?
<florhizome[m]>If it’s a knowledge that ppl in a more or less inner circle share but that is of some kind of importance, yet barely is addressed (you can shoot me a link anytime) in an accessible fashion for non insiders, I consider obtaining that knowledge more of a ritual, esp when it’s connected to some intuitive flaw.
<podiki[m]>or with "to be able to use the setuid program in a system it needs to be added to the system declaration"
<lfam>The use of the "a" article here causes a semantic disconnection from the previous code snippet
<lfam>It's important to refer to it, IMO
<florhizome[m]>florhizome[m]: Then comparing the experience of obtaining it to a ritual is not that far off.
<nckx>lfam: Well, I would have used networkmanager as the only example (nix passwd indeed), so no previous snippet.
<podiki[m]>"to use *this* setuid program"? (assuming one concrete example rather than shadow and swaylock)
<nckx>Not telling you what to write, but I don't know what you have so far.
<lfam>nckx: But, this text is giving an example of the SETUID-PROGRAM record type, as well as how to use it
<lfam>So, I think it's useful to show the SETUID-PROGRAM record in isolation
<lfam>For the Scheme noobs like me
<lfam>podiki[m]: Yes, we are unifying the two examples to use the same package
<podiki[m]>florhizome: I would like to see that "gotcha" noted somewhere like the manual or cookbook on packaging; it also can help illuminate hashes and the packaging process so it would be worthwhile in my opinion
<nckx>OK, then that's where we would have disagreed without discussion. Then, yes, I'd just say ‘to make the nmtui utility setuid’ or so.
<lfam>I'll write, "And then, to make nmtui setuid on your system, add the previous example to your operating system declaration [...]"
<lfam>podiki[m]: It may already be noted... not sure. Most of us learn by trying to make packages and only occasionally consulting the manual
<lfam>The same "gotchas" come up every time, whether or not they are documented
<podiki[m]>:) agreed
<lfam>For example... the dreaded localstatedir
<podiki[m]>a tips/tricks on packaging in the cookbook could be helpful then
<nckx>podiki[m]: I think we should not that files are content-addressed if we don't do so yet (and what that implies, but it's not a gotcha). Where should we do so…
<nckx>*note
<nckx>Well, to be accurate: files are {store file name, hash} addressed.
<lfam>"Operations such as file downloads and version-control checkouts for which the expected content hash is known in advance are modeled as fixed-output derivations. Unlike regular derivations, the outputs of a fixed-output derivation are independent of its inputs—e.g., a source code download produces the same result regardless of the download method and tools being used. "
<podiki[m]>in the package reference?
<nckx>Maybe that's why people expect changing metadata to magically invalidate the hash. Because they saw it happen once & didn't understand why.
<nckx>We should definitely point that out.
<lfam>"When hash and hash-algo are given, a fixed-output derivation is created—i.e., one whose result is known in advance, such as a file download."
<podiki[m]>I would say an example there would be great: e.g. if you just change the commit this won't affect...
<lfam>Anyways, "origin Reference" is the definitive manual section on this subject IMO
<lfam>But this note could go in Defining Packages
<podiki[m]>yeah
<podiki[m]>(or even in the cookbook packaging)
<nckx>Could we link to the section in Derivations everywhere it's relevant (origin Reference, Defining Packages) to keep the latter to the point, whilst making the former less low-level by adding this concrete example? Or do you not think that would clarify things? I want to avoid adding a friendly explanation in one random place (where it can easily be missed) or having to repeat it everywhere.
<nckx>I'd try if the majority thinks it would actually be a step forward.
<nckx>I can't tell.
<lfam>It could also go in the cookbook, but the cookbook is not updated reliably and is basically a wiki
<podiki[m]>right, that could be good, I think it is too easy to skip derivations if you are packaging (i certainly did)
<nckx>Yeah.
<nckx>IMO it should not be required reading for first-time packagers.
<lfam>Defining Packages is the entry point, IMO
<podiki[m]>and that makes a stronger connection to the internals of what is happening
<nckx>that == ?
<podiki[m]>(finally reading gexps and that part of the manual was helpful)
<nckx>lfam: Meaning?
<podiki[m]>"that" meaning linking to derviations in the packaging section, better connecting where a user might start or look at first, to the understanding of what it means
<lfam>nckx: It's where new packages start reading. If we want them to avoid this confusing experience, we should put a note there. The text in Derivations does make the point, but too obtusely for new Guix packages
<nckx>podiki[m]: It's definitely recommended reading, but (and this will be different for everyone) I don't think a dry first reading without packaging experience will give you a good idea of gexps/derivations.
<lfam>I mean, for new Guix packagers
<podiki[m]>nckx: right. and going back to reading it recently after lots of packaging was much more useful than it would have been
<lfam>Like, people won't understand what a derivation is, what a fixed-output derivation is, that /gnu/store is just a cache and not what's "installed" (I see this confusion constantly)
<podiki[m]>(if I read it first without knowing or trying anything in guix)
<podiki[m]>learn by doing is great, and for guix I feel that means packaging and system configuration
<nckx>‘Installed’ is horrible, and now ‘guix home’ has added another ‘installed’ meaning that has suckered me into supporting guix home a few times (which I can't) ☺
<nckx>But oh well.
<lfam>The paradigm is just totally different
<lfam>These words don't mean what people expext
<lfam>It's frustrating for everyone
<podiki[m]>yup
<podiki[m]>or exciting :)
<lfam>Especially if you insist on words meaning the same thing
<nckx>True, but we can't swap them either. There just isn't an analogue.
<lfam>Like, it doesn't bother me at all. But I do get annoyed having to explain it so many times
<nckx>We can't say ‘in store’ == ‘installed’ (IMO, but it *really* doesn't make sense in that O).
<lfam>Nobody is suggesting that!
<nckx>I know?
<lfam>I just gave it as an example of how the finer points of Guix are not understood by new Guix users
<nckx>I was saying there is no easy solution.
<nckx>Chill.
<nckx>Grant me my musings and I will grant you yours.
<lfam>👍
<podiki[m]>if the whole committees/working groups/whatever it is called does happen, I would like to have a documentation/cookbook group that has both very new, intermediate, and advanced users
<nckx>lfam: 👌!
<podiki[m]>I think what we just saw shows why we need that to further improve the docs and early user experience
<nckx>That is all the hand gestures I have. Please do not escalate with cooler ones. I will lose.
<nckx>podiki[m]: Absolutely.
<podiki[m]>🦾
<KE0VVT>Hm. I should figure out how to select emoji with `bemenu`…
<nckx>You go 3-byte, I can't even see them.
<podiki[m]><mechanical arm>
<nckx>Bitchin'.
<lfam>The cookbook is a little bit annoying. We require that significant contributions include relevant additions to the manual, but the cookbook is allowed to become stale, and then users are upset. Which is exactly what some people were worried about before we added it
<nckx>I didn't know that it was allowed.
<lfam>So I agree that it would be good if some people who are interested in these things could focus on the cookbook a bit
<lfam>It's not specifically allowed or disallowed, but simply not considered
<nckx>Like, I would *forget* about it when reviewing, but I wouldn't allow it if reminded of its existence.
<nckx>Ah OK.
<lfam>It's basically a parallel track of documentation. An attempt to capture energy that would otherwise take place on a 3rd party site
<nckx>Yes, the cookbook was a compromise to reduce a certain kind of friction, so now it's fallen into exactly the crack it was supposed to fill up.
<nckx>Monorepo wikitime.
<lfam>But it's tricky because the downside comes later, when it gets out of sync
<nckx>I should… read… the cookbook.
<podiki[m]>I think I started more in the cookbook, but now it is all the manual for me
<lfam>And if somebody did not want to contribute ot the manual, they may also not want to maintain the cookbook
<lfam>Whether it's the manual or the cookbook, maintenance is harder than writing new sections