<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. <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). <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? <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>the only thing is that if hydra.gnu.org uses a different name, then you can't substitute <viric>civodul: I was wondering... given how much Debian criticised Nix, what is their relationship with Guix now :) <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? <viric>By "Debian criticised", I just wanted to ring you a bell about that. <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>despite not being debian-devel <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 :) <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 <gzg>mark_weaver: Cool, I'll look into it this weekend then. :^) <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 <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: tekmote.nl 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? <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. <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 ... <gzg>viric: For a Skype replacement, have you seen "Tox"? It seems fairly promising. http://tox.im/ <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>gzg: do you already use filegive, for sending files? It's the trend <gzg>Honestly, never heard of it. <civodul>(if only it were written in Guile... ;-)) <viric>there are people that rewrite programs in guile. maybe you can ask them ;) <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 <viric>Since some months, I was asking myself: how does civodul manage to do so much things and have an income? <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? <viric>I can't help with any job offer I might know <jeffrin>i have downloaded guix source and compiled it <Steap>once you've installed it, you need to run the daemon <Steap>did you create the builders ? <jeffrin>you mean that useradd and other stuff <Steap>adding them to the right group and stuff <jeffrin>i put all thod things in a script and executed it <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>it may be downloading glibc and gcc along with hello <viric>mark_weaver: it's to avoid glibc depending on bash <viric>mark_weaver: for system() and alike <mark_weaver>civodul: indeed, that's exactly what I was looking for. it all makes sense now, thanks! <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>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? <civodul>yeah in that case it builds a bunch of gccs <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>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 <civodul>(remember that there can be more than one .drv leading to a given output) <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>the fixed output derivations <mark_weaver>I changed 'gas' to implement the workaround by default on all MIPS code. <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? <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>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>maybe the *current* binutils don't support that? <mark_weaver>I suspect it was only ever in patched versions of binutils, used within the Loongson community. <mark_weaver>and I believe the relevant patch may have originated with me. <viric>but I never used gnewsense... <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>another binutils thing. I try to build libsodium, and I get: <viric>src/libsodium/Makefile.am:219: 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) ***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... <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>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 <viric>civodul: no, it comes with ./autogen.sh (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>their tarballs are lazy github snapshots <civodul>(unlike cmake-using projects, autotools-using projects don't require the autotools) <viric>yes, they didn't understand autotools, definitely. <civodul>so the error you gave means their Makefile.am or configure.ac 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>configure.ac 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) <Guest2985>Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)" <Guest2985>Very suspicious. This should have been solved in commit a2270ce2. <civodul>Guest2985: icui18n in libqt.so's RUNPATH? <civodul>err, is icui18n in libqt.so's RUNPATH? <Guest2985>It should be, no? icu4c is an input to the package. <Guest2985>viric: Interesting. I suppose it depends on tox? <viric>I don't have qt-5 in nixpkgs :( <viric>No, I'm not doing any guix dev :) I'm a lurker <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 <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. <viric>an x server for the frame buffer? no idea. <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>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>(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 . <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" <Guest2985>Then what happens to the other ones? binutils, gcc, glibc, guile? <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 <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. <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. <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 <Guest2985>There is only one. Cleaning the cache does not help/ <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. <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!