IRC channel logs


back to list of logs

<davexunit>hmm, says my signature is corrupt
<davexunit>I notice that my signatures are *much* shorter than the signatures on
<davexunit>yay, got it to work!
<davexunit>ah boy I've screwed things up now...
<davexunit>substitute binary failed... but created a directory in the store
<davexunit>with an incomplete copy
<davexunit>that causes future tries to fail. eek.
<zacts>hello guixians
<icarious>the installation method is nice
<icarious>just a text file :D
<davexunit>icarious: yes, indeed. :)
<davexunit>it's just a scheme expression. very elegant.
<icarious>packages are getting download. by the way are the packages signed?
<davexunit>icarious: yes
<icarious>ok nice
<icarious>I wonder how it would be to construct a system using LFS (with linux-libre) and using guix as a package manager.
<icarious>ath9k-htc-firmware is packaged
<icarious>ok system is isntalled and booted. how do I switch to bash?
<grasshopprWhoppr>I thought there were no packages and the manager downloads sources and builds from those
<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. :)
<davexunit>and yes, guix can build from source, but guix can also download binaries.
<davexunit> is our build farm
<davexunit>well, the frontend to our build farm
<grasshopprWhoppr>does it store binaries?
<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>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.
<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>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:
<iyzsong>civodul: thanks!
<paroneayea>davexunit: looks like I might be switching to use qemu also for my stuff
<paroneayea>did you know that virtualbox is now also requiring a nonfree bios compiler?
<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
<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
<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.
<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
<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?
<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>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., 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
<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>well, it seems my troubles with icu4c on arm are not yet resolved.
<mark_weaver>the generated 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>mr. davexunit :)
<civodul>mark_weaver: well, *cough* my code is behaving better...
<davexunit>jxself: oh cool :)
<davexunit>didn't know about that.
<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. :)
<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.
<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.
<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>gotta go now. we can chat about it some other time here or on the list I guess.
<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
<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>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.
<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:
<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