IRC channel logs
2014-02-14.log
back to list of logs
<phant0mas>could guix package manager be used for a gnu system with a hurd kernel? <mark_weaver>phant0mas: yes, and we hope to do that at some point. <mark_weaver>if you'd like to help with that, it would be most welcome! <Sleep_Walker>2] I simply couldn't install texinfo docs before correctly, it wasn't OBS fault (I suspected Fedora support in OBS, which is completely unrelated to OBS itself - like you can't blame kernel for application termination after SIGSEGV) <mark_weaver>phant0mas: and then you can use those to build Guix on a GNU/Hurd machine and use them to bootstrap the distro. <mark_weaver>phant0mas: I did this process to bootstrap Guix on mips64el-linux, and it was relatively painless compared with what I expected. <mark_weaver>phant0mas: we'd be glad to give you lots of support here on channel and on guix-devel :) <mark_weaver>Sleep_Walker: how did you fix the texinfo problem on OBS? <Sleep_Walker>If I understand correctly, /usr/share/info/dir file is index, specific for package configuration - there is no point in installing the file directly <Sleep_Walker>instead I need to call install-info from post-install script (which I already did anyway) <phant0mas>mark_weaver: I am using guix on Arch for quite some time ,so the first step is done :D <mark_weaver>is the Hurd supported by the modern GNU toolchain (glibc/binutils/gcc) without patches? <mark_weaver>so, I made a little list of package ordering constraints that I care about, and now I have to make sure that anytime I install (or upgrade?) packages in Guix, that I must make sure to add some existing packages to the end of the -i list, to preserve the desired ordering. <mark_weaver>my constraints so far are these: (binutils ld-wrapper) (glibc bash) (net-tools inetutils) (procps coreutils) <mark_weaver>it would be nice to have a better way of dealing with these things, but these constraints might not be flexible enough to handle all cases. <civodul>yeah, it would be nice if we could specify how to handle collisions <civodul>Nix allows uses to assign package "priorities", but i don't find it very convenient <mark_weaver>well, we can talk about this later. I need sleep anyway. <sriharsha>Is there any origin-method to fetch from local file system? <Steap_>civodul: is this day today because nobody will have to celebrate both their love for Free Software and for their significant other ? :p <taylanub>I'd like a shirt with a gnu and a penguin holding hands. <viric>is today a 'love day' in France? <viric>I don't know what countries take that as a love day <Steap_>viric: most Western countries, I guess :) <viric>In catalonia we have such love day in the 23th of April. And the Valencian Country has it on the 9th of October. <Steap_>and nothing on February the 13th ? <viric>well, there is media spam about this valentine thing <viric>but there is also about Santa Claus, and foreign things like that. <viric>as if all the world was USA :) <civodul>sriharsha: just use a plain file name as the 'source' field of your package <Steap_>civodul: ehey, you're the one who knows <phant0mas>when cross compiling bootstraps what flag should I pass to --target for hurd? <viric>but if you talk about autoconf... remember that '--target' maybe is not what you want <phant0mas>I tried i386 and I am getting the error In gnu/packages/gcc.scm: <phant0mas>ERROR: dynamic linker name not known for this system "i686-gnu" <viric>that may not be autoconf then <mark_weaver>phant0mas: a line needs to be added to 'glibc-dynamic-linker' in gnu/packages/bootstrap.scm <mark_weaver>it needs to know the pathname of the dynamic linker on the hurd. <mark_weaver>fwiw, I think the target should probably be "i686-gnu", not "i386-gnu". <mark_weaver>yes, it wouldn't have worked anyway, but I think we should benefit from the i686 features in compiled code. <mark_weaver>in 2014, I doubt anyone is using anything less than i686 in the intel world. <mark_weaver>Guix targets i686 on GNU/Linux, so I guess we should follow that same choice for GNU/Hurd, no? <civodul>phant0mas: if it's for "guix build --target", the triplet should be "i686-gnu", indeed <civodul>but the problem is that you would need to package MiG, Mach, and the Hurd's glibc <civodul>and hook that into cross-base.scm and friends <mark_weaver>civodul: phant0mas indicated a willingness to help porting Guix to GNU/Hurd, and I was trying to steer him in the right direction, but I forgot some of what would be needed here. <civodul>phant0mas: first thing would be to submite packages for MiG and Mach <phant0mas>so I should start by packing Mig and Mach, getting to that then <civodul>and there are even recent tarballs for these two :-) <civodul>which was not the case some months ago <phant0mas>I will start from mig which is needed for compiling mach and hurd' glibc <mark_weaver>what's the dependency ordering on those two packages? <phant0mas>but I think I should read more about guile and scheme <mark_weaver>of course, learning about guile and scheme is probably a good thing, but you don't really need to know it to do basic packaging. <mark_weaver>and there are lots of examples in gnu/packages/*.scm <phant0mas>I finished my exams, univercity will be closed for 2 weeks, guix here I come :-D <davexunit>I need to get back to writing packages soon. <phant0mas>right now I am trying to compile mig the normal way, to see what "special treatment" it needs <phant0mas>how do I do "autoreconf --install" through guile? <mark_weaver>you should verify that the return value is 0, using 'zero?'. <mark_weaver>see 'boost' in gnu/packages/boost.scm for an example. <mark_weaver>well, in this case I guess you need to do it before the configure phase? <mark_weaver>so you'd do something like (arguments '(#:phases (alist-cons-before 'configure 'autoreconf (lambda _ (zero? (system* "autoreconf" "--install"))) %standard-phases))) <mark_weaver>I'm surprised the 'autoreconf' is needed though. that should have already been done in a tarball release. <phant0mas>we need the mach header files intalled first <mark_weaver>I think you'll need to make the mach header files a separate package. that's what we do for the linux headers. <mark_weaver>the corresponding package for linux-libre is "linux-libre-headers", defined in gnu/packages/linux.scm <phant0mas>when you build a package with guix , you use the 32 version or the 64 of each tool? <mark_weaver>civodul: fyi, I just got burned by an impurity in the Guix emacs build. <mark_weaver>MIPS supports multiple different page sizes. You can choose 4K, 16K or 64K. It's a kernel compile-time option. <mark_weaver>I built emacs on a kernel with a 16K page size. Now I'm running 64K page size, and the emacs I built no longer works. Hits an assertion failure in glibc's malloc. <mark_weaver>so, we need to make sure that the build machines for MIPS all use 64K page size. and more generally, on any platform with multiple page sizes, the build machine has to use the largest supported page size on that platform. <civodul>mark_weaver: isn't it the case that huge pages (at least on x86) allow the use of pretty much any page size at run time? <mark_weaver>along the way, I also discovered a problem with --gc-keep-outputs=yes. When the daemon was running with that flag, I was unable to "guix gc --delete" the old emacs build, even after deleting all of the referrers. <mark_weaver>I had to restart the daemon without that option to delete emacs. <civodul>well you probably still had the .drv around referring to it no? <mark_weaver>perhaps, but it wasn't listed by "guix gc --referrers" <mark_weaver>so if that was the problem, then I guess "guix gc --referrers" needs to be fixed to include those. <civodul>well, the semantics of --gc-keep-* is to keep things regardless of whether they have referrers <civodul>so, back to the emacs issue ;-), i don't really know what to do <mark_weaver>hmm, well, in that case --gc-keep-outputs=yes won't do what I need, because I guess it will keep everything.