IRC channel logs
2019-01-25.log
back to list of logs
<dongcarl>Any way to change working directory before a configure in a guix package? <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>dongcarl: I believe you should modify make-flags to get CXXFLAGS set. <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>argh, due to a wrong format string, 'guix refresh -l' would display the wrong number of dependents in some cases <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 <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>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? <jonsger>downloading substitutes feels very fast :P <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' *jonsger likes "guix weather" only when people doesn't forget to add their patches to gnu/local.mk <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 <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>I wonder if we can just disable TLS 1.3, merge staging, and fix this in core-updates. <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 <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` *rekado fixed the qgpgme test failure *rekado tests a fix for kcoreaddons <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: 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 <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>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>roptat: right abover this line you have: "warning: ambiguous package specification `guix'" <civodul>oh, that's because the cache contains two entries <civodul>well i think the easiest fix is to remove (@ (gnu packages package-management) guix-devel) <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>But I don't know where is this config stored <d4ryus>ah, guix environment glibc@2.27 did the trick :) <g_bor>rofrol: this is the guix system qemu image? <g_bor>then you should have a look at /etc/config.scm <g_bor>civodul: kcoreaddons is not building with no space left on device <g_bor>rofrol: you should modify the config in that. Just cons* the dhcp-client-service on the services field. <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. <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>But I am afraid it will modify the system I currently have <rofrol>in a way to make it unbootable or sth <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? <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' <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>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 <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 <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>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 <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 :/ <civodul>lfam: we usually set the mtime to 1, not 0... except in patch-and-repack <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 <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 <bavier>dongcarl: there is no network access inside the build containers <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>This error is reported when the number of watches limit gets exceeded. <CornBurglar>I ran systemctl start guix-daemon.service successfully <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... <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>I've just been playing with `guix environment -C -N` right now <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