IRC channel logs


back to list of logs

<mark_weaver>The new MIPS N32 bootstrap is going well. I've built make-boot0, diffutils, findutils, binutils-cross-boot0, gcc-cross-boot0, perl, linux-libre-headers, glibc-intermediate, gcc-cross-boot0-wrapped, and bash-light. Now working on the final glibc.
<civodul>Hello Guix!
<mark_weaver>good morning, civodul!
<civodul>hey, mark_weaver
<civodul>how is it going?
<mark_weaver>very well!
<mark_weaver>I've built make-boot0, diffutils, findutils, binutils-cross-boot0, gcc-cross-boot0, perl, linux-libre-headers, glibc-intermediate, gcc-cross-boot0-wrapped, bash-light, and almost done building the real glibc (currently in the strip phase).
<mark_weaver>yes, it's slow :)
<civodul>still, that's good news!
<civodul>so you mounted a different fs on /tmp to workaround the problem you had, right?
<viric>mark_weaver: in nixpkgs, I used a trick with a distcc impurity, to get PCs collaborating
<mark_weaver>I like that idea, but I'd want to make sure that no impurities were getting in.
<viric>well, first you go fast with distcc, and some day, you go the slow path.
<mark_weaver>the real glibc is built, now on to the real binutils.
<mark_weaver>what are these '-wrapped' derivations? what is getting wrapped, and how?
<viric>I think ld has to be wrapped
<viric>to handle lib paths, rpaths, ...
<viric>(a script named 'ld' calls the original 'ld' with extra parameters)
<mark_weaver>civodul: any idea when /nix/store will be renamed to /guix/store ?
<mark_weaver>I guess maybe when you don't need Nix anymore, when Guix is sufficient on its own?
<mark_weaver>nevermind, it's a pointless question
<viric>I remember hearing about a milestone date for that.
<civodul>mark_weaver: 'ld' is wrapped, see the comment at the top of ld-wrapper.scm
<civodul>mark_weaver: for the store, you can already do this with --with-storedir=/guix/store :-)
<civodul>it just works
<civodul>i was thinking of /gnu/store tho
<civodul>the only thing is that if uses a different name, then you can't substitute
<mark_weaver>ah, right. that
<viric>civodul: I was wondering... given how much Debian criticised Nix, what is their relationship with Guix now :)
<mark_weaver>that's probably better, actually.
<civodul>viric: there's no such thing as "Debian", in that it's a very diverse group of people
<viric>I know, I know. I was simplifying. Do you remember the wikipedia-referred article though?
<civodul>hmm no?
<viric>bottom link
<viric>it has always been there.
<viric>By "Debian criticised", I just wanted to ring you a bell about that.
<civodul>aah ok, sorry
<civodul>ok i remember the debian-devel message
<viric>is there already a debian-devel message about guix?
<civodul>trolls are not necessarily interesting ;-)
<viric>well, Debian looks so much as 'the GNU distro', and so I wondered if they have something to say about Guix
<viric>I guess this counts as "the debian-devel message"
<viric>despite not being debian-devel
<civodul>"that's cool" :-)
<viric>What system is RMS using in the lemote?
<mark_weaver>Wow, that wording is very atypical for him. I don't think I've ever seen him say or write "that's cool"
<gzg>viric: Last I heard gNewsense, though he was considering Parabola last I heard.
<viric>I don't think he uses a lot of software though.
<gzg>On that note, does Guix work on Debian Wheezy -- or do I have to compile a bunch of stuff not in the repos?
<gzg>viric: Yup, very modest means. He rarely even opens xorg, from what I hear. :^)
<viric>civodul: does the guix repository have any restriction on the expressions it can contain? Is an expression for 'skype' welcome, let's say? :)
<gzg>viric: Non-free software -- I assume is a no-go... :^U
<viric>gzg: since linux got the framebuffer thing, x were much less a need :)
<mark_weaver>gzg: yes, it works on debian wheezy
<gzg>viric: I doubt RMS renders Emacs via GTK in a framebuffer though. It'd be interesting to see if someone writes a compositor for Emacs in Wayland, if RMS would use graphical Emacs on a regular basis though, I think.
<mark_weaver>gzg: On my Wheezy box, I compiled and installed libgc-7.2d and guile-2.0.9 from source before installing Guix, but iirc it should work well enough with the guile-2.0.5 that comes with wheezy.
<viric>gzg: I thought more of looking at bitmaps
<viric>or videos
<gzg>mark_weaver: Cool, I'll look into it this weekend then. :^)
<mark_weaver>RMS runs emacs in a text console.
<gzg>mark_weaver: That's what I suspected.
<viric>I hope RMS doesn't use the text mode; the pixels in bios text modes are rendered by a blob in the video card.
<gzg>viric: RMS has an all free device though via the Leemote Yeelong though, right?
<viric>I imagine the video card still renders the pixels in the vga text modes. :)
<gzg>Woah, though combo. :^P
<mark_weaver>gzg: RMS uses the YeeLoong 8101B. (so do I)
<gzg>mark_weaver: The next device I buy, will probably end up being one... assuming I can still find one (which will be, I assume, unlikely).
<mark_weaver>gzg: still has them in stock (and they're on sale now), but if you want one you'd better be quick because they are no longer being produced.
<gzg>mark_weaver: I by no means have the money and this laptop is new-enough, that I don't really have an excuse sadly. :^/
<viric>has anyone tested those quadcore notebooks by lemote?
<civodul>viric: it's about freedom:
<viric>civodul: aha! Good
<mark_weaver>viric: the yeeloong does not have a hardware "text mode". it's a framebuffer.
<viric>these days, running a spread distro feels as free as running a factory-flashed android
<gzg>civodul: Should we ever package anything but stable versions of software?
<viric>mark_weaver: really? the fuloong has a text mode I think
<civodul>gzg: only released stable versions, unless we don't have a choice (that happens sometimes)
<mark_weaver>so when I say he uses "text mode", I mean that it looks like text mode to userspace, but really Linux (the kernel) is drawing text on the framebuffer.
<gzg>civodul: Gotcha.
<civodul>viric: a spread distro?
<mark_weaver>viric: I don't know much about the fuloong.. it has much different video than the yeeloong.
<viric>civodul: I had in mind the gentoo, parabola, arch, ubuntu, debian ...
<viric>nixos included
<gzg>viric: For a Skype replacement, have you seen "Tox"? It seems fairly promising.
<viric>gzg: oh, I didn't know!
<mark_weaver>I guess I should admit that I don't really know whether YeeLoong has a hardware text mode. but I *do* know that I've never seen it used.
<civodul>viric: yeah, unfortunately these trendy distros are not concerned with user freedom
<viric>civodul: it's only about running all software available
<gzg>viric: It's P2P, encrypted, and GPLv3 -- that's three really big sellers for me. It's still in alpha, from what I can tell; But it looks like it's going to keep the steam to develop a solid protocol and client on-top of it.
<viric>yes, very nice
<viric>gzg: do you already use filegive, for sending files? It's the trend
<gzg>Honestly, never heard of it.
<civodul>filegive rocks
<civodul>(if only it were written in Guile... ;-))
<viric>there are people that rewrite programs in guile. maybe you can ask them ;)
<civodul>i have a history of doing that :-)
<viric>we know, we know. hehe
<civodul>sometimes i find myself a bit scary
<viric>Freedom through forgery, isn't it?
<gzg>Well, I'll be back later. See y'all. o/
<viric>civodul: I've the problem that I always write trivial programs.
<viric>non-trivial programs are unsustainable and unauditable, among other features. ;)
<civodul>viric: think of programs as modules/libraries
<viric>I can't understand how people can use a computer without task spooelr, either.
<civodul>and everything becomes much clearer :-)
<viric>civodul: those are only tricks
<civodul>not really
<civodul>depends on how you approach it
<viric>:) I was joking
<viric>no need to elaborate
<civodul>i'm looking for a job, BTW
<viric>Since some months, I was asking myself: how does civodul manage to do so much things and have an income?
<viric>so much *good* things
<viric>looked to me like a contradiction
<civodul>the income is unrelated to the good things ;-)
<viric>it could be the only explanation.
<viric>civodul: yoru interests are systems programming and free software, right?
<civodul>yes, and functional programming
<viric>ah ok
<civodul>a bit "too much" ;-)
<viric>I can't help with any job offer I might know
<jeffrin>i have downloaded guix source and compiled it
<jeffrin>is guix.go a guix binary
<Steap>it's a Guile Object :)
<jeffrin>so how to run guix ?
<Steap>once you've installed it, you need to run the daemon
<Steap>then you can run "guix"
<jeffrin>i think i have started the daemon
<Steap>Have you read the manua l?
<Steap>did you create the builders ?
<jeffrin>you mean that useradd and other stuff
<jeffrin>i have done that
<Steap>adding them to the right group and stuff
<jeffrin>i put all thod things in a script and executed it
<Steap>so now
<Steap>you could try
<Steap>guix package -i hello
<Steap>which should install the 'hello' program in ~/.guix-profile/bin/
<jeffrin>i do not seem to have a guix command
<Steap>Did you run "make install" ?
<jeffrin>Just ran
<jeffrin>now command is working
<jeffrin>is it downloading glibc
<jeffrin>yes i think
<jeffrin>it may be downloading glibc and gcc along with hello
<mark_weaver>why does /nix/store/*-glibc-2.18/bin contain bash?
<mark_weaver>that seems odd to me
<viric>mark_weaver: it's to avoid glibc depending on bash
<viric>mark_weaver: for system() and alike
<viric>(can it be?)
<civodul>i think so :-)
<mark_weaver>ah, okay
<civodul>if you're talking about what i think you're talking about, then you may find answers in
<mark_weaver>civodul: indeed, that's exactly what I was looking for. it all makes sense now, thanks!
<civodul>aah, you're welcome :-)
<mark_weaver>my YeeLoong is currently chugging away at building the first of two 'gcc' derivations (the one that uses the bootstrap shell binary, I guess)
<civodul>there's one "cross" gcc, then two libc, and then the final gcc
<mark_weaver>no, this package is actually called just "gcc".
<civodul>so that must be the final one
<mark_weaver>well, for some reason, it's going to build two different ones called "gcc"
<mark_weaver>c1j010q1wn8cj3xggakjmqgjv0k6s8xf-gcc-4.7.3.drv and p2sx17501ghi0r36ihz92iks5gqcvf4n-gcc-4.7.3.drv
<civodul>aah, when running 'guix build bootstrap-tarballs', right?
<mark_weaver>no, I'm just running 'guix build bash'
<civodul>yeah in that case it builds a bunch of gccs
<mark_weaver>yeah, there are several packages like that
<mark_weaver>where it's going to built what looks like the final package more than once.
<mark_weaver>it's doing that for bash, diffutils, findutils, gcc, gmp, m4, and make. some packages will be built three times: ncurses, perl, and readline.
<civodul>mark_weaver: try: guix gc --references $(guix build -e '(@ (gnu packages base) gcc-final)' -d)
<mark_weaver>and when I say "two times" or "three times", I mean that the .drv filename is identical except for the hash.
<civodul>there's only "gcc" and "gcc-cross-boot0" there
<civodul>ah yes: guix gc --requisites $(guix build bash -d) |grep gcc|grep -v -E '(guile-builder|tar|wrapped)'
<civodul>two gccs here
<civodul>aaah no, that's OK
<civodul>mark_weaver: the .drv hashes are different, but the output file name is the same (if you look in the .drvs)
<civodul>that's because one downloads its source with the bootstrap Guile, whereas the other one downloads it with the final Guile
<civodul>but it's the very same tarball, so the end result is the same
<mark_weaver>ah, so it should not build it a second time?
<civodul>(remember that there can be more than one .drv leading to a given output)
<civodul>no, it's only built once
<civodul>so it won't be too hot at home ;-)
<mark_weaver>I still have much to learn about Nix/Guix.
<mark_weaver>civodul: I guess I should ask whether you have any objection to my method of enabling the Loongson 2F bug workaround by default.
<viric>civodul: more than one drv for an output? Really?
<viric>ahh ok the downloads.
<viric>the fixed output derivations
<mark_weaver>I changed 'gas' to implement the workaround by default on all MIPS code.
<viric>the nop thing?
<viric>I somehow remember enabling it in gcc, but maybe it was gas :)
<mark_weaver>whereas the upstream 'gas' doesn't do it by default. instead, you must pass a flag to 'gas' to implement the workaround, and gcc is commonly patched to pass that flag to 'gas'.
<mark_weaver>upstream 'gas' implements flags that enable the workaround.
<mark_weaver>note that there is also a 'gas' switch to *disable* the workaround, which still works in my patched version.
<mark_weaver>my rationale is that I want MIPS .s files to add the workaround by default, without special patching.
<viric>by 'upstream gas', do you mean, an unreleased gas?
<viric>yes, clear
<mark_weaver>no, it's in the released binutils.
<mark_weaver>I believe that Debian instead patched gcc to pass the workaround flag to 'gas'.
<viric>I don't remember having to patch anything...
<viric>ah right, I found it. I'm using --enable-fix-loongson2f-nop in binutils, not gcc.
<mark_weaver>the relevant flag is -mfix-loongson2f-nop
<mark_weaver>viric: afaict, upstream binutils doesn't have --enable-fix-loongson2f-nop.. 'gas' supports -mfix-loongson2f-nop (and -jump, needed for the kernel), but they must be passed to 'gas' each time its run.
<mark_weaver>--enable-fix-loongson2f-nop sounds vaguely familiar as something I might have come up with for gNewSense a couple of years ago, but I don't remember clearly.
<viric>are you sure? hm
<viric>maybe the *current* binutils don't support that?
<viric>but some old did?
<mark_weaver>I suspect it was only ever in patched versions of binutils, used within the Loongson community.
<mark_weaver>but I'm not 100% sure
<mark_weaver>and I believe the relevant patch may have originated with me.
<mark_weaver>ah yes:
<viric>but I never used gnewsense...
<viric>I'll check
<mark_weaver>yeah, but the patch was probably picked up by some other distros.
<viric>then it seems I never enabled this nop thing
<viric>I was fooled by this flag! :)
<viric>I'll have to rebuild the whole thing.
<viric>incredible how far it wnet.
<viric>another binutils thing. I try to build libsodium, and I get:
<viric>src/libsodium/ error: HAVE_LD_OUTPUT_DEF does not appear in AM_CONDITIONAL
<mark_weaver>maybe your processor doesn't have the bug (I think they might have fixed it at some point during the 2F production)
<viric>does this ring a bell?
<mark_weaver>actually, I've never run into the bug either
<mark_weaver>viric: I don't think I've seen that error before
<viric>I don't know any autoconf.
***ae is now known as Guest2985
<Guest2985>Does anybody know an interesting and simple qt application? I would like to package something easy to exercise my qt libraries. Just because they compile and pass their tests does not mean they actually work...
<viric>Guest2985: freicoin
<Guest2985>A strange project. INSTALL speaks about compiling bitcoin. They might have run 'sed' when forking.
<Guest2985>It is qt4. I will have to wait for this one.
<Guest2985>We are too bleeding edge for the real world!
<viric>ah, what qt did you mean?
<viric>is there qt5? :)
<Guest2985>Qt 5.1.1 is already in the distribution.
<Guest2985>Right now, I am trying to compile Qt 4.8.5.
<viric>yes, far too bleeding edge I think
<civodul>mark_weaver: i'm fine with putting the Loongson patches by default
<civodul>mark_weaver: it also works for YeeLoong, right?
<civodul>viric: the libsodium error means you're running autoconf, which you shouldn't
<civodul>well, automake
<viric>civodul: no, it comes with ./ (which calls autoreconf). ACLOCAL_PATH=`pwd`/m4 fixed it
<civodul>yes, but you don't want to run that when building from a tarball
<viric>it's not from tarball
<viric>their tarballs are lazy github snapshots
<civodul>(unlike cmake-using projects, autotools-using projects don't require the autotools)
<civodul>lazy github snapshots...
<civodul>silly people
<civodul>well ok then :-)
<viric>yes, they didn't understand autotools, definitely.
<civodul>so the error you gave means their or is buggy
<viric>maybe I'm just picking the wrong file. I'll check.
<viric>Oh, my fault, they have a proper tarball I didn't find first.
<civodul> should read AM_CONDITIONAL([HAVE_LD_OUTPUT_DEF], [...])
<viric>civodul: this line is in their m4/
<mark_weaver>civodul: great, thanks! Loongson 2F is the name of the processor that's in the YeeLoong (and FuLoong)
<mark_weaver>the workarounds are needed for the Loongson 2F
<mark_weaver>anyway, gotta go afk for a while.. ttyl!
<viric>Guest2985: I just hit this one in qt5:
<Guest2985>Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)"
<Guest2985>After one hour of computation!
<Guest2985>Very suspicious. This should have been solved in commit a2270ce2.
<civodul>Guest2985: icui18n in's RUNPATH?
<civodul>err, is icui18n in's RUNPATH?
<Guest2985>It should be, no? icu4c is an input to the package.
<Guest2985>viric: Interesting. I suppose it depends on tox?
<viric>yes, and this on libsodium
<Guest2985>Which you are packaging right now?
<viric>I don't have qt-5 in nixpkgs :(
<viric>No, I'm not doing any guix dev :) I'm a lurker
<Guest2985>We are so modern in Guix!
<civodul>cutting edge!
<Guest2985>You should give it a try, viric.
<Guest2985>Just because you can.
<viric>I know I will join.
<viric>But I won't touch scheme without understanding a bit more about it :)
<Guest2985>civodul: There is also "tst_qwebelement: cannot connect to X server".
<civodul>it seems to fail to connect to the X server
<civodul>Guest2985: is that in the chroot?
<viric>yes, check the connection with the X server
<viric>do any of you play any bitcoin/freicoin?
<Guest2985>I wonder if I need xorg-server or something else; how come we have not yet packaged xvfb?
<viric>In my begging internet life, I'll try to show my wallet key in my projects, to see if I get some bitcents
<Guest2985>viric: I have a bitcoin account, for which I mined some 10^-{?} bitcoins once, just to see how it works. I think they are worth about one real cent.
<civodul>a € cent, or a $ cent?
<civodul>what's xvfb BTW?
<viric>an x server for the frame buffer? no idea.
<viric>civodul asked what is xvfb
<civodul>aaah, thanks
<Guest2985>Actually, sorry, we have packaged xvfb - it is simply part of xorg-server.
<viric>ah I didn't know this. nice.
<Guest2985>So, what do I do with my mips64el-linux-gnu bootstrap binaries now? The documentation could be a little more explicit for dummies...
<Guest2985>civodul: I see my question on bootstrapping has shocked you and kicked you out of the channel...
<Guest2985>How do I get things running on the fuloong now? Where do I put the bootstrap tarballs?
<Guest2985>Just into the store with "guix download file:..."?
<mark_weaver>Guest2985: you'll want the work that I'm currently doing.
<Guest2985>And a few binaries from static-binaries-0-... into gnu/packages/bootstrap/mips64el-linux-gnu ?
<mark_weaver>you'll need different bootstrap binaries than the ones that are currently publicly available.
<Guest2985>The ones I build from the wip-loongson branch are not valid?
<mark_weaver>what commit number are you on?
<mark_weaver>okay, that's current. what command did you use to build the bootstrap tarballs?
<Guest2985>guix build --target=mips64el-linux-gnu bootstrap-tarballs
<mark_weaver>okay, good
<mark_weaver>(assuming that the 'guix' you were using was actually cf8bb376cf959c4cea7c28370d052a48811b623a and not an older installerd version)
<Guest2985>The output is /nix/store/1psfxbw2pvznbkj16llbsblc6r2mxm6d-bootstrap-tarballs-0 .
<Guest2985>Wait -
<Guest2985>I am doing a ./preinst-env just to be sure.
<mark_weaver>that's what I always do
<mark_weaver>on the FuLoong, you'll need to copy the relevant binaries into gnu/packages/bootstrap/mips64el-linux/ with the right permissions, and apply something close to the following patch:
<mark_weaver>you'll need to replace "/home/mhw/guix-loongson-tarballs-n32/" with the directory containing the tarballs.
<mark_weaver>and on the FuLoong, make sure that /tmp is on a different filesystem than /nix/store
<Guest2985>The "relevant binaries" are bash, mkdir, tar and xz from the static-binarires-... package, right?
<mark_weaver>right. and you also need to copy the guile tarball into there, renamed to "guile-2.0.9.tar.xz"
<mark_weaver>(the guile bootstrap tarball, that is)
<Guest2985>Then what happens to the other ones? binutils, gcc, glibc, guile?
<mark_weaver>see the patch
<Guest2985>Is the guile-2.0.9.tar.xz not created automatically? From some guile in the store?
<mark_weaver>which includes references to a directory where the tarballs are found.
<mark_weaver>guile-2.0.9.tar.xz should be a copy of guile-static-stripped-2.0.9-mips64el-linux-gnu.tar.xz, one of the tarballs that should have been created
<Guest2985>Okay, I see.
<mark_weaver>I'm only part way through the bootstrap myself. I don't know for sure that all the problems are fixed....
<viric>civodul: did you already write the nix expression to install guix, in the guix repository?
<Guest2985>Instead of your last modification to bootstrap.scm, I think one could also just put the tarballs into the store using "guix download file:binutils-..." etc., and then add the hash in a new "(match system" clause. This should also make the first part of your patch obsolete.
<mark_weaver>that entire patch is just a hack for now..
<Guest2985>Anyway, it looks like I forgot the "./preinst-env" yesterday and will need a few hours now to compile the correct bootstrap tarballs.
<mark_weaver>after I've build natively-built bootstrap tarballs, we'll put those in the official place where bootstrap tarballs are made available, and I'll make a more proper set of patches.
<mark_weaver>this is all very preliminary right now.
<Guest2985>This could be the occasion to switch all bootstrap tarballs to guile 2.0.9.
<Guest2985>I should be able to do a "make" on guix on mips right now, no?
<Guest2985>It fails on guix/scripts/download.scm with a lengthy message, that ends with
<Guest2985>ice-9/boot-9.scm:106:20: In procedure make_objcode_from_file: bad header on object file: "GOOF----LE-8-2.0"
<mark_weaver>I guess this should be merged first into 'core-updates', and then MIPS will be part of the next 'core-updates' merge into master.
<mark_weaver>it sounds like you have a broken guile install, or something.
<Guest2985>It is guile 2.0.5 from debian wheezy, as on x86_64.
<mark_weaver>you might try clearing out your ~/.cache/guile/ccache/ directory
<mark_weaver>do you have multiple versions of guile installed?
<Guest2985>There is only one. Cleaning the cache does not help/
<mark_weaver>what version of guix are you trying to build?
<Guest2985>The wip-loongson branch.
<Guest2985>A fresh checkout.
<mark_weaver>well, fwiw, I also bootstrapped the tarballs from Debian wheezy, but in my case I had built gc-7.2d and guile 2.0.9 from upstream source code.
<mark_weaver>both of which are recommended.
<Guest2985>On x86_64, the guile 2.0.5 from wheezy works without problem.
<mark_weaver>guix is *supposed* to work with Guile 2.0.5, but I haven't checked that myself.
<Guest2985>And I have used it to build guix on mips before.
<Guest2985>Actually, the old guix version os still installed in /usr/local.
<mark_weaver>I'm busy with other stuff right now, and don't have much time to help debug this at the moment..
<Guest2985>No problem. I will just stop for now. Thanks!
<mark_weaver>I'd be glad to help more later..