Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hi,
2018-06-29 11:35 GMT+02:00 Adam D. Barratt <adam@adam-barratt.org.uk>:
> On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton wrote:
> [...]
>> what is the reason why that package is not moving forward?
>
> I assume you're referring to the dpkg upload that's in proposed-updates
> waiting for the point release in two weeks time? Please check your
> facts before ranting, particularly with such a wide cross-posting.
Yep, this changed in the last few days. Thanks to the people involved!
It's not guaranteed that this version will be part of the final update
9.5, but let's hope that no blocker appears.
People from DSA have also attempted to fix them in other ways over the
last few months (thanks for that too!), but the solutions have been
rejected. I am not aware of the full details (only part of them), but
I assume that it's done for sound reasons. One good reason for this
is that they don't want to duplicate code or list of architectures.
> Also, ttbomk, the dpkg change landing in stable is not likely to
> magically lead to the architecture being added to unstable - a decision
> which is not the release team's to make or block. Again, please ensure
> you've actually done your research.
I think that there's some confusion related to this. I am not sure if
everyone is on the same page about what "added to unstable" means.
At the risk of failing to enlighten and make matters worse, let me try.
The packages uploaded to unstable now (since ~March) are attempted to
build automatically in riscv64, and most of them succeed, just over
80%. Most of the remaining missing packages are because of lack of
support upstream that blocks this big chunk of the archive for one
reason or another.
The problem which involves this dpkg-in-stable-updates topic is that
some packages need to add the string "riscv64" in Architecture fields
to be able to build, but they cannot be uploaded to unstable with such
modification, because they would be auto-rejected by the archive
software "dak", which relies on dpkg's knowledge of architectures for
this (the dpkg installed on the system, not from git or anywhere
else).
This is the case of, among other packages, "binutils", "glibc" or
"linux", and we need to build them specially adding "riscv64" in
specific places, and upload to another suite which is not "unstable"
(named "unreleased", which probably many people never heard of).
This is problematic mainly for two reasons:
- needs human intervention, repeatedly
- "debootstrap" for example, the most widely used tool for creating
chroots and the base of images, cannot work. This is because it is
restricted to one URL, so it cannot use both suites
unstable+unreleased at the same time, and some of the packages that I
mentioned before are needed in any base system [*].
Now, if a dpkg version with knowledge about riscv64 architecture
enters an stable-update and the systems running "dak" do apply the
upgrade, "dak" will start accepting these packages, so we can request
that maintainers add support for riscv64, so they don't need human
intervention and it'll save significant amounts of pointless work, and
will automatically make the port to be more up-to-date with these
packages that cannot build.
Some people like the binutils maintainer already did the biggest part
of the job long ago, and it's much easier for us after that, but they
cannot add this last bit until this problem is resolved somehow.
If this doesn't work for some reason (e.g. a blocker bug to this
version of dpkg that prevents actually becoming part of the
stable-update), we will have to keep doing this pointless work at
least until a year from now, with the next stable.
[*] Maybe there are more packages from the base set installed by
debootstrap which would prevent this for other reasons, but these
packages for sure are the biggest problem right now.
> I'm also getting very tired of the repeated vilification of SRM over
> this, and if there were any doubt can assure you that it is not
> increasing at least my inclination to spend my already limited free
> time on Debian activity.
Sorry about that :(
I don't think that it's a problem caused SRM by other parts in
particular, and I am sorry that you get vilified for this.
>From a more distanced view, it would be nice though for other ports in
the future if dak's knowledge about architectures could be decoupled
from "dpkg-version-in-stable", and no other parts were too coupled in
general to versions of packages from stable. The very nature of ports
means that sometimes they need features not present in packages by the
time that they entered stable.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: