[Debian-ports-devel] Bug#852215: FTBFS on non-release architectures

[Cyril Brulebois]

Hi,

James Clarke <jrtc27 at debian.org> (2017-01-22):
> As you know, debian-installer does not build on non-release
> architectures, since it tries to build for stretch. Some architectures
> also have some of the needed udebs in the unreleased suite, such as
> sparc-utils on sparc64. The attached patch lets me build on sparc64
> even after a `dch --release`, and I would assume on other ports
> architectures too. Is this something you would consider applying?

As mentioned on IRC a tiny while back, I can understand how this is
necessary since ports are going to have specific packages (e.g.
bootloaders) which don't really make sense to have in the official
archive.

It looks to me like your proposed patch makes it a bit hard to
understand what's happening in debian/rules, and I'd like to propose
a different take on this, by first having the usual daily builds vs.
release heuristics, then having overrides for ports. I've pushed a
pu/support-for-ports branch for you folks to double check:
  https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=pu/support-for-ports&id=6580c874c5263fb500f5b222f7d4f6a1c17ac532
  https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=pu/support-for-ports&id=1ca77bc7c8aaa7c4948905bd0dc4ca8b397a0c00

I removed amd64 from RELEASE_ARCHES so that amd64 would be considered
like a port (2005 called, it wants its sarge-amd64 release back!) and
it seems to work just fine, with a warning about an invalid mirror
when unreleased isn't found there. So hopefully that shouldn't make
it any harder for kfreebsd-* (which currently FTBFS anyway…).

Please let me know what you think and which results you get with a
real test on unreleased ports.


KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-ports-devel/attachments/20170203/96069339/attachment.sig>