Re: Installer Questions
On 06/14/2016 12:06 AM, alexmcwhirter@triadic.us wrote:
> Ok, so i have a new CD the works well enough. I took some time to dig through the source and i have a few questions.
You should share your CD images. My images are about a month old and I cannot create any new images because my SPARC
box is currently sitting in the basement after I changed jobs.
> 1. Are we allowed to sign the sparc64 unstable repo?
We are signing the repository. We are just using the Debian Ports Archive keyring (package: debian-ports-archive-keyring) and not
the regular Debian archive keyring (package: debian-ports-keyring).
> I'm 90% certain that this is why "select & install software" fails. Even if its signed unofficially and the
> signature is pushed into the unofficial CD it would help in that regard. Of course, i can do this for myself locally but that wont help anyone else.
Yes, this is the reason as can be seen from the Debian Installer log. The Debian Ports Archive keyring is wired up in the Debian Installer
configuration [1], it's just not being used for some reason. I have patched out the signature verification in some CD releases or used a
preseed file [2] to disable authentication.
It might be a bug in Debian Installer that it ignores the value set in [1]. If you find out why, please suggest a patch and we can fix
that in Debian Installer.
> 2. I understand that sparc64 is an unstable branch, and from what i can see it keeps up to date with the official unstable branch. It seems like there are some
> situations where keeping a unofficial testing branch may be more ideal. Is something like buildd capable to taking the source of the current testing branch and
> build a sparc64 version of it?
testing is never built by the buildds, testing is created by taking packages from unstable after these have been in unstable after a grace period of 2 to 10
days. The same applies for the release architectures.
The problem is that Debian Ports does not have all the fancy release mechanisms that the release architectures have and it is therefore more complicated to
create usable releases. This is basically the reason why I want sparc64 to become a release architecture in Debian as this would magically resolve all the
installer and quality issues. But unless some company is willing to donate some new sparc64 hardware to Debian or someone is able to convince DSA to use
some older sparc64 hardware, this is not going to happen, unfortunately.
> I ask because it might make sense to keep something somewhat stable around (stable as in not constantly changing). This might help in the future when new bugs
> are introduced (I.E Kernel 4.6). We could keep 4.5 in testing until 4.7 is in unstable and verified working as well or better than 4.5. This is mostly just to
> keep machines that were working fine from breaking after an update (as much as possible anyways). Testing may be the wrong name for such a branch, but again i
> am not certain of what is allowed as what is not. If we tracked real testing, then i suppose we would be stuck with 4.5 until the next release after stretch.
> That may not be ideal.
Again, Debian Ports has no means to support anything besides unstable and experimental. testing requires additional infrastructure which is not present
in Debian Ports. sparc64 needs to become a release architecture and all these problems are magically solved, that's all.
I'd still be gladful if you figured out though what the problem with the KEYRING setting from [1] being ignored is, in any case. For the other ports
architectures.
> This is something i would be interested in doing for myself, but i would do it for everyone if we're even allowed to do such a thing.
Try fixing the bug in [1] and convince someone rich to hand over some sparc64 boxes. Problem solved :).
Adrian
> [1] http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/sparc64.cfg
> [2] https://people.debian.org/~glaubitz/preseed-sparc64.cfg
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: