Re: d-i: autopkgtest for i386

2026-03-29 Thread Holger Wansing
Hi,

Paul Gevers  wrote (Sat, 28 Mar 2026 09:18:49 +0100):
> It does, at least it helped me to search for whether partman-base was 
> already not installable in testing. And obviously I should have thought 
> of it before, but this is tracked on the d-i.debian.org website [1]. Aas 
> we don't build an installer on i386 anymore anyways, it's OK to hint it 
> through, which I'll do.

partman-partitioning migrated to testing now.
Thanks for caring, Paul!



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Mass arch-specific removals (Re: d-i: autopkgtest for i386)

2026-03-28 Thread Charles Plessy
Le Sat, Mar 28, 2026 at 04:21:07PM +0100, Paul Gevers a écrit :
> 
> You can see in the current ongoing r-cran-* turn-around that that might be
> more work than it's worth.

Hi Paul, you are the first to complain about this, and not directly to me.

The main complain I have is that it causes dependencies to stay out of Testing
for a long time.

I do not want to be a pain or a stress factor to core teams.  If the removal is
causing too much work to the Release team or the Archives Operations team,
please let me know and I will do one more mass upload to revert what was not
completed yet.  (In 10 days, because I am about to travel).

But please tell it frankly, on the debian-r mailing list.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -



Re: d-i: autopkgtest for i386

2026-03-28 Thread Cyril Brulebois
Paul Gevers  (2026-03-28):
> Correct, if you add a not installable dependency to something that's still
> installable. If this would happen often, you could stop building packages on
> i386 and get the binaries removed on that architecture. You can see in the
> current ongoing r-cran-* turn-around that that might be more work than it's
> worth.

Since we know about this specific issue, and provided the release team
is happy to process a few hint requests if and when this problem arises
again… and unless we get an explicit request to nuke i386 out of the
orbit, I think I'd rather avoid playing whack-a-mole with i386 binaries
indeed.


Cheers,
-- 
Cyril Brulebois ([email protected])
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: d-i: autopkgtest for i386

2026-03-28 Thread Pascal Hambourg

On 28/03/2026 at 16:21, Paul Gevers wrote:


Correct, if you add a not installable dependency to something that's 
still installable. If this would happen often, you could stop building 
packages on i386 and get the binaries removed on that architecture.


It was a missing dependency, so it should not happen often. I let d-i 
maintainers comment on the opportuneness to keep or stop building 
packages on i386.


Thanks for the confirmation and hint.



Re: d-i: autopkgtest for i386

2026-03-28 Thread Paul Gevers

Hi,

On 3/28/26 15:58, Pascal Hambourg wrote:

- It will not happen again until a dependency is changed ?



Correct, if you add a not installable dependency to something that's 
still installable. If this would happen often, you could stop building 
packages on i386 and get the binaries removed on that architecture. You 
can see in the current ongoing r-cran-* turn-around that that might be 
more work than it's worth.


Paul



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: d-i: autopkgtest for i386

2026-03-28 Thread Pascal Hambourg

On 28/03/2026 at 14:54, Paul Gevers wrote:

On 3/28/26 13:31, Holger Wansing wrote:
Hmm, does that mean, in the future such manual action is required for 
every migration to testing?


No, because what the migration software tries to prevent regressions.


IIUC,

- Some d-i packages depend on kernel module udebs.
- When i386 kernel packages were removed from testing, d-i packages 
which directly or indirectly depend on them became uninstallable on i386.
- New package versions in unstable were also uninstallable on i386 but 
versions in testing were already uninstallable so it was not considered 
a regression and transitions to testing were not blocked.
- Then I added one of these uninstallable packages to 
partman-partitioning 161 Depends, making it uninstallable too, and it 
was considered a regression so its transition to testing was blocked.

- It will not happen again until a dependency is changed ?



Re: d-i: autopkgtest for i386

2026-03-28 Thread Paul Gevers

Hi,

On 3/28/26 13:31, Holger Wansing wrote:

Hmm, does that mean, in the future such manual action is required for every 
migration to testing?



No, because what the migration software tries to prevent regressions.

Paul



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: d-i: autopkgtest for i386

2026-03-28 Thread Holger Wansing
Hi,

Am 28. März 2026 09:18:49 MEZ schrieb Paul Gevers :
>
>It does, at least it helped me to search for whether partman-base was already 
>not installable in testing. And obviously I should have thought of it before, 
>but this is tracked on the d-i.debian.org website [1]. Aas we don't build an 
>installer on i386 anymore anyways, it's OK to hint it through, which I'll do.

Hmm, does that mean, in the future such manual action is required for every 
migration to testing?
If yes, it would be worse finding the real cause for this requirement, so maybe 
the probably circular deoendency?


Holger


-- 
Sent from /e/ OS on Fairphone3



Re: d-i: autopkgtest for i386

2026-03-28 Thread Paul Gevers

Hi Holger,

On 3/28/26 10:42, Holger Levsen wrote:

i'm just standing idle on the sidelines but I'm wondering why you care about
autopkgtests for udebs on i386 at all, given that since trixie there is no
d-i for i386 as per
https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-reduced-support

