Hi Sergio, On Sun, Nov 01, 2026 at 09:31:27PM -0500, Sergio Durigan Junior wrote: > I don't vehemently disagree with you, but if upstream chose to keep > -Werror in the release then I tend to follow their lead here. For > example, OSCAR has this snippet in their .pro file: > > --8<---------------cut here---------------start------------->8--- > # Always treat warnings as errors, even (especially!) in release > QMAKE_CFLAGS += -Werror > QMAKE_CXXFLAGS += -Werror > --8<---------------cut here---------------end--------------->8--- > > So using -Werror in the release build was intentional. I understand we > may see FTBFSes due to that, but I'm personally willing to go through > the trouble of reporting problems upstream in this case.
To me, that's precisely the problem. Keeping -Werror in your CI allows you to go through the trouble of handling those FTBFSes. Enabling it in the package makes *others* go through that trouble. > Having said that, I noticed that my last upload did build correctly on > s390x: > > > https://buildd.debian.org/status/fetch.php?pkg=oscar&arch=s390x&ver=2.1.0-2&stamp=1793330527&raw=0 No idea what's different between the cross build and the native one, but we agree on not spending further effort here: > Ah, right. I thought this was a problem with OSCAR itself. In this > case, let's keep things in this bug. > It wasn't as hard as I was thinking, although TBH I haven't checked if > upstream is patching their amalgamation of botan (I don't think so). > > I've just uploaded the package to experimental; feel free to take a look > at the patch and let me know. I will probably give it a week before > uploading to unstable, unless upstream agrees with my changes. I spent a brief look and it mostly looks fine. In principle, this could be upstreamable if changing two more aspects. I guess upstream would want to keep the vendor copy, so adding a conditional for selecting the vendored vs system one would likely be required. The other aspect is using pkg-config to discover the flags for botan. Maybe you can try this snippet? CONFIG += link_pkgconfig PKGCONFIG += botan-3 > Oh, I haven't unvendored the existing botan either. We can do that > later. I don't think there is much point in repacking the source to remove the vendored botan so long as it is distributable (and it is). The problem to solve here is not copying vulnerabilities and that is achieved by linking the system version. To me, your experimental upload fully addresses the reported problem. How about also looking at bookworm and trixie? Unvendoring botan there probably is not appropriate. But maybe updating the debian-security-support package to call oscar unsupported in those releases would be worthwhile? See for example https://sources.debian.org/src/debian-security-support/1%3A14%2B2026.05.07/security-support.deb13 Helmut
