Numba 0.61.2 and llvmlite 0.44.0 built with with python 3.13, numpy 2.2, and llvm-19
Hello, With help from upstream we've got versions of llvmlite and numba that build with dependencies currently in Debian. Numba built and passed tests for amd64 and arm64. It build but the build time tests failed for mips64el, ppc64el, and s390x. Numba couldn't build on armel, armhf, i386, and riscv64 because the BD are uninstallable. Upstream mostly supports amd64 and arm64, with unofficial support for ppcle64. https://numba.readthedocs.io/en/stable/user/installing.html Does this new version work for packages that need numba? How important are mips64el, ppc64el, and s390x for other people using packages dependent on numba? Diane
Re: MBF: Packages which break with nocheck
Hi Santiago,
On Sun, Apr 13, 2025 at 01:22:21PM +0200, Santiago Vila wrote:
> After building all the archive (trixie/sid) with nocheck, I only found 33 new
> packages which fail to build with nocheck that were not reported before.
> Admittedly
> a little bit more than I expected, but certainly not "hundreds" as some
> people feared.
Thanks for performing these builds!
For the rest of this mail, I am going to assume that "with nocheck"
means "when enabling the nocheck build profile" (see Simon's mail for
context). Please correct me if I'm wrong.
> My current plan for now would be to report them as "important" (using some
> usertag) with the following disclaimer:
I argue that the correct severity is serious. The release team agreed to
treat them as rc bugs about two years ago and I have reported more than
33 at rc severity. If we were not treating them as rc, the autoremover
could break trixie in the sense that it would no longer be
self-contained. So we should either have them rc, or change the behavior
of the autoremover to disregard restrictions.
The other side of this is that erroneous restrictions (and
that's what it is most of the time) are trivial to "fix". With rare
exceptions, you simply drop them. So while 33 may be a worrisome number
of additional rc bugs, the effort spent on fixing them is rather low in
practice.
That said, Emilio explicitly asked them not to be filed as rc on irc.
That feels like RT is not internally consistent here. How about filing
them as rc now and tagging them trixie-ignore later if we deem the
effort too big?
When filing them, please ensure that you file them with the source
package ("Source: ..." or "Package: src:...") and add the ftbfs tag such
that other automatic ftbfs reporters don't file duplicates.
Helmut
Re: MBF: Packages which break with nocheck
Hi, On 13-04-2025 17:12, Helmut Grohne wrote: That said, Emilio explicitly asked them not to be filed as rc on irc. That feels like RT is not internally consistent here. How about filing them as rc now and tagging them trixie-ignore later if we deem the effort too big? What I think he means, and I agree with him if I'm right, we don't want a _new_ systematic QA effort like this _at this stage_ of the release to add lots of RC bugs for a case where the RC-ness only comes from the way we run our autoremoval. I'm monitoring the "self-contained" state of trixie [1] for more then a year now and I've been filing (RC) bugs to make packages aware of problems (not only for this class of issues). Currently trixie is nearly fully self-contained in this respect. So at this moment this RC problem (running with nocheck build profile changes the content of the package) is in practice not a critical issue for trixie. What I really want to avoid is that people get afraid to add the !nocheck profile. It's valuable to have, let's not scare people so late in the release cycle. Paul [1] https://qa.debian.org/dose/debcheck/src_testing_main/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Brief progress report on the Gatway to NEW project.
Hello, Thanks for the links. The checklist in itself seems like it would fix a lot of problems. Here are some comments: - The item "A verbatim copy of the package’s copyright information is often required to be present in /usr/share/doc/PACKAGE/copyright, too; see Copyright considerations." doesn't seem clearly actionable. It's already basically covered by "All the copyright holders found by the copyright-grep CI test are mentionned in debian/copyright.". - That requirement could be weakened: "All the copyright *notices* [not holders] found by the copyright-grep CI test are mentionned in debian/copyright except those where copyright *notices* are already installed in plain text in the binary package." (this is the issue that "often required to be present" is trying to get at -- let me know if you're not clear on what I mean). - Some items to check for preferred forms for modification would be helpful. For example if there is a .jpg with metadata saying it was exported from Photoshop, then we also need the .psd in d/missing-sources. - The grep copyright CI jobs are nice. Hopefully over time we can tweak them to exclude duplicates etc.. It can be done collaboratively so that people's efforts can be pooled. All in all, a great start to this effort. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#1094969: git linked with OpenSSL
On 2025-04-13 Chris Hofstaedtler wrote: > brian m. carlson (one of the git upstream copyright holders) claims > in Bug #1094969 that git cannot be distributed when linked with > OpenSSL. IIRC the Debian position is to use the system library > exception. > Indeed our /usr/lib/git-core/git-remote-https links against > libssl.so.3, probably via libcurl-gnutls.so.4. > To avoid introducing distro-wide changes at a time where this seems > inappropriate, an option is to disable building git with libcurl. > Below is a simple patch to accomplish this. Barring any new insights > or feedback from the involved maintainers, this might be a way out. > I believe all relevant people are in CC:, and they can figure this > out. Details can be found in the bug. [...] Hello, well, we have decided to use the system library exception because we thought we had the right to so, not because we hoped that no copyright holder would notice. Undoing this for specific packages where a copyright holders tells us he disagrees undermines this position. Imho we need to either with using the exception or somebody(TM) needs to do a license analysis of our packages and we then need to implement coding changes to weed out any and all GPL<->openssl linkage. Personally I doubt we have the manpower nowadays to switch back from linking against OpenSSL. cu Andreas
Re: Proposal: drop libcrypt-dev dependency from libc6-dev
Hello fellow developers, On Thu, Apr 10, 2025 at 07:37:32AM +0200, Helmut Grohne wrote: > how about libc6-dev stops depending on libcrypt-dev? with minor disagreement in details, I have received much positive feedback and therefore moved forward. > So far so good. That's 1 + 95 + 11 + 1 = 108 source packages from the > perl ecosystem in need of changes. What about others? All of the perl ones have been filed and gregor already fixed (thanks!) a significant fraction including all 11 perl-xs-dev ones. I guess that on third of these is fixed in git or unstable. > few packages that indirectly use libcrypt. The following packages ship a > pkgconfig file containing -lcrypt and therefore need "Depends: > libcrypt-dev". > * guile-2.2-dev > * guile-3.0-dev > * heimdal-multidev > * libapr1-dev > * libidzebra-2.0-dev > * librep-dev > * libuser1-dev > * ruby3.1-dev > * ruby3.3-dev > In addition, gauche-dev has gauche-config that also emits -lcrypt. Now > matching this up with the build failures yields four that will be fixed > be one of these being modified. Bugs with patches are filed for these. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helm...@debian.org&tag=libcrypt-pkgconf Notably, libuser is missing as I did a QA upload instead. > So that's modifying another 110 + 9 + 1 + 6 = 126 source packages > outside the perl ecosystem. You'll find all of the mentioned categories > in the published logs as subdirectories. Please bear in mind that among > the packages that FTBFS in unstable, a small fraction would additionally > FTBFS without libcrypt and I've missed those. Expect a few more. ... > build depend on libcrypt-dev (mostly to support bootstrapping). So if > you disregard all of those duplicates, what remains is 28 packages > missed in the FTBFS-based analysis: I have not yet filed bugs for packages lacking "Build-Depends: libcrypt-dev". That's a next step. I consider the perl-xs-dev dependencies and the runtime dependencies more important as both of them also affect other use cases (such as cross building). > I'd appreciate explicit replies from: Thanks for the quick feedback! Regarding the timing of the glibc upload, I also am in favor of not upgrading lots of these bugs to rc severity. Given the usertags, we may monitor how the situation evolves in forky. I suggest once the remaining unfixed bug count (across all categories) is 30 or less, we may proceed and upgrade the remaining ones to rc. Helmut
Re: Bug#1094969: git linked with OpenSSL
brian m. carlson (one of the git upstream copyright holders) claims in Bug #1094969 that git cannot be distributed when linked with OpenSSL. IIRC the Debian position is to use the system library exception. Indeed our /usr/lib/git-core/git-remote-https links against libssl.so.3, probably via libcurl-gnutls.so.4. To avoid introducing distro-wide changes at a time where this seems inappropriate, an option is to disable building git with libcurl. Below is a simple patch to accomplish this. Barring any new insights or feedback from the involved maintainers, this might be a way out. I believe all relevant people are in CC:, and they can figure this out. Details can be found in the bug. Chris diff -Nru git-2.49.0/debian/changelog git-2.49.0/debian/changelog --- git-2.49.0/debian/changelog 2025-03-15 18:48:53.0 +0100 +++ git-2.49.0/debian/changelog 2025-04-13 22:18:18.0 +0200 @@ -1,3 +1,11 @@ +git (1:2.49.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Disable building with libcurl. + + -- Chris Hofstaedtler Sun, 13 Apr 2025 22:18:18 +0200 + git (1:2.49.0-1) unstable; urgency=low * new upstream release (see RelNotes/2.48.0.adoc, RelNotes/2.49.0.adoc). diff -Nru git-2.49.0/debian/control git-2.49.0/debian/control --- git-2.49.0/debian/control 2025-03-15 18:48:14.0 +0100 +++ git-2.49.0/debian/control 2025-04-13 22:18:18.0 +0200 @@ -3,9 +3,10 @@ Priority: optional Maintainer: Jonathan Nieder Uploaders: Anders Kaseorg +Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev Build-Depends: libz-dev, gettext, libpcre2-dev | libpcre3-dev, - libcurl4-gnutls-dev, libexpat1-dev, + libexpat1-dev, subversion, libsvn-perl, libyaml-perl, tcl, python3, libhttp-date-perl | libtime-parsedate-perl, diff -Nru git-2.49.0/debian/rules git-2.49.0/debian/rules --- git-2.49.0/debian/rules 2025-03-15 18:36:51.0 +0100 +++ git-2.49.0/debian/rules 2025-04-13 22:18:18.0 +0200 @@ -10,6 +10,7 @@ OPTS =NO_OPENSSL=1 prefix=/usr gitexecdir=/usr/lib/git-core \ mandir=/usr/share/man htmldir=/usr/share/doc/git/html \ INSTALLDIRS=vendor \ + NO_CURL=1 \ SANE_TOOL_PATH= INSTALL=install TAR=tar \ NO_CROSS_DIRECTORY_HARDLINKS=1 NO_INSTALL_HARDLINKS=1 \ NO_PERL_CPAN_FALLBACKS=1 \
Pending autoremoval of debian-reference* packages
I belive debian wants to provide its documentation as packages in stable releases. But currently debian-reference is scheduled for auto removal on 2025-04-15 (which this mail bumps a bit into the future). Maybe "nobody" is aware of this? Anyone up to taking a look at this? On Mon, 17 Mar 2025 08:14:02 +0100 Helmut Grohne wrote: > Package: > debian-reference-de,debian-reference-en,debian-reference-es,debian-reference-fr,debian-reference-id,debian-reference-it,debian-reference-ja,debian-reference-pt,debian-reference-pt-br,debian-reference-zh-cn,debian-reference-zh-tw > Version: 2.125 > Severity: serious > User: debian...@lists.debian.org > Usertags: fileconflict > Control: affects -1 + debian-reference-common > > The debian-reference packages have a tricky undeclared file conflict > that may break bookworm to trixie upgrades. In bookworm, > debian-reference-common contains a symlink > /usr/share/doc/debian-reference-common/docs pointing to > ../../debian-reference whereas the debian-references-* packages in > trixie install the same location as a directory. On the face of it, this > is an undeclared file conflict. Really though, a bad unpack order can > cause the unpack of the trixie files to be redirected and then go > missing as this is a symlink to directory conversion moving between > packages. The debian-refefence-* packages really need to prevent > concurrent unpack with bookworm's debian-reference-common. Breaks and > Replaces is not sufficient here. I think the options basically are using > Conflicts or upgrading the versioned dependency on > debian-reference-common to a Pre-Depends (requires consultation with > d-devel). The latter option is a larger hammer and prevents a weird > corner case that is not covered by Conflicts. > > Helmut
MBF: Packages which break with nocheck
Hello. After building all the archive (trixie/sid) with nocheck, I only found 33 new packages which fail to build with nocheck that were not reported before. Admittedly a little bit more than I expected, but certainly not "hundreds" as some people feared. (The main reason there are not so many is that Helmut Grohne has been reporting those every now and then). My current plan for now would be to report them as "important" (using some usertag) with the following disclaimer: Disclaimer: This was going to be a release goal for trixie, but I'm reporting it as "important" because it's not clear how many bugs of this type are acceptable as RC at this point of the release cycle. but of course I'm open to suggestions regarding the above text, particularly from Release Managers. On a personal note, I consider those bugs interesting to fix because I think there should be a safe procedure to build all packages in the archive in a way which minimizes build failures as much as possible. Currently such procedure would be to build all the packages in the regular way and then retry with nocheck those which fail to build. It would be more simple and straightforward if we were able to build everything with nocheck from the beginning. It would be a sign of quality and a milestone if one day we could get zero build failures doing that. Thanks.
Re: MBF: Packages which break with nocheck
On Sun, 13 Apr 2025 at 13:22:21 +0200, Santiago Vila wrote: After building all the archive (trixie/sid) with nocheck, I only found 33 new packages which fail to build with nocheck that were not reported before. Admittedly a little bit more than I expected, but certainly not "hundreds" as some people feared. (The main reason there are not so many is that Helmut Grohne has been reporting those every now and then). I think there are two subtly different things that you could mean by "with nocheck": 1. DEB_BUILD_OPTIONS=nocheck, but no special build profiles - therefore build-dependencies are still installed 2. DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=nocheck - therefore build-dependencies are likely to be missing (DEB_BUILD_PROFILES=nocheck without DEB_BUILD_OPTIONS=nocheck is not allowed by https://wiki.debian.org/BuildProfileSpec, and for convenience some build tools automatically convert it into (2.), with a warning.) Failing to build in either of those configurations is a bug, and both could be argued to be either RC or non-RC depending on opinions and priorities, but in practice I think (1.) is going to succeed more often than (2.). For example #1102605 is an example of a package that FTBFS when we do (2.) but would have succeeded if we do (1.). This is a fairly common failure mode, but I would expect packages that FTBFS in scenario (1.), but do build successfully if their tests had been run, to be very rare. My current plan for now would be to report them as "important" (using some usertag) I think that seems reasonable, but in the template email please be clear about which scenario it was that you tried. Helmut's wording "fails to build from source in unstable when enabling the nocheck build profile" seems good - that unambiguously identifies scenario (2.). On a personal note, I consider those bugs interesting to fix because I think there should be a safe procedure to build all packages in the archive in a way which minimizes build failures as much as possible. If that's what you want, I think scenario (1.) is the one that will maximize your number of successful builds, although possibly at the cost of shipping software that compiles but does not work (in ways that build-time tests would have detected). Running build-time tests is a trade-off: it makes us less likely to ship broken software, at the cost of sometimes treating unimportant bugs (either in the software under test, or in the tests themselves) as more serious than they necessarily need to be. Helmut has been testing scenario (2.) and reporting bugs when it fails, because it's interesting as a way to reduce build-dependencies for bootstrappability and cross-compiling, but the price he pays for that is that he'll sometimes see build failures like #1102605. smcv
Re: MBF: Packages which break with nocheck
El 13/4/25 a las 15:22, Simon McVittie escribió: On a personal note, I consider those bugs interesting to fix because I think there should be a safe procedure to build all packages in the archive in a way which minimizes build failures as much as possible. If that's what you want, I think scenario (1.) is the one that will maximize your number of successful builds, although possibly at the cost of shipping software that compiles but does not work (in ways that build-time tests would have detected). Yes, that's what I tested and what I was going to report. I'll make sure that the bug text is not ambiguous, and also will use some usertag like ftbfs-deb-build-options-nocheck to make it even more clear. Thanks a lot!
