IRC channel logs

<davexunit>grasshopprWhoppr: well, a 'package' is just a scheme object that describes the recipe for building a piece of software. so we have lots of those. :)

<grasshopprWhoppr>ok

<davexunit>and yes, guix can build from source, but guix can also download binaries.

<grasshopprWhoppr>oh

<davexunit>hydra.gnu.org is our build farm

<davexunit>well, the frontend to our build farm

<grasshopprWhoppr>does it store binaries?

<davexunit>yeah

<davexunit>in the exact same way that your local guix does

<davexunit>in /gnu/store

<davexunit>guix allows you to use the cache from someone else's machine if you choose.

<grasshopprWhoppr>building from source was fun with gnu stow. the cache has binaries or?

<davexunit>yes

<davexunit>the cache stores "derivations", the output of a build process

<icarious>so guix can be used as a total source based system like gentoo? if one wants to build the entire system?

<davexunit>icarious: exactly.

<icarious>its my thing then :D

<davexunit>it's a transparent source/binary package manager.

<icarious>nice

<grasshopprWhoppr>who would use a cache? computers on a LAN to save bandwidth?

<davexunit>grasshopprWhoppr: that's one possibility. the thing to understand is that your own local machine has the very same cache, called "the store".

<davexunit>which is /gnu/store

<davexunit>when guix goes to build something, it checks if its already in your local cache (/gnu/store). if not, it checks if any authorized remote machines have it in their store. if not, then a local build occurs.

<davexunit>afterwards, your local store has the package.

<grasshopprWhoppr>oh, and one of those remote machines could be hydra

<davexunit>yes

<davexunit>I'm working on a feature that will allow any guix to "publish" their store on the network.

<davexunit>any guix user*

*rekado already gets to 1200 seconds in the OpenJDK/IcedTea build phase.

<iyzsong>civodul: hi! is it ok to get hydra build wip-qt? even I haven't build it locally?

<civodul>iyzsong: ooh, i forgot to enable it

<civodul>lemme see

<civodul>iyzsong: it should start building soon: http://hydra.gnu.org/jobset/gnu/wip-qt

<iyzsong>civodul: thanks!

<paroneayea>davexunit: looks like I might be switching to use qemu also for my stuff

<jxself>From?

<paroneayea>did you know that virtualbox is now also requiring a nonfree bios compiler?

<paroneayea>:(

<jxself>Oh, from VirtualBox. Good good. :)

<davexunit>paroneayea: yeah, sad.

<paroneayea>I was surprised I never heard of that.

<jxself>It was in version 4.2, by the way, so if you want to stick with an old version...

<jxself>And the folks at Oracle pretended to not understand the matter, like th ecomment from bird at https://www.virtualbox.org/ticket/12011

<jxself>Not understanding why some people don't want to use compiler output as a "source"

<jxself>Or at least pretending to...

<paroneayea>jxself: arg

<paroneayea>jxself: I'm doing some contracting for kfogel, and he wants (yay) to use only free software with his company

<paroneayea>I set up something using virtualbox, which *previously* was installed with debian stable

<paroneayea>but, and here's what I get for having contrib enabled, I didn't notice it move to contrib

<jxself>Debian stable is old so maybe they still have version 4.1?

<jxself>And yes, yay to Karl. :)

<paroneayea>oh, debian testing

<paroneayea>sorry :)

<svetlana>pesky people, they don't like the new name, hehe

<DusXMT>What's the new name?

<DusXMT>ah, found it, Guixotic

<mark_weaver>civodul: I fixed the gcc-4.9.2 build on mips, so we could revisit the idea of switching to it by default in core-updates

