IRC.

1 files changed, 464 insertions, 3 deletions

diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn
index 332fc03b..c6212da8 100644
--- a/hurd/running/nix.mdwn
+++ b/hurd/running/nix.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -8,7 +9,12 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
-[[!meta title="Nix-based GNU/Hurd System"]]
+[[!meta title="Nix-based GNU/Hurd System, Guix"]]
+
+[[!toc]]
+
+
+# Nix
 
 <http://www.nixos.org/>
 
@@ -25,7 +31,7 @@ Nix, and because of that, it uses per-package installation directories under
 `/nix/store`.
 
 
-# IRC, freenode, #hurd, 2013-02-04
+## IRC, freenode, #hurd, 2013-02-04
 
     <braunr> is it possible to use nix ?
     <braunr> or nixos
@@ -39,3 +45,458 @@ Nix, and because of that, it uses per-package installation directories under
     <civodul> (my favorite)
     <civodul> i've been willing to unbreak it, but now i rather invest time in
       Guix
+
+
+# <a href="guix">Guix</a>
+
+## <http://www.gnu.org/software/guix/>
+
+## IRC, freenode, #hurd, 2014-02-13
+
+    <phant0mas> is debian hurd the only way to use hurd?
+    <braunr> maybe
+    <braunr> there is arch hurd but i haven't heard from them in some time
+    <braunr> building from source is difficult
+    <phant0mas> what is the problem with building from source?
+    <braunr> no automated build system, except for debian
+    <braunr> each project has its own build system
+    <braunr> but there is no tool to take care of the global procedure
+      (i.e. build in the correct order, with the correct options, paths and
+      patches, etc...)
+    <youpi> well, there is, it's called Debian :)
+    <braunr> 00:17 < braunr> no automated build system, except for debian
+    <phant0mas> how far away is it  from building a gnu system with let's say
+      guix as a package manager?
+    <phant0mas> and hurd as the kernel?
+    <braunr> i don't know
+    <youpi> phant0mas: there are already proofs of concepts
+    <phant0mas> youpi: any more info about the proofs of concepts?
+    <youpi> phant0mas: ask civodul
+    <youpi> apparently he's not here atm, though
+    <phant0mas> I will ask him at guix channel
+
+
+## IRC, freenode, #hurd, 2014-02-14
+
+    <phant0mas> can I ask a question about configuring gnu mach from source?
+    <taylanub> phant0mas: IRC etiquette: don't ask to ask, just ask, it saves
+      time.  People often leave IRC open for long durations but don't always
+      check it, if you just leave your question in the channel someone might
+      come back and see it at any time (even hours later).
+    <phant0mas> when I try to configure gnumach with 
+    <phant0mas> CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld
+      -melf_i386' ./configure --prefix= --host=i686-unknown-linux-gnu
+    <phant0mas> on a 64 bit system
+    <phant0mas> I get the error 
+    <phant0mas> checking for i686-unknown-linux-gnu-gcc... gcc -m32
+    <phant0mas> checking whether the C compiler works... no
+    <phant0mas> configure: error: in `/home/manolis/Downloads/gnumach-1.4':
+    <phant0mas> configure: error: C compiler cannot create executables
+    <phant0mas> but if I remove the -m32 from CC='gcc -m32' the error
+      disappears
+    <phant0mas> what is the problem?
+    <braunr> what do you think there is a problem ?
+    <braunr> i don't think -m32 should be part of CPP/CC, but rather CPPFLAGS
+    <braunr> also, i don't think you need it since the target is well defined
+    <phant0mas> I am following exaclty the instruction from here
+      http://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html
+    <braunr> hm that's weird
+    <braunr> phant0mas: what does gcc -v says and what's your host system ?
+    <phant0mas> Using built-in specs.
+    <phant0mas> COLLECT_GCC=gcc
+    <phant0mas>
+      COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
+    <phant0mas> Target: x86_64-unknown-linux-gnu
+    <phant0mas> Configured with: /build/gcc/src/gcc-4.8-20131219/configure
+      --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
+      --mandir=/usr/share/man --infodir=/usr/share/info
+      --with-bugurl=https://bugs.archlinux.org/
+      --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
+      --enable-threads=posix --with-system-zlib --enable-__cxa_atexit
+      --disable-libunwind-exceptions --enable-clocale=gnu
+      --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-
+    <phant0mas> object --enable-linker-build-id --enable-cloog-backend=isl
+      --disable-cloog-version-check --enable-lto --enable-plugin
+      --enable-install-libiberty --with-linker-hash-style=gnu
+      --disable-multilib --disable-werror --enable-checking=release
+    <phant0mas> Thread model: posix
+    <phant0mas> gcc version 4.8.2 20131219 (prerelease) (GCC) 
+    <braunr> check config.log for the actual error message then
+    <phant0mas> http://pastebin.com/raw.php?i=eQ75qafX 
+    <phant0mas> if you want to have a look as well
+    <braunr> install gcc-multilib maybe
+    <braunr> or lib32gcc1
+    <sjbalaji> Installing gcc-multilib solves it.
+    <phant0mas> braunr: it works like a charm now
+    <braunr> phant0mas: good
+
+
+## IRC, freenode, #hurd, 2014-02-18
+
+    <phant0mas> why mig has no make target, and the executable gets generated
+      from the ./configure?
+    <phant0mas> I mean shouldn't make be the one building mig?
+
+
+## IRC, freenode, #hurd, 2014-02-19
+
+    <phant0mas> mig binary shouldn't be built by make? why is it built at the
+      end of the configure command?
+    <braunr> no idea
+    <phant0mas> http://pastebin.com/raw.php?i=2HVni53Y
+    <braunr> "creating mig" you mean ?
+    <phant0mas> loot at the end of the config output
+    <phant0mas> config.status: creating mig <--
+    <phant0mas> the binary
+    <phant0mas> and then when you call make
+    <phant0mas> it says no target
+    <braunr> weird
+    <phant0mas> normally binaries are built from make
+    <braunr> what system are you building on ?
+    <phant0mas> on Arch Linux x86_64 with gcc version 4.8.2
+    <phant0mas> I am using the flag i686-pc-gnu to crossbuild it for 32 bit
+    <phant0mas> I am using the tar file from here
+      http://ftp.gnu.org.ua/gnu/mig/
+    <phant0mas> version 1.4
+    <braunr> tar file ?
+    <braunr> ok, i guess it's fine
+    <phant0mas> so source from the tar file builds mig through configure?
+    <braunr> again, i don't know
+    <braunr> i never build mig myself
+    <braunr> but it does look weird
+    <braunr> look at the debian package maybe
+    <braunr> who knows, maybe you'll find a patch with some explanation
+    <phant0mas> okay then,going over that way right away
+    <phant0mas> thnx braunr
+    <teythoon> phant0mas: mig is a shell script wrapper
+    <phant0mas> so it's not a binary....
+    <teythoon> no
+
+
+## IRC, freenode, #hurd, 2014-02-21
+
+    <phant0mas> do I need some minimal set of drivers to build gnumach?
+    <phant0mas> because I get this error
+      ../linux/src/drivers/scsi/BusLogic.c:53:24: fatal error: FlashPoint.c: No
+      such file or directory
+    <phant0mas> when running make
+    <teythoon> i thought we fixed that
+    <teythoon> are your sources up to date ?
+    <phant0mas> I am using the tar ball
+    <phant0mas> cause I am trying to package it for guix
+    <teythoon> what tarball ?
+    <braunr> 1.4
+    <phant0mas> yes
+    <braunr> phant0mas: just don't build scsi drivers
+    <phant0mas> 1.4
+    <phant0mas> worked
+    <teythoon> why do we keep the driver if it doesn't even build ?
+    <gg0> on debian it builds with --disable-net-group --disable-pcmcia-group
+      --disable-wireless-group
+
+
+## IRC, freenode, #hurd, 2014-02-23
+
+    <phant0mas> why when I configure gnumach like this CPP='gcc -m32 -E -x c
+      -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ./configure --prefix=
+      --host=i686-unknown-linux-gnu it builds just fine but when I try to
+      configure it with ./configure --prefix= --host=i686-unknown-linux-gnu
+      CFLAGS='-m32' CPPFLAGS='-m32 -E -x c -undef -ansi' LDFLAGS='-melf_i386'  
+    <phant0mas> I am building it on a 64 bit machine
+    <phant0mas> when setting env vars before configuring everythings works like
+      a charm
+    <phant0mas> but if I pass them as flags to the configure ,it won't
+
+
+## IRC, freenode, #hurd, 2014-02-25
+
+    <phant0mas> what version of mae do I need in order to compile glibc for
+      hurd?
+    <phant0mas> make*
+    <azeem> phant0mas: did you have issues with a particular version?
+    <azeem> I believe GNU make is required, though
+    <phant0mas> I am using gnu make 4.0 and I get the error 
+    <phant0mas> These critical programs are missing or too old: make
+    <phant0mas> checking version of gmake... 4.0, bad
+    <azeem> phant0mas: that sounds bogus
+    <azeem> can you pastebin the relevant part of the config.log or so?
+    <phant0mas> of course one sec
+    <phant0mas> http://pastebin.com/raw.php?i=4CHZJi4W
+    <phant0mas> azeem_: any news about the problem I have with glibc?
+    <azeem_> phant0mas: sorry - got distracted - I suggest you post this to
+      bug-hurd or so
+    <azeem_> though it could well be Hurd-independent, then checking glibc
+      master and possibly filing a report there might be better
+    <azeem_> phant0mas: or in case you speak autoconf, check the conf check for
+      the make version
+
+
+## IRC, freenode, #hurd, 2014-02-26
+
+    <tschwinge> ph4nt0mas: Which glibc sources, and how are you
+      configuring/building?
+    <phant0mas> tschwinge: I am trying to crossbuild it from a linux 64 bit
+      machine with gnu make 4.0 and gcc 4.8.2 
+    <phant0mas> ../configure --prefix=/home/manolis/gnu/glibc/
+      --target=i686-pc-gnu
+    <phant0mas> wrong config
+    <phant0mas> ../configure --prefix=/home/manolis/gnu/glibc/
+      --with-headers=/home/manolis/gnu/include/ --host=i686-pc-gnu
+    <phant0mas> I am using the last one
+    <phant0mas> it says gnu make is too old
+    <phant0mas> this time I tried with glibc from the hurd git repo
+    <phant0mas> baseline branch
+    <phant0mas> should I build an older toolchain just for it?
+    <tschwinge> phant0mas: If you'd like to experiment with this, then please
+      use the tschwinge/Roger_Whittaker branch.  However, that one might still
+      be missing the glibc upstream change to allow GNU Make 4.0 and greater,
+      commit 28d708c44bc47b56f6551ff285f78edcf61c208a, so cherry-pick that one
+      (assuming there are no additional patches needed for GNU Make 4.0).
+    <phant0mas> okay going to  do that right away
+    <phant0mas> thnx :-)
+    <tschwinge> phant0mas: You have seen
+      http://www.gnu.org/software/hurd/toolchain/cross-gnu.html -- but beware
+      this may be out of date somewhat.
+    <phant0mas> tschwinge: I worked around that problem as you told me
+    <phant0mas> but it seems I forgot to build hurd 
+    <phant0mas> so I got the tarball
+    <phant0mas> but I am getting this error
+    <phant0mas> No rule to make target 'lowlevellock.h', needed by 'timefmt.o'.
+      Stop.
+    <phant0mas> after I manage to make all of this work I will write an up to
+      date guide on how to build the hurd  system
+    <phant0mas> for future reference
+
+
+## IRC, freenode, #hurd, 2014-02-27
+
+    <ph4n70m4s> when trying to build gnumach microkernelin a 32 bit enviroment
+      it builds just fine
+    <ph4n70m4s> but when i try to crossbuild it from a 64 bit machine, even
+      though i am using --target=i686-gnu --host=i686-gnu  to crossbuild it I
+      am just getting the error i386/i386/i386asm.symc:116:1: warning: asm
+      operand 0 probably doesn't match constraints [enabled by default]
+    <ph4n70m4s>  __asm ("\n\
+    <ph4n70m4s>  ^
+    <ph4n70m4s> i386/i386/i386asm.symc:116:1: error: impossible constraint in
+      'asm'
+    <ph4n70m4s> http://pastebin.com/raw.php?i=emag63N4 
+    <ph4n70m4s> the config.log
+    <ph4n70m4s> and the build output if anyone want to have a look
+    <ph4n70m4s> http://pastebin.com/raw.php?i=jAZPnybB
+    <ph4n70m4s> wants*
+    <ph4n70m4s> I am building through guix so you may see some strange paths 
+    <tschwinge> ph4n70m4s: Nice, Guix!  :-)
+    <tschwinge> ph4n70m4s: Does that help?  CC=gcc\ -m32
+    <tschwinge> Because:
+    <tschwinge> configure:3574: gcc -v >&5
+    <tschwinge> Using built-in specs.
+    <tschwinge> COLLECT_GCC=gcc
+    <tschwinge>
+      COLLECT_LTO_WRAPPER=/nix/store/7awbhk5hdkd4lqj4wsj6lm6h84630jhm-gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
+    <tschwinge> Target: x86_64-unknown-linux-gnu
+    <teythoon> guix looks nice
+    <tschwinge> ph4n70m4s: Also you don't need --target with GNU Mach -- it
+      doesn'T target any architecture, that is, doesn'T create code or similar.
+    <tschwinge> Alternative to -m32, as you're specying --host=i686-gnu, you
+      could have (that is, you'd need) a i686-gnu-gcc (that internally defaults
+      to -m32 then).
+    <tschwinge> ph4n70m4s: Are you generally working on GNU Hurd support for
+      Guix, or just trying to build GNU Mach?
+    <ph4n70m4s> I am working on porting gnu guix to gnu hurd
+    <ph4n70m4s> so I need to port hurd to it
+    <ph4n70m4s> bootstrap it
+    <ph4n70m4s> and the make guix work on hurd
+    <ph4n70m4s> :-)
+    <teythoon> very cool :)
+    <tschwinge> \o/
+    <ph4n70m4s> then*
+    <ph4n70m4s> and If I manage to do all that we will be able to make a qemu
+      image 
+    <ph4n70m4s> with hurd -guix
+    <tschwinge> Yep, and then I'll be happy.  :-)
+    <ph4n70m4s> :-)
+    <tschwinge> For then we'll be easily able to change some detail in, say,
+      glibc, rebuild the whole system, and see whether it still works.
+    <ph4n70m4s> exaclty
+    <tschwinge> Of course, that doesn't strictly need Guix, but it's one way to
+      achieve this goal.
+    <tschwinge> For the initial cross compiler toolchain, I suggest you look at
+      my cross-gnu script (link provided yesterady) -- the gist of it should
+      all still be valid.
+    <ph4n70m4s> I do 
+    <tschwinge> For example, you don't actually need to build GNU Mach
+      initially, but just need to install the headers/defs files
+      (install-data).
+    <tschwinge> Perfect.
+    <ph4n70m4s> I have already done that, installing gnu mach headers was the
+      easy part
+    <ph4n70m4s> it's already on guix
+    <tschwinge> \o/
+    <tschwinge> Should really clone Git repository.  And subscribe to the
+      mailing list, and all that.
+    <ph4n70m4s> I have already done that
+    <ph4n70m4s> I am actually following hurd from last year
+    <tschwinge> Yeah, I was talking about me.  ;-)
+    <ph4n70m4s> aaaa
+    <ph4n70m4s> :P
+    <tschwinge> ph4n70m4s: Are you doing this as a Google Summer of Code
+      project?
+    <ph4n70m4s> I suggested the idea for the page
+    <ph4n70m4s> to ludovic
+    <ph4n70m4s> and he agreed
+    <tschwinge> :-)
+    <tschwinge> Good guy.
+    <tschwinge> Both of you.  ;-)
+    <ph4n70m4s> trying my best to help :-)
+    <ph4n70m4s> tschwinge: so to build glibc I only need mach and hurd headers 
+    <ph4n70m4s> right?
+    <braunr> yes
+
+
+## IRC, freenode, #hurd, 2014-02-28
+
+    <phant0mas> tschwinge: In your cross-gnu script while configuring hurd you
+      pass--disable-profile 
+    <phant0mas>  --without-parted . Why do we need to pass these flags to it?
+    <teythoon> well, --disable-profile turns off profiling afaiui
+    <teythoon> you should keep it
+    <teythoon> --without-parted is not needed if you have libparted
+    <phant0mas> ok
+
+
+## IRC, freenode, #hurd, 2014-03-01
+
+    <phant0mas> The hurd tarball has as a dependency autoconf
+    <phant0mas> normally it shouldn't, right?
+    <azeem> phant0mas: you mean there's no configure script?
+    <phant0mas> no no, for some reason the configure script states as
+      dependency autoconf which it shouldn't as it is a tarball
+    <azeem> phant0mas: how does it state that?
+    <phant0mas> you already have the configure script in it
+    <azeem> you get an error running it saying autoconf is required?
+    <phant0mas> yes
+    <azeem> hrm
+    <phant0mas> actually it gives an error for autoconf and git
+    <phant0mas> but if you have autoconf ,it forgets about git
+
+
+## IRC, freenode, #hurd, 2014-03-02
+
+    <phant0mas> youpi: civodul told me you are the one to ask about libpthread 
+    <phant0mas> how should I handle Hurd's libpthread in order to build it,with
+      the rest of the hurd system?
+    <phant0mas> anything I should be extra carefull?
+    <phant0mas> I am building it from the tarball
+    <youpi> phant0mas: nothing I can think of
+
+
+## IRC, freenode, #hurd, 2014-03-03
+
+    <phant0mas> youpi: what does libpthread do when we do "make
+      install-data-local-headers" ?
+    <phant0mas> Does it patch the mach headers in the prefix folder?
+    <phant0mas> tschwinge: why do we need this flag passed to configure at
+      libpthread "ac_cv_lib_ihash_hurd_ihash_create"?  
+    <youpi> phant0mas: I don't remember such detajils of the build system
+    <phant0mas> I am studying the cross-gnu script from tschwinge
+    <phant0mas> and if I try to call configure without that flag I am getting
+      the error  
+    <phant0mas> configure: error: need libihash
+    <tschwinge> Well, there's this comment: # `$TARGET-gcc' doesn't work yet
+      (to satisfy the Autoconf checks), but [...]
+    <tschwinge> At this point we're only intested in the header files, so that
+      was the "path of least resistance".
+    <phant0mas> so we are only interested in the headers of libpthread?
+    <phant0mas> do I need to pass as --prefix the folder which the include
+      folder with the mach headers are installed?
+    <tschwinge> I wonder whether it'd be better for you to directly include
+      libpthread in glibc, as Debian is doing -- probably yes.
+
+[[open_issues/packaging_libpthread]].
+
+    <phant0mas> maybe it would be much simpler that way
+    <phant0mas> let me check the debian package
+    <braunr> i'd consider it mandatory, since libpthread can't work correctly
+      now if it's not part of glibc
+    <tschwinge> Ack.
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+    <teythoon> braunr: did i understand it correctly that our libpthread needs
+      libihash ?
+    <teythoon> if so, won't that be a problem for phant0mas bootstrapping
+      efforts ?
+    <braunr> apparently, they're used only for thread-specific data
+    <braunr> which could now be implemented on top of TLS
+    <braunr> although i'm not sure
+    <braunr> but to answer, yes, it depends on libihash
+    <braunr> why would it be a problem ?
+    <teythoon> b/c it then forms a dependency loop
+    <braunr> which one ?
+    <teythoon> hurd->libc (which includes libpthread, thus)->hurd
+    <braunr> isn't that already the case ?
+    <teythoon> yes
+    <braunr> what's the problem then ?
+    <braunr> actually, it's not a dependency loop
+    <teythoon> y not ?
+    <braunr> hurd and libc depend on each other headers
+    <teythoon> ah, right
+    <braunr> actually, hurd-libs depend on libc headers
+    <braunr> hurd executables do depend on libc
+    <braunr> it's a bit tedious to bootstrap but not much more than the
+      three-step build required for linux already
+    <phant0mas> actually for that libihash if I pass the flag
+      "ac_cv_lib_ihash_hurd_ihash_create=yes" at configure it stops asking for
+      it
+
+    <phant0mas> when glibc's configure says "configure: running configure
+      fragment for add-on libpthread"
+    <phant0mas> does it mean it runs configure inside the folder of libpthread?
+    <youpi> I guess so
+    <phant0mas> yeh because I am getting the error configure: error: cannot
+      find sources (include/pthread/pthread.h) in .. or ..
+    <phant0mas> which I should not as I am passing
+    <phant0mas> the path to that folder
+    <phant0mas> it's an error from libpthread configure
+
+
+## IRC, freenode, #glibc, 2014-03-05
+
+    <phant0mas> when we pass to the configure script of glibc the flag
+      --enable-add-ons=something what it the process followed for that addon?
+      How does it build it?
+    <phant0mas> what is*
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+    <phant0mas> ../configure --without-cvs --build=i686-pc-gnu
+      --host=i686-pc-gnu --target=i686-pc-gnu --prefix="/home/manolis/gnu/"
+      --with-headers="/home/manolis/gnu/include/" --disable-profile
+      --disable-multi-arch --enable-add-ons=libpthread
+    <phant0mas> trying to configuring glibc with libpthreads as addon I get
+      this
+    <phant0mas> configure: running configure fragment for add-on libpthread
+    <phant0mas> configure: WARNING: you should use --build, --host, --target
+    <phant0mas> configure: WARNING: you should use --build, --host, --target
+    <phant0mas> configure: error: cannot find sources
+      (include/pthread/pthread.h) in .. or ..
+    <phant0mas> without libpthread it moves on
+    <phant0mas> in the include folder it should find al the headers it needs
+    <phant0mas> maybe it's a problem that I installed the headers from the
+      tarballs
+    <phant0mas> while glibc is from the git repo
+    <phant0mas> if I remove libpthread
+    <phant0mas> I get the error configure: error: Hurd headers not installed or
+      too old
+    <phant0mas> I really think I should reinstall the headers using the source
+      from the repo the headers 
+    <phant0mas> the headers from the tar ball are okay
+    <phant0mas> when I pass this flag to "--enable-add-ons=libpthread" to glibc
+      configure how can I pass flags for the libpthread configure that it's
+      called while configuring? 
+    <teythoon> phant0mas: you could look at what the debian package does
+    <phant0mas> ok
+    <braunr> phant0mas: check debian glibc for all the patches