IRC channel logs
2015-07-08.log
back to list of logs
<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 <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 ;) <davexunit>usually people aren't demanding that you only write free software. <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>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>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 :-/ <davexunit>unfortunately the syscall id is a C preprocessor define <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. <davexunit>I'm glad that people seem to be excited about it. <mark_weaver>it may be that we need to handle stacks specially with the garbage collector anyway. <davexunit>I've been waiting to see if that would be the case, but primitive-fork is doing a verrry similar syscall. <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? <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. <crocket>I want third party repos that contain packages guix people had little time to look at. <davexunit>you'll want to maintain your own package modules on your system and set GUIX_PACKAGE_PATH to point to them. <mark_weaver>crocket: so far it has not been a problem. why don't we cross that bridge when we come to it? <crocket>I don't know the reason that linux is monolithic. <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. <davexunit>I suppose there's some new terms you need to familiarize yourself with in order to understand what we mean. <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 hydra.gnu.org (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 <crocket>Does GUIX_PACKAGE_PATH support multiple repos? <davexunit>it's a path, which means its a colon delimited list, much like $PATH <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>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. <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. <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. <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. <davexunit>such as: is the license on this package recipe correct? <codemac>Dude, as a former arch dev, trust me, every package that is accepted into the arch repos is manually reviewed for correctness. <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 <crocket>Sharing third party repos would be beneficial. <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>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>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 can rerun the build with ffmpeg <Jookia>sir123: it may actually be libvpx <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! <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. <civodul>for all these years they had been supported entirely by institutes and companies <davexunit>yeah, maybe we need a foundation for ourselves <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"? <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>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... <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? <taylanub>I wonder why "guix environment guix --pure -E make" downloads some guix-...-checkout item? it also downloaded gcc-...-boot0 or so. <mark_weaver>phant0mas: the wrapper would set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <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>oh, there's the 'build-bootstrap-guile.sh' shell script in 'raw-build'. maybe that could be enhanced to do this. <mark_weaver>okay, I think this is doable. I'm working on it now. <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>with that in place, guile-relocatable.patch should no longer be needed. <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. <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 <zacts>what distro is this? proteanOS? <mark_weaver>phant0mas: fwiw, I successfully built bootstrapped using that patch and built GNU hello on x86_64-linux. <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) <paron_remote>ACTION trying to catch up with what has been merged and hasn't for the container stuff! <davexunit>ugh, I'm still getting that transient test failure with the container-excursion test. <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>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>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. <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 <davexunit>readlink("/proc/2/ns/user", 0x8ed0d0, 100) = -1 EACCES (Permission denied) <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? <mark_weaver>well, it sounds like that error happens before you call 'setns' at all. <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 <mark_weaver>so this error doesn't happen from the calls to 'call-with-input-file' in that procedure? <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>the answer will become obvious at some point... <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.