<str1ngs>hmmf I have a package that I want to copy to my publish server. though I've export and imported it. it still want to build the packaeg on the publish server. the guix describe hashes are the same. and the package file hash is the same. how do I figure out why it wants to build the package? and not use the imported path?
<dftxbs3e>efraim, oriansj: is it possible to create an environment container for a private package?
<pat_h>Hello, is there any Guix equivalent to Nix's 'nix-serve' (docs here: https://nixos.org/nix/manual/#sec-sharing-packages)? I know there is 'offload' for Guix, but I am looking for something that is closer to setting up one machine to pull substitutes/binaries from another guix machine on the same network.
<pat_h>That link may get recognized improperly, here it is again: Hello, is there any Guix equivalent to Nix's 'nix-serve' (docs here: https://nixos.org/nix/manual/#sec-sharing-packages)? I know there is 'offload' for Guix, but I am looking for something that is closer to setting up one machine to pull substitutes/binaries from another guix machine on the
<g_bor[m]>civodul: I believe we can announce our intention to participate, and showcase the project ideas, so that potential applicants know what to expect, and post an update when the participation becomes official.
<civodul>would you like to spearhead that again, and if so, what help do you need?
<g_bor[m]>Actually the approach taken by the two organizers are now completely the opposite of one another. Outreachy expects the students first, with barely any infromation about the perspective projects, while for GSoC they expect the project ideas first, and later come the students, with all the project possibilities at hand.
<g_bor[m]>civodul: yes, I will prepare a blogpost about our intention to participate. Do we have any other forums we should promote this?
<g_bor[m]>Also, we are handling everything for Outreachy, but I believe I should contact the GNU GSoC group regarding GSoC.
<civodul>g_bor[m]: in the case of GSoC, i guess we cannot promote anything until we have a list of projects + mentors, right?
<civodul>in the case of Outreachy, it seems weird to say "we're participating" if we're not putting some projects on display, but maybe that's how it's supposed to work?
<g_bor[m]>civodul: I think that this system is very new, and there are some communication curlpits. The main thing is that by the time the projects are announced the initial application period is already closed. We should communicate something like 'if you think a project will fit you, then you should fill in the initial application form. If it turns out that there is no appropriate project, then you don't need to go further with
<kirisime>Looks like I need firmware, thanks anyhow leoprikler
<ng0>i guess you were as generalizing as i was, discussing libressl details isn't that important to me. some ports I don't get (guilty of working on some myself, but just out of curiosity), like a portable openbsd nc which is now packaged for guix
<roptat>mh... that's what I'm using too, and I get the English manual, even with my fr locale (which is expected, info doesn't support i18n)
<roptat>the other languages are supposed to be separate info files (there's guix.info for the English version, guix.fr.info fro the French version, guix.de.info for German, etc)
<roptat>so "info guix" should open guix.info, but I remember a discussion where it appeared that older versions of info / other implementations simply dropped the file names at the first dot (to support guix.info.gz for instance) instead of at the last dot
<roptat>which means that guix.es.info is mapped to the info manual for guix, as well as guix.info, guix.fr.info etc
<roptat>but you should have a recent enough info reader...
<jyscao>roptat, great thanks, info guix.info gave me the english
<nckx>Parra: Guix shouldn't bundle anything 😉 There isn't really such a thing as ‘X11’, you should find out which library (I mean, it could be libX11 but that's often not enough) Ruby tests for, and make sure it's an input.
<Parra>I mean, Ruby isn't building tk which is a graphic UI library, because it depends on libx11 and it isn't present, this is a bug? because python and Ruby both use tk
<Parra>this is how it's working right now on the current ruby package in guix master
<Parra>so ruby build is incomplete, all gems depending on tk wont work
<smithras>it sounds like he just tried 'guix --help' without realizing that there was a 'guix package --help'
<nixo_>half of his problems can be explained by the hash thing. the icon problem is different and as I'm not using a DE I don't know if it can be fixed easily. The slowness, I don't know, as I'm used to it (and I think it became faster in the last year, and this review is 6 months old)
<nixo_>bavier: ok your commit worked (and it took 55 minutes for my computer to build it...). I hope the git bisect will catch it fast
<nixo_>the command is "guix environment --ad-hoc ffmpeg meson ...."
<alextee[m]>doesnt the current profile have everything installed?
<alextee[m]>but maybe it's more "correct" to be in an environment
<nixo_>I think not all environment variables are set when you just install it in the profile
<valignatev>Hey! Couple days ago I had a problem with guix failing to find locales. The weirdest thing was that guix-daemon didn't have any problems with locals while user's guix couldn't find them and warned me with "failed to install locales" every time. roptat was kind enough to explain to me how guix and guix-daemon relate and how locales work with guix: e
<valignatev>.g. their relation to glibc and user profiles. It really got me to the right direction and I've solved my problem finally, yay!
<valignatev>The problem was that I'm using fish shell really, and GUIX_LOCPATH wasn't set as a global environment variable, it was set as a universal shell variable, and they are a different things in fish. Basically, "universal shell variables" don't get exported to the child processes. In order to make them so, one have to "set -Ux GUIX_LOCPATH $HOME/whateve
<valignatev>It all snapped when I was digging deep and opened "guix" executable in the text editor which is just a little scheme script that reads GUIX_LOCPATH and adds to a guile load paths. Then I've tried (getenv "GUIX_LOCPATH") in the giule repl which returned #f, I've tried (getenv "PATH") which returned correct PATH, and I figured out the something _fish
<valignatev>roptat: So yeah, thanks one more time, your explanation was really helpful. I've also found out that fish package definition in guix itself is installed in such a way that it reads /etc/profile and potentially obtains GUIX_PROFILE and GUIX_LOCPATH from there, so I'll try to replace my Arch fish with the fish from Guix and see how it goes. But even
<dftxbs3e>there could be a list of servers that publish hashes, and GNU Guix would hardcode a list of all these servers, and every time you get a package, if the hashes don't correspond to what everyone (or 90%) got, you get a want-to-continue warning
<nckx>johnjay: The installer is the first *and last* GUI helper, unless you count emacs 🙂