IRC channel logs

<markasoftware>When I run guix pull as a user, then subsequently run guix pull as another user, why does it take so long? Can't it see all the built derivations in the store?

<raingloom>mbakke: oh. go-build-system led me to replace-store-references. it has some comments about its implementation not being very efficient and the graft.scm one being better.

<raingloom>but since they basically do the same thing except one being in-place and the other not, and one taking a vhash and the other mapping to a constant, i thought it would be nice to deduplicate things.

<raingloom>mbakke: ...actually, remove-store-references is not what i want, i only want to remove certain references.

<Bumblehorse>When I try and clone the guix repo I get the error "git: 'remote-https' is not a git command.". I then checked guix edit git for any extra outputs and tried all of them except for the gitk/gui one, but I still get the same error. Does anybody know why?

<Bumblehorse>I also guix pulled and update the normal git output

<raingloom>Bumblehorse: how are you running git? what's the exact command?

<Bumblehorse>git clone https://git.savannah.gnu.org/git/guix.git

<Bumblehorse>Right out of the manual

<Bumblehorse>I found a work arouns URL but I still would like to know why I can't use this one

<Bumblehorse>The URL git://git.savannah.gnu.org/guix.git works just fine (from https://git.savannah.gnu.org/cgit/guix.git)

<raingloom>Bumblehorse: guix environment --pure --ad-hoc git nss-certs -- git clone https://git.savannah.gnu.org/git/guix.git

<raingloom>i tried with this, it worked

<raingloom>from a quick search for the error message, it would seem like it only happens when $PATH doesn't have some git subcommands on it? i think???

<raingloom>so if you run git from an absolute store path without the rest of it being on $PATH, it would not find its other parts.

<Bumblehorse>Interesting

<xelxebar>Hrm. I'm unable to clone git repositories from https repos: git: 'remote-https' is not a git command. See 'git --help'

<xelxebar>Looks like I'm missing git-remote-https.

<xelxebar>Any idea what provides that? Don't see any specific git outputs that look promising.

<raingloom>xelxebar: Bumblehorse just had the same problem.... maybe something broke the most recent git and mine only works because i'm a day behind...

<Bumblehorse>raingloom: Mine was much older, I just upgrading because I though that would fix it

<Bumblehorse>upgraded*

<xelxebar>Wait, git-remote-https sits under libexec/git-core/ it looks like. Why is git failing to find it then?

<mbakke>xelxebar: probably because GIT_EXEC_PATH is unset (did you try logging out and in again?)

<xelxebar>mbakke: Oh. It's set, but to the wrong thing :/

<mbakke>huh

<xelxebar>For some reason it's getting set to $HOME/.config/guix/current/libexec/git-core; however, there is no git there. It should be under .guix-profile/ instead

<xelxebar>There's nothing like that in my .profile.

<mbakke>xelxebar: which distro are you on?

<mbakke>or: how did you install guix?

<xelxebar>It's a Guix System.

<xelxebar>mbakke: Um. I think it's my profile doing something funky. By moving it out of the way GIT_EXEC_PATH looks to be set correctly.

<xelxebar>Thanks for pointing me in the right direction!

<mbakke>xelxebar: do you mean ".profile"?

<xelxebar>Whoops. yes my ~/.profile.

<mbakke>xelxebar: that problem can happen if $GUIX_PROFILE is set to ~/.config/guix/current by the time ~/.guix-profile/etc/profile is sourced

<xelxebar>mbakke: I suspect that is what is happening. I copied this profile from my previous system which was guix on a foreign distro. It manually sources .guix-profile/etc/profile. You're most likely correct.

<xelxebar>Cheers!

*xelxebar gives internet cake to mbakke

<mbakke>xelxebar: cheers, glad you figured it out :-) on Guix System you don't have to source those profiles explicitly (see /etc/profile)

<xelxebar>Is there any particular reason that virt-viewer is built without VNC support?

<nckx>Good morning, Guix.

<Bumblehorse>Good morning, nckx how are you?

<nckx>Sleepy but well.

<nckx>Thank you. Yourself?

<Bumblehorse>I'm doing just fine. I just sent in my first patch (also first patch for any project).

<mroh>\o/

<nckx>Sweet.

<Bumblehorse>After a patch is sent what happens? I would assume it sits in a queue for someone to look it over and then if they like it they just commit it?

<nckx>Hum. It's more of a heap than a queue, and review is much more ad-hoc than we'd like (if not almost random). But yeah, someone will eventually look at it, provide feedback, and if there are no major issues, commit it.

<nckx>xelxebar: I doubt it. Its VNC support works fine once enabled.

<nckx>Done on master.

<Bumblehorse>Aha I see why you said we. I didn't realize until today that a bunch of you are top-dogs until I found the members list on savannah.

<Bumblehorse>What is the difference between an admin like yourself and a member?

<nckx>Bumblehorse: Don't read to much into it. We don't have much of a hierarchy.

<Bumblehorse>Lol ok

<nckx>*too. Are your patches the aforementioned 3 emacs packages?

<Bumblehorse>Well I only sent one in since I was supposed to separate them

<Bumblehorse>I though that I would then wait for the next two incase there was an issue with the first

<Bumblehorse>I doubt there would be an issue though... it's just an emacs theme...

<nckx>That's fine and probably a good idea for your first patch.

<nckx>It just doesn't seem to have arrived yet.

<Bumblehorse>Oh no

<nckx>If you sent it to guix-patches at gnu.org it will arrive eventually.

<Bumblehorse>Oh crap I forgot the period at the end of the commit message/header

<Bumblehorse>Yes I did

<nckx>Bumblehorse: Oh no...! 😮

<nckx>You'll recieve a friendly note to add it!

<nckx>(And then the committer will add it for you and commit anyway.)

<Bumblehorse>:)

<xelxebar>Bumblehorse: Congrats on your first patch!

<Bumblehorse>Lol thanks, it's kinda pathetic though. I'm still having issues with gtick so I decided to try something that won't keep me up at night trying to fix angrily.

<Bumblehorse>I was quite suprised to see that emacs-nord-theme wasn't packaged though. It's quite popular.

<Bumblehorse>atleast on r/unixporn...

<xelxebar>Yeah, the packages aren't hard *per se*, but there are a lot of moving parts and details. It makes a lot of sense to start with something simple, if nothing else than for your own sanity.

<xelxebar>Speaking of sanity... somehow I screwed something up after a reconfigure. Can no longer sudo or login from a different console...

<Bumblehorse>o_o

<xelxebar>Trying to run docker-service-type, it claims to need elogind-service, so I enabled both. Suspect that the latter is doing something with PAM that's killed my login...

<xelxebar>Maybe I just need to restart a herd service?

<Bumblehorse>I wouldn't be able to say.

<mroh>hmm, I haven't tried, but is php really needed in libsoup?

<lfam>sneek: later tell nckx: Thanks for your help!

<sneek>Got it.

<xelxebar>Tried a reboot and herd would immediately reboot the system. Luckily, because this is Guix, I could just boot from a previous working generation.

<vits-test>mroh: php is for tests, maybe?

<jackhill>l

<dannym>xelxebar: Can you check /var/log/messages ? It should still contain messages from the failed generation

<xelxebar>dannym: Oh nice. I can find the points in the log that correspond to different boots; however, after a cursory scan, nothing stands out.

<xelxebar>Unrelated, but when trying to start shepherd as a normal user, it complains that /run/user/UID/shepherd doesn't exist. In fact /run/user/UID doesn't even exist.

<xelxebar>Is there a proper way to get those directories created?

<mothacehe>hello guix!

<dannym>xelxebar: Yes. elogind

<dannym>xelxebar: But that's a bad idea if it doesn't work ;)

<dannym>xelxebar: For what it's worth, it works here--so it's not generally broken

<dannym>(docker works here, too)

<dannym>it works=elogind works

<dannym>xelxebar: What login manager are you using?

<xelxebar>dannym: Are you using %desktop-services? My config.scm is minimal. Currently, I am starting X manually via xinit.

<xelxebar>dannym: Currently, I have no login manager installed.

<dannym>Oh okay

<dannym>xelxebar: Yes, I'm using %desktop-services .

<dannym>xelxebar: That means maybe elogind should complain about something else being missing, like docker does for elogind :P

<dannym>should=should be made to

<dannym>Unfortunately, I can't think of an easy way to find out what it is if there's no log messages

<xelxebar>Yeah, that's what I suspect. It seems almost all guix users make use of some login manager, so I'm likely striding through untested territory here.

<dannym>xelxebar: Can you file a bug at bug-guix@gnu.org about it (too)?

<xelxebar>Before rebooting and after reconfiguring with elogind and docker, I immediately had problems with pam authentication. Wasn't able to login in on a different console; sudo failed to auth; etc. Maybe there's a hint there.

<xelxebar>dannym: Well, I'd like to, but I have very little to report. I guess I could just share my config.scm and see if people can reproduce the issue.

<dannym>xelxebar: Yes, please

<dannym>xelxebar: elogind-service-type extends pam via pam-extension-procedure, which adds "pam_elogind.so" to pam config

<dannym>xelxebar: Sharing the config.scm in order to reproduce this is already a big help--after all, one can start this in a system vm and have a much nicer debug environment than a real machine

<dannym>(via "guix system vm-image")

<xelxebar>dannym: Hrm. Just to be clear, I find no "elogin-service-type" in the manual. So I directly invoked (elogind-service) in my services.

<dannym>xelxebar: %desktop-services does that too. I says "(elogind-service)" in there

<dannym>xelxebar: If you want to debug it, you can divide and conquer %desktop-services

<dannym>xelxebar: It's in https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/desktop.scm at the bottom

<dannym>xelxebar: You can just copy&paste the content of %desktop-services into your services list

<dannym>xelxebar: Then delete a random half

<dannym>xelxebar: reconfigure again

<dannym>xelxebar: Try if it works

<dannym>xelxebar: If it doesn't, remember this half as containing a problem; otherwise re-add the half.

<dannym>xelxebar: Continue likewise

<dannym>(with smaller halves)

<leoprikler>dannym: Don't mention-bomb if you are going on a chain

<leoprikler>chances are your target is going to continue to read until they have all the info they need

<xelxebar>dannym: Thanks. Binary-searching through the list of services is a good idea. I'll probably do that, if nothing else, so that I can give a better bug report than "this failed to work"

<xelxebar>leoprikler: :)

<leoprikler>:)

<dannym>A lot of them are very probably not the culprit, like sane, cups, network-manager, usb-modeswitch, avahi, udisks, geoclue, ntp, pulseaudio, alsa

<leoprikler>for the record, what are we debugging here?

<xelxebar>Okay, so exporting XDG_RUNTIME_DIR lets me run a user instance of shepherd. Very cool.

<dannym>Very probable changing-things (in PAM etc) entries are screen-locker-service, polkit-wheel-service, accountsservice-service (!!!)

<dannym>, dbus-service

<xelxebar>leoprikler: Enless reboot cycle problem. I added docker-service-type and elogind-service to config.scm and reconfigured. That promptly caused sudo to fail authenticating me and console login failed similarly

<xelxebar>I tried rebooting and after completing the kernel load, it would quickly drop back to BIOS.

<leoprikler>do you get the same if only adding elogind?

<xelxebar>Reverting to the previous generation successfully boots and can log in.

<xelxebar>leoprikler: Haven't tried yet. Still at work :p

<nixo_>Hi guix! Do any of you know if/when emacs-guix (https://gitlab.com/emacs-guix/emacs-guix/-/issues/27) is going to be fixed?

<sneek>nixo_, you have 2 messages!

<sneek>nixo_, NieDzejkob says: Ouch, I just saw your fixups of my commit. Sorry for that, I should've given it a deeper review :/

<sneek>nixo_, peanutbutterandc says: surprise! https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42960 (:

<nixo_>NieDzejkob

<nixo_>oops

<xelxebar>Someone running a Guix System, would you mind checking if /run/user/$(id -u) exists for you?

<dannym>xelxebar: It does exist for me

<dannym>none on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)

<divoplade>It exists for me too

<dannym>tmpfs on /run/user/983 type tmpfs (rw,nosuid,nodev,relatime,size=786924k,mode=700,uid=983,gid=978)

<dannym>tmpfs on /run/user/27481 type tmpfs (rw,nosuid,nodev,relatime,size=786924k,mode=700,uid=27481,gid=998)

<xelxebar>Thanks. I suspect that elogind is creating those for you.

<efraim>it might be worth looking into whether the elogind-service does anything with 'linger', /var/lib/elogind/linger/<username>

<efraim>where is channel documented? I want to see if I can put several channels inside one repository, with one or more depending on other different channels

<efraim>ah, chapter 6 of the manual

<civodul>Hello Guix!

<wleslie>good GMT morning, civodul!

<iyzsong-w>hello z.Z

<civodul>hey iyzsong-w & wleslie!

<civodul>iyzsong-w: night time for you?

<iyzsong-w>no, at work, writing some Dockerfiles..

<davidl>has anyone advice on how to package python packages that don't use setup-tools?

<abcdw>civodul: What do you think, Is "Nix vs Guix" a good topic for Guix Day?

<davidl>I don't know how to ensure they are correctly added so they can be found and used by other python packages.

<leoprikler>What build system do they use? GNU, Meson, ...?

<efraim>abcdw: I would be interested. Also there are some of us who didn't come to Guix from Nix, and there are those who haven't used Nix in a while

<leoprikler>Hand-crafted Makefile? ;)