I managed to refrain from posting this for the first 5 mails on this bug but
now I thought to comment anyway.



I think you missed a point somewhere as I don't think anybody says we 
care about testing udebs on i386. The original bug report (1131935) was 
about autopkgtest failure on all architectures because it was testing 
i386 everywhere, not only on i386. That bug has been fixed already. In 
the discussion about partman-partitioning I was worried about britney 
bugs, so I wanted to understand.


All should be well soon (one I get my hints right).

Paul



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: d-i: autopkgtest for i386

2026-03-28 Thread Samuel Thibault
Holger Wansing, le sam. 28 mars 2026 11:26:14 +0100, a ecrit:
> Am 28. März 2026 10:19:22 MEZ schrieb Pascal Hambourg 
> :
> >On 28/03/2026 at 09:18, Paul Gevers wrote:
> >> 
> >> It does, at least it helped me to search for whether partman-base was 
> >> already not installable in testing.
> >
> >Many d-i packages depend on kernel udebs, which are not available for i386 
> >in testing.
> 
> What irritates me more is, that most d-i packages are listed as uninstallable 
> on amd64 as well, according to
> 

That's a completely different issue, being solved, waiting for
dfsg-queue action.
(which also had its own piece of irritation, please do not pour more on
it)

Samuel



Re: d-i: autopkgtest for i386

2026-03-28 Thread Holger Wansing
Hi,

Am 28. März 2026 10:19:22 MEZ schrieb Pascal Hambourg :
>On 28/03/2026 at 09:18, Paul Gevers wrote:
>> 
>> It does, at least it helped me to search for whether partman-base was 
>> already not installable in testing.
>
>Many d-i packages depend on kernel udebs, which are not available for i386 in 
>testing.

What irritates me more is, that most d-i packages are listed as uninstallable 
on amd64 as well, according to



Holger



-- 
Sent from /e/ OS on Fairphone3



Re: d-i: autopkgtest for i386

2026-03-28 Thread Holger Levsen
hi,

i'm just standing idle on the sidelines but I'm wondering why you care about
autopkgtests for udebs on i386 at all, given that since trixie there is no
d-i for i386 as per
https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-reduced-support
 

I managed to refrain from posting this for the first 5 mails on this bug but
now I thought to comment anyway.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Things don't "fall into the public domain" at the end of their copyright term,
Ugh.
Once released from copyright, works Ascend into the glorious ranks of the
public domain, fulfilling their rightful destiny as part of the cultural
heritage of humanity! (Duncan Lock)


signature.asc
Description: PGP signature


Re: d-i: autopkgtest for i386

2026-03-28 Thread Pascal Hambourg

On 28/03/2026 at 09:18, Paul Gevers wrote:


It does, at least it helped me to search for whether partman-base was 
already not installable in testing.


Many d-i packages depend on kernel udebs, which are not available for 
i386 in testing.


(I wonder why xfs-modules is not available for armhf either)



Re: d-i: autopkgtest for i386

2026-03-28 Thread Paul Gevers

Hi Holger,

On 3/28/26 07:09, Holger Wansing wrote:

Am 27. März 2026 22:11:51 MEZ schrieb Paul Gevers :


That sounds more like a question to the Release Team. I'm trying to find the answer. I'm 
wondering if this isn't a case of "no regression", and hence could/should be 
ignored.


Pascal already mentioned some sort of circular dependency as the reason:
partman-partitioning 161 (newly) depends on partman-base, while partman-base 
also depends on partman-partitioning.

Maybe this helps.



It does, at least it helped me to search for whether partman-base was 
already not installable in testing. And obviously I should have thought 
of it before, but this is tracked on the d-i.debian.org website [1]. Aas 
we don't build an installer on i386 anymore anyways, it's OK to hint it 
through, which I'll do.


Paul

[1] https://d-i.debian.org/dose/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: d-i: autopkgtest for i386

2026-03-27 Thread Holger Wansing
Hi Paul,

Am 27. März 2026 22:11:51 MEZ schrieb Paul Gevers :
>
>That sounds more like a question to the Release Team. I'm trying to find the 
>answer. I'm wondering if this isn't a case of "no regression", and hence 
>could/should be ignored.

Pascal already mentioned some sort of circular dependency as the reason:
partman-partitioning 161 (newly) depends on partman-base, while partman-base 
also depends on partman-partitioning.

Maybe this helps.

Holger




-- 
Sent from /e/ OS on Fairphone3



Re: d-i: autopkgtest for i386

2026-03-27 Thread Paul Gevers

Hi Holger,

On 3/27/26 09:26, Holger Wansing wrote:

Maybe, partman-partitioning suffers from a similar problem?



partman-partitioning doesn't have autopkgtest. Heh, it even doesn't have 
debs.



It fails to migrate to testing for weeks, due to being uninstallable on i386.
Because of unmet dependencies, but I fail to see which one; ftpmasters didn't 
answer yet.



That sounds more like a question to the Release Team. I'm trying to find 
the answer. I'm wondering if this isn't a case of "no regression", and 
hence could/should be ignored.


Paul



OpenPGP_signature.asc
Description: OpenPGP digital signature