IRC channel logs

2014-10-05.log

back to list of logs

<tadni>"guix pull" fails, on a new GNU Distro Alpha install.
<tadni>It fails on my regular install, on my Fedora 20 hostbox too.
<tadni_>Yeah, I guess I'll check the ML tomorrow; Becuase it just seems borked.
<tadni>Well, it's on the mailing list -- or at least a similar issue.
<tadni>Does this make the Distro alpha broke then?
<tadni> http://lists.gnu.org/archive/html/guix-devel/2014-09/msg00486.html
<tadni_>Probably unrelated ... but alpha.gnu.org is down.
<tadni_>Now it's up... weird.
<tadni_>Oh, excuse me -- it's ftp.gnu.org that appears to be down.
<isd>Hey all - I'm trying to package feh. I got most of this done during the hackathon, then got swamped with things afterwards and am just getting back to it. In any case, I'm just trying to sort out dependencies now. It's not building because of missing xlib headers -- what package has those?
<tadni>Hm, do we have xlib packaged even?
<tadni>I know we have like all of xcb.
<isd>Where would it be in the source tree, if it were packaged? I'm not seing the xcb stuff either, so maybe I'm just not looking in the right places.
<isd>Just in gnu/packages?
<isd>ah, nevermind, it looks like its in gnu/packages/xorg.scm
<tadni>isd: Yeah.
<isd>(the xcb stuff anyway)
<tadni>You can just "guix package -s xcb" and find it.
<tadni>It ecen gives what source file it is in.
<isd>looks like it is packaged. libx11
<tadni_>isd: Are you the one who packaged scrot?
<isd>tadni_: I am not.
<isd>why does imlib2 want curl?
<tadni_>isd: I don't know, that's very odd.
<isd>it's not actually listed as a direct dependency
<isd>yet I'm getting an error about it when building imlib2 (as a dep for feh)
<tadni_>Are you aware imlib2 is packaged already?
<isd>hrm, archlinux has it listed as a dep for feh. weird.
<isd>tadni_: yeah, I'm trying to build feh, which depends on it.
<isd>sounds like the dep is feh though.
<isd>huzzah, it built
<tadni>isd: Neat! :^)
<mark_weaver>if you ever want to answer a question such as "why does imlib2 want curl", you can find out by going to the corresponding page on hydra.gnu.org (e.g. <http://hydra.gnu.org/job/gnu/master/imlib2-1.4.6.i686-linux>), select the latest build <http://hydra.gnu.org/build/112517>, click on "build dependencies" or "runtime dependencies", and then search in there for curl.
<mark_weaver>it could also be done programmatically within guix, but I don't think we have a ready-made command to do that easily.
<mark_weaver>note that build dependencies do not always become runtime dependencies.
<mark_weaver>runtime dependencies are always a subset of the build dependencies, iiuc
<isd>that's probably why I'm needing to pull in e.g. xlib myself
<isd>it turns out curl is actually a direct dependency of feh
<isd>still don't know why
<isd>I'm going to investigate further
<mark_weaver>what is feh?
<isd>mark_weaver: image viewer
<tadni>mark_weaver: Image viewer and wallpaper setter.
<mark_weaver>maybe it includes the ability to download images.
<isd>maybe. I found it surprising. I'm going to look it up
<tadni>Well, I have no idea why Fedora spits "configure.ac:55: error: possibly undefined macro: PKG_CHECK_MODULES" now...
<tadni>
<isd>yeah, looks like that's basically it.
<tadni>Coming back to guix, after about a month break ... has been problematic on all accounts.
<isd>tadni: what package?
<tadni>isd: Trying to build guix for git checkout.
<mark_weaver>tadni: that's because you didn't have 'pkg.m4' (part of pkg-config) installed when you ran autoreconf -vfi.
<mark_weaver>(autoreconf -vfi is run by ./bootstrap)
<tadni>I did/do though?
<mark_weaver>well, maybe there's some dev package that you're missing.
<mark_weaver>do you have a file pkg.m4? on debian it would probably be in /usr/share/aclocal. not sure if fedora is putting it somewhere else these days.
<tadni>Yeah, I have a /usr/share/aclocal
<tadni>Also, there's no pkgconfig-devel.
<mark_weaver>in general, if configure ever fails while apparently trying to run some command in all uppercase like that, it's really an m4 macro that was missing at the time at autoconf/automake was invoked (typically done via autoreconf -vfi)
<mark_weaver>tadni: does /usr/share/aclocal/pkg.m4 exist?
<mark_weaver>that's the file you need.
<tadni>Yup, it's in there.
<mark_weaver>are you sure it was there when you ran ./bootstrap?
<tadni>Like 95%, I can pull it down again and try.
<mark_weaver>maybe /usr/share/aclocal is no longer in the default search path for autoconf on fedora these days.
<mark_weaver>there's an ACLOCAL_PATH environment variable you can set, to augment the search patch for .m4 files.
<mark_weaver>you could try setting ACLOCAL_PATH=/usr/share/aclocal and then rerunning autoreconf -vfi
<mark_weaver>but this all sounds fishy. I'd expect fedora to put pkg.m4 in a place where it would be found by their autotools.. (or did you install autotools and/or pkg-config manually?)
<tadni>Pulled and ran bootstrap again, and nothing. Tried setting ACLOCA_PATH and running autoreconf, and nothing.
<tadni>mark_weaver: Nope, via dnf.
<mark_weaver>dnf?
<tadni>mark_weaver: It's the "new yum".
*tadni is considering using this as an excuse just to install the Fedora 21 Alpha on this box.
<mark_weaver>well, I suspect you're making some mistake here.
<mark_weaver>I assume you exported ACLOCAL_PATH ? and ran "autoreconf -vfi" from the same shell where you had set ACLOCAL_PATH ?
<tadni_>Yeah.
<mark_weaver>and you still end up with PKG_CHECK_MODULES in the generated configure file?
<tadni_>OOOOOOOOOOOOOh!
<tadni_>No, I didn't export it.
<tadni_>Sorry.
<mark_weaver>:)
<tadni_>Let me check now.
<tadni_>mark_weaver: Yup, making! Ty! :^)
<mark_weaver>cool :)
<tadni_>So am I right to assume the Alpha Distro is borked now? A major driver for me wanting to get this working tonight, was to be able to generate a usb-install image.
<mark_weaver>this sounds like a fedora bug, though.
<mark_weaver>huh?
<tadni_>mark_weaver: I reinstalled GNU Distro Alpha today on a spare box, tried pulling, and it fails now. Checked on the ML and one needs 0.7 or a recent git grab to use the commit that fixes it... and since the test distro ships with 0.6...
<mark_weaver>hmm, okay
<tadni_>I'm assuming this is the case, I'll bring it up on the ML either way soon enough.
<tadni_>Does the generation of a usb-install take the latest guix pull ... or is it based on a release?
<mark_weaver>what I did is to install using the alpha usb installer, and then build guix from git within that instal.
<mark_weaver>that allowed me to avoid building the usb installer myself.
<mark_weaver>but your way sounds good too. hopefully it will work.
<tadni_>Okay, the install image is building.
<isd>What hypervisor does guix vm use?
<isd>Also: is there a nice way for me to get a chroot or the like of a guix system? Or just general tips on testing a package without doing intrusive things to my existing linux system?
<tadni_> isd: I mean, most just install guix and use the ./pre-inst-env
<tadni_>I guess you could just use a vm?
<tadni_>Also, I think guix vm uses qemu.
<tadni`>Well, guix's disk-image generator pulls from the latest release -- not guix-latest.
<isd>tadni`: what I'm not clear on is how I actually get a shell running in guix; it looks like feh built successfully, but I want to actually *run* it to make sure.
<isd>I am very surprised that I'm having trouble finding this in the manual.
<mark_weaver>isd: you can install guix on a normal system and it is totally non-intrusive. literally, the only directories that are changed are: /gnu, PREFIX/var/guix, and PREFIX/var/log/guix.
<mark_weaver>and in your user directory, there's a symlink ~/.guix-profile that points to a tree of symlinks in one of those aforementioned directories.
<mark_weaver>so you have to set PATH and some other environment variables to point to guix's stuff, otherwise it is all totally out of the way.
<tadni`>... Well, evidently a newly generated guix disk-image comes with 0.7 and installs 0.6, like the current install image.
<mark_weaver>heh
<tadni`>I wonder how much of a pain it really is to install guix from git on the distro... it wasn't as easy as Fedora, last time I checked/tried.
<mark_weaver>you just have to use "guix package -i" to install all the packages needed to build guix from git, same as on any other system.
<tadni`>Does guix have a "build depend" tool?
<mark_weaver>and that's work you'll have to do anyway, if you intend to use your guix system to do development on guix (or pretty much anything else)
<isd>mark_weaver: I'm not seeing ~/.guix-profile. At what point is this supposed to appear?
<tadni`>Build depend makes it super easy, to say build Guile from git in Fedora.
<mark_weaver>isd: after running "guix package -i <packages>" (which you run as your normal user, not as root, btw)
<mark_weaver>(if you run it as root, then you'll get ~root/.guix-profile, which you could also do I suppose)
<mark_weaver>tadni`: we don't yet have anything like that, but I suppose it would be a good thing.
<isd>mark_weaver: thanks.
<mark_weaver>tadni`: btw, one of the packages you'll want to install is "gcc-toolchain".
<mark_weaver>that covers glibc, binutils, and gcc, but also with ld-wrapper, which is a little finicky to get right otherwise.
<mark_weaver>(ld-wrapper has to take precedence over the one from binutils, in order to have the built programs use rpaths to find the same shared libraries they were built against)
<mark_weaver>tadni`: two other important notes: when building guix within guix, it's important to pass --localstatedir=/var to configure, or else the built guix will not look in the right place for the sqlite database that's already on the system. (and things won't work properly otherwise).
<mark_weaver>tadni`: and you'll also need to pass --with-libgcrypt-prefix=/gnu/store/XXXX-libgcrypt-XXXX (the first line output by "guix build libgcrypt")
<mark_weaver>anyway, time for me to sleep. good luck!
<tadni`>mark_weaver: Ty, peace. o/
<mark_weaver>also, I recommend _not_ running "make install" if you intend to help contribute to guix. just always run guix using "./pre-inst-env guix ..." from within the git build directory. or, to make it more convenient, I put a little shell script in ~/bin/guix that does this: exec /path/to/guix/git/pre-inst-env guix "$@"
<mark_weaver>in my case, it's: exec /home/mhw/guix/pre-inst-env guix "$@"
<mark_weaver>okay, now I'm really going to sleep.. :)
<isd>okay, patch submitted. I'm going to call it a night.
<tadni`>Well, I'm done for tonight. It's spewing a syntax error near "have_guile_json" -- even after I installed it.
<tadni> Woke up this morning, repulled it from git and ran the bootstrap -- and it's not complaining about json now. Odd... but yah, currently building!
<jmd>I cannot get guix to download from https urls. Is it at all possible?
<civodul>hello, jmd
<civodul>jmd: is it through "guix download" or "guix build -S"?
<civodul>in the former case, you need to make sure the Guile bindings of GnuTLS are installed and visible in the load path
<jmd>Both I think.
<jmd>wait, I'll check
<jmd>What does build -S do ?
<jmd>... anyway, I can't get either to work.
<jmd>How do I "make sure the Guile bindings of
<jmd>I have (modules '((guix build utils))) Shouldn't that have done the job?
<jmd>
<civodul>hmm
<civodul>"guix build -S foo" fetches the source of package "foo"
<civodul>it does so in a controlled environment where GnuTLS is available if needed
<civodul>could you copy/paste the command and error?
<jmd> http://paste.lisp.org/+332I.
<jmd> http://paste.lisp.org/+332I/1 contains the code
*civodul tries
<civodul>jmd: i think it's an instance of http://bugs.gnu.org/18526
<civodul>unfortunately we have to wait for a GnuTLS release now
<civodul>i'm trying to make sure it really is the same problem
<jmd>ok. I'll use a local workaround for now.
<jmd>Or perhaps hydra or somewhere could mirror sane ?
<civodul>or does alioth offer a non-HTTPS URL?
<jmd>No.
<jmd>At least I haven't found one.
<civodul>jmd: there's ftp://ftp2.sane-project.org/pub/sane/sane-backends-1.0.23.tar.gz, which is the version just before
<civodul>perhaps we could package this one while waiting for the GnuTLS release?
<civodul>(it should be a matter of days, i think)
<jmd>Maybe I'll wait a couple of days then.
<civodul>yeah, sorry i don't have a better answer
<civodul>jmd: actually there's also http://fossies.org/linux/misc//sane-backends-1.0.24.tar.gz
<jmd>civodul: No problsm.
<civodul>found on http://www.linuxfromscratch.org/~krejzi/blfs-git/pst/sane.html
<tadni>Well, Emacs dumps on GNU distro.
<civodul>tadni: tell us more :-)
<civodul>it works for me™ on x86_64
<DusXMT>works here as well, i686
<tadni>Well, this a pain to get a paste going... sec.
<tadni> http://paste.lisp.org/display/143948
<tadni>I can run "emacs -nw" without a problem.
<civodul>tadni: is it on the standalone system, or on some other distro?
<tadni>civodul: Dedicated box, I just installed last night and pulled to latest today.
<civodul>ok so it's the whole system, right?
<tadni>Yup.
<civodul>then you may need to add dbus-service to the config
<civodul>or just run dbus-uuidgen manually
<tadni>Well, ran dbus-uuidgen and it fails with the same issue.
<civodul>and does /etc/machine-id exist now?
<tadni>Nope.
<tadni>It generates a string of charecters and numbers, do I just need to write a file with it?
*tadni goes to see.
<tadni>Yup, thanks, that was the issue.
<tadni>Yah! :^)
*tadni finally got this spare laptop back from his friend, so he'll probably be more motivated to work on more guix packages, more often!
<tadni>Clisp and Stumpwm, outside of some sort of network manager, is all that I really need anymore to do GNU Distro 24/7. :^)
<civodul>ahah :-)
<civodul>oh we have gcl but not clisp
<tadni>civodul: Yeah, I should probably see if it build on it ... but, I think Clisp is used more often than gcl anyways, so? :^P
<jmd>I had a go at packaging Clisp but ran into a lot of problems.
<tadni>jmd: Example(s)?
*tadni wishes he could just happily live in guile-wm, but I don't see that happening.
<jmd>tadni: I don't remember the details
<jmd>Just that I concluded that packaging clisp would require a lot more familiarity with how it works.
<tadni_>Well, bummer, I thought it looked as if it'd be fairly straight forward.
<tadni_>Anyone running GNU Distro know why Emacs can find some fonts and not others?
<tadni_>Like it can't find dejavu.
<civodul>tadni_: it looks for fonts in your profile, so you have to explicitly install them
<civodul>i have gs-fonts, freefont-ttf, and ttf-dejavu
<tadni_>What do you mean by, "explicitly install them"?
<civodul>run "guix package -i gsfonts ..."
<civodul>*gs-fonts
<tadni_>Yeah, I have for dejavu and freefont, but it's not in there.
<civodul>not in there?
<tadni_>As in, it's not poping up in Emacs's font selection pane.
<tadni_>Not sure where it'd be in my .guix-profile
<mark_weaver>you might have to restart emacs for it to notice the new fonts
<tadni_>Well, found it in /share/fonts/truetype.
<tadni_>mark_weaver: I'll try again, but did already.
<mark_weaver>works for me
<tadni_>Yup, not there.
<tadni_>Started a whole new emacs process.
<tadni_>Is it maybe not in my load path...?
<tadni_>Yeah, I don't think it is -- because the default fonts emacs finds are not in this directory.
<mark_weaver>our fontconfig is configured to look in ~/.guix-profile/share/fonts by default (see gnu/packages/fontutils.scm line 88)
<mark_weaver>I wonder if you have an environment variable setting, or configuration file copied from another system, that overrides that somehow.
<mark_weaver>for me, it just worked on my standalone guix system, with no configuration necessary.
<tadni_>I mean, I don't think I have any env vars that are copied over from anywhere and my only configuration file is a .emacs that doesn't do any messing with fonts.
<mark_weaver>maybe run emacs within strace and see where it's looking for fonts during startup
*mark_weaver goes afk
<tadni_>Doing a "grep /fonts /var/log/Xorg.0.log" and it only pulls up ${prefix}/share/fonts/X11/...
<tadni_>So it seems to be missing /share/fonts/truetype entirely.
<mark_weaver>that's the legacy server-side font stuff, which modern toolkits no longer use.
<mark_weaver>hmm, are you using the 'emacs' package, or 'emacs-no-x-toolkit'? if the later, that may be the issue.
<tadni_>GTK one.
<civodul>how does one access the font selection pane in Emacs?
<tadni_>Is there a place where I can sheck the fontpath?
<civodul>oh i see
<mark_weaver>civodul: you can select "Set default font..." from the Options menu.
<civodul>yes, just found it :-)
<mark_weaver>the dejavu fonts are in there for me.
<civodul>same here
<tadni_>... :^/
<civodul>tadni_: so you installed all 3 font packages, restarted Emacs, and nothing shows up?
<tadni_>civodul: Yup.
<civodul>nothing, or just a limited list?
<tadni_>civodul: Limited.
<civodul>so what's missing exactly?
<tadni_>Nothing in the /share/fonts/truetype/ directory.
<civodul>there's no /share directory
<tadni_>Everything is from /share/fonts/X11
<civodul>oh
<tadni_>From .guix-profile/share/...
<civodul>yes
<civodul>so DejaVu is missing, right?
<tadni_>civodul: Everything from the truetype directory, so yeah, dejavu and freetype.
<civodul>ok
<civodul>could you leave Emacs, rm -rf ~/.cache/fontconfig, and restart Emacs?
<civodul>it should re-populate the cache
<mark_weaver>oh, right!!
<mark_weaver>forgot about that :-(
<tadni_>civodul: Yup, that was it; Just fantastic, thanks! :^)
*tadni_ will brb, going to close this old Emacs session.
<mark_weaver>civodul: would it be possible to have "guix package -i" advise users of this fact when they install one of the ttf font packages?
<mark_weaver>(as part of a more general mechanism, of course)
*tadni_ is going to grab some late lunch -- he'll be back in about an hour.
<civodul>tadni_: good!
<tadni_>Thanks for all the help though, you two, this install is coming along a lot better than I expected. :^)
<civodul>tadni_: could it be that .fontconfig was inherited from a previous system, for instance because you reused an existing /home partition?
<civodul>mark_weaver: yes, that would be nice
<tadni_>civodul: Reformated completly, on this install; So I don't think so...
<tadni_>Okay, I'll bb in like an hour or so. o/
<tadni_>
<mark_weaver>I think maybe all it takes is running emacs (or anything else that uses fontconfig) and then later installing a new font.
<civodul>and then the cache is stalled and fontconfig doesn't notice?
<mark_weaver>right. it might have to do with our policy of setting all timestamps to the epoch, dunno.
<civodul>yeah
<mark_weaver>I suppose we could enhance fontconfig's method of checking cache freshness, perhaps by taking note of the destination of the .guix-profile symlink, or something.
<mark_weaver>not very nice though, and unlikely to be accepted upstream.
<civodul>indeed
<tadni_> Back.
*davexunit attempts to implement 'guix environment' again