<efraim>I'm still trying to figure out what I want to do for a presentation.

<wleslie>abcdw: was it you who gave the equivalent talk at nixconf 2019?

<abcdw>wleslie: Nope

<civodul>abcdw: sure, something about what we can learn from each other would be nice

<civodul>i mean, in a constructive fashion :-)

<civodul>i agree with efraim here

<wleslie>ah. well, there was an enjoyable talk I watched recently.

<civodul>wleslie: yeah i saw it as well

<civodul>abcdw: BTW, zimoun & roptat are the ones really overseeing the Guix Day

<abcdw>wleslie: Do you recommend to check out that enjoyable talk from nixconf 2019?)

<efraim>I think the setup for running guix services in guix VMs on a foreign distro might be interesting

<abcdw>civodul: Thank you for information!

*efraim means in terms of talks I could probably do

<wleslie>sure. vagrantc also gave a great talk from the debian perspective a few years back.

<efraim>"everything is negotiable" would be a nice title for "howto hack any package or service"

<leoprikler>Negotiations are not negotiable.

<efraim>I thought about something with statically compiled languages (haskell, go, rust) but at this point it would mostly be a rant, so not so useful

<civodul>heh :-)

<leoprikler>"Why node-build-system is still screwed even with esbuild"

<abcdw>sneek, tell what you can

<sneek>what, abcdw says: you can

<wleslie>davidl: got an example?

<leoprikler>/msg sneek help

<abcdw>leoprikler: thanks

<leoprikler>sneek, apropos call/cc

<sneek>(guile): call/cc #<procedure call-with-current-continuation (_)>

<efraim>'quick and dirty guix.scm' would actually probably be nice for howto use guix when contributing to other projects

<abcdw>sneek, later ask roptat Is "Nix vs Guix" a good option for Guix days? If yes do I need to make a separate recording or I can just cleanup stream recording and provide webm file?

<sneek>Okay.

<abcdw>sneek, botsnak

<abcdw>sneek, botsnack

<sneek>:)

<davidl>wleslie: I do. I have a package called python-nbdev-org-babel which depends on nbconvert which depends on testpath, but testpath is not found at runtime for nbdev-org-babel. Looking up testpath we can see it's packaged using python-flit. the nbconvert package I use is here: https://github.com/methuselah-0/my-guix-packages/blob/master/packages/python-extras.scm#L151

<davidl>wleslie: the testpath-0.4.4 I use is just below, or here: https://github.com/methuselah-0/my-guix-packages/blob/master/packages/python-extras.scm#L205

<c4droid>Hi, I'm trying move my disk to lvm for my Guix System installation, the lvm-device-mapping type is available now?

<civodul>c4droid: hi! close, but not quite unfortunately: https://issues.guix.gnu.org/41143

*civodul pings the author

<c4droid>civodul: it's still developing now?

<civodul>it's under review, almost ready but we're waiting for the hopefully last iteration from the person who implemented it

<c4droid>civodul: OK, I'll move to LVM when lvm-device-mapping type available

<roptat>hi guix!

<sneek>Welcome back roptat, you have 1 message!

<sneek>roptat, abcdw says: Is "Nix vs Guix" a good option for Guix days? If yes do I need to make a separate recording or I can just cleanup stream recording and provide webm file?

<thorwil>hi! how do i start docker on a foreign distro? as “sudo systemctl start dockerd” fails with “Failed to start dockerd.service: Unit dockerd.service not found.”.

<roptat>thorwil, on a foreign distros, guix does not manage your services, so you have to manage them yourself, or use your distro's package manager

<thorwil>roptat: well, i would like to manage that service, but it seems the guix package is not set up for that? does this mean services installed via guix are useless on a foreign distro?

<roptat>guix doesn't "install" services, so yes :)

<roptat>although, maybe the docker package comes with a .service file? I don't know

<roptat>in that case you need to point your systemd to ~/.guix-profile/etc/services or something similar

<roptat>but we don't use systemd, so it's not guaranteed to work, even if the file might be there

<roptat>(and it's not there, I just checked)

<roptat>so your solution would be to write your own systemd service for guix' docker

<leoprikler>Btw. has there been any work on shepherd's proposed systemd compatibility layer?

<roptat>abcdw, I think it's a great subject for the guix day! You just need to make sure not to advertise nonfree software (your stream is a bit borderline in that regards), otherwise I guess it was fine. You'd need to polish it a bit for a more conference format, but I don't think a new reconding is required. Can you drop a message to guix-days@

<jonsger>leoprikler: I think there is an idea of a GSoC project having a translator for systemd service files to shepherd services

<leoprikler>that's the one I mean

<leoprikler>Is it being worked on or was it merely a proposal?

<jonsger>leoprikler: it was only a proposal

<jlicht>I think civodul made some things happen RE: signalfd support in shepherd, which was tangentially related to having support for .service files

<abcdw>roptat: sure, will write to ML.

<vits-test>sneek: later tell sneek botsnack

<sneek>:)

<raingloom>roptat: did you get my yggdrasil followup? i only saw your reply on issues.guix.gnu.org, but it never got to my email inbox for some reason, so it's possible the email demons also ate my email before it reached yours.

*vits-test one simple #\a, but such a difference!

<roptat>raingloom, I might have missed that

<roptat>raingloom, I see you still have a single patch to add go-github-com-mitchellh-mapstructure and go-golang-zx2c4-com-wireguard; can you split it?

<roptat>while you're at it, can you add #t at the end of the 'install phase in yggdrasil?

<roptat>with that, I think I can push everything for you :)

<raingloom>hec,, i was _sure_ i spli everything

<raingloom>*split

<raingloom>did i send the wrong patch file somehow? o.o

<raingloom>damn.

<raingloom>i actually wanted to remove the mapstructure patch because it's already packaged. >_<

<roptat>ah

<roptat>mh... can you send a new message with the patches you want me to apply'

<roptat>?

*civodul works on flagging cases where we wrongfully import the host (guix config) module

<civodul>enough is enough! :-)

<roptat>civodul, when are we branching? I'll need to send a new tarball to the TP

<civodul>roptat: you can already send it and we can branch as well

