Hi Bastian (2025.02.04_13:25:08_-0400)
The resolution of the issue brought to the tech-ctte requires figuring
out whether linux-libc-dev will take over providing these headers for
cross toolchain building, or whether cross-toolchain-base continues to
own the linux-libc-dev-${arch}-cross virtual p
Hi,
On Tue, Feb 04, 2025 at 05:25:08PM +, stefa...@debian.org wrote:
> Hi Bastian (2025.02.04_14:05:07_+)
> > > > Provides: linux-libc-dev-amd64, linux-libc-dev-arm64, ...
> > > We have two proposed provides schemes here, can we select one and add
> > > it?
> >
> > Something like simple pr
Hi
On Tue, Feb 04, 2025 at 05:25:08PM +, stefa...@debian.org wrote:
> So, by implementing this Provides scheme, Helmut's cross-bootstrapping
> toolchain can determine which architectures are supported, and have a
> target to Depend on.
I just read through rebootstrap, which I think is what He
Hi Bastian (2025.02.04_14:05:07_+)
> > > Provides: linux-libc-dev-amd64, linux-libc-dev-arm64, ...
> > We have two proposed provides schemes here, can we select one and add
> > it?
>
> Something like simple providers is the easiest to do.
So, by implementing this Provides scheme, Helmut's cros
Hi
On Mon, Jan 27, 2025 at 07:36:21PM -0400, Stefano Rivera wrote:
> > Provides: linux-libc-dev-amd64, linux-libc-dev-arm64, ...
> We have two proposed provides schemes here, can we select one and add
> it?
Something like simple providers is the easiest to do.
> > As stated elsewhere, I still do
Hi Bastian:
> > Something like this?
> >
> > | Provides:
> > | linux-libc-dev-supports (= amd64-0),
> > | linux-libc-dev-supports (= arm64-0),
> > | linux-libc-dev-supports-multiarch (= aarch64-linux-gnu-0),
> > | linux-libc-dev-supports-multiarch (= x86-64-linux-gnu-0),
>
> Using Provid
Hi Bastian,
On Thu, Dec 05, 2024 at 03:30:53PM +0100, Bastian Blank wrote:
> What kind of information can this dependency satisfiability test use?
>
> Something like this?
>
> | Provides:
> | linux-libc-dev-supports (= amd64-0),
> | linux-libc-dev-supports (= arm64-0),
> | linux-libc-dev-s
On Thu, Dec 05, 2024 at 08:38:35AM +0100, Helmut Grohne wrote:
> This is the stage I am concerned about. You claim that it would not
> matter whether the package is all or any, but my experience is
> otherwise. With the exception of linux, the cross bootstrap tooling does
> not build any Arch:all p
Hi Bastian,
On Wed, Dec 04, 2024 at 10:40:59PM +0100, Bastian Blank wrote:
> On Thu, Oct 24, 2024 at 01:29:31AM +0200, Ben Hutchings wrote:
> > Do we really want to be on the critical path for the early stages of
> > defining a new architecture, including any renaming that might happen
> > before
Hi Bastian,
I think much of what you are asking here is already answered in my reply
to Ben's followup.
On Wed, Dec 04, 2024 at 10:33:28PM +0100, Bastian Blank wrote:
> On Sat, Oct 19, 2024 at 06:15:57PM +0200, Helmut Grohne wrote:
> > On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote
On Thu, Oct 24, 2024 at 01:29:31AM +0200, Ben Hutchings wrote:
> On Sat, 2024-10-19 at 15:35 +0200, Bastian Blank wrote:
> > I have to disagree. With this setup, we can support architectures that
> > are neither known by dpkg nor dak. This was not possible before and
> > required patching, aka ma
On Sat, Oct 19, 2024 at 06:15:57PM +0200, Helmut Grohne wrote:
> On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote:
> > On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote:
> > > A. Multi-Arch: foreign is a lie
> > All the examples of yours will immediatelly fail to build anyt
Hi Bastian (2024.10.19_09:35:21_-0400)
> What you describe here is a headers only library. It is consensus
> within Debian that those exist and are shipped as arch:all. They don't
> provide further architecture clues in the dependencies, but you need to
> know or convey this information by failin
Hi,
I skipped replying here earlier, because I felt like I would not add any
content. Stefano indicated that my impression was wrong. Hence replying
now.
On Thu, Oct 24, 2024 at 01:31:32AM +0200, Ben Hutchings wrote:
> On Sat, 2024-10-19 at 18:15 +0200, Helmut Grohne wrote:
> > Hi Bastian,
> >
>
On Sat, 2024-10-19 at 15:35 +0200, Bastian Blank wrote:
> Hi
>
> On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote:
[...]
>
> > Ben asked me whether linux-libc-dev could simply support all relevant
> > architectures, but there often is a check&egg problem. The linux package
> > can on
On Sat, 2024-10-19 at 18:15 +0200, Helmut Grohne wrote:
> Hi Bastian,
>
> On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote:
[...]
>
> > But now you can have a port without hand patched linux that is built in
> > a non-standard way and relying on internal and unstable package API,
> >
Hi Bastian,
On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote:
> On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote:
> > A. Multi-Arch: foreign is a lie
...
> All the examples of yours will immediatelly fail to build anything with
> it. So what harm is done?
This is practi
Hi
On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote:
> A. Multi-Arch: foreign is a lie
>
> linux-libc-dev declares being Multi-Arch: foreign, but it does not live
> up to the involved promise and cannot. Earlier, a dependency on
> linux-libc-dev:hurd-i386 would be considered unsatisf
Package: linux-libc-dev
Version: 6.6.3-1~exp1
Hi,
Ben asked me to file a bug report with the linux package describing the
issues I see with linux-libc-dev being Arch:all.
A. Multi-Arch: foreign is a lie
linux-libc-dev declares being Multi-Arch: foreign, but it does not live
up to the involved p
19 matches
Mail list logo
