<Sleep_Walker>(I heard about lzip for the first time in 'Self-contained Guix tarball' mail) <taylanub>I wonder why xz caught all the attention when lzip is older and works just as good or better <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 <civodul>kete: xz is free software as well, only non-copyleft <Sleep_Walker>well, I don't care using any of them, I was just wondering if it is some "new default" ***boegel|quassel is now known as boegel
<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 <atheia>ALL the things?, he asked one-and-a-half hyperbolically. <Sleep_Walker>hm, it seems I miss `pkg-config' in my `guix environment guix' environment <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. <mark_weaver>you can get the old one using 'guix build -S' with the old hash <mark_weaver>we should send a message to upstream asking them not to do that *mark_weaver goes afk for a while <rekado_>hmm, I can't get the old tarball with "guix build -S". <rekado_>yes, I still have the old hash in place. <rekado_>maybe it's too long ago that rseqc was built successfully? <Sleep_Walker>mark_weaver: --pure doesn't seem to have any effect, pkg-config is required by `./configure <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. <rekado_>yes, I just saw this. I pushed it two days before that. <davexunit>Sleep_Walker: does 'which pkg-config' yield anything? <davexunit>Sleep_Walker: does './bootstrap; ./configure' work? <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? <mark_weaver>trying to build anything with a mixture of libraries from guix and from the host system will cause problems. <mark_weaver>graphviz is in the native-inputs for guix-devel. it should be there. <mark_weaver>davexunit: does 'guix environment' include native-inputs? <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>guix-devel is just the variable name, not the package name <davexunit>so, let's try something that ensures we get guix-devel... <davexunit>guix environment -e '(@@ (gnu packages guix) guix-devel)' --pure <Sleep_Walker>guix environment: error: failed to evaluate expression `(@@ (gnu packages guix) guix-devel)': (unbound-variable "module-lookup" "Unbound variable: ~S" (guix-devel) #f) *Sleep_Walker feels like interactive shell :) <davexunit>yeah, I'm relying on you to give me feedback since I'm not using a computer with guix on it. :) <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 <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>yeah, if folks could 'dpkg -i guix-x.y.z.deb', that would be great <civodul>paroneayea: i agree it would be nice, but it wouldn't be accepted in upstream Debian <davexunit>paroneayea: that changes the hash of all the derivations <paroneayea>well having a .deb on the guix website that's guix-endorsed would help a lot <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 <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 <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 <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. <mark_weaver>well, I've partially grokked them but my understanding of them is somewhat limited. *wingo reboots into linux 4.0 *davexunit is running 'guix pull' on his VPS <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>i guess it downloads the "lib" output of gcc, no? <civodul>it contains libgcc_s, libgomp, libstdc++, etc. <davexunit>/gnu/store/4sqgnc9bc1kmn058yp4xnj4vpydmfzpq-gcc-4.8.4 <civodul>the emacs binary has a reference to /gnu/store/4sqgnc9bc1kmn058yp4xnj4vpydmfzpq-gcc-4.8.4 <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 <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... <civodul>taylanub: yes, it's PATH_EXEC in epaths.in apparently <civodul>davexunit: glibc-utf8-locales, for instance <davexunit>sort of a silly question, but this is the first system I've had such an issue with <davexunit>export LOCPATH=$HOME/.guix-profile/share/locale <civodul>export LOCPATH=$HOME/.guix-profile/lib/locale, i think <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 <davexunit>civodul: ohhhh so there is a search path for it already <wingo>phase `validate-runpath' failed after 0 seconds <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>(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