coreutils 5.97-5.2

[Manoj Srivastava]

Hi,

coreutils was NMU'd with permission to fix SELinux issues
(changelogs below). Unfortunately, it seems that the versions in
unstable are not in sync;
,----
| __> rmadison coreutils
| coreutils | 5.2.1-2 | stable | source, alpha, arm, hppa,
| i386, ia64, m68k, mips,
| mipsel, powerpc, s390, sparc
| coreutils | 5.96-5 | unstable | hurd-i386
| coreutils | 5.97-5 | testing | source, alpha, amd64, arm,
| hppa, i386, ia64, m68k,
| mips, mipsel, powerpc, s390,
| sparc
| coreutils | 5.97-5 | unstable | s390
| coreutils | 5.97-5.2 | unstable | source, alpha, amd64, arm,
| hppa, i386, ia64, m68k,
| mips, mipsel, powerpc, sparc
| coreutils | 6.0-1 | experimental | source, alpha, amd64, hppa,
| i386, powerpc, sparc
`----


Looking at the build logs, I see the test pwd-long failed on
s-390. I need help diagnosing the problem, and was wondering if
someone could help getting this resolved.

It would be nice if we managed to get the SELinux fixes into
etch.

manoj


coreutils (5.97-5.2) unstable; urgency=low

* This is an follow up non-maintainer upload to fix an issue introduced
in my last NMU. This fixes an FTBS bugs when building for non-SELinux
environments, for example, for non Linux architectures.
* Bug fix: "coreutils: FTBFS on hurd and kfreebsd: Unguarded usage of
SELinux code", thanks to Michael Banck. I missed out on guarding
assignments one. Rather than use the suggested patch (which adds two
members to a struct on non-selinux machines that would never get used,
I went back and corrected the non-selinux patch, since that is the
correct location to add this fix. The version of the patch included
in this version should do the right thing. (Closes: #396655).

-- Manoj Srivastava <***@debian.org> Sun, 5 Nov 2006 16:04:08 -0600

coreutils (5.97-5.1) unstable; urgency=low

* With permission from the maintainer, this upload (from a non-maintainer)
updates the SELinux patch, synchronizing with the latest patches from
fedora core (:pserver:***@cvs.fedora.redhat.com:/cvs/dist,
repository rpms/coreutils/devel). The patches had to be tweaked for
Debian. This bring coreutils into compatibility with the latest
version of SELinux now in Debian.
* Bug fix: "coreutils: Updated SELinux patch", thanks to Manoj
Srivastava. The NMU patch is available in that bug report,
essentially, this is a minimal change upload. (Closes: #394287).

-- Manoj Srivastava <***@debian.org> Fri, 20 Oct 2006 15:11:27 -0500
--
"MTV. An obedient tongue licking the shiny leather boot of rock and
roll." MTV commercial
Manoj Srivastava <***@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

[Bastian Blank]

Post by Manoj Srivastava
Looking at the build logs, I see the test pwd-long failed on
s-390. I need help diagnosing the problem, and was wondering if
someone could help getting this resolved.

The relevant bug report is #380552, which was closed without fix.

The following informations are from memory. The test fails if it reaches
a bind mount on the same device. I reproduced it somehow with
| mkdir test1 test2
| mount --bind test1 test2
| cd test2
| call testsuite

Bastian

[Manoj Srivastava]

Hi,

Post by Bastian Blank

Looking at the build logs, I see the test pwd-long failed on s-390.
I need help diagnosing the problem, and was wondering if someone
could help getting this resolved.

The relevant bug report is #380552, which was closed without fix.
The following informations are from memory. The test fails if it
reaches a bind mount on the same device. I reproduced it somehow
with

mkdir test1 test2
mount --bind test1 test2
cd test2
call testsuite

OK. So where does that leave us at the moment? The first bug
closing message said:
] This wasn't duplicated for any other arch, and this plaform
] apparantly hasn't even tried building the last two uploads. I'm going
] to assume it was a platform-specific build environment bug unless
] there's further information provided.

which implies that the maintainer does not seem to support the
s390 architecture (well, my read of that mail). It seems a pity that
after all the effort, SELinux support would not reach the _other_
arches for etch.

Where do we go from here?

manoj
ps: my sig generator must be sentient