<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?
<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.
<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.
<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 firstname.lastname@example.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.
<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.
<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
<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.
<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...
<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!
<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
<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?
<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>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.
<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(?)?
<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
<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
<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’.
<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.
<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