IRC channel logs


back to list of logs

<dongcarl>Any way to change working directory before a configure in a guix package?
<dongcarl>`chdir` apparently
<jackhill>bgardner: cool, glad that worked out for you!
<dongcarl>Where can I specify CXXFlags in a guix package?
<rekado>bgardner: you can also use Ctrl-L
<g_bor>hello guix!
<g_bor>dongcarl: I believe you should modify make-flags to get CXXFLAGS set.
<roptat>hi guix!
<civodul>Hello Guix!
<g_bor>civodul: I've update the GSoC page, and sent a letter ot the ml, to allow people who offered to mentor last year to review.
<civodul>g_bor: excellent, thank you!
<civodul>argh, due to a wrong format string, 'guix refresh -l' would display the wrong number of dependents in some cases
<civodul>roptat: ↑ this has to do with ~*
<civodul>hi serichsen
<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.)
<roptat>civodul, in the French translation?
<serichsen>To be more specific, the screen is just blank
<serichsen>I can even login blindly and do things.
<roptat>weird, but I don't know how to help :/
<civodul>roptat: no, in English; i've already fixed it locally, but i wanted to share my astonishment :-)
<roptat>mh... ok
<roptat>btw, I can't really use it in my translations (for instance when two things are said in reverse order in French) because gettext doesn't like ~*
<roptat>so, some of the sentences in French used to be in reverse order compared to English
<roptat>that's because gettext thinks we use lisp format strings (where I think ~* either has an other meaning or doesn't exist) instead of guile
<roptat>so I'm forced to use the same order, and this also prevents one of the files from being translated at all
<nly>are there services which can be started as user?
<cynede>what is copyright policy for contributors? able to use pseudonims?
<rekado>cynede: yes.
<jonsger>downloading substitutes feels very fast :P
<civodul>jonsger: yay :-)
<civodul>make sure to let Chris know about your happiness!
<jonsger>yeah, but to be honest I wished we don't need Amazon for that...
<civodul>problem is that achieving high-availability and high-bandwidth is not easy
<civodul>and more importantly, none of us is doing it
<jonsger>yes, I know that. So I think the solution with Amazon is the best for the moment
*civodul pushes 'guix weather --coverage'
<civodul>hope you'll like it :-)
<roptat>what's that?
*jonsger likes "guix weather" only when people doesn't forget to add their patches to gnu/
<bgardner>rekado: Aware of Ctrl-L, but I was trying to add things to .zlogout, as opposed to interactively. All good now.
<civodul>roptat: i've just sent an email on this topic
<civodul>basically it tells you which important packages lack substitutes
<roptat>ha, cool :)
<civodul>the goal is to get "staging" merged in our lifetime :-)
<rekado>staging is on hold because of the problems downloading with TLS 1.3.
<rekado>that’s bug 34102
<rekado>I wonder if we can just disable TLS 1.3, merge staging, and fix this in core-updates.
<civodul>i wasn't aware of that
*civodul M-x debbugs-gnu
<cynede>why are you using mailing lists for patches and 7k+ lines files for packages, was there reasons for it :(
<rekado>cynede: these files are modules. They contain multiple package definitions.
<cynede>yes but why not split it into more files
<rekado>what is the problem you have with the size of the files?
<cynede>in VCS it will be easier to track changes for single packages for example
<rekado>I don’t think that’s true.
<efraim>ccl 1.11->1.11.5 broke armhf support, and sbcl hasn't been working on armhf since upgrading to 1.4.13 :/
<cynede>rekado there is `git log --follow -p -- file`
<cynede>same works for directory...
*rekado fixed the qgpgme test failure
*rekado tests a fix for kcoreaddons
<civodul>rekado: yay, thumbs up! :-)
<civodul>this won't have been in vain ;-)
<civodul>rekado: BTW, did you see ?
<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?
<janneke>dongcarl: probably, yes
<dongcarl>janneke: Thanks!
<janneke>dongcarl: i assume you've seen the features of guix pack (relocatable, symlink) that would support using shipping and running shared libraries?
<dongcarl>janneke: Perhaps I did it wrong last time but it seems to want to ship an entire environment around it as well?
<janneke>dongcarl: it will certainly package the whole closure, if that's what you mean, yes
<dongcarl>janneke: Yeah I'm trying to use guix as a way to build our GitHub release tarballs which are much more minimal
<dongcarl>So back to static linking I go :-)
<bavier>It seems the wine-staging package can be moved to wine@4.0
<civodul>dongcarl: if you run "guix package -A -static" you'll see existing statically-linked packages that you can take inspiration from
<civodul>some of these are used in the initrd, for instance
<dongcarl>civodul: Thank you! That's very useful :-)
<roptat>guix environment: warning: choosing guix@0.16.0-8.7ba2b27
<roptat>what does that mean?
<roptat>that's a warning from "guix environment guix" from current master
<rekado>civodul: sorry for the delay! I did receive the message but I didn’t see it in my inbox.
<rekado>thanks for the reminder; just replied.
<civodul>rekado: cool, thanks
<civodul>roptat: right abover this line you have: "warning: ambiguous package specification `guix'"
<civodul>which is nonetheless surprising
<civodul>oh, that's because the cache contains two entries
<civodul>lemme see
<civodul>well i think the easiest fix is to remove (@ (gnu packages package-management) guix-devel)
<civodul>we no longer need it
<d4ryus>hi, i would like run a program in a environment with glibc 2.27 (my version is 2.28), is it possible? if so, how would i do it?
<rofrol>I want the `dhclient eth0` command start at boot. I see there is
<rofrol>But I don't know where is this config stored
<d4ryus>ah, guix environment glibc@2.27 did the trick :)
<rofrol>I someone can answer this
<g_bor>hello guix!
<g_bor>rofrol: this is the guix system qemu image?
<g_bor>then you should have a look at /etc/config.scm
<g_bor>do you have such a file?
<g_bor>civodul: kcoreaddons is not building with no space left on device
<rofrol>g_bor: yes. qemu image
<g_bor>rofrol: you should modify the config in that. Just cons* the dhcp-client-service on the services field.
<rofrol>I don't have /etc/config.scm
<g_bor>Then guix system reconfigure
<rofrol>or any other scm file under /etc
<g_bor>you can also just copy any config.scm sample from anywhere. It should just work.
<rofrol>$ guix system reconfigure
<g_bor>it needs a config.scm as a parameter.
<rofrol>guix system: error: wrong number of arguments for action `reconfigure`
<g_bor>rofrol: yes, it needs a config.scm
<g_bor>you can use any sample you find...
<rofrol>Like the sample from here ?
<g_bor>yes, it will do
<rofrol>But I am afraid it will modify the system I currently have
<rofrol>in a way to make it unbootable or sth
<rofrol>Maybe I should use this one
<rofrol>As I am using vm image
<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?
<g_bor>you can use that
<dongcarl>It seems like the changes to mariadb still hasn't been merged? :-(
<rofrol>Is vm-image build from v0.16.0 tag or master?
<lfam>bgardner: Packages provided by the system are controlled separately from packages installed by users
<lfam>bgardner: So, yes, the user's installed packages need to updated separately, by the user. This gives the user more control over their environment
<bgardner>lfam: That's consistent with what I expected, okay - then if they remove that package they would revert to seeing/using the system package?
<lfam>bgardner: Yes, if it was installed at the system level. The packages provided by the system administrator through config.scm are made available at '/run/current-system/profile/bin'
<bgardner>lfam: Awesome, thank you
<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
<bavier>lfam: hydra has substitutes for mariadb
<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>dongcarl: Understood
<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>rekado: thanks for the synergy update :)
<cbaines>dongcarl, in my opinion, unfortuantely it's not something that more money for infrastructure can solve on it's own
<dongcarl>cbaines: Do go on
<lfam>dongcarl: The builders run continuously, on every commit. But we try to avoid making changes that cause >300 packages to be rebuilt on the master branch
<cbaines>well, there's issues with Cuirass, which has been getting better, but it still doesn't give a great overview of what's not working and why
<bavier>dongcarl: could you and your coworkers work from a local branch for the time being?
<lfam>The immediate reason for this was that, previously, the build farm could not do more than that. Now, it can do more than that
<lfam>IMO, mariadb could be updated on master, assuming the build farm can keep up. I think we can trust the mariadb team to not break dependent programs in minor version updates
<g_bor>rofrol: I believe so
<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 :)
<dongcarl>lfam: I see I see!
<lfam>Yes, it's a problem for flaky builds ;)
*dongcarl shakes fist at sky
<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?
<lfam>It's definitely something to consider
<lfam>Maybe it should be a subject for discussion at the upcoming "Guix Days" meeting. The CI / build farm process and possible improvments
<dongcarl>Awwww, sad I'll be missing that
<dongcarl>You guys have fun tho, cheers!
<lfam>I'm sure we will :)
<lfam>Changing the subject... 'patch-and-repack' resets mtimes to the epoch, right? Is it possible to not do that, and preserve mtimes?
<lfam>This actually breaks the build of the Go compiler!
<lfam>There are some Go tests that rely on upstream file mtimes
<cbaines>lfam, is the breakage regarding zip's?
<cbaines>as I've seen that failure (I think connected with go stuff before)
<lfam>I don't understand what these tests are looking for, but they explicitly look at the file mtimes and croak when the mtime is 0
<lfam>I could skip them. I've actually looked into this 3 years ago and have an upstream bug report on the subject
<bavier>istr a suggestion to set times to 1 instead?
<bavier>I don't recall what the was in relation to though
<lfam>Unfortunately none of this is fresh in head :/
<lfam>in my head
<civodul>lfam: we usually set the mtime to 1, not 0... except in patch-and-repack
<civodul>something to fix in core-updates
<civodul>(everything in the store has the mtime set to 1)
<bavier>lfam: is the go stuff failing because mtime=0 or because the mtimes loose relative ordering?
*lfam re-runs the tests to get the failure output
<lfam>Go 1.11 fails like this if you apply any patch:
<rekado>g_bor: that one test for kcoreaddons also fails with an out of space error.
<rekado>g_bor: I fixed the error that originally caused the build to fail.
<rekado>FWIW I had 8.7G free disk space when I started the kcoreaddons build. The one test generates a lot of files, but I don’t think it actually runs out of space.
*rekado tries to fix the scmutils build
<dongcarl>When I have `curl` as a build dependency and try to use it in my build it seems to not be able to resolve anything
<dongcarl>Feel like I'm missing something here
<bavier>dongcarl: there is no network access inside the build containers
<dongcarl>bavier: Ah I see
<dongcarl>Any way to get around that? Or will I have to specify everything in origin?
<bavier>no way around, using origins is the solution, indeed
<roptat>I've built maven-plugin-plugin! \o/
<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.
<lfam>CornBurglar: How did you install Guix?
<rekado>CornBurglar: this error means that the daemon isn’t running.
<rekado>hmm, there are many problems building scmutils with the current mit-scheme. I think it may not be compatible.
<g_bor>hello rekado!
<CornBurglar> from this package. I have also tried to install with the install script on the guix website before and run into the same issue.
<g_bor>This seems related:
<g_bor>This error is reported when the number of watches limit gets exceeded.
<g_bor>How could we mitigate that?
<CornBurglar>I ran systemctl start guix-daemon.service successfully
<rekado>g_bor: we can disable the test.
<rekado>it doesn’t seem very important.
<rekado>CornBurglar: can you confirm that the daemon is actually running?
<g_bor>ok, will you have a look at that, or should I
<g_bor>I can do it only tomorrow, maybe later...
<rekado>no rush, thanks!
<tune>how come sftp on guix does not have tab complete? can I change this?
<rain1>are you using password or key based auth?
<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.
<dongcarl>cbaines: Oh I see!
<dongcarl>I've just been playing with `guix environment -C -N` right now
<bavier>there are examples
<dongcarl>Just wanna get something working for now
<g_bor>dongcarl: icedtea packages use this
<dongcarl>But yeah that seems like it'd be the way to go once I get things working
<dongcarl>g_bor: Thank you sir!