IRC channel logs

2015-04-13.log

back to list of logs

<Sleep_Walker>morning
<Sleep_Walker>is lzip prefered over xz for any reason?
<Sleep_Walker>(I heard about lzip for the first time in 'Self-contained Guix tarball' mail)
<civodul>Hello Guix!
<Sleep_Walker>morning
<kete>Sleep_Walker, lzip is more like Unix, less proprietary, and compresses more than xz: http://www.nongnu.org/lzip/lzip_benchmark.html
<Sleep_Walker>kete: thank you! interesting reading
<taylanub>well that's a surprise
<taylanub>I wonder why xz caught all the attention when lzip is older and works just as good or better
<Sleep_Walker>I'd love to see some more benchmarks though
<Sleep_Walker>yeah, first implementation I knew about was 7-zip, but that also implements archive container, I expected to see some tool similar to gzip and bzip2
<Sleep_Walker>than I have found xz and lzma as being used
<Sleep_Walker>*then
<civodul>kete: xz is free software as well, only non-copyleft
<taylanub> https://blogs.gentoo.org/mgorny/2014/02/22/a-few-words-on-lzip-compressor/ points out some "weird" aspects of lzip, such as having no public repo. (maybe it changed on the meanwhile)
<kete>civodul, thanks
<Sleep_Walker>taylanub: thx
<Sleep_Walker>well, I don't care using any of them, I was just wondering if it is some "new default"
<civodul>indeed, i can't see a public repo
<civodul>that sucks
***boegel|quassel is now known as boegel
<Sleep_Walker>hm, only empty CVS
<taylanub>what's with user and group ownership in /gnu/store again? should it all be root:root, or is it normal that some have group guix-builder?
*wingo rebases on top of core-updates
<wingo>download all the things!
<atheia>ALL the things?, he asked one-and-a-half hyperbolically.
<wingo>'sa lot of things yo
<Sleep_Walker>hm, it seems I miss `pkg-config' in my `guix environment guix' environment
<Sleep_Walker>ok, I may not be up-to-date yet
<Sleep_Walker>pkg-config is really missing, but it seems I miss more
<Sleep_Walker>any ideas, what I miss in my environment? http://paste.opensuse.org/view/raw/99680526
<mark_weaver>somehow, the guix-devel package builds successfully without pkg-config
<mark_weaver>it needs the --with-libgcrypt-prefix configure flag though
*davexunit is excited to try out ludo's binary guix bundle.
<mark_weaver>Sleep_Walker: you should probably pass --pure to 'guix environment guix' to help avoid picking up anything from your host system
<rekado_>I just updated the hash of "rseqc"; upstream replaced the tarball after I packaged it without changing the version number :-/
<mark_weaver>that would cause trouble, and I suspect your problem is related to that.
<Sleep_Walker>mark_weaver: I'll try, thanks
<mark_weaver>rekado_: can you post the diffs?
<rekado_>of the tarballs?
<mark_weaver>yes
<rekado_>let me check
<mark_weaver>you can get the old one using 'guix build -S' with the old hash
<mark_weaver>(from hydra)
<rekado_>ah, nice.
<mark_weaver>we should send a message to upstream asking them not to do that
<mark_weaver>I can do it if you like
*mark_weaver goes afk for a while
<rekado_>hmm, I can't get the old tarball with "guix build -S".
<mark_weaver>rekado_: you need to revert your update of the hash
<mark_weaver>to get the old one
<rekado_>yes, I still have the old hash in place.
<rekado_>(different machine)
<rekado_>maybe it's too long ago that rseqc was built successfully?
*mark_weaver looks
<Sleep_Walker>mark_weaver: --pure doesn't seem to have any effect, pkg-config is required by `./configure
<Sleep_Walker>'
<davexunit>Sleep_Walker: what package is this?
<Sleep_Walker>guix
<davexunit>'guix environment guix' ?
<Sleep_Walker>exactly
<davexunit>what's the value of $PATH ?
<davexunit>try 'guix environment guix -E "bash --norc --noprofile"'
<rekado_>apparently, even the oldest evaluation on hydra failed because of a hash mismatch, but it's a different hash than the current one.
<rekado_>seems that the authors have replaced the tarball more than once since I packaged it in February.
<mark_weaver>rekado_: it has _never_ built successfully on Hydra. from the first time Hydra tried (2015 Feb 20), the hash of the source tarball has not matched what it downloaded.
<mark_weaver> http://hydra.gnu.org/job/gnu/master/rseqc-2.6.1.x86_64-linux/all
<mark_weaver> http://hydra.gnu.org/build/261407
<rekado_>yes, I just saw this. I pushed it two days before that.
<Sleep_Walker>davexunit: it started interactive bash
<mark_weaver>rekado_: we should ask them not to do this
<mark_weaver>horrible
<rekado_>I'll write them.
<mark_weaver>thanks!
<davexunit>Sleep_Walker: does 'which pkg-config' yield anything?
<Sleep_Walker>davexunit: yes, it does
<mark_weaver>rekado_: can you CC me on the email please?
<davexunit>Sleep_Walker: does './bootstrap; ./configure' work?
<Sleep_Walker>davexunit: yes
<rekado_>mark_weaver: will do.
<davexunit>Sleep_Walker: any remaining problems?
<Sleep_Walker>all
<Sleep_Walker>linker issue, pkg-config still needed for configure
<mark_weaver>pkg-config is not in the inputs for guix-devel. apparently it builds successfully without it
<mark_weaver>but if it picks up your system pkg-config, there will be trouble
<davexunit>Sleep_Walker: so 'which pkg-config' must point to something not in /gnu/store, yes?
<davexunit>try a pure environment again.
<mark_weaver>trying to build anything with a mixture of libraries from guix and from the host system will cause problems.
<mark_weaver>your paste smells of that
<Sleep_Walker>davexunit: yes
<Sleep_Walker>now no pkg-config found
*mark_weaver goes afk
<davexunit>Sleep_Walker: did you rebootstrap?
<davexunit>that's important
<Sleep_Walker>...in progress...
<Sleep_Walker>autoreconf failed on missing autopoint :[
<mark_weaver>graphviz is in the native-inputs for guix-devel. it should be there.
<mark_weaver>davexunit: does 'guix environment' include native-inputs?
<rekado_>I'm still having problems building OpenJDK7 with OpenJDK6 --- I would be very happy for any ideas what to try next: http://lists.gnu.org/archive/html/guix-devel/2015-03/msg00793.html
<davexunit>mark_weaver: yes
<davexunit>I build my own projects this way, with packages defined with native inputs.
<davexunit>is 'guix environment guix' use the guix-devel package currently?
<davexunit>s/is/does/
<Sleep_Walker>should I invoke it `guix environment guix-devel'?
<davexunit>guix-devel is just the variable name, not the package name
<Sleep_Walker>autopoint exists in /gnu/store/*-gettext-*/bin
<Sleep_Walker>but doesn't get to environment
<davexunit>so, let's try something that ensures we get guix-devel...
<davexunit>guix environment -e '(@@ (gnu packages guix) guix-devel)' --pure
<davexunit>wrote that off the top of my head
<davexunit>not in a situation where I can test
<davexunit>hopefully it works
<Sleep_Walker>guix environment: error: failed to evaluate expression `(@@ (gnu packages guix) guix-devel)': (unbound-variable "module-lookup" "Unbound variable: ~S" (guix-devel) #f)
<davexunit>oh sorry, silly mistake
<davexunit>(gnu packages package-management)
<davexunit>not (gnu packages guix)
*Sleep_Walker feels like interactive shell :)
<davexunit>hehe
<Sleep_Walker>that did something
<davexunit>yeah, I'm relying on you to give me feedback since I'm not using a computer with guix on it. :)
<Sleep_Walker>bootstrap passed (autopoint apparently found)
<Sleep_Walker>running build
<davexunit>okay, so 'guix environment guix' must have used the guix package that builds from the release tarball, which doesn't require gettext and such
<Sleep_Walker>good to know, thanks!
<davexunit>I guess our docs should recommend: guix environment -e '(@@ (gnu packages package-management) guix-devel)'
<davexunit>not as convenient, but people will copy/paste anyway
<davexunit>or, and I don't know how others will feel about this, we could a convention I've established for my own projects:
<davexunit>include a 'package.scm' file in the root of the source tree that defines a guix package for use with 'guix environment'
<davexunit>but for guix, it would just be redundant
<davexunit>since we have guix-devel in another module.
<paroneayea>civodul: https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00247.html makes me think a .deb of guix is even more feasible
<paroneayea>I really want to have such a thing :)
<davexunit>yeah, if folks could 'dpkg -i guix-x.y.z.deb', that would be great
<davexunit>it would bridge a mighty gap
<paroneayea>nully: you've got lots of free time right? :)
<paroneayea>;)
<paroneayea>I hear you can .deb
<civodul>paroneayea: i agree it would be nice, but it wouldn't be accepted in upstream Debian
<civodul>because of the FHS violation
<paroneayea>civodul: why not?
<paroneayea>oh
<paroneayea>:<
<paroneayea>civodul: I wonder if there's a workaround!
<davexunit>civodul: we could offer a deb, though
<paroneayea>putting it in /var/ something
<paroneayea>/var/cache/gnu/ ;)
<davexunit>paroneayea: that changes the hash of all the derivations
<paroneayea>hm
<civodul>davexunit: yes, sure
<davexunit>so we'd a completely separate build
<davexunit>we'd need*
*paroneayea nods
<paroneayea>hrm
<davexunit>I hadn't thought of FHS thing
<Sleep_Walker>davexunit: that worked - thanks!
<paroneayea>well having a .deb on the guix website that's guix-endorsed would help a lot
<davexunit>Sleep_Walker: yay!
<Sleep_Walker>now finally the fun part
<civodul>i'd like to get feedback regarding the binary tarball, hopefully that helps a bit already
<davexunit>civodul: I'm going to try it out on my Linode VPS
<paroneayea>maybe even something to put something in /etc/apt/sources.list
<paroneayea>:)
<civodul>davexunit: nice!
<davexunit>civodul: I still have to do stuff to create the users and groups, right?
<davexunit>pjotrp installing it on 5 machines this morning is promising
<civodul>davexunit: yes, the daemon setup is still manual
<civodul>we could provide a script, but i'd rather let users do that consciously
<davexunit>civodul: okay, that's fine. it still really helps bootstrap things.
<paroneayea>civodul: I think it would be nice, if a .deb exists, for the .deb to do that automatically
<paroneayea>just as installing postgres installs a postgres user, etc
<civodul>yes, for a .deb it would be natural
<civodul>right
<davexunit>the thing that is impressive to me is that you were able to build this self-contained tarball with not much code at all
<davexunit>it's like a single page of code.
<davexunit>awesome.
<civodul>yeah it's one of this "why haven't we done this before?" moments ;-)
<mark_weaver>civodul: yeah, I was really impressed at how concise the code is. it makes me realize that I need to learn more guix internals.
<davexunit>same
<davexunit>I haven't grokked gexps yet
<mark_weaver>ditto
<davexunit>but I can see that they are incredible
<mark_weaver>well, I've partially grokked them but my understanding of them is somewhat limited.
*wingo reboots into linux 4.0
<davexunit>nice!
*davexunit is running 'guix pull' on his VPS
<davexunit>:)
<civodul>davexunit: so you went this far?
<civodul>sounds like rather good news? :-)
<davexunit>civodul: yeah, it works!
<davexunit>it's awesome
<civodul>good!
<davexunit>the only issue:
<davexunit>warning: failed to install locale: Invalid argument
<davexunit>I feel like I should know the answer to the following question by now, but I don't: why does 'guix package -i emacs' need to download gcc if it is not building from source?
<civodul>right, you need to define LOCPATH
<civodul>i guess it downloads the "lib" output of gcc, no?
<civodul>it contains libgcc_s, libgomp, libstdc++, etc.
<civodul>it's /gnu/store/...-gcc-4.8.4-lib
<davexunit>civodul: ah, okay.
<davexunit>civodul: it doesn't specify -lib
<davexunit>/gnu/store/4sqgnc9bc1kmn058yp4xnj4vpydmfzpq-gcc-4.8.4
<civodul>oh
<civodul>then it's something else
<civodul>the emacs binary has a reference to /gnu/store/4sqgnc9bc1kmn058yp4xnj4vpydmfzpq-gcc-4.8.4
<civodul>not sure why
<civodul>$ strings /gnu/store/3fcrad1hsw5vbp61lqdnb1xdxh51q867-emacs-24.5/bin/.emacs-24.5-real |grep 4sqgnc9bc1kmn058yp4xnj4vpydmfzpq
<civodul>/gnu/store/4sqgnc9bc1kmn058yp4xnj4vpydmfzpq-gcc-4.8.4/bin
<civodul>oh this is terrible: it has a reference to each item of its built-time $PATH
<davexunit>glad I found it, then. :)
<taylanub>perhaps the `exec-path' variable in the dumped emacs executable
<davexunit>in other news, I set my $LOCPATH and I still get the warning...
<davexunit>is there a guix package I need to install?
<civodul>taylanub: yes, it's PATH_EXEC in epaths.in apparently
<civodul>davexunit: glibc-utf8-locales, for instance
<davexunit>civodul: thanks
<davexunit>sort of a silly question, but this is the first system I've had such an issue with
<davexunit>hmmmm
<davexunit>export LOCPATH=$HOME/.guix-profile/share/locale
<davexunit>still nothing
<civodul>export LOCPATH=$HOME/.guix-profile/lib/locale, i think
<davexunit>sigh, that was it.
<davexunit>thanks civodul
<davexunit>sorry for the hassle
<civodul>np!
<civodul>we should document it somewhere i guess
<davexunit>I've been wondering if 'guix package --search-paths' should print out stuff like this
<civodul>unfortunately it only does so when both glibc and glibc-utf8-locales are installed
<civodul>taylanub: it's not just epaths.{in,h}, i wonder where that $PATH comes from
<civodul>anyway
<civodul>ttyl!
<davexunit>civodul: ohhhh so there is a search path for it already
<davexunit>bye!
<wingo>phase `validate-runpath' failed after 0 seconds
<wingo>for icecat
<wingo>sup with that
<wingo>yeah icecat in core-updates doesn't build for me
<mark_weaver>wingo: it needs an rpath added, probably similar to what python does (LDFLAGS=-Wl,-rpath=<out>/lib)
<mark_weaver>I'll get to it soon if you don't...
<mark_weaver>where soon == in the next 24 hours
<mark_weaver>(my machines are slow, so a test build will take a while)
***fchmmr is now known as fchmmrrunstrisqu
***fchmmrrunstrisqu is now known as fchmmr
***fchmmr is now known as iruntrisquel
***iruntrisquel is now known as fchmmr