IRC channel logs

<gnucode>hardly criticism. :) I think it's pretty cool. Though I haven't used guix in quite a while now.

<nckx>Hmm, there are definitely old patches missing. I'd gone all the way up to replacing the setuid → privileged symlinks with scripts that echo a deprecation warning. That's gone now. I wonder what else I lost.

<nckx>gnucode: Cooler would be not invoking the setcap(8) binary but reimplementing this in Guile, but that's not something I personally want to maintain in Guix. And I'm unaware of an existing Guile library.

<podiki[m]>so cuirass is building a lot, but these are from ~a day ago or are the status pages just not showing current derivations?

<bjc>since we're talking about setuid activation, i would love it if people had a look at https://issues.guix.gnu.org/62726 and maybe help push it through

<squeaktoy>nckx: what should I use on an existing system then?

<squeaktoy>I can't get guix to use the existing internet connection in the chroot

<squeaktoy>It just disconnects

<nckx>I have no idea what you're trying to do, or why you're in a chroot.

<nckx>But I'm away a bit.

<nckx>ACTION toodles.

<squeaktoy>I want to reconfigure a Guix system's config.scm, but I'd have to use the init command according to the manual

<squeaktoy>Or go into a chroot and then do the reconfigure command

<squeaktoy>But I don't want to chroot because it'll just disconnect me from the internet

<squeaktoy>and it will fail

<nckx>ACTION back already.

<nckx>Still very vague to me, but sounds like you want ‘guix system init’. Assuming your target Guix System is at /mnt, running ‘guix system init /mnt/etc/guix/system.scm /mnt’ will deploy a new Guix System matching /mnt/etc/guix/system.scm to /mnt/gnu, which you can then boot back into. I don't see a reason to involve chroots at all unless there's something I'm missing.

