<cmhobbs>is gnunet and gns available in guix? <efraim>it's showing up as available on my debian sid system <efraim>oh, I guess being in experimental doesn't really count <lfam>It looks like they are still in development, according to gcc.gnu.org. Such early development that the "GCC 6.0 (release criteria)" link goes to the release criteria for gcc-5. <efraim>that's the impression I got from phoronix <efraim>debian apparently packaged a snapshot from dec 11th <efraim>I see on their site they have a weekly snapshot <roelj>Regarding the build status icons on the package list: It turns out the webmasters are not in control of the Apache configuration, and my request has been forwarded to the sysadmins. <swedebugia>hi. where is the complete documentation for the package defs? Specifically I need to know how to modify phases and delete a phase. <roelj>swedebugia: See section 4.2 Build systems. <roelj>swedebugia: An example provided there: #:phases (alist-delete 'configure %standard-phases) <swedebugia>already read that one and most of the manual actually. did not help as it does not specify how the syntax for (arguments is done right. <roelj>swedebugia: I'd suggest looking at existing package definitions. <swedebugia>roelj: thanks for the tip. any package with cmake-build-system and the 'check phase removed? <roelj>swedebugia: Not sure, you can have a look at conky. Then apply the #:phases (alist-delete <roelj> 'configure %standard-phases) instead of the (alist-cons-after ...) <roelj>Conky is in: gnu/packages/conky.scm <fps>sneek: later ask cmhobbs: yes, gnunet is available <swedebugia>roelj: now it build without errors and the program runs. dunno if it works though <roelj>swedebugia: Cool. You can look at the build output directory to see if it looks fine. <anonymiss_>hm. if i would need make for a makefile for a local C programm, where would i get make? gcc or does the other gcc of guix include it as well? yedsterday someone mentioned issues with make? <efraim>iirc the issue yesterday is he needed gcc-toolchain and not just gcc <anonymiss_>but, what's the difference? does gcc-toolchain lack some parts of gcc or is it cusromized for guix? <efraim>it has gcc, ld-wrapper, binutils and libc <anonymiss_>i did not even have gcc-toolchain, maybe that's enough. i'll just try <anonymiss_>no it's not. so i can have gcc-toolchain and full gcc next to each other in my profile? <rekado>anonymiss_: you don't need "gcc" when you have "gcc-toolchain" <rekado>you'd probably get a lot of conflicts having both in the same profile. ***raulet_ is now known as raulet
<anonymiss_>so for being able to `make run`, not compile or install, on a Makefile, gcc-toolchain is not enough it seems. or i have forgotten to export some paths <anonymiss_>-bash: make: command not found. whivh means it's either not in my path or not existing at all. i haven't configured much so far <anonymiss_>oooh. my bad. so much for being used to another system. found it. thanks <anonymiss_>Firefox got weird.. setting up a windows virtual machine on the new debian system of my mother for ms word etc (hopefully she will transition at some point to libreoffice with public services and schools getteinto free software), and Firefox now offers to create an online account at first install.. <rekado>circular dependencies between modules hit me again. <mark_weaver>anonymiss_: what does that have to do with Guix? Guix doesn't have Firefox. <rekado>statistics.scm may not use the haskell.scm module. <rekado>haven't pinned down the cause yet. <rekado>ah, it's the "#:select (libxml2)" in haskell.scm. <davexunit>rekado: are the license variables not prefixed? <davexunit>someone selected libxml2 to avoid a collision between expat in (guix licenses) and (gnu packages xml) <rekado>no, licenses are explicitly imported. <davexunit>rekado: ah, dunno then. maybe no good reason? <mark_weaver>rekado: but 'expat' is one of the licenses that's explicitly imported <mark_weaver>I suspect davexunit was right in his suggestion of what happened here. <mark_weaver>and I would suggest adding a prefix to the (guix licenses) import <fhmgufs>Would it be a good idea to set root's guix profile path to "/"? <mark_weaver>there are regular suggestions to put more things in the standard FHS locations, but that would eliminate the advantages of Guix. <civodul>roelj: thanks for the update on the build status icons <civodul>folks, #:select must be avoided in package modules <civodul>because it is "greedy", which creates problems with circular dependencies <mark_weaver>to be more specific, it's a problem to use #:select in one package module to selectively import from another package module <mark_weaver>iiuc, using #:select to selectively import from (guix licenses), for example, would not be a problem. <fhmgufs>What does it mean if guix build says that it "cannot create directory ‘/usr’: Permission denied" in phase install? <fhmgufs>I think make should have the permissions. <bavier>fhmgufs: a package shouldn't be trying to install anything to '/usr' <bavier>most likely an installation prefix issue <fhmgufs>bavier: I think it means usr in the installation directory not the main /usr. <bavier>the error message you shared says '/usr', I would expect it to say '/gnu/store/.../usr' otherwise <fhmgufs>As I read this it overrides the value generated by ./configure for the LOCALEDIR. <bavier>fhmgufs: if the makefile ignores a value generated by configure, you might need to pass the correct value in #:make-flags <bavier>fhmgufs: please run `guix lint xaos` <bavier>and rather than (alist-delete 'check %standard-phases), use "#:tests? #f" with a comment explaining why <bavier>fhmgufs: I think we could also leave off the last sentence of the description. ***ifur_ is now known as ifur
<davexunit>ACTION pokes at creating standalone binary tarballs for arbitrary applications <fhmgufs>zlib is also imported from licenses. Should I remove it? <davexunit>fhmgufs: it's best to prefix licenses with "license:" <davexunit>#:use-module ((guix licenses) #:prefix license:) <mark_weaver>davexunit: how would you deal with a user wanting to install more than one of those binary tarballs for arbitrary applications? <davexunit>mark_weaver: I'm actually doing this not so people can install binary tarballs into their own guix system, but rather use the application without having guix at all. <davexunit>this is to try to make something that people who just want a binary to lazily run <davexunit>I'm preparing for the "lisp game jam" where participants build a game with lisp in 7 days, and my game will be plyed more if I can supply a binary. <mark_weaver>davexunit: understood, but what happens if someone installs one application that way, and then wants to install another application packaged using the same mechanism? <davexunit>this is so someone can just extract a tarball, cd to the directory created, and run the binary. <davexunit>self-contained. if something else was distributed this way, they would have another isolated directory full of stuff. <mark_weaver>ah, okay. so there will be no /gnu/store references? <davexunit>there will be, and there's no reasonable way around it, so I will need to take advantage of containers to build a file system that has everything mounted correctly. <davexunit>the user will unpack the tarball and run a script that launches a container, bind-mounts the unpacked store items to /gnu, and runs the binary. <davexunit>so as long as the distro the user has supports unprivileged user namespaces, it will work. <davexunit>this is about as much effort as I'm willing to put in to providing binaries. <davexunit>because on principle I really don't like doing it. <tsyesika>hey, just wondering i screwed up the /etc/config.scm the first time on install and I'm wanting to chroot back in to run ´guix system reconfigure` but when i do it says failed to connect to `/var/guix/daemon-socket/socket` I presume i've missed something <davexunit>tsyesika: you cannot use 'reconfigure' if you haven't booted that guixsd system <mark_weaver>tsyesika: I think you have to run "guix system init" again. <wingo>davexunit: yes i want that! being able to build an epiphany nightly would be great <wingo>with the latest webkitgtk and all <wingo>would do wonders for casual testers on non-guix operating systems like debian, fedora, etc <wingo>also gives us a good story against xdg-app <wingo>would be lovely to be able to say to someone "download the nightly and see if it's fixed" <davexunit>wingo: the bundles will be *big* because they include the full closure of the package, but it should work! <wingo>we could eventually start to use binary diffs, or some more intelligent bundle-diff algorithm... <swedebugia>i'm not that versed in iptableish and would much prefer use something like ufw <davexunit>swedebugia: don't think anyone has packaged it <swedebugia>it begs to be a service and that I dunno how to accomplish that ... yet <davexunit>swedebugia: making the package is the first step :) <swedebugia>how do I run guix lint on my slurm package? there is no -f argument to that command and it complains <tsyesika>woot! guixSD installed and booted on my desktop ^_^ <davexunit>swedebugia: the package module needs to be on the load path then <davexunit>if there's a build system argument that does what you want: use it! <davexunit>better than editing phases if there's no need. <fhmgufs>I have sent my GNU XaoS patch to the mailing list, I hope everything is right now! <davexunit>swedebugia: either GUILE_LOAD_PATH or GUIX_LOAD_PATH <davexunit>but I can't say anything for certain because I have no idea how you are doing things <davexunit>typically when one develops a package, they add it to the guix git repo <davexunit>if you're making a package to be kept separate, then you'll need to use GUIX_PACKAGE_PATH <swedebugia>davexunit: ah, none of those are set. should I set it in /root/.bashrc or my user ditto? <davexunit>swedebugia: I don't know because I don't know how you are doing things. <davexunit>is your file a guile module or just a file with some arbitrary code in it? <swedebugia>yeah, submit sounds good. It is in the source tree of guix (uncompiled as of yet) <davexunit>swedebugia: then you shouldn't have to set any environment variables <davexunit>if 'guix lint' can't find it, that means you've done something wrong <wingo>ACTION sends ridiculous dovecot service impl <davexunit>hmmm, how to copy the closure of a store item from within a build container? <davexunit>the binary tarball script uses a profile to accomplish this. <davexunit>however, that doesn't work for me because I don't have a package to use, I just have a file-like object <swedebugia>davexunit: i'm running guix on top of trisquel. I have a lot more error-msg in this environment than on the box with guixsd installed. <davexunit>but when I try to make a profile derivation using that file-like object's derivation output path, it says the path is not valid... which is true because it hasn't been built yet! <davexunit>swedebugia: is the file in question a guile module? is it located in gnu/packages in the source tree? <davexunit>swedebugia: is the package assigned to a public variable? <swedebugia>running export GUILE_LOAD_PATH=~/git-repos/guix/gnu/packages && guix lint renders an error concerning some other scm than the one I created. <swedebugia>maybe I should just run a git pull or compile the tree. (on 0.9.0 binary now) <davexunit>when you're working with the git repo, you need to use the 'pre-inst-env' script <swedebugia>I get a file does not exist when running from the root of the source tree <swedebugia>ah, I would really like to make patches to the docs stating that clearly! <swedebugia>now comes the question. should I compile it with tools from debian or from guix? <davexunit>you can do it with either, but it's easier with guix <davexunit>to spawn a shell with everything you need, run 'guix environment guix' <davexunit>./bootstrap && ./configure --localstatedir=/var <swedebugia>I think I should do a guix pull first. I get an ugly error (the same I got from the lint command above) when running 'guix environment guix' <swedebugia>davexunit: ah forget about it. It was due to the export GUILE_LOAD_PATH set above messing things up. <swedebugia>now the 'guix environment guix' seems to work :) <swedebugia>davexunit: ./bootstrap && ./configure --localstatedir=/var gives me an error about my locale <davexunit>error or warning? "invalid locale" is annoying but harmless <davexunit>swedebugia: if that requirements list is accurate: easy <fps>ok, bspwm is interesting :)