IRC channel logs


back to list of logs

<efraim>jack is also on the list
<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->hmm, still the same.
<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>ACTION has a VPS running GuixSD.
<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?
<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
<nextos>the repos to my home
<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:// seems down though?
<efraim>it might be
<efraim>git pull failed for me
<nextos>i see
<alezost>yeah, it looks like git:// is down. There is also <>
<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
<nextos>./pre-inst-env guix edit
<nextos>if theres only
<nextos>and its not executable
<efraim>you have to ./configure (and make?) first
<nextos>ah, cool
<alezost>efraim: in a git repo you need to run ./bootstrap at first. See the manual: (info "(guix) Building from Git")
<efraim>oh, right
<alezost>efraim: sorry, I meant nextos
<efraim>sorry nextos
<nextos>efraim: thanks
<nextos>i do ./configure --with-libgcrypt-prefix=$HOME/.guix-profile/ --localstatedir=/gnu
<nextos>inside a guix environment guix
<nextos>and after running bootstrap
<nextos>but i get
<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
<alezost>not /gnu
<iyzsong>when use 'guix environment', libgcrypt is not installed into profile.
<nextos>using var leads to the same
<nextos>checking for nix-instantiate... no
<nextos>checking for nix-hash... 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?
<nextos>i think so
<alezost>check that ~/.guix-profile/lib/ exist
<alezost>also I think it shouldn't be "~/.guix-profile/lib/libgcrypt" but "/home/<me>/.guix-profile/lib/libgcrypt"
<nextos>then the README is wrong?
<alezost>nextos: no, I mean in the config.log
<nextos>alezost: i got it now, it was the home expansion, sorry
<nextos>i don't get one concept
<nextos>why not making guix environment guix libgcrypt instead of just guix?
<nextos>for building?
<alezost>I don't understand what you mean: why not making "guix environment guix libgcrypt" instead of just "guix environment guix"?
<nextos>alezost: yes
<alezost>sorry, I think I just don't understand what you want. Anyway, I need to go now
<nextos>alezost: no problem
<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).
<rekado_>it's disgusting.
<davexunit>it's sad that this is what software looks like in 2015
<davexunit>massive dependency circles that no one really understands
<rekado_>"guix graph" ftw!
<rekado_>publishing the full graph ought to be mandatory :)
<davexunit>it's really cool
<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>lfam: the package objects themselves.
<lfam>Right, yeah
<davexunit>first-class data :)
<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>okay, thanks :)
<paroneayea>what's going down in #guix town?
<remi`bd>it’s not clear how to compute the sha256 sum of a directory, anyway, thus I’ll wait for Guix to complain!
<paroneayea>remi`bd: heya
<paroneayea>you need "guix hash -r directory" I think
<paroneayea>let me double check
<paroneayea>the -r is needed for recursive checking
<remi`bd>thanks :D
<paroneayea>remi`bd: np :)
<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 do any armv7 building?
<lfam>Never mind, I see that it doesn't. What kind of machine would be suitable for that purpose?
<davexunit>The Linux Action Show covered Guix recently:
<davexunit>the guix bit starts around 33:53
<davexunit>generally positive, which surprised me.
<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>lfam: the Novena is such a machine.
<davexunit>nothing is confirmed (or at least I don't know about it) but we may have hydra building armv7 binaries soon.
<sneek>Got it.
<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>they're not all there yet.
<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.
<rekado->sneek: what is nothing
<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>hey rekado- figured out the code
<davexunit>sneek: soup is good food, it makes a good meal
<davexunit>sneek: what is guix
<davexunit>sneek: what is soup
<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>I'll keep that in mind.
<davexunit>sneek: what is guix
<sneek>Someone once said guix is a functional package management tool for the GNU system
<rekado->what is nothing
<rekado->sneek: what is nothing
<rekado->ACTION just issued "forget soup" and "forget nothing"
<phant0mas>haha sneek is funny
<daviid>sneek: what is guixsd