<mark_weaver>(it turned out that our GLIBC_DYNAMIC_LINKER patching code in our 'pre-configure' phase wasn't coping with the multi-line definitions in 4.9.2 on mips)

<civodul>yes, i noticed, thanks for fixing it!

<civodul>i'd rather wait for the next cycle to switch to 4.9

<civodul>this one has been long and full of new stuff already

<civodul>WDYT?

<mark_weaver>okay, sounds good!

<mark_weaver>the armhf port is going well. I'm using guix's emacs-no-x-toolkit and enough to bootstrap+build 'guix' from git using only guix packages.

<civodul>ok

<civodul>nice!

<mark_weaver>ran into problem with icu4c, which I've only just now resolved.

<civodul>it's really cool to get this port going

<DusXMT>One thing I don't understand about picking names is: why bother with how non-English people will read it? Over here in Slovakia, we read almost everything in out own way. Languages are simply all different

<davexunit>agreed.

<DusXMT>No one, for example, says firefox as an english-speaking person would say, we say "fajerfox"

<mark_weaver>civodul: btw, I noticed recently that the old 'udev' package is used in only one place: as input to 'lvm2'. any reason not to switch 'lvm2' over to 'eudev' and get rid of 'udev'?

<mark_weaver>for security reasons, it seems good to avoid keeping around old versions that we don't need.

<mark_weaver>(if we keep them around, we'll have to backport security fixes to them, etc)

<davexunit>would following Nix's lead and naming the distro something simply like "GuixOS" be undesirable?

<davexunit>s/simply/simple/

<bavier>davexunit: that would seem natural to me, and would be about as generic a name as we could get

<davexunit>that said, I can live with "guixotic", because I'd like this to be over with. :)

<bavier>same here

<mark_weaver>GuixOS sounds good to me too, but I'm fine either way.

<civodul>mark_weaver: yeah we should get rid of "udev"

<mark_weaver>civodul: thanks

<mark_weaver>civodul: btw, I realized recently that (%current-system) returns a nix-system string, whereas (%current-target-system) returns a GNU triplet. given how often we have written (or (%current-target-system) (%current-system)), and the similarity of the names, I had assumed that they were both nix-systems.

<mark_weaver>I've added code to the tree that does the equivalent of (string=? "mips64el-linux" (or (%current-target-system) (%current-system))). I'll have to fix those.

<mark_weaver>but I wonder if the situation could be improved to be less confusing, and to make it more convenient to do checks like that.

<mark_weaver>thoughts?

<mark_weaver>well, I suppose the mailing list is a better place for that discussion.

<alirio>I read [PATCH] linux-boot: Make /etc/mtab a symlink to /proc/self/mounts. https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00059.html, and now I wonder if hurd has /proc/self/mounts

<DusXMT><antrik> youpi: there is no way to provide /proc/self, because the server doesn't know the identity of the client (from http://www.gnu.org/software/hurd/hurd/translator/procfs/jkoenig/discussion.html#self)

<DusXMT>alirio: ^

<civodul>mtab itself doesn't make much sense on the Hurd

<civodul>mark_weaver: oh right, i wonder if there are actual problems though; most of the time we just use string-prefix? or string-contains i suspect, in which case (or (%current-target-system) (%current-system)) is fine

<DusXMT>Although there is one, not sure how it works though, it's probably a voluntary thing translators can writ themselves to, for example, the ext2fs one

<alirio>civodul: so this won't make harder the Hurd support later?

<mark_weaver>civodul: it's workable in practice, but a bit clunky IMO.

<mark_weaver>maybe it would be enough to provide something that does (or (%current-target-system) (nix-system->gnu-triplet (%current-system)))

<mark_weaver>I guess my main gripe is the name of %current-target-system, specifically the suffix "-system", although it does not return what we generally call a 'system'.

<mark_weaver>%current-target-triplet would be a better name for it, imo.

<mark_weaver>s/return/hold/

<mark_weaver>WDYT?

<mark_weaver>well, it seems my troubles with icu4c on arm are not yet resolved.

<mark_weaver>the generated libicuuc.so seems to be trying to link to shared libraries whose names are garbage, like "^G\\334\\320Ӧ\\300"

*mark_weaver wonders if the radically modified patchelf is working correctly

<civodul>alirio: no, i don't think so

<civodul>mark_weaver: yes, "-triplet" may be a better name

*civodul is finally having some success with HTTP pipelining

<davexunit>civodul: what does the HTTP pipelining do?

<mark_weaver>that's good! is nginx behaving better?

<jxself> http://en.wikipedia.org/wiki/HTTP_pipelining

<jxself>mr. davexunit :)

<civodul>mark_weaver: well, *cough* my code is behaving better...

<davexunit>jxself: oh cool :)

<davexunit>didn't know about that.

<davexunit>thanks.

<civodul>davexunit: BTW, i hope Guile's HTTP server supports it correctly

<civodul>so we the HTTP pipelining stuff will work there as well

<civodul>there = 'guix publish' :-)

<davexunit>I hope so, too. :)

<civodul>heheh

<davexunit>civodul: did you happen to see the bug I filed yesterday?

<civodul>yes, and i replied no?

<davexunit>I corrupted my store with substitute-binary somehow.

<civodul>or i thought i did

<DusXMT>So it's basically an asynchronous approach to HTTP? (pipelining)

<davexunit>oh, did you? didn't see. I'll go look.

