IRC channel logs
2016-08-13.log
back to list of logs
<catern>setuid binaries are more difficult to lock down than IPC, I believe <myglc2>catern,mark_weaver`: ARG! Topic collision. I am talking about an emacs/gnus/notmuch replacement for gmane.org <sapientech>looking up the main error: socket.gaierror: [Errno -2] Name or service not known, it appears this has something to do with hostname resolve issues <sapientech>testing those commands in the repl, though work fine. was wondering if this is a guix build related issue <sapientech>since i know that the are nameserver issues with guix's tests <lfam>sapientech: The environment in `guix build` has no network access at all. <lfam>No, there is no network access allowed <sapientech>yeah just confirmed that :( . so in this case have #:tests? #f <lfam>The manual sections 2.4.1 'Build Environment Setup' and 2.5 'Invoking guix-daemon' has some details about the build environment. <lfam>Sometimes it's possible to only disable specific tests. That's desirable if it's not too much work <sapientech>lfam: okay thanks for the reference, any good examples of disabling specifc tests? <lfam>sapientech: For Python software, there are a few examples in gnu/packages/calendar.scm and gnu/packages/python.scm <lfam>We have to take an ad-hoc approach to this. It's rare that we get a real interface for disabling specific tests <lfam>sapientech: I realized that by "install" you might mean `guix package --install`. I meant the install phase of a build system. I'm not sure about the former. <lfam>We have profile hooks, but I haven't looked closely at them <lfam>sapientech: In general, we don't want to use the network for anything that's not content-addressable. That is, for anything that can't be named with a hash. <sapientech>lfam: former is what i meant, and it didn't work <lfam>kocio_: Can you share the entire package definition on paste.lisp.org? Ideally as a patch created with `git format-patch`? <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). <lfam>But, with those changes, it builds for me <kocio_>could you show me the altered code? I'm doing baby steps learning it and I'm not even a programmer. <lfam>kocio_: Reload that paste.lisp.org link you showed me. I added your original package, in the "patch" format, and a second patch showing my changes <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? <kocio_>I'm not sure, could you paste the raw content? I know the patches, but don't work with them, because I'm a sysadmin. <kocio_>I even don't have local.mk file - I put scm file into /root/.guix-profile/share/guile/site/2.0/gnu/packages <lfam>kocio_: If you intend to get the package merged into GNU Guix, we will be happy to help you learn how to use Git and patches :) <kocio_>I know git, but my skills are basic =} <kocio_>I can use it, but it's hard enough to try learning Guile notation and guix recipes <lfam>kocio_: That's not the best place to put your new package if you want to add it to Guix <lfam>You should read about GUIX_PACKAGE_PATH in the manual and try that. Even better, clone our Git repo and add the package in preparation for having it added to GNU Guix <lfam>The directory you used is supposed to be read-only, and is changed each time you use the `guix package` command <lfam>Basic Git skills are all that is required. People learn the fancy stuff when they eventually need it :) <kocio_>I know, that's exactly why I'm learning those fancy recipes, just because I believe guix premise is great =} <kocio_>Great, GUIX_PACKAGE_PATH proved to be /gnu/packages and placing scm file there did the trick <kocio_>now, what if I want to pass the option to configure (disabling gtk)? any sane example? <lfam>kocio_: Search our Git repository for "#:configure-flags" for some examples <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>what is so bad about setuid in practice? <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. <phant0mas>we can only continue trying to explain to them and hope they listen <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 <janneke>yay! @ build-succeeded /gnu/store/ffffcgp0fmm0vc8pkjy6i0h3ysrpz8n1-cross-lilypond-2.19.33.drv <rekado>I have an update for pulseaudio here. This will result in a lot of rebuilds. I want to push it to a ‘pulseaudio-update’ branch and have hydra build it. <marusich>rekado, setuid is difficult to do securely, even though it is possible to do it safely. For this reason, some organizations/people prefer to avoid it entirely. <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 <dhamidi>a question: does GUIX (the package manager) run on Mac OS X? <alezost>what tools do people use on GuixSD to suspend, hibernate, etc.? <mark_weaver>alezost: hibernation is not yet supported. we need some bits added to our initrd for that <mark_weaver>alezost: in GNOME anyway, suspend should work automatically when you close the lid. <sneek>Welcome back Snake, you have 1 message. <mark_weaver>and I'm not sure it's gnome-specific. wingo took care of that a while ago. <mark_weaver>it should be handled by elogind. see the <elogind-configuration> in gnu/services/desktop.scm <Snake>i have a query about GNU Guix, if any user can install a package, is not this a security problem? <mark_weaver>my Libreboot X60 is a bit weird in this regard, so it doesn't quite work for me, but multiple people have said it works for them. <mark_weaver>what security problem are you thinking of, specifically? <Snake>any user can admin the system? <mark_weaver>that's very vague. this is more akin to "any user can compile a program and install it in their home directory". <Snake>i didnt know that install it in only own home directory <alezost>mark_weaver: thanks for the info! I didn't meant for closing the lid, I'm just searching for a command that will replace "echo mem > /sys/power/state" for me :-) <mark_weaver>well, to be more precise, the builds are actually managed by a build daemon, performed by an unprivileged user in an isolated build container, and added to a common store. <mark_weaver>so if another user on the same system builds the same package, they can make use of the already-built one. <mark_weaver>but unless someone else is specifically looking for that exact build, it won't affect anyone else. <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! <rekado>mark_weaver: I just pushed to pulseaudio-update. <rekado>not sure if this worked all right because I got this message: <rekado>remote: fatal: bad object 0000000000000000000000000000000000000000 <dhamidi>hey! Is there a way to build/test a guix package with a local source tree, e.g. the package definition is in $DIR/guix.scm and the package source tree is in $DIR as well <rekado>dhamidi: if you have a package description you can tell Guix to use the sources from elsewhere. <rekado>so far I’ve only tried this with prerelease tarballs. <rekado>not sure if this would work for directories as well. <rekado>look for the ‘--with-source’ option in the manual. <dhamidi>rekado: thank you, I'll check that out <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>(while investigating strange ENOSPC errors from a filesystem with over 80 gigs free and 500 million inodes free) <mark_weaver>basically, it has to do with peculiarities of the htree directory representation used in ext3/4. <mark_weaver>you can even get in a state where some file names can be added to a directory, but not others, depending on what hash value the new entry happens to have. <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 <balduin>while trying to build my own package I got the following error: Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) <balduin>what should I do? How can I investigate errors further? <jlicht>adding the pkg-config package as a native input to your package might help <sneek>Welcome back jlicht, you have 1 message. <sneek>jlicht, lfam says: Those are very important patches. Thank you for sending it! Keep paying attention :) <balduin>@jilicht: how do I add the pkg-config package as a native input? <jlicht>balduin: for example, see the python-numpy package ( guix edit python-numpy) <jlicht>balduin, it's jlicht, but that's okay still ;) <balduin>now I get the following error message: CMake Error at cmake/FindAPR.cmake:56 (MESSAGE): <balduin>but I use: #:use-module (gnu packages apr) <balduin>and defined apr and apr-util as input of my package <balduin>@OrangeShark: but why do I get the error message from CMake: Could not find APR library? <OrangeShark>balduin: oh, hmm looks like they hardcode the location to find APR <OrangeShark>though there is the APR_INCLUDE_DIR which might be a variable you can pass in? <balduin>@OrangeShark: thanks. How can I pass variables like APR_INLCLUDE_DIR into the build process? <OrangeShark>balduin: some of the build systems have arguments so like adding configure flags <OrangeShark>cmake looks like it has a #:configure-flags parameter <OrangeShark>so you can add right after (build-system cmake-build-system) <OrangeShark>just need to add something like `(#:configure-flags (list of flags) <OrangeShark>I am not familiar with how cmake accepts flags or arguments though <OrangeShark>add the `(#:configure-flags ...) inside of (arguments ...) <balduin>@OrangeShark: I tried this one: (arguments `(#:configure-flags '("-DCMAKE_APR_INCLUDE_DIR=xyz") )) <balduin>I still get the same error message: Could not find APR library <OrangeShark>balduin: you will need to pass it the directory on where to find APR <OrangeShark>lets see if I got this right, you should add `(#:configure-flags (list (string-append "-DCMAKE_APR_INCLUDE_DIR=" (assoc-ref %build-inputs "apr")))) <OrangeShark>assoc-ref is a scheme procedure to return a value from the first argument with the key in the second argument <OrangeShark>so this basically gets the inputs you list right below <balduin>yes, thanks the path is so far correct, but I think that CMAKE file really just looks in the hardcoded folders and this does not work with guix <balduin>sorry, I am not so shure how this works: FIND_PATH(APR_INCLUDE_DIR apr.h <balduin>does it mean search first for APR_INCLUDE_DIR / apr.h and then for /usr/local/include/apr-1? <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 <OrangeShark>balduin: I think it means APR_INCLUDE_DIR is the variable that has the directory for apr.h which can be found in /usr/local/include/apr-1... etc