<nckx>(And it will also set up the bootloader, as ulfvonbe` said.)

<nckx>(…unless you disabled it, right, that might've been you :)

<ulfvonbe`>if you're using efi, and don't want your host system to boot from the guix you're init'ing, you could use the grub-efi-removable bootloader, I think that passes --no-nvram

<ulfvonbe`>curiously enough when I tried actually using grub-efi-removable for an actually removable (USB stick) install, it wasn't recognized as bootable when I tried plugging it in to another system. I should figure out why sometime.

<jcoby>Hi guys,

<jcoby>I need to compile against an old version of glibc, but I can't seem to get it to work.

<jcoby> http://ix.io/4B4Z

<jcoby>The above is what happens after running this:

<jcoby> http://ix.io/4B50

<zamfofex>jcoby: Maybe you need an older version of GCC too.

<nckx>ulfvonbe`: I'd hoped that ‘--no-bootloader’ would be perfect for this situation, but according to the docs it doesn't update grub.cfg :-/

<nckx>ACTION → 😴💤

<RavenJoad>ulfvonbe`: grub-efi-removable-bootloader does not pass --no-nvram. The only thing that makes it unique is the --removable flag passed to grub-install.

<RavenJoad>Using grub-efi-removable-bootloader on a guix system init will still make the newly-init'd system bootable.

<jcoby>zamfofex: would that entail just adding -version?

<jcoby>sorry it's been a long time since i manually put packages in a scm file

<zamfofex>jcoby: I think you’d have to inherit from your ‘gcc-glibc-2.29-toolchain’ package and change the version.

<jcoby>zamfofex: what does that look like 🥴

<zamfofex>(package (inherit gcc-glibc-2.29-toolchain) (version "foo"))

<jcoby>Hmm still this error: http://ix.io/4B58

<jcoby> http://ix.io/4B59

<jcoby>zamfotex: are you sure you didn't mean this: http://ix.io/4B5a

<squeaktoy>Hey if I don't set a password in config.scm, what will the password be?

<squeaktoy>It constantly says password incorrect

<squeaktoy>Also the fbcon trick doesn't work

<squeaktoy>the font is still small af

<jcoby>zamfofex:

<jcoby>if you're still here, sorry to bother you, but my internet got cut off

<jcoby>This doesn't seem to be working to force an old version of gcc

<jcoby> http://ix.io/4B5f

<oriansj>squeaktoy: no password, just hit enter

<oriansj>you might find this: https://git.sr.ht/~oriansj/System_setup/tree/main/item/files/guix-config.scm#L162 helpful

<squeaktoy>Where can I see what's in %base-packages

<Zambyte>squeaktoy: I like to keep a clone of the guix repo locally so I can easily grep for things like that. You can find the definition here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system.scm#n932

<oriansj>squeaktoy: gnu/system.scm but if you want to see what packages are actually needed and why (no need to include %base-packages) you can just look at my config

<squeaktoy>Can I replace sudo with doas?

<bjc>yes

<bjc>you'll need to add it to setuid-program-program-service-type

<bjc>s/program-//

<oriansj>bjc: or just add it to setuid-programs

<oriansj> https://git.sr.ht/~oriansj/System_setup/tree/main/item/files/guix-config.scm#L323

<oriansj>(but I guess I am in the rare group of people who thinks Guix is too implicit and would be better off requiring everything to be explicit)

<RavenJoad>oriansj: If you think Guix is too implicit, I think you would hate NixOS even more... That was part of the reason I am moving to Guix, because it is slightly more explicit (and easier to understand/document).

<squeaktoy>I'm checking out Guix instead of NixOS because NixOS has systemd and systemd is shit

<squeaktoy>But so far herd hasn't been amazingly convincing either: it always waits on a process and never shuts down the computer

<RavenJoad>squeaktoy: I think that is a recent thing. My desktop frequently (and laptop occasionally) do the same thing. Shepherd used to shutdown all my computers correctly every time.

<linj><RavenJoad> "oriansj: If you think Guix is..." <- Could you give some implicit exampes

<distopico>that happens to me, the issue with the shutdown, but it's not a bug of herd, actually no was a bug, I just forget start an polkit agent, but could be good have an error or warning in that case

<distopico>in my case because I use awesome wm, but with Gnome, Xfce I did't have that issue

<RavenJoad>linj: My favorite has always been the import dir; statement, just implicitly choosing the default.nix in the given directory. Passing specialty scripts (what Guix would use a custom phase for) is another good one. Getting octave packages into the right spot was tricky to do right, because of seemingly implicitly passed inputs.

<RavenJoad>But the bigger issue for me has always been the poor documentation.

<RavenJoad>distopico: Hmmm... I wonder which polkit it is then. I use stumpwm, and it feels 50/50 whether or not the system actually shuts down.

<squeaktoy>What is polkit needed for?

<squeaktoy>Right now on Gentoo I've gotten rid of both polkit and elogind

<distopico>RavenJoad: with those WM such stumpwm, xmonad etc you need to choose one polkit agent, is the same way in parabola/archlinux, Xfce for example use by default mate polkit agent, you can search "guix search polkit agent"

<squeaktoy>Why do you need a polkit agent for herd to shutdown properly?

<squeaktoy>What kind of nonesense is that?

<distopico>the default service include polkit daemon, but you need one agent, and polkit is to elevate permission and shutdown etc

<distopico> https://www.reddit.com/r/linuxquestions/comments/khhvcd/polkit_agent/

<distopico> https://wiki.archlinux.org/title/Polkit

<linj>RavenJoad: Yeah, the doc is not good. However, import dir is well documented in the builtin function section of nix mamual. Not sure what "passing specialty scripts" means.

<squeaktoy>polkit is controversial

<squeaktoy>Is there a way to not have it?

<distopico>maybe, removing the polkit daemon from services could be an option but I did't tested

<RavenJoad>linj: It is well documented, I just do not like it behaving quite that way. By specialty scripts, I mean ones that add more complex steps to the default builder.

<squeaktoy>Where is base-services defined?

<distopico>it's a variable exported (gnu service base) https://guix.gnu.org/manual/en/html_node/Base-Services.html

<distopico>sorry, it's inside desktop-service https://guix.gnu.org/manual/devel/en/html_node/Desktop-Services.html

<distopico>`the elogind login and seat manager, the Polkit privilege service`

<squeaktoy>Well I'm just using base-services

<squeaktoy>not desktop-services

<squeaktoy>Do you perhaps know how to apply a console font to all TTYs

<RavenJoad>squeaktoy: For something like that, I think you have to take a page from %base-services and manually write out console-font-service-type and body yourself. See (gnu services base) %base-service's list for how it is defined.

<squeaktoy>But it only shows this weird thing where you have to define one for tty1 tty2 blah blah

<squeaktoy>I just want to set one font for every tty

<distopico>there is a example there in the docs that you can use as inspiration https://guix.gnu.org/manual/en/html_node/Base-Services.html#index-console_002dfont_002dservice_002dtype

<RavenJoad>squeaktoy: distopico's suggestion is the more correct route.

<juliana[m]>thinking about the security model of guix... you can execute arbitrary executable binaries in the store, right?

<juliana[m]>like even if they're not sourced if you know (or can sufficiently closely approximate) their path you can execute them?

<juliana[m]>they're not in a sourced profile*

<RavenJoad>distopico: Which polkit agent are you using for awesomewm?

<RavenJoad>juliana[m]: I believe are correct. I would appreciate someone else's input too though. If you find the path for a binary on your system, it is likely you can execute it. I do not believe this is any different from any other Linux distro though.

<juliana[m]>it is not, but it does undermine the security model significantly. if you have an insecure binary sitting in your store, it can be exploited even if your profile has replaced it with a secure version

<juliana[m]>whereas most distros would replace old binaries entirely on upgrade

<distopico>squeaktoy: for all you can use %desktop-service an remove the service that you don't want with `modify-service`, "(service console-font-service-type (map (lambda tty (tty . "lat9u-16"))) ("tty2" "tty2" "tty3" ...))"

<RavenJoad>juliana[m]: True, but neither Guix nor Nix attempt to solve that. In addition, I am not sure how much Guix's grafts affect my answer.

<juliana[m]>correct

<juliana[m]>anyway, just an idle thought because i'm looking at tinycc and it's ridiculously insecure

<distopico>the difference is for example this one https://bugreports.qt.io/browse/QTBUG-58508, qmlcache is trying to write in the root, or relative to an qt library, in normal system it can, but in Guix it cannot, due the immutability, so cases like that malicious code adding or removing root stuff

<distopico>RavenJoad: I user lxqt-policykit

<distopico>in a normal system, if you install an unknown program, and in the installation moment you give privilege access, the program can add an user in /etc/passwd, a new group etc, remove something etc, but in Guix it can't

<ChocolettePalett>Why is tinycc insecure btw? It is tiny, so I assume it has fewer bugs or smth

<juliana[m]>HAHAHAHAHAHAHAHAHA

<juliana[m]>you only need one insecure memory access to pop a shell

<juliana[m]>check out the function parse_number in tccpp.c

<ChocolettePalett><juliana[m]> "it is not, but it does undermine..." <- I assume that deleting generations and collecting garbage will mitigate this issue, but I am neither GNU/Guix nor security expert

<ChocolettePalett>As a side effect you get a very nice Gentoo experience on next guix home reconfigure, the more packages you have, the more Gentoo experience you get

<ChocolettePalett>I also think that in order to execute some binary in the store, a hacker needs access to user's account, for example to locate the desired directory. And even if the hacker knows the full path to binary, being able to execute commands is still required.

<ChocolettePalett>So in order to hack your computer, one needs to first hack your computer I guess, it's like those vulnerabilities which descriptions start with "first, do ``su``...": can be exploited in theory but hard (nearly impossible) to exploit in practice

<juliana[m]>it is a reasonable path for privilege escalation, but you're right that if you're not worried about users who already have accounts then it doesn't really matter

<juliana[m]>also your messages are uh... very IRC-unfriendly just so y'know ;)

<squeaktoy>guix system: error: service 'console-font-tty1' provided more than once

<squeaktoy> https://bpa.st/HRMQ

<RavenJoad>juliana[m]: tcc may be insecure, but it was never designed to be secure. It was designed to be ridiculously fast and self-hosting (and easy to bootstrap I believe).

<juliana[m]>to be fair, if a user has access to any C compiler they already have enough power to do pretty much whatever they want including privilege escalation

<juliana[m]>you can just write your own insecure binary at that point

<bjc>what is the threat model here? if i can dump arbitrary binary to a file and make it executable, then i can suddenly pwn all the systems?

<ChocolettePalett>squeaktoy: Is is possible that console-font-tty services are already defined in %base-services? This might be the cause, but I'm not sure

<bjc>better get rid of chmod and cat, then?

<RavenJoad>squeaktoy: You need to (modify-services %base-services ...) to make it work. Give me a second to put something together and pastebin.

<juliana[m]>it depends what mitigations exist in the kernel and libc and various other plumbing of the system, but yeah, i guess you could compromise a system with handwritten binary, chmod, and cat, huh?

<RavenJoad>squeaktoy: https://paste.debian.net/1286489/

<RavenJoad>The problem was you were providing 2 services that had the exact same name, which shepherd does not like.

<bjc>i'm saying you're going to need to be more explicit than claiming that certain binaries have “security flaws”. unless they're privileged executables, i'll need a path from “has buffer overflow” to “remote execution” or “root”

<bjc>cuz, like, i'd wager the vast majority of executables have buffer overflows, or similar vulnerabilities. and, for the vast majority of that set, it's not a problem, because they don't escalate privileges

<bjc>if your webserver allows randos to run ‘tcc’, your webserver has a serious problem, not tcc

<juliana[m]>fair

<juliana[m]>as i've already said, this is idle musing

<juliana[m]>i am not a security person

<RavenJoad>ACTION is going to take a break from Lisping for a while. Later all!

<HiltonChain[m]>squeaktoy: I personally want less ("tty[...]" . [...]) lines, but the end result may be the same number of lines. ;) <https://codeberg.org/hako/Testament/src/branch/trunk/dorphine-system.scm#L255>

<squeaktoy>How would I just remove the console-font service? maybe I can set the font in a kernel parameter instead

<HiltonChain[m]>I don't know about relevant kernel parameters, but that service internally invokes setfont from kbd.

<oriansj>well if we are being fully honest on the secure system problem. I would like to point out the following: there is no hardware available that doesn't have unfixable bugs which can be used to compromise the system if you have the ability to run binaries on said hardware.

<oriansj>that being said, if you have the abilty to execute an arbitrary 100bytes you have everything you need to bootstrap GCC on your target system

<juliana[m]>well. i'm working on tcc explicitly because that's not quite true yet, but ;)

<juliana[m]>yeah

<oriansj>juliana[m]: have you not heard of stage0?

<oriansj>or the #bootstrappable community?

<juliana[m]>i am working on tcc for the riscv64 port of the full source bootstrap

<juliana[m]>stage0 is more than 100 bytes last I checked, and besides only works on x86 and aarch64 atm

<oriansj>juliana[m]: stage0 has riscv32 and riscv64 ports right now

<juliana[m]>yes, but can't get to gcc

<juliana[m]>i just told you i'm working on this project

<juliana[m]>i know what i'm talking about

<damo22>lol

<damo22>why dont you work together

<oriansj>lots of this sort of work takes place on the #bootstrappable channel (where all of the guix bootstrapping work takes place)

<juliana[m]>yeah i should probably join that channel

<juliana[m]>i've been hanging around in the guix-risc-v channel

<oriansj>the seed for stage0 can be under 100bytes if one does dirty tricks and skips having elf headers

<damo22>someone i know is working on hurd's new bootstrap process, it looks like we might end up building something with a simple REPL to follow a boot script

<juliana[m]>these are exciting times for boostrappability. I mean, when was the last time a software ecosystem was bootstrapped from (pretty well close to) nothing? 70 years ago maybe?

<oriansj>juliana[m]: well Kathleen and Andrew Donald Booth's 1947 work; after that everyone had an assembler and a bunch of tools available

<damo22>hurd starting up is an interesting problem

<damo22>its like a chicken egg problem because you dont have access to disk until the disk translator starts

<oriansj>well a read-only memory filesystem can fit in a single page

<damo22>yeh but we plan to do it without a ramdisk as such

<oriansj>damo22: and the init problem?

<oriansj>you would need to load the init from disk before it could start anything such as the disk translator service.

<damo22>thats what grub is for

<oriansj>damo22: so have grub build a ramdisk or load the binaries into memory and pass that info to the kernel?

<damo22>yeah we currently do it that way, but its a bit clumsy

<damo22>we load statically linked binaries as grub modules and have them talk to each other

<oriansj>damo22: for what advantage would that provide over just building a ramdisk?

<damo22>subhurds could, for example, be full hurds

<damo22>without a disk image

<damo22>but we are planning to replace the awkward loading of grub modules chaining together by a single bootstrap task

<oriansj>well hopefully it pays off ^_^

<damo22>it might need to load a script that says which tasks to load, perhaps it could be a scheme REPL

<oriansj>damo22: so shepherd running on guile like guix does right now

<damo22>it could simplify a lot of the hurd translators, not having to care if they were started from userspace or loaded from grub

<squeaktoy>guix system: error: service 'networking' requires 'wpa-supplicant', which is not provided by any service

<squeaktoy>Is there a way to use iwd instead of wpa-supplicant?

<damo22>oriansj: maybe we could share code with shepherd

<oriansj>squeaktoy: yes look here: https://git.sr.ht/~oriansj/System_setup/tree/main/item/personal/x200.scm#L437

<oriansj>damo22: well the starting of hurd translators could just be services in shepherd

<damo22>ok

<damo22>we need to write a bootstrap task that grants "fake" certain things that dont yet exist to the other tasks that need to start, start them with shepherd, and when they do exist, the bootstrap task swaps them to the real ones and exits... something like that

<damo22>not sure where the script should live

<damo22>maybe a hardcoded scheme script in memory, and drop to the REPL if it fails

<adanska>Hey guys, having some trouble getting package `vkquke` running. It says it requires SDLv2.06 to work, but I dont have the expertise or confidence to try and submit a commit to fix this. I'm not sure how to specify specific versions of packages as inputs for `package` decls.

<abrenon>hello guix

<adanska>Im not really confident either with getting a patch ready and submitted. I suppose this would be a good time to try, haha

<adanska>its pretty daunting, though

<adanska>anyway! how do you specify specific package versions as inputs for a package decl?

<abrenon>adanska: well the first step before submitting a patch is that you get it running for you

<abrenon>and that'll be very rewarding, and will prolly give you the energy to then submit a patch ; )

<adanska>haha, you're probably right :)

<abrenon>that's the funny part: you don't : )

<adanska>oh?

<abrenon>at a given point in time (commit in guix' repos), one package has one specific version

<abrenon>now for some packages with multiple, interesting version — ok stupid example but at least at a time say python2 python3

<abrenon>then you'll find that there are several versions available but from guile's POW they are just several distinct values

<abrenon>(ok, not entirely true, they'll probably be generated from a common function)

<abrenon>look at the linux packages for instance

<abrenon>when you `guix search linux`, you'll see several packages "called linux", and if you want to install one or the other you pick a version the usual way with a good ol' @ (e.g. linux@5.15.116)

<abrenon>but if you `guix edit` one of them and look at their declaration, you'll see that they each have a separate name, as if they were distinct values

<adanska>yeah im looking right now. theyre all seperate entries!

<abrenon>from the context of a package, you would use linux-libre-5.15 etc.

<abrenon>exactly !

<abrenon>crazy isn't it ?

<abrenon>now the bad news is that I don't see any sdl with version >= 2.06, so either I'm confused about the versioning scheme of that particular library or it's not available in guix yet

<abrenon>(the annoying case when you have to package a dependency before packaging what you want)

<abrenon>but at least, if you manage it, you'll know how to name the new version and won't replace current sdl ; )

<adanska>Right. So I'll have to create a 'sdl-2.06' package before I can fix vkquake's package decl

<abrenon>ok, apparently I can't grep this morning (had a bad night, FWIW) ignore what I said

<abrenon>the >2 versions are named sdl2

<abrenon>now they are way above 2.06 but that's a "at least 2.06", it should work

<abrenon>in any case it seems to be already available

<adanska>The problem is is that vkquake requires *specifically* sdl v 2.06. vkquake borrows its inputs from the 'quakespasm' package, which is already taking 'sdl2' as an input.

<adanska>im not really sure why this software requires this very specific version of sdl, though.

<abrenon>ahahah then I think you're going to have to declare a new version anyway

<adanska>ok haha

<abrenon>except… if that's a case of ">= 2.06 because that's the one I tested and < 2.07 because who can predict the future ?"

<adanska>so i have to go about declaring a 'sdl-2.06', right

<adanska>hmm maybe

<abrenon>in which case the easier fix would be to lift the restriction in vkquake's source code with a small patch or minor edit of the sources

<abrenon>then build with 2.26 because why not use the most up-to-date when it works ?

<abrenon>anyway it's still very uncertain and will need some trial-and-error rounds

<abrenon>so in your place I would clone locally, try and come up with a stub of the package precise enough for you not to build it but to enter a "development shell" with `guix shell -D -f guix.scm`

<abrenon>then you can fiddle with it and ascertain whether it works with > 2.06 or not

<abrenon>and find all the subtleties which will no doubt arise in the build process

<abrenon>and that'll tell you how to modify the build-phases

<abrenon>if that really doesn't work, you will indeed have to declare a sdl-2.06

<adanska>riiiight. okay

<abrenon>that's your mission, if you accept it ; )

<adanska>thank you so much for your help abrenon!

<abrenon>you're welcome ! I hope it helps

<adanska>i really want to contribute to guix, i think its going to be a great way to learn how to contribute to open source whilst also supporting something i use and love

<adanska>excited to submit my first patch (ever!)

<abrenon>in any case, the good news is that this message *won't* destroy itself and will still be available at https://logs.guix.gnu.org/guix/2023-07-21.log should you need some memory refreshment when the chan is more crowded

<abrenon>good luck !

<adanska>thanks! :)

<abrenon>(yeah, I think you're not starting with the simplest project but I'm sure you can make it and you'll learn tons in the process)

<adanska>mhm! i dont think theres a better way to reap the benefits of guix than hacking on it myself haha

<abrenon>that's for sure !

<adanska>i've only been using guix for a few months and i already love how easy and fun it is to muck about with

<abrenon>same here

<abrenon>well, I mean I've been using it for 2y and half but I remember that very early on, a couple months like you said I was already shocked to see how usable it was actually

<adanska>i can only imagine how far its come since then

<abrenon>despite all the warnings of "steep learning curve" and the such

<adanska>i mean, there is, but its very easy to ride that curve

<adanska>my only gripe with it initally was the install. grub 2.06 doesnt support many of the ext4 features that tools like parted enable automatically, and it doesnt tell you why it fails

<abrenon>well not that much actually, I defined a couple packages I was using, now I mostly enjoy the easiness when I need to generate systems, containers, and live USB to run my code somewhere else

<adanska>so i finished spending an hour downloading and installing everything, compiling linux and then for it to fail at the very last part haha

<abrenon>yeah, that happens

<adanska>took me like 5 days of pain to figure out what was happening

<abrenon>I didn't know there were such problems, I had the luck of falling into the nice cases from the start

<adanska>i was so upset it was something so simple haha

<abrenon>that's often how it is with comp. sciences, once you understand and fix the issue, it's become nothing at all

<adanska>i might see about adding an entry to the installation manual warning about that, because im sure there has to be people who are formatting their disks using some more up to date tool and then getting that sort of faliure

<abrenon>yeah, this kind of on-boarder first-glimpse feedback is very precious

<adanska>no worries! id hate for someone to give up guix even before they had a chance to try it because of something like that

<cbaines>any Guile experts around with any theories as to why we've sometimes dropped support for i686-linux and armhf-linux?

<ChocolettePalett>Not many developers have i686 CPUs these days, new intel CPUs with a spying OS on the chip are way much more popular among Free software enthusiasts

<abrenon>what do you mean "dropped support" ? it's not possible to run guix on a i686 CPU any more ?

<cbaines>abrenon, I'm seeing this through the data service, e.g. https://data.guix.gnu.org/revision/67fb8efdf782592c133726a1ab7bc6692259e385 shows only 67 packages supported for those systems

<cbaines>I haven't managed to reproduce the issue locally yet, but I'm pretty sure that sometimes guix will report that pretty much nothing is supported for those systems

<ekaitz>hi what's the proper way to obtain the parent directory in guile?

<ekaitz>i have a (dirname (current-filename)) but I need the parent

<cbaines>Maybe call dirname twice then?

<ekaitz>let me try

<ekaitz>oh it works

<ekaitz>lol

<abrenon>I remember trying to generate a liveUSB for one of an old i686 netbook

<ekaitz>cbaines: thank you...

<cbaines>you're welcome :)

<abrenon>and it proved surprisingly difficult but I'm pretty sure I managed to do it eventually by lifting any reasonable requirements in terms of GUI environments (I just wanted to get a shell running)

<ekaitz>i don't know why but i was thinking this wouldn't work, i was thinking doing dirname twice would return the same thing

<abrenon>something like cairo breaking or something, not sure it was a while

<jpoiret>cbaines: on latest master fzf is shown as supported on i686-linux for me, which has more than 67 dependencies i bet

<abrenon>ekaitz: because you expected the trailing slash to remain ?

<ekaitz>abrenon: might be!

<abrenon>not related but I finally managed to fix my locale issue on this new server where I'm guix-packing stuff

<abrenon>\o/

<cbaines>jpoiret, right, but for this revision it apparently doesn't support i686-linux and armhf-linux http://data.qa.guix.gnu.org/revision/182be30fb1a8b847c30492462ec22c08ec7a9849/package/fzf/0.41.0?locale=en_US.UTF-8

<cbaines>the derivations don't appear in the table on that page

<jpoiret>how do you check for the supported system?

<jpoiret>it might be that the guix CLI tools don't properly check for transitive supportedness

<cbaines>by calling package-transitive-supported-systems on the package

<abrenon>I could've used a little help but in the end I'm really glad to have solved this one entirely, maybe I'll end up understanding at least a little about locales and glibc and stuff

<cbaines>see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64762 for some more details, but I'm pretty sure this is some nasty non-deterministic issue

<jpoiret>I locally get i686-linux

<cbaines>jpoiret, right, and I haven't managed to reproduce this locally yet either, but I'm pretty sure it's a issue in Guix rather than the data service

<jpoiret>and can you reproduce that on the data service?

<jpoiret>what arch does the data service run on?

<cbaines>it's been happening quite frequently if that's what you mean

<cbaines>both data.qa.guix.gnu.org and data.guix.gnu.org are x86_64-linux

<jpoiret>I only realized recently that calls to package-transitive-supported-systems actually call package->bag

<jpoiret>i meant in an interactive session

<jpoiret>so that there could be some more info

<abrenon>in the end it amounted to exporting quite a bunch of env variables, by replacing /gnu/store/… to the path where I intended to deploy on the remote machine in the output of --search-paths

<abrenon>I suppose this must be frequently needed, is there any direct support for this in the output of guix pack ?

<abrenon>how can a packed bundle of software can be remotely useful (pun intended) without the proper variables ?

<jpoiret>depends on which engine you're using

<abrenon>what is the usual approach in this case ?

<jpoiret>did you source the /etc/profile of the bundle beforehand?

<abrenon>tarballs

<jpoiret>ah, for tarballs I don't think you should be unpacking anywhere other than root

<abrenon>hmmm it doesn't have a /etc

<jpoiret>it's even weird that this would work

<abrenon>well I did make it work : )

<abrenon>ACTION is proud

<jpoiret>any hardcoded references in the packages would point directly to /gnu/store and not where you unpacked it

<jpoiret>and that you can't really patch easiy

<abrenon>ok, but if you need to unpack to /, it means you must be admin on the destination server, doesn't it ?

<jpoiret>yes

<jpoiret>that's why the tarballs aren't the best for this

<abrenon>^^

<jpoiret>you want relocatable bundles instead

<abrenon>but what are the other options ? docker isn't available on the HPC environment I was targeting

<jpoiret>guix pack -RR

<abrenon>but I did make it -RR

<abrenon>and it didn't change anything

<jpoiret>then that's probably why it works

<abrenon>ahhahahaha

<abrenon>ACTION just found etc within the profile

<jpoiret>but it's weird that you don't have an /etc/profile in the tarball then

<abrenon>yes, I just hadn't though of "publishing" it through -S (like I did for /bin and /lib…)

<jpoiret>ah, yeah you need to symlink the profile's etc to /etc, same for /bin probably if you want to use the binaries

<jpoiret>then you just need to source that and start the program of your choice, and it should Just Work™

<abrenon>ok, so I suppose a sane approach would be to extract anywhere, and source the profile

<abrenon>yes

<abrenon>ok ^^

<abrenon>I'm being useless again, sorry

<abrenon>you may resume your interesting discussion on i686 ^^'

<jpoiret>no worries, I don't think that's properly documented

<jpoiret>you're talking to someone who only ever runs these commands to reproduce bugs, my knowledge of them is biased

<abrenon>quite understandable, where to put that ? it's directly related to the use of guix pack but not to the command itself

<abrenon>cookbook ?

<jpoiret>probably

<abrenon>I'm definitely going to take some note for myself, it's cost me too much time so far

<abrenon>wouldn't mind sharing that

<cbaines>jpoiret, I was being a bit blind, I now have a local reproducer https://paste.debian.net/plain/1286508

<cbaines>I was assuming that the data service computed revisions in a deterministic order, but it gets the order from Guix, which is apparently non-deterministic

<cbaines>and I think this is the source of the non-determinism

<cbaines>the breakage looks to be occuring for revisions where the i586-gnu derivations are computed earlier

<jpoiret>ouch

<jpoiret>I'll have a look after sending the fixes to the test suite

<rekado>ci.guix.gnu.org doesn’t respond

<cbaines>jpoiret, cool, I think it might have something to do with %final-inputs and the system argument not being used

<cbaines>I added (parameterize ((%current-system system)) in there, and then glibc-final started supporting i686-linux

<rekado>…and it’s back

<cbaines>rekado, I see missing metrics from hydra-guix-129 in the last 10 minutes, so maybe it wasn't just you having problems with connectivity

<jpoiret>cbaines: good catch!

<cbaines>I've sent a patch now regarding %final-inputs

<jpoiret>it's really terrible that we often have both a system argument and parameter

<cbaines>I guess there's no reason why either couldn't be used exclusively, but different bits favour different approaches

<janneke>jpoiret: that was quick!

<janneke>ACTION goes to reset hurd-team once more

<bjc>is hurd now using rumpdisk by default? i can see it in the process list, but i'm not sure if that means its in use

<janneke>bjc: no, rumdisk is only used when using the "noide" kernel-argument

<bjc>how do you specify that? there's no grub screen when starting the vm.

<janneke>"noide" disables the IDE driver in gnumach, which takes precedence over rumpdisk

<janneke>bjc: in your operating-system, use: (kernel-arguments '("noide"))

<bjc>👍

<jpoiret>you can also edit the grub line manually

<jpoiret>add noide and change hd0 to wd0

<bjc>while its booting, or from ‘operating-system’?

<bjc>the normal grub bootscreen is just the background texture when using ‘hurd-devel.tmpl’, and hitting keys didn't bring up a command line editor

<jpoiret>while it's booting

<jpoiret>you can press e on a boot option

<bjc>there's no menu at all is the thing

<bjc>just the background image for a couple seconds before it boots the kernel

<phf>Hello Guix! I think I might have stumbled upon an unexpected behaviour of ~guix~. Essentially, the package referenced by ~-f guix.scm~ is different depending on the arguments used to build the enviroment. For example: ~guix shell --preserve="^TERM$" -C -f guix.scm emacs coreutils tree~ and ~guix shell --preserve="^TERM$" -C -f guix.scm emacs~

<phf>Is this worth sending a bug report?

<HiltonChain[m]>Would --rebuild-cache option of guix shell help?

<phf>I'm trying.

<phf>It's perfectly correct. It works. Thanks.

<HiltonChain[m]>Ah, annoying. Matrix lost messages again...

<mirai>phf: might be worth it, no idea if its expected behavior or not

<nckx>I thought the mtime of the file was taken into account.

<nckx>If that's buggy or not happening, definitely worth a report.

<phf>OK!

<bjc>janneke: found the issue, the hurd-devel.tmpl uses ‘%hurd-vm-operating-system’, which uses ‘grub-minimal’ as its bootloader. using standard ‘grub’ gives me the menu back

<bjc>fwiw, the “root” argument to multiboot already uses “wd0”, not “hd0”

<janneke>bjc: ah, nice

<janneke>maybe we should move to using `grub', if that's (now easily) available

<bjc>it was a trivial substitution

<janneke>ACTION likes that :)