<davexunit>civodul: I don't see the reply.

<civodul> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19512

<davexunit>strange.

<davexunit>I didn't receive the mail. thanks.

<civodul>in short: i think your store is just fine

<civodul>no worries

<davexunit>oh great. thanks for the explanation.

<davexunit>sorry to bother you with that.

<civodul>np!

<davexunit>I was worried about using 'rm -rf' because I hosed my store that way when I first started using guix.

<civodul>yeah, i never use that

<mark_weaver>civodul: hehe :)

<mark_weaver>(regarding the pipelining work)

<davexunit>civodul: the remaining issue with guix publish then is figuring out why it doesn't like the archive produced by write-file. it still doesn't like the eof marker, even when using force-output.

<civodul>davexunit: bah

<civodul>i forgot the details

<civodul>we must be overlooking something

<davexunit>okay

<davexunit>gotta go now. we can chat about it some other time here or on the list I guess.

<davexunit>bye!

<svetlana>is thre a plan to make offline installer?

<mark_weaver>civodul: the removal of glibc:locales has caused me some trouble on my systems where /run/current-system doesn't exist. have you thought about what to recommend to those who run guix on another distro?

<mark_weaver>for now, I ran 'localedef' manually and set LOCPATH. it would be nice if this were handled automatically somehow, but at very least, the needed steps should be documented.

<civodul>mark_weaver: are there explicit references to /run/current-system?

<civodul>LOCPATH would be the solution, but yeah, it would be better if it worked out of the box

<civodul>svetlana: you mean requiring no network access?

<mark_weaver>civodul: yes, the reference is inserted because our glibc package now passes "libc_cv_localedir=/run/current-system/locale" to configure

<mark_weaver>civodul: ideally, we would have a way to install a "parameterized" package, in this case a 'custom-locales' package with a user-specified set of locales

<civodul>oh, right

<mark_weaver>and then we add a search-path specification for LOCPATH

<civodul>yes, that might work

<civodul>i think initially i was going to force people to define LOCPATH

<civodul>and then i added this shortcut for "Guixotic" usres

<civodul>*users

<mark_weaver>that seems reasonable. we just need a not-too-painful way for users to generate a directory of locales.

<mark_weaver>I see 'locale-directory' in (gnu system locale). what's the proper way to adapt that into a procedure that accepts a list of locales and returns a package object?

*mark_weaver shows his ignorance of guix internals

<civodul>you would write a procedure that returns a package that uses trivial-build-system

<civodul>hmm

<civodul>rather a custom build system that binds the result of locale-directory

<civodul>we could have a procedure to lift a monadic procedure to a package

<civodul>anyway it's a bit of plumbing, but it's definitely doable :-)

*mark_weaver removed the use of 'patchelf' from the 'icu4c' package. turns out they have an --enable-rpath option that works properly.

<mark_weaver>and that in turn solved the problem with icu4c on armhf.

<jxself>Yay.

<mark_weaver>but the problem now remains that we apparently lack a working patchelf on armhf.

<jxself>That poor elf.

*mark_weaver would be happiest if we reduced the number of uses of 'patchelf', preferably down to zero.

<mark_weaver>almost certainly, there's always a more proper solution, if one is willing to dig into arcane build systems occasionally.

<svetlana>civodul: yes

*davexunit is back

<davexunit>civodul: 'guix gc --references' works on the corrupt store item...

<davexunit>and 'guix gc' doesn't remove it

<davexunit>I guess I'll try 'rm -rf'

<civodul>mark_weaver: yay for icu4c!

<civodul>davexunit: so the corrupt thing is valid?

<civodul>but that's because it was valid before, i guess

<civodul>can you remove it with "guix gc --delete /gnu/store/xxx"?

<civodul>NixOS is all over the place these days: http://lwn.net/Articles/628548/

<mark_weaver>civodul: he wrote: <davexunit> and 'guix gc' doesn't remove it

<civodul>oh right

<civodul>davexunit: if 'guix gc' cannot remove it, then you shouldn't rm -rf it

<civodul>try 'guix gc --referrers' to see what's using it

<davexunit>civodul: nixos is on the front page of HN a lot

<davexunit>and I shill for guix when I can ;)

<civodul>yeah i've noticed a few times :-)

<davexunit>oh, my profile is using that package.

<civodul>thank you

<civodul>davexunit: so first remove it from the profile, and remove the profile generation(s)

<civodul>i need to go now, but leave me a note

<civodul>and don't rm -rf if it's still referenced

IRC channel logs

2015-01-05.log