<benny>I installed a packge with guix package -i, and then I uninstalled it with -r but it's still in my path. even after a reboot. I checked if it's in the system's config.scm but it's also not there. How would I find out why this is ?
<lfam>benny: Do you see the package in `guix package --list-installed`?
<xelxebar>Just installed vim and it's complaining that I need to relink libpng and libfreetype with libpthread
<xelxebar>There's an email thread where someone was seeing the same problem, but for them a guix pull && guix package -u got rid of the error.
<xelxebar>That's not working on my end. Is it likely that some grafting operation screwed up some libraries?
<xelxebar>Actually, how do I find out exactly which commit my guix-latest is at?
<bavier1> xelxebar: 'guix --version' should show the commit if you've done a 'guix pull'
<xelxebar>bavier1: Thanks. That's an obvious one :P
<Guest85319>That's strange, I've just "guix reconfigured" my openssh service from port 2222 to port 22, but it still seems to be running on 2222. I've tried "herd stopping/starting" it which work, but doesn't change the port.
<rekado_>Guest85319: you need to stop ssh-daemon and then reconfigure.
<rekado_>it’s a known missing feature of the shepherd.
<boskovits>I'm now at the Reproducible Build Summit, and I would like to package python-networkx, so that we can have better understanding of our dependency graphs.
<boskovits>I got some strange error from python-build-system, in phase 'reset-gzip-timestamps' I got In unknown file: 0 (open "/gnu/store/vl8wngq035vkk9s5y2apvkgyss397624-pyt…" …) ERROR: In procedure open: ERROR: In procedure open-fdes: Permission denied
<boskovits>I can build with this phase disabled, but the result is not reproducible.
<boskovits>I also have a .lock in the store with the output name.
<ng0>hey… I have an application that is using pkg-config to check for gst-plugins-good, in a way which obviously requires gst-plugins-good to have the gst-plugins-good-1.0.pc file in the pkg-config path. However this does not exist (neither for -good nor for -ugly (or was it -bad?)), and the source of gst-plugins-good only includes a "pkgconfig/gstreamer-plugins-good-uninstalled.pc.in" … I'm irritated by
<ng0>"uninstalled". The software in question is a gstreamer project aswell (gnonlin). Is it established in operating systems just to pass the path by hand? I looked at Gentoo and Nix, they don't change a thing for gnonlin.
<ng0>I could send a patch upstream, but maybe you have a better idea.
<brendyn>for me the process is called /gnu/store/sq118zpg6kzqwjsldbspjkwn0cfl8rp3-emacs-25.3/bin/emacs-25.3 but killall /gnu/store/sq118zpg6kzqwjsldbspjkwn0cfl8rp3-emacs-25.3/bin/emacs-25.3 doesn't work either
<efraim>Tar's test suite has timed out for me before
<cehteh>long time ago i suggested that we should add some option to skip tests on packages, sometimes its really not bearable
<efraim>'Make an 8 GB sparse file and destroy it' took too long on my SD card
<cehteh>option as in per user, and maybe tag the generated binary package as 'untested'
<cehteh>one doesnt want to serve untested to the world, but for locally build --fallback and private packages it should be a choice for the user to prefer speed over safety
<TeMPOraL>hi there; I'm testing Guix/GuixSD for the first time, and installing _everything_ takes hours; could anyone help me figure out what am I doing wrong?
<TeMPOraL>sorry, s/everything/anything/, e.g. "guix package -i htop" is downloading and installing stuff for the past hour, pausing in between each download for a minute or more
<ng0>Guix or GuixSD? There is a difference, but you could be lacking the binary substitutes for the package receipes you have locally as 0.13 is old (a new release is due), so if you already have guix running you should issue 'guix pull'
<mb[m]1>TeMPOraL: are you within the live USB environment?
<TeMPOraL>mb[m]1: no, I installed GuixSD on a spare computer, but the same thing happened during installation; it took ~8 hours to finish
<ng0>htgoebel: I found an official explanation for my problem
<TeMPOraL>the biggest pauses are on "Downloading https://mirror.hydra.gnu.org/....."; it hangs on it for a minute or more, and after that it does the next step (actual installation?) in few seconds, and hangs again on the next "Downloading...." message
<ng0>a good while back gstreamer used to include .pc files for some complicated mix of it, so they dropped it recently
<ng0>gstreamer-plugins-* that is. I think I need to tell gnonlin about this
<ng0>one should assume internal communication works better, but sometimes it doesn't.
<mb[m]1>TeMPOraL: Did you run `guix pull` after installation?
<rekado_>TeMPOraL: is it compiling things from source or just downloading stuff?
<lfam>cehteh: But, it's not so simple, IMO. The effect would be that every package with a test suite would have two different "final" derivations, because we can't be sure the tests don't effect the result of the build
<lfam>Idk, maybe I'm overthinking it. We've been bitten hard by failing test suites for core packages in the past
<cehteh>that could be checked/challenged, but having 2 final derivations would be fine, if not even intended, just keep the non.tested one private
<jlicht>lfam: you could keep the untested one private
<lfam>Would one expect substitutes for the untested package?
<rekado_>we wouldn’t force each GCC compilation to go through this, but it’s a package that could be built on powerful hardware as a sanity check.
<cehteh>some 'net of trust' with anyone can contribute a build farm and some trust/voting system about propagating binaries would be nice eventually, but i guess the project doesnt have the developer resources now to put that on priority, maybe someday
<rekado_>cehteh: we already have “guix challenge” and “guix publish”
<rekado_>users can share their store via “guix publish” and other people can download packages from them, or simply compare results with “guix challenge”
<cehteh>yes, i meant in an automated way, that needs more infrastructure
<lfam>cehteh: The issue would be that anything depending on that "no tests" package would have a different dependency graph, meaning you'd compile the whole thing
<lfam>So I think that, in practice, it would usually be slower
<cehteh>even if i publish my farm, no one going to use it unless he explicitly adds trust and my host
<lfam>The Nix suggestion was not really about speed but reliability
<bavier>many packages don't have tests that can easily be run against already-installed artifacts
<rekado_>lfam: not if we were to default to building the “no tests” package
<lfam>rekado_: Right, but then we'd basically double our list of builds :)
<rekado_>the build farm would build the “no tests” variant first, then “continue” the build by just running the tests on it.
<bavier>oh, but if the tested packages for a separated package graph, that wouldn't be an issue I guess
<rekado_>the “with tests” variant is a continuation, not a completely separate build.
<rekado_>we’d have to monitor the list of “with tests” variants that fail.
<rekado_>build continuations are also relevant for grafts.
<jlicht>rekado_: is that a problem? Could we not just tag these builds as being "private", and not count them for these purposes?
<rekado_>what I mean is that we would attempt to build more things, even though the “with tests” variant of one of the dependencies had failed.
<cehteh>build package, run tests, if successful build package again, check that we got the same package twice, the first package might be installed locally, but never ever published, and taint any package which depend on it as private as well
<rekado_>I guess we could deny users the download for packages like this, but it’s something that has to be thought through.
<cehteh>the 'with test' variant should still be the norm, the 'without-test' is the exception
<rekado_>cehteh: this would make each build more expensive.
<rekado_>or do you mean we build twice out of band?
<rekado_>that would be the same as having two separate derivations.
<cehteh>make; 'generate guix package (thats essentially a make install)'; if make test; then generate guix package again;
<cehteh>first package is tainted as 'private' if thats somehow possible
<bavier>a "testing continuation" could invalidate the "build continuation" if it fails
<cehteh>if the second one results in the same package, then this taint is revovked
<cehteh>mmh can we have 2 stores? one private store and one public store? .. would be nice when one could *just publish* a public store while maintaining a private store with own packages maybe even package things which wherent meant to be packaged before, like things which contain private key stuff (CA's etc)
<cehteh>just needs to be damn sure that this never ever can leak out
<cehteh>i'd feel a bit anxious about having a single store with private things as well, having separate stores would allow reasonable dumb publishing and make it easier to write backends for that (gnunet, ipfs, torrent, ...)
<lfam>Okay, I'm back after all. This issue of separating the tests is more complicated than it sounds at first :)
<cehteh>ideally one should be able just to serve the store without worries
<rekado_>you can’t have anything private in the store.
<lfam>Rather than try to bend the store into a mechanism for storing sensitive data, I think it would be good to research how people who are deploying many servers do it. Presumably there are some good ideas that we haven't heard of yet ;)
<cehteh>and if packages/derivations are private or public doesnt affect their hash, just the place where they are stored defines it
<lfam>Like, how do people deploy servers automatically along with sensitive data without exposing it unnecessarily. I'm sure many people have been trying to invent a solution since the rise of "devops"
<cehteh>those tend to make things more complicated .. see ACL's on store
<cehteh>eventually you need that when you want to deploy things site wide w/o exposing it elsewhere
<ng0>yep. lfam: for example the system of A/I, and how they switched from the deployment they described in the original Orangebook to where they are now
<lfam>One could say the same thing about functional packaging. It's more complicated than old-school mutable packaging, but it enables a much simpler workflow and way of reasoning about what's installed and how it's built
<lfam>cehteh: I didn't know people were using ACLs on the store. Has anyone published anything about it?
<lfam>ng0: What's A/I? I'm having troubling finding relevant search results along with "orangebook"
<lfam>Anyways, having a better method for distributing secrets with GuixSD would be awesome
<ng0>from what I know my potential goals are introducing GuixSD as a second choice OS to IN-Berlin Vservers and eventually introduce it to the collective A/I to maybe improve some parts of the infrastructure if it fits their usecase (from my outside view it does). At least A/I would be an application of this which is very often under attack and gets regular stress-testing of their infrastructure for free.
<lfam>bavier: The EOMA68 are armv7, not aarch64, right?
<bavier>lfam: for the current board, yes, but I think plans for future boards with aarch64 are in the works
<efraim>One small thing that I haven't worked o yet is the xorg service, which uses an Intel-only package, and should be rewritten to be swapped based on archtecture
<efraim>ng0: I looked at your dot-config files and I saw your bash alias 'clear = guix environment --ad-hoc ncurses -- clear', I added 'Control-l: clear-screen' to my .inputrc and now C-l works as expected and clears the screen
<efraim>i'm getting net-tools-for-tests FTBFS on core-updates for aarch64
<mb[m]1>The `itstool` update broke "gtk-doc" on master.
<xelxebar>So multiplication is iterated addition, exponentiation is iterated multiplication, tetration is iterated exponentiation, etc ad infinitum. What's a good name for the operation that takes maps an operator to the next highest order in this heirarchy?