1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
[[!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.
|
