IRC channel logs

<mark_weaver>rekado: why don't you just use git-fetch?

<mark_weaver>no need to use their tarball generation

<Sleep_Walker>yay, first successful enlightenment build :)

<mark_weaver> http://audio-video.gnu.org/video/misc/2015-01__GNU_Guix__The_Emacs_of_Distros.webm

<mark_weaver>now to get it on the web site...

<sir123>Hello, here t otry and resolve my Guix build problems and get some work done on here :) I downloaded the guix git source and am trying to build it, but I've got some issues. First: configure.ac:18: error: required file 'build-aux/config.rpath' not found

<sir123>And: config-daemon.ac:12: error: required file 'nix/config.h.in' not found

<sir123>So, do I create these files?

<mark_weaver>sir123: did you run ./bootstrap ?

<mark_weaver>there are some extra steps required when building from the git repo

<mark_weaver>it's documented in the HACKING file

<mark_weaver>although I see that the HACKING file is slightly out of date. there is no git submodule anymore.

<sir123>Okay, it now complains that 'dot' is missing on your system.

<sir123>What's dot? I don't see any information on it on here.

<mark_weaver>sir123: dot is from the graphviz package

<sir123>mark_weaver: Is graphviz mentioned in the HACKING file? I didn't see it

<mark_weaver>yes, it is there

<mark_weaver>you have to hit TAB on those section headings to make them expand.

<sir123>Forgive my ignorance. I know I've asked a lot of stupid questions on this IRC

<mark_weaver>I don't think you've asked stupid questions. don't worry about it :)

<sir123>Btw, does anyone know if 32 bit packages are on the radar? Maybe I could be of use there

<mark_weaver>we already have a full 32-bit i686 system. my primary system is 32-bit.

<sir123>I meant cross-platform. I need some 32 bit packages to build in my 64-bit

<mark_weaver>just pass --system=i686-linux to any command that builds packages.

<mark_weaver>it is trivial for us to support this, because of the fact that everything lives in individual directories in /gnu/store with a hash. this design supports having many variants of the dynamic linker, shared libraries, compilers, core utilities, everything. so there's nothing special to do to also install a 32-bit system alongside a 64-bit one.

<sir123>I don't understand. So I rebuild the package using guix build, but pass --system=i686-linux to it? How do other packages know to go to the 32 bit instead of the 64-bit version?

<sir123>Trisquel was too easy on me, i guess :)

<mark_weaver>any package built with --system=i686-linux will be built using only components from our i686-linux port.

<mark_weaver>it will not even see the 64-bit components at all.

<sir123>Ah, that's genius. I see what you meant.

<mark_weaver>think of it as having two systems, one 32-bit, one 64-bit, living together in harmony because each of them are looking for their components in their own places in /gnu/store

<mark_weaver>there is no conflict, because they don't look for things in the same places.

<sir123>Brilliant. So how can I search for 32-bit packages in the i686 system? can I pass something to guix package -s

<sir123>Or do they have the same name as there is no difference between 32 bit and 64 bit?

<mark_weaver>the package names are the same across platfors.

<mark_weaver>*platforms

<sir123>Dang, Guix is breaking my mind... I like its better design, but it has a learning curve

<mark_weaver>heh :)

<sir123>So how could you set up a package that could only exist as 32-bit? Take ADB, for instance. That package can't be built as 64-bit, so how would you implement that restriction?

<mark_weaver>package descriptions can have an optional 'supported-systems' field.

<sir123>You guys think of everything, unbelievable.

<mark_weaver>well, sometimes we don't think of things until we come to them :)

<sir123>Oh, yeah... My gpg isn't working. Installed, but sh can't find it.

<sir123>bash: gpg: command not found

<mark_weaver>gnupg-1.4.18 contains 'gpg'. gnupg-2.0.26 contains 'gpg2'.

<mark_weaver>gnupg is kind of unusual in that gnupg-1.4 has a different design and interface from gnupg-2.0, and they are both actively maintained.

