***ljhms_ is now known as ljhms
<abnegate>i'm trying to compile qjackctl against a guix package called jack <abnegate>in the qjackctl source directory, i did: LDFLAGS="-L/home/me/.guix-profile/lib64" CXXFLAGS="-I/home/me/.guix-profile/include" CFLAGS="-I/home/me/.guix-profile/include" ./configure --prefix=/usr/local/apps/qjackctl --with-jack=/home/me/.guix-profile/lib64 <abnegate>then, when i did a make, it compiled a bunch of stuff and then complained: ld-wrapper: error: attempt to use impure library "/usr/lib/x86_64-linux-gnu/libc.so" <mark_weaver>you need to set the environment variables as "guix package" should have suggested after you installed gcc-toolchain, etc, notably LIBRARY_PATH, CPATH, PKG_CONFIG_PATH, ACLOCAL_PATH, PATH, etc.. <mark_weaver>if you're going to be building software manually, you need to ensure that 'configure' will not pick up stuff from Debian. <mark_weaver>that means that when configuring and building the software, PATH should not include /bin or /usr/bin <mark_weaver>the easier and better way to do all this is to just create a Guix package description for qjackctl <abnegate>how can i see the suggestions that "guix package" gave me after installing gcc-toolchain? <mark_weaver>guix-daemon builds software in a chroot and private namespace where it cannot even see anything that's not part of guix. <abnegate>just hoping to do a quick and dirty compile before i dive deep in to guix package building <mark_weaver>it would probably take less time than what you're doing now <abnegate>btw, i read through guix-ghm-andreas-20130823.pdf <abnegate>it's a nice brief overview and series of exercises <abnegate>but not enough hand-holding for me.. and some steps need more knowledge than i have to make sense of <mark_weaver>btw, once you have your environment variables set correctly, you can run ./configure without any arguments at all in many cases. <mark_weaver>although some package's build systems are better than others, and some of them need a lot of help to cope with Guix's unusual filesystem structure <abnegate>i've begun looking at the "djvu" guix package as my example/model <abnegate>and i'm wondering, why does it have "/home/cthulhu/compilation/own/guix-packages <abnegate>and i'm wondering, why does it have "(define-module (gnu packages djvu)" <abnegate>why do they call it "djvu" in one place and "djvulibre" in another? <abnegate>and then under "(package" they have "(name "djvulibre")" again <abnegate>but earlier they had "(gnu packages djvu)" <abnegate>but when i "guix build qjackctl.scm" i get an error: "guix build: error: qjackctl.scm: unknown package <mark_weaver>(gnu package djvu) is the name of the guile module. in general, modules can contain many packages and/or other definitions. <mark_weaver>the name after 'define-public' is the scheme _variable_ name, which is bound to a package object <mark_weaver>the name in the package definition, e.g. (name "foo") is the name of the argument you pass to 'guix build' <mark_weaver>your package belongs in gnu/packages/audio.scm I would say <mark_weaver>abnegate: the hash of the source tarball is wrong. it should be the output of 'guix hash <filename>' <mark_weaver>it's the same hash function, but a different text format to represent the hash <abnegate>i was wondering how you were supposed to get tbe base32 of it <abnegate>so, say i want to build my package without putting it in to gnu/packages/audio.scm <abnegate>any reason to put it in gnu/packages/audio.scm other than for better organization? <mark_weaver>well, if you want to contribute your package to guix, you need to work with git <mark_weaver>otherwise it makes a lot more work for us to incorporate your work <abnegate>what if i need to create a private package? <mark_weaver>my recommendation is to create a private git branch for yourself and periodically rebase it on our upstream (or merge our upstream into your branch) <mark_weaver>that's what I do, and it allows not only adding private packages but making arbitrary changes to anything in guix <mark_weaver>the other less flexible way is to set GUIX_PACKAGE_PATH <mark_weaver>set it to point to some directory DIR, and then put your file in DIR/gnu/packages/qjackctl.scm <mark_weaver>the module name (foo bar baz) is found in DIR/foo/bar/baz.scm <mark_weaver>but I would encourage you to use the git approach instead <mark_weaver>the first step to doing that would be to build guix from a clone of our git repo <mark_weaver>abnegate: you can use your existing guix install to create the environment needed to compile guix itself, using 'guix environment' <mark_weaver>'guix environment guix' will spawn a shell which environment variables set to build 'guix', such that everything needed to build 'guix' from git is available. <mark_weaver>(it will build/download whatever software is needed to do that) <mark_weaver>or, if you prefer, you can build guix against the software you have in your host debian system. <abnegate>would i need to rebuild the entirety of guix just to install my own little package that i just created the definition of? <abnegate>in that way, i'd need to rebuild all of guix every time i added a new guix package? <abnegate>so what's the point of building guix itself from git? <mark_weaver>you just run 'make' and it only rebuilds what's needed based on what source files changed <mark_weaver>with almost *any* piece of software, if you want to contribute to development, it is advisable to build that software from it's source repo <abnegate>so i wouldn't use "guix build foo" to build from "foo.scm" definition? <mark_weaver>no, the argument to 'guix build' is not the scm module/filename. <mark_weaver>'guix build' loads all files in gnu/packages/*.scm (and also all *.scm files within the directory tree rooted in GUIX_PACKAGE_PATH) and scans those modules for variables bound to package objects. <mark_weaver>the argument to 'guix build' corresponds to the 'name' field of the package object. <abnegate>why are the packages so tightly bound to guix itself and the guix filesystem heirarchy? <abnegate>why wouldn't guix just allow you to build from an arbitrary foo.scm file anywhere in your path without further setup/intervention? <mark_weaver>we keep the package manager and package descriptions in the same git repo to give us flexibility to change the way that package descriptions are expressed <mark_weaver>it's the same reason that the linux (the kernel) developers choose to keep their drivers in the same tree as the kernel <mark_weaver>otherwise the APIs between the drivers and the core would have to remain fixed <mark_weaver>or there would be tons of backward compatibility cruft, etc. <abnegate>but, say, debian package files (.deb files) can be downloaded separately, without needing to be in the official debian repo (or any repo) <mark_weaver>we are a young project. we need to retain the ability to make incompatible changes in the way that packages are defined, etc. <abnegate>i was just curious behind the reasoning of it all <abnegate>another question: if i use git and then do my own makes of guix, will i still need to do guix pulls? <mark_weaver><abnegate> why wouldn't guix just allow you to build from an arbitrary foo.scm file anywhere in your path without further setup/intervention? <mark_weaver>you have that option if you want it. I'm just saying that the git approach is superior in every way except that it requires a bit more effort up front. <mark_weaver>abnegate: no, the git approach replaces 'guix pull' entirely. <mark_weaver>I don't run 'make install' in the git checkout either. <mark_weaver>I always run guix out of the git checkout, using pre-inst-env <mark_weaver>I have a shell script in ~/bin/guix that does: exec /path/to/guix/pre-inst-env guix "$@" <mark_weaver>the builds themselves are done using unprivileged users in an isolated build environment <abnegate>so, i have run "guix pull".. if i start using the git method you describe, will i need to reinstall all the packages i've already installed using non-git guix? <abnegate>or can the git guix take over from here? <mark_weaver>when you run guix via 'pre-inst-env', the 'guix pull' has no effect <mark_weaver>'guix pull' populates ~/.config/guix/latest with the source code of the latest guix from git and builds it <abnegate>do you run a "git pull" to keep your guix master branch in sync? <abnegate>perhaps a better topic for #git, but i've heard some people recommend that you should never run "git pull" but rather always do "git fetch" and then "git merge" <mark_weaver>if you have made your own local commits, then "git pull --rebase" will rebase your local commits on top of our current 'master' <mark_weaver>abnegate: that could be true, I don't claim to be a git expert <mark_weaver>my personal method is to use 'git-new-workdir' (a script in the contrib directory of the git source code but not normally installed) to create multiple working directories that share a single local git repository. <mark_weaver>so I have multiple working directories on different branches, and among them are 'guix-master' which is upstream master and then 'guix' which is my own private branch. <mark_weaver>so I "git pull" from 'guix-master' and then "guix rebase master" from my private branch in 'guix' <mark_weaver>I prefer to keep my local changes in the form of patches based on current upstream master <mark_weaver>this allows me to have my own private branch but also make changes to upstream master and push them to our git repo. <mark_weaver>abnegate: one last note: in order for the 'guix' from git to take over from your current setup, you must ensure that --localstatedir (specified to ./configure) is the same as for the guix system you're currently using. <mark_weaver>otherwise it won't be able to find the 'sqlite' database and other things that you have in place now. <mark_weaver>if you use the same --prefix that you did before, it will be fine. <Sleep_Walker>I use git branch for packages I'm working on, and extra path for packages which are not meant to be pushed <abnegate>when i run "./bootstrap" from the guix i got from git, i get this error: "configure.ac:58: error: possibly undefined macro: GUILE_MODULE_AVAILABLE" <Sleep_Walker>this is defined in /usr/share/aclocal/guile.m4 on usual distribution *Sleep_Walker makes note to ask about creating guix-bootstrap to be used as environment, but not as package <abnegate>great, installing guile fixed that error <abnegate>now i'm getting some warnings: configure.ac:18: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged. <abnegate>Makefile.am:314: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS <abnegate>now when i run "./configure" i get this error: configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README' <abnegate>i tried installing libgcrypt-1.6.3 and then libgcrypt-1.5.4, and neither helped <Sleep_Walker>and I'm not sure what distribution you are on, but there are usually packages with separated development files <abnegate>i also tried running "./configure --with-libgcrypt-prefix=~/.guix-profile/lib" bu that didn't help <abnegate>shouldn't guix's configure pick up the libgcrypt version i installed with guix itself <abnegate>i can, of course, install debian's libgcrypt-dev, but i thought that mixing debian and guix libraries in one executable was a no-no <Sleep_Walker>but you can pass the path to --with-libgrcypt-prefix=/gnu/store/*-libgcrypt-*/ <abnegate>i tried that, to pass in --with-libgcrypt-prefix=~/.guix-profile/lib but that didn't work <Sleep_Walker>I'll be back later, but as you will find, I'm not that usable as other gurus here :b <abnegate>--with-libgrcypt-prefix=/gnu/store/vk0wlmpmywvx5rl694ah16d48sybi86v-libgcrypt-1.6.3 didn't work either, by the way <abnegate>neither did --with-libgrcypt-prefix=/gnu/store/zb64wv4nbrzckasd9jd8lq1yl955qbdm-libgcrypt-1.5.4 <abnegate>configure still complains "configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'." <phant0mas>Samuel made some interesting commits on the glibc and libpthread repos that will simplify our glibc/hurd package <civodul>for your work i think we should host a libc tarball <civodul>it would be good to check with the Hurd people what revision they recommend <civodul>and perhaps whether they want to publish the tarball themselves <phant0mas>that could be great and latest commits seems to be okay <phant0mas>it seems that in the last 3 months the hurd guys were quite active <phant0mas>but now I have more undeclared things to hunt... <phant0mas>will ask in their mailing list what _SERVERS_STARTUP should be <phant0mas>the commit log says "Lookup the startup server through /servers/startup" <phant0mas>normally it should find the correct value in <hurd/paths.h> but this file doesn't exist <civodul><hurd/paths.h> is part of the Hurd, not of libc <civodul>so you probably need to update the Hurd before you can build this libc <civodul>or did i misunderstood? (why would libc refer to _SERVERS_STARTUP?) <phant0mas>but this means we will have to use the git repo in hurd-headers as well <rekado>I wonder if we could make scipy/numpy depend on a substitutable openblas instead of ATLAS. <rekado>then they could be substituted as well. <rekado>using a shared /gnu/store for lots of users I encountered a recurring annoyance. <rekado>Often when I update guix to get the latest packages I see that minor changes make me install a new version of python and numpy in particular. <rekado>Since the version number hasn't changed but only the hash (as inputs have likely changed) I'd very much like to replace the previously installed versions in the store with the new ones for *all* users. <rekado>I don't really want to have to upgrade each profile. I want to avoid actually upgrading to any newer versions. Just want to have everyone use the latest "incarnation" of the version they have installed. Then I could also purge the older incarnations from the store to save space. <rekado>Is there a safe way to "upgrade" a profile's packages without upgrading the versions? <abnegate>in the guix README, it talks about a "localstatedir" <abnegate>is that where guix is installed? like, for example, /usr/local/guix? <rekado>abnegate: it's where profiles and other state is stored. <rekado>If installed to /usr/local it's probably /usr/local/var/guix or so. <mark_weaver>civodul, rekado: the patch-and-repack change should go to core-updates, right? won't it force a rebuild of all patched packages? <sneek>Welcome back mark_weaver, you have 1 message. <sneek>mark_weaver, ArneBab_ says: sorry for being away, my homeserver died (so I do not have a backlog) <civodul>mark_weaver: the patch-and-repack change *went* to core-updates (by bavier) <mark_weaver>abnegate: I pass --with-libgcrypt-prefix=/gnu/store/...-libgcrypt-1.6.3 to guix's ./configure in git, when building against all guix libraries <abnegate>mark_weaver: that didn't work for me.. but this did: --with-libgcrypt-prefix=$HOME/.guix-profile/ <civodul>rekado: why do you want to have all users upgrade at the same time? <mark_weaver>I'm not sure why the other didn't work for you. the snippets you pasted here on irc had the configure flag mispelled; not sure if that was it. <civodul>rekado: IMO the whole benefit on a cluster is precisely that users can choose whether/when to upgrade <rekado>civodul: I don't want to upgrade. I just want to avoid having ten incarnations of python-2.7.6 in the store just because some input changed. <civodul>rekado: right, but for what reason do you want to avoid that? <mark_weaver>abnegate: --with-libgcrypt-prefix=~/.guix-profile didn't work because the shell won't substitute $HOME for ~ in that position. <mark_weaver>rekado: if you don't let users upgrade on their own terms, you are discarding one of the most important features of guix <rekado>civodul: old sysadmin habits, I suppose ;) At the moment it's no problem because the store is just about 10 GB, but it may become a problem in the future. <mark_weaver>rekado: our "liberating users" idea seems to be getting drowned in your bathtub <rekado>I have the practical problem that we have one shared store. <rekado>and only one server with write access. <rekado>I can't *yet* give all users ssh access to that server. <rekado>and actually, I'd prefer not to have to give them ssh access at all. <rekado>these are biologists who are not necessarily comfortable with the command line. <rekado>I'd like to give them a web interface to manage their profiles. *civodul looks at davexunit <civodul>with deduplication, having several python-2.7.6 doesn't cost much in terms of disk space <rekado>so I have to put my sysadmin hat on and do the sysadmin thing: manage software for them. <abnegate>looks like the guix compilation aborted because it was missing the "dot" program (from graphviz, i gather) <rekado>civodul: the problem is that I'm not really benefiting from deduplication when I have to reinstall the same version of python again and again. <abnegate>configure didn't pick up that i didn't have graphviz installed <rekado>it's not just linked to a shared item. <civodul>rekado: wait, they're connecting to a cluster over ssh, and they're not comfortable with command line? how's that possible? :-) <rekado>civodul: stranger things have happened. <davexunit>abnegate: because it's not required for users compiling from released source tarballs <rekado>we had to give them a crash course in how to use the simplest command line tools. <civodul>rekado: what do you mean by "reinstall the same version of python"? <rekado>they are, for the most part, biologists with access to computers, not bioinformaticians. <abnegate>davexunit: isn't there some way configure could be a little smarter about this and tell me in advance i need something that i don't have installed before my make begins? <rekado>civodul: say I install scipy for a user on Monday. On Tuesday there is an update to the inputs of Python. On Wednesday I update Guix to get my latest bioinfo tools. Then I install scipy for another user. <civodul>abnegate: ./configure doesn't warn you about missing graphviz because it's not needed when building from a tarball, as davexunit wrote <rekado>the hash for python at that point will be different from the one I installed on Monday. <rekado>This happened often enough in the past. I'm *again* downloading (or trying to download) texlive because numpy needs to be built from scratch for some reason (even though I installed it before for some other user). <rekado>this makes installing software to profiles very slow even though I'd prefer to just see a symlink be installed. <civodul>there's no good answer for that at the moment <civodul>as a hack you could sync the ~/.config/guix/latest symlinks of users <civodul>this is a lesser evil than what you suggested, but still not great <civodul>the good answer will be to change our substituter protocol <civodul>the problem is that Hydra would be stuck with the old protocol <rekado>re ~/.config/guix/latest symlinks: I don't know what this means -- I'm usually running make install as root to upgrade guix globally on the server. <civodul>rekado: you should write somewhere about your experience with Guix-on-cluster <rekado>I'm planning to do that tonight, actually. <civodul>rekado: last time i ran "make install" was months ago <civodul>the normal way is just "guix pull", which works per-user <civodul>maybe that partly explains the pain you've endured? <civodul>i mean, if a user install numpy, then days later installs texlive, presumably the texlive is already in store <civodul>unless they run 'guix pull' in the meantime <civodul>or the admin did 'make install' in the meantime <rekado>but I'd still have the same problem if I installed numpy for another user if guix had been updated since the last installation of numpy for another user. <rekado>I didn't have much of a problem with individual user profiles yet (e.g. installing texlive into a profile that already has numpy installed), because we're only just begun making people use Guix software profiles. <civodul>well, each user could be running a different revision of guix, presumably leading to different variants of numpy <civodul>syncing the ~/.config/guix/latest links could mitigate that <rekado>with "make install" isn't guix the same for everyone? I haven't used "guix pull" even once in this environment. <rekado>"which guix" always results in the globally installed guix on that server, making it a little more predictable for me to see what software is installable. <civodul>$(which guix) is always the same, but it first looks for modules in ~/.config/guix/latest <civodul>effectively ignoring the previously-installed modules <rekado>hmm, I see that for my users there is no ~/.config/guix/latest. <rekado>there is no ~/.config/guix at all. I assume it's only created after "guix pull"? <rekado>so, in this shared environment everybody uses /usr/bin/guix and the latest global modules (plus the stuff in GUIX_PACKAGE_PATH that I cannot upstream). <wingo>is it possible to run a vm in guix? *wingo pondering whether to make guix the host or guest OS on a new machien <davexunit>wingo: guix uses qemu + kvm for the 'guix system' command, so yeah, we have the software needed to create a Debian VM or whatever. <wingo>so i could run a VM for running $proprietary-video-chat-app if i needed to do so <davexunit>okay, let's finish up these 'guix publish' patches... <mark_weaver>rekado: ~/.config/guix is not created until you run 'guix pull', right. <mark_weaver>(I've never used 'guix pull', preferring instead to use 'git pull' :) <davexunit>civodul: is it worth a bit of extra code to avoid connecting to the daemon when running 'guix publish --help'? <davexunit>I'm thinking yes, but want to know your thoughts. I'd like to delay the connection until needed. <mark_weaver>everyone should upgrade their icecat for important security updates <mark_weaver>hydra has recently finished building it on intel platforms <civodul>davexunit: yes, we've tried to do that for the other commands <civodul>mark_weaver: and thanks for taking care of it again! <civodul>we should get Ruben to use Guix and do that as well ;-) <civodul>wingo: be aware of the limitations, like no GNOME, no NetworkManager <civodul>if that's a problem Guix can be used on top of another distro <civodul>just wanted to warn you so you know what to expect :-) <wingo>i guess there's nothing fundamental preventing gnome and networkmanager and such to be packaged with GuixSD right? <civodul>well, there's GNOME/systemd relationship that needs to be sorted out <civodul>i don't know how much of a problem it would be <Kolt>can I troubleshoot here? <Kolt>bavier: I compiled guix successfully (instead of downloading from my distro's available options), created the build user, and such. When I tried to test install guile, the computer ran out of memory and I had to turn it off. After booting up again, I find that I can't use the socket anymore, there's just no way. <bavier>Kolt: you may have had substitutes disabled, in which case you would have been building all packages on your machine. <bavier>the socket you can't use; are you referring to the guix-daemon socket? <Kolt>bavier: correct, the guix-daemon socket. <bavier>a `sudo rm ...` should work I think, then restart the guix-daemon <bavier>they're generally a good idea, unless you like to build your own software ***tschwing_ is now known as tschwinge
<Kolt>I removed the socket file, but everytime I kill the daemon I find the same problem. This can be solved using substitutes as you stated I suppose. <Kolt>any idea why it crashed when installing guile through guix? <bavier>Kolt: I'm guessing system resources <Kolt>unfortunatelly, I couldn't debug it, but I suspect a memory overflow since I've experienced them before in this same machine. <Kolt>Ijust checked the fstab I have a partition for /var but not for /tmp <ph4nt0mas>tmpfs /tmp tmpfs rw,size=(size you want, 8G for example) 0 0 <rekado>whenever I build big applications (e.g. the JDK) I run the daemon with TMPDIR=/buildtmp, where /buildtmp is somewhere on the disk. <ph4nt0mas>sorry mark_weaver I just came to the computer, didn't follow the conversation <Kolt>what if I remount /tmp on the UUID that /var is? <mark_weaver>Kolt: it's not safe to remount /tmp on a running system <Kolt>I meant with a recovery usb <Kolt>I have one that is gentoo based and the arch installation <mark_weaver>I don't understand what would be the use of a recovery usb here <Kolt>to change my fstab while my system is not running <mark_weaver>Kolt: if there's no fstab entry for /tmp but it's nonetheless a tmpfs (check /proc/mounts), then most likely there is a system startup script that specifically mounts it as a tmpfs. <mark_weaver>Kolt: what is the output of grep /tmp /proc/mounts ? <Kolt>Arch (I know there's Guix in the AUR, but since I'm planning to change it, I'm trying to get used to build) <Kolt>did I miss something in the install or the daemon invoking? <mark_weaver>or you could just set TMPDIR=/var/tmp (or somewhere else) before running guix-daemon, either way is fine <Kolt>Which flags do you recommend I use when running the guix-daemon? <Kolt>ok, is there an online list with the software that can be installed through guix? (instead of opening the store) <Kolt>how do I run it in emacs? 'M - x guix'? <Kolt>how many people is working on the project? <bavier>Kolt: the AUTHORS files lists 28 <civodul>"git log v0.8.1..HEAD |grep ^Auth|sort -u|wc -l" says 23