<rekado->efraim: "guix size" works on whatever is in the store, so I think this is a somewhat older build of mpv. <rekado->I'm building the latest version now and will compare the output. <rekado->bleh, never mind. The input is called "jack-2". I'm going to prepare a patch to replace "jack-2" with "jack-1" where possible. <iyzsong>not know what to play with it, but lshd work fine with ssh clint :-) <efraim>i'm having a bit of trouble with a package i'm packaging. I'm trying to take out the configure stage and put in autogen before the build phase. Something's not working right for me. any suggestions? https://pastee.org/h282 <alezost>efraim: 'alist-cons-before' is unbound because you don't use (guix build utils) module. <alezost>But better use 'modify-phases' macro instead (from the same module). <alezost>Also 'autogen' phase should be added after 'unpack', not before 'build'. Grep for "autogen" in gnu/packages dir: you'll see many similar examples <nextos>hello, i want to update a package and send a patch. guix edit leads me to a write protected file <nextos>what's the way i should do this? <alezost>nextos: guix edit leads you to a file in /gnu/store. You can't (and shouldn't) edit any file from store <nextos>yes, i kind of got that. So should i clone <alezost>yes, to send a patch, you need to work with a git repo <alezost>more precisely "guix edit" finds a package in "~/.config/guix/latest" which is usually a symlink to a store dir. "./pre-inst-env guix edit" in the repo dir will open a package file from this repo <nextos>git://git.savannah.gnu.org/guix.git seems down though? <nextos>alezost: thanks, that one is reachable <efraim>my package is looking good, except that /gnu/store/...-autoconf-2.69 doesn't have autopoint <efraim>so it's back to saving it for later <alezost>efraim: I see that "gettext" package has autopoint <efraim>I'll add that as a native-input and see if that works <nextos>lame question but how am i supposed to do <efraim>you have to ./configure (and make?) first <alezost>efraim: in a git repo you need to run ./bootstrap at first. See the manual: (info "(guix) Building from Git") <nextos>i do ./configure --with-libgcrypt-prefix=$HOME/.guix-profile/ --localstatedir=/gnu <nextos>configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'. <alezost>nextos: look at config.log. Perhaps $HOME wasn't expanded <iyzsong>nextos: I use "./configure --with-libgcrypt-prefix=`pkg-config --prefix libgcrypt` --prefix=". <alezost>btw it should be --localstatedir=/var <iyzsong>when use 'guix environment', libgcrypt is not installed into profile. <nextos>checking for nix-instantiate... no <nextos>checking for Nixpkgs source tree... not found <nextos>checking for libgcrypt shared library name... ~/.guix-profile/lib/libgcrypt <nextos>checking whether ~/.guix-profile/lib/libgcrypt can be dynamically loaded... no <alezost>nextos: did you really installed libgcrypt into your profile? <alezost>check that ~/.guix-profile/lib/libgcrypt.so exist <alezost>also I think it shouldn't be "~/.guix-profile/lib/libgcrypt" but "/home/<me>/.guix-profile/lib/libgcrypt" <alezost>nextos: no, I mean in the config.log <nextos>alezost: i got it now, it was the home expansion, sorry <nextos>why not making guix environment guix libgcrypt instead of just guix? <alezost>I don't understand what you mean: why not making "guix environment guix libgcrypt" instead of just "guix environment guix"? <alezost>sorry, I think I just don't understand what you want. Anyway, I need to go now <rekado_>working on Java again; to build maven we need maven to build maven's many dependencies. <rekado_>alternatively we could download two binaries used to bootstrap maven. <rekado_>(I hope it's just two and not all of their dependencies.) <davexunit>rekado_: bummer. there's no way that we could just collect maven's dependencies without using maven? <davexunit>every single language that we try to support reveals another ridiculous architecture decision <rekado_>davexunit: I tried to trace the dependency tree, but it's massive. <rekado_>the two plugins maven needs to build a minimal version of itself using ant have a very large number of dependencies, most of which need maven (or need tools that need maven to build them). <davexunit>it's sad that this is what software looks like in 2015 <davexunit>massive dependency circles that no one really understands <rekado_>publishing the full graph ought to be mandatory :) <davexunit>I think it can used well for "marketing" purposes. <lfam>The visual graph is very nice for humans but is there a "machine readable" format for dependency graphs? <davexunit>I've been thinking about fun ways to incorporate Guix with my game engine written in Guile. <davexunit>maybe a little package browser with pixel art style graphics would be fun. <lfam>It would truly be first class if dep graphs were considered part of source code <lfam>I guess that's what Makefiles are <davexunit>I don't understand. The source code is just text, but the result of evaluating that code is all of the information that you'd want to know about the dependency graph. <remi`bd>how should I compute the sha256 sum of a package I’m writing a recipe for? <remi`bd>especially, I’m writing a recipe for a package retrieved via svn, thus I have no archive to compute the sum of. <rekado_>remi`bd: what I often do is start building. Guix will complain and tell you the hash. <davexunit>remi`bd: we have 'guix download', but it doesn't currently know how to handle things that aren't tarballs, so you can either do has rekado_ suggested or clone the svn repo and delete all of .svn or whatever directories have all the svn stuf. ***hacker is now known as y
<remi`bd>it’s not clear how to compute the sha256 sum of a directory, anyway, thus I’ll wait for Guix to complain! <DusXMT>I wonder, is it possible to install GuixSD's grub into a partition? I'm installing a system (currently building Guix on a temporary debian chroot I set up on a scrap partition from a live CD, since this machine can't boot off of USB), and I want to dual-boot the GNU Hurd, which guix's Grub doesn't support yet (you can make custom menu entries for it, but currently only for Linux-based system)... or would it p <DusXMT>erhaps be better to just build the Grub configuration and load that from the Hurd's grub? <DusXMT>By installing grub, I mean the bootcode, which can then be chainloaded by a different instance of Grub <DusXMT>Or I may just add the Hurd entry manually after a "guix reconfigure", before I attempt adding multiboot support to Guix's grub... <lfam>Does hydra.gnu.org do any armv7 building? <lfam>Never mind, I see that it doesn't. What kind of machine would be suitable for that purpose? <davexunit>of course they pointed out that "it's not a looker" <davexunit>which is true since we don't have GNOME and other eye candy easily available yet. <davexunit>nothing is confirmed (or at least I don't know about it) but we may have hydra building armv7 binaries soon. <davexunit>sneek: you react to some weird stuff sometimes <daviid>davexunit: out of curiousity, why no GNOME on guix yet? it seems that all gnome modules are there already <davexunit>wingo has made great progress on this recently though <davexunit>he had to extract a part of systemd into a standalone daemon <daviid>owh, that'sd fantastic that wingo takes care of that part! <davexunit>maybe by the next release we'll have gnome as the default DE. that would be wonderful. <sneek>Someone once said nothing is confirmed (or at least I don't know about it) but we may have hydra building armv7 binaries soon. <davexunit>sneek: soup is good food, it makes a good meal <sneek>I've heard soup is good food, it makes a good meal <davexunit>sneek: guix is a functional package management tool for the GNU system <sneek>Someone once said guix is a functional package management tool for the GNU system <rekado->ACTION just issued "forget soup" and "forget nothing"