<mark_weaver>it may be that we should add a wrapper package that includes a symlink from gpg -> gpg2.

<sir123>Right. A search on guix reports only the 1.4 version.

<mark_weaver>we've had gnupg-2.0 for at least a year.

<mark_weaver>oh, do you mean you have only installed the 1.4 version in your profile?

<mark_weaver>how did you perform the search?

<sir123>Yeah. It never mentioned any existence of a 2.0 in the install.

<sir123>guix package -s

<sir123>gnupg

<sir123>Ah, there we go. Yeah it's a 2.0 version

<sir123>But bash doesn't recognise it. gpg2 works though.

<sir123>Odd.

<mark_weaver>bash doesn't recognize what?

<sir123>gpg on its own, which I guess is gnupg 1.4.x. gpg2 works well though.

<mark_weaver>gnupg-2.0 is designed to be installable alongside gnupg-1.4, so the commands have different names.

<sir123>Ah, okay. Guix defaults to installing gnupg 2.0, therefore the expected command 'gpg' doesn't do anything. User misunderstanding? Think it could confuse people?

<mark_weaver>yes, I think there is room for improvement here

<sir123>What I mean is that no other distro does this behaviour. But you can't exactly create an info page for one package.

<mark_weaver>maybe bring it up on the mailing list?

<mark_weaver>right now I'm working on a security update for icecat

<sir123>Yeah, I think we should by default symlink gpg -> gpg2, then program the gpg 1.4 install to remove it? That should sort out issues, right?

<mark_weaver>it's not that simple I'm afraid.

<mark_weaver>you are thinking in imperative terms, where packages are mutating some filesystem, making changes to what other packages have done.

<mark_weaver>guix is all based on creating immutable outputs and then taking their unions to create profiles.

<sir123>Ok. So packages can't tamper others, and a daemon provides control. Hmm.

<mark_weaver>we can make the union process more intelligent though

<mark_weaver>but this is a discussion for the mailing list

<sir123>Ok, I'll send an email. I don't have a gnu email address, can I use my regular one to send the message?

<sir123>Never used a mailing list, sorry

<mark_weaver>you don't need a GNU email address, any email address will do. however, you need to subscribe to the list or else your posts will have to wait for moderation before they go through (a necessary measure to prevent huge amounts of spam coming through)

<mark_weaver> https://lists.gnu.org/mailman/listinfo/guix-devel

<mark_weaver>you could also write a message to bug-guix@gnu.org without any subscription needed, although that will be in our bug tracker and fewer people are likely to be looking there.

<sir123>Guess I'm gonna have to learn how to use Gnus.

<mark_weaver>if you'd like to contribute to any GNU projects, it will be important to become comfortable with mailing lists.

<sir123>Righto. Thanks for clearing up my misconceptions, I couldn't figure out why gpg *wasn't* installing. You've helped me a lot, I was briefly considering dual-booting trisquel :)

<sir123>I'm interested by how the big distros lull users into a sense of security, such that they never examine their system. Goes against free software principles, doesn't it?

<sir123>Anyway, I'm off. Glad I can start to do some *real* hacking on my system. Thank you!

<mark_weaver>you're welcome!

<Sleep_Walker>mark_weaver: thanks for the fix and sorry for breaking that

<mark_weaver>Sleep_Walker: no worries!

<rekado>mark_weaver: I'm planning to use git-fetch if the tarball generation cannot be fixed, but I think it's a bit ugly.

<mark_weaver>I don't have much confidence that they'll do what's needed to make the tarball generation truly deterministic.

<mark_weaver>they'd need to fix the timestamps, the order the files are added to the tarball, and perhaps even fix the version of tar used to create the tarball.

<mark_weaver>it seems better to use our own code to extract the code from the git repo, rather than theirs.

<mark_weaver>if the "ugly" part is simply the form that our 'git-fetch' origins look like, maybe we should think about how to improve that.

<rekado>yes, true. Also, I'd rather have the two patches merged sooner than later, so I'll just use git-fetch right away.

<rekado>"ugly" was not referring to the looks but to the conceptional complexity of having to have git and its dependencies around rather than just a generic downloader.

<mark_weaver>well, in practice it will be hydra that does that downloading, unless the user has disabled substitutes in which case they already need to build a huge amount of stuff to get anywhere.

<mark_weaver>guix developers will also need to download when they update the package, but they will need git to do guix development anyway.

<mark_weaver>and I'm not sure that the "conceptual complexity" is lessened by having essentially the same operation done on someone else's server out of our control.

<mark_weaver>I hope that 'freetype' makes a new release soon. a rather large number of security fixes have recently been announced by Fedora.

<mark_weaver>19 separate CVEs

<mark_weaver> http://lwn.net/Vulnerabilities/634231/

<civodul>Hello Guix!

<mark_weaver>hi civodul!

<mark_weaver>up late patches security flaws.

<mark_weaver>*patching

<mark_weaver>fixed icecat, samba, and e2fsprogs. about to update grep in core-updates.

<mark_weaver>freetype will be a pain though. 19 separate

<mark_weaver>19 separate CVEs: http://lwn.net/Vulnerabilities/634231/

<mark_weaver>I hope they make a new release soon.

<civodul>ouch!

<civodul>indeed

<civodul>thanks for taking care of those again!

<rekado_>when a python module loads other python modules upon importing it should these modules be propagated inputs?

<rekado_>I noticed a problem with scikit-learn: when I "import sklearn" it fails because it cannot find numpy and scipy.

<rekado_>when I move numpy from inputs to propagated-inputs it only complains about scipy.

<rekado_>My PYTHONPATH is set to contain my profile's python2.7/site-packages directory.

<rekado_>moving both numpy and scipy to propagated-inputs fixes the issue, so I'll just do that and move on.

<iyzsong>My (obvious) answer is: Yes, they should be propagated.

<rekado_>:)

<rekado_>submitted an updated patch.

<davexunit>good morning #guix

<davexunit>how goes the hack?

<davexunit>my workstation at the FSF is borked right now due to an automated upgrade gone wrong last night

<davexunit>would be great if I had --rollback ;)

<civodul>howdy, davexunit!

<civodul>heh, indeed

<civodul>i wouldn't do unattended upgrades without rollback actually

<davexunit>yeah

<davexunit>it was actually a mistake that my machine got "hit" by this

<civodul>oh

<davexunit>but we are in a bit of debian package conflict hell

<davexunit>or rather, trisquel.

<civodul>i see

<davexunit>during these times I look towards a brighter future with guix. :)

<civodul>:-)

<Digit>new hd arrivd today... i wonder... just throw guix os on it n hope it works with my x60t... :) ... before i do my usual multi-boot extremism.

<rekado_>iyzsong: now that we have freepats do you want to modify your wildmidi patch to use it by default?

<rekado_>civodul: thank you for additionally working on bringing lilypond to guile 2!

<civodul>well i haven't done much

<civodul>but it's a longstanding issue, and a difficult one

<civodul>not only technically ;-)

<civodul>davexunit: should i put the video right below "Status"?

<civodul>the <video> tag i mean

<civodul>opinions?

<davexunit>civodul: I'll answer shortly, in a meeting currently. :)

<civodul>ok

<civodul>bbl

<a_e>Icecat currently takes ages to start. And my laptop makes little tapping noises on the side where the hard disk is. What do we conclude?

<a_e>Maybe time to install GSD on a fresh disk :-)

<civodul>it starts in a second on my laptop (with SSD)

<davexunit>civodul: I think putting the video about 'status' or even 'news' would be fine

<davexunit>now I'm off to get lunch. Reddit just gave the FSF $82K, btw!

<bavier`>davexunit: that's great!

<davexunit>s/about/above/

<bavier`>subversion doesn't like perl 5.20