<civodul>i've been meaning to do it but got busy with other things

<civodul>sorry for the delay!

<roptat>it's fine, but it'll delay the release

<roptat>I don't want to send a tarball until we branch, because we might change the strings after I generate it

<civodul>ok, i can create the branch within the next hour or so

<roptat>thank you :)

<roptat>ping me when it's done, I'll send a tarball from that branch

<raingloom>roptat: a sec, i wanna test it to make absolutely sure it works with the already packaged mapstructure version

<roptat>sure

<apteryx>civodul: what kind of strace command did you run on the .gnome-shell-real process to validate it worked in a guix system vm?

<apteryx>I was trying something along 'strace -s200 -p $PID |& grep .guix-profile'

<apteryx>(good morning, by the way :-))

<civodul>moin apteryx!

<civodul>apteryx: "strace -p PID -s 200 -o log -f", where PID is .gnome-shell-real of the user

<apteryx>OK, did you see actual file names in there (that would contain $HOME/.guix-profile ?)

<apteryx>I only see opaque file descriptors

<apteryx>it seems to output more stuff when I recreate /run/current-system, but it doesn't seem to react to recreating $HOME/.guix-profile.

<maav>apteryx: i didn't noticed your nick! i'm reproducing the issue with emacs...

<maav>it's quite weird as the eval somehow appears in file-local-variables-alist

<apteryx>perhaps because it's used for any modes? does moving the snippet to scheme-mode only buffers work around this?

<Fenlair>hi all

<apteryx>hmm, 'guix system vm-image' is broken: https://issues.guix.gnu.org/44468

<apteryx>Fenlair: hello!

<vits-test>+1

<mothacehe>apteryx: That's sad. In the meantime you can use `guix system disk-image -t qcow2 my-os.scm` that should achive the same result.

<raingloom>roptat: sent the patches a few minutes.

<raingloom>(just a heads up, in case the email demons eat them)

<civodul>apteryx: oh i fixed that yesterday

<civodul>i noticed it while testing the GLib patch

<civodul>commit 341f67991da4380485676987e24a3fac01403835

<civodul>:-)

<apteryx>oh, thank you!

<apteryx>you're a time saver ;-)

<civodul>heh

<civodul>apteryx: regarding your previous question above, i did see file names under ~/.guix-profile/share

<apteryx>hm, it seems unrelated, but I now get: https://paste.debian.net/1170054/

<civodul>oh i used "strace -t" actually to have timestamps

<civodul>and to make sure i'm looking at what happened right after i created ¿.guix-profile

<civodul>er, ~/.guix-profile

<civodul>dunno, looks like an ABI issue

<civodul>i've just pushed changes to (guix gexp) that require "make clean-go && make" BTW

<civodul>roptat: i've create the 'version-1.2.0' branch!

<civodul>it's identical to 'master' right now but i hope to change "NEWS" in there RSN :-)

<maav>apteryx: seems that at least the reproducer (fresh emacs with geiser+magit -> open guix file -> ! -> Start magit -> start geiser session -> M-. -> M-. -> open file without dir-locals.el -> C-x v =)

<maav>apteryx: ... the reproducer doesn't happen when it's only for scheme, mode

<apteryx>OK, so perhaps that's what we should do. It was neat to be able to 'run-guile' anywhere and have it work, but if that somehow leaks to other projects that's a no go.

<Fenlair>Man, to whoever wrote the documentation at guix.gnu.org, that's some fine work!

<maav>apteryx: do you want to move it? i feel bad because i gave you so much changes... and even then i missed things :(

<apteryx>maav: it probably had that problem to start with :-). There's no need to feel bad.

<maav>my erc is going mad because of the debugging...

<maav>brb

<apteryx>I've never tested the 'no' case, I expected nobody would since there's no way to have Emacs persist a 'no' answer (and thus it is super annoying, with or without this change).

<apteryx>civodul: ah, yes, make didn't fly. Rebuilding.

<roptat>civodul, thanks!

<Fenlair>If I want to add remmina to the repository, would I add a remmina.scm file or merge it into rdesktop.scm?

<bavier[m]1>rdesktop.scm imo, it has a bunch of other "remote desktop" stuff.

<apteryx>civodul: hmm, I don't see how it'd pick up changes to /root/.guix-profile (running as root in the VM), given: 'cat /proc/257/environ | tr '\0' '\n' | grep XDG_DATA_DIRS | grep .guix-profile doesn't return anything

<apteryx>257 is the process corresponding to .gnome-shell-real

<apteryx>XDG_DATA_DIRS comes from the wrapper .gnome-shell-real

<apteryx>hmm, that means our proposed fix still depends on the exported XDG_DATA_DIRS value from /etc/profile... which is not great.

<apteryx>this was with my modified version which expected to see $HOME/.guix-profile/share and /run/current-system/share in XDG_DATA_DIRS. I think your version must work since it doesn't care about XDG_DATA_DIRS and installs monitor to hardcoded locations, which is better :-)

<civodul>apteryx: exactly, it hard-codes ~/.guix-profile, for better or worse :-)

<civodul><Fenlair> Man, to whoever wrote the documentation at guix.gnu.org, that's some fine work!

<civodul>Fenlair: you made my day!

<civodul>we rarely get positive feedback about the doc :-)

<civodul>mothacehe: so! with the latest changes i pushed, "guix weather -m etc/system-tests.scm" will tell us where we are!

<civodul>well, that + guix publish cache bypass

