IRC channel logs


back to list of logs

<jxself>Apple's interest in it is to be able to get rid of GCC, since they don't like copyleft.
<jxself>Or freedom in general for that matter.
<zacts>I guess my interest is that I'm a compiler nerd.
<zacts>I've been trying to decide between TenDRA/Gcc/Clang|LLVM
<zacts>and pcc
<zacts>and tcc
<jxself>If there are places in which GCC doesn't measure up technically, why not help with that?
<civodul>actually it seems that the NVIDIA back-end is free:
<zacts>jxself: I have heard that gcc code can be a bit obfuscated, at least in the past
<zacts>although, I've also heard that gcc is making steps to improve
<jxself>Help with that then. :)
<zacts>especially in competition with clang/llvm
<jxself>I'm sure that, one day, the entire clang/llvm thing will disappear into a proprietary binary.
<jxself>bkuhn talked about this at one point. I forget where - His blog, or the FaIF oggcast or somewhere.
<zacts>who is bkuhn?
<zacts>oh cool
<zacts>I do like how gcc is ported to so many platforms
<zacts>so, on the topic of guix.. what all is involved to port guix to a new cpu architecture?
<mark_weaver>the guix manual has a section of porting.
<jxself>Getting the bootstrap binaries built.
<mark_weaver>it's actually fairly well automated. I was pleasantly surprised.
<zacts>oh neat
<mark_weaver>the only work I really needed to do was to apply some patches to various packages for MIPS that aren't yet in the upstream tarballs.
<mark_weaver>for a more popular architecture such as ARM, I suspect it would be much easier.
*jxself would like to see PowerPC support but can't be botered to do it
<zacts>jxself: I would be interested in that also
<jxself>And 64-bit
<zacts>64 bit would be cool too
<zacts>I could help with 32 bit though
<zacts>as I have a few old I-Macs running debian
<jxself>Sure, none of the FSF-endorsed distros support PowerPC.
<zacts>jxself: yep, but guix would be way awesome on that platform
*zacts puts learn about ppc + linux kernel + toolchain on todo list
<zacts>jxself: debian is about as free as I can get for macppc
<mark_weaver>zacts: go for it! the first step is to run "guix build --target=<GNU-TRIPLET> bootstrap-tarballs".
<mark_weaver>(from some machine where Guix is currently supported)
<jxself>zacts: Indeed. At the moment I can't make any other suggestions. Trisquel could, in theory, support PowerPC since Ubunutu does.... but, they don't.
<zacts>personally, I have more hope for guix than any other current gnu distro..
<zacts>I do feel that it's so important to be able to build any component from source at any time, if that is what you want
<zacts>debian fails to really do this
<zacts>you depend on binary formats
<jxself>You can't do the whole apt-get source foo & go compile it?
<zacts>apt-get source only fetches the current revision, and things of that nature.
<mark_weaver>well, it's fairly easy to build packages from source in debian, but it's quite hard to bootstrap to a new architecture.
<zacts>jxself: you can't easily apt-get the entire operating system and build an exact copy from scratch afaik
<zacts>mark_weaver: well, of course. individual applications are simple to build.
<zacts>but an entire system is not so easy
<mark_weaver>yes, that's definitely true.
<mark_weaver>once upon a time, I would like to have bootstrapped debian for MIPS N32, but I found the task too intimidating. I didn't really know how to go about it.
<jxself>I've never tried, but I did mirror the source code for every release back to 2005 (Sarge) for John's talk at FOSDEM.
<jxself>So at least the source code is easy to get.
<zacts>I'm sure the gnewsense people would know
<mark_weaver>zacts: I don't know about that. they never bootstrapped to a new architecture.
<zacts>oh I see
<mark_weaver>they just modified a relatively small number of packages.
<jxself>In a way didn't they?
<jxself>Getting Ubuntu to run on mipsel?
<jxself>Back in the version 2.3 days when they were still based on Ubuntu.
<mark_weaver>I don't think they ever did that. the mipsel port was always based on vanilla debian, I believe.
<jxself>Oh? OK.
<mark_weaver>at one point, a few years ago, I actually took the lead in getting the gnewsense build system running again after the previous maintainer of it left under bad circumstances, so I know how it works.
<mark_weaver>they just mirror the vast majority of packages, blacklist some, and compile a tiny number of them from modified sources.
<mark_weaver>or at least that's what they did for metad. maybe parkes is slightly different, but probably not much.
<civodul>mark_weaver: looks like the core-updates patch won't be ready tonight :-/
<civodul>i've been building all day long
<civodul>adding C++ here and there
<civodul>things like that
<civodul>so we're almost there, but not quite
<mark_weaver>civodul: okay, thanks for working on it!
<mark_weaver>so you've actually had to modify C++ code in GCC?
<civodul>no no no
<civodul>i had to add an intermediate libstdc++ build, for instance
<civodul>and then there are problems because it doesn't get picked up automatically, etc.
<civodul>the problem is when you find an issue, you have to wait for a loooong time to see if the fix is correct
<mark_weaver>well, it's okay. it'll be ready when it's ready :)
<mark_weaver>in the meantime, the 'loongson' branch works quite well on my machines, so I'm happy.
<civodul>heh, good
<mark_weaver>civodul: on the topic of build machines for MIPS, do you think it would be feasible to use a large number of Loongson 2F machines?
<civodul>yes, why not? :-)
<mark_weaver>because djbclark and the FSF, together, have on the order of a dozen such machines just lying around doing nothing.
<civodul>as soon as we have support to off-load builds
<civodul>woow, great
<mark_weaver>we could try to convince someone to buy some 3A machines, but it seems more expedient to use the machines that are already lying around.
<mark_weaver>hydra might need some intelligence to make efficient use of so many machines, e.g. to prevent them from building the same package more than once.
<mark_weaver>I think that will require some analysis of the dependency graph, e.g. so that we don't ask two machines to build two different packages that each depend on a common input that's not yet built.
<mark_weaver>anyway, I have to take a break from guix for the next few days, and work on fixing the guile bug that is causing major problems for tupi.
<civodul>i did a bit of that back in the day:
<civodul>in practice brute force works quite well ;-)
<mark_weaver>the biggest issue there is the fact that I can't figure out how to safely use guardians with the async-based GC hook.
<mark_weaver>since you pushed back on my proposal for how to fix asyncs, I may need to talk with you about this at some point soon (but not now; I know it's late there)
<mark_weaver>s/GC hook/after-gc-hook/
<mark_weaver>hubble looks cool!
<civodul>yeah let me know if there's a discussion i should look at about async things
<civodul>off to bed now
<mark_weaver>good night! :)
<zacts>what is hubble?
<mark_weaver><civodul> i did a bit of that back in the day:
<zacts>oh cool
<zacts>I'm at a sushi bar
<zacts>while at the same time working on guix
<zacts>hubble reminds me of the song: bud's bubble - bud powell
<djbclark>yup, sittn' around
<mark_weaver>djbclark: are you referring to the 2F machines?
<mark_weaver>(for build machines)
<mark_weaver>A nice 3A-based server would probably be ideal, but we'd have to convince someone to buy them, and I don't even know how freedom-friendly they are. Therefore, a bunch of 2F machines seems more expedient, at least for now.
<Infiltrator>What are 3A and 2F machines?
<mark_weaver>The Loongson 2F and Loongson 3A are both MIPS-compatible processors, designed from scratch in China, and used in the YeeLoong laptops, including the YeeLoong 8101B which is the laptop that RMS uses.
<mark_weaver>The YeeLoong 8101B has a free BIOS and all the hardware in it can be used without binary blobs and with 100% free software.
<Infiltrator>I have heard of the YeeLoong laptops; but I did not know which chips they had. Thank you.
<mark_weaver>did you run guix-daemon as root?
<nalaginrut>ah, so many guys here ;P
<mark_weaver>and what was the exact command line you used?
<nalaginrut>mark_weaver: need to be root?
<mark_weaver>well, I think it's possible to run it as non-root, but I've never tried it, and it's likely to actually be less secure in the end, because it won't be able to make a proper chroot for the builds.
<mark_weaver>(the builds themselves are run as unprivileged users)
<mark_weaver>nalaginrut: did you read the "installation" section of the guix manual? you need to create some users and a group for the guix-builders.
<nalaginrut>I specified --build-users-group=root
<mark_weaver>nalaginrut: note that only the 'guix-daemon' needs to run as root.
<mark_weaver>nalaginrut: you should make the users and group, as specified in the manual.
<mark_weaver>it's a bad idea to run the build processes as root.
<nalaginrut>but use root should work in principle, right?
<mark_weaver>I'm sorry, I don't know enough about how guix-daemon works to answer that question.
<mark_weaver>but I strongly discourage you from running the builds as root.
<mark_weaver>it only takes a few minutes to set up the users and group.
*nalaginrut reading the doc
<nalaginrut>nalaginrut@Renee-desktop:guix> sudo guix-daemon --build-users-group=guix-builder &
<nalaginrut>[4] 28815
<nalaginrut>nalaginrut@Renee-desktop:guix> sudo guix package -i zile
<nalaginrut>accepted connection from pid 28818, uid 0
<nalaginrut>guix package: error: No such file or directory
<nalaginrut>13 operations
<nalaginrut>I think zile is an valid package name
<mark_weaver>nalaginrut: don't run guix package as root.
<nalaginrut>mark_weaver: ok, but it throws the same error
<mark_weaver>did you run 'make install' ?
<nalaginrut>for guix? I think yes
<nalaginrut>maybe it's the problem of my nix installing
<mark_weaver>did you install nix into the same prefix?
<mark_weaver>what prefix did you use to install Guix?
<mark_weaver>is that also where you installed nix? do you care about preserving your nix installation?
<nalaginrut>but IIRC I didn't have a chance to specify prefix of nix
<nalaginrut>I just run bootstrap
<mark_weaver>do you care about preserving your nix installation?
<mark_weaver>I think this is because the sqlite database has gotten out of sync with what's in /nix/store. and it might also be because of Nix being installed in the same prefix.
<mark_weaver>we can probably fix the problem by: rm -rf /nix /usr/local/var/nix
<nalaginrut>I don't care about preserving it
<mark_weaver>someone else got the same error message as you, and it was fixed by doing just that.
<mark_weaver>to be more specific: kill guix-daemon, then do the "rm" command, and then relaunch the daemon.
*nalaginrut trying
<mark_weaver>hi zacts
<mark_weaver>btw, never delete anything in /nix/store manually. if you want to do that, use the "guix gc --delete ..." command.
<mark_weaver>(the sqlite database in /usr/local/var/nix must be kept in sync with /nix/store, or else there will be trouble)
<nalaginrut>mark_weaver: nice~it works
<nalaginrut>but seems I have to use 'sudo' for guix package
<mark_weaver>nalaginrut: please, let's fix that. you shouldn't have to, and that'll just be a mess anyway.
<mark_weaver>what happens when you try to run guix package as non-root?
*nalaginrut Ctrl-c
<mark_weaver>you'll have to manually create the directory /usr/local/var/nix/profiles/per-user/<YOUR-USER-NAME>
<nalaginrut>first, I have to run guix-daemon with sudo, or it can't access /usr/local/var/nix
<mark_weaver>and chown it to your user.
<mark_weaver>yes, guix-daemon needs to run as root.
<mark_weaver>'guix' runs as non-root.
<nalaginrut>there'd be a helper script for all the manual operations
<mark_weaver>each user has his own profile of installed packages.
<mark_weaver>yes, there are still rough edges. these things will be naturally taken care of when guix becomes a standalone distro.
<nalaginrut>mark_weaver: working successfully now
<nalaginrut>nice work guy~
<nalaginrut>but I still don't think these operations should be done by users
<mark_weaver>btw, what will happen is this: ~/.guix-profile/ will become a symlink to a directory structure containing a bunch of symlinks, similar to how stow works.
<nalaginrut>let me try some helper script
<mark_weaver>nalaginrut: the problem is, it would have to be a setuid script, and there are security issues.
<mark_weaver>nalaginrut: the proper solution is to arrange for these directories to be created automatically when normal users are added.
<mark_weaver>anyway, please talk to civodul about it before spending time working on something, to avoid wasted time.
<nalaginrut>have to go for lunch
<nalaginrut>see ya
<mark_weaver>so you'll need to add ~/.guix-profile/bin to your PATH.
<mark_weaver>okay, ttyl!
<jmd>My daemon keeps crashing!
<mark_weaver>really? It has never crashed for me, and I've built every packages in Guix several times over on two architectures.
<mark_weaver>how does it crash? what version of GCC?
<jmd>gcc --version
<jmd>gcc (Debian 4.7.2-5) 4.7.2
<jmd>I typed:
<jmd>$ guix package --list-installed
<jmd>$ guix package --install=pspp
<jmd>and got:
<jmd>guix package: error: Connection reset by peer
<jmd>and the daemon is no more.
<mark_weaver>can you run the daemon within gdb and get a backtrace?
<jmd>I'll try.
<jmd>I will have to do that tonight or at the weekend. I'm not in a position to get root privileges right now.
<mark_weaver>you've been running the daemon as non-root?
<jmd>No. It was running as root.
<mark_weaver>okay. well, any details you can provide would be helpful.
<jmd>But on this terminal I cannot get root, so I cannot restart it.
<jmd>Which is the localstatedir which the manual talks about?
<zacts>do I really have to create dummy users when installing guix?
<mark_weaver>yes. they are the users that will run the build processes.
<mark_weaver>you can ask civodul if there are ways to avoid that, but I can assure you that it would be a much inferior setup.
<jmd>It strikes me that there are a lot of similarities between guix and aegis.
<mark_weaver>jmd: btw, did you run "make check" for Guix?
<jmd>I don't recall. Usually I do.
<zacts>ok cool
<civodul>Hello Guix!
*civodul turns #x21
<jxself>Hey there.
<jxself>Happy birthday sir.
<civodul>thanks :-)
<bavier>civodul: merry wishes on your birthday
<civodul>hehe tx
<jxself>I was thinking about the topic of slaves. How much storage is needed/how much does Hydra have, etc.
<civodul>crazy cycles: rebuild all -> ENOSPC -> guix gc -> rebuild all -> ...
<civodul>lemme check
<jxself>I was looking but have no idea for comparison to know.
<zacts>I've just turned 26 on the 8th of this month
<civodul>hydra has 400 GiB
<civodul>the big things are: TeXLive (4 GiB of sources, times 3), GCC, and Linux-Libre
<zacts>does guix require a lot of storage requirements?
<civodul>not necessarily
<civodul>it requires space when building big things like those above
<civodul>otherwise it's fine on our infinite disks/SSDs
<jxself>As long as the FSF has storage space to continue giving the VM?
<civodul>the VM is fine with 400 GiB
<jxself>How much is actually used?
<zacts>hm.. interesting
<civodul>there's a script running hourly or so that makes sure there's at least 80 GiB free
<jxself>So mostly full then.
<civodul>so for hydra is really how much we can retain
<civodul>less space means less things retained
<gzg>civodul: Happy b-day. Mine was actually yesterday (21). :^U
<mark_weaver>Happy birthday, civodul! :)
<civodul>gzg: oh, happy birthday too, then :-)
<civodul>same age, different base
<mark_weaver>I'll soon turn 21 in base 21 :)
<gzg>civodul: FYI, when my classes end for the year ... (~Dec 12th) I'm going to dedicate a significant amount of my time finishing up most of these expressions I've kept in limbo; Which has to be at least 20 by-now. Right now I'm back onto packaging rtorrent and with those depends, there's 5 in this file/module. :^)
<civodul>ah :-)
<civodul>gzg: you have 20 packages around?
<civodul>c'm'on you need to submit a couple of them ;-)
<civodul>slim would be great
<gzg>civodul: It's that OCD man. :^I
<mark_weaver>gzg: releasing early and often is better than big code dumps :)
<jxself>Well, since we're talking of ages I'll say that I am 0x24.
<civodul>coming out :-)