<bavier`>the SWIG version that subversion-1.7.18 uses is too old

<bavier`>maybe time to upgrade subversion too.

<civodul>woow, Reddit is cool

<a_e>bavier`: You will be in for a recursive update week!

<bavier`>a_e: I'm so excited :/

<a_e>Subversion looks difficult.

<civodul>davexunit: i've added the video at http://www.gnu.org/software/guix/ but the big FOSDEM logo when the page is loaded is a bit disturbing

<civodul>what can be done about it?

<davexunit>civodul: we can choose a different thumbnail image

<davexunit>I think

<davexunit>I'll look after I eat my lunch

<mark_weaver>that's great news about reddit!

<davexunit>civodul: http://paste.lisp.org/display/145971

<davexunit>this will center the video, make it precisely half the full size, and use the guix logo for the poster instead of a frame showing the FOSDEM logo.

<Steap>do we have a magic method to uncompress an archive ?

<Steap>s/method/function/

<civodul>davexunit: thank you!

<civodul>davexunit: strangely enough, Icecat likes it but Conkeror seems to be confused

<civodul>although they both use the same renderer

<civodul>Steap: no

<civodul>we probably should add one to (guix build utils)

<davexunit>civodul: confused how?

<bavier`>civodul: my conkeror doesn't like the video either

<Steap>civodul: k

<davexunit>did it like the video before?

<civodul>before it worked fine

<davexunit>I've only tested in ice cat

<civodul>but now it displays the logo and fails to play it

<davexunit>strange...

<davexunit>a quirk in an old gecko?

<civodul>it seems to get the size wrong

<civodul>the box has the size of the logo

<civodul>i'll upgrade and see if it makes a difference

*davexunit has to go

<a_e>My icecat does not show unicode characters. Will it be enough to install a font and run fc-cache?

<a_e>Yes!

<a_e>We have font-gnu-freefont-ttf for this.

<a_e>How about Chinese?

<Steap>can I use "(match ..." to match a string against a regexp ?

<civodul>Steap: no, but there's 'string-match' from (ice-9 regex) for that

<civodul>bavier`: the new Conkeror works fine

<civodul>(and is exempt from a few CVEs, as a bonus ;-))

<bavier`>civodul: oh great, good to hear

<a_e>On debian, I need systemd to burn a dvd with brasero or k3b... And I just got rid of it yesterday.

<a_e>Our guix brasero crashes:

<a_e>** (brasero:20744): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

<a_e>GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.

<a_e>**

<a_e>Gtk:ERROR:gtkrecentmanager.c:1971:get_icon_fallback: assertion failed: (retval != NULL)

<mark_weaver>a_e: I've been unable to get either icecat or emacs on GuixSD to display iyzsong's name properly.

<a_e>I already installed hicolor-icon-theme just in case.

<a_e>mark_weaver: I can see it in my guix mutt on debian. It looks like we are missing a Chinese font.

<mark_weaver>although I see the characters properly on my YeeLoong, which is Guix on top of my home-built system based on [GNU/]Linux from Scratch.

<a_e>宋文武 would be a perfect candidate to package one ;-)

<mark_weaver>indeed!

<a_e>Probably there is some Chinese font in your LFS.

<mark_weaver>a_e: regarding the dbus issue: is that on GuixSD, or Guix on top of another system?

<a_e>Guix on debian.

<mark_weaver>hmm, dunno then

<a_e>(I am not yet ready to switch to guixsd).

<mark_weaver>that's fine, just wondering if the idea I had was relevant, but in this case no.

<a_e>(or guixsd is not yet ready to be switched to by me :-))

<a_e>Ah, we have xorriso. I will give it a try.

<a_e>xorriso-tcltk is a shell script looking for /usr/bin/wish !

<taylanub>mark_weaver: by the way, ping on the ECL update :-) (I realize you're quite busy)

<toothbrush0>hello! very silly newbie question here, trying to package my first guix package... how do i get "autoreconf -i" to run before it tries ./configure?

<bavier`>toothbrush0: you'll need to add a new phase before the configure phase

