IRC channel logs
2015-04-22.log
back to list of logs
<angelic_sedition>I'm having trouble getting guixsd installed in virtualbox. "guix system init..." says that it completes successfully, but when I reboot I get a kernel panic and just before it 'ERROR: In procedure state: No such file or directory: "/etc/static/localtime"'. Any ideas? <angelic_sedition>Also, after "guix system init /mnt/etc/config.scm /mnt", config.scm is still the only file in /mnt/etc. Should there be others? <mark_weaver>angelic_sedition: can you paste your config.scm somewhere? <mark_weaver>a bad configuration can lead to the init process dying, which causes a kernel panic. <mark_weaver>angelic_sedition: when you boot in virtualbox, does it start by running our grub menu? <mark_weaver>are you are loading our kernel and initrd directly in some other way? <mark_weaver>include the config.scm, the exact command you used, and the version of 'guix <mark_weaver>btw, we provide a 'guix system vm' command to build VM images for qemu. <paroneayea>interesting... can you only have python2 or python3 in a single guix profile? <mark_weaver>iyzsong: I see you pushed those commits to 'wip-glib'. is there anything else you'd like to push before I start hydra building it? <iyzsong>mark_weaver: Yes, I'd like to remove all the 'CC=gcc' setenv calls <iyzsong>mark_weaver: Yes, with the new gobject-introspection-cc.patch. <paroneayea>very close to havinga guile-minikanren package... <paroneayea>I got it to pull it down, but not sure where to have it copy the stuff after it does so <paroneayea>I know I want it to end up on the guile load path <mark_weaver>paroneayea: did you use ijp's port of minikanren to guile? <paroneayea>mark_weaver: yes that's what I'm attempting to package <paroneayea>however I don't know where the scripts would get copied in the #:builder build expression <mark_weaver>a module named (foo bar) should be put in <out>/share/guile/site/2.0/foo/bar.scm <paroneayea>mark_weaver: and is there a way to copy a directory? I see ways to copy individual files <mark_weaver>paroneayea: see 'copy-recursively' in (guix build utils) <paroneayea>mark_weaver: also do you think guile-minikanren is a good name for the package? <paroneayea>there is a mainline "minikanren" which is why I am hesitant to use that <iyzsong>mark_weaver: done. please start build it on hydra ;-) <paroneayea>btw, I have it so that it installs to the right place <paroneayea>but I can't get it to work in guile still it seems <paroneayea>cwebber@earlgrey:~/devel/guix$ ls ~/.guix-profile/share/guile/site/2.0/ <paroneayea>I guess there is no guile-style module definition <mark_weaver>paroneayea: hmm, we probably shouldn't be putting things into the top-level namespace like that. <mark_weaver>and is that where guile-json installs by default also? <paroneayea>mark_weaver: I'm not sure what top-level namespace means <mark_weaver>I mean that modules should generally have at least two components <paroneayea>mark_weaver: I think both guile-json and minikanren do as above, just that minikanren uses (import) <mark_weaver>so, in the upstream guile-json, the module name is just (json) ? <paroneayea>mark_weaver: there is (json builder) and (json parser) and (json syntax) <paroneayea>the json.scm does nothing other than export modules tho <mark_weaver>blah, I'm going to have to talk to the upstream guile-json author about it. <mark_weaver>error: Failed to execute child process "cc" (No such file or directory) <iyzsong>mark_weaver: oops, thanks for notice. let me try to fix it. <iyzsong>while I'm at it, I'll bump gtk+, gtkmm to latest version. <rekado_>new feature in R 3.2.0: "R CMD INSTALL gains an option --built-timestamp=STAMP allowing 100% reproducible package building, thanks to Dirk Eddelbuettel." <paroneayea>hey davexunit, maybe interesting to you (I still have to post it to guile-devel, will do after I finish getting ready for the day) but: <jrandall>I'm struggling to get guix working from behind a firewall that requires outbound http/https traffic to go via an http proxy. I've spent the past few days developing fixes that make the core of guix work with a proxy (see patches at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20402), but now I'm stuck because the bootstrap guile is only version 2.0.9, and 2.0.10 or greater is required for proxy support. <jrandall>Can anyone advise me on how I can move to a newer version of the bootstrap guile? <bavier>jrandall: have a look in gnu/packages/bootstrap.scm <jrandall>I was just poking around in there - I see that for armhf it is already using 2.0.11 <bavier>you may be able to make 2.0.11 the universal version <bavier>and use 'guix build bootstrap-tarballs' <jrandall>so far I haven't been able to get `guix build bootstrap-tarballs` working because it seems to use the existing bootstrap guile, but I guess I can try to create the binary tarball manually? <bavier>jrandall: you may need to wait until civodul gets on here... <jrandall>Thanks, I'll keep an eye out... in the meantime I'll keep poking around at trying to create an x86 binary tarball for guile 2.0.11 <jrandall>It looks like guile-bootstrap-tarball defined in gnu/packages/make-bootstrap.scm is relevant, but I'm not sure how to call it <paroneayea>davexunit: others: how do you generally send patches to the list? <davexunit>paroneayea: that or just attach the patch in an email yourself <davexunit>I haven't configured git-send-email to work correctly, yet. <mark_weaver>jrandall: if you replace the bootstrap guile, then you'll need to build *every* package from source code, starting with a bootstrap process not unlike that described in Cross [GNU/]Linux From Scratch. <mark_weaver>jrandall: do you want to be building everything yourself, or do you want to use binaries built by our build farm? <jrandall>mark_weaver: unfortunately, I can't access anything without a guile that supports http proxies so I guess I have no choice but to build them myself? <davexunit>thanks for packaging it! I will enjoy it. :) <mark_weaver>jrandall: there are other options. but first, can you answer my question? <jrandall>mark_weaver: I'd ideally like to be use binaries built by your build farm as well as develop new packages that I build myself <mark_weaver>jrandall: okay, so you shouldn't replace the bootstrap guile. let's find another option :) <jrandall>mark_weaver: ok - I assume eventually guix is supposed to start using the non-bootstrap guile package... is there a way I can get to that point by getting binaries built elsewhere? <mark_weaver>jrandall: this will require some study, and quite possibly civodul knows the answer from memory. <mark_weaver>I'm afraid I don't have a ready answer for you right now. <mark_weaver>jrandall: thanks for your patience, and for working on improving it! <jrandall>mark_weaver: no problem - I suspect not too many people these days are still stuck behind corporate proxy servers (some of our machines are now freed from it, but this particular set is still firmly trapped) <jrandall>In order to use the pre-built binaries from hydra, do we need to keep the default store path as /gnu/store ? <jrandall>mark_weaver: ah, then that explains why I am not getting the substitutes - in that case I will want to be building everything from source <mark_weaver>I should also warn you that the absolute path of the store needs to be kept quite short. <mark_weaver>because absolute pathnames of programs in the store need to be put into shebangs at the top of scripts, and the kernel imposes a severe limitation on the length of those. <mark_weaver>I forget the exact length, but it's quite constraining in practice. <mark_weaver>jrandall: out of curiosity, why can't you put it in /gnu/store ? <jrandall>mark_weaver: Oh, I see - that makes sense. /gnu/store is 10 characters, and I was intending to use one with 20 - is that likely to be too long? <jrandall>I can put it at /gnu/store on some machines on which we have full access, but I was hoping to also use guix on other machines where we only control a mountpoint under /software <mark_weaver>can you use a bind mount to map /gnu to something within /software ? <jrandall>mark_weaver: only on some of the machines - I was hoping we could run it as a non-root daemon user who owns the store on those machines <jrandall>we wouldn't be able to do that on some of the machines, at least not without going through a heavy change request process <mark_weaver>I believe there may be issues with running guix-daemon as a non-root user. in that case it is unable to create a chroot or isolated build environment, and so the builds may pick up things from the host environment and many things may break. <jrandall>an alternative might be for us to provide our users with the guix environment inside containers <jrandall>(inside of which we can operate as root) <jrandall>I see there is a potential GSoC project having something to do with guix targeting containers <mark_weaver>guix-daemon essentially creates containers for doing builds, where only the declared inputs are available to the build process. <mark_weaver>package build systems tend to be resourceful in finding things from the host system though, and if they do, the builds will break. <jrandall>Is there any documentation on how to setup a hydra-like build server to serve substitutes (in case we do want to change the store path and build our own environment)? <mark_weaver>hydra is not yet nicely packaged, but we are working on that. in the meantime, take a look at section 2.3.2 of the manual "Using the Offload facility" <jrandall>Oh, I've just noticed the time - I need to head out but I'll try to come back later this evening <sneek>civodul was here May 07 at 12:12 pm UTC, saying: that's still a good idea anyway ;-). <mark_weaver>Sleep_Walker: gnunet_bot only logs. sneek is the one who will deliver messages and some other things. <sneek>I last saw mark_weaver on May 08 at 08:09 am UTC, saying: sneek: seen mark_weaver. <mark_weaver>Sleep_Walker: can you send mail to 20081@debbugs.gnu.org about it? <davexunit>paroneayea: one thing I noticed about your minikanren patch is that you don't compile the scheme files. I think adding that step would be good. 'guild compile' does the job. <mark_weaver>I never studied that bug, and it's probably more efficient for civodul to look at it. <davexunit>paroneayea: I'll make a reply on list later when I'm at home with a better email setup. <davexunit>I'm very excited to have this packaged, since I just bought "The Reasoned Schemer" this weekend. <paroneayea>davexunit: cool, that makes sense... I should do that. <davexunit>I'll try out the package myself later when I'm on a guix machine. <davexunit>paroneayea: you picked a tricky first package! <mark_weaver>a package without a build system included, it seems. <davexunit>it makes sense because they are just R6RS modules with no ties to any implementation <mark_weaver>maybe we should have a better way of dealing with pure R6RS scheme code. <davexunit>perhaps we could come up with the start of a guile-r6rs-build-system if we wrote a package for industria <davexunit>and see the common code between it and this minikanren package <paroneayea>davexunit: mark_weaver: yeah civodul suggested maybe we could eventually have a r6rs-build-system thing <davexunit>that would be very helpful for libraries like these <davexunit>industria is my next most wanted r6rs package <paroneayea>I didn't realize this was a harder than normal first package :) <paroneayea>okay, so if I was going to compile that though, I'd need the guild command right? <davexunit>so it should be in your build environment already <paroneayea>also, I assume need to copy down the license file, since it's modfied BSD <paroneayea>I was following grue-hunter, but I think that might do the wrong thing <paroneayea>I should throw an error if the "guild compile" fails <paroneayea>I could use "assert" but that requires including (rnrs base (6)) <paroneayea>though I could also just use (if (not (zero? (system* "blah"))) (error "uhoh")) <mark_weaver>paroneayea: it might be simpler to use the 'gnu-build-system' and remove the phases you don't want <mark_weaver>gnu-build-system includes some useful phases, notably one that sets environment variables and paths. <paroneayea>mark_weaver: I could probably do that I guess? I'm also just confused as to why guild isn't there <paroneayea>mark_weaver: also, it's not clear in the docs, do you know what the difference between "inputs" and "native-inputs" is? <mark_weaver>paroneayea: right, it's not on the path. setting path is one of the things done by an early phase of gnu-build-system <mark_weaver>paroneayea: when cross-compiling, e.g. building for ARM on an intel box, native-inputs are built to run on intel, and inputs are built to run on ARM. <davexunit>you get a reference to guild like so: (string-append (assoc-ref %build-inputs "guile") "/bin/guild") <paroneayea>davexunit: yeah I just figured that out, but now I'm getting other weird errors <mark_weaver>right, but there may be other needed variables as well <mark_weaver>I'm one-handed right now. it's hard to do much. one arm holding a baby <mark_weaver>I'm currently trying to get the 'guix' package to build successfully on MIPS and ARM, so that I can make self-contained tarballs for them. <mark_weaver>I'm currently stuck on the fact that 'guix package -A' never prints anything on armhf, because it's not in %supported-systems, which causes one of the tests to fail. <mark_weaver>maybe hydra should have its own variable for %hydra-supported-systems or something? <civodul>mark_weaver: could you add that to %supported-systems? <civodul>we probably need a separate variable for Hydra <civodul>we just need it in build-aux/hydra/gnu-system.scm in fact <mark_weaver>civodul: also, 5763ad9266 does not seem to affect guix package -s at all <civodul>yeah, initially i made the same for -s and -A <civodul>but then thought that this was not ideal for -s <mark_weaver>I do think that we should have a way to find packages even if they aren't supported on %current-system <mark_weaver>I'd been using guix package -A for that, but I can switch to using -s instead. <civodul>i'm looking at the libstdc++ RUNPATH issue, it's terribly annoying <mark_weaver>civodul: another problem I ran into on armhf is that there's a call to (search-bootstrap-binary "guile-2.0.9.tar.xz" ...) in tests/packages.scm, but on armhf it's guile-2.0.11.tar.xz <mark_weaver>I was thinking of just putting a redundant 'match' in there, but it's not so nice. <paroneayea>I kind of wish I could run `guix package --search-paths` in guile <paroneayea>it doesn't actually work though due to the quoting I guess. <mark_weaver>paroneayea: the early phases of gnu-build-system do exactly what you need <mark_weaver>I would recommend just using that build system and remove/replace the phases that don't do the right hting. <paroneayea>mark_weaver: great! (btw the --search-path was about my .bashrc :)) <mark_weaver>well, for one thing it's not a particularly fast operation. <mark_weaver>and it only takes into account things in your user profile, not things in the system-wide profile. <mark_weaver>although really that other problem should be fixed somehow anyway. <paroneayea>maybe guix should write out a standard_env_things thing that should be sourced ;) <mark_weaver>I think there might be a bug ticket discussing this issue. <civodul>mark_weaver: regarding the test, ok for the redundant match (i don't have a better idea right now) <civodul>paroneayea: one can run "eval `guix package --search-paths`" and that kinda works <paroneayea>civodul: maybe it would be nice to have a post-hook for guix package install/remove things that writes source'able files out <paroneayea>I guess that would be upon changing generations and etc too <davexunit>to me, 'guix package --search-paths' is something you run rarely and stuff into your bashrc <paroneayea>what if we end up targeting users who don't ever run the guix cli stuff directly <paroneayea>we'd want a way to have this environment stuff mostly set up for them right? <civodul>paroneayea: i sympathize with the idea that it should just DTRT to make it work out of the box <civodul>however, i can't think of anything "acceptable" that can be done automatically <paroneayea>civodul: not even providing on-profile-change hooks? <civodul>opam (OCaml's package manager) offers to write env var settings in ~/.bashrc, and asks interactively whether the user is ok <civodul>that's fine, but not quitte elegant IMO <davexunit>the problem I see with such a hook is that the process becomes imperative <paroneayea>I don't think writing stuff to ~/.bashrc is good <civodul>paroneayea: what would this hooks be used for? <paroneayea>civodul: so that users can add to their own .bashrc <civodul>and there would be a convention that "env-stuff" files are always created, etc.? <paroneayea>what if you made it more functional in that it happens as part of each generation of profile being built? <civodul>like there could be ~/.guix-profile/the-env ? <davexunit>to complicate matters: what about when you want to also use the current system's paths? <civodul>it is so much better than "eval `...`"? :-) <paroneayea>civodul: <mark_weaver> well, for one thing it's not a particularly fast operation. <paroneayea><mark_weaver> and it only takes into account things in your user profile, not things in the system-wide profile. <paroneayea><mark_weaver> although really that other problem should be fixed somehow anyway. <paroneayea>the top one at least, is one reason why better than eval <paroneayea>though maybe there could be something that does profile merging, I don't know. <civodul>yes there's an open bug for profile merging <paroneayea>at any rate, I wonder if it's hooked into each generation and just always written out <paroneayea>I have no idea how to handle, say, the gnome shell overview. <davexunit>I don't know how to change it without reloggin <paroneayea>I do think this is a critical issue to have a solution to in the long term. I have no idea what such a solution could be though. <paroneayea>in the meanwhile, I mean, I'm okay with doing --search-paths and adding it manually <civodul>paroneayea: but it *has* to be manual, no? <civodul>i guess i don't fully grasp what the problem is <paroneayea>civodul: the problem is that I'd love GuixSD to become a solution to even the non-technically-inclined in the future <paroneayea>and that can't happen if it involves "well, just open your .bashrc ..." <paroneayea>there has to be some automatic way to propagate the current profile's environment requirements to the user's environment <civodul>but the thing is, except on GNU/Hurd (!), we can't change the environment variables of running processes <paroneayea>which is to ship with default environment paths that have all the most commonly changed environment variables in the guixsd already set up <civodul>but on GuixSD, i agree we can (and will) do better <paroneayea>civodul: do you think the "by default you already have all these paths set up to these places" is the best route? <civodul>actually on guixsd /etc/profile already has a bunch of libraries initialized for convenience <civodul>the next step is to auto-generate it <paroneayea>also, I'm not surprised that Hurd has a solution that monolithic kernel systems don't :) <paroneayea>maybe guixsd will be the route to which I actually play with Hurd again. <paroneayea>I feel kind of bad about it. I need to focus on mediagoblin tomorrow <paroneayea>but I feel much better about knowing how guix's packaging works now <civodul>i haven't completely caught up with today's emails <paroneayea>but then davexunit and mark_weaver convinced me to try to get it to compile the .scm files and I went down a deep rathole :) <civodul>i had done too many gcc recompiles in my shell buffer i guess <civodul>and emacs spent more and more time in gc <civodul>and eventually spent all its time in gc