<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. ***Xenguy_ is now known as Xenguy
<nckx>You'll have to file a bug with one of the third party channels that needs to be updated. In this case, the one on line 13. <reily>The guix-gaming-games channel? I dont actually currently use anything from that channel, let me test removing it. <nckx>It has two references to libpng-1.2. <nckx>There may be others in other channels, I didn't check. The only one I use myself is flat. <reily>Perfect, sorry for the false alarm. Just for reference, did you find that by searching the channel, or was there some indication in the error message that I missed? <nckx>No, unfortunately I just checked out random eebil repos (to tmpfs, so it doesn't count!) and got lucky with the first one. <nckx>IWBN if that were part of the error message! Feel free to file a bug in general terms. <reily>Yeah, even just having a file name would be nice. *nckx nods. I thought I'd seen that happen once, but who knows. <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. <nckx>But who the hell is sending bogus NXDOMAINs in the first place? <nckx>Is this due to ‘search’? <apteryx>breakpoint() in Python + ipdb is quite the debugger's Cadillac; when in Guile? <apteryx>dominicm: thanks! I'll take anything, starting from zero :-) <apteryx>but gmail will require two factor authentication (OAuth) from tomorrow if I understand tomorrow, breaking most setups (I'm currently using Gnus as a client) <apteryx>perhaps OAuth is doable, but I'm clueless here <apteryx>GNUtoo: I'm porting h-client to Python 3, seems doable so far <apteryx>in both the python 2 and python 3 (newly ported) versions though, pressing "Submit" ends with a "wrong request" text printed in the GUI <apteryx>and my change doesn't seem to be written to the h-node.org database <apteryx>eh, the result from the query is: "<?xml version='1.0' encoding='UTF-8'?>\n<user_info>\n\t<status>error</status>\n\t<notice>\n\t\t<![CDATA[]]>\n\t</notice>\n</user_info>\n\n", i.e. 'error' <iyzsong-w>emacsomancer: it won't work in guix system, which use 'shepherd' as the init. <iyzsong-w>add a service to run '/etc/rc.local' should work though. <emacsomancer[m]>iyzsong-w: thought as much. is there a good example of setting up a shepherd service to run `/etc/rc.local` ? <iyzsong-w>maybe replace (start ...) with (start #~(lambda _ (invoke "/etc/rc.local"))) in 'iptables-shepherd-service', just seems reasonable to me.. <avalenn>What is the way to add tags to bugs in debbugs? I would like to have a way to find easily all bugs related to Go ecosystem. <florhizome[m]>Is there an explanation what the different sockets that shepherd offers mean? <tinybronca[m]>Can anyone explain what the purpose of "impure derivations" are for? <jpoiret>tinybronca[m]: looks like impure derivations are just packagers getting fed up with language pms and reverting back to "traditional" packaging methods <jpoiret>about the gui, guix doesn't have something like this, and it'd be a bit harder to code up since guix is configured in Guile, not a constrained DSL like in Nix <jpoiret>you could just invent a simple DSL that'd work for most end-users and interface it with guile though <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.) " <tinybronca[m]>Files being ordered differently when tarballs being generated on the fly? Does this happen in Guix?? <civodul>tinybronca[m]: hi! there's a policy to not refer to generated tarballs in Guix <sneek>Welcome back civodul, you have 1 message! <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 <civodul>"manually-produced" tarballs are fine <civodul>well, not ideal either, but that's a different problem <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>that too may be an observable difference <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? <nckx>civodul: <strictly speaking> Eek, you've got to clear such things with legal first 😉 <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? <vagrantc>usually i would guess they'd CC the submitter on any replies, though <KarlJoad>vagrantc: Ok. I am more used to the issues interface, but the reply email I got points me to the debbugs page. <vagrantc>issues.guix.gnu.org is essentially an alternate frontend to debbugs.gnu.org (technical details may call it something else, but from a use perspective, that seems close enough) <KarlJoad>Yep. Just wasn't sure about the debbugs interface being up-to-date with the status of my patch. <nckx>If there is a delay it's not significant. <nckx>And, IME, related to the overview (front page) — that is, a new bug won't immediately show up in the list but you can manually browse to issues.guix.gnu.org/NNN and there it is. <civodul>mjw: hi! yeah, it was an experiment, and one that didn't quite work i suppose, but we should check with cbaines <cbaines>civodul, I think that patchwork instance was setup quite a bit prior to when I started looking at patchwork <mjw>civodul, so OK if I remove it? Do you maybe want it back later? <mjw>Why didn't it work out? <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. <cbaines>including using checks to show when applying the patch worked or didn't work <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 overseers@sourceware.org) if you need/want it. <mjw>But that is currently disconnected from the patchwork instance <mjw>that is what I want to work on <cbaines>interesting, I've heard of buildbot, but I've never actually tried to use it <vagrantc>can i assume that "true" will be in path during a typical guix build ? <nckx>But only for typical values of typical. <vagrantc>tempted to replace a call to date in keyutils with ... true ... as embedding SOURCE_DATE_EPOCH=0 isn't going to be all that informative <vagrantc>presuming an empty value doesn't explode... <nckx>Sure. BOGUS_COMMAND=true is quite conventional in Guix, despite its potential confusingality. <vagrantc>heh. it's plausible that replacing it with a command that doesn't exist might effectively have the same effect <nckx>But plenty of stuff embeds 1970 too. <vagrantc>honestly, i think guix would be better off embedding guix's first commit date ... some things react badly to such ancient dates <nckx>You can even replace it with ‘echo REDACTED FOR REPRODUCIBILITY’ :) <apteryx>yeah; could be better to embed epoch 0 in case things depend on a string being present <nckx>(Yes, in seriousness I agree: unless it's the --help output or something else that should never be parsed, keep something date-looking.) <nckx>vagrantc: I (and I was certainly not the first) suggested using the newest time stamp in the package's own source archive for that purpose once. Same idea. *vagrantc is going to tow the official party line that there's no timestamp like no timestamp (when possible) <nckx>Those queer Debianites and their exotic ways. <vagrantc>the official reproducible-builds.org stance, that is <vagrantc>and this, me declaring to focus my reproducible builds efforts on guix this month, this is how i'm repaid! :P <vagrantc>i suspect there's something fishy with compressed modules in linux-libre ... going to try builds without compressed modules <nckx>vagrantc: How bad is it to make you feel compelled to help out? ☺ I seem to have misplaced the Guix Data Service link again. <vagrantc>it's not horrible, but some of them are things that have known fixes in debian <nckx>I swear I bookmark it ever so often but Firefox loses bookmarx somehow :-/ <vagrantc>i always get to it by following reproducible-builds.org -> continuous tests -> gnu guix <vagrantc>nckx: though it's about as bad as debian's unstable suite, where things are intentionally varied that shouldn't affect guix (e.g. normalized build path in guix's build environment) <nckx>unmatched-paren: …you have nothing to lose but your links! <nckx>vagrantc: And something like disorderfs I presume? <vagrantc>it should be at least as good as debian's testing suite ... ~95% <nckx>And if so, any idea if it slows down builds significantly? <vagrantc>i forget if disorderfs is in play ... we've had problems with it at various points <vagrantc>but since guix normalizes many things ... ought to get better numbers! <nckx>Yes you have the kindest way of saying our numbers are misleadingly inflated. :) <vagrantc>well, normalized build environments are a good thing ... it's not as much of a stress test, but that's fine :) <cbaines>there's good normalisation, and there's the lack of rigorousness of the testing approach <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>vagrantc: You need to build before you can --check? <nckx>(You didn't mention --check, buut…) <nckx>vagrantc: There's no reason that error couldn't just say that, instead of… that. I'll get me editor. <vagrantc>had assumed check would build it if it wasn't already built <vagrantc>does --check populate the local database such that guix challenge will work? <nckx>vagrantc: I hope I've clarified the error somewhat. <nckx>Not sure I understand. Doesn't ‘build’ do that? <vagrantc>guix build will usually download from the substitute server, and leave nothing to actually guix challenge <vagrantc>and i haven't had great luck with --check doing much better <vagrantc>it seems to perform a build and throw away the results <nckx>--check will never substitute. <vagrantc>.... guix build somepackage && guix build --check somepackage && guix challenge somepackage ... more or less results in "no local build" <vagrantc>how do i guix challenge something i've already downloaded? <nckx>--check --keep-failed (I think) will keep the mismatched local build at different location. <nckx>vagrantc: <how do i guix challenge something i've already downloaded?> If --check returns an identical build there's nothing to challenge with. <vagrantc>hrm. issue wasn't just module compression in linux-libre ... there's something deeper going on :/ <nckx>What's the issue exactly? <vagrantc>kernel modules have something different in them between builds <vagrantc>the diffoscope output isn't particularly large per module, but it's not particularly enlightening either <vagrantc>how do i manually download and unpack nar archives? ... i'd like to be able to diffoscope individual files on two builds of a package <vagrantc>oh, it's not just the modules, but bzimage and system.map too <vagrantc>hrm. i may have found bugs in diffoscope, even more fun! <nckx>You cat manually download /nar/lzip/<output hash>-<name+version> | guix archive --extract=DIRECTORY I guess. <nckx>Be sure to sudo curl of course. *vagrantc puts on the experimentation goggles <nckx>Have you tried out difftastic by any chance? <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 :) <vagrantc>Resource not found: /nar/lzip/wxvzlvnysb4jyd9r0y8ijqdjm359ya8-linux-libre-5.17.12 <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. <nckx>I tried x86_64-linux and aarch64-linux because it's you, but neither match. *nckx ruined unmatched-paren's colon. <vagrantc>nckx: oh, dervation rather than output ... ok <vagrantc>/gnu/store/2wxvzlvnysb4jyd9r0y8ijqdjm359ya8-linux-libre-5.17.12 <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. <unmatched-paren>* atomic updates; you *mostly* don't have to worry about things breaking on e.g. a sudden power outage <nckx>vagrantc: Because the /gnu/store/wxvzlvnysb4jyd9r0y8ijqdjm359ya8-linux-libre-5.17.12 you posted above simply doesn't exist. <nckx>So your guix weather command is checking for… something else. <nckx>s/exist/exist on berlin/. <unmatched-paren>* declarative configurations, so your packages/services/dotfiles are all listed in the same place <nckx>vagrantc: You forgot the 2… <unmatched-paren>* temporary `guix shell`s where you have certain packages available inside the shell, but not out of it <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]’. <bingulo>jackhill: My choice to try a source based distro is to learn how GNU/Linux works, as well as gain more control about what I'm installing in my system <unmatched-paren>bingulo: guix will DEFINITELY help with the latter :) as long as you use the declarative package management system <unmatched-paren>for the former... well, you wouldn't really be learning a traditional Linux system... <bingulo>rekado: I admin void linux servers, and would consider using guix on it if I like it, as I apreciate a lot the replicability of guix, instead of some bloated technologies like docker <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 <bingulo>rekado: Of course I am not in the level to implement it, but I always consider it as workaround, I always try to be purist <unmatched-paren>as long as this repo exists, i can replicate my entire system config and most of my $HOME <unmatched-paren>i think there's also a `guix pack` command that lets you export configurations in guix to e.g. Docker images, self-contained tarballs, etc <bingulo>unmatched-paren: I can install guix package manager in any distro to allow these deploys, can't? <unmatched-paren>but guix on a foreign distro isn't quite as powerful (though it's still worthwhile): you can't declaratively configure the system itself or roll-back from GRUB <bingulo>so i think that my points are reducted to choose a traditional system vs. choose a potentially innovative system to learn <jonsger[m]>can cargo-inputs and cargo-development-inputs be already style with the new gexp input style? <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? *attila_lendvai notes that his issue is not guix related <vagrantc>does guix support pre-shared keys? (would hope so, but ... maybe it is missing?) <vagrantc>hrm, to fix a bug in diffoscope, i have to rebuild off of ghc and numerous other expensive things :( <vagrantc>i guess i could parse the output of python3 --version ... and mangle to drop the later parts (e.g. 3.9.9 mangled to 3.9) but no idea if that is even correct <apteryx>vagrantc: site-packages from (guix build python-build-system) <apteryx>which should already be in scope if diffoscope uses the python build system <vagrantc>git grep is pretty much my primary mode of "understanding" guix packaging :) <ham5urg>I just discovered Guix. I was waiting for its concept for years, if not decades. Is it possible to install the whole system (kernel, userland etc. like a debootstrap) with guix? <unmatched-paren>if you're talking about building entirely from source: you can do that, too <ham5urg>unmatched-paren, thanks for the info. Are source code installations similar to Gentoo? <unmatched-paren>it's actually _more_ from source than gentoo, since guix currently has the smallest bootstrap seed out of any distro i know... <ham5urg>The concept of 'profiles' is new to me. Does it mean that every user (which can login) can install software from the repository into its profile (it's home directory)? <ham5urg>unmatched-paren, which profile is used to install the bootloader, kernel, userland, etc.? <jackhill>civodul: thanks for reviewing pushing the profanity patches! *unmatched-paren away, bye \o *vagrantc squints at: building /gnu/store/lp5df665r6xkq97s8asm8h0ypr2yawr5-gcc-10.3.0.drv... <ham5urg>Should an http server be installed within root's profile or within a users one? <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. <ham5urg>guix environment --ad-hoc guile -- guile <ham5urg>would install guile as a system wide 'package'? <KarlJoad>Not quite. guix environment will spawn a shell/run a command inside a profile that only exists for the duration of the guix-environment call. <KarlJoad>BTW, guix environment --ad-hoc was "deprecated" in favor of guix shell, I think. <KarlJoad>Though the profile used for the environment will continue to exist until a GC event, I think. <KarlJoad>Apparently my Cuirass instance does not like my "guix deploy" systems. Is that expected? It gets hung up when evaluating the machine list. <zimoun>how people are managing their GPG thing for signing on several machines? <ham5urg>Will my-hello.scm be copied inside guix directories for documenting purposes (e.g. to understand what has be done to a package) after 'guix package --install-from-file=my-hello.scm'