Merge remote-tracking branch 'fp/master'

5 files changed, 182 insertions, 0 deletions

diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn
index 95c23920..168823bf 100644
--- a/hurd/running/debian/qemu_image.mdwn
+++ b/hurd/running/debian/qemu_image.mdwn
@@ -29,3 +29,35 @@ Just in case you were wondering: the *root* password is empty.
 
 [[!if test="destpage(hurd/running/qemu)" then="" else="For more detailed
 instructions, please see the [[hurd/running/QEMU]] page."]]
+
+
+# IRC, freenode, #hurd, 2014-03-10
+
+    <mcsim> scp doesn't work either
+    <braunr> what ?
+    <braunr> why wouldn't it ?
+    <mcsim> scp -P5555 -r ./hurd/ root@localhost:/root/src/
+    <mcsim> root@localhost's password: 
+    <mcsim> The Hurd is not Linux. Make sure to read
+    <braunr> that shouldn't happen ...
+    <braunr> use tar maybe ?
+    <mcsim> the same with tar archive
+    <braunr> :/
+    <braunr> i don't know what to tell you
+    <braunr> i don't have that problem
+
+
+## IRC, freenode, #hurd, 2014-03-11
+
+    <teythoon> braunr: mcsims scp problem is b/c youpis images echo stuff from
+      the .bashrc or something
+    <teythoon> i wish he'd change that, as it is a reoccuring problem
+    <teythoon> youpi: ^
+    <teythoon> (didn't realize you are around >,<)
+    <teythoon> now that /etc/issue is displayed, you can put the welcome text
+      there
+    <braunr> teythoon: i see
+    <teythoon> mcsim: your ssh trouble are rooted in the .bashrc printing some
+      stuff to stdout
+    <mcsim> teythoon: thank you. It works now
+    <teythoon> :)
diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn
index c6212da8..68052948 100644
--- a/hurd/running/nix.mdwn
+++ b/hurd/running/nix.mdwn
@@ -500,3 +500,13 @@ Nix, and because of that, it uses per-package installation directories under
     <teythoon> phant0mas: you could look at what the debian package does
     <phant0mas> ok
     <braunr> phant0mas: check debian glibc for all the patches
+
+
+## IRC, freenode, #hurd, 2014-03-10
+
+    <ph4n70m4s> tschwinge: While crosscompiling glibc I get the error "Error:
+      incorrect register `%rax' used with `l' suffix"
+    <ph4n70m4s> http://pastebin.com/raw.php?i=ZJKHrm4s
+    <ph4n70m4s> Any idea why is this happening?
+    <braunr> ph4n70m4s: something is trying to compile as an x86-64 object,
+      while the hurd is i386 only
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index ba849cca..81e54dff 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -431,6 +431,41 @@ That would be a nice improvement, but only after writeback throttling is impleme
     <gnu_srs1> k, the file created with mke2fs has 128
 
 
+### IRC, freenode, #hurd, 2014-03-10
+
+    <mcsim> hi. I'm having problems with copying directory from host machine to
+      hurd image. I mount hurd image at host and than use "cp -r" to copy
+      directory. Then I unmount image and start qemu. When I try to see
+      contents of the directory I get error "Computer bought the farm".
+    <braunr> mcsim: are you using the ext4 driver from linux ?
+    <mcsim> I use image debian-hurd-20140211.img from 
+    <braunr> if so, avoid it
+    <mcsim> ok
+    <mcsim> i'll try
+    <mcsim> braunr: do I have to compile module on my own? because modprobe
+      ext2 && lsmod | grep ext2 give no output?
+    <braunr> maybe
+    <braunr> mcsim: what kernel are you using ?
+    <mcsim> 3.12
+    <braunr> oh
+    <mcsim> braunr: what is wrong with it?
+    <braunr> grep 'EXT[234]' /boot/config*
+    <braunr> it probably uses ext4 for ext2 and ext3
+    <braunr> and i don't think it's possible to simply load the ext2fs module
+    <braunr> because the options are mutually exclusive iirc
+    <mcsim> # CONFIG_EXT2_FS is not set
+    <mcsim> is there another way to copy data?
+    <braunr> probably not
+    <braunr> (check for CONFIG_EXT4_USE_FOR_EXT23)
+    <gg0> mcsim: install 3.10
+      http://snapshot.debian.org/package/linux/3.10.11-1/#linux-image-3.10-3-686-pae_3.10.11-1
+    <gg0> https://bugs.debian.org/738758
+    <gg0> assuming host is debian
+    <mcsim> gg0: thank you
+    * gg0 redirects thanks to AliciaC who caught it
+    <AliciaC> gg0: thanks :)
+
+
 ## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.`
 
 ### IRC, freenode, #hurd, 2014-02-19
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 932e11a6..496d2a06 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -1346,3 +1346,85 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
     <bwright> irAwesome.
     <bwright> Plan9 is exactly it.
     <braunr> enjoy
+
+
+# IRC, freenode, #hurd, 2014-03-11
+
+    <ltx> Does anyone have a distributed OS over GNU/hurd project running?
+    <ltx> (GNU/hurd has many of the utilities to make this easy, but it still
+      requires some more utilities for transparent computation)
+    <braunr> not at the moment, no
+    <braunr> and i consider our ipc inappropriate if you want system able to
+      run over heterogeneous hardware
+    <braunr> or rather, our RPCs
+    <ltx> I haven't spent the time, this is speculative (in the worse "let's do
+      everything magically!" way.)
+    <ltx> Just wondering if this exists outside of plan9 (which is limited in
+      some ways.)
+    <braunr> dragonflybsd had plans for a SSI
+    <braunr> there are ancient research systems that actually did the job
+    <braunr> such as amoeba
+    <braunr> here at the hurd, we just don't have the manpower, and the people
+      spending time on the project have other interests
+    <ltx> Yeah, that seems like a large problem.
+    <ltx> GNU/hurd is self hosting (in the "I like working on it" way), yes?
+    <ltx> I've done some work on it, but don't really know how nice it is.
+    <braunr> yes it is
+    <ltx> Working from a microkernel to add pseudo-SSI features to a bunch of
+      servers seems like a much more trivial task than, say, modifying TLK.
+    <braunr> posix conformance and stability are good enough that more than 70%
+      of debian packages build and most of them work fine
+    <braunr> tlk the linux kernel ?
+    <ltx> Yes.
+    <braunr> first time i see this acronym :)
+    <braunr> and yes i agree, a microkernel is much much more suited for that
+    <braunr> but then, i consider a microkernel better suited for practically
+      everything ... :)
+    <ltx> :)
+    <ltx> I'm wondering how to mix SSI with network-awareness.
+    <braunr> mach used to have a network server
+    <braunr> which would merely act as a proxy for capabilities
+    <braunr> network drivers were in kernel though
+    <ltx> That's the simple way of sharing the sources.
+    <ltx> I'm wondering how we can make a software stack that's network aware;
+      completely transparent SSI can lead to inefficiencies in userspace, as it
+      may do things the kernels won't expect. Having to deal with the network
+      through a network server is a headache.
+    <braunr> what kind of problems do you have in mind ?
+    <ltx> Still working on defining the problem. I think that's half the
+      problem.
+    <ltx> (For any problem.)
+    <ltx> Beyond that, it's just some coding ;)
+    <braunr> ok
+    <braunr> sounds interesting :)
+    <braunr> i'd love to see a modern SSI in action
+    <braunr> but that's really a secondary goal for me so glad to see someone
+      making this his primary goal
+    <braunr> doctoral thesis ?
+    <ltx> ... Undergrad who's been hacking away since grade school.
+    <braunr> heh :)
+    <ltx> 18 y/o sophomore at a respected technical college, dealing with
+      boredom :)
+    <braunr> well throroughly thinking about "defining the problem" is an
+      excellent reflex
+    <teythoon> :) stick around, the hurd is fun
+    <braunr> it does help fight boredom a lot indeed ...... )
+    <braunr> :)
+    <cluck> maybe it'd be possible to port the relevant features from plan9 now
+      that there is a gpl'ed version
+    <teythoon> either way, we'd need network-transparent mach messaging
+    <teythoon> which mach messaging could do, but gnumach does not implement
+      this currently
+    <cluck> teythoon: afaiui if there was a proper 9fs2000 hurd server the rest
+      could be hidden behind the curtains 
+    <teythoon> ah, well, that sounds like a 9p network filesystem translator
+    <cluck> teythoon: also iirc plan9 uses libmach for some things so i suppose
+      a port wouldn't be completely impossible
+    <teythoon> given that in plan9 everything is a file, that might be enough
+      to use plan9 services
+    <cluck> teythoon: yes, it'd be the easiest route (at least initially) i
+      believe
+    <teythoon> careful, lots of stuff is named mach-something
+    <cluck> bloody ernest mach and his damned famous-ness-ish
+    <cluck> =)
+    <teythoon> :D
diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn
index fc9c2f18..1cf33091 100644
--- a/open_issues/nightly_builds_deb_packages.mdwn
+++ b/open_issues/nightly_builds_deb_packages.mdwn
@@ -958,3 +958,26 @@ See also [[nightly_builds]].
       version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04)
     <gg0> user01@jessie01 ~$ uname -v
     <gg0> #1 SMP Debian 3.11.10-1 (2013-12-04)
+
+
+## IRC, freenode, #hurd, 2014-03-10
+
+    <gg0> teythoon: err, i had unpacked your packages to initrd but
+      gnumach/ext2fs.static i was using for multiboot were debian ones
+    <gg0> now with yours by reading system /proc/mounts (not chroot one) i get
+      read error: (ipc/mig) bad request message ID
+    <gg0> mixing up things
+    <teythoon> gg0: yes, that is to be expected. the message ids for the
+      relevant rpcs changed "recently". i'm really sorry about that.
+    <teythoon> but in general, you should use the hurd components from one
+      source together
+    <teythoon> gg0: yes, that is to be expected. the message ids for the
+      relevant rpcs changed "recently". i'm really sorry about that.
+    <teythoon> but in general, you should use the hurd components from one
+      source together
+
+
+## IRC, OFTC, #debian-hurd, 2014-03-10
+
+    <gg0> tschwinge: i just meant Debian Jenkins provides (hopefully for hurd
+      too) continuos testing of debian installer, it doesn't produce .debs