[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#902226: debian-installer-netboot-images: FTBFS in stretch, even when allowing network access

Hi Santiago,

Santiago Vila <sanvila@unex.es> (2018-06-23):
> Without using any special flag or environment variable, what I would
> expect is that it downloads things from stretch as well, as every
> point release of stretch should ideally be "self-contained" for
> building purposes.
> I see this line in debian/rules:
> export DISTRIBUTION?=stretch-proposed-updates
> Maybe that's the problem.

Right, that allows us to build from s-p-u when catching up with d-i
changes staged into s-p-u, which happens for each and every point
release where d-i gets updated (I don't remember any where it was
skipped, but my memory is not to be trusted), starting right after r0.

> I'm putting all my build logs here for you to see:
> https://people.debian.org/~sanvila/build-logs/debian-installer-netboot-images/
> You will see that version 20170615 of this package used to build ok in
> the past.

Right, see commit 5a0d0847c8a12e2dd3f13ce86aff797f4472dbd6 for stretch;
previous releases should have something similar.

> [ Note: I fear that this could be another wontfix bug, like the one
>   complaining about network access, so I will not bother to set a
>   severity, but I still believe that for consistency, packages in
>   stretch should be buildable in stretch by default, even when they
>   need network access ].

Well, I've seen a fair share of “complaints”, but no solutions, so I
fear this isn't going to be fixed any time soon indeed. Needless to say,
I'm not a huge fan of this specific requirement / policy violation, but
I have yet to see actual, viable solutions. From my rather self-centered
point of view, d-i releases are a sufficient burden already that I don't
wish to make this worse by adding some extra layers of complexity or

>   If, after all, you consider that the cure is worse than the disease,
>   then please consider this as a documentation bug and if possible
>   explain somewhere why we are not expected to build this package
>   without failures ].

At first glance, it seems to me this bug could be addressed in two
different ways, which don't seem to be too convoluted. The first way
would be to try the s-p-u download and fall back to s download, for each
and every download. But this could (probably only theoretically) lead to
inconsistent downloads, mixing bits and pieces from s-p-u and from s.
Plus plenty of errors when the default location isn't the right one.

I suppose a better way would be to figure out with an early test if the
target version is available in s-p-u or in s, and then pick the right
suite for all downloads. Patches for this second approach are welcome.
(Currently travelling, not easy to test things needed network access.)

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: