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

Re: Bug#852215: FTBFS on non-release architectures

On 3 Feb 2017, at 15:28, Cyril Brulebois <kibi@debian.org> wrote:
> James Clarke <jrtc27@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.

Some data points:

alpha          : Missing srm-reader in archive. Builds after adding a
                 locally-built .udeb to localudebs (and working around the
                 crazy broken mirror setup on electro [one of the local mirrors
                 has no unstable -> sid symlink, but has an unreleased -> sid
                 symlink]*...  but that's not debian-installer's problem). If
                 alpha porters want installer images, I guess they should
                 upload and maintain srm-reader in unreleased.
hppa           : Builds after applying patch from #852260.
hurd-i386      : Builds without any further changes.
kfreebsd-amd64 : Builds if the netboot gtk image size limit is increased by 2M.
sparc64        : Builds without any further changes.

These were all done in chroots with just the build-deps installed. None of the
build results have been tested.


* This would not be a problem for http mirrors, since debian-installer would
  discard the mirror as invalid when generating the udeb sources.list, but
  since this is a file: mirror, it doesn't check for validity and assumes it
  works. In theory debian-installer could check file: mirrors too, which would
  work around this insanity.

Reply to: