Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
On 5/8/23 21:22, Paul Gevers wrote: Hi Tobias, On Sat, 6 May 2023 10:24:41 + Tobias Hansen wrote: Note that we could also just remove python3-sage and the autopkgtest. I assume you mean python3-brial here. Yes indeed. Nothing in Debian depends on it Not true (and it's too late in the freeze to do that [1]): paul@mulciber ~ $ reverse-depends python3-brial Reverse-Recommends == * science-mathematics-dev * singular-data I see. I checked with dak [1] and those were not shown, maybe because they are recommends and not depends. Anyway, I'm fine with the proposed NMU. Best, Tobias [1] https://wiki.debian.org/ftpmaster_Removals
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
Hi Tobias, On Sat, 6 May 2023 10:24:41 + Tobias Hansen wrote: Note that we could also just remove python3-sage and the autopkgtest. I assume you mean python3-brial here. Nothing in Debian depends on it Not true (and it's too late in the freeze to do that [1]): paul@mulciber ~ $ reverse-depends python3-brial Reverse-Recommends == * science-mathematics-dev * singular-data Paul PS: please cc me on reply, I'm not subscribed to this bug. [1] https://release.debian.org/testing/freeze_policy.html#appropriate OpenPGP_signature Description: OpenPGP digital signature
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
On 5/2/23 14:20, plugwash wrote: I've prepared a NMU, and intend to open a pre-approval request with the release team. If you have any objections to the NMU please tell me ASAP (I do not intend to upload it until I receive a response from the release team, if you would preffer to make the upload yourself that is fine too). Hi, thanks for taking care of the NMU. Note that we could also just remove python3-sage and the autopkgtest. Nothing in Debian depends on it and the upstream maintainer of brial pointed out that it is not needed anymore: https://alioth-lists.debian.net/pipermail/debian-science-sagemath/2023-May/001809.html Best, Tobias
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
Hell All, I have just made singular independent from brial
Thanks for dealing with that part of the issue.
Otherwise it must be keep in mind that Sage is mostly umbrella software.
That means that the dependency of brian on sage material is odd.
odd as it may be, it seems the dependency of python3-brial
on sagemath is real.
I've prepared a NMU, and intend to open a pre-approval
request with the release team. If you have any objections
to the NMU please tell me ASAP (I do not intend to upload
it until I receive a response from the release team, if you
would preffer to make the upload yourself that is fine too).
diff -Nru brial-1.2.11/debian/changelog brial-1.2.11/debian/changelog
--- brial-1.2.11/debian/changelog 2023-04-03 12:13:10.0 +
+++ brial-1.2.11/debian/changelog 2023-05-02 10:39:34.0 +
@@ -1,3 +1,11 @@
+brial (1.2.11-2.1) bookworm-staging; urgency=medium
+
+ * Non-Maintainer upload.
+ * Limit architectures for python3-brial package to architectures where
+sagemath is available (Closes: #1034443).
+
+ -- Peter Michael Green Tue, 02 May 2023 10:39:34
+
+
brial (1.2.11-2) unstable; urgency=medium
* Team upload.
diff -Nru brial-1.2.11/debian/control brial-1.2.11/debian/control
--- brial-1.2.11/debian/control 2023-04-03 12:11:20.0 +
+++ brial-1.2.11/debian/control 2023-04-08 15:18:38.0 +
@@ -22,7 +22,7 @@
Homepage: https://github.com/BRiAl
Package: python3-brial
-Architecture: any
+Architecture: amd64 arm64 i386 riscv64
Section: python
Depends: python3-sage,
${misc:Depends},
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable
Hell All, I have just made singular independent from brial. Otherwise it must be keep in mind that Sage is mostly umbrella software. That means that the dependency of brian on sage material is odd. Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi, On 23-04-2023 23:01, Peter Michael Green wrote: That does leave the question of how brial with this bug migrated to testing in the first place. Whether there was a recent intentional change in britney, whether there was a bug/glitch, or whether it was forced in (and if-so who forced it). I'm pretty sure that if you look at my hints [1], you'll find who did it. I think that in this case I *thought* it better to let brial move with the fix, obviously shortsightedly overlooking this particular effect. Maybe I was wrong doing that, but I'm still unsure. I really dislike hardcoding of the architectures of dependencies, as it's a maintenance burden forever (until sage builds everywhere). I mean, who is going to regularly check if sage builds on more architectures? Paul [1] https://release.debian.org/britney/hints/elbrus OpenPGP_signature Description: OpenPGP digital signature
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
On 23/04/2023 21:07, Paul Gevers wrote: Can you point to a discussion where we might draw the conclusion that this is common practice or consensus? I *personally* [no hats on] find that distinction a bit weird although I can see how we would come to it and also why. No, I can't point to a discussion. I vaugely remember hearing it from a more experianced developer (possiblly a release team member) on IRC years ago. But it has been consistent with how I have seen bugs handled in practice over my years in Debian. It's also consistent with how britney behaves or at least did until very recently. My understanging is that britney performs architecture checks on all release architectures where a package is built for arch specific packages, but only performs architecture checks on a small subset of architectures (when I first started with Debian it was i386 only, I think now it's amd64 and arm64, maybe also i386) for arch all packages. I have vauge reccollections of a document descirbing the different behaviour for arch all packages in britney as a "hack", so I presume this is something that started as a hack and then just became the status quo. If you wanted your package in testing and it was arch specific you had to make sure it was installable on all architectures where it was built, but if it was arch all you did not (and often could not). I have seen people ask the release team for exceptions when their arch-all package is not installable on one of the architectures where arch all packages are checked but I can't recall ever seeing such a request for an arch-specific package. And when I look at https://qa.debian.org/dose/debcheck/testing_main/index.html this seems to back up my observation. That does leave the question of how brial with this bug migrated to testing in the first place. Whether there was a recent intentional change in britney, whether there was a bug/glitch, or whether it was forced in (and if-so who forced it). This seems to be your real issue. Why file the bug against python3-brial? When an issue involving multiple packages shows up on my radar, I tend to start by filing a bug with the package where a fix could potentially have the most impact and cc the maintainers of other packages that are involved. Ack. And I agree with this approach. However, we are *also* in the Hard Freeze, so RC bugs reports have more severe results if not treated swiftly. Agreed, given where we are in the Freeze, enough time has passed to file a rc bug against singular with an expression of intent to NMU. I'll do that later today. I also hereby announce that I intend to NMU brial if I don't get a maintainer response soon. (I am assuming Paul is posting as a release team member and not as a maintainer of the package, if that is wrong please speak up)
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi Peter, On 23-04-2023 21:24, Peter Michael Green wrote: That works in some cases, but it's a bad option here for two reasons. 1. It would create a build-dependency loop between brial and sagemath. Which isn't practical problem as long as there is a proper build profile involved, right? But given point 2, I think both the point and this is argument are moot. 2. It would mean that other binary packages built from the brial source package had their architecture list unnecessarily limited. Aha, I missed that detail. There are more arch: binaries build by src:brial. > Technically I even think that this isn't a bug in python3-brial. One of the criteria (indeed the first on the list) for grave is "makes the package in question unusable or mostly so". I consider that a package that cannot be installed is unusable. If I follow that reasoning than about 850 arch:all binaries also have RC bugs: https://qa.debian.org/dose/debcheck/testing_main/1682226002/some.html My understanding has always been that for source packages that build multiple binaries, the test of "is the package unusable" is applied for each binary package individually and that for packages that are built separately for multiple architectures (not arch all packages) it is applied for each architecture individually. I don't think that is officially written down anywhere though. Can you point to a discussion where we might draw the conclusion that this is common practice or consensus? I *personally* [no hats on] find that distinction a bit weird although I can see how we would come to it and also why. This seems to be your real issue. Why file the bug against python3-brial? When an issue involving multiple packages shows up on my radar, I tend to start by filing a bug with the package where a fix could potentially have the most impact and cc the maintainers of other packages that are involved. Ack. And I agree with this approach. However, we are *also* in the Hard Freeze, so RC bugs reports have more severe results if not treated swiftly. If the maintainer of brial came back and said that the fix for bug 1033878 was wrong, and that python3-brial could in-fact be made usable on all architectures then there would. [missing words?] Yes, sure. However, looking at the stack trace in that bug, I agree that the dependency is the most logical solution. Ensuring python3-brial to be useful without that dependency will require patching the code by the looks of it. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
On 23/04/2023 19:19, Paul Gevers wrote: I claim this is wrong. Would python3-sage one day build on more architectures, this list would need manual updating. Instead of hard-coding the list, it's better to ensure the build doesn't happen or fails on architectures where python3-sage is not available. E.g. by build-depending (ideally with a build profile indicating that the *build* itself works; I suggest ). That works in some cases, but it's a bad option here for two reasons. 1. It would create a build-dependency loop between brial and sagemath. 2. It would mean that other binary packages built from the brial source package had their architecture list unnecessarily limited. > Technically I even think that this isn't a bug in python3-brial. One of the criteria (indeed the first on the list) for grave is "makes the package in question unusable or mostly so". I consider that a package that cannot be installed is unusable. My understanding has always been that for source packages that build multiple binaries, the test of "is the package unusable" is applied for each binary package individually and that for packages that are built separately for multiple architectures (not arch all packages) it is applied for each architecture individually. I don't think that is officially written down anywhere though. This seems to be your real issue. Why file the bug against python3-brial? When an issue involving multiple packages shows up on my radar, I tend to start by filing a bug with the package where a fix could potentially have the most impact and cc the maintainers of other packages that are involved. If the maintainer of brial came back and said that the fix for bug 1033878 was wrong, and that python3-brial could in-fact be made usable on all architectures then there would. On the other hand whatever changes were made in singular we would still have unusable python3-brial packages. So I started out with a bug against python3-brial.
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Hi Peter, all, On Sat, 15 Apr 2023 15:33:04 +0100 Peter Green wrote: * The architecture list of python3-brial needs to be limited to architectures where python3-sage is available. I claim this is wrong. Would python3-sage one day build on more architectures, this list would need manual updating. Instead of hard-coding the list, it's better to ensure the build doesn't happen or fails on architectures where python3-sage is not available. E.g. by build-depending (ideally with a build profile indicating that the *build* itself works; I suggest ). Technically I even think that this isn't a bug in python3-brial. Assuming the dependency is real and unavoidable, than being uninstallable is bug in the depending on package, but not an RC one. * The build-dependency of singular on python3-brial needs to be either removed or limited to architectures where python3-sage is available This seems to be your real issue. Why file the bug against python3-brial? * Removal of the old python3-brial packages needs to be requested. Assuming something is done to prevent the binaries from building, then yes, obviously. However, why would we consider arch: uninstallable packages different than arch:all uninstallable packages if the reason is the same: depending on a binary that's not build on some arch. Do our tools have different expectations for them? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular
Package: python3-brial Version: 1.2.11-2 Severity: serious X-debbugs-cc: singu...@packages.debian.org python3-brial recently added a dependency on python3-sage, however python3-sage is only available on amd64, arm64, i386 and riscv64. This also means that the build-depends of singular on those architectures are unsatisfied. Strangely, when I look at the singular build log the only mentions of brial I see are in the Debian packaging steps, I don't see any mentions of it from the upstream build system. Grepping for brial in the polybori source doesn't reveal anything outside the debian dir either. I maintain a downstream distribution and, after removing the build-dependency, was able to build singular there without having any brial related packages installed. So assuming the dependency on python3-sage is real and unavoidable what I think needs to happen to get things back in a consistent state is. * The architecture list of python3-brial needs to be limited to architectures where python3-sage is available. * The build-dependency of singular on python3-brial needs to be either removed or limited to architectures where python3-sage is available * Removal of the old python3-brial packages needs to be requested.
