<Isorkin>how to specify guix package to build perl5.10.1.scm
<mekeor>Isorkin: you can put set the environment variable GUIX_PACKAGE_PATH and then put your package definition in there and then just 'guix package -i firstname.lastname@example.org'
<thomasd>rekado_: I did a small demonstration of Guix to our sysadmin. He would consider setting it up on a system here, but wanted some more info on how it would work out with shared storage on NFS etc.
<rekado_>it seems to be linear in the number and size of files in the profile.
<rekado_>re central uids: yes. You also want to be sure that all hosts that can mount the share over NFS have read-only access. Only the “guix builder” host should have write access.
<thomasd>rekado_: thanks, it all sounds doable within our setup! (but I'm no sysadmin myself, so there are likely some details I'm overlooking)
<rekado_>thomasd: I have a couple of unpublished scripts and snippets for a cluster deployment
<rekado_>all the nodes where users should be allowed to manage their profiles should redirect guix RPCs to the guix builder host.
<rekado_>to achieve that I listen for RPCs on the network using socat.
<thomasd>ah, that's a new step compared to your blog article. As a first step, I'd aim for the setup you describe (with a dedicated host running guix), but it'd still be great if you're willing to share the scripts. (never heard about socat until now, but I'll figure it out :) )
<rekado_>it’s still a dedicated host running the daemon.
<rekado_>but the daemon listens on a socket, which is exposed to the intranet.
<rekado_>a script “guixr” is installed on /gnu/remote/bin
<rekado_>and all that does is run the actual guix script (also shared on /gnu/remote) with a few variables set to redirect RPCs to a temporary instance of socat that connects to the exposed daemon socket.
<rekado_>those people who want to use their own version don’t normally use our shared installation anyway.
<rekado_>Guix normally checks the user’s ~/.config/guix/latest symlink
<rekado_>but it doesn’t do it when pre-inst-env is used.
<rekado_>it’s possible to do without pre-inst-env, but I didn’t have a need for that yet.
<thomasd>yes, it would probably be fine here, too (we would start with a try-out phase anyway). By “people who want to use their own version”, you mean people can use their own checkout, and connect to the remote daemon on the build host in the same way as your guixr script?
<rekado_>thomasd: they would have to have ~/.config/guix/latest pointing at their version of Guix. No other change would be required on their side. But this is currently not supported as the guixr uses pre-inst-env.
<thomasd>yes, but they could run their own “guixr”, too, I think? Also, do I get it right that your guixr setup even allows people to use “guix environment” from the remote machines?
<efraim>i see hydra is still trying to cross build from armhf/i686 to aarch64, anyone know how to disable that? I'm not familiar with the build-aux/hydra code
<rekado_>thomasd: yes, they could have their own “guixr”. It just has to talk to a socket that is forwarded to port 9999 on the remote server.
<rekado_>thomasd: “guix environment” works fine on all nodes.
<thomasd>rekado_: neat, can't wait to have it running here :)
<ng0>hi, has the urwid failure already been resolved? I just ran into it while initing a new system
<ng0>fixed itself as I used xfce-service now ... I think
<ng0>without this error, a guix system installation, including a guix pull, takes 2 - 3 hours on hardware from around 2010 / 2012 .. including compiling with --fallback etc. Might this be worth to add to the documentation to give an average expectation of how long it could take to set up the system?
<rekado_>ng0: I don’t think we should add this to the manual.
<sneek>civodul, wingo says: did you forget to push guile-web update for 2.0.14? if so would you please rebase and push and regen the guile web site; i think we might have lost 2.0.14 news item from the feed
<ng0>I mean guix has no dependency on cvs, and cvs-download exists :)
<ng0>civodul: is guix pull over onion disfunctinal as it is currently? I'm trying to figure out by replicating hydra.gnu.org locally, why the .onion of bayfront is not picked up. I don't want to confuse bancfc with this input, but it would fall into the scope of the questions askec
<ng0>over the onion of bayfront I mean. it's never picked up, even when it's defined.
<sneek>gnu_guix, Apteryx says: About pip not finding python packages, this is a "known" issue. I haven't bothered opening a bug about it but it's on my fixing todo list. Even have a branch with some hacking on it. The problem is how we define the searchpath (and use PYTHONPATH). We should create a distinct GUIX_PYTHONPATH for that instead.
<sneek>gnu_guix, adfeno says: continuing Apteryx's message: Also check that there is a file at "$HOME/.pip/pip.conf" and see if it has "target=" set to some place you can write to.
<rekado_>catonano: in Guix we pass CONFIG_SHELL to point at the actual bash executable.
<rekado_>catonano: when you have to add autoconf and others you are working with sources that have not been bootstrapped. Are you trying to use the development version? If not, try a proper release tarball.
<rekado_>gah, I’m still working on Hartmut’s java patches.
<catonano>rekado_: I am using a released tarball: 0.1.2. I just saw autogen and I assumed I had to run it.
<lfam>quiliro: The best way to learn this is to try writing some shell scripts to simplify or automate some tasks that you do
<ZombieChicken>Well, if you're on that mailing list then there is a patch for the package in the email. As for a package patch, I don't know enough to do that and other things are more pressing (like finally ditching Gentoo)
<lfam>ZombieChicken: We *should* do a better job patching QEMU, but the volume of security issues published about QEMU is insane.
<lfam>Often, they get published when the patches are still in the RFC stage, so we can't address them at that time
<ZombieChicken>Ideally Qemu's devs would fix things and push updates to fix it and devs would just need to update the version number
<ZombieChicken>Anyways, off to (re)start backing up a few hundred gigs of data over USB 2...
<lfam>Although I must be fair to the Debian maintainer. It was extremely difficult for downstream maintainers to communicate with the OpenSSL project at that time. There are some important projects that are still like that...
<lfam>You would not be able to ask their advice about a change or issue even if you tried
<lfam>quiliro: Are you using an i686-linux system?
<ZombieChicken>Always nice to have uncommunicative people writing important software. It really helps you feel confidant that they'll fix bugs instead of ignoring them
<lfam>I found a gnupg test failure when building for i686-linux
<ZombieChicken>lfam: On a somewhat related note; does GuixSD support LibreSSL?