IRC channel logs


back to list of logs

<ng0>xfsprogs works more or less. some tools need checking.
<ng0>i was able to create and mount a device.
***jonsger1 is now known as jonsger
***rekado_ is now known as rekado
<rekado>hmm, I manually built core-updates wayland on berlin, but I still cannot get its substitute.
<civodul>Hello Guix!
*janneke is commenting and cleaning-up patches -- discovering some bits are no longer needed...and discovering other bits are :-/
<janneke>it would be nice if the gcc-4.x tarballs weren't so big with stuff we don't need
<g_bor>hello guix!
<janneke>hey g_bor!
<g_bor>We actually confirmed with the Outreachy organizers that the video documentation project is ok.
<g_bor>However we should get the proposal ready.
***jonsger1 is now known as jonsger
<g_bor>We have also been notiifed that this project might not be ok for someone with a low bandwidth connection.
<civodul>g_bor: yup, i saw this message, that's a valid point
<civodul>though the proposal remains valid
<g_bor>I believe that this kind of project should be doable even if there is low bandwidth at the intern's site, as these kind of video can be genetated in a reproducible way from much less data.
<civodul>probably, yes
<jonsger>janneke: I tried wip-bootstrap and it builds hello successfull :)
<civodul>g_bor: we haven't writtent it down yet, right?
<efraim>Or produced locally, downscaled for review, and then shipped off at higher resolution
<g_bor>civodul: no, we have not written it yet.
<civodul>g_bor: how should we proceed? do you feel like having a first stab at it?
<civodul>i'm happy to help
<g_bor>I might have a look, but I'm not sure about the form yet. I will have a look at the Outreachy site.
<efraim>Speaking of which, anyone know if its illegal to discuss how to ship a package to Sudan? Preseeding that person with sources would probably be the easiest way for them to get guix running
<janneke>jonsger: thanks, and \o/
<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>not sure what that could look like
<civodul>it could be a tutorial on using Guix for some specific activity?
<rekado>re videos: I don’t think the project should involve shipping rendered videos around.
<rekado>the way I see it the videos would be narrated slideshows with occasional animations.
<rekado>much of the work is in preparing the narration scripts and laying out the contents
<rekado>the video could be “assembled” elsewhere
<g_bor>rekado: I agree. Just about what I thought. If even the narration is problematic we can do just the scripting and add the audio later.
<rekado>the biggest drain on bandwidth might be sending audio recordings, but I would not even require the audio to be recorded by the intern.
<rekado>part of a successful project would be to make sure that this approach can be translated easily
<g_bor>The only image, timing and text(or audio) information should be sent around.
<rekado>i.e. to prefer text-based formats and to write simple scripts that combine recorded audio tracks (with timing cues) with rendered slides / animations.
<g_bor>civodul: writing documentation on a task could be one option. If I remeber correctly we even have some documentation related bugs in the tracker.
<divansantana>anyone else here using a dark theme with icecat? Using adwaita-dark, but then some text boxes text is unreadable/invisible. Perhaps because icecat needs updating?
<divansantana>Looking forward to more browser options. Esp next browser and newer firefox/icecat.
<rekado>g_bor: packaging something simple could still be a good first contribution.
<rekado>it ensures that the applicant gets familiar with building a package, communicating over the mailing list, using git, etc.
<rekado>using git is still useful, even for this project, as we may be working on text files collaboratively.
<g_bor>rekado: I agree, I mentioned that. I also included packaging in the possible contributions.
***happy is now known as Guest51223
<g_bor>as for the issue tracker uri, should I add the debbugs on, or
<roptat>hi guix!
<g_bor>hi roptat!
<rekado>g_bor: yes, please use
<civodul>g_bor, rekado: i agree that packaging is still a good first task, *and* it can allow the person to find out what's wrong with our documentation :-)
<roptat>civodul: I found why my program was exiting prematurly: it received a sigpipe. it worked fine after ignoring sigpipes :)
<roptat>fibers documentation has just an example and doesn't seem to discuss it
<roptat>at least the word "sigpipe" appers only in an example
<civodul>the SIGPIPE "problem" is not Fibers-specific though, so in a way, it can't be blamed ;-)
<roptat>can I read about this "problem" somewhere?
<civodul>probably in
<civodul>info "(libc) Operation Error Signals"
<rekado>civodul: I found a problem with “guix pull”
<rekado>civodul: I want to travel back in time to the year 2016 to build an environment in which python2-rpy2 would be usable.
<rekado>so I did guix pull --commit=444464ec28fe63… (commit from 2016) and guix pull crashes: error: %guix-register-program: unbound variable.
<rekado>I guess that’s because the target Guix from 2016 does not contain %guix-register-program.
<ng0>efraim: your local listing of how Wassenar is applied will help, as well as the probably outdated .. at least I guess your concern includes this range of Guix
<civodul>rekado: the opposite: current guix does not have %guix-register-program
<civodul>i'll take a look
<g_bor>ok, I've submitted a proposal for the outreachy project, please make sure to have a look, and if it is good to go, then approve it.
<civodul>excellent, thank you g_bor!
<rekado>g_bor: thank you so much!
<jonsger>amz3: btw, thanks for releasing guile-git 0.1.0. It's now packaged in openSUSE :) it was already before, but from tar is "nicer"...
<Sleep_Walker>mbakke: thanks for chromium!
<xen1>hello i have been tring to install guix distro for a while
<xen1>and getting segfault here and there
<xen1>last time it was
<xen1>.guix-real: segfault at 10.. ip 00.. sp 0.. error 4 in
<xen1>i also get similar kind of error installing perviously
<civodul>hello xen1
<civodul>xen1: how did you install it?
<xen1>i have copy the disk image to flash
<xen1>reboot pc
<xen1>partitioned using parted
<xen1>then configue it
<xen1>then run guix
<xen1>exact command was
<xen1>guix system init /mnt/etc/config.scm /mnt
*davexunit attempts to revive the guile-next package with the latest from guile master
<davexunit>I'll report back in 5+ hours when it's all built hopefully...
<roptat>xen1: what system are you trying to install to?
<nckx>sneebot auto-detects off-line users now? Or maybe always has? Coool.
<davexunit>I think it's a bug in sneek
<nckx>civodul: No useful review from me, but know that your tireless channel work brings much joy into this world.
<nckx>It's not a bug if it works.
*nckx did not check whether it works.
<roptat>I see xen1 online though ;)
<nckx>roptat: Oh, poss'. They were off last I tried to tab them.
<xen1>i got offline
<nckx>Oh, make check: "EXXTT44--ffss ((vvddaa11)):: mo unmteodu fnilteesyds tefm wiilthe soyrdserteed dmdt a modew. Optsith : (null)ordered"
<xen1>it is a intel i7 pc
<nckx>xen1: Is it possible to capture the full error text? Segfaults while installing an OS have always indicated bad hardware for me, but if you always get the exact same error it's probably legit.
<nckx>OK, so pretty new & probably not dodgy...
<xen1>i have changed by hard disk
<nckx>'i7 = new' → I am olds.
<xen1>it 5 years old pc
<xen1>i am not sure what gen it belongs to
<nckx>xen1: Have you enabled substitutes? That might work around the problem for now, by compiling as little as possible.
<xen1>i didn't nothing extra what is written in manual for guix distro
<xen1>there may be some hardware fault that's why i changed my hard disk
<nckx>That's ambiguous, since substitutes are written there but not everyone seems to enable them successfully :-)
<xen1>do you suggest isntall debian first, to check if there is any hardware fault?
<xen1>or restart install guix again?
<xen1>*guix os
<nckx>My 1st suggestion would be to paste as much of the error and preceding output as you can, here or to the mailing list.
<pkill9>is there a way to create a directory in the root of the container during building?
<roptat>not here, paste it on
<nckx>roptat: What I meant but good idea to be explicit. Oh god yes.
*nckx → AFK
<xen1>ok i am going to ssh to my build pc
<xen1>and start installing guix os again
***jonsger1 is now known as jonsger
<civodul>nckx: heh, thanks :-)
<davexunit>has anyone seen "undefined variable gzip" in guix/scripts/pack.scm when compiling lately?
<davexunit>it must be some weird module thing. (gnu packages compression) is included and exports the gzip variable.
<davexunit>and it doesn't seem to be a parallel build issue
<civodul>davexunit: i haven't seen it but there's an old open bug about it
<civodul>with a reproducer
<civodul>i haven't yet taken the time to look into it
<davexunit>I haven't compiled guix from git in awhile, but I did make sure to run 'make clean' first.
<davexunit>thanks, was just looking for it
<civodul>the thing about inferior packages: \o/
<civodul>rekado: for patch series, it would be nice to display the Subject line on pages like the one above
<davexunit>is this a custom issue viewer?
<civodul>(when the subject line is unchanged, it's best to not display it, as is currently the case)
<davexunit>it looks good
<davexunit>I had no idea we had this!
<civodul>it's fairly new!
<civodul>we owe it to rekado
<civodul>guile-debbugs + mumi
<civodul>i think it rocks :-)
<davexunit>it's really nice
<davexunit>what is mumi? google is not giving me the result I'm after
<mbakke>civodul: That inferior example is mind-bogglingly cool. Thank you!
<davexunit>what's the purpose of the inferiors? looks like it's a part of channels
<civodul>thanks mbakke!
<RetardedOnion>how would i create a file in the global profile?
<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
<civodul>xen1: please use a paste service
<civodul>it looks like your system or image is corrupt
<davexunit>civodul: neat, thanks for explaining. guix is really getting some cool superpowers these days.
<roptat>civodul: I'd like to update our ocaml package, but I'm not sure how to proceed
<roptat>most of our packages must still be compiled with ocaml 4.02
<roptat>but others could be upgraded and compiled with ocaml 4.07
<roptat>using 4.07 also means that most packages will now require a new input: ocaml-num
<roptat>it used to be part of the standard library but was removed in ocaml 4.04 or 4.05
<roptat>so simply upgrading ocaml will break all our ocaml packages
<katco>hey all, thought i'd point this out. i haven't read into it too much, but seems neat: (pardon the weird emacs namespacing...)
<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?
<amz3>notice: I lost all my /query
<lfam>katco: I saw your message about the Go update. I'd be happy to help with it
<katco>thanks lfam :)
<katco>i'm reading over submitting patches now
<_tibbe>Hi, clang does not have correct C++ include paths set when used through guix. Is this a known bug/limitation? I can reproduce it and temporarily fix it using CPLUS_INCLUDE_PATH.
*davexunit found a bug in the bootstrap phase of the gnu build system
<lfam>_tibbe: Not sure! If nobody chimes in here, please send a bug report to <>
<lfam>davexunit: What is it? :)
<davexunit>lfam: if the bootstrap file it detects is actually a directory, it throws an error because it tries to read from it.
<davexunit>for example, the guile repository has a directory called "bootstrap"
<lfam>Hm... so if you try to build Guile from the repo, it crashe?
<davexunit>I am overriding the phase to workaround it
<davexunit>the phase needs to be adjusted to detect this case
<lfam>It *might* be too late to fix this in the current core-updates, but that's really up to mbakke, I think
<lfam>It's sort of on the edge in terms of the timeline
<davexunit>yeah it's a rebuild the world change. I'm sure it can wait for the next round. it's an edge case that few will run into.
<davexunit>and when you run into it it's easy to work around it
<davexunit>but I am *finally* beginning a guile-next build from the latest in master.
<lfam>Awesome :)
<davexunit>which means in 3+ hours I should have guile with JIT to try out.
<davexunit>I hope the build will complete. I'm worried my laptop will overheat.
*janneke finished touching all `package-with-explicit-inputs' bootstrap packages and goes to rebase wip-bootstrap onto core-updates
<janneke>rebase rebuild world
<janneke>and pray no extra work comes from it...
<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>it applies to what follows it, so spacing comes before
<civodul>well, that's a convention
*thorwil conventionalizes code
<thorwil>got resynthesizer configure to succeed until "checking for gimp-2.0 >= 2.2.0 gimpui-2.0 >= 2.2.0... no"
<thorwil>the only mention of "gimpui" i find in gimp.scm is in a comment
<thorwil>actually, in the entirety of guix/gnu/packages/
<civodul>"ls $(guix build gimp)/lib/pkgconfig" shows guixui-2.0.pc
<civodul>what does config.log say?
<thorwil>wasn't "guix build --log-file gimp-resynthesizer" the way to get that log?
<katco>lfam: cool! yeah i've hit a few new issues with go1.11, but not too many. then again, i could be doing this completely wrong o.0
<lfam>civodul, thorwil: That command shows gimpui-2.0.pc, not guixui-2.0.pc :)
<lfam>katco: Probably not completely wrong :)
<katco>lfam: also, as a project, does guix favor keeping multiple minor releases around? as a dev i appreciate it for toolchains since $WORK stuff often lags behind releases
<lfam>So far I've been doing most of the Go work in Guix and I don't even write Go
<thorwil>lfam: to be honest, that command started a lot of work and saw an early ctrl-c :/
<lfam>katco: Hm, it really depends on the cost of keeping them around and what people say they want. Basically, it's up to us :)
<katco>lfam: you will probably enjoy go1.11 which adds support for modules which is a way to pin deps with their path, version, and -- when a version isn't available -- their commit hash
<katco>it will make writing a go importer a lot easier i imagine
<civodul>lfam: oops, good point :-)
<lfam>katco: For Go, so far I've kept the latest Go version that works in the Guix go-build-system, while also trying to offer newer versions
<lfam>katco: Yes, that will be great for us and for everyone. The Go dependency story so far has seemed pretty weak
<katco>lfam: we might consider tracking go's support window which encapsulates a set of releases
<lfam>katco: I keep up with the Go release schedule. IIRC, the previous release is supported until it becomes the 2nd previous release
<lfam>So, there are always two supported versions
<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
<lfam>So, right now we are using the unsupported Go 1.9 to build packages :/
<thorwil>--log-file seems to make no difference to guix build, here 0.o
<lfam>thorwil: What do you mean? It doesn't return a log file?
<thorwil>lfam: no apparent difference in text output and no trace of a log file
<lfam>thorwil: What command did you run?
<katco>lfam: i was having trouble determining which version we were using. it seemed like some stuff with 1.4.3 to build
<lfam>katco: Can you offer more details? The only use of 1.4.3 should be to build later versions of Go itself
<katco>lfam: i have to go do $WORK stuff for awhile, i'll try and produce a patch either tonight or tomorrow
<thorwil>first `guix build --log-file gimp-resynthesizer` then `guix build gimp-resynthesizer --log-file`
<lfam>katco: Cool, see you later!
<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: Hm... looking
<janneke>*packages that use package-with-explicit-inputs
<civodul>janneke: great, thanks a lot for your patience
<civodul>i know it's already been so much work, i feel bad asking for more
<janneke>i still see differences in native x86 vs -s i686-linux, from static-bash-for-glibc onwards
<civodul>hmm ok
<janneke>i'm happy to do this, esp. as long as i get so much help!
<lfam>civodul: Can you give an example command to reproduce what you are seeing?
<janneke>i suspect the (let ((gcc (cross-gcc-wrapper ...))) but i don't see a way to fix it
<janneke>anyway, full mail later
<civodul>lfam: in guix/scripts/pull.scm, comment out the call to honor-lets-encrypt-certificates!; then unset SSL_CERT_{FILE,DIR} and run ./pre-inst-env strace -o log guix pull
<janneke>hmm, /me got an idea -- thanks for listening!
<davexunit>damn... 2 hours later... guile build failed because of a test failure :(
<davexunit>well... if anyone else wants to take this over maybe I can post a WIP patch
<janneke>sometimes you'd just want to say: oh wait--i didn't care *that* much about all tests pass...before the result is gone
<davexunit>heh yeah
<davexunit>2 hours is too long of an iteration time for me to deal with debugging this
<rekado>civodul: re guix pull to pre-2018: for this case I’ll just use Guix from git then. That’s fine. Thanks for checking!
<janneke>i heard civodul has a time machine that goes ~6 months back
<civodul>rekado: you'll also need Guile 2.0
<civodul>the issue is that back then things were not "bootstrapped", they relied on whatever Guile and packages provided by the surrounding Guix
<civodul>davexunit: oh? was it the gzip issue you mentioned earlier?
<davexunit>civodul: no I got around that by sheer chance. I pulled some new commits, ran 'make clean-go', and this time I was able to compile.
<davexunit>but I'm trying to build guile with jit from master
<civodul>oh cool
<davexunit>the build itself completed without an issue, but the test suite fails so there goes the 2 hours spent building.
<davexunit>tweaking random stuff and then waiting 2 hours to see if it works doesn't sound particularly appealing to me right now
<janneke>*woot*, i fixed static-bash-for-glibc, now all diffs between native x86 and --system=i686-linux are gone
<davexunit>popen.test and ports.test fail :(
<civodul>davexunit: oh yeah, there's tests/pack.scm which needs skipping
<civodul>i was looking at it too
<rekado>davexunit: debugging is easier with “guix build -K”, and then running the tests in “guix environment’
<davexunit>rekado: yeah, but I have to wait another 2 hours to get back to that point
<davexunit>it took me a little while to get the bootstrap phase figured out, and now I've just run out of time for today
<janneke>hi g_bor!
<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`
<civodul>lfam: oh ok, thanks for checking
<civodul>somehow i always thought openssl defaulted to /etc/ssl/certs
<civodul>unlike GnuTLS, for which you have to set the default at configure time
<rekado>g_bor: I’m about to approve the project proposal now. I just have a couple of comments. Do you have a few minutes?
<lfam>I didn't dig very much but it seems undocumented in 1.0.2, although 1.1.1's docs mentioned it:
<lfam>I think that OPENSSLDIR defaults to /usr/local/ssl unless it's set explicity (--openssldir) or implicitly (--prefix) when configuring the build
<lfam>That's for 1.0.2
<lfam>So, we could set --openssldir if we wanted to, but I don't think there is a good value that would work on multiple distros
<civodul>right, the status quo is probably ok
<civodul>but it does mean that we must adjust 'guix pull' to use /etc/ssl/certs/ by default
<rekado>setting the value to that used by a popular distribution (family) could be a big improvement, though.
*janneke writes another two fixup commits that could be squashed later, oh well
<lfam>Debian uses /etc/ssl/certs AFAICT. It would be worth checking if Ubuntu inherits that or not
<lfam>If the Fedora family does the same thing, that's a pretty good default
<rekado>on CentOS 7 it’s /etc/ssl/certs/
<rekado>the bundle file name differs between the Debians and Fedoras
<rekado>(it’s /etc/ssl/certs/ca-bundle.crt on Fedora, but something longer on Debian)
<rekado>g_bor: I approved the project proposal, but it would be great if we could flesh it out some more.
*janneke writes another fixup commit
<rekado>g_bor: e.g. to note the intended target length of each video (around 3 minutes), and a few more details on milestones that should be reached.
<rekado>I still wonder why I cannot get a substitute for a package that has already been built on berlin.
<rekado>it’s that core-updates wayland: /gnu/store/f5zpqnlfcfpa8n8dpjicf8bjdgb47flf-wayland-1.16.0.drv
<rekado>I can’t build it on the institute’s central Guix because the tests fail when NFS is involved.
<rekado>it’s right there on berlin, though, and I regularly fetch substitutes from there.
<janneke>rekado: is there a way to be absolutely sure that the package on berlin is a proper substitute for what you are trying to build?
<janneke>a only ever so slightly "different" pacakge is not a substitute...
<civodul>rekado, lfam: i went ahead with this change:
<civodul>not ideal because it's limited to 'guix pull'
<rekado>janneke: I used ‘guix build -d wayland’ on both machines and the derivation is the same.
<civodul>but it's an improvement
<rekado>civodul: looks good. Thanks.
<janneke>rekado: hmm, that sure sounds convincing...
<lfam>civodul: So the effect is that le-certs is only used when SSL_CERT_FILE, SSL_CERT_DIR, and /etc/ssl/certs do not exist?
<lfam>I guess that is what the commit message says, so my reading of the code must be correct ;)