<reily>Hello, after the recent commit(s) removing many python2 packages, guix pull fails during pacakge cache building. Is this something other people are experiencing, or is this only an issue on my machine?
<nckx>reily: I was actually expecting it to fail here, but it didn't.
<nckx>(There still are some python2- left-overs in Guix, but they didn't break pull.)
<nckx>reily: You could try removing ~/.cache/guix.
<nckx>reily: If that doesn't help, please share the entire output on paste.debian.net.
<apteryx>my gmail access officially stops working tonight (outside a browser); time to up my game any email configs out there?
<FriendFX>Hi all, I just installed GuixSD and GNU IceCat. The latter seems to have problems resolving any host names, while I can resolve them fine in a terminal (e.g. via ping). Any ideas how to debug/resolve this problem?
<iyzsong-w>FriendFX: maybe 'herd restart nscd', or disable https dns in icecat if there is such a thing (i don't know about this..)
<FriendFX>iyzsong-w: `sudo herd restart nscd` and re-starting IceCat worked for me. What's the nscd (noob here)?
<iyzsong-w>when resolve dns, nscd's cache is quered first, it can have negative cache (NXDOMAIN) which leads 'no such host'. nscd is a part of glibc, and used in guix system to eliminates binary incompatibility between different glibc versions.
<jpoiret>🤡 "Emacs: Make Guix System usable for non-technical users through a settings / package management GUI."
<jpoiret>said GUI originated before GUIs even existed
<tinybronca[m]>"A motivating example for impure derivations is the problem of using fetchurl on a dynamically generated tarball whose contents are deterministic, but where the tarball does not have a canonical form. Previously, this required fetchurl to do the unpacking in the same derivation. (That's what fetchzip does.) "
<sneek>civodul, apteryx says: by the way, if you apply https://paste.debian.net/1242590/ on top of the patch fixing the jami test, you'll see the test failing, which suggests something is not right with either Shepherd or Jami (haven't investigated)
<civodul>apteryx: dunno, but the 'stop' method definitely shouldn't call waitpid; that's taken care of by shepherd
<tinybronca[m]><civodul> "tinybronca: hi! there's a policy..." <- Hmmm by "generated tarballs" you mean "on the fly" or something? I mean doesn't every tarball need to be "generated" once to archive it up?
<tinybronca[m]>What is the problem with on the fly archival that makes it impossible to do this reproducably or something
<civodul>tinybronca[m]: by "generated tarball", i meant those that are generated on the fly by github.com and similar services
<jpoiret>jonsger[m]: can't you just put the (let ...) directly in the inputs?
<jonsger[m]>maybe, never mind thats for another day/mont/year :)
<patched[m]>Is there a gexp for the home directory, for usage in guix home?
<patched[m]>Or just, something to get the home directory. Need to mkdir there
<apteryx>civodul: OK; I guess perhaps a deadlock remains in Jami on exit with a simple SIGTERM in our current version that require SIGKILL I hear things have improved in recent versions, so we may be able to drop that in the future.
<civodul>apteryx: BTW, note that make-kill-destructor terminates the process group, not just the main process whose PID is the "running" value of the service
<civodul>patched[m]: hi! perhaps you can extend home-files-service-type, which will take care of mkdir, symlink, etc. for you?
<civodul>tinybronca[m]: not ideal in the sense that, strictly speaking, tarballs are byproducts rather than "source" (they're the result of a computational process)
<civodul>jonsger[m]: you could move the origin from inputs straight into the phase that needs it
<dominicm>apteryx: Wait is it really only OAuth2.0? From my understanding you just have to use app passwords; they just aren't allowing logins with your google account passwords anymore. So anything that accepts an IMAP/SMTP setup should still work.
<apteryx>dominicm: ah! that would explain why Gnus is still able to fetch from Gmail today
<ennoausberlin>Hi. I created a docker image from within Guix SD. I can load and run it. But how can I use the network from within docker?
<mjw>I assume that has been dead and unused for 6 years?
<patched[m]><civodul> "patched: hi! perhaps you can..." <- Hmm, is there anything like this for `git clone x; cd x; stow *`?
<patched[m]>Idk if I'm going about it the wrong way, but I'm looking for some general way to execute certain commands the first time the home system is created. Playing around with home-activation-service, but that will run on each reconfiguration if I understand it correctly
<KarlJoad>Is there any way to see if a patch I have submitted has been reviewed yet?
<mjw>So the reason I want to upgrade it is that the glibc people have a cute trybot thing that can pickup patches from patchwork run it and set a flag on the entry so you can immediately see if the patch applies, it compiles and the tests still pass.
<mjw>cbaines, do you have your setup documented somewhere or in some source repo?
<cbaines>sort of, but it's pretty messy and the repo isn't public (as it's currently in my personal machine config repo)
<mjw>cbaines, and do you want/need an instance on patchwork.sourceware.org? I don't want to remove it if you feel it might still have value.
<cbaines>mjw, I'd remove it for now, it might be nice at some point to have a shared "CI" system for several GNU projects, sharing a patchwork instance and build resources, but first I'm just focusing on trying to get something useful setup for Guix
<mjw>cbaines, of course, please feel free to ping me (or sent email to firstname.lastname@example.org) if you need/want it.
<vagrantc>any idea why this refuses to build? leaving me with an error ... guix build: error: some outputs of `/gnu/store/8x56wb84alfjli0qy6cm4advl06375c9-isl-0.23.drv' are not valid, so checking is not possiblehttps://paste.debian.net/1242718/
<nckx>It's in guixrus. I've installed it but not run it yet.
<bingulo>Hi everyone, I will try to start using some source based distro, and guixSD shown to be a good candidate. I'm choosing between guixsd and gentoo. I'm personally adept of simplicity, and guixsd seems to be a lot complex, but I liked the distro concepts. Also, I see that guixSD is far away from a tradicional GNU/Linux distro, Is the learning curve too sharp? Should I consider try guixSD?
<vagrantc>bingulo: you're asking a biased sample :)
<vagrantc>bingulo: but i would definitely say it is quite different and there's a lot to wrap one's head around :)
<bingulo>vagrantc: yeah, I know, but I'll apreciate to hear guix users. Maybe I get some reasons to try it
<vagrantc>bingulo: if you like something with a strong commitment to free software and scheme/lisp/guile, you're definitely in the right place
<vagrantc>guix does tend to be a bit expensive on disk space ... tends to rebuild things more often than some people might expect (e.g. any time a package changes, anything that's built using that package is essentially rebuilt)
<unmatched-paren>bingulo: Guix also has (optional) support for loading binaries from servers though, something which i think gentoo doesn't have?
<bingulo>bingulo: I'm a free software entusiast, but my unique contact with lisp was emacs configuration, I have to learn some lisp to use guix, of course
<rekado>bingulo: I don’t think Guix System (we don’t use the old name “GuixSD” any more) has too much of a learning curve. It’s very different, but everything is configured through just one config file, and all that is documented.
<unmatched-paren>bingulo: scheme is somewhat different from elisp, but it should feel familiar. just be aware that there are differences that may trip you up
<rekado>there are never enough examples, and it’s rough if you don’t feel like picking up some Scheme on the way.
<rekado>I do agree with your impression that Guix is complex, though.
<jackhill>bingulo: I think Guix and Gentoo have different goals. There must be more to the story about your desire for a source-based distro. Can you say more about that? It's been a while since I've used Gentoo, but Gentoo you'll get to/have to make a lot of decsions about how you want to configure your system. I think as their saying goes, it's a meta-distribution as it it is the building blocks for creatign any
<jackhill>number of actual distros. Guix has more of a single configuration out of the box, but with some of the unique features that make replacing your decisions for ours easy and pleasurable.
<unmatched-paren>bingulo: also, my advice to you: use Guix Home manifests *from the start*.
<nckx>vagrantc: I can't find the derivation matching that store output. How did you get it, and how did you check the weather for it?
<rekado>the basic idea is pretty simple, but the implementation is not trivial and it comes with tradeoffs that other distros and package managers don’t need to worry about.
<vagrantc>guix build from 16a0aea02deacd9872490f9328474a442a85380d
<rekado>bingulo: long ago I learned how to administer RHEL systems. After having used Guix System I’m unlikely to ever return to traditional distros. I no longer worry about system state, and I no longer fear upgrades.
<bingulo>unmatched-paren: I don't know a lot of gentoo, my first choose point is that gentoo is traditional and guix not. About scheme, I think that I will like to spend time learning it, so It isn't a bad aspect
<nckx>I'm afraid can't join the sales meeting right now, but you can add me to the sample size of ‘people who used Gentoo for years and now use Guix [for many more]’.
<rekado>probably the biggest downside of using Guix System is that you need to be prepared for when things aren’t supported/implemented. What’s your strategy to work around a missing feature? Implement it? Use a Debian VM? Use Docker…?
<bingulo>unmatched-paren: yeah, I see guix to be much distant of any other traditional system, maybe I consider that point for the former motivation
<jackhill>last commit almost a year ago though … 🤔
<unmatched-paren>jackhill: as a stranger to python: why do people want to keep an obsolete version so badly that they fork the python interpreter?
<unmatched-paren>except for backwards compatibility reasons, of course, but in that case it surely would be far less work to just update their projects...
<civodul>unmatched-paren: to scientists who don't consider themselves developers, it's just a tool
<civodul>and some view(ed) Python 2 EOL as an opportunity: it meant Python 2 as a language could be frozen forever
<civodul>so that their code would never need to be updated
<jackhill>unmatched-paren: well, I guess it's varied. Sometimes the software I'm concerned about isn't really "my" project unless I get involved, and I can't get involved in every project. And touthon isn't really "my" project either, so I can't speak for them, but looking at their description of having backported some of the compaitble new ideas from python3, I can see it being intellectually stimulating to work
<jackhill>through an alternate python history without the flag day.
<lilyp>tbf PEP 517 makes tauthon a whole lot more attractive
<attila_lendvai>i'm struggling with a wireguard vpn (first time i'm using it). my server is an openwrt, and i think it's set up. my first client is a guix, where i have a wireguard-peer entry, and reconfigure works, but the vpn doesn't. i guess i need to specify the preshared-key that i see on my server... but there's no such field for wireguard-peer. what am i missing?
<ham5urg>Ahh, I first thought everything is going via profiles.
<jackhill>well, technically behind the cutain a profile might be created for the service, but Guix takes care of that, so you don't have to worry about it.
<jackhill>ham5urg: also, note that this means some tools that you might usually expect to be availalbe, like htpasswd for apache don't nessisarily end up in PATH. If you need stuff like that, I'd tend to install it in a user's profile.
<jackhill>Also, note, that, on Guix System, root is like any other user, and can manage it's own profiles. There also a system profile which has the "globally" installed stuff. It's what's under /run/current-system and will have things like the setuid binary, etc.