On 04/13/2011 10:12 PM, Andrew O. Shadoura wrote:
> Hello,
>
> On Wed, 13 Apr 2011 22:04:54 +0200
> Luk Claes <luk@debian.org> wrote:
>
>>> I confirm the bug.
>>>
>>> # cat </dev/null >/dev/tcp/localhost/111
>>> -su: /dev/tcp/localhost/111: No such file or directory
>>
>> Unless you show that you:
>>
>> 1) have bash 4.1-3 or later installed ('apt-cache policy bash' for
>> instance) 2) are using bash as shell ('exec bash' for instance)
>> 3) sunrpc service is running ('lsof -i :111' for instance)
>> 4) still have this issue
>>
>> It's going to stay closed as only in that case it's supposed to work.
>
> If it's the only case, it should be specified explicitly. And, after
> all, why not use the utility that is supposed to be used, and not this
> hackish thing?

The only reason it was implemented this way is because bash is still
essential and so does not need a dependency.

> Also, there's no way to get a newer bash unless I install it by hand.
> This system isn't lenny any more, but nothing has upgraded it yet by
> means of dependencies.

Well, we only guarantee to support upgrades from stable to the next one.
Obviously we will try to not break things in unstable and testing.
Though it's not uncommon to make the assumption that users have at least
upgraded to stable before doing partial upgrades to unstable/testing
versions.

Anyway, using a really old packaged bash, a newly packaged bash or a
self compiled bash (even the version in lenny) should all work for this
/dev/tcp use. It can also be replaced by 'lsof -i :111' or something
netcat like, though for both these you need to make sure you have lsof
or netcat installed.

Cheers

Luk



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DA60786.1090406@debian.org">http://lists.debian.org/4DA60786.1090406@debian.org

Hello,

On Wed, 13 Apr 2011 22:28:54 +0200
Luk Claes <luk@debian.org> wrote:

> > If it's the only case, it should be specified explicitly. And, after
> > all, why not use the utility that is supposed to be used, and not
> > this hackish thing?

> The only reason it was implemented this way is because bash is still
> essential and so does not need a dependency.

So you prefer not to specify dependencies at all and break the install
than to specify the dependency explicitly? I don't grok this, sorry

> > Also, there's no way to get a newer bash unless I install it by
> > hand. This system isn't lenny any more, but nothing has upgraded it
> > yet by means of dependencies.

> Well, we only guarantee to support upgrades from stable to the next
> one. Obviously we will try to not break things in unstable and
> testing. Though it's not uncommon to make the assumption that users
> have at least upgraded to stable before doing partial upgrades to
> unstable/testing versions.

This machine is (obviously) a server. I can't 'just upgrade' it to the
stable at once, so I do partial upgrades. Dist-upgrade is no go at this
moment. So in my attempt to get NFS over IPv6 working I got broken NFS
at all

> Anyway, using a really old packaged bash, a newly packaged bash or a
> self compiled bash (even the version in lenny) should all work for
> this /dev/tcp use.

It's bash 3.2-4 from lenny, it's not so old. And it doesn't
have /dev/tcp support.

> It can also be replaced by 'lsof -i :111' or
> something netcat like, though for both these you need to make sure
> you have lsof or netcat installed.

It could be replaced by rpcinfo (as suggested before) which is provided
by libc-bin, so no extra dependencies and no breakage. Why not? Why
such a resistance?

--
WBR, Andrew

On Wed, Apr 13, 2011 at 11:39:37PM +0300, Andrew O. Shadoura wrote:
[...]
> > Well, we only guarantee to support upgrades from stable to the next
> > one. Obviously we will try to not break things in unstable and
> > testing. Though it's not uncommon to make the assumption that users
> > have at least upgraded to stable before doing partial upgrades to
> > unstable/testing versions.
>
> This machine is (obviously) a server. I can't 'just upgrade' it to the
> stable at once, so I do partial upgrades. Dist-upgrade is no go at this
> moment. So in my attempt to get NFS over IPv6 working I got broken NFS
> at all
[...]

This is extremely foolish. Partial upgrades are not nearly so well
tested. And while Debian attempts to support partial upgrades from
one stable release to the next (oldstable/stable or
stable/testing/unstable), we explicitly do not support skipping a
release, which is what you are doing by mixing oldstable and unstable.

If you still insist on mixing oldstable and unstable, use a staging
server and pay a consultant to support it.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110413204829.GN2268@decadent.org.uk">http://lists.debian.org/20110413204829.GN2268@decadent.org.uk