<bjc>ah, looks like the wd0 substitution is done by sniffing ‘kernel-arguments’ for “noide”

<bjc>oh, you did that =)

<janneke>it's kinda ugly: it breaks abstraction and assumes hurd, but yeah ;)

<bjc>the boot image/installation part of guix is a mess of broken abstraction already, so…

<bjc>i wish i had some good ideas to clean it up

<minima>hello :) i need to create a guix shell env that contains texlive; if i try and do that, it says it's going to redownload the whole shebang; i know i have the texlive "blob" already in my store, possibly from a few weeks ago; how do i tell guix to use that instead of downloading the latest version? i suppose this would involve using time-machine?

<janneke>bjc: ah...

<bjc>minima: there was a recent merge of the tex-team branch, which is most likely the source of your issues. i don't have a better idea than time-machine

<minima>not sure what to feed time-machine with, i suppose that i'd need to check my downloaded version of texlive, see what guix commit it belongs to, and then use that commit for the time-machine command?

<bjc>you can trawl through the git repo to see when it got merged and use the previous commit to that

<minima>bjc, hm super, that makes sense, let me try that, 1k thanks!

<bjc>alternately, if you remember a time when it worked, you could use the commit from ‘guix system list-generations’ that corresponds to it

<ncd>GUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUIX

<nckx>Gweks.

<ncd>What's going to be better for my long-term health TODAY: Finishing HTDP, or fixing my dryer?

<bjc>going for a walk

<nckx>Finding a different channel to spew noise in.

<ncd>I can't walk all day, though.

<ncd>nckx: Finishing HTDP is my criterion for getting to understanding guix

<ncd>Wonder if I could do them all.

<nckx>ACTION has never finished HTDP. Small wonder I don't know HTDP.

<minima>bjc: the first option worked like a charm, i was in a bit of a hurry with a task and this literally saved me, thank you so much!!

<bjc>👍

<ncd>lmao; I think the design recipe is very interesting, though I wish there was a way he would agree that you can eventually not write according to the recipe and have to simplify later.

<ncd>Do you guys write your scheme files in the "most obvious" way first, and then refactor, like people commonly recommend, or do you go at it as cleverly or tersely as possible as a goal?

<janneke>ACTION does the former, as their thoughts flow

<janneke>but it's a personal preference, it's how my mind works best

<nckx>☝ same.

<janneke>also, i often try not to solve the whole problem at once; rather first do the simplest case, test, extend, etc.

<janneke>solving (a part of) the problem for the first time, helps me understand the problem better

<apteryx>ncd: I like the '1. make it to work 2. make it right 3. make it fast' approach, often skipping 3

<apteryx>unless it's noticeably or on a critical path

<apteryx>nociteably slow*

<apteryx>noticeably**

<janneke>+1

<bjc>is “ghostscript-CVE-2023-36664.patch” not being found when using guix in a hurd vm a known issue, or did i miss something?

<bjc>i would love to know how guix gets copied into the store for the vm image, because i commented that out in my branch and its still showing up

<bjc>i assumed it was being pulled in from ‘guix-service-type’, but why wouldn't that use the environment from ‘pre-inst-env’?

<janneke>bjc: doesn't ring a bell here

<bjc>can you share your hurd config? this problem has had me stumped for a few days now, and its recent with some of the updates in the last week

<bjc>week or two, that is

<janneke>bjc: i'm using https://gitlab.com/janneke/guix/-/raw/wip-hurd/gnu/system/examples/devel-hurd.tmpl?inline=false for my regular development vm

<bjc>that's the same one i'm using

<bjc>weird

<janneke>i've just built and started an image

<bjc>i can't execute any guix command that i've tried due to that missing file

<bjc>‘guix pull’ runs for a bit before aborting

<janneke>oh wait, i haven't built a new VM in weeks *and* done development in it...

<janneke>also, i've only run ./pre-inst-env in a git archive on the hurd

<janneke>or tried guix pull --with-branch=/root/src/guix/wip-hurd