<mothacehe>civodul: nice! Installer tests seem broken on the CI. There were fine until yesterday :(

<mothacehe>*They

<apteryx>civodul: I'll give another shot at adding /run/current-system to your patch and retest

<apteryx>I don't want to see this issue again on the tracker next week when someone decides to reconfigure with a new application on their operating-system record ;-)

<civodul>apteryx: sounds good!

<civodul>i'll focus on NEWS meanwhile

<civodul>mothacehe: oh, did i break something?

<Fenlair>civodul: and the documentation made my day :P

<Fenlair>I cloned the guix git repo -> guix environment guix --pure -> ./bootstrap -> ./configure so I get the ./pre-inst-env. Then I wanted to do ./pre-inst-env guix build remmina --keep-failed, which failed :( 'failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory'

<civodul>ah you probably need to run ./configure with --localstatedir=/var

<civodul>so that it looks for /var/guix/daemon-socket/socket

<mothacehe>civodul: not sure they timed-out, which was a symptomatic of https://issues.guix.gnu.org/41948

<civodul>oh no, not that one

<mothacehe>I have a Guile fix for that, but it will have to wait for after 1.2 I think!

<civodul>you rock!

<civodul>we'll feel relieved when it's fixed

<Fenlair>civodul: thanks :)

<jonsger>civodul: is this expected with guix weather: https://paste.opensuse.org/view/raw/84301854

<civodul>jonsger: hmm no

<civodul>weird, it works for me

<civodul>but i think the installation tests require ./pre-inst-env

<apteryx>civodul: was there a reason for not reusing the existing desktop_file_dir_changed callback?

<apteryx>it does g_mutex_lock which seems safer

<apteryx>civodul: I'll be testing this: https://paste.debian.net/1170062/

<pkill9>is it possible to run something as root in a guix container?

<pkill9>with sudo for example

<civodul>apteryx: yes, that's because we're watching ~/.guix-profile but our DesktopDir is ~/.guix-profile/share

<civodul>whereas the rest of the code assumes that the two are the same

<civodul>pkill9: in a "guix system container" kind of container, i think so

<pkill9>i tried exposing /run/setuid-programs but they are owned by 'overflow' in the container

<pkill9>oh, i havent' tried guix *system* container

<pkill9>ohh i see

<pkill9>thats the one you pass a system config to

<pkill9>yea hopefully that will work

<civodul>maav: oooh, ¡me parece que hay una traducción del sitio en Castellano!

<civodul>¡muchas gracias compañero! :-)

<civodul> https://guix.gnu.org/es/ (for those wondering)

<jorge[m]> https://guix.gnu.org/en/blog/2020/online-guix-day-announce-1/

<maav>civodul: gracias a ti :)

<maav>also, i have to push a change from the first review, missing ó

<civodul>maav: also the headline at the top is not translated

<maav>i have to update the pot first for that too, thanks for the heads up :)

<maav>also... roptat, civodul: are we pushing a new tarball to tp soon? i have it almost ready already (manual + guix), hehe

<roptat>maav, I'm on it

<roptat>I'll ask the coordinator in a moment

<maav>roptat: thanks a lot :)

<roptat>sent, hopefully it'll be available on the tp soon

<civodul>woohoo!

<jonsger>civodul: guix environment guix -- guix weather -m etc/system-tests.scm fails for a recent master checkout for me

<jonsger>as well as outside the environment

<civodul>the environment has no effect though, unless you meant "--ad-hoc guix"

<civodul>"guix time-machine -- weather -m etc/system-tests.scm" works for me tho

<jonsger>ad-hoc fails now with: guix weather: error: canonicalize-path: Datei oder Verzeichnis nicht gefunden: "/gnu/store/pj99lz2fjhh773qi9mz71gvldrf9qxd8-guix-1.1.0-31.1c6d985/share/guile/site/3.0/gnu/installer/aux-files/logo.txt"

<jonsger>so I guess my installation is maybe to old...

<pkill9>didn't know you could pass .drv file to guix build

<pkill9>has anyone managed to run openvpn in a guix system container?

<roptat>raingloom, finally pushed!

<raingloom>roptat: \o/

<raingloom>thanks so much :D

<raingloom>also for putting up with my many MANY failed attempts

<luis-felipe>maav: Te quedó muy bien la traducción :) Hay algunas cositas que me parecen raras, tal vez porque hablo otro tipo de español, pero en general se ve bien.

<sneek>Welcome back luis-felipe, you have 1 message!

<sneek>luis-felipe, mroh says: for a mumble server (murmur) running on your machine, you only need to forward one tcp and udp port (64738 standard) on your router.

<maav>luis-felipe: gracias, ¿cuál? he intentado usar el castellano más neutro posible (por ejemplo, uso usted en vez de tú)

<maav>se agradecen los comentarios :)

<luis-felipe>sneek: Later tell mroh: Thanks, but I don't have access to the router myself. I kinda depend on services run by kind souls on the Web.

<sneek>Okay.

<luis-felipe>maav: ¿Esta traducción busca ser panhispánica o ibérica?

<luis-felipe>Igual lograr algo que le guste a todo el mundo es muy difícil, pero hay algunos términos que creo que solo se usan en España.

<maav>luis-felipe: en la península yo conozco muchos idiomas... y mientras que bajando despeñaperros o cruzando parece otra cosa, todavía nos entendemos, cosa que no sucede con el resto de lenguas de la península realmente, por lo que yo entiendo que el sentido sería hacerlo para todo el mundo castellanohablante

<luis-felipe>vídeo y fichero, por ejemplo.

<maav>hmmm, vídeo es difícil, sí, porque video aquí suena mal también, claro... ¿conoces algún término que podamos usar a ambos lados del charco?

<luis-felipe>No :)

<luis-felipe>maav: Otra cosa que ya había visto, tal vez en el manual en español es el uso de nombres femininos como neutros: «Tiene nuestra bienvenida para unirse a nosotras»

<maav>luis-felipe: audiovisuales no suena perfecto, pero ¿podría valer? Sobre fichero... eso sí que no conozco

<maav>luis-felipe: el manual y la página web también, claro

<apteryx>civodul: it took one hour to generate a 'guix system vm' with the new glib change :-O

<luis-felipe>maav: En América generalmente se usa «archivo» en vez de «fichero».

<maav>perfecto, lo cambio también porque aquí se entiende exáctamente igual

<luis-felipe>maav: Y «computador/computadora» en vez de «ordenador».

<luis-felipe>Para este último he visto equipos de traducción que usan «equipo» para satisfacer a las dos partes.

<maav>luis-felipe: esa estaba pensando, jejeje

<maav>spanish overflow :)

<luis-felipe>No importa :)

<maav>luis-felipe: ¿"sistema de archivos" en vez de "sistema de ficheros" también?

<luis-felipe>Ah, otra cosa. La traducción de «Overview» en el menú del sitio como «Vista previa» no me suena natural.

<luis-felipe>maav: «sistema de archivos», sí.

<luis-felipe>Y por alguna razón, el enlace de «Vista previa» lleva a la página en inglés.

<maav>luis-felipe: tienes razón, mando ahora un correo a bug-guix (si puede ser a guix-patches con la corrección ya, pero primero actualizaciones)

<luis-felipe>maav: Yo traduciría «website» como «sitio web» y «web page» como «página web». Yo sé que la mayoría de hispanohablantes usan «página web» para referirse a «sitio web», pero técnicamente es incorrecto.

<abcdw>bye guix

<bjth>Hello! I have a small question. I am considering jumping ship from NixoS To Guix but there is something I am missing, or am probably just looking straight over. In Nix I can define the packages a user has in the config.nix but I don't see this option in Guix, is this right?

<civodul>maav: ¿quizás pudimos haber dos traducciones, en-es y en-am(?)?

<civodul>hi bjth!

<civodul>bjth: you can write a "manifest" for that and pass it to "guix package --manifest"

<civodul> https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html#index-profile-manifest

<maav>civodul: the only point that I have to think about is the translation (or not) for video (hehe), the other ones aren't even a problem for any spanish speaker, so i'd prefer to keep the translation understandable to anyone as far as possible

<Fenlair>In a freshly cloned guix repo I tried: guix environment --pure guix -> ./bootstrap -> ./configure --localstatedir=/var -> make and receivedthis resulted in error: tcc: unbound variable, hint: Did you ferget a `use-modules' form? I'm a bit lost now :/ I just wanted to try to build my package definition in the git repo instead of -L

<leoprikler>Is Guix' gettext built without XML support?

<leoprikler>[i.e. gnu-gettext, not gettext-minimal]

<lfam>That error is surprising to me Fenlair. What commit of Guix are you trying to build?

<Fenlair>i used 'git clone https://git.savannah.gnu.org/git/guix.git', let me quickly check

<lfam>Also, what is the result of `guix describe`?

<Fenlair>commit a5945a60cf7e0899447cabedf4ea5aff8ee8dff8

<Fenlair>guix describe: guix describe: error: failed to determine origin

<Fenlair>and I get a hint:

<Fenlair>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.1.0-30.875c01f.

<Fenlair>or should I do ./pre-inst-env guix describe?

<maav>leoprikler: what do you mean with xml support?

<leoprikler>nvm, it does appear to work for xml in general, but it barfs on this rather specific input

<maav>yup, its was implemented some time ago

<maav>you can output also xml, IIRC

<roptat>Fenlair, so you never ran "guix pull", right?

<leoprikler>okay, how do I add an xml tag as "keyword"

<Fenlair>I ran it quite a few times on my guix installation, but I don't think I ever ran it with the ./pre-inst-env guix

<maav>leoprikler: https://www.gnu.org/software/gettext/manual/html_node/Preparing-ITS-Rules.html this may be helpful

<Fenlair>I just ran a guix pull rn and I get the same error message on guix describe (which I never ran before)

<lfam>Fenlair: Alright, I'm going to try reproducing it

<lfam>You might also make sure you don't have any relevant variables being set in your ~/.bash_rc

<leoprikler>maav: and on the command line without modifying the file?

<Fenlair>I have GUIX_PROFILE="$HOME/.guix-profile"; . "$GUIX_PROFILE/etc/profile"; in my .zshrc

<maav>leoprikler: that doesn't modify the file but shows how to create an its description of the content that must be extracted, you can provide it with --its=

<Fenlair>but when I did the guix environment it loaded zsh without config

<Fenlair>After cloning the git repo I did: git fetch origin keyring:keyring, could that be the cause of the describe error: failed to determine origin?

<lfam>I don't think that's relevant

<Fenlair>I don't quite get how a source repo of git would mess with my guix installation :/ maybe my guix was always broken?

<lfam>It's not broken

<lfam>That error is expected with `pre-inst-env`

<lfam>We are debugging a compilation failure — I don't think anything is wrong with your installation

<Fenlair>oh, I thought the guix describe error was concerning :)

<vits-test>Fenlair: Maybe U did modified anything before ./bootstrap?

<Fenlair>I probably dropped my package file in there

<nixo_>Hi guix! I've a question on guix offload. I followed the guide here (https://guix.gnu.org/manual/en/html_node/Daemon-Offload-Setup.html) and it is working, but I get "The 'system' field is deprecated, please use 'systems' instead."

<nixo_>should the manual be updated?

<efraim>nixo_: https://guix.gnu.org/manual/devel/en/html_node/Daemon-Offload-Setup.html for the development version, not the 1.1.0 version

<vits-test>Fenlair: what is the latest hash of git log?

<lfam>Fenlair: What is the output of `which guix`, and then `realpath $(which guix)`?

<Fenlair>which guix: /home/pascal/.guix-profile/bin/guix

<Fenlair>realpath $(which guix): /gnu/store/qyjhy4bkz51jyspi63llfznsnz7vibzy-guix-1.1.0-30.875c01f/bin/guix

<lfam>Okay. I don't know if this is related to your original problem or not, but you should not install the Guix package

<Fenlair>I cloned the git repo fresh, did the guix environment --pure guix, ./bootstrap, ./configure --localstatedir=/var, make again and it seems to work now

<lfam>Okay good

<lfam>Still, you should remove the Guix package from your profile with `guix remove guix`, so that `which guix` shows '/home/pascal/.config/guix/current/bin/guix'

<nixo_>efraim: oh thanks

<Fenlair>I think I tried ./pre-inst-env guix build hello before I did the make, that might be a bad idea as well?

<Fenlair>guix remove guix on my regular guix installation? will that not kill itself?

<lfam>Nope :)

<lfam>The Guix package is special

<lfam>It gets "installed" and updated by `guix pull`

<lfam>It lives in its own profile at '/home/pascal/.config/guix/current'

<lfam>You can do the regular profile operations on it

<Fenlair>now which guix shows: /home/pascal/.config/guix/current/bin/guix :)

<Fenlair>lfam: thanks alot! :D

<lfam>For example, `guix package -p ~/.config/guix/current --list-generations`

<lfam>And all the rest

<lfam>You can switch generations, delete old ones, etc

<lfam>Delete all `guix pull` generations that are older than 6 weeks:

<lfam>guix package -p ~/.config/guix/current --delete-generations=6w

<lfam>For example

<Fenlair>so make in the git repo ran through and guix describe now works!!! :D

<Fenlair>but ./pre-inst-env guix build hello still fails :( no code for module (gcrypt hash)

<lfam>Are you within `guix environment --pure guix`?

<Fenlair>ah no I'm not :/

*vagrantc wishes environment too a profile argument

<vagrantc>took

<lfam>That should provide all the development dependencies of Guix, including (gcrypt hash) — aka guile-gcrypt

<lfam>Interesting, vagrantc. Can you give more details about your use case?

<vagrantc>lfam: when i build guix from source ... e.g. guix environment --pure guix ... ./bootstrap && ./configure ... && make ... i want to be able to have guix gc --delete keep track of old things

<vagrantc>lfam: i can use --root but then i have to manually remove the old ones

<vagrantc>i'd rather keep them in a profile and then do things like for p in $(guix package --list-profiles) ; do guix upgrade $p ; done

<vagrantc>i guess the dependencies of guix could change, but if they do, then guix environment --profile=profiles/guix-source should upgrade it like it would with a manifest or something

<bavier[m]1>'guix environment' registers a temporary root, so gc shouldn't collect those things. or do you mean something else?

<vagrantc>i want to be able to use "guix gc --delete-generations=8w" or such

<vagrantc>to remove the old crufty stuff

<vagrantc>but i don't want to have to run ./bootstrap && ./configure ... && make ... every time i want to work on packages ...

<vagrantc>but guix gc might delete the environment used ... this would give me some systematic way of tracking that environment

<vagrantc>otherwise next time i try to run make, the specific bash used might not be present

<vagrantc>and then i have to rebuild the whole of guix

<vagrantc>if there's an easier way to do this, i'm all ears :)

<bavier[m]1>right, and 'guix package -p foo -i ...' you'd have to know guix's dependencies.

<vagrantc>exactly

<bavier[m]1>hmmm

<vagrantc>or a way to have "guix environment --output-manifest guix | guix install --profile=profile/guix-source --manifest=-

<vagrantc>"

*vagrantc shrugs

<vagrantc>no huge deal, i can manage as is ... hurts a little more on the slower arm/aarch64 machines

<lfam>There's definitely room for improvement there

*nckx logs in to the official Guix tagline.

<nckx>Evening all.

<sneek>Welcome back nckx, you have 1 message!

<sneek>nckx, lfam says: Thanks for your help!

<bavier[m]1>yeah, we've learned a lot over the years about how we can interact with everything, and new advances change things sometimes too

<nckx>Er... did I help you? That is excellent. My pleasure.

<vagrantc>there's also the whole "guix environment --ad-hoc A B C" and the as-yet-unfinished "guix shell A B C"

<vagrantc>or did guix shell ever happen?

<bavier[m]1>first I've heard of it

<jonsger>lfam: if you only updated the kernel to 5.9.4 because 5.9.5 doesn't build, there is now a 5.9.6 release which does build :)

<nckx>vagrantc: What is ‘guix shell’?

<vagrantc>nckx: there was some discussion of such a feature on the list a while back

<nckx>I haven't had time to read as much list as I'd like... How does it differ from guix environment?

<nckx>(I guess that's my issue with it: it doesn't say what it does.)

<vagrantc>someone proposed to change the default behavior of "guix environment" to default to installing the listed packages, rather than the dependencies of listed packages ... but changing behavior is generally bad form

<vits-test>"shell" means sexp-hell, that is

<vagrantc>the other big plus with "guix shell" is it's considerably shorter :)

<lfam>nckx: Yes, with that viz1090 package. It's definitely not "ready for prime-time" but it's still pretty fun

<lfam>jonsger: I did 5.9.4 because, when I started working on it, that was the latest release

<nckx>Meh, we should just change ‘guix environment’ to be --ad-hoc by default (or at least add --for/--with synonyms) & let the gods sort it out.

<nckx>Unfortunately that'll probably never happen.

<lfam>jonsger: Now I'm waiting for linux-libre to finish their part of the update

<jonsger>lfam: ah, yes. There is another layer between us and the upstream vanilla kernel. forgot about that...

<lfam>So, we can expect 5.9.6 in Guix tomorrow, or maaaaybe late tonight NY time

<lfam>It takes me a few hours to do all the tests I like to do. I don't have a very fast computer for building the kernel

<lfam>I appreciate the attention :) Sometimes it gets lonely in kernel land

<nckx>lfam: Glad to hear you got it to run!

<lfam>Yeah, it runs! It's just a toy really. I found it in a list of "movie-style" aircraft tracking programs

<lfam>It would be nice to have a fully-featured graphical map-plotting tracker... but I don't know of any for GNU

<lfam>The dump1090 program does trivially pull the aircrafts' transponder signals out of the air and display the data, though. Magical

<nckx>Is this a hobby of yours?

<lfam>I have an rtl-sdr and I do spend too much time playing with it

<lfam>Radio is like the internet but cooler, IMO

<nckx>I get that.

<lfam>There's just all this... information, floating around! Invisibly!

<nckx>Getting something SDR-related would probably start me on a long & expensive new road, so I've been putting it off.

<lfam>The rtl-sdr devices are an incredible value. It would take a long time to outgrow them, I think. For receiving, at least

<lfam>Besides, it feels useful to keep of police and military aircraft in my city, these days

<nckx>M-hm.

<lfam>Never know when that info will come in handy

<lfam>I live in the same neighborhood that was bombed by our police in 1985. It wasn't that long ago

<civodul>maav: heh, is "vídeo" used consistently in all of Latin América?

<Fenlair>1985 not that long ago? D:

<nckx>Not long enough.

<lfam>The survivors still live here, and it's still obvious when you cross into the section that burned down

<lfam> https://en.wikipedia.org/wiki/1985_MOVE_bombing

<lfam>It was rebuilt quite poorly

<Fenlair>uff never heared of that before - that sounds horrible

<xelxebar>Regarding `guix shell`, that kind of alias would be nice. Seems like it might mean that we want a general command alias infrastracture, a la git config alias.

<lfam>Yes, it was horrible. I wish more people knew the story

<maav>civodul: in america they say "video", with the stress on the e, and here we say "vídeo", with the stress on the i... so I think i'll try "material audiovisual" instead...

<maav>hehehe

<civodul>heh :-)

<civodul>it's a fun game, finding phrases that avoid non-consensual words :-)

<nckx>xelxebar, vagrantc: So the difference would be something like: guix environment guix -- echo \$PATH → ‘$PATH’, guix shell guix -- echo \$PATH → ‘/gnu/store/...’?

<Fenlair>wow wouldn't have expected something like that in 'recent' times in America :/

<lfam>Learning about it completely changed my perspective on things, Fenlair

<vits-test>lfam: not that i understand those matters, but 500 policemens used 10000 bullets, then.. is that really at least partially true? against 8 adults?

<lfam>And they dropped a bomb from a helicopter, that burned down 65 homes

<vits-test>sound too "wikipedia about politics", are U sure it's true?

<lfam> https://www.mcall.com/resizer/cCnvUCsdDiTMfRpZwz8XkWX5BTk=/415x295/top/arc-anglerfish-arc2-prod-tronc.s3.amazonaws.com/public/M6SOHHL6GNB6BMLZAKYX6CXSUE.jpg

<lfam>Yes, it's true

<vits-test>wtf police has such bombs, heh.

<vits-test>feel myself idiot.

<xelxebar>nckx: Not sure I catch your drift. if you s/path/environment --ad-hoc/ in that command, the output is '$PATH'.

<lfam>The wikipedia article has a long list of references

<nckx>It's similar in Europe. People just collectively forgot that there were bombs in the streets (CCC/RAF) & the 1970/80s weren't some synthwave exception to the 20th century.

<nckx>xelxebar: I mean: where does the ‘shell’ come in.

<xelxebar>ugh. by 'path' I mean 'shell', of course.

<Fenlair>I think croatia was bombed in the 90s

<xelxebar>It's 6:30 am here

<nckx>I hardly if ever use ‘guix environment’ to launch a shell.

<nckx>So having to type ‘guix shell -- make foo’ is not intuitive.

<Fenlair>switzerland had bombs under a lot of bridges, so we could destroy them in case we would be invaded by germany and the last bombs were unarmed only a few years back

<lfam>Pick any news organization that covers the US, they will have published an article about it

<xelxebar>I use guix environment all the time to drop into shell that has the tools I need for some one-off task.

<Fenlair>just happy none of them ever detonated by accident

<lfam_>Similar all over the US, ncxk. It's rare that somebody of my generation knows how violent the 70s and 80s were here. Bombings are unheard of these days

<lfam_>We have to do everything we can to maintain this unprecedented period of peace

<nckx>xelxebar: Sure, but the emphasis is on the environment, not the tool you happen to spawn inside it. Anyway, if the logical name ‘guix environment’ is locked into backward-compatibility hell, whatever replaces it will be less intuitive by definition. Oh well.

<jlicht>We still have a live grenade being left in front of a coffee shop about once a year where I live, but that mayhem is pretty concentrated on one or two streets in the entire city

<xelxebar>nckx: I agree that a simple 'guix shell' alias seems heavy handed. However, having a general command alias mechanism might be useful?

<nckx>I've read up on the/a thread, and despite my distaste for abbreviations I prefer ‘guix env’. No ‘shell’.

<lfam_>Oof jlicht

<lfam_>That's scary

<nckx>xelxebar: Sure, if only because I think it's inevitable, people keep asking for it ☺

<lfam_>Can I ask which conflict that is?

<Fenlair>I coworker from turkey told me that bombings were a regular thing in his childhood - which would've been in the 90s I guess

<nckx>lfam_: Drugz. Not to one-up jlicht, but it happens in residential Antwerp neighbourhoods more than once a year. Being the largest port in Europe for specialty transport includes... a specific kind of specialty.

<lfam_>Right...

<xelxebar>nckx: Haha. I'm not entirely sure how useful it'd be though. At least, no option-heavy commands I have used have never really needed general use.

<xelxebar>Holy crap, "Police used more than ten thousand rounds of ammunition before Commissioner Sambor ordered that the compound be bombed." :(

<nckx>The current midnight curfew has had an unintended effect on granade attacks, so that's nice.

<lfam_>It's a sad story, xelxebar. The surviving participants were only released from prison this year

<lfam_>Now I sit here, waiting for the votes to be tallied. The struggle never ends

<jonsger>it gets a bit offtic now, I think...

<nckx>lol ‘now’.

<lfam_>Yes, it's totally off-topic

<xelxebar>lfam_: Yeah, how is this real, "No one from the city government was criminally charged in the attack. The only surviving adult MOVE member, Ramona Africa, was charged and convicted on charges of riot and conspiracy; she served seven years in prison."

<lfam_>Well... it goes part of the way to explaining the marches this past spring

<xelxebar>Anyway. Stay safe all of you in the states!

<lfam_>Thanks xelxebar. Pray for us, if you do that

<xelxebar>So, guix output hashes are computed from the inputs, meaning that even for non-material changes like code comments, guix believes treats the outputs as completely different. It'd be cool if hashes could be computed from the *outputs*. I'm positive this idea has been around for a while, but I haven't found the right keywords to point me to existing discussions. Anyone know if anything like this is on

<xelxebar>the mailing list?

<civodul>xelxebar: yes this idea appears in the PhD thesis on Nix of Eelco Dolstra

<civodul>some are enthusiastic but it's tricky

<xelxebar>Oh! Right back to the source. I'd like to read about some of this trickiness. Is Dolstra's thesis a good place to start?

<xelxebar>If the ideas have progresses much, I'd love to dive into the progressions as well.

<civodul>yes i think it's a good place to start reading about this

<civodul>the Nix folks are working towards enabling it, or rather a mixture of both models IIRC

<civodul>well Nix and Guix both already use a mixture of both models in fact, but they want to push it further

<vagrantc>it'd be interesting to apply reproducible builds to that to see if you get identical results

<civodul>that's one of the practical issues: for those packages that are not reproducible, you'd have problems

<vagrantc>making what should be no-difference changes to the source(stripping commentS), and seeing if it did, in fact, not change anything

<vagrantc>right, while reproducibility state-of-the-art is still impressive, it's far from 100%

<xelxebar>^ This is exactly what I am wanting to do for a partilar package right now.

<vagrantc>civodul: though maybe you only do such transformations on packages that are known and periodically tested for reproducibility

<vagrantc>though i would guess it's pretty rare to see comment-only changes

<vagrantc>or other things that should be so completely trivial

<xelxebar>The particular changes I'm making are to a build system, and I want to know that these changes make zero difference in the outputs.

<civodul>yes, this is a use case where that model is particularly useful

<civodul>you could also achieve that by, say, calling remove-store-references on all the files and compare the result in both cases (with and without the change you're testing)

<civodul>obviously it's a trick that only works for comparison purposes

<civodul>actually we could provide a "guix diff" tool that does that for you

<xelxebar>civodul: Oh. Nice. I had just been manually tarring (with appropriate reproducibility options) the results and comparing hashes. Didn't know about remove-store-references.

<civodul>remove-store-references is necessary if your build output embeds store file names, which is usually the case

<xelxebar>Yeah, I did try simply using guix hash, but quickly noticed the problem.

<xelxebar>Dang. The Dolstra thesis is 281 pages. This will be something nice to sit down with!

<lfam_>xelxebar: I think the key words are "intrinsic" and "extrinsic"

<nckx>‘intensional’ and ‘extensional’.

<xelxebar>Beautiful. That's exactly the kind of keyword pair I was looking for. Cheers.

<lfam_>Right, I knew it sounded off to me

<xelxebar>There we go. Sections 5 and 6.

<nckx>Some hubs for explorin': https://github.com/NixOS/rfcs/pull/17 https://github.com/NixOS/nix/issues/296

<vagrantc>civodul: likely to tag any release candidates before the release?

<civodul>vagrantc: good point: yes, let's do that nicely this time :-)

*civodul -> zZz

<civodul>night/afternoon!

IRC channel logs

2020-11-05.log