rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 132 deletions

diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn
deleted file mode 100644
index 46cc1c1c..00000000
--- a/open_issues/ti-rpc_then_nfs.mdwn
+++ /dev/null
@@ -1,132 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-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]]."]]"""]]
-
-[[!tag open_issue_hurd open_issue_porting]]
-
-TI-RPC replaces glibc's Sun RPC implementation, [[!message-id
-"4D0632C5.1040107@RedHat.com"]].
-
-It needs some work on our side, [[!message-id
-"20101214213212.GU1095@kepler.schwinge.homeip.net"]].
-
-Then, the Hurd's [[hurd/translator/nfs]] translator and [[hurd/nfsd]] can be
-re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]].
-
-
-## IRC, freenode, #hurd, 2014-02-19
-
-    <pere> hi.  I'm trying to port libtirpc to get rcpbind on hurd, and am
-      unable to find IPV6_PORTRANGE and IPV6_PORTRANGE_LOW.  is this a known
-      problem with a known fix?
-    <braunr> what are they supposed to be ?
-    <pere> braunr: found them described in <URL:
-      http://www.daemon-systems.org/man/ip6.4.html >.
-    <braunr> "The IPV6_PORTRANGE socket option and the conflict resolution rule
-      are not defined in the RFCs and should be considered implementation
-      dependent
-    <braunr> "
-    <braunr> hm
-    <braunr> if we have that, they're very probably not accessible from outside
-      our network stack
-    <pere> needed feature on hurd, in other words...
-    <braunr> why ?
-    <pere> If I remember correctly, SO_PEERCRED is also missing?
-    <braunr> yes ..
-    <braunr> that one is important
-    <pere> braunr: you wonder why the IPV6_PORTRANGE socket option was created?
-    <braunr> i wonder why it's needed
-    <braunr> does linux have it ?
-    <pere> yes, linux got it.
-    <braunr> same name ?
-    <pere> it make it possible for some services to work with some
-      firewalls. :)
-    <pere> yes, same name, as far I can tell.
-    <braunr> they could merely bind ports explicitely, couldn't they ?
-    <pere> not always.
-    <braunr> or is it for servers on creation of a client socket ?
-    <pere> see <URL:
-      http://www.stacken.kth.se/lists/heimdal-discuss/2000-11/msg00002.html >
-      for an example I came across.
-    <braunr> i don't find these macros on linux :/
-    <pere> how strange.  libtirpc build on linux.
-    <braunr> is there a gitweb or so somewhere ?
-    <braunr> i can't find it on sf :/
-    <pere> for <URL: http://sourceforge.net/projects/libtirpc >, you mean?
-    <braunr> yes
-    <pere> no idea.
-    <braunr> are you looking at upstream 0.2.4 or a particular debian package ?
-    <pere> I'm looking at the debian package.
-    <braunr> let me take a look
-    <pere> http://paste.debian.net/82971/ is my first draft patch to get the
-      source building.
-    <braunr> ok so
-    <braunr> in src/bindresvport.c
-    <braunr> if you look carefully, you'll see that these _PORTRANGE macros are
-      used in non linux code
-    <braunr> not very portable but it explains why you hit the problem
-    <braunr> try using #if defined (__linux__) || defined(__GNU__)
-    <braunr> also, i think we intend to implement SCM_CREDS, not SO_PEERCRED
-    <braunr> but consider we have neither for now
-    <pere> ah, definitely a simpler fix.
-    <braunr> pere: btw, see
-      https://lists.debian.org/debian-hurd/2010/12/msg00014.html
-
-    <pere> <URL: https://bugs.debian.org/739557 > with patch reporte.d
-
-
-## IRC, freenode, #hurd, 2014-02-20
-
-    <pere> new libtirpc with hurd fixes just uploaded to debian.  should fix
-      the rpcbind build too.
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-20
-
-    <pere> hm, rpcbind built with freshly patched libtirpc fail to work on
-      hurd.  no idea why.
-    <pere> running 'rpcinfo -p' show 'rpcinfo: can't contact portmapper: RPC:
-      Success'
-    <teythoon> o_O
-    <pere> I have no idea how to debug it. :(
-    <pere> anyway, I've found that rpcinfo is the broken part.  rpcbind work,
-      when I test it from a remote machine.
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-21
-
-    <pere> failing rpcinfo -p on hurd reported as <URL:
-      http://bugs.debian.org/739674 >.  Anyone got a clue how to debug it?
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-03
-
-    <pere> I was just tipped by sesse that the hurd fix for libtirpc probably
-      caused RC bug in nfs-common, <URL: https://bugs.debian.org/740491 >.
-      Have not had time to check it out more closely.
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-04
-
-    <youpi> pere: I don't really see how debian/patches/05-hurd-port.diff could
-      break Linux' libtirpc
-    <youpi> AIUI, the patch has zero effect on non-hurd builds
-    <youpi> oh wait
-    <youpi> it's simply missing a reautoconf to get HAVE_SYS_USER_H undefined
-      in config.h.in
-    <pere> youpi: I am quite sure I did add the required dh_autoreconf call.
-      did you see a build log where it was missing?
-    <youpi> pere: ah, ok. Then 02-rerun-bootstrap.diff can be dropped
-    <youpi> and I don't have any further idea
-    <youpi> pere: maybe it's the autoreconf itself which broke something?
-    <pere> could be.  not quite sure how to find out.
-    <gnu_srs> pere: what about running autoreconf on the previous (working
-      version)?
-    <pere> gnu_srs: sound like a good idea.  perhaps a good idea to just
-      disable the two patches as a start.