<janneke>hmm, guix is pretty broken in the latest image :-(

<janneke>bjc: and indeed

<janneke>guix build: warning: failed to load '/gnu/store/k3qwmhh9n8pf7pv0rplghifg2jdzxka6-guix-1.4.0-9.cce7fd7/share/guile/site/3.0/gnu/packages/abiword.scm': ghostscript-CVE-2023-36664.patch: patch not found

<bjc>whatever the problem is, it's from the guix installed in the image, since it's complaining about packages installed in /gnu/store

<janneke>ah, but it's missing from gnu/local.mk!

<janneke>oops

<bjc>missed in a merge, i guess?

<vagrantc>if only there were a CI system that could check for things like missing but used patches ...

<janneke>bjc: yes, in a rebase

<janneke>oops

<bjc>easy fix at least. thanks for looking into it

<bjc>you'll need %D%/packages/patches/ghostscript-CVE-2023-36664-fixup.patch too fwiw

<podiki[m]>hi guix

<janneke>bjc: yeah, thanks

<janneke>ACTION is testing a fix now

<podiki[m]>what's the latest on cuirass, lots of builds going but is still some day(s) behind?

<old>Question regarding debuginfod. Is there plan for support of it?

<apteryx>mirai: I've implemented your last comments for the wireguard dyndns feature; would you like a v6 posted, or are we good?

<apteryx>old: it'd be nice! I thought about it once, but there are more important things to fix first

<janneke>bjc: pushed fix to master, thanks!

<janneke>ACTION will reset hurd-team, wip-hurd in a moment

<apteryx>such as transitioning to use build ids instead of matching debug files by file name prefix (which breaks when using grafts)

<bjc>what's the difference between wip-hurd and hurd-team? last time i looked it seemed like wip-hurd was pretty out-of-date

<bjc>(that was some weeks ago, though)

<janneke>wip-hurd contains stuff that i consider not ready for digestion by mere mortals yet

<old>apteryx: I see

<janneke>bjc: indeed, also i have been keeping wip-hurd at an old commit for which i had substitutes available

<old>Hopefully we will have it later :-)

<bjc>got it

<bjc>my build machine killed itself last week, so i've been feeling the pain of building guix for hurd =)

<janneke>ouch, yeah hopefully we'll have substitutes rsn

<janneke>bjc, jpoiret: headsup, i've just reset hurd-team

<bjc>thanks

<janneke>now to re-create VMs ...

<apteryx>ACTION pushed the wireguard service dyndns feature; for those interested

<apteryx>it allows me to keep a permanently usable wireguard tunnel even to my home desktop which sits behind a dynamic dns IP

<janneke>apteryx: congrats

<apteryx>:-)

<bjc>by dyndns do you mean using rfc2136, or using dyndns.net?

<apteryx>duckdns.org in my case

<apteryx>maybe I should add a cookbook entry for it, I have a mcron job that does a GET to it, updating my IP

<bjc>i think that's the same api as dyndns. it'd be nice to have rfc2136 support

<apteryx>bjc: but the change I installed is for wireguard to re-resolve your machine host name

<apteryx>otherwise wireguard resolves it at start and keeps the same IP for the length it runs

<apteryx>so it assumes you already have setup dyndns for your host name

<bjc>ah, ok. that's a separate thing, then

<apteryx>old: did you see #64746 ? does it resolve the issue (in terms of documentation / user experience) for you?

<old>yes!

<old>Hopefully this wont break in the future :D

<apteryx>did you try visiting that old commit? (I haven't!)

<apteryx>the oldest commit

<apteryx>I'll do this and push if it works

<mirai>apteryx: I think its fine, its only a simple prefix change iirc

<apteryx>mirai: good, because I've went ahead and installed the change

<apteryx>thanks for the review!

<mirai>anytime :)

<old>apteryx: No I did not, but will happy to see the message next time I try to go too far in past!

<old>I guess that now the API is stable?

<old>In that, the time-machine will not break again?

<apteryx>yeah, despite inferiors being still labeled as a technology preview, I think it can't be broken in backward incompatible ways to avoid breaking time-machine

<old>okay!

<apteryx>ACTION tries: guix time-machine --commit=2ca299caf -- shell hello -- hello

<vagrantc>ACTION chuckles at finding nckx's not-thinking paste about the privledged binaries by some random prodding at browser history

<nckx>Hand me some of that good cheer, I need it. What new brain-rot is this: https://paste.debian.net/plainh/bccf36bb

<nckx>Good thing CMake can be read by humans and I have a clue how to patch the build scripts and they're not just long strings of uppercase constants.

<gabber>cheer? \o\ \o\ `o` `o` /o/ /o/ nckx

<gabber>but yeah, /gnu/store/.../bin/srec_cat is being installed thrice

<vagrantc>string(CMAKE_SALUTATION CHEER %s UTC)

<vagrantc>wonder what the consequences of making "true" setuid root might be.

<vagrantc>or false, for that matter.

<vagrantc>my real horse in the game is capabilities for lcsync

<nckx>gabber: Not just that, but its entire library closure. Including libm, libc, all the good stuff. Then the runpath is reset to that dystopian /lib.

<pjals_fox>/lib?!?? we dont talk about the beast here sorry

<nckx>*Not* including the linker loader (at which point you're just wondering: why not, upstream? Why not go all the way?) so runpath validation fails.

<gabber>nckx: i think here in this channel we call it "the joy of packaging", no?

<gabber>ACTION feels nckx's pain

<nckx>pjals_fox: Well, /gnu/store/$out/lib, but I'm pretty sure you're not supposed to put your favourite copy of glibc there.

<nckx>gabber: :)

<nckx>ACTION is full of joy.

<gabber>that's what i wanted to hear!

<nckx>ACTION gets the joyhammer.

<nckx>ACTION spreads the joy.

<vagrantc>ACTION blocks with a shield of misery

<nckx>Not my proudest moment: https://paste.debian.net/plainh/b52a0744

<gabber>you mean the chmod 755 * ?

<janneke>nckx: omg, what is the problem with certain upstreams?

<gabber>or rather commenting out CMAKE_INSTALL_PREFIX?

<janneke>ACTION stumbled upon library bundling with ghostscript when supporting the hurd

<nckx>gabber: I meant using substitute* to snip out part of a function, which admittedly worked out a lot cleaner than I expected. I'd written a whole FORMAT monstrosity I didn't end up needing.

<nckx>But the chmod is a nice touch too.

<pjals_fox>i once used to use cpm and i used to love it, now im a guix user, i despise it until the heat death of the universe

<nckx>Better not make these executables executable, possible security risk.

<nckx>We could easily invoke "bash" "foo.sh" in that case but that would be effor.

<nckx>—t, even.

<nckx>I'm just grumbling though, I'm not really that miffed now that I no longer have to look at CMake for the day.

<janneke>cmake: let's create our own broken language, using all caps, and make the documentation proprietary

<bjc>is the documentation really proprietary?

<vagrantc>if i keep running the same guix time-machine command ... should it be "Computing Guix derivation for 'x86_64-linux'... |" ... i thought that part would be cached

<janneke>i don't know, it was for the first 10y or so

<bjc>geez

<janneke>i have no real problem with people doing something so stupid

<bjc>how does something like that even gain a foothold when you can't read the docs?

<janneke>what i have problems with, is that people actually go support and use it

<pjals_fox>are there any better build systems anyways? better does not include make, it doesnt even support spaces in filenames

<janneke>autotools

<singpolyma>redo ;)

<lispmacs[work]>hi, I'm trying for the first time to run a local user instance of shepherd, which simply launches the "agate" service

<janneke>a big feature of autotools is that it's standard, can handle most everything and you don't have to dive into a package's home grown build system

<lispmacs[work]> https://bpa.st/PUOA

<gabber>nckx: i thought one *had to* substitute* major parts of CMakeLists.txt when fixing cmake builds..? turns out using opaque technologies invites anti-patterns even in the brighter of heads