<toothbrush0>right. i'll go dig in the manual!

<bavier`>see e.g. liuninameslist in gnu/packages/fontutils.scm:263

<toothbrush0>ah, i'd already done `git grep autoreconf` but the results weren't enlightening :)

<toothbrush0>i'll look there, thanks bavier`

<bavier`>np

<mark_weaver>toothbrush0, bavier`: actually, it should go *after* unpack instead of before configure.

<mark_weaver>I was looking for an example that does it properly, but almost all of them get it wrong.

<mark_weaver>the problem is that there are some other phases that need to fix things up in the configure script before it is run, and if you add the new phase before configure, those phases can't do their jobs.

<bavier`>mark_weaver: yes, I recall that coming up in discussion previously

<bavier`>I thought something seemed wrong when I looked at that package.

<mark_weaver>in practice, those phases are usually only needed on non-Intel platforms, so most people don't notice the breakage.

<mark_weaver>I guess I should do a bit commit to fix all of those places, especially since it is so common for people to look to existing recipes for examples of how to do things.

<mark_weaver>s/bit/big/

<civodul>taylanub: thanks for modify-phases, it's great

<toothbrush0>NICE! Thanks mark_weaver, bavier`, it looks like my package builds!

<bavier`>toothbrush0: great!

<a_e>taylanub: Now you will have to manually convert 1200 packages :-P

<taylanub>civodul: glad to hear you like it :-)

<a_e>toothbrush0: Great!

<taylanub>a_e: heh :-)

<toothbrush0>um, silly question though; is it normal that `./pre-inst-env guix package -I` gives a different list than i see in ~/.guix-profile/.. ?

<taylanub>toothbrush0: ~/.guix-profile does not directly list the packages you have, though I guess all packages showing up in -I should appear somewhere within it (as symlink targets). how exactly are you comparing the two?

<toothbrush0>well, notably `guix package -I` shows version X of my package, and .guix-profile/bin/.. points to version Z, where Z older than X

<civodul>toothbrush0: could it be that both X and Z are installed, but Z took precedence?

<toothbrush0>Ah, maybe. Let me investigate

<a_e>civodul: I am having a problem with a cmake-built package; the command line for linking (using c++, not ld) lists lots of absolute paths to libQt5Gui.so.5.4.0 etc.

<a_e>But it ends with -Wl,-rpath,::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

<a_e>And the resulting library does not find libQt5Gui etc.

<toothbrush0>Hm, no civodul that's not it.

<a_e>Did you not fix this quite a while ago?

<toothbrush0>civodul: it's as if the `./pre-inst-env guix` commands are not affecting the ~/.guix-profile directory at all...

<civodul>toothbrush0: that's weird; can you also check ~/.guix-profile/manifest?

<civodul>a_e: wasn't it due to cmake sucking?

<civodul>i forgot the conclusion

<toothbrush0>civodul: manifest disagrees with the output of `./pre-inst-env guix pack -I`

<a_e>Yes, because cmake puts "/gnu/store/..../libx.so" instead of "-lx".

<a_e>civodul: See commit d8491ba5: "ld-wrapper: Add '-rpath' flag for libraries passed by file name."

<civodul>toothbrush0: hmmm but -I does nothing more than display its contents, roughly; could you strace it?

<civodul>a_e: oh right

<toothbrush0>civodul: i think i have the answer, i have /usr/local/guix/var/guix/profiles/per-user/paul/guix-profile AND /usr/local/var/guix/profiles/per-user/paul/guix-profile

<toothbrush0>and guix vs. .guix-profile use different ones!

<toothbrush0>no idea how that happened :/

<toothbrush0>perhaps it's best to throw it all away and start from scratch?

<a_e>toothbrush0: It looks like one configure with --prefix=/usr/local/guix, and the other one without --prefix.

<civodul>toothbrush0: just rm ~/.guix-profile

<civodul>yeah

