Hi, 2018-06-29 11:35 GMT+02:00 Adam D. Barratt <[email protected]>: > 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 <[email protected]>