<lispmacs[work]>but shepherd gives me this error:

<lispmacs[work]> https://bpa.st/HSBA

<gabber>lispmacs[work]: this is not a home-service, is it?

<lispmacs[work]>gabber: I'm not messing around with guix home just at present. Just working through the shepherd manual

<lispmacs[work]>and running shepherd as a normal user, with an init.scm in my home directory

<lispmacs[work]>the error message seems to tell me that I have passed in a bad keyword, but the few I used were straight out of the agate service documentation in guix manual

<lispmacs[work]>maybe I haven't loaded all the correct modules...?

<lispmacs[work]>yes, that might be it.

<lispmacs[work]>not sure

<janneke>pjals_fox: what i'd like to see is something like https://github.com/spk121/potato-make

<nckx>(-> ".c" ".o" (~ ($ CC) "-c" $<))

<janneke>nckx: yeah, a programming interface that looks less like line noise would be nice

<gabber>i mean, knowing both Guile and Make this kinda makes sense

<gabber>but i doubt this is inviting to anybody else (which is mostly make's fault)

<janneke>bjc: finally running `guix build hello` in a fresh vm

<jpoiret>tbh autotools and cmake really aren't comparable at all

<jpoiret>writing a proper CMakeLists.txt is wayyy easier than a proper Makefile.am

<jpoiret>it's not even a contest

<bjc>janneke: i'm still building the vm =)

<lispmacs[work]>i think I must be confusing guix system services vs. shepherd services

<bjc>my goal for now is to actually build ‘hello’, to get a handle on how big the image needs to be. 4G is not enough, regardless of what the example config says

<janneke>bjc: i guess that assumes having substitutes available

<bjc>that'd make sense. i'll need to remember to try it without substitutes to get the upper bound

<viaken>singpolyma - Wouldn't be hard to write a pure Guile redo-build-system. ;)

<janneke>ACTION has been using a 16GiB qcow2, fwiw

<janneke>jpoiret: hmm, my few confrontations with cmake build systems have been just terrible; and the fact that no free documentation was availeble has made me hate it with a vengeance

<apteryx>what does that mean? invalid build result (#<derivation /gnu/store/rj2g4x23lqyaq16471qm94xp90slxp3h-compute-guix-derivation.drv => /gnu/store/b70mihsj9xx0xxp6izliqb5vm462yifl-compute-guix-derivation 7fbf5bf82c30> "")

<apteryx>that's the result of my 'guix time-machine --commit=2ca299caf -- shell hello -- hello' experiment

<apteryx>which i assume is the oldest commit that guix time-machine may navigate to

<apteryx>travel*

<Mari[m]>does anyone know how i could fix this?

<Mari[m]>ACTION uploaded an image: (47KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/HRREcEfjbFMNmWoNUrpQuiMI/clipboard.png >

<gabber>Mari[m]: have you tried the instructions in that last line?

<nckx>Mari[m]: Did you explicitly install libdrm? If so, why?

<nckx>(Same applies to libadwaita, actually.)

<apteryx>re my previous time-machine experiment, it fialed with: ./guix/self.scm:903:2: In procedure guile-for-build \n Throw to key `match-error' with args `("match" "no matching pattern" "3.0")'.

<Mari[m]>i don't remember going out of my way to install libdrm

<nckx>Is it listed in ‘guix package -I’?

<nckx>(It accepts an optional search regex.)

<Mari[m]>ACTION uploaded an image: (80KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/jRsddVgHLfyEqjEYHzRRFSuQ/clipboard.png >

<Mari[m]>is my guix install fucked

<nckx>OK, so it's installed. If you don't have a reason for installing it, remove it.

<nckx>Why? Just remove the packages you don't need or might have installed by accident.

<gabber>Mari[m]: in Guix things are rarely ever f-d (: we just fix profiles or roll-back or something

<lispmacs[work]>Mari[m]: did you run a guix pull recently?

<Mari[m]>ok removing libdrm helped

<Mari[m]>lispmacs[work]: yes

<lispmacs[work]>can you just run guix upgrade, and then guixinstall libadwaita again?

<nckx>Mari[m]: The ‘I don't care, fix it now’ answer is ‘guix upgrade’ which will upgrade everything and shouldn't cause any propagation conflicts. But it's just kicking the tin down the road: you should remove this mystery packages you might have installed by accident or otherwise no longer need.

<lispmacs[work]>isn't guix just saying that you are trying to mix and old profile from an older generation of guix, and a package from a new generation of guix?

<nckx>That's not a problem per se.

<nckx>The problem is propagation. Propagation is evil.

<pjals_fox>this is why i dont use profiles, they are finnicky to work with

<lispmacs[work]>oh, so libepoxy should not be propogated?

<lispmacs[work]>propagated

<nckx>pjals_fox: You're always using profiles, at least one, and two on Guix System.

<nckx>lispmacs[work]: Sometimes a necessary or pragmatic evil. But it breaks guixy things, like being able to install different packages from different Guix versions, which is supported in general.

<vagrantc>nckx: this does not seem to set capabilities on lcsync ... https://paste.debian.net/1286561/ am i holding it wrong?

<nckx>It just undoes a lot of the clever functional package management stuff and yeets everything back into a global and somewhat monolithic environment.

<lispmacs[work]>wonder why libepoxy is propagated

<jpoiret>Imagine a very nicely presented plate of food getting thrown into a mixer

<jpoiret>It still tastes nice, but well

<gabber>jpoiret: wow

<gabber>what an analogy

<jpoiret>gabber: it's a surprisingly versatile one

<Guest84>Someone using browserpass and it works? Tried Firefox, IceCat, ungoogled Chromium and it does not for me.

<nckx>vagrantc: Hahahaha.

<nckx>The patch set is incomplete.

<nckx>It's missing the actual setcap.

<nckx>Yeah, that's not going to work.

<gabber>jpoiret: not sure i want to try to verify it, tho

<vagrantc>nckx: you *did* say you thought you forgot something.

<nckx>Aren't brains great. ‘Psssst… psst you forgot something.’ ‘Thanks for having my back buddy! What is it?’ ‘Hell if I know. Anyway, here's a song about cats.’

<nckx>I'll send a v3 when I'm back at that laptop next week.

<ncd>Wonderwall's about cats?

<pjals_fox>nckx: sorry, i was unclear, i ment the usage of `guix package <xyz>`

<vagrantc>cats are not insects, mostly

<nckx>pjals_fox: Oh, you don't use the implicit user profile at all?

<nckx>That's an option.

<pjals_fox>nope

<pjals_fox>i use guix home and guix system for my packages

<nckx>(Both create and load profiles, but I won't tell you if you don't want to know.)

<pjals_fox>(you already did :P)

<nckx>(No, I put it in parenthesis.)

<nckx>Aren't all songs about cats? Very few explicitly mention humans. A few jazz ones explicitly mention cats.

<nckx>vagrantc: Good point on the left-over directory (why would one ever want to revert my perfect patches‽)!

<nckx>I… don't see an obvious solution, however, the left-over won't be in $PATH once you reboot at least.

<vagrantc>that seems a generic problem for the handling of /run

<vagrantc>nckx: and... for setuid/setgid binaries ... not having them in $PATH is not a comfort :)

<vagrantc>FHS suggests to clean /run at boot time

<vagrantc>i know guix does not really use FHS ... but might want to implement that part of it :)

<vagrantc>submitted a bug about it, though don't have a number back yet

<nckx><comfort> I didn't mean security-wise, I meant confusion-wise.

<vagrantc>and ... #64775

<nckx>I agree that having a tmpfs /run is good.

<bjc>i gave that a whirl a while ago and crashed and burned

<nckx>By putting it in file-systems?

<bjc>activation doesn't work

<nckx>Happen to remember why?

<nckx>IC.

<bjc>i mean, some activation works, but a lot of it happens before reboot

<bjc>ideally most things can be moved to shepherd, but not everything will be able to

<nckx>So boot succeeds, but reconfiguration messes up the running system?

<nckx>Or not even that?

<bjc>i don't get as far as login, because certain parts of activation happen during system configuration

<bjc>i can't remember what, specifically, but istr account activation was one of them

<bjc>speaking of: https://issues.guix.gnu.org/62726

<bjc>it'd be nice to be able to run wireguard as non-root =)

<bjc>s/wireguard/wireshark/

<juliana[m]>guh, i feel like a dingaling. anyone know a good code snippet to get all the packages used by a build system? trynna replicate gnu-build-system with ((@ (guix build-system gnu) standard-packages)) tells me 'Throw to key match-error' with args ("match" "no matching pattern" "tar")'.'

<bjc>no matching pattern indicates a syntax error. like you've forgotten a parenthesis or some prefix, not a missing package

<juliana[m]>indeed

<juliana[m]>what should guix shell -e output look like? do we want write output, display output, an s-expression...?

<bjc>if that's for ‘guix shell -e’, drop the outside parens

<juliana[m]>tried that but standard-packages is a procedure so that just returns the procedure object

<bjc>what you have there looks like you're trying to call the procedure bound to ‘standard-packages’ from the ‘(guix build-system gnu)’ module

<bjc>oh, i see

<nckx>Also it has to return a list of packages, not, say, an alist.

<bjc>right

<nckx>No idea what it *does* return, just pointing out what might be an obvious oversight.

<juliana[m]>hmm okay so what if that lambda had like `(specification->package (car v))`?

<juliana[m]>i'll try it

<bjc>you can use ‘guix repl’ to execute that code, fwiw, and inspect it there

<bjc>i get an alist of string → package

<juliana[m]>yeah

<juliana[m]>so `(map (lambda (v) ((@ (gnu packages) specification->package) (car v))) ((@ (guix build-system gnu) standard-packages)))` does it except not all of these packages are exported... guess i'm just gonna have to do this by hand XD

<bjc>(lambda (v) (cadr v)) may do what you want

<bjc>there's no reason to use ‘specification->package’ when you already have the package in the alist

<juliana[m]>oh yeah i'd already tried that and it failed with the same error as the one I shared

<bjc>this worked for me: guix shell -e '(map (lambda (v) (cadr v)) ((@ (guix build-system gnu) standard-packages)))

<bjc>'

<bjc>and, actually, (map cadr …) would work. the lambda is unnecessary

<RavenJoad>If you want to make a manifest out of it, (packages->manifest (map cadr ((@ (guix build-system gnu) standard-packages)))) should also work.

<juliana[m]>ah!

<juliana[m]>bjc tysm!

<bjc>scheme needs a ‘second’ function so i don't have to inspire the wrath of luo by using ‘cadr’ because i don't want to resort to ‘match’ =)

<bjc>s/luo/ludo/

<janneke>bjc: second is defined in (srfi srfi-1), but my guess is that civodul dislikes cadr by any other name

<janneke>;)

<bjc>it's perfectly legitimate to hate c*r functions for being very poorly named and no other reason

<nckx>There are some (ordinals) in Guix.

<nckx>I think that's where I first encountered them.

<janneke>pun intended ;)

