IRC channel logs

2014-11-17.log

back to list of logs

<davexunit>bam, gnu.org cvs updater is back in action!
<jxself>What was wrong?
<davexunit>jxself: the cron job that updates the cvs repo has been hanging for days now.
<davexunit>not sure why, but I killed it and restarted cron and things were good
<jxself>OK
<jxself>"When all else fails, reboot"
<phant0mas>good morning guix
***Necrosporus_ is now known as Necrosporus
<Necrosporus>Whats the difference between guix and nixos beside using different package manager config syntax?
<civodul>Hello Guix!
<civodul>www.gnu.org is back to life! \\o/
<civodul>sneek: later tell davexunit thanks a lot for fixing the CVS commit hooks!
<sneek>Got it.
<jmd>I have built bootstrap binaries, but I still get complaints about In execvp of tar: No such file or directory
<jmd>when I try to build make-boot0
<jmd>
<civodul>jmd: could it be that the 'tar' executable has the wrong ELF interpreter?
<civodul>try "strings tar | grep ld-linux"
<civodul>or just "ld", even
<Necrosporus>Is guix better than nixos?
<civodul>definitely
<civodul>any other questions?
<civodul>;-)
<jmd>where should that "tar" actually be?
<civodul>Necrosporus: the standalone OS based on Guix is not as mature as NixOS
<Necrosporus>i know
<civodul>jmd: it's in a bootstrap tarball that you built, i guess
<Necrosporus>but what's the difference, so you decided to make another OS instead of joining effort with NixOS?
<civodul>i did join efforts with NixOS for a long time
<civodul>but NixOS has no committment to free software, for one thing
<civodul>and on the technical side, Guix tries to provide a more consistent and hackable framework
<civodul>some of the technical motivations are detailed in http://arxiv.org/abs/1305.4584
*civodul goes have some coffee
<Necrosporus>civodul, about free software, isn't there an option in NixOS to use only free software?
<jmd>civodul: I don't understand what I'm supposed to do after I build bootstrap-tarballs.
<jmd>I've hacked bootstrap.scm (right now with shas of 000000000000000000000000) but it doesn't look as if anything even tries to refer to the built tarballs.
<civodul>Necrosporus: yes, there's that now; unfortunately, there's no license auditing at all, so packages sometimes have no license info, sometimes have erroneous info, etc.
<Necrosporus>another question, is why the directory name starts with hash?
<Necrosporus>Why not to use package-version-hash format instead?
<civodul>jmd: you can try "guix build -e '(@ (gnu packages bootstrap) %bootstrap-glibc)'", for instance
<civodul>Necrosporus: well that's historical, it's inherited from Nix
<civodul>it's a FAQ :-)
<civodul>jmd: you can try "guix build -e '(@ (gnu packages bootstrap) %bootstrap-glibc)'", for instance
<Necrosporus>But if you put package name first you could take advantage of using shell autocompletion when browsing package store
<civodul>yes, but in practice you normally don't browse the store directly
<civodul>except when "debugging" things, and in that case it can be useful to have the hash first
<Necrosporus>But is there any drawbacks of not putting the hash first?
<civodul>not really, it's a matter of taste :-)
<Necrosporus>civodul, I might want to know which versions of GCC I have already installed for example
<Necrosporus>If the name of package comes first, it's easier to do, as one can type /gnu/store/gcc<tab><tab> and that's it
<DusXMT>Necrosporus: but it's also easy to do `$ echo /gnu/store/*-gcc-*'
<civodul>yes, and for that, you would rather use "guix package --list-installed gcc"
<Necrosporus>/gnu/store/gcc<tab><tab> is still easier, though not much
<jmd>civodul: That works.
<jmd>But I get the problem running guix build --target=xxxx gcc-toolchain
<alezost>Necrosporus: what you have in the store is not necessarily installed
<jmd>(for example)
<civodul>jmd: wait, are you cross-building stuff, or building natively?
<jmd>I'm cross building
<jmd>(or trying to)
<civodul>so you don't need to touch bootstrap.scm at all
<civodul>see http://www.gnu.org/software/guix/manual/guix.html#Porting
<jmd>Yes, I have read that.
<civodul>you are at the stage just before "Once these are built", right?
<jmd>Yes.
<jmd>I have built the bootstrap-tarballs
<civodul>yay, congrats!
<civodul>so that's a very important milestone
<civodul>you could push a wip-arm branch, if you want
<civodul>then, could you copy these tarballs to an ARM machine?
<civodul>and from there, unpack them, and make sure you can run the executables in there
<jmd>Yeah I've done that.
<civodul>ok, and they run?
<jmd>Yes.
<civodul>wonderful :-)
<jmd>... at least, I did some rudementary tests.
<civodul>so the next step is to unpack guix.tar.gz on that ARM machine
<civodul>you did that already maybe?
<jmd>Thats the thing, I cannot cross build guix.
<jmd>guix build --target=xxxx guix fails
<civodul>you don't need to cross-build it
<civodul>just copy a tarball or git clone it on the ARM machine
<civodul>and then, run ./configure --with-courage
<Necrosporus>With courage?
<DusXMT>Just out of curiosity, is porting to a different architecture using an emulator allowed?
<civodul>DusXMT: "allowed"? :-) as long as it does something useful
<civodul>Necrosporus: that's to make sure you understand that you are porting the thing to a new architecture ;-)
<Necrosporus>So there is at least three different software deployment languages, Vesta, Nix and Scheme/Guix
<viric>civodul: in catalan, vesta = dress. nics = furious. guix = chalk. es pla interessant. :)
<DusXMT>Over here, Vesta is a very light jacket
<civodul>:-)
<jmd>civodul: I'm still not sure that I follow.
<jmd>Exactly *which* tarball are you asking me to copy to the target machine?
<civodul>jmd: i'm talking about the guix source tree; either copy guix-0.8.tar.gz (build it with "make dist"), or better yet, git clone guix
<jmd>There is a problem there. I don't have a native compiler on the target machine.
<Necrosporus>I do not know, what is string interpolatoio and homoiconity
<jmd>Which is why I'm trying to cross build as much as possible.
<civodul>jmd: but can't you install one?
<civodul>typical ARM machines are powerful enough for that
<civodul>Necrosporus: "string interpolation" is when you can refer to variables from within a string; in Nix: "foo ${bar}"
<jmd>Yeah. I was trying to build one. That is why I was running "guix build --target=armel-linux-gnueabihf gcc-toolchain"
<jmd>(but that fails for reasons I don't fully understand)
<civodul>Necrosporus: homoiconicity is best described at http://en.wikipedia.org/wiki/Homoiconicity
<civodul>jmd: i mean, install GCC using whatever distro is already running on that ARM machine
<civodul>one problem at a time ;-)
<jmd>Ahh well that's the issue. The distro currently on it, is severely broken.
<Necrosporus>civodul, bash and perl and other languages support it too
<DusXMT>jmd: There must be some way you can get it... How about manually extracting the packages? On debian-based ones, you extract them first with ar, and then the data.tar.XX file
<jmd>DusXMT: Well the approach I was trying was to manually extract the Guix packages.
<jmd>I suppose I should be able to build using the static gcc.
<jmd>brb
<jmd>I'll have to rezip the binaries from xz to gz - I cannot decompress xz on the target.
<civodul>heh, ok
<jmd>Is everything to build guix contained in the bootstrap tarballs?
<Necrosporus>Tcl is homoiconic too, why not to use Tcl instead of guile? it at least has both homoiconicity and string interpolation
<civodul>no, Guix needs SQLite, libgcrypt, etc.
<DusXMT>and also graphviz
<jmd>Is Necrosporus trolling?
<civodul>Necrosporus: Scheme has technical advantages of Tcl, and it's the extension language of GNU
<civodul>jmd: i think Necrosporus is trying to understand, which is reasonable
<civodul>things that are obvious to use aren't necessarily obvious to people "outside"
<Necrosporus>civodul, what are technical advantages of Scheme?
<DusXMT>RMS has a real distaste of TCL. I personally know nothing about it though, but he claims that lisp is more powerful and clean
<Necrosporus>I know about that post, but it's outdated
<jmd> http://vanderburg.org/OldPages/Tcl/war/0000.html
<jmd>
<civodul>Necrosporus: it's a long story, but Scheme is a functional programming language, and it's an extensible language
<jmd>Tcl is almost dead today. Its only still with us because a few legacy applications still depend on it.
<Necrosporus>civodul, tcl is too functional and extensible
<Necrosporus>as far as I know Tcl is as powerful as Scheme but is easier to read and has more gentle learning curve
<taylanub>Necrosporus: Scheme is a very nicely designed language which is both very high-level and doesn't go overboard with "user-friendliness" thus can be compiled to very efficient code. s-expression syntax coupled with hygienic macros allow writing very neat EDSLs. there's probably a couple more points. and in the end, if we assumed they're equi-powerful, then the fact that we've went with Scheme so
<taylanub>far is enough justification to continue with it, since a switch would be extremely costly.
<jmd>Tcl is most certainly not easier to read.
<jmd>I think the learning curve is about the same.
<taylanub>ease of reading and learning curve are subjective; it could be said that scheme assumes its users to be willing to learn many new powerful ideas, instead of shoehorning them into widely known coding patterns, somewhat akin to Emacs for example.
<Necrosporus>jmd, it's 20 years long, languages evolved a lot since then
<Necrosporus>* old
<DusXMT>Necrosporus: C is even older than that, and we still use it
<DusXMT>Age doesn't matter much, if the language is designed good, it's good
<Necrosporus>I mean, Tcl has all features it was blamed for lack of them by now
<DusXMT>Changing things that work just for the sake of `evolution' isn't a really bright way of thinking.
<Necrosporus>Threads, modules, namespaces, objects and continuations
<Necrosporus>so the RMS post is outdated
<jmd>All Turing complete languages can do anything computable. The question is, not what can it do, but how elegant can it be done in that language. IMO Tcl doesn't do things elegently.
<civodul>Necrosporus: surely other languages could do the job, but it turns out that Scheme does it well and has a number of appealing features
<Necrosporus>civodul, I have read the document you mentioned, for me, nix build file seem to be easier to read and understand compared to scheme ones
<DusXMT>to each his own, arguing about tastes is pointless
<DusXMT>However, once you start thinking in parenthesies, it's hard to go back :)
<jmd>I'm still not sure how exactly to use (%current-system)
<civodul>Necrosporus: yeah well, i don't claim that it's to everybody's taste ;-)
<civodul>then again, Nixpkgs really uses two languages
<Necrosporus>bash and nix?
<Necrosporus>Also your paper says that building rpm and deb packages in not reproduciable, though I read about building ubuntu packages, there is a tool which creates a chroot environment for each package for building deb
<Steap_>Funnily, I know neither Nix nor Guile, and Guix recipes seemed easier to read
<DusXMT>Necrosporus: Guix/Nix go way deeper into the problem of reproducibility, and yet they still can-t produce 100% bit-reproducible executables, althought that's being worked on
<DusXMT>A sinple chroot is far from being enough
*Steap_ is reading mails about Wine and thinks civodul has no idea what kind of hell it is :D
*civodul confirms having no idea :-)
<civodul>i would expect it to just DTRT
<civodul>maybe i'm naïve
<Steap_>yeah, really wine 64 bit is not used by anyone :D
<Steap_>and it cannot really run 32 bits applications
<Steap_>it's a terrible mess
<Steap_>so we would need to build the 32 bits dependencies on x86-64
<Steap_>not sure if it's an issue
<civodul>uh, ok
<civodul>but is it a problem for people running proprietary apps, or a more general problem?
<Steap_>hum
<Steap_>well I think you may want to have both versions on your system
<Steap_>anyway Wine is mostly useful to run non-free apps :)
<civodul>well, i don't want to facilitate that
<civodul>i know it's also useful to develop free software for Windows
<civodul>that part is OK, IMO
<Steap_>I'm afraid the same issue might arise
<Steap_>so we may want to build both
<civodul>ok
<Steap_>or have two packages
<civodul>yeah
<Steap_>but it's really a huge PITA
<civodul>we could have the "normal" variant, and one with #:system "i686-linux"
<civodul>okay
<Steap_>I'm building wine from source on Debian, and it's terrible.
<civodul>iyzsong: WDYT? ↑
<jmd>Guix doesn't recognise match.
<jmd>ERROR: In procedure memoize-variable-access!:
<jmd>ERROR: Unbound variable: match
<jmd>
<jmd>Yes I do have: #:use-module (ice-9 match))
<jmd>
*nebuli thinks udev's dead in master... pivoting from initrd is foobar...
<iyzsong>civodul: the normal one should be (#:system "i686-linux"), I can add wine64 later :)
<Steap_>iyzsong: do ytou know if anybody uses the 64 bits version ?
<iyzsong>Steap_: not know to me
<DusXMT>Is the 64-bit version not backwards compatible with the 32-bit one?
<iyzsong> http://wiki.winehq.org/Wine64, no, as far as I understand
<davexunit>hey #guix
<sneek>davexunit, you have 2 messages.
<sneek>davexunit, ArneBab says: I think it would be great to have an option to save the whole guile session as a module. ,save-session-as-module "save-the-world-again.scm"
<sneek>davexunit, civodul says: thanks a lot for fixing the CVS commit hooks!
<davexunit>my recent blog post about guix has made it to the hacker news front page: https://news.ycombinator.com/item?id=8616918
<davexunit>upvotes welcomed :)
<davexunit>civodul: you're welcome! it *was* that cron job, after all.
<jmd>Is there a way of doing (self-native-input? #t) but specifying only one output ??
<civodul>hey, davexunit!
<civodul>my hero! :-)
<Necrosporus>Is dmd not as bad as systemd?
<ArneBab>davexunit: this is really cool!
<civodul>iyzsong: ok, let's keep #:system for now, then
<davexunit>my web server has gotten 3785 hits since it showed up on HN.
<davexunit>I've never seen this much traffic to my site before.
<iyzsong>civodul: thanks :)
<iyzsong>davexunit: great!
<civodul>you're famous now :-)
<ArneBab>davexunit: I did not expect that, but guix environment provides a solution to a deep seated problem for distributed development: A program requires multiple tools with multiple build systems to work. It allows saying “just use this environment to build” without having to resort to describing the way to set it up for multiple distributions.
<ArneBab>and that is really cool
<ArneBab>kind of a meta-distribution system :)
<davexunit>civodul: my girlfriend says that this is my "15 minutes", but come on! it has to last longer than that, I already signed the paper work for a new Porsche!
<ArneBab>
<ArneBab>davexunit: you should give a talk about that.
<davexunit>ArneBab: thanks! it's our equivalent of an existing tool in nix called 'nix-shell'.
<davexunit>though I think that our tool is implemented more cleanly, and is more robust.
<ArneBab>there remains just one problem: its usefulness depends on making guix extremly easy to install on every platform.
<civodul>davexunit: ah ah :-)
<davexunit>ArneBab: I think it would be great if we could get a debian/fedora/etc. developer to package guix.
<ArneBab>a page “setting up guix environment” with *definitely working* instructions for every system which people can simply reference could make this a new default.
*jmd wants a USB image for i386
<civodul>jmd: build it yourself: guix system vm --image-size=800MiB gnu/system/install.scm
<civodul>:-)
<davexunit>ArneBab: it also depends upon the package they need being in guix, so we have a ways to go. :)
<ArneBab>davexunit: if the package is missing they can fix that ☺
<jmd>civodul: How long does it take?
<jmd>And where is the parameter to tell it that I want i386 ?
<davexunit>--system I think?
*davexunit doesn't have guix on his work machine
<civodul>jmd: if you're on i686 already, it'll build for i686; otherwise, use --system=i686-linux
<jmd>ok.
<civodul>that said, the release may well be for tomorrow
<civodul>i haven't seen any serious issue reported
<davexunit>I haven't tested the install image yet. :( I don't have the FSF x60 like last time.
<davexunit>I'm going to try to test with another computer of mine tonight, if possible.
<jmd>Och. (self-native-input? #t) seems not to set PATH
<jmd>is that a bug or by design?
*davexunit likes the screenshot viewer.
<davexunit>I wish it looked better when JS is disabled, though.
<civodul>it looks OK in emacs-w3m
<civodul>jmd: dunno, it may well be a bug
<davexunit>I see tiny thumbnails
<davexunit>in mozilla
<civodul>yeah, they're very small
<jmd>In the meantime, how can I workaround it? I need something like (native-input `( ,(if (%current-target-system)
<jmd> `("glib-native" ,glib "bin") '())))
<jmd>
<roptat_>I compiled xfce4-terminal with its dependencies (vte, xfconf, libxfce4util and libxfce4ui). Do you prefer one big patch or one patch for each of them?
<jmd>What's the difference between inputs and %build-inputs ?
<bavier`>jmd: I believe %build-inputs is a special build-side variable that lists all the inputs. In most cases it should hold the same thing as the "inputs" keyword argument.
<bavier`>roptat_: please send separate patches for each new package; it makes reviewing them easier.
<jmd>bavier`: Yeah. I found a case where they didn't. That's why I asked.
<bavier`>jmd: guix/build-system/gnu.scm:238 might be the place to look.
<roptat_>There is a package with a COPYING file that contains the GPL2 license, but its source code says LGPL2 only. What is the license of this package?
<DusXMT>roptat: It's GPL2. This happens most commonly in cases where the project uses GPL'ed libraries. The project itself then has to be licensed, as a whole, under the GPL
<DusXMT>But thinking about it... the whole point of the LGPL is to allow programs of non-GPL-compatible licenses to use the library, which putting the entire thing under the GPL completely defeats the purpose...
*civodul prepares to tag the tree
*jmd Thinks civodul owes him a drink.
<civodul>do i? :-)
<davexunit>other way around, right? :P
<jmd>Copying those static binaries bricked my arm device.
<civodul>oh