<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>looks like it's due to using `execl` in a `simple-service`, if I change it to `system*` it installs the bootloader correctly <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>opalvaults[m]: What about the package `gsettings-desktop-schemas`? <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]>If anyone knows how to configure GTK applications without gsettings that works for wayland that'd be fine as well ***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. <lfam>nckx: I'm looking at the kernel configs for 5.16, and it's asking if we want DRM_SIMPLEDRM on i686 <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
<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 <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 ***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>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 <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? <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 <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>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 <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>I tried switching to linux-libre-lts, but it doesnât help either. <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 <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>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>OpenBSD doas is minimal alternative for sudo <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>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 ;-) <jpoiret>jlicht, Sabry: that's how guix system does it anyway, copies the program and chmods it <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>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 <ngz>I can build something with that manifest if I add gawk and sed to my environment. <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 <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>(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) <Sabry>jlicht doas worked but it ask me for root password instead of my user password :( <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! <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 <ngz>Where is located that config? <rekado_>(BTW: Iâm getting weird errors when exiting a âguix environmentâ shell session) <rekado_>and I see in the strace log that the unmodified texmf.cnf from texlive-bin is accessed <apteryx>rekado_: hi! "the generated one" from who/where ? <rekado_>(@ (guix profiles) texlive-configuration) <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? <mothacehe>rekado_: the substitutes rsync from the SAN -> bordeaux is at 700GiB, progressing 100GiB a day roughly <sneek>jonsger, you have 1 message! <sneek>jonsger, nckx says: Guix uses both. Use whichever you prefer. <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) <civodul>i only rsynced the small bits before vacation because of that <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>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>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? <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_>because itâs pretty damn confusing :) <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_>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? <jlicht>rekado_: I found a comment in texk/kpathsea/elt-dirs.c:189 that perhaps is relevant <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? <jlicht>unmatched-paren: you can include multiple origins as labelled (old-style) inputs; <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. <unmatched-paren>i'm trying to do visurf btw, which is a keyboard frontend to netsurf <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? <rekado_>jlicht: wait, this comment is inside an #if defined (WIN32) block <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 <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 <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 <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>I guess improvement is going to get faster when people switch from singularity to podman, if that happens. <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>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 <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 <opalvaults[m]>pinging again for help with a strange issue where guix home is not installing packages when running guix home reconfigure <nckx>anguixuser: All looks good. <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 ***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
<jlicht>the_tubular: to answer my own question: podman run supports "docker-archive:/gnu/store/...-guix-pack-docker-img.tar.gz" urls :-) <the_tubular>I plan to use it only for that use case in the future <rekado_>jlicht: Iâll update the wip-texlive branch and get a first commit in <jlicht>the_tubular: you do, but `podman run docker-archive:$(guix pack --format=docker hello)' is still plenty cool for me <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>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' ***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? <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 <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>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>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. <nckx>to what is this relating? <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-* <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. <anguixuser>the log just says "[440/654] compiling... 34.6% of 327 filesguix". I try to launch the command guix pull again <nckx>Oops, I didn't mean to capture MPV. At least it was nothing embarrasing. <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. <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>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]>it contains all of the binaries I've installed via guix home, but none of them are available to my user ***phf-1 is now known as phf-1[afk]
<nckx>Because it's not clear to me what âshells are managed by Guix Homeâ means. <nckx>opalvaults[m]: And what does that mean? <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]>here is the configuration inside of the guix home configuration file <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 ? <apteryx>the_tubular: you could patch the references <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 ? <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
<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 <the_tubular>Well what I mean by that is Iptable is on my system. but podman can't find it <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â. <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. <the_tubular>Cool kids use monero, that's all I'm going to say :P <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. <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
<apteryx>lfam: 2.2.32 will be in the version 1.4.0 rebuild branch I'm still polishing <lfam>I fixed this bug on master in the meantime <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 <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. <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. <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]>like hey are all in /gnu/store but completely unavailable to me :( <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/ <phf-1>If I wanted to send a few âŹ, where to send it then? <jlicht>opalvaults[m]: what happens if you `source .profile' in a fresh shell? <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>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. <nckx>Well, wait up, we might just not be starting things The GNOME Way. <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... <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]>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 <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]>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. <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? <lfam>It's a small thing but... annoying <nckx>Git proper? So it's taking what it gets from the editor and⊠mangling it!? <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>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? <apteryx>lfam: my /tmp is not in RAM if that's what you were thinking <nckx>I don't see any for emacs at least⊠<lfam>I use htop to inspect memory usage per-process <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>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 <lfam>It seems to be widespread <lfam>But, no other tools corroborate that? <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 <apteryx>sorts by descending RSS memory usage <lfam>It's a "Color-Mapping" command but this section seems to be missing from the man page <apteryx>there's obviously lots going on with some docker container running and both icecat & chromium, but the numbers seem off still <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. <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 :) <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
<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. <podiki[m]>is there any general policy on compiling with/without BUILD_SHARED_LIBS? <podiki[m]>for instance, spdlog could be built with it, which I need for mangohud, would a hidden package variant be better? <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. <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]>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 <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 <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. <florhizome[m]>> <@florhizom:matrix.org> challenge: take any package declaration that takes a git commit <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 <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]>for the documentation of this shortcoming (or to have it fixed) I agree <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) <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 <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 <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 ? <florhizome[m]>Nobody can point me to a bug report? What's the exact scope? <KE0VVT>nckx: I could not understand the code examples, to make Swaylock work. <KE0VVT>Icedove keeps forgetting my settings. :-( <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 <rekado_>you can run âguix buildâ on that derivation; and you can rebuild it with â--checkâ 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 <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>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? <KE0VVT>nckx: My sys. decl. has no `%setuid-programs` or anything. <KE0VVT>(setuid-programs #~(string-append #$shadow "/bin/passwd")) <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? <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. <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, ..." <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>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" <nckx>Is the only vaguely different thing in my own configuration. <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 <lfam>Maybe we should just delete the chapter <KE0VVT>I don't know how these newfangled G-expressions work. :-( <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 <nckx>KE0VVT: You forgot a list. You can't (append something-that-is-not-a-list to-a-list). <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) <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. :-( <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? <lfam>Content-addressing is useful but quite abstract from a human perspective <lfam>Nobody is trying to put you through a ritual. I'm just saying that you aren't alone in feeling confused about this <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 <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]>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 <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 <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>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. " <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 <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. <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>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 <podiki[m]>(finally reading gexps and that part of the manual was helpful) <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) âș <lfam>The paradigm is just totally different <lfam>These words don't mean what people expext <lfam>It's frustrating for everyone <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! <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>Grant me my musings and I will grant you yours. <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 <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. <KE0VVT>Hm. I should figure out how to select emoji with `bemenu`⊠<nckx>You go 3-byte, I can't even see them. <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. <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. <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