IRC channel logs


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!
<phant0mas>of course I would like to help with that!
<phant0mas>where can I find more info about this?
<phant0mas>can guix be compiled on a hurd system?
<Sleep_Walker>mark_weaver: not completely correct
<Sleep_Walker>1] I believe I fixed that already
<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: excellent!
<mark_weaver>phant0mas: the first step is to get Guix installed on a GNU/Linux box. Once you have that, you can use it to cross-compile bootstrap binaries for GNU/Hurd (see )
<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>(much easier than porting Debian, for example)
<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)
<Sleep_Walker>so I simply deleted this file from RPM
<phant0mas>mark_weaver: I am using guix on Arch for quite some time ,so the first step is done :D
<mark_weaver>phant0mas: excellent!
<mark_weaver>is the Hurd supported by the modern GNU toolchain (glibc/binutils/gcc) without patches?
<ArneBab_>mark_weaver: as far as I know yes
<civodul>Hello Guix!
<mark_weaver>hi civodul!
<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.
<mark_weaver>anyway, I'll give it some thought...
<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>are those priorities numeric values?
<mark_weaver>(or symbols that represent numbers)
<mark_weaver>well, we can talk about this later. I need sleep anyway.
<civodul>yes, numeric values
<civodul>Happy I love Free Software day! ♥
<civodul>(kindly reminded on #nixos :-))
<sriharsha>Is there any origin-method to fetch from local file system?
<viric>crazy fsfe people :)
<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>Steap_: :)
<viric>is today a 'love day' in France?
<Steap_>viric: it's Valentine's Day
<viric>I don't know what countries take that as a love day
<viric>hence I ask about france :)
<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>hm no
<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 :)
<Steap_>viric: isn't it ? :p
<civodul>sriharsha: just use a plain file name as the 'source' field of your package
<civodul>Steap_: Feb. *14th* :-)
<Steap_>civodul: ehey, you're the one who knows
<phant0mas>when cross compiling bootstraps what flag should I pass to --target for hurd?
<viric>something like that
<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> 130: 1 [arguments]
<phant0mas>In unknown file:
<phant0mas> ?: 0 [scm-error misc-error #f ...]
<phant0mas>ERROR: In procedure scm-error:
<phant0mas>ERROR: dynamic linker name not known for this system "i686-gnu"
<viric>that may not be autoconf then
<phant0mas>is there a problem with the flag I pass?
*mark_weaver looks
<phant0mas>maybe something doesn't recognize it?
<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>I don't know the answer off-hand.
<phant0mas>let me look into that
<mark_weaver>fwiw, I think the target should probably be "i686-gnu", not "i386-gnu".
<phant0mas>tried both :P
<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>ah, forgot about those.
<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>good :-)
<civodul>phant0mas: first thing would be to submite packages for MiG and Mach
<civodul>that's quite easy to do
<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>does mig need anything from mach? I suspect so, no?
<mark_weaver>what's the dependency ordering on those two packages?
<mark_weaver>oh, sorry, you just said :)
<mark_weaver>sounds like you're on the right track...
<phant0mas>but I think I should read more about guile and scheme
<mark_weaver>phant0mas: this is a good introduction to packaging for Guix:
<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>source code is the best tutorial :P
<phant0mas>I finished my exams, univercity will be closed for 2 weeks, guix here I come :-D
<mark_weaver>yay :)
<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>and then I will start preparing the package
<mark_weaver>sounds great, thanks!
<phant0mas>okay build mig is easy
<phant0mas>you just have to pass flags for i686 build
<phant0mas>now it's me and you gnumach :P
<phant0mas>how do I do "autoreconf --install" through guile?
<mark_weaver>(system* "autoreconf" "--install")
<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>(but with proper formatting)
<mark_weaver>I'm surprised the 'autoreconf' is needed though. that should have already been done in a tarball release.
<phant0mas>you are right
<phant0mas>now In order for mig to get compiled
<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.
<phant0mas>how should I name it?
<mark_weaver>how about "mach-headers".
<phant0mas>seems good to me :P
<mark_weaver>the corresponding package for linux-libre is "linux-libre-headers", defined in gnu/packages/linux.scm
<mark_weaver>I have to go offline for a while, good luck!
<phant0mas>when you build a package with guix , you use the 32 version or the 64 of each tool?
<phant0mas>I am ready to package gnu mach headers now
<phant0mas>but enough for today :P
<phant0mas>see ya tomorrow morning guys
<civodul>see you tomorro, phant0mas!
<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>that's expected
<civodul>but yeah
<mark_weaver>oh? can you explain?
<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>that adds an extra criterion
<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.
<mark_weaver>how will I know which .drvs to clean up?