IRC.

1 files changed, 31 insertions, 0 deletions

diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
index 8901e1c3..88a18a93 100644
--- a/open_issues/virtualization/fakeroot.mdwn
+++ b/open_issues/virtualization/fakeroot.mdwn
@@ -24,6 +24,8 @@ License|/fdl]]."]]"""]]
     <youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name
       but apparently not fixed in that case, for some reason
 
+[[glibc#execve_relative_paths]].
+
 
 ## IRC, freenode, #hurd, 2013-08-26
 
@@ -36,6 +38,9 @@ License|/fdl]]."]]"""]]
     < youpi> yes
     < youpi> pinotree's exec_file_name is supposed to fix that, but for some
       reason it doesn't work here
+
+[[glibc#execve_relative_paths]].
+
     < pinotree> it was pochu's, not mine
     < youpi> ah, right
     < teythoon> ah I see, I was wondering about that
@@ -73,6 +78,9 @@ License|/fdl]]."]]"""]]
     <teythoon> I believe I figured out the argv[0] issue with fakeroot-hurd
     <teythoon> but I'm not sure how to fix this
     <teythoon> first of all, Emilios file_exec_file_name patch set works fine
+
+[[glibc#execve_relative_paths]].
+
     <teythoon> but not with fakeroot
     <teythoon>
       http://git.sceen.net/hurd/hurd.git/blob/HEAD:/exec/hashexec.c#l300
@@ -1293,3 +1301,26 @@ License|/fdl]]."]]"""]]
     <braunr> teythoon: was it a big package ?
     <teythoon> half of the hurd package
     <braunr> that's not a port right overflow then
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+    <teythoon> youpi: what about the exec_filename patch series? even though
+      fakeroot still has some issues (has it?), i consider it worthy for
+      inclusion
+
+[[glibc#execve_relative_paths]].
+
+    <youpi> Roland was disagreeing with it
+    <youpi> iirc the fakeroot issue was solved
+    <teythoon> braunr: ^
+    <braunr> fakeroot goot a lot more robust than it used to be
+    <braunr> but i haven't checked that it actually behaves exactly like the
+      library for corner cases
+    <braunr> there are minor differences
+    <braunr> also, it seems to trigger concurrency bugs in ext2fs
+    <braunr> e.g. git reporting that files either "already exist" or "can't be
+      found"
+    <braunr> it happens (rarely) when directly using ext2
+    <braunr> and more often through fakeroot
+    <braunr> i didn't take the time to investigate