<lfam>And yes, they both seem to be related to changes in glibc 2.26
<lfam>There is also an issue with rpcbind, where the default build glibc 2.26 removed headers for NIS/YP. They were spun off into a standalone library libnsl, or you can build glibc with --enable-obsolete-nsl. It's too late to rebuild glibc IMO
<mb[m]1>lfam: Good to know, there are probably lots of packages with similar issues :)
<soundtoxin>Latest mpv isn't building due to some dependencies related to libdvdcss and dvdread. Adding them both to my system packages and rebuilding doesn't seem to get around the issue either. https://hastebin.com/ekajawixab.sql log here
<RockAndSka>I'm looking to Guix for a while. I want to use it as an unprivileged user, so it comes to 3 options if I'm not wrong : use namespaces if available, use proot ( but require to proot all command i would like to use and didn't find a wrapper who use proot automatically for all commands inside a special directory, does it exist ? ), or compile guix wit
<RockAndSka>h a custom path but require to compile from all the packages from source because I can't use the subtitute
<RockAndSka>So i start to read about the offload system, but require a static config with offload servers already in place. Is there any roadmap to include a system to spawn dynamically some instances from cloud to offload the builds ?
<RockAndSka>or is there already a way to launch some commands before the offload hook to prepare the remote server used for the offload ?
<rekado>RockAndSka: offloading would not help you as you’d still need to store the built packages on your target system under /gnu.
<rekado>rebuilding everything is a big task and I wouldn’t recommend it.
<rekado>due to the nature of functional package management, you’d have to rebuild quite a few packages regularly.
<rekado>if user namespaces are available that’s probably the easiest way.
<g_bor>rekado: The remaining work on switching default jdk to java8 seems more tractable.
<rekado>RockAndSka: you’d run the daemon in a container where it can run as root, and where it has write access to /gnu (which may be bind-mounted from a directory your unprivileged user owns). When you run applications, though, they’d have to be run in that container as well.
<g_bor>rekado: I would like to know if adding ant-junit to packages is really the best way to solve the junit problem, because a lot of package definitions are affected. Also, if it is, should I squash these as one commit, or send them individually?
<g_bor>rekado: it seems that 39 packages are affected.
<RockAndSka>@rekado: to use a container, i need root access to install docker, so it is not a solution for what i want to achieve
<RockAndSka>@rekado: and why the offloading still need to store packages under /gnu if i reocnfigure guix to use a custom path ?
<RockAndSka>from what i read, the offload respect the custom path inside his builds
<rekado>g_bor: Does this package provide junit target support for ant? If so, should it be a default part of ant?
<rekado>RockAndSka: if you build with custom paths it’s going to be all right.
<rekado>RockAndSka: I just think that building everything from source will not be a nice experience.
<rekado>g_bor: what do you think about propagating ant-junit with the junit package? Does this make sense? Actually, I think it’s not so bad to add ant-junit manually to packages that use ant features for junit.
<RockAndSka>rekado: indeed it will be not a nice experience to rebuild all the packages, but without the possibility to use the substitute with custom path ( user namespace, automatic proot for a specific directory ) it is better than nothing and add the possibility to use the same environnement without "proot" trick
<g_bor>rekado: I tend to agree, that we could leave it as is, and add manually. Another thing that could be done would be to add ant-junit if we have junit, and the build system is ant-build-system. It is actually an optional component of ant. I would not propagate ant-junit in the prespective of having more java build systems. I don' think that making de
<g_bor>fault this default part of ant is not needed, we have a lot of packages not using junit.
<RockAndSka>rekado: but rebuild all packages on cloud computer could be a solution to speed up things, it will be great if we could had commands to the offload hook, that way we could use dynamic remote offload server
<buenouanq>where can I find if a particular wifi chip has a free driver?
<buenouanq>one in question is the Qualcomm Atheros AR956x
<g_bor>rekado: However, I dont know if we can make the add ant-juint if junit is added, and ant-build-system is the build system idea without making ant-build-system depend on junit.
<ng0>while I'm procrastinating, I have a question I couldn't answer out of my head at chaos congress: someone I know wants to use GuixSD on an i686 computer. this computer doesn't have enough resources to build software. all the other computers in their house are x86_64. offloading does not support cross-compiling to my best knowledge. what would be an applicable solution here?
<clacke[m]>run guix i686 on one of the x86_64 machines -- it might even be able to coexist with guix x86_64, with the right namespacing tricks around the daemon fifo
<clacke[m]>otherwise, just shove the i686 guix into a container
<ng0>right, I think one solution they thought about was to run a container with Guix i686 on the x86_64
<shiranaihito>running out of memory would usually result in stuff not happening properly
<shiranaihito>when did "postgresql-service" learn to initialize the data directory by itself.. ? or did it? :) (i.e. am i just confused)
<kwerdy>I see many mentions of efforts to get lvm support in guix over the years (even dating back to 2013) but it seems like none of it made it? Does guix support lvm nowadays and if so, how? I can't find any information whatsoever on the topic, and people who ask in mailing lists are told to check the mailing list archive, which only really show unanswered/incomplete threads...
<efraim>I don't believe there is support yet for lvm
<kwerdy>Any idea if someone is working on it or what the status is for lvm support? Or what happened with the 2013 and 2015 efforts?
<shiranaihito>so how would i generally avoid having the postgresql service getting disabled, because it won't start, because the data directory hasn't been initialized yet (after first installing the system)?
<shiranaihito>i thought of initializing the db with something like /gnu/store/0haa85i5rhpxmmninqpkyn3rqax83887-postgresql-10.1/bin/initdb .. but i'm not sure i can specify the postgres user for that command yet
<g_bor>kwerdy: I've been thinking about lvm support, and I feel that we miss an abstraction. It seems that we can map devices, we can even map multiple devices to one device, but we don't have partitions, i.e. we can't effectively part of a device to another.
<g_bor>Anyone here familiar with the installer effort?
<shiranaihito>so now that i've used a "local-file" for my postgresql.conf, where do i edit it? am i supposed to edit it somewhere, and then use the new version with a new "guix system reconfigure" command?
<catonano>shiranaihito: what are you trying to achieve ?
<shiranaihito>and the system reconfigure has been going on "for ages" now, basically
<shiranaihito>i wonder how the decision to skip some tests is made: "SKIP: tests/builders.scm" but "PASS: tests/modules.scm", for example
<shiranaihito>all in all, i have no clue what "guix system reconfigure" has been doing for a long time now, downloading stuff, compiling stuff, running out of memory, skipping tests (that supposedly matter when doing whatever it's doing).. and the only change (compared to the config applied before) was new content in a postgresql config defined as a "local-file"
<lfam>For Guix's own tests, again, it's handled automatically by the test suite. Generally, a test suite will check the environment for various features, tools, and other conditions, and decide which tests to run based on that
<shiranaihito>the worrying part here is all this work happening for no apparent reason though
<lfam>It sounds like your system is building the latest version of Guix
<shiranaihito>lfam ok, but why? :) all i did was run system reconfigure on a config that hadn't changed (itself), but referenced a "local-file" whose contents had
<lfam>Did you run `guix pull` ever since the latest `reconfigure`? Or did you never run it since initializing the system?
<lfam>Recently Guile 2.2 was released, superseding Guile 2.0. This brought some big changes to the Guile compiler, which allowed for faster run-time execution of Guile programs at the cost of slower and more memory-intensive compilation.
<shiranaihito>i guess that was used up too, before officially running out of memory
<lfam>Upstream, the Guile team is trying to reduce the resource consumption, but it's a slow and iterative process. In Guix, we are working on changes to `guix pull` that could improve the situation too
<shiranaihito>but if GuixSD basically requires more than 4GB of RAM for anything it's run on, that might be a problem too
<rekado>shiranaihito: we agree that it’s undesirable to require more than 1GB of RAM.
<shiranaihito>and why is it building stuff anyway when the only change is in the contents of a "local-file"?
<lfam>shiranaihito: The thing is, it looks like you are building the Guix package itself, which we generally offer substitutes for. However, you are building a really older version, so we might not have substitutes cached for that.
<lfam>Hm, maybe not "really" older, but not so current :)
<lfam>It may simply be a matter of waiting a few minutes for the mirror to be populated
<shiranaihito>lfam well, all i did was run "guix system reconfigure" with the same system config i used for "guix system init", but again, with new contents for a "local-file" referenced in the system config
<lfam>I'm sorry, my use of "Anytime" was ambiguous. My intention was to communicate that you don't have to it immediately after booting the new system for the first time, but simply at some point before you start reconfiguring the system, or building or installing packages
<shiranaihito>so just to be clear: run "guix pull" after "system init" and before any other "system" or "package" operation until the end of time? :P
<shiranaihito>i mean, any time i'm about to do a "system <something>" or some "package" operation, i should run guix pull first?
<lfam>Run `guix pull` after booting a newly initialized system and before doing anything that builds or installs packages
<lfam>Having been using Guix for a while, it's hard for me to see the weak points in our documentation. I already know how to do this stuff and how to avoid the potential pitfalls. So I'm curious, did you follow the system installation guide?
<shiranaihito>lfam yeah, i did, and i remember it mentioning i should run "guix pull", but apparently it didn't make it clear enough that it NEEEEEDS TO BE DONE, and what the correct time to do it is :P
<lfam>Okay, I'll see what we can do to clarify that