<serichsen>I can't see my virtual consoles, although I could see in a term in X that the gettys are running. What might be the problem? (I also locked myself out because I can't login to X anymore, due to some mistake in .xsession or .xinitrc or something, so I have to start from a rescue stick again.)
<civodul>i'm never quite sure whether messages sent to a closed issue are actually relayed
<dongcarl>Hey all, perhaps this is a general question about build systems but what the heck. To make sure that I have a static version of bitcoin-core that we can distribute as binary tarballs. I would need all my package inputs to also be static, right?
<g_bor>rofrol: that should not happen, you can most probably boot the previous version on you grub menu
<bgardner>So if you have a GuixSD installation up and running with a certain package NOT installed, then a user installs it, and then after that you reconfigure the system so that it IS included. Does the user's installation just fold into the system or does it need to be separately pulled and updated as time goes on?
<lfam>dongcarl: Can you give me the link to the relevant patch?
<dongcarl>lfam: 38f77be464b0b6ca76105d5f0a1b5e55fd694036 in staging
<dongcarl>cbd833750a57ae0596e80d06c74b02bccddf6197 has been in core-updates for longer I think
<lfam>dongcarl: I see. We've been waiting to update it on master because it would cause a lot of dependent packages to be rebuilt. It seems non-urgent because there are substitutes available, right? Or am I missing something?
<dongcarl>lfam: Well I found this bug while building bitcoin-core, and mariadb is a dependency of qtbase
<dongcarl>I'm a n00b, what do you mean by substitutes?
<lfam>dongcarl: I mean that we've already built a mariadb package, so nobody should need to build it themselves
<dongcarl>lfam: I'm trying to convince our developers to use Guix as a replacement for our current bootstrap system, as I love that we can track the trusted binaries in a graph in Guix, but without the ability to build it ourselves it is sort of pointless
<lfam>Sorry if this discussion already happened, I've been mostly absent lately. Did you bring up that point on the mailing list discussion of the subject?
<dongcarl>lfam: I don't think I did, I only submitted the patches
<cbaines>It's likely that staging will be merged in to master within the next week
<lfam>I ask because although mariadb's reverse dependency graph is technically larger than what we normally change on the master branch, it's not very much bigger. Perhaps an exception could be made, dunno
<cbaines>hopefully the last few issues can be resolved
<bavier>I put the patch on staging because of the number of dependents
<dongcarl>I'm happy to respect Guix's governance process, I just think that perhaps the builders should be run a little more often. I truly love that Guix guarantees a lot of software freedom, but if users can't build and have to rely on downloads, then it defeats the purpose a little.
<dongcarl>It is funding that is lacking? Genuinely curious.
<bavier>but, even so, for users who would prefer to build packages themselves, it's nice to not be "disrupting" master all the time
<dongcarl>Yes, I'm happy to do work from a local branch. I guess to be very specific, my question is: Why did I spot this and the build farm didn't? Why was it that the last time mariadb was build was a few months back?
<lfam>dongcarl: It means that the package did not need to be rebuilt because none of its dependencies had changed
*dongcarl trying to convey that this is genuine curiosity and not accusations
<lfam>Any time the dependency graph changes at all, the package will be rebuilt
<bavier>and the tests are flaky, and the build farm got lucky :)
<lfam>We try to identify and skip flaky tests for this reason
<cbaines>dongcarl, while I think it would be good to assess the quality of packages by rebuilding them to check they build every time, and bit for bit reproducibly, this isn't something that is done currently
<cbaines>(outside of the normal builds because a package actually needs to be built)
<dongcarl>Hmmm... Okay here's my naive thought... For packages with a lot of dependencies, maybe they can be built twice or thrice to spot flakiness? No guarantees but it might catch something?
<roptat>Now I need to understand how to use it to build maven plugins that will be used by the future maven-build-system :D
<g_bor>rekado: is it possible that it hits another resource limit? For example the number of open file descriptors, or runs out of inodes?
<g_bor>I have to go now, I will have a look at that later, if nothing comes up...
<CornBurglar>I'm running into an error installing guix on a foreign distro (Fedora 29) : guix package: error: failed to connect to 'var/guix/daemon-socket/socket': No such file or directory. I also notice that any folders I would expect to be set up, like the directories /var/guix/profiles... are missing and I'm not sure what's causing the issue here.
<CornBurglar>It looks like despite executing the command it is not running
<cbaines>dongcarl, regarding curl and networking. You can use (origin ... ) blocks as inputs as well, which can be neater if you want to pass multiple things that should be fetched from the network in to a package
<dongcarl>cbaines: Oh... you can have multiple origin blocks?
<cbaines>dongcarl, so the (origin ... ) block represents as fixed output derviation. You can pass anything that can be represented in the store in to a package as an input, including (origin ...) blocks.
<cbaines>Sorry, I'm not explaining this very well. I don't know if there are any examples in Guix, as it's an unusual thing to do.