On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote:
> Hello,
>
> On Wed, 13 Apr 2011 22:28:54 +0200
> Luk Claes <luk@debian.org> wrote:
>
>>> If it's the only case, it should be specified explicitly. And, after
>>> all, why not use the utility that is supposed to be used, and not
>>> this hackish thing?
>
>> The only reason it was implemented this way is because bash is still
>> essential and so does not need a dependency.
>
> So you prefer not to specify dependencies at all and break the install
> than to specify the dependency explicitly? I don't grok this, sorry
>
>>> Also, there's no way to get a newer bash unless I install it by
>>> hand. This system isn't lenny any more, but nothing has upgraded it
>>> yet by means of dependencies.
>
>> Well, we only guarantee to support upgrades from stable to the next
>> one. Obviously we will try to not break things in unstable and
>> testing. Though it's not uncommon to make the assumption that users
>> have at least upgraded to stable before doing partial upgrades to
>> unstable/testing versions.
>
> This machine is (obviously) a server. I can't 'just upgrade' it to the
> stable at once, so I do partial upgrades. Dist-upgrade is no go at this
> moment. So in my attempt to get NFS over IPv6 working I got broken NFS
> at all
>
>> Anyway, using a really old packaged bash, a newly packaged bash or a
>> self compiled bash (even the version in lenny) should all work for
>> this /dev/tcp use.
>
> It's bash 3.2-4 from lenny, it's not so old. And it doesn't
> have /dev/tcp support.
>
>> It can also be replaced by 'lsof -i :111' or
>> something netcat like, though for both these you need to make sure
>> you have lsof or netcat installed.
>
> It could be replaced by rpcinfo (as suggested before) which is provided
> by libc-bin, so no extra dependencies and no breakage. Why not? Why
> such a resistance?

I didn't see the suggestion to use rpcinfo. The one of libc-bin will
probably be removed at some point, though we always will have the one of
rpcbind.

Committed, so will be in a new upload unless any objections are out.

Cheers

Luk



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DA60F26.6080401@debian.org">http://lists.debian.org/4DA60F26.6080401@debian.org

On 13-Apr-2011, Debian Bug Tracking System wrote:
> Date: Wed, 13 Apr 2011 23:12:15 +0300
> From: "Andrew O. Shadoura" <bugzilla@tut.by>
> Message-ID: <20110413231215.189a2fc2@ileemo>
>
> On Wed, 13 Apr 2011 22:04:54 +0200
> Luk Claes <luk@debian.org> wrote:
>
> > Unless you show that you:
> >
> > 1) have bash 4.1-3 or later installed ('apt-cache policy bash' for
> > instance) 2) are using bash as shell ('exec bash' for instance)
> > 3) sunrpc service is running ('lsof -i :111' for instance)
> > 4) still have this issue
> >
> > It's going to stay closed as only in that case it's supposed to
> > work.
>
> If it's the only case, it should be specified explicitly.

$ dpkg-query --showformat='Depends: ${Depends}
' --show nfs-common
Depends: libc6 (>= 2.4), libcap2 (>= 2.10), libcomerr2 (>= 1.01), libevent-1.4-2 (>= 1.4.13-stable), libgssapi-krb5-2 (>= 1.6.dfsg.2), libgssglue1, libk5crypto3 (>= 1.6.dfsg.2), libkrb5-3 (>= 1.6.dfsg.2), libnfsidmap2, libtirpc1, libwrap0 (>= 7.6-4~), rpcbind | portmap, adduser, ucf, lsb-base (>= 1.3-9ubuntu3), netbase (>= 4.24), initscripts (>= 2.86.ds1-38.1)

No mention of bash at all. If a specific version of bash is required,
that must be expressed as a dependency.

> And, after all, why not use the utility that is supposed to be used,
> and not this hackish thing?

The patch supplied with the original message on this bug report works,
AFAICT. I ask again that it be applied, to avoid needing to use
version-specific Bash features.

--
“We can't depend for the long run on distinguishing one |
` bitstream from another in order to figure out which rules |
_o__) apply.� —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney <ben@benfinney.id.au>

On Wed, Apr 13, 2011 at 11:01:26PM +0200, Luk Claes wrote:
> On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote:
[...]
> > It could be replaced by rpcinfo (as suggested before) which is provided
> > by libc-bin, so no extra dependencies and no breakage. Why not? Why
> > such a resistance?
>
> I didn't see the suggestion to use rpcinfo. The one of libc-bin will
> probably be removed at some point, though we always will have the one of
> rpcbind.
>
> Committed, so will be in a new upload unless any objections are out.

Does glibc's rpcinfo actually work with rpcbind, then? It is
documented as only speaking the portmapper protocol, and we now
know libtirpc doesn't handle that.

Also, I think either method (/dev/tcp/localhost/111 or rpcinfo)
will not work for anyone who configures rpcbind to listen on IPv6
only.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110413213224.GO2268@decadent.org.uk">http://lists.debian.org/20110413213224.GO2268@decadent.org.uk

On 04/13/2011 11:32 PM, Ben Hutchings wrote:
> On Wed, Apr 13, 2011 at 11:01:26PM +0200, Luk Claes wrote:
>> On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote:
> [...]
>>> It could be replaced by rpcinfo (as suggested before) which is provided
>>> by libc-bin, so no extra dependencies and no breakage. Why not? Why
>>> such a resistance?
>>
>> I didn't see the suggestion to use rpcinfo. The one of libc-bin will
>> probably be removed at some point, though we always will have the one of
>> rpcbind.
>>
>> Committed, so will be in a new upload unless any objections are out.
>
> Does glibc's rpcinfo actually work with rpcbind, then? It is
> documented as only speaking the portmapper protocol, and we now
> know libtirpc doesn't handle that.

Yes, it does work.

> Also, I think either method (/dev/tcp/localhost/111 or rpcinfo)
> will not work for anyone who configures rpcbind to listen on IPv6
> only.

Only rpcbind's rpcinfo would work in that case, true.

Cheers

Luk



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DA61D3F.7060705@debian.org">http://lists.debian.org/4DA61D3F.7060705@debian.org