IRC channel logs


back to list of logs

<davexunit>hello hackers
<paron_remote>hello davexunit
<davexunit>paron_remote: hey!
<paron_remote>davexunit: I'm getting dragged into extra contracting this week so I haven't gotten on testing the guix container stuff as fast as I hoped :X
<davexunit>paron_remote: no worries!
<davexunit>2/15 patches in master ;)
<paron_remote>well "dragged into" for a client that pays well and demands that I only write free software, and because I'm going to a conference in a few weeks so I need to make up hours, not the worst circumstance ;)
<paron_remote>davexunit: whoo!
<davexunit>paron_remote: yeah that sounds pretty good!
<davexunit>very nice contracting terms.
<davexunit>usually people aren't demanding that you only write free software.
<paron_remote>davexunit: yeah, Open Tech Strategies, great people
<paron_remote>the CEO was one of the main subversion authors :)
<davexunit>oh neat
<paron_remote>so it's nice that the highest level or the org also knows what makes and doesn't make technical sense generally when we talk about things :)
<davexunit>yeah that sounds very nice
<davexunit>mark_weaver: if you get a second, could you tell me the output of 'uname -a' on your lemote?
<davexunit>I want to get proper utsname:machine string for the mips64el arch
<davexunit>get the*
<mark_weaver>davexunit: what is this for?
<mark_weaver>"uname -m" outputs "mips64"
<davexunit>mark_weaver: perfect, thanks. it's so I can get right syscall ID for 'clone'
<mark_weaver>okay, we'll want to make this more portable at some point.
<mark_weaver>matching strings against "uname -m" output is *very* skanky :-/
<mark_weaver>but for now it's fine :)
<davexunit>unfortunately the syscall id is a C preprocessor define
<davexunit>so I don't know of a better way right now.
<davexunit>maybe a small c program could be run at configure time that outputs the value of __NR_clone as part of processing one of .in files.
<mark_weaver>davexunit: it's fine for now. I don't want this to distract from the important container work you're doing. we can improve the clone wrapper any time.
<mark_weaver>wip-container is *very* exciting work :)
<davexunit>I'm glad that people seem to be excited about it.
<davexunit>it's been a really great learning process.
<mark_weaver>probably 'clone' should be in guile core.
<mark_weaver>it may be that we need to handle stacks specially with the garbage collector anyway.
<mark_weaver>*hand waving*
<davexunit>I've been waiting to see if that would be the case, but primitive-fork is doing a verrry similar syscall.
<davexunit>I just add namespace flags.
<davexunit>we'll see. :)
<crocket>mark_weaver, It'll take many days for guix people to accept packages. Until then, I want to maintain my own repository and use other third party repositories.
<crocket>If packages were accepted automatically, I wouldn't worry.
<davexunit>we certainly cannot add things automatically. we have standards, after all.
<crocket>Does guix have third party repos as ubuntu has ppa?
<mark_weaver>crocket: no
<crocket>ACTION fizzles
<davexunit>crocket: you can install your own packages that aren't in upstream guix easily, though.
<davexunit>we don't have the same notion of a repo that traditional distros do.
<mark_weaver>the package descriptions are maintained together with the support infrastructure, in the same git repo, just like linux (the kernel) maintains drivers together with the support infrastructure.
<crocket>There will be people whose packages are not accepted due to lack of manpower or guix policy.
<mark_weaver>crocket: guix policy, that's the crux of this, I think.
<mark_weaver>you want third party repos with non-free software
<mark_weaver>am I right?
<mark_weaver>so what's the issue?
<crocket>I want third party repos that contain packages guix people had little time to look at.
<ijp>so maintain one
<davexunit>you'll want to maintain your own package modules on your system and set GUIX_PACKAGE_PATH to point to them.
<crocket>Why is it monolithic?
<mark_weaver>crocket: so far it has not been a problem. why don't we cross that bridge when we come to it?
<mark_weaver>crocket: the same reason that Linux is monolithic.
<crocket>I don't know the reason that linux is monolithic.
<davexunit>crocket: it eases maintenance.
<mark_weaver>so that the drivers and the functions that drivers use to interface to the kernel can be evolved.
<mark_weaver>the alternative is to try to maintain stable internal APIs, which turns out to be a nightmare over time.
<codemac>To put it lightly - arch lasted a long ass time without decent support for these kinds of things, and GUIX_PACKAGE_PATH + setting up you're own source for alternates (like is done with hydra today) is probably good enough(tm) to do what you want.
<crocket>hydra? a substitute repo?
<davexunit>I suppose there's some new terms you need to familiarize yourself with in order to understand what we mean.
<davexunit>hydra is, our build farm.
<davexunit>it serves 'substitutes', which are pre-built binaries, the results of building one of our package recipes.
<davexunit>however, guix is *not* a binary-based distro, but guix will let you authorize (or another server) to download pre-built binaries if they are available.
<davexunit>when a substitute is unavailable, guix builds it from source.
<mark_weaver>supporting alternate build farms is no problem at all. we intend to do that.
<mark_weaver>but guix (the package recipes plus the support code for those package recipes) is a monolithic project, in one git repo.
<mark_weaver>if you want, you can create your own branch or fork of guix, in another repo.
<mark_weaver>linux also has lots of branches for different subsystem maintainers to work on things before upstreaming to the main repo.
<mark_weaver>but one way or another, the packages stay together with the support code for those packages, so that we can evolve it all together and make changes to the way packages are written. that's flexibility that we would be foolish to give up, especially at this early stage in our project.
<mark_weaver>I myself have my own private branch of guix, and that's the one I use.
<crocket>I figured out that getting a third party repo is as easy as just cloning the repo and pulling changes.
<crocket>However, I'd have to add them to GUIX_PACKAGE_PATH manually.
<davexunit>I have my own "repo" (which is just a git repo with scheme code) at ~/Code/guix-custom
<davexunit>so I do: export GUIX_PACKAGE_PATH=$HOME/Code/guix-custom
<davexunit>and I'm good to go
<crocket>Does GUIX_PACKAGE_PATH support multiple repos?
<davexunit>it's a path, which means its a colon delimited list, much like $PATH
<crocket>You say it's scheme.
<crocket>I think it's guile.
<davexunit>Guile Scheme, to be precise.
<crocket>I want to switch to guix in the near future because pacman and AUR are resistant to automation.
<crocket>I want to fully automate system configurations.
<davexunit>guix will certainly allow you to do that.
<davexunit>just be aware of the paradigm shift. our system can be confusing to newcomers that are expecting more-or-less a traditional package manager with some added goodies.
<davexunit>nice things.
<crocket>Does it have less things than ArchLinux?
<davexunit>we have less packages right now, but our package manager and associated utilities are more featureful.
<crocket>Oh, there's lack of AUR.
<davexunit>well, no, that's what the GUIX_PACKAGE_PATH is about. *anyone* can just create a git repo or something with packages and people can collaborate.
<crocket>For guix to really take off, guix people will have to accept packages without much filtering.
<davexunit>I disagree.
<crocket>They need a tendency to just accept packages...
<crocket>ZeroMQ wes built on the principle of accepting commits that pass tests, and it is still incredibly stable.
<davexunit>but it's not enough that the code merely works. there's things that we need to check for that cannot be automated.
<crocket>like what
<davexunit>such as: is the license on this package recipe correct?
<davexunit>is this really free software?
<codemac>Dude, as a former arch dev, trust me, every package that is accepted into the arch repos is manually reviewed for correctness.
<davexunit>then there's code style guidelines
<crocket>codemac, AUR is not.
<codemac>aur doesn't even ship packages crocket, it's merely sharing PKGBUILD
<davexunit>I think you're missing the point that *anyone* can make their own AUR equivalent
<davexunit>and in fact it's much easier with guix
<crocket>Sharing third party repos would be beneficial.
<ijp>go nuts
<davexunit>alright, 7/15 patches pushed to master.
<davexunit>now for the hard stuff.
<davexunit>actually, 9/15
<davexunit>*now* the hard stuff
<sir123>Hey guys, I got a running system :) But I can't build icecat 31.7. It keeps reporting an error in the 'compile' stage. I can't find the point that makes it fail. Can I get some advice?
<rekado_>sir123: do you not see any build logs at all?
<sir123>It takes a good hour to get to the build termination, it's running atm
<sir123>In other news, what's going on with the gnunet_bot?
<sir123>Ok, I have a failure
<sir123>Since it's been running multicore, I can't tell which exact file caused the failure
<taylanub>rekado_ & others: it sounds like Guitarix are uninterested in changing their project page; they will continue to refer to all GNU/Linux distributions as "Linux flavours". in that case should GuixSD be listed there at all?
<sir123>but, first guess is the file '/icecat-31.7.0/content/svg/content/src/nsSVGViewBox.cpp', but I can't see the error itself
<rekado_>sir123: try to search the output for "error". Since compilation is done in parallel by default, the actual error could be further up.
<rekado_>(This is where shell-mode in Emacs is extremely useful, as the console output is just text in a regular buffer, so it can be searched easily.)
<sir123>a 'Find' search in xfce4-terminal only reports the -Werror flags passed to g++, which is useless
<sir123>but i've hit the limit in the terminal
<sir123>i'm running the build in the emacs shell, but it takes an hour to compile unfortunately
<rekado_>you could also write the logs to a file with "tee".
<rekado_>and maybe you could get the build log with "guix build --log-file icecat", but I've never used that and I'm just guessing.
<sir123>Alright, I found the issue. Trying to compile GNU icecat 31.7.0 fails because of the file VP8TrackEncoder.cpp in /content/media/encoder fails because it has undeclared variables. What should I do?
<sir123>The variables seem to be PLANE_Y, PLANE_U and PLANE_V. They are undeclared. I cannot compile IceCat 31.7. What should I do?
<sir123>What is the bug severity on a package like IceCat failing to compile?
<sir123>I can report that my GuixSD system is failing to build GNU IceCat 31.7 because of the file icecat-31.7.0/content/media/encoder/VP8TrackEncoder.cpp complaining about not having IMG_FMT_I420, PLANE_U, PLANE_Y, PLANE_V.
<sir123>When given the command 'guix package -i icecat --no-substitutes'
<sir123>What can we do?
<sir123>Is there something I'm missing? I'm looking at the build log right here and it says that IMG_FMT_I420, PLANE_U, PLANE_V and PLANE_Y are not declared in this scope. What do I do?
<Jookia>sir123: do you have ffmpeg/libavconv?
<sir123>No, but shouldn't it be set up as a required package?
<Jookia>sir123: yeah it probably should, i've done some vague programming and maybe remember those symbols being from libavconv
<Jookia>sir123: or perhaps it wants libvpx given it's from VP8
<sir123>I'm installing ffmpeg now
<sir123>I can rerun the build with ffmpeg
<Jookia>sir123: it may actually be libvpx
<sir123>Should I install libvpx first?
<sir123>So I install libvpx, then rebuild and report results?
<Jookia>sir123: i'm not sure, add it as a build depend and report results
<rekado_>you don't need to install anything first to build something else.
<rekado_>if this is failing and you have a good snippet of the build log I'd suggest sending a bug report or to ask for support on guix-devel.
<rekado_>taylanub: re Guitarix: thanks for trying!
<rekado_>ACTION goes afk for a while
<davexunit>morning guix
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, ArneBab_ says: we discussed during the last few days. Now the important part to stabilize the non-Github workflows is that people actually use them.
<ArneBab_>^ use the non-Github workflows for SRFIs
<davexunit>ArneBab_: progress, anyway. glad that happened.
<ArneBab_>Jookia: Scheme Request For Implementation:
<Jookia>ArneBab_: non-github workflows?
<ArneBab_>Jookia: see
<civodul>hey there!
<davexunit>yo civodul
<civodul>maybe an example to follow:
<civodul>for all these years they had been supported entirely by institutes and companies
<davexunit>yeah, maybe we need a foundation for ourselves
<davexunit>Nix always seemed pretty well funded
<davexunit>especially compared to us. :)
<civodul>that's not difficult ;-)
<Jookia>guix - now funded by google?
<Jookia>2016 goal
<davexunit>we're running on paper cups and string in comparison
<taylanub>civodul: hi! Guitarix seems intent on calling GNU/Linux distributions "Linux flavours". would it be better for GuixSD not to be listed at all on their project page, instead of as a "Linux flavour"?
<taylanub>mark_weaver: ^ opinions welcome
<davexunit>civodul: 9 container patches down. :)
<civodul>davexunit: yay!
<civodul>all tests pass here
<civodul>taylanub: well, if that's really their intent (as opposed to just them following what everyone else does), then maybe
<civodul>bavier: the 'guix build hydra' slowness is due to the O(n²) delete-duplicates in transitive-inputs
<civodul>bavier: i hacked up a linear delete-duplicates using (guix sets), but it slightly slows down simpler cases
<davexunit>ooh that sounds nice
<davexunit>I always feel a little weary when I use delete-duplicates
<civodul>yeah i should have been more wary actually ;-)
<civodul>the thing is, in most cases n is small
<civodul>but for Hydra, with all the propagated inputs, n is quite big
<civodul>namely, (bag-transitive-inputs (package->bag hydra)) returns a list of 42211 items...
<civodul>sounds a bit insane
<phant0mas>sneek: later tell civodul with dladdr working only for dynamic linked binaries and argv[0] not a reliable solution what are our options?
<phant0mas>sneek later tell civodul with dladdr working only for dynamic linked binaries and argv[0] not a reliable solution what are our options?
<phant0mas>sneek is dead :P
<taylanub>I wonder why "guix environment guix --pure -E make" downloads some guix-...-checkout item? it also downloaded gcc-...-boot0 or so.
<phant0mas>mark_weaver: what will the wrapper do?
<mark_weaver>phant0mas: the wrapper would set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH
<mark_weaver>similar to the wrappers created by 'make-wrapper'
<mark_weaver>the wrapper would be a shell script, and the shebang on the shell script would have to include the absolute path to the bootstrap bash.
<mark_weaver>the wrapper couldn't be included in the actual bootstrap guile. it would have to be created by the build process after unpacking the bootstrap guile.
<mark_weaver>it would use the 'snippet' argument to 'package-from-tarball' that I created for '%bootstrap-coreutils&co' in bootstrap.scm
<mark_weaver>see how that package patches the shebangs for 'egrep' and 'fgrep' after unpacking the tarball?
<mark_weaver>hmm, it might be a little trickier with the bootstrap guile though, since the bootstrap guile is used to run the snippet.
<mark_weaver>so we can't actually do it that way. hmm..
<mark_weaver>well, now I'm not sure how best to proceed.
<mark_weaver>I wish civodul were here
<mark_weaver>oh, there's the '' shell script in 'raw-build'. maybe that could be enhanced to do this.
<mark_weaver>to make the wrapper, that is.
<mark_weaver>hmm, this is tricky
<mark_weaver>okay, I think this is doable. I'm working on it now.
<phant0mas>okay I will see what I can do as well
<phant0mas>thank you for helping me on this :-)
<rekado_>I can no longer use "guix environment -l env.scm" for guix-web. Seems that "guix environment" no longer likes (source ".").
<rekado_>The error: guix/derivations.scm:578:7: In procedure derivation->output-paths:
<rekado_>guix/derivations.scm:578:7: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): "."
<rekado_>Have to go now, but I should be back to answer questions in a couple of hours.
<davexunit>rekado_: looks like a string literal in a package's 'source' field is no longer acceptable
<davexunit>rekado_: I've been thinking about ways around this hack, anyhow.
<davexunit>I'd like to have the source field reference a tarball at the root of the source tree, as built by 'make distcheck'
<davexunit>and a helper procedure that computes it's hash to create the correct <origin> object
<mark_weaver>phant0mas: okay, I think I have something here that should work. now to test it...
<mark_weaver>oh, well, it will be a little trickier than this. I have to use the bootstrap guile to create its own wrapper :)
<mark_weaver>it's definitely doable, I just have to get it done...
<mark_weaver>phant0mas: here's what I came up with:
<mark_weaver>with that in place, guile-relocatable.patch should no longer be needed.
<mark_weaver>I'll post it to the list as well...
<phant0mas>I am trying it now
<mark_weaver>phant0mas: that patch will cause a full rebuild of everything, so I would first create a new bootstrap guile *without* guile-relocatable.patch and also without my patch applied.
<mark_weaver>and then, once you have that new bootstrap guile, then apply my patch and try using it to bootstrap the system on hurd.
<mark_weaver>in other words, apply that patch only to the hurd system, not to the system you use to cross-compile the guile bootstrap binary.
<mark_weaver>s/the hurd system/the guix running on hurd/
<davexunit>reading this article has informed me of where the Nix folks get all their names from:
<mark_weaver>ah, interesting!
<mark_weaver>So Nix and Hydra are two of Pluto's moons.
<mark_weaver>ACTION goes afk for a while...
<davexunit>and Charon is the former name for NixOps
<zacts>oh wow
<zacts>didn't realize this about pluto in regards to nix
<phant0mas>mark_weaver: I am waiting for the rebuild of the bootstrap-tarballs and I will report back
<phant0mas>in the meanwhile I am tidying up my local repo because it's a mess
<davexunit>new fully free distro in the house :)
<zacts>what distro is this? proteanOS?
<zacts>ACTION looks
<zacts>oh indeed
<zacts>I see
<mark_weaver>the creator of proteanOS hangs out on #libreboot
<francis7>mark_weaver, and also #proteanos-dev
<francis7>that's the proteanos channel
<mark_weaver>pehjota, if I'm not mistaken
<francis7>mark_weaver, yes, it's pehjota
<mark_weaver>francis7: thanks!
<mark_weaver>phant0mas: fwiw, I successfully built bootstrapped using that patch and built GNU hello on x86_64-linux.
<mark_weaver>s/built bootstrapped/bootstrapped/
<mark_weaver>I suspect the plan will be to apply that to the next core-updates cycle and remove guile-relocatable.patch (on _all_ platforms)
<mark_weaver>hi paron_remote!
<davexunit>yo paron_remote
<paron_remote>hi mark_weaver :)
<paron_remote>hi davexunit !
<paron_remote>davexunit: nice, a link in your patch :)
<paron_remote>ACTION trying to catch up with what has been merged and hasn't for the container stuff!
<davexunit>all of the new syscall wrappers are merged
<davexunit>but the actual container stuff isn't.
<davexunit>ugh, I'm still getting that transient test failure with the container-excursion test.
<davexunit>it's killing me.
<paron_remote>davexunit: wow `guix environment --container' is awesome
<paron_remote>davexunit: there's been a lot of times I've wanted to test some software I don't totally trust
<davexunit>I really want to have that here on my work computer so I can build environments with only guix stuff.
<davexunit>inevitably, I try to use the Ruby package manager and it uses compilers and stuff from the host system
<davexunit>and everything blows oup
<davexunit>so, being able to just launch a container will ensure that nothing from the host is accessible
<davexunit>and I should be able to build happy little ruby environments
<davexunit>this test is such a pain. just passed 34 times in a row before the failure.
<davexunit>sleep 250ms makes it pass consistently
<davexunit>it's some sort of race condition. not sure if it's okay to leave the sleep in and move on with life.
<davexunit>oh wow, that didn't even work. it failed after the 136th try.
<mark_weaver>davexunit: where did you add the sleep?
<davexunit>mark_weaver: in the excursion process, before I tested for namespace equality
<davexunit>I've also tried adding before creating the excursion process
<davexunit>there's gotta be some resource that I need to wait for
<mark_weaver>and when it fails, what goes wrong exactly?
<davexunit>readlink("/proc/2/ns/user", 0x8ed0d0, 100) = -1 EACCES (Permission denied)
<davexunit>something like that
<davexunit>a process should be able to read it's own proc files
<davexunit>but my concern is that something is wrong with the mount namespace
<davexunit>and it's reading the /proc of the parent pid namespace, where the process is not pid 2.
<davexunit>I haven't been able to track down any documentation about having to wait for some resource after the setns call
<mark_weaver>when you say "something like that", what does that mean? is that error you pasted from a real strace?
<davexunit>that's from a real strace
<mark_weaver>well, it sounds like that error happens before you call 'setns' at all.
<davexunit>it happens after.
<mark_weaver>where is the call to 'setns' that happens before this?
<davexunit>I call setns 6 times, once for each namespace, and then fork.
<davexunit>it's in the container-excursion procedure in gnu/build/linux-container.scm
<davexunit>in my test, the thunk I pass to it forks
<mark_weaver>so this error doesn't happen from the calls to 'call-with-input-file' in that procedure?
<davexunit>those work just fine
<davexunit>my test tries to call 'readlink' on its own namespace files
<davexunit>to compare them to the containers, whose namespaces were captured earlier.
<mark_weaver>well, I seem to be as useless today on this problem as I was last time :-/
<davexunit>it's alright. it's a tricky one.
<davexunit>the answer will become obvious at some point...
<davexunit>perhaps it's a file descriptor issue.
<mark_weaver>it might be worth trying to write a minimal C program that exhibits the same problem, and then submit it to the Linux developers as a bug report.
<davexunit>right now i have a hard time believing that it's a Linux problem.
<mark_weaver>and if you can't make it exhibit the same problem, that will also be interesting.
<davexunit>but if I can reproduce it in C.
<davexunit>that would make me think otherwise.
<davexunit>gotta go.