<a_e>toothbrush0: Could it be a problem that the linker is invoked as /gnu/store/16j0v2km34g471cs77gxlq0n0a956cw1-gcc-4.8.4/bin/c++ ?

<toothbrush0>i think a_e has a point!

<a_e>Sorry, this was a question to civodul.

<toothbrush0>oh, it still makes sense though :p

<toothbrush0>i vaguely remember doing ./configure --prefix=... once in the first instance

<a_e>toothbrush0: No, my last line was a question to civodul, the one about the linker.

<toothbrush0>and since then i've done make clean && ./configure && ./make

<toothbrush0>ah right

<a_e>toothbrush0: So you could simply delete /usr/local/guix/ and .guix-profile.

<civodul>a_e: i don't think so

<toothbrush0>civodul: confirmed fixed

<toothbrush0>a_e: yup.

<a_e>civodul: This is crazy! It worked for other projects, like kdelibs.

<a_e>civodul: I see code like this in your commit:

<a_e>+ ((and (string-prefix? %store-directory argument)

<a_e>+ (string-suffix? ".so" argument)) ;add library

<a_e>+ (cons library-path

<a_e>+ (cons argument library-files)))

<a_e>But here, it actually does not _end_ in .so.

<a_e>It is /gnu/store/rlhc2fjwwi3g2rif9ad9jfp5if5ga4qy-qt-5.4.0/lib/libQt5Gui.so.5.4.0

<toothbrush0>is it safe to blow away the entire contents of ~/.guix-profile, then reinstall my packages?

<a_e>Yes.

<toothbrush0>great.

<toothbrush0>because i'm getting weird errros after discovering that i have two profiles

<a_e>civodul: I think we should match the regexp "\\.so(\\.[:digits:]+)*" (however this is written precisely).

<civodul>a_e: oooh, i see

<civodul>cmake is really perverse

<a_e>I think nowadays perversion are considered as just different preferences :-)

<a_e>We need to match a string against a regular expression. We have talked about this already today!

<a_e>civodul: Could you quickly modify this in core-updates?

<a_e>A general question on regular expressions: Does '$' match the end of string, or only the newline characte '\\n'?

<toothbrush0>is it normal that doing `./pre-inst-env guix package -i something` build the world from scratch and doesn't use substitutes?

<a_e>No, unless you modified a core package.

<toothbrush0>uh, not intentionally anyway

<a_e>Did you enable the hydra key?

<toothbrush0>hm perhaps that got clobbered when i wiped my guix-profile

<Sleep_Walker>a_e == 'Andreas Enge' ?

<a_e>No comment :-)

<a_e>I am here incognito.

<Sleep_Walker>nevermind

<Sleep_Walker>I just wanted to thank him ;)

<toothbrush0>a_e: um wait, does that make sense if i'm running guix on top of another linux installation? i don't remember doing that before... (but my memory is a sieve)

<toothbrush0>((not a erastosthenes sieve, unfortunately))

<a_e>toothbrush0: Let me prime you: I am using guix on top of debian, and it works without problem.

<a_e>But you need to enable hydra's key as explained in the manual.

<toothbrush0>a_e: LOL :)

<toothbrush0>a_e: it complains about not being able to mkdir -- strace tells me it's trying to mkdir /usr/local/etc/guix

<toothbrush0>should i let it? (i.e. sudo)

<a_e>toothbrush0: No idea. I used "--prefix=/usr/local/guix"... And indeed, I have a file acl in /usr/local/guix/etc/guix.

<a_e>So I suppose you should be brave.

<toothbrush0>right. turns out that worked, and i've remembered the reason

<toothbrush0>i had a botched install at /usr/local/guix/... before

<toothbrush0>thanks! funny how i thought that was the thing, then discounted it again, then had to get someone else to tell me to do it ;)

<a_e>civodul: I just sent a patch to the mailing list, concocted from the guile documentation and my limited understanding of regular expressions. Hopefully, it is not too wrong...

IRC channel logs

2015-02-26.log