reassign 480295 libc6.1-dev
thanks

On Fri, May 09, 2008 at 05:33:40PM +0200, Aurelien Jarno wrote:
> Matthias Klose a écrit :
> > In file included from ../../bfd/trad-core.c:45:
> > /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory
> > make[5]: *** [trad-core.lo] Error 1
> /usr/include/asm is provided by linux-libc-dev, not by libc6.1-dev.

/usr/include/asm/page.h is _not_ provided by linux-libc-dev, but
exclusivly used by /usr/include/sys/user.h which is included in
libc6.1-dev.

Bastian

--
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5



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

On Fri, May 09, 2008 at 05:51:26PM +0200, Bastian Blank wrote:
> reassign 480295 libc6.1-dev
> thanks

> On Fri, May 09, 2008 at 05:33:40PM +0200, Aurelien Jarno wrote:
> > Matthias Klose a écrit :
> > > In file included from ../../bfd/trad-core.c:45:
> > > /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory
> > > make[5]: *** [trad-core.lo] Error 1
> > /usr/include/asm is provided by linux-libc-dev, not by libc6.1-dev.

> /usr/include/asm/page.h is _not_ provided by linux-libc-dev, but
> exclusivly used by /usr/include/sys/user.h which is included in
> libc6.1-dev.

/usr/include/asm/page.h *was* provided by linux-libc-dev in 2.6.24 and
earlier.

Time and again I see this position taken by members of the kernel team that
any changes that are made to the API of linux-libc-dev are correct, and
anything that relies on the previous behavior of linux-libc-dev is buggy.

While many times (such as in this case) it is technically correct that these
packages are depending on features that they shouldn't, linux-libc-dev is
still transitively build-essential, and this is an irresponsible way to
maintain a build-essential package. We can't have assumptions about
build-essential APIs holding true for three quarters of a release cycle,
only to be broken right as the freeze is starting merely because the
upstream kernel has made changes.

This particular API change is now water under the bridge - all the packages
I know of that were affected by it have been fixed to build again - but
that's no guarantee that other packages won't be broken in another future
kernel upload.

I see only a few options here to keep kernel API changes from derailing the
release process:

- the kernel team should commit to maintaining the APIs of the current
linux-libc-dev throughout the freeze, in spite of any upstream changes
- the kernel should be frozen for lenny at this point to avoid any further
changes to the set of exported kernel headers
- linux-libc-dev needs to be broken back out of the kernel again and
maintained separately if it can't comply with the freeze requirements when
maintained in-tree.

What's the best way forward here?

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


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

On Sat, Jun 07, 2008 at 12:06:07PM -0700, Steve Langasek wrote:
> On Fri, May 09, 2008 at 05:51:26PM +0200, Bastian Blank wrote:
> > /usr/include/asm/page.h is _not_ provided by linux-libc-dev, but
> > exclusivly used by /usr/include/sys/user.h which is included in
> > libc6.1-dev.
>
> /usr/include/asm/page.h *was* provided by linux-libc-dev in 2.6.24 and
> earlier.

Yes and it was scheduled for removal since some time. Most architectures
in the glibc already stopped using them.

> Time and again I see this position taken by members of the kernel team that
> any changes that are made to the API of linux-libc-dev are correct, and
> anything that relies on the previous behavior of linux-libc-dev is buggy.

Incorrect. There is another "problem" in linux/capability.h which I
consider problematic. It affects some packages and is fixed in 2.6.26.

> While many times (such as in this case) it is technically correct that these
> packages are depending on features that they shouldn't, linux-libc-dev is
> still transitively build-essential, and this is an irresponsible way to
> maintain a build-essential package. We can't have assumptions about
> build-essential APIs holding true for three quarters of a release cycle,
> only to be broken right as the freeze is starting merely because the
> upstream kernel has made changes.

gcc 4.3 also removed (long deprecated) support for some things.

> I see only a few options here to keep kernel API changes from derailing the
> release process:
> - the kernel team should commit to maintaining the APIs of the current
> linux-libc-dev throughout the freeze, in spite of any upstream changes

You are member of the kernel team. Feel free.

Bastian

--
Too much of anything, even love, isn't necessarily a good thing.
-- Kirk, "The Trouble with Tribbles", stardate 4525.6


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

On Sat, Jun 07, 2008 at 09:50:38PM +0200, Bastian Blank wrote:
> On Sat, Jun 07, 2008 at 12:06:07PM -0700, Steve Langasek wrote:
> > On Fri, May 09, 2008 at 05:51:26PM +0200, Bastian Blank wrote:
> > > /usr/include/asm/page.h is _not_ provided by linux-libc-dev, but
> > > exclusivly used by /usr/include/sys/user.h which is included in
> > > libc6.1-dev.
> >
> > /usr/include/asm/page.h *was* provided by linux-libc-dev in 2.6.24 and
> > earlier.

> Yes and it was scheduled for removal since some time. Most architectures
> in the glibc already stopped using them.

I am not arguing that software expecting asm/page.h should not be fixed. I
am asserting that such changes should not be made to linux-libc-dev during a
freeze.

> > Time and again I see this position taken by members of the kernel team that
> > any changes that are made to the API of linux-libc-dev are correct, and
> > anything that relies on the previous behavior of linux-libc-dev is buggy.

> Incorrect. There is another "problem" in linux/capability.h which I
> consider problematic. It affects some packages and is fixed in 2.6.26.

No, not incorrect. I have seen claims - not by you, but by maks - that the
linux-libc-dev headers are correct *because* they're what upstream ships.

> > While many times (such as in this case) it is technically correct that these
> > packages are depending on features that they shouldn't, linux-libc-dev is
> > still transitively build-essential, and this is an irresponsible way to
> > maintain a build-essential package. We can't have assumptions about
> > build-essential APIs holding true for three quarters of a release cycle,
> > only to be broken right as the freeze is starting merely because the
> > upstream kernel has made changes.

> gcc 4.3 also removed (long deprecated) support for some things.

There is a very significant difference between gcc dropping support, and
linux-libc-dev dropping support. Long before gcc was switched, it was
discussed with the release team, and full-archive rebuild testing was done
to identify the regressions that the change would introduce, and these were
systematically fixed, and *then* gcc 4.3 was accepted as the default
compiler for lenny.

linux-libc-dev just one day dropped a header that libc6.1-dev was looking
for, and then the kernel and glibc maintainers played bug ping-pong about
it.

That's why I'm concerned about possible freeze impacts.

> > I see only a few options here to keep kernel API changes from derailing the
> > release process:
> > - the kernel team should commit to maintaining the APIs of the current
> > linux-libc-dev throughout the freeze, in spite of any upstream changes

> You are member of the kernel team. Feel free.

I'm happy to assume responsibility for this within the kernel team, *IFF*
I'm not going to have to contend with fellow team members assigning API
compatibility bugs away from the kernel package. Do I have any assurance of
that?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


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