As discussed by a number of people in bug #562757 it appears that
nfs-kernel-server has kicked off a transition to the use of rpcbind - at
least, nfs-kernel-server has switched to needing rpcbind and we can't
have two things claiming the portmap port. Since a number of packages
currently rely on portmap (list based on rdepends below) this is likely
to require a transition of some kind.

I've not seen any discussion of how this is supposed to work, or any
mention of the planned transition before it broke my systems. There's
quite a few bugs in ONCRPC related packages related to the current state
but none of them seem to have a summary of what the intention is - does
anyone have any information here?

Daniel Baumann <daniel@debian.org>
doodle (U)

Mark Brown <broonie@debian.org>
nis

Tim Cutts <timc@chiark.greenend.org.uk>
am-utils

Debian QA Group <packages@qa.debian.org>
unfs3

Alberto Gonzalez Iniesta <agi@inittab.org>
netkit-bootparamd
netkit-rusers
netkit-rwall

Noèl Köthe <noel@debian.org>
drac

Chuan-kai Lin <cklin@debian.org>
fam

Robert Luberda <robert@debian.org>
rlinetd

Ola Lundqvist <opal@debian.org>
harden

Debian GNUnet Maintainers <gnunet@lists.debian-maintainers.org>
doodle

Michael Meskes <meskes@debian.org>
quota

Anibal Monsalve Salazar <anibal@debian.org>
nfs-utils
rstatd

Miquel van Smoorenburg <miquels@cistron.nl>
nis (U)

Geert Stappers <stappers@debian.org>
p3nfs


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Jan 04, 2010 at 02:45:27PM +0000, Mark Brown wrote:

> I've not seen any discussion of how this is supposed to work, or any
> mention of the planned transition before it broke my systems. There's
> quite a few bugs in ONCRPC related packages related to the current state
> but none of them seem to have a summary of what the intention is - does
> anyone have any information here?

The rpcbind package is fixed now as far as I can see, if you install it then it
will remove portmap, and nfs-common and the kernel server seem to work on my
systems (I use NFSv4 for all shares).

I see that nfs-common depends on portmap | rpcbind. However, nis only depends
on portmap, and can therefore not be installed at the same time as rpcbind.

--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>

On Thu, Jan 07, 2010 at 01:52:43PM +0100, Guus Sliepen wrote:

> I see that nfs-common depends on portmap | rpcbind. However, nis only depends
> on portmap, and can therefore not be installed at the same time as rpcbind.

Yes, this is the root of the issue - if we're changing what we're doing
with portmappers what's the plan for managing this. What should be the
default, is the old portmap going away and so on. At the minute there's
been no coordination at all, the first time I heard of rpcbind was when
I was resolving the NFS breakage.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Mark Brown schrieb am Donnerstag, den 07. Januar 2010:

Hi,

> > I see that nfs-common depends on portmap | rpcbind. However, nis only depends
> > on portmap, and can therefore not be installed at the same time as rpcbind.
>
> Yes, this is the root of the issue - if we're changing what we're doing
> with portmappers what's the plan for managing this. What should be the
> default, is the old portmap going away and so on. At the minute there's
> been no coordination at all, the first time I heard of rpcbind was when
> I was resolving the NFS breakage.
Ehm, the reason was a bug. nfs-common was broken, if connecting to localhost
it was only trying ::1, but without a fallback on 127.0.0.1.

There wasn't any indication in the package that this breakage was on purpose.
I guess it was just bad testing.

The NMU is in delayed/1 and should hit unstable in a few hours.

Alex


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Jan 07, 2010 at 07:17:16PM +0100, Alexander Wirt wrote:
> Ehm, the reason was a bug. nfs-common was broken, if connecting to localhost
> it was only trying ::1, but without a fallback on 127.0.0.1.

> There wasn't any indication in the package that this breakage was on purpose.
> I guess it was just bad testing.

> The NMU is in delayed/1 and should hit unstable in a few hours.

Sure, but my main point is that looking at the package meant I noticed
that it's now added rpcbind as an alternative portmapper. That's
something which we should be doing over the entire distribution rather
than in a few packages.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Jan 04, 2010 at 02:45:27PM +0000, Mark Brown wrote:
> As discussed by a number of people in bug #562757 it appears that
> nfs-kernel-server has kicked off a transition to the use of rpcbind - at
> least, nfs-kernel-server has switched to needing rpcbind and we can't
> have two things claiming the portmap port. Since a number of packages
> currently rely on portmap (list based on rdepends below) this is likely
> to require a transition of some kind.

> I've not seen any discussion of how this is supposed to work, or any
> mention of the planned transition before it broke my systems. There's
> quite a few bugs in ONCRPC related packages related to the current state
> but none of them seem to have a summary of what the intention is - does
> anyone have any information here?

Any updates on this? Are we switching portmappers, and if we are how
are we doing so?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Jan 20, 2010 at 06:49:07PM +0000, Mark Brown wrote:
>On Mon, Jan 04, 2010 at 02:45:27PM +0000, Mark Brown wrote:
>>As discussed by a number of people in bug #562757 it appears that
>>nfs-kernel-server has kicked off a transition to the use of rpcbind -
>>at least, nfs-kernel-server has switched to needing rpcbind and we
>>can't have two things claiming the portmap port. Since a number of
>>packages currently rely on portmap (list based on rdepends below) this
>>is likely to require a transition of some kind.
>>
>>I've not seen any discussion of how this is supposed to work, or any
>>mention of the planned transition before it broke my systems. There's
>>quite a few bugs in ONCRPC related packages related to the current
>>state but none of them seem to have a summary of what the intention is
>>- does anyone have any information here?
>
>Any updates on this? Are we switching portmappers, and if we are how
>are we doing so?

Not yet, as I'm busy at LCA2010 in Wellington, New Zealand. I would like
to replace portmap with rpcbind. Uploadind rpcbind was a first step.
I'll be working on the plan after LCA2010.