<ng0>jonsger[m]: I think it was on the mailinglist a long time ago <Apteryx>sneek, later tell civodul: svn is an optional dependency for git, for git-svn I believe. <Apteryx>I also get annoyed when subversion gets built for git when I have no use for it! Tests are especially lengthy... ***pareidolia_ is now known as pareidolia
<OriansJ>one would think if the binaries are perfectly Identical to one that passed the tests, that the tests wouldn't actually be required <Apteryx>when substitutes are built it's because no binaries were found to start with, no? <vagrantc>or the binaries downloaded didn't match the expected hashes, if i'm understanding correctly <Apteryx>vagrantc: replace binaries in the sentence I said with 'valid binaries', and we got all cases covered :) <Apteryx>Where would this line get printed in Guix?: Downloading https://bayfront.guixsd.org/nar/gzip/30ljqil5xmcs... Grepping for "Downloading" returns a single possibility: line 965 in guix/scripts/substitute.scm, but messing the text and running Guix with ./pre-inst-env doesn't change a thing, so... I'm confused :) <brendyn>When gvfs is installed, the gio command is not available because glib:bin is not available. Shoul glib:bin be a propagated input of gvfs? <Apteryx>oh, the error comes from the nix daemon ***Guest77373 is now known as sturm
***sturm is now known as Guest72803
<sneek>civodul, you have 1 message. <sneek>civodul, Apteryx says: svn is an optional dependency for git, for git-svn I believe. <efraim>We could have git-svn as a separate package completely <civodul>we'd need to check whether Git's build system makes it easy <civodul>ACTION tries to come up with a stripped-down "groff-minimal" that doesn't depend on Perl <brendyn>Is it possible to have a package in both native inputs and propagated-inputs? <brendyn>I thing gvfs requires glib:bin, but in already has it in native-inputs, so i was unsure <civodul>as long as there's a justification, that's fine <civodul>you mean it requires glib:bin at run time? <brendyn>because commands like gvfs-info require binaries in glib:bin <civodul>then it's probably better to patch the gvfs source so that it refers to those programs by absolute file name <civodul>(propagated inputs are frowned upon) <brendyn>I thought it might be the reason Evince is failing to save data like the last page i was on in a book, but it still doesn't work after i installed it. <brendyn>Ok well maybe it can work as an input too <jonsger>civodul: I think we should note in the Release notes/mail that there could still occur problems with memory consumption... <civodul>jonsger: well that's akin to saying "there are still bugs" :-) <civodul>though the Guile 2.2.3 release of today addresses part of that <civodul>and other changes that were made in Guix help as well <civodul>so i don't know if we need to draw attention to this specific issue <jonsger>okay. didn't get that about the new guile release, if this fixes those problems. then of course <rekado_>civodul: that’s 77% of 17% of the tested packages. <sneek>Welcome back rekado_, you have 1 message. <sneek>rekado_, wingo says: sounds like equiv of -O1. anyway yes there is a lot of duplication there, am working on avoiding producing some of the more egregious bits <civodul>rekado_: oh right, we're doing better (i guess 17% of Arch packages < 100% of Guix packages) <rekado_>on a CentOS 7 server guix-daemon could not be started <rekado_>systemd said: Unknown lvalue 'PassEnvironment' in section 'Service' <rekado_>and: Unknown lvalue 'TasksMax' in section 'Service' <rekado_>had to remove these settings to start it. <civodul>the cluster at work has CentOS 7.1 and i think it went fine <civodul>wigust: that's expected: "environment-variables" remove strace from $PATH <civodul>you can run $GUIX_PROFILE/bin/strace though <wigust>civodul: Oh, dumm. Forgot about $GUIX_PROFILE. Thanks! <brendyn>Looks like Guix is around 90% reproducible. ***propumpkin is now known as contrapumpkin
<OriansJ>rekado_: shakespearian by the looks of it <OriansJ>baconicsynergy: the fastest way to have Guix production ready is to start working on pieces you think need to be done to make it production ready <rekado_>baconicsynergy: I’d say it is production ready, being used in production and all. <bavier>with guix-on-guile-2.0 I get this from tests/guix-daemon.sh: 'ERROR: In procedure setvbuf: Wrong type argument in position 1 (expecting port that supports 'setvbuf'): #<input-output: gnutls-session-port e69820>' <mb[m]1>Why do the various "root-os" system tests attempt to download the bootstrap binaries from within the VM (and fail)? <civodul>bavier: i would have thought this came from 866f37fb7e4f3e0bd695a951071383cdff3da8cd, but apparently not <bavier>civodul: I'm bisecting right now <mb[m]1>civodul: yeah, the in-vm build fails because it can't download the bootstrap binaries. <mb[m]1>I think they are in my store: I did `guix build bootstrap-binaries` and even -e '(@@ (gnu packages bootstrap) %binutils-bootstrap)' to be sure. <mb[m]1>Testing without the glibc and binutils grafts now. <mb[m]1>Would it be acceptable to simply add an LVM activation service to %base-services? <OriansJ>mescc-tools has just released v0.3 and it'll be in guix as soon as janneke feels like it ^_^ <mb[m]1>civodul: dropping the glibc and binutils grafts made no difference. Ideas? <mb[m]1>I'm heading out for now, but should have some LVM patches by Sunday provided I can get the system tests working. <bavier>civodul: indeed 866f37fb7e4f3e0bd695a951071383cdff3da8cd is the first commit where this test fails for me <bavier>civodul: 'guile-2.0' is not a feature <civodul>oh i guess it should be (not guile-2.2) <bavier>so the cond-expand skips over and issues the setvbuf <bavier>unless 3.0 will define guile-2.2, the docs say "starting from Guile 2.2" <mb[m]1>I just read #29409 and see the bootstrap binaries problem is discussed there. But it's peculiar that dropping the binutils and glibc grafts didn't make a difference. <mb[m]1>Hmm maybe it's using the Guix snapshot. Can try making a new one tomorrow. <civodul>bavier: to be safe we can write (and guile-2 (not guile-2.2)) i think <mb[m]1>Somewhat ironically, the <mapped-device> interface is not a great fit since the LVM tools wants to do all the mappings at once automatically, instead of specifying source and target. <mb[m]1>I considered using`dmsetup` directly, but an early boot service that runs `vgchange -ay` is all that's required for the simple case. <mb[m]1>civodul: with some luck we can support LVM in 0.14! :) <buenouanq>has the goal of v1.0 out by newyears been abandoned then? <mb[m]1>buenouanq: I think one milestone for 1.0 was a "channels" interface, but it didn't make it yet. Though I don't actually know if the next release is 1.0 or 0.14. <mb[m]1>bavier: did you manage to solve the remaining Guile 2.0 test problem? <bavier>mb[m]1: yes, I've figured out fixes, need to get patches applied still <nee`>what package contains the host executable? <mb[m]1>bavier: sweet, thanks. I have a system at work that's stuck on 0.13.0-8 IIRC. <mb[m]1>nee`: that's probably bind:utils. <nee`>mb[m]1: Thanks! I was looking for it with bind-utils