<g_bor>civodul: is 50-100 regular contributor a good number for guix?
<g_bor>also, what contribution de we accept on the application period? One option is to stick with packaging, but I believe that for a documentation project documentation contributions should also be considered?
<g_bor>so I think that documentation contributions should be considered for a documentation project.
<civodul>g_bor: there are 40-50 monthly contributors and 100+ yearly
<civodul>i agree that documentation contributions would be nice\
<civodul>davexunit: "inferiors" are a way to talk to a separate Guix process, which can be used to refer to "old" packages, as in the example above
<xen1>guix system: error: build failed: some substitutes for the outputs of derivation `/gnu/store/r1rc6c4kryyahf361fj6984rvk746c6g-orc-0.4.28.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<xen1>root@gnu ~# guix system init /mnt/etc/cofig.scm /mnt --fallback
<xen1>guix system: error: corrupt input while restoring archive from #<closed: file 16c9000>
<xen1>guix system: error: build failed: executing SQLite query: database disk image is malformed
<katco>also, i'll be submitting a patch for go 10.3 -> go 1.11 either today or tomorrow. it's my first patch, so some hand holding is appreciated :)
<davexunit>can anyone else not compile guix right now? I thought it was just guix/scripts/pack.scm that had an issue but when I remove it from the makefile entirely I just get a failure somewhere else.
<janneke>hmm, one of my patches "cleaned up" just a bit too far, perl-boot0 does not compile
<janneke>working to cleanup wip-bootstrap further...
<civodul>roptat: maybe you could upgrade everything that needs to be upgraded at once?
<lfam>katco: I'm testing an update of Go 1.10.3 to 1.10.4 and if it works I'll push it today. I'm still interested in your work on 1.11! Maybe we will keep packages for both 1.10 and 1.11, or just use 1.11. We'll decide once we see how 1.11 works with Guix's go-build-system.
<lfam>Speaking of which, I'm looking for help with the go-build-system! It needs to be updated to work properly with Go 1.10 and above.
<thorwil>hi! without noticing at first, i started writing th items in native-inputs with comma-space: ("foo", foo), but now i see it's ("foo" ,foo) in given definitions
<thorwil>wht's the reason behind this space-comma thing?
<civodul>thorwil: comma means "unquote the next thing"
<civodul>rekado: i looked at the issue with traveling back to May 2016, and i think everything before f0527ce3a40e07d5f56b4b18c7eec91dbd016e88 (March 2018) will be hard to salvage; i can expound on that if you will :-)
<katco>lfam: "Each major Go release is supported until there are two newer major releases. For example, Go 1.5 was supported until the Go 1.7 release, and Go 1.6 was supported until the Go 1.8 release. We fix critical problems, including critical security problems, in supported releases as needed by issuing minor revisions (for example, Go 1.6.1, Go 1.6.2, and so on). " looks like you're correct
<civodul>lfam: by default OpenSSL looks for certs in /gnu/store/x8nacy2qpqlwi0gm7r6slcynv1cwmicb-openssl-1.0.2o/share/openssl-1.0.2o/certs/, which is empty; is this a recent change?
<janneke>civodul: much progress; just rewrote package-with-explicit-inputs, rebased on core-updates, now testing the build @gcc-mesboot; still some open questions -- hoping to compose a mail later tonight
<lfam>civodul: I'm not sure how old that behaviour is, but if I'm reading things correctly, it's very old. Basically, the default is defined with the macro X509_CERT_DIR in crypto/cryptlib.h as 'OPENSSLDIR "/certs"'. OPENSSLDIR is set at build-time as /gnu/store/...-openssl-1.0.2o/share/openssl-1.0.2o
<lfam>And can be easily tested with `openssl version -d`