<lfam>kocio_: Instead of bootstrapping after the 'unpack' phase, you should do it before the 'configure' phase. Otherwise, you try to run ./bootstrap.sh before its shebang has been patched. Also, you'll need to add autoconf, automake, and pkg-config as native-inputs. And also gtk+-2, for some thing. I don't know if that is needed at run time (inputs) or just build time (native-inputs).
<kocio_>hm, still not working at me: patch-shebang: ./bootstrap.sh: changing `/bin/sh' to `/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/sh' phase `patch-source-shebangs' succeeded after 0.0 seconds starting phase `configure'
<lfam>kocio_: It works for me. Are you sure you are using both of my patches?
<lfam>Or, equivalent code, if not using my patche?
<lfam>kocio_: The idea with GUIX_PACKAGE_PATH is that you can choose what it is. Mine is ~/pkgs, and my packages declare themselves as (leo packages foo). So, the package module file foo.scm would be in ~/pkgs/leo/packages/foo.scm
<lfam>So, foo.scm would start with (define-module (leo packages foo) ...), instead of (define-module (gnu packages foo) ...)
<lfam>And my ~/.bash_profile exports GUIX_PACKAGE_PATH=~/pkgs
<kocio_>I guess mtr belongs to admin.scm BTW - do we add new recipes there at the end of the file or maybe sort them by name?
<kocio_>it's just easier to start with one short file
<lfam>kocio_: I prefer to append new packages to the end of the file, but some files sort the packages alphabetically. So, look to see if they are in order or not and make your choice based on the convention
<kocio_>My main work with guix is translation, but I want to know how it works first, because good translation is about understanding some basic ideas not just words
<lfam>Indeed, translation requires understanding the source text
<kocio_>and it's fun to learn new, crazy things =}
<rekado>I’m trying to get Galaxy to support Guix as a backend for installing packages, but they are very unhappy with the requirement to have a root daemon.
<rekado>the point here is that not all admins running Galaxy instances have root access (which I find surprising).
<rekado>so they would depend on admins to set the daemon up and make sure it works.
<rekado>with a setuid program it appears to be much less effort.
<rekado>what is sad about this is that people seem to be willing to throw out reproducibility and take something like inadequate like Conda over Guix, just because it seems easier to get started with it.
<rekado>the Galaxy folks seem to have plans to push software environments from one Galaxy instance to another and this would only work with the inadequate solutions like Conda (it is really terrible).
<rekado>They have a talk slot right before mine and I’d really like to make Guix work with Galaxy because I fear that otherwise the bioinfo folks will continue to ignore Guix for this purpose (even though it’s a near perfect match).
<Gamayun>kelsoo: I'm out of the UK then, but looks awesome :D
<random-nick>why are the hashes of the dependencies before the package name?
<mark_weaver>setuid binaries are also quite awkward to deal with in Guix, since they cannot exist as setuid binaries in the store, you can't have multiple versions of them co-existing, etc.
<mark_weaver>this decision is inherited from Nix, and I'm not sure what they're reasons were, but I can think of a few reasons myself. it makes filename lookups in /gnu/store faster. also, I don't see any actual advantage to doing it the other way.
<mark_weaver>you always need to know the hash to get the correct version of whatever package you're looking for, and once you know that, it takes less typing to start with the hash and type TAB than to do it the other way around.
<mark_weaver>regarding the speed of file name lookups: when comparing two file names for equality, having the hash at the beginning means that mismatched file names are detected after just a few characters.
<mark_weaver>the only perceived advantage I see to the other way is that if you just want some random version of a particular package, you can pick one at random. but that's a bad idea. you might get an old version linked with an old library with security holes. you should always pick the right one, and for that you need the hash.
<mark_weaver>(we should have a FAQ for this, it comes up often enough)
<mark_weaver>having the hash at the beginning also makes it easier and more robust to scan for store references in build outputs, and to substitute them in grafts.
<random-nick>well doing it the other way would sort alphabetically the package names and not the hashes
<mark_weaver>each user has a ~/.guix-profile symlink that points to a "profile", which is a tree of symlinks that implements a union of all the packages they desire to have in their profile. and each user that wants to use guix packages sets environment variables, e.g. PATH=$HOME/.guix-profile/bin
<mark_weaver>if you're curious for more details, we have papers and videos of talks available in the "help" section of our website
<alezost>yay, it looks like "loginctl suspend" does what I want; thanks wingo!
<dhamidi>rekado: guix informs me that this had no effect
<dhamidi>What I'm trying to achieve: put together a minimal package for a guile module, including a guix package definition (as an example/starting point for creating more guile packages in the future)
<mark_weaver>rekado: thanks. the error message you saw happens whenever pushing a new branch, due to a problem with the git hook that checks for signatures, but it seems to be harmless afaict.
<mark_weaver>rekado: unfortunately, at the moment only 1/3 of our x86 build slaves is online.
<mark_weaver>one of them (chapters.gnu.org) I could fix right now if I had root access on that box, but I don't. civodul normally takes care of that machine, but he's away.
<mark_weaver>another one should be working again after "guix gc" finishes running on it, but that's going to take a while. it's having problems because /gnu/store/.links has too many entries in it, and we're running into limitations of the ext3/4 filesystem that were unknown to us previously.
<mark_weaver>(I've seen lots of claims on the net that ext4 directories can have an "unlimited" number of non-subdirectory entries, but it turns out that's hogwash)
<mark_weaver>so we're going to have to make some changes to how we store those links, which are used to implement deduplication.
<mark_weaver>(the problem doesn't show up until you have a very large store, in this case the store has 1.5T of stuff in it)
<mark_weaver>and it could be avoided altogether by using a better filesystem without these silly limits
<ijp>have you or the nix people talked with the kernel fs developers about this?
<mark_weaver>apparently there are patches floating around to support 3-levels of htree (the current limit is 2-levels), which would vastly increase the directory size limits, but apparently it was deemed not sufficiently important.
<mark_weaver>but just to briefly conclude: it won't be hard to work around this limitation. one option would be to change /gnu/store/.links directory from a simple flat directory into a two-level directory structure, with the first two digits of hash determining the subdirectory name, like we do for log files in /var/log/guix/drvs
<daviid>anyone running guix on a mac? someone is complaining (again :)) he can't install guile-gnome, it is too complicated, pretend guile-cairo does not compile on the mac (I doubt but he says so)... so I'd like to recommend guix