IRC channel logs
2013-11-03.log
back to list of logs
<jmd>mark_weaver: I don't see any build instructions on either page. <jmd>Oh wait. Two lines: "he build procedure for Guix is the same as for other GNU software, and is not covered here. Please see the files README and INSTALL in the Guix source tree for additional details. " <jmd>Hmm. make check took over 10 minutes, but make installcheck tool less than 3 seconds. <jmd>That is suspicious to me. <mark_weaver>yes, I guess that should be fixed. would you like to file a bug report? <bug-guix@gnu.org> <mark_weaver>"(automake) Basic Installation" says: Presently most packages do not have any 'installcheck' tests because the existence of 'installcheck' is little known, and its usefulness is neglected. Our little toy package is no better: 'make installcheck' does nothing. <jmd>$ guix package --install=hello <jmd>guix package: error: failed to connect to `/usr/local/var/nix/daemon-socket/socket': No such file or directory <jmd>Did I forget something? <mark_weaver>see the Installation section of the manual, specifically "Setting Up the Daemon" and "Invoking guix-daemon" <jmd>I have to leave the guix-daemon running ? <mark_weaver>yes, the guix-daemon is what actually builds the packages. <mark_weaver>that's what allows the builds to be done within an isolated chroot, and yet non-privileged users to be able to ask software to be built, and to install it in their local profile. <jmd>Is guix-daemon supposed to detach itself or must I background it? <mark_weaver>you must background it, or just leave it running in a dedicated terminal (that's what I do, fwiw) <mark_weaver>it occasionally outputs a few lines, so if you background it make sure to redirect the output ports. <jmd>No space left on device! <jmd>Which directory needs the space? <jmd>How can I change that? Or will I have to symlink it to another device? <mark_weaver>as for /tmp, it's probably best for you to arrange to have a /tmp capable of holding at least a few gigs. <jmd>oh! I have about 5MB <mark_weaver>it has to be big enough to hold the build directory of any software you want to build <jmd>does it respec TMPDIR <jmd><mark_weaver> you can make /nix a symlink <jmd>$ guix package --install=hello <jmd>guix package: error: build failed: the path `/nix' is a symlink; this is not allowed for the Nix store and its parent directories <mark_weaver>looking at the code, I suspect that it respects TMPDIR, but keep in mind that has to be set when the _daemon_ is run. <jmd>I'll shuffle some lvm volumes ... <jmd>It would be good if the manual had some recommendations on how much disk space you need in the respective directories. <mark_weaver>keep in mind that /nix/store will get big if you install a lot of software <jmd>So you recommend > 2GB for /tmp and > 10GB for /nix ? <mark_weaver>if you want to build gcc then I think you may need around 4-5 gigs on /tmp. I've forgotten the exact size of the gcc build directory, but it's quite big. <mark_weaver>and for /nix, again, it depends very much on how many packages you build <jmd>guix-daemon could use an option to specify an alternative location for /nix <mark_weaver>actually, these numbers I'm giving you are based on my experiences building on MIPS N32, which might be as much as a factor of 2 off from a build where int/long/void* is 64-bits. <jmd>What's the size of your /nix ? <mark_weaver>that's after systematically trying to build all of the packages in guix, and with some duplications from old versions kept around. <jmd>OK. I'll see how much space I have. <mark_weaver>I started out using many partitions, but some years ago switched to having just one big partition (with the exception of /var/log and maybe /boot), and I've been much happier that way. <mark_weaver>as for /tmp, if it's inconvenient to have a big /tmp, I think it would be okay to prefix the guix-daemon command with TMPDIR=/usr/tmp <jmd>and how do you manage backups? <gzg`>mark_weaver: I do ~30-50GB for / on a box and the rest is /home -- seems to work fairly well. <mark_weaver>well, my method for backups has long been to use rsync with multiple hard-link trees. <mark_weaver>so when I want to make a new backup, I do: cp -al <most-recent-backup> <new-backup-dir>; rsync -aP --delete /just-root/ <new-backup-dir>/ <jmd>I like to keep my "important" stuff on a seperate drive from the rest. <mark_weaver>where /just-root/ is a bind-mounted copy of / (but without any of the mounts) <jmd>That way I can just clone the important partition <gzg`>I just recently moved from rsync to unison, which keeps my files in-sync on both machines, but every to weeks, I plan on rsyning to a 3rd-party drive. <jmd>mark_weaver: That's one option I have been experimenting with. <mark_weaver>well, like I said before, /nix can always be a bind mount. <mark_weaver>it's also possible to build a guix where things will be put somewhere other than /nix/store, but if you do that you won't be able to download any binary substitutes from hydra.gnu.org. instead, you'd have to bootstrap the system from source code only. <mark_weaver>well, to be more clear: bootstrapping from source code only is fine, and in fact I do it myself exclusively. however, I don't recommending changing the prefix from /nix/store to something else, especially if you're just starting out. <jmd>$ guix package --install=hello <jmd>guix package: error: No such file or directory <jmd>Both /tmp and /nix are Huge now. <jmd>It would be really nice if it told me which file or directory doesn't exist. <jmd>When I do "guix build --no-substitutes pspp" I just get lots of lines like: <jmd>acquiring write lock on `/usr/local/var/nix/temproots/21360' <jmd>downgrading to read lock on `/usr/local/var/nix/temproots/21360' <jmd>and finally it seems to use a substitute anyway. <jmd>How can I actually build a package using guix ? <Steap>jmd: by "build" do you mean "install" (as in 'apt-get install') ? <jmd>Steap: Well there is a guix build command, but it doesn't seem to do anything. <Steap>jmd: it literally "builds" the package <Steap>to install it in your profile, use "guix package -i foo" <jmd>So far as I can makeout it simply downloads the package. Even if I pass --no-substitutes. <jmd>Similarly guix package --remove does nothing. <jmd>(but at least it prints "nothing to be done") <jmd>which is incorrect, because the package is still installed. <Steap>so you can install packages, right ? <jmd>I want to build it from source. I thought that's what guix was supposed to be able to do- <jmd>However "guix build <package>" does nothing more than print the name of a directory in /nix/store <jmd>which should not be there anyway since "guix package --list-installed" says there is nothing installed, and I have just run the garbage collector. <Steap>Do you want to "build" it, as a developer <Steap>Build does not __install__ packages <jmd>What do you mean "as a developer" ? <Steap>well, when I package stuff, as a developer, I build it <Steap>If you're a user, and need the "foo" program <jmd>... I know it doesn't - like I say - it appears to do nothing. I want to build it from source. <jmd>The manual seems to imply that "guix build --no-substitutes <package>" should do that. <jmd>But unfortunately it only prints some obsolete directory. <Steap>Weird, since you(ve run the garbage collector <jmd>finding garbage collector roots... <jmd>deleting `/nix/store/trash' <jmd>deleting unused links... <jmd>note: currently hard linking saves -0.00 MiB <Steap>whatdo "guix gc --list-live" and "guix gc --list-dead" return ? <jmd>--list-dead shows nothing. <jmd>--list-live shows lots of stuff. <Steap>including stuff you compiled earlier ? <jmd>probably dependencies of them. <Steap>guix gc --delete <path returned by guix build> <jmd>It says cannot delete path since it is still alive. <jmd>(although it is not one of those listed by gc --list-live <jmd>How can I just clean everything? <Steap>I'm wondering why these paths are considered reachable <civodul>mark_weaver: i'm gonna merge 'loongson' into 'core-updates', fine with you? <mark_weaver>well, I'd like to go over the patches and improve some of them. <mark_weaver>would you like me to apply the patches to core-updates one by one? <mark_weaver>I've still been unable to build core-updates, because my 'git' is still unable to checkout from github :-( <civodul>are you talking about the libffi, etc. patches? <civodul>i think i trust you on those, not being a MIPS person ;-) <mark_weaver>well, some of the early patches had changelogs that didn't follow the usual conventions, and I forgot to update gnu-system.am for a while, etc. <mark_weaver>well, the patches themselves won't change, although the libffi used spaces instead of tabs, so I wanted to change that to match the conventions of that project (tabs) <civodul>right, so you'd like to rewrite the history? <civodul>the space vs. tabs issue doesn't matter for us <mark_weaver>well, everything in core updates will have to be built from scratch anyway, so I figure it's an opportunity to fix up a few things. <mark_weaver>it's not rewriting history, because those patches have never been applied to core-updates. <civodul>i mean rewriting the history of 'loongson' <mark_weaver>they have to be changed to use the new patch style, etc. <mark_weaver>ah, well, I think I'll keep 'loongson' around until core-updates is merged back into master. <civodul>the thing is, some of these patches affect everyone, like the libffi one <civodul>and we need to build the new bootstrap tarballs <civodul>mark_weaver: so i'll let you merge/adjust as you see fit, and then we'll proceed with the re-bootstrap phase <mark_weaver>okay, I'll get to work on merging these patches into core-updates then. <civodul>you can send notes to the list if you feel some things need discussion <mark_weaver>okay, I think everything I've pushed so far to 'loongson' is quite solid, so I . later, there will be some more questionable <mark_weaver>so I'll just go ahead and push slightly fixed up versions of those two core-updates. <mark_weaver>later, there may be some more questionable patches. for example, I've been looking at what's needed to get X working on the yeeloong, and it's not pretty. <civodul>but it's OK because this doesn't trigger a full rebuild <mark_weaver>*nod* I've already done everything that's needed in the lower parts of the stack, afaik. <mark_weaver>(though libffi still doesn't entirely pass its test suite on MIPS N32, so maybe there are still some issues there to be investigated) <mark_weaver>but that'll have to wait for later. it's working well enough for most things, anyway. <civodul>would be nice to announce it on the loongson (or linux-mips?) list, no? <mark_weaver>yes, there's a loongson-dev list (on google groups, ick) that I'm already subscribed to. <mark_weaver>at Nikita's request, I just deleted the mips64el branch. I agree, it was confusing to have that still around. *civodul switches dmd to GPLv3+ <mark_weaver>well, as a workaround, I set GIT_SSL_NO_VERIFY=true before running ./bootstrap. <civodul>is it just the clone, or also pulls that don't work? <mark_weaver>civodul: are you okay with me applying c9ffa4d1b1edbe75a49d41efb9429e3ccd91c2a9 more-or-less as-is to core-updates? <mark_weaver>should the first line of the commit message start with "gnu:" ? suggestions for what it should be, precisely? <mark_weaver>I might do things in a slightly different order though. (applying the patches to low-level packages before adding the boostrap binaries) <mark_weaver>civodul: I think maybe po/eo.po and po/pt_BR.po should be in .gitignore <mark_weaver>I didn't touch anything in there, but after bootstrapping and building from a clean working tree, now git thinks that I've modified those files. <mark_weaver>well, I know nearly nothing about gettext, but it seems that those .po files got automatically updated on my system somehow. <civodul>mark_weaver: you can reset the changes (it just automatically adjusted the line numbers etc.), but it's good to have them under the radar <mark_weaver>civodul: will core-updates currently build bootstrap tarballs containing gcc-4.8.2 ?