Bug#1065416: Bastian's offer in #1065416

[Stefano Rivera]

Hi 1065416 (2024.11.28_17:03:25_-0400)

Two months later:
> #1081826:  linux-libc-dev ships header files not needed for 99% of it's users

That bug is now closed and archived.

> #1084908:  arch:all linux-libc-dev causes problems to architecture bootstrap

This feels close. There are a couple of proposals for provides schemes.
Or reverting back to arch-any. I've pinged the bug.

My hope is that Bastian or the kernel team can just make a decision here
and implement it.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

On Thu, 2024-11-28 at 17:03 -0400, Stefano Rivera wrote:
[...]
> Helmut: it looks like #1081826 is waiting on you for some replies.
> 
> Ben, Bastian: #1081826 could benefit with a reply from the kernel team.

We already considered this in a team meeting and downgraded it to
"minor".  With our large bug list and limited resources, we don't give
a personal response to every low severity bug.

The other bug, #1084908, is likely to be discussed at next week's
meeting.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


signature.asc
Description: This is a digitally signed message part

Bug#1065416: Bastian's offer in #1065416

[Stefano Rivera]

Hi Ben (2024.09.19_16:08:07_-0400)
> This change is included in version 6.11-1~exp1 which I am uploading to
> experimental.

Thanks for defusing the archive breakage with that upload.

I've taken on the role of moderating this bug for the tech-ctte. So,
I'll be reporting on it in the monthly tech-ctte meetings, and pinging
people, when I see conversation stalling. I took this on 2 months ago,
and then ignored the bug since then, sorry about that. :/

Now the next questions are where we want to go next. For those following
this bug, I see a few concerns being raised:

#1081826:  linux-libc-dev ships header files not needed for 99% of it's users

#1084908:  arch:all linux-libc-dev causes problems to architecture bootstrap

I think the main discussion of how to structure this package is now
continuing in #1084908. We seem to be making some progress in
understanding each others needs in there, although it has now stalled a
month ago.

Helmut: it looks like #1081826 is waiting on you for some replies.

Ben, Bastian: #1081826 could benefit with a reply from the kernel team.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

[Dropped leader@ and community@]

On Thu, 2024-09-12 at 00:38 +0200, Ben Hutchings wrote:
> On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
> [...]
> > My answers below are mine alone.  I have not discussed this with other
> > team members and do not speak for them.
> > 
> > On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> > > Hello kernel maintainers,
> > > 
> > > While potential solutions to this bug are being discussed, would you
> > > please consider removing the Provides from linux-libc-dev?
> > 
> > I am open to doing so.
> [...]
> 
> I raised this at today's team meeting and it was agreed to do this; see
> .

This change is included in version 6.11-1~exp1 which I am uploading to
experimental.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


signature.asc
Description: This is a digitally signed message part

Bug#1065416: Bastian's offer in #1065416

[John Paul Adrian Glaubitz]

Hi Matthias,

On Sun, 2024-09-15 at 13:50 +0200, Matthias Klose wrote:
> > It is trivial for us to add support for additional architectures once
> > they are minimally supported in upstream Linux (we may also require
> > that dpkg recognises their triplet; I'm not sure).  There is no
> > requirement that we define a kernel configuration for the architecture
> > at the same time, or ever (see x32).
> > 
> > Can we assume that new Debian Linux ports will be able to satisfy that
> > or would that be a problem sometimes?
> 
> CCing Adrian, he recently wanted to provide cross toolchains for 
> sparc-linux-gnu and ia64-linux-gnu, which the kernel doesn't provide 
> anymore. So a design which allows these toolchains would be helpful.

I actually don't care about ia64 anymore as the architecture was beyond
repair and upstream really wanted to get rid of it.

Having said that, a cross-toolchain for 32-bit SPARC would be nice to have
(binutils, glibc, gcc and linux-libc-dev) to perform regular integration
tests for the sparc-unknown-linux-gnu target as well as the 32-bit SPARC
kernel.

32-bit SPARC has been adapted as the Leon CPU for space applications such
as satellites and space craft. Thanks to this, SPARC is also being actively
maintained in the Linux kernel again and there is solid funding behind the
port.

Oracle also has some people actively maintaining the software stack for SPARC,
allegedly even on Linux although the latter doesn't have high priority at the
moment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1065416: Bastian's offer in #1065416

[Matthias Klose]

On 12.09.24 19:56, Ben Hutchings wrote:

On Thu, 2024-09-12 at 12:19 +0200, Helmut Grohne wrote:

Hi Ben,

Dropping leader@ and community@ from Cc as this is a technical
side-track.

On Thu, Sep 12, 2024 at 12:38:24AM +0200, Ben Hutchings wrote:

On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
[...]

My answers below are mine alone.  I have not discussed this with other
team members and do not speak for them.

On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:

Hello kernel maintainers,

While potential solutions to this bug are being discussed, would you
please consider removing the Provides from linux-libc-dev?


I am open to doing so.

[...]

I raised this at today's team meeting and it was agreed to do this; see
.


Thank you.

I note that these provides (while causing problems) also solved one
problem that now reappears. linux-libc-dev is marked `Multi-Arch:
foreign`, but this technically is a lie. It does not provide
linux-libc-dev for all architectures - not even for all linux-any
architectures and never will.

[...]

It is trivial for us to add support for additional architectures once
they are minimally supported in upstream Linux (we may also require
that dpkg recognises their triplet; I'm not sure).  There is no
requirement that we define a kernel configuration for the architecture
at the same time, or ever (see x32).

Can we assume that new Debian Linux ports will be able to satisfy that
or would that be a problem sometimes?


CCing Adrian, he recently wanted to provide cross toolchains for 
sparc-linux-gnu and ia64-linux-gnu, which the kernel doesn't provide 
anymore. So a design which allows these toolchains would be helpful.

Bug#1065416: Bastian's offer in #1065416

[Matthias Klose]

On 12.09.24 11:58, stefa...@debian.org wrote:

Hi Ben (2024.09.11_22:38:24_+)

While potential solutions to this bug are being discussed, would you
please consider removing the Provides from linux-libc-dev?


I am open to doing so.

[...]

I raised this at today's team meeting and it was agreed to do this; see
.


thank you!


Thank you, Ben and Bastian.

Matthias, I hope that unblocks you from making cross-toolchain-base
uploads.


I'm waiting for an upload with the removed or renamed provides.


Bastian, I'm assuming you still want to be able to provide these cross
headers. Can you propose a patch or description of how you'd provide
them, so we and Matthias can review?

Stefano



I also filed #1081826, I don't think that 99% of user installations 
should suffer a bad design for cross/bootstrap/whatever requirements.


Matthias

Bug#1065416: Bastian's offer in #1065416

[Helmut Grohne]

Hi Ben,

On Thu, Sep 12, 2024 at 07:56:09PM +0200, Ben Hutchings wrote:
> It is trivial for us to add support for additional architectures once
> they are minimally supported in upstream Linux (we may also require
> that dpkg recognises their triplet; I'm not sure).  There is no
> requirement that we define a kernel configuration for the architecture
> at the same time, or ever (see x32).

I understand that it is easy to add support for additional
architectures. The tricky part here is that bootstrapping needs such
support rather early and early tends to mean at a time where the dpkg
architecture name and properties are not yet finalized. Having this
support is crucial for performing test bootstraps and thus validating
the dpkg triplet, so there is a chicken&egg problem here.

As a result, bootstrapping has generally assumed that it needs to cater
for adding support to the linux package and only bothering linux package
maintainers once the architecture is known to dpkg. For doing that, the
bootstrap tooling needs to know whether a prospective architecture is
already supported by the linux source package or not. The necessary
change in src:linux is then rather simple as you pointed out.

> Can we assume that new Debian Linux ports will be able to satisfy that
> or would that be a problem sometimes?

It will be a problem in the common case.

Helmut

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

On Thu, 2024-09-12 at 12:19 +0200, Helmut Grohne wrote:
> Hi Ben,
> 
> Dropping leader@ and community@ from Cc as this is a technical
> side-track.
> 
> On Thu, Sep 12, 2024 at 12:38:24AM +0200, Ben Hutchings wrote:
> > On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
> > [...]
> > > My answers below are mine alone.  I have not discussed this with other
> > > team members and do not speak for them.
> > > 
> > > On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> > > > Hello kernel maintainers,
> > > > 
> > > > While potential solutions to this bug are being discussed, would you
> > > > please consider removing the Provides from linux-libc-dev?
> > > 
> > > I am open to doing so.
> > [...]
> > 
> > I raised this at today's team meeting and it was agreed to do this; see
> > .
> 
> Thank you.
> 
> I note that these provides (while causing problems) also solved one
> problem that now reappears. linux-libc-dev is marked `Multi-Arch:
> foreign`, but this technically is a lie. It does not provide
> linux-libc-dev for all architectures - not even for all linux-any
> architectures and never will.
[...]

It is trivial for us to add support for additional architectures once
they are minimally supported in upstream Linux (we may also require
that dpkg recognises their triplet; I'm not sure).  There is no
requirement that we define a kernel configuration for the architecture
at the same time, or ever (see x32).

Can we assume that new Debian Linux ports will be able to satisfy that
or would that be a problem sometimes?


Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


signature.asc
Description: This is a digitally signed message part

Bug#1065416: Bastian's offer in #1065416

[Helmut Grohne]

Hi Ben,

Dropping leader@ and community@ from Cc as this is a technical
side-track.

On Thu, Sep 12, 2024 at 12:38:24AM +0200, Ben Hutchings wrote:
> On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
> [...]
> > My answers below are mine alone.  I have not discussed this with other
> > team members and do not speak for them.
> > 
> > On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> > > Hello kernel maintainers,
> > > 
> > > While potential solutions to this bug are being discussed, would you
> > > please consider removing the Provides from linux-libc-dev?
> > 
> > I am open to doing so.
> [...]
> 
> I raised this at today's team meeting and it was agreed to do this; see
> .

Thank you.

I note that these provides (while causing problems) also solved one
problem that now reappears. linux-libc-dev is marked `Multi-Arch:
foreign`, but this technically is a lie. It does not provide
linux-libc-dev for all architectures - not even for all linux-any
architectures and never will. Whenever we add an architecture, a new
niche architecture comes along. This gives rise to the need to tell
apart from the package metadata whether linux-libc-dev provides headers
for a given architecture. Before the change from Arch:any to Arch:all,
the question was easily answered by the existence or non-existence of
the binary package. Then, when we added the provides, we could use them
to answer this question. As we remove the provides, there is no
metadata-driven answer to this question anymore.

This is not an urgent matter from my side, but it still is one I would
like to see a solution for eventually. As far as I understand things,
the removal of provides is meant to go back to a working state and then
let discussion resume. If we end up reinstating them (in combination
with other changes), my use case will be solved again. If the provides
are to be removed permanently, I'd like to see a different way of
answering the question.

Thanks for considering

Helmut

Bug#1065416: Bastian's offer in #1065416

[stefanor]

Hi Ben (2024.09.11_22:38:24_+)
> > > While potential solutions to this bug are being discussed, would you
> > > please consider removing the Provides from linux-libc-dev?
> > 
> > I am open to doing so.
> [...]
> 
> I raised this at today's team meeting and it was agreed to do this; see
> .

Thank you, Ben and Bastian.

Matthias, I hope that unblocks you from making cross-toolchain-base
uploads.

Bastian, I'm assuming you still want to be able to provide these cross
headers. Can you propose a patch or description of how you'd provide
them, so we and Matthias can review?

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
[...]
> My answers below are mine alone.  I have not discussed this with other
> team members and do not speak for them.
> 
> On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> > Hello kernel maintainers,
> > 
> > While potential solutions to this bug are being discussed, would you
> > please consider removing the Provides from linux-libc-dev?
> 
> I am open to doing so.
[...]

I raised this at today's team meeting and it was agreed to do this; see
.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


signature.asc
Description: This is a digitally signed message part

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

Hello Stefano, Matthias, Andreas, and other committee members,

I apologise for taking so long to respond to this issue.  I missed the
beginning of it as I did not have much time for Debian in February and
March this year.  I've been aware of it in recent months it but until
today I had not gone back and read through the full conversation.

My answers below are mine alone.  I have not discussed this with other
team members and do not speak for them.

On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> Hello kernel maintainers,
> 
> While potential solutions to this bug are being discussed, would you
> please consider removing the Provides from linux-libc-dev?

I am open to doing so.

> They can be re-instated again later, in combination with the requested
> symlinks, or the binary package can be transitioned to
> cross-toolchain-base, or some other solution found. I would hope that we
> can figure out the future of this package, without leaving
> cross-building broken.
> 
> Last month, Sean asked you:
> 
> > In [1], Bastian proposes that Matthias  take over the
> > linux-libc-dev binary package, building it from one of the crossbuilding
> > source packages he maintains.  Different people have been reading
> > Bastian's e-mail differently as to whether it was a serious proposal for
> > how to resolve the dispute, or just a rhetorical device Bastian was
> > using to make a point.
> > 
> > In any case, doko is among those who took the offer seriously.
> > 
> > In two messages written today, Bastian appears to say both that he
> > is okay with resolving the dispute that way, and also that he is not.
> > 
> > I am writing seeking some clarity.  What is the team consensus on this?
> > Is this something you are happy to do, would consider doing, or is it
> > off the table?  That would help us see where we are.

Since the Linux UAPI headers originate with Linux upstream, I think it
makes most sense for the linux source package to remain the primary
source for them in Debian.  If I understand correctly, no-one has
claimed that linux-libc-dev is causing problems other than through the
disputed Provides field.

I also don't see any convincing reason why linux-libc-dev and linux-
libc-dev-*-cross cannot continue to be built by different source
packages.  I recognise that there is some duplication that could be
avoided by building them together and having the -cross packages
contain only symlinks, but in my experience of cross-building for
embedded systems an extra few megabytes on the build system is in the
noise.

Kind regards,
Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


signature.asc
Description: This is a digitally signed message part

Bug#1065416: Bastian's offer in #1065416

[Stefano Rivera]

Hello kernel maintainers,

While potential solutions to this bug are being discussed, would you
please consider removing the Provides from linux-libc-dev?

They can be re-instated again later, in combination with the requested
symlinks, or the binary package can be transitioned to
cross-toolchain-base, or some other solution found. I would hope that we
can figure out the future of this package, without leaving
cross-building broken.

Last month, Sean asked you:

> In [1], Bastian proposes that Matthias  take over the
> linux-libc-dev binary package, building it from one of the crossbuilding
> source packages he maintains.  Different people have been reading
> Bastian's e-mail differently as to whether it was a serious proposal for
> how to resolve the dispute, or just a rhetorical device Bastian was
> using to make a point.
> 
> In any case, doko is among those who took the offer seriously.
> 
> In two messages written today, Bastian appears to say both that he
> is okay with resolving the dispute that way, and also that he is not.
> 
> I am writing seeking some clarity.  What is the team consensus on this?
> Is this something you are happy to do, would consider doing, or is it
> off the table?  That would help us see where we are.
> 
> Many thanks.
> 
> [1]  https://bugs.debian.org/1065416#108
> 
> -- 
> Sean Whitton

Have you given this any thought yet?

Thank you,

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1065416: Bastian's offer in #1065416

[Sean Whitton]

Hello kernel maintainers,

In [1], Bastian proposes that Matthias  take over the
linux-libc-dev binary package, building it from one of the crossbuilding
source packages he maintains.  Different people have been reading
Bastian's e-mail differently as to whether it was a serious proposal for
how to resolve the dispute, or just a rhetorical device Bastian was
using to make a point.

In any case, doko is among those who took the offer seriously.

In two messages written today, Bastian appears to say both that he
is okay with resolving the dispute that way, and also that he is not.

I am writing seeking some clarity.  What is the team consensus on this?
Is this something you are happy to do, would consider doing, or is it
off the table?  That would help us see where we are.

Many thanks.

[1]  https://bugs.debian.org/1065416#108

-- 
Sean Whitton


signature.asc
Description: PGP signature