<bjc>a car encounter would be much less pleasant

<janneke>my other car is a cdr

<bjc>there's gotta be an etsy shop for this stuff

<bjc>$400 for a replacement mobo for my build box =(

<juliana[m]>oh no, that's a major bummer!

<juliana[m]>if it makes you feel any better I just executed guix shell -CFs riscv64-linux -e '(map (lambda (v) (cadr v)) ((@ (guix build-system gnu) standard-packages)))' and am about to do programming crimes (hardware enablement) thanks to your help

<bjc>it does make me feel better. i'd love to have the option to both: have a reasonable rv64 desktop, and run guix on it

<juliana[m]>right?

<Guest28>What is a mobo?

<bjc>motherboard

<Guest28>ah

<Guest28>isn't this a normal price nowadays?

<bjc>you can get 'em a lot cheaper if you don't need much

<bjc>the one in my nas cost something like $50

<Guest28>well, it is probably old hardware isn't it?

<bjc>nah, it's a 2nd gen ryzen. not that old

<bjc>sorry, 3rd gen

<Guest28>If you can get that for 50$, what cpu is that 400$ motherboard?

<bjc>for a 3950x, but i want the option to go to 5950x later if i need to. plus front header for usb c, so that means x570 chipset

<Guest28>Ah I see

<Guest28>If a package requires systemd-run, does that mean that functionality is not available or is there an alternative package?

<bjc>i don't think there's an equivalent available to guix

<Guest28>I see there is a huge new commit list, since there is now a texlive build system. I assume this is done in a seperate branch and if it works it is pushed to master but at the same time there would be substitutes available?

<Guest28>(basically my question is: those packages are already build if merged in master?)

<ulfvonbe`>anyone else find that shepherd git has a nondeterministic test failure in tests/close-on-exec.sh?

<ngz>Guest28: The texlive build system existed before the last merge. And yes, packages built in the separate branch are available in master.

<Guest28>ngz: Ah thank you. That means that the build farm does not differentiate between branches?

<ngz>Guest28: I'm pretty sure it does.

<Guest28>ngz. Ah okay. That means if you did fetch the latest revision, updating the system would lead to local compiling since the build farm has not finished building everything?

<ngz>Guest28: I wasn't clear. Packages (successfully) built in the separate branch are available as substitutes even if you install from master (assuming the branch was merged).

<Guest28>ngz: Okay got it. How much disk space is currently allocated for all those packages?

<ngz>No idea.

<Guest28>ngz: https://issues.guix.gnu.org/64729 I have the same issue after upgrading. Does that mean texlive itself isn't enough anymore?

<ngz>I fixed the python-nbconvert package.

<ngz>So the issue should be gone if you pull again.

<Guest28>You mean again as of now? I pulled roughly 30 mins or 1 hr ago

<Guest28>With the command you provided I get "! LaTeX Error: File `xcolor.sty' not found." (this is on my file not your example)

<Guest28>(need to reboot)

<Guest28>Ah okay nvm. I needed to reboot for something else and tried again. It works now fine. Thought respawning the terminal would be enough

<ngz>Guest28: My example is minimal, and is about XeTeX. It doesn't (and needn't) provide "xcolor.sty". I don't know what packages are needed to compile your document. You may try a different "starter kit", such as `guix shell texlive-scheme-small -- latex your-file.tex'

<Zambyte>Hi, does anyone know why I would not be able to execute a binary with a "no such file or directory" error, when the binary definitely exists?

<Zambyte>For context, I'm trying to run wally from: https://github.com/zsa/wally

<Zambyte>(ideally I would package this, but for now I just need to run it)

<nckx>Is this a downloaded binary?

<nckx>Those hard-code library names and directories that don't exist on Guix System.

<Zambyte>ldd shows all of the dependencies found. Running ./wally in the directory I have it downloaded says not found

<nckx>Also /lib/ld-linux-x86-64.so.2 ? Have you tried a Guix FHS environment?