Bug#1061376: marked as done (pam-python ftbfs with Python 3.12 as default)
Your message dated Wed, 07 Feb 2024 07:49:47 + with message-id and subject line Bug#1061376: fixed in pam-python 1.1.0~git20220701.1d4e111-0.5 has caused the Debian Bug report #1061376, regarding pam-python ftbfs with Python 3.12 as default to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1061376: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061376 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:pam-python Version: 1.1.0~git20220701.1d4e111-0.4 Severity: serious Tags: sid trixie ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.12 with python3-defaults from experimental: a work around is to build without -Werror. [...] running build_ext building 'pam_python' extension creating build creating build/temp.linux-x86_64-cpython-312 x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -g -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/<>=/usr/src/pam-python-1.1.0~git20220701.1d4e111-0.4 -Wall -Wextra -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Werror -I/usr/local/lib/ -Wdate-time -D_FORTIFY_SOURCE=3 -fPIC -g -DLIBPYTHON_SO=\"libpython3.12.so.1.0\" -I/usr/include/python3.12 -c pam_python.c -o build/temp.linux-x86_64-cpython-312/pam_python.o Running Sphinx v7.2.6 pam_python.c: In function ‘initialise_python’: pam_python.c:130:3: error: ‘Py_DontWriteBytecodeFlag’ is deprecated [-Werror=deprecated-declarations] 130 | Py_DontWriteBytecodeFlag = 1; | ^~~~ In file included from /usr/include/python3.12/Python.h:48, from pam_python.c:44: /usr/include/python3.12/cpython/pydebug.h:18:37: note: declared here 18 | Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_DontWriteBytecodeFlag; | ^~~~ pam_python.c:131:3: error: ‘Py_IgnoreEnvironmentFlag’ is deprecated [-Werror=deprecated-declarations] 131 | Py_IgnoreEnvironmentFlag = 1; /* Required to mitigate CVE-2019-16729 */ | ^~~~ /usr/include/python3.12/cpython/pydebug.h:17:37: note: declared here 17 | Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_IgnoreEnvironmentFlag; | ^~~~ pam_python.c:132:3: error: ‘Py_NoUserSiteDirectory’ is deprecated [-Werror=deprecated-declarations] 132 | Py_NoUserSiteDirectory = 1; /* Required to mitigate CVE-2019-16729 */ | ^~ /usr/include/python3.12/cpython/pydebug.h:19:37: note: declared here 19 | Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_NoUserSiteDirectory; | ^~ pam_python.c:134:3: error: ‘Py_IsolatedFlag’ is deprecated [-Werror=deprecated-declarations] 134 | Py_IsolatedFlag = 1; | ^~~ /usr/include/python3.12/cpython/pydebug.h:22:37: note: declared here 22 | Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_IsolatedFlag; | ^~~ --- End Message --- --- Begin Message --- Source: pam-python Source-Version: 1.1.0~git20220701.1d4e111-0.5 Done: Mike Gabriel We believe that the bug you reported is fixed in the latest version of pam-python, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1061...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Mike Gabriel (supplier of updated pam-python package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 07 Feb 2024 08:07:10 +0100 Source: pam-python Architecture: source Version: 1.1.0~git20220701.1d4e111-0.5 Distribution: unstable Urgency: medium Maintainer: Russell Stuart Changed-By: Mike Gabriel Closes: 1061376 Changes: pam-python (1.1.0~git20220701.1d4e111-0.5)
Bug#1062821: ola: NMU diff for 64-bit time_t transition
Hi Lucas,
On Sat, Feb 03, 2024 at 02:39:49PM -0300, Lucas Kanashiro wrote:
> Source: ola
> Version: 0.10.9.nojsmin-4
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> ola as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
Would it make sense for me to contact upstream and ask if they do
certain things? They're quite knowledgeable and might know.
If not, then no worries, but I thought I'd ask.
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1062570: libpng1.6: NMU diff for 64-bit time_t transition
control: found -1 1.6.40-3 On Sun, 4 Feb 2024 11:05:46 +0100 Gianfranco Costamagna wrote: control: affects -1 1.6.40-3 G. On Thu, 01 Feb 2024 23:12:06 + Steve Langasek wrote: > Source: libpng1.6 > Version: 1.6.42-1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libpng1.6 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libpng1.6 > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: Re: libpng1.6: NMU diff for 64-bit time_t transition
Processing control commands: > found -1 1.6.40-3 Bug #1062570 [src:libpng1.6] libpng1.6: NMU diff for 64-bit time_t transition Marked as found in versions libpng1.6/1.6.40-3. -- 1062570: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062570 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063275: marked as done (r-bioc-rhtslib: identified for time_t transition but no ABI in shlibs)
Your message dated Wed, 07 Feb 2024 07:23:43 + with message-id and subject line Bug#1063275: fixed in r-bioc-rhtslib 2.4.1+dfsg-2 has caused the Debian Bug report #1063275, regarding r-bioc-rhtslib: identified for time_t transition but no ABI in shlibs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1063275: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063275 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: r-bioc-rhtslib Version: 2.4.1+dfsg-1 Severity: serious User: debian-...@lists.debian.org Usertags: time-t Hi Andreas, Analysis of the archive for the 64-bit time_t transition[0][1] identifies r-bioc-rhtslib as an affected package, on the basis that it depends on some library whose ABI is sensitive to time_t, which requires reverse-dependencies to be built with LFS support enabled, and r-bioc-rhtslib's own ABI is sensitive to LFS support. However, r-bioc-rhtslib's shlibs file declares a dependency on a library package name that contains no ABI information: $ cat DEBIAN/shlibs libhts 3 r-bioc-rhtslib (>= 2.4.1+dfsg) $ It is not obvious that we should rename the package to 'r-bioc-rhtslibt64' as part of this transition. Looking at the archive, there are packages built from the separate r-bioc-rsamtools and r-bioc-variantannotation source packages that depend on this library. Since there is no self-evident thing to do with the library package name here, we will not be handling this package as part of the mass NMUs. Instead I am filing a serious bug because partial upgrades from bookworm to trixie on 32-bit architectures will result in ABI skew and may result in broken behavior. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [0] https://wiki.debian.org/ReleaseGoals/64bit-time [1] https://lists.debian.org/debian-devel/2024/01/msg00041.html signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Source: r-bioc-rhtslib Source-Version: 2.4.1+dfsg-2 Done: Andreas Tille We believe that the bug you reported is fixed in the latest version of r-bioc-rhtslib, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1063...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Tille (supplier of updated r-bioc-rhtslib package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 07 Feb 2024 07:58:13 +0100 Source: r-bioc-rhtslib Architecture: source Version: 2.4.1+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Debian R Packages Maintainers Changed-By: Andreas Tille Closes: 1063275 Changes: r-bioc-rhtslib (2.4.1+dfsg-2) unstable; urgency=medium . * Restrict architectures to 64bit to avoid time_t transition Closes: #1063275 Checksums-Sha1: 9a41b02d035c9880ebb0e90fc7145e761c239ab6 2286 r-bioc-rhtslib_2.4.1+dfsg-2.dsc 1fadb6ea5b0abcf9319161679f02934c37dd0732 4320 r-bioc-rhtslib_2.4.1+dfsg-2.debian.tar.xz ed822d08c3f6a6de9ea077d8f956e50d719228e0 11453 r-bioc-rhtslib_2.4.1+dfsg-2_amd64.buildinfo Checksums-Sha256: 154aa3e5708f6b7585d268ae77149ba14f2122033350284c9f5d54334dbefea6 2286 r-bioc-rhtslib_2.4.1+dfsg-2.dsc a01dbe4eae9d026c6c3425ab715e21f0a329af9a07b6ad91c4867c15edc205e3 4320 r-bioc-rhtslib_2.4.1+dfsg-2.debian.tar.xz a8a17047fe2debed41e49726154a07865d75824a578b57ab12ff22c6f7e562a4 11453 r-bioc-rhtslib_2.4.1+dfsg-2_amd64.buildinfo Files: 66dbdc0bcca40d1dca280b67e848b26b 2286 gnu-r optional r-bioc-rhtslib_2.4.1+dfsg-2.dsc a75cce87be6b81af8009f089a728285a 4320 gnu-r optional r-bioc-rhtslib_2.4.1+dfsg-2.debian.tar.xz 69005620990ef469f3fc286adb44f29f 11453 gnu-r optional r-bioc-rhtslib_2.4.1+dfsg-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCAAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmXDKvMRHHRpbGxlQGRl Ymlhbi5vcmcACgkQV4oElNHGRtEKsA/9EFKpj4ZLQAJ+jKwtyT61tq+zf+ZE+hK6 rItqTMMpKWdy07zBTIwaC8PK9r4Fk21QECXbBKCiMRS4chBrrbk1Tsnp8pwKab8s
Bug#1061341: Fwd: Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
On 2/7/24 06:31, ellie timoney wrote:
Hi Xavier,
On Mon, 29 Jan 2024, at 9:59 AM, ellie timoney wrote:
On Thu, 25 Jan 2024, at 3:53 PM, Yadd wrote:
yes there are other errors because some .h require unavailable .h like
config.h
Ooh interesting, I'll have a look
I'm still working on this, but the more I work on it, the more of it turns out
to need fixing...
I think for now, it makes sense for you to proceed with the packaging changes
assuming that 32 bit Cyrus will _not_ be ABI compatible when recompiled with 64
bit time_t. From the original email, I think that means you'll need to set up
strict version dependencies between the cyrus-common, cyrus-admin and
cyrus-clients packages, so that people can't partially upgrade and wind up with
conflicts.
Cheers,
ellie
Hi,
dependencies are already strict (= ${binary:Version}).
To be able to render cyrus-dev headers compatible with ABI test, I'll
have to remove the following (missing config.h,...):
/usr/include/cyrus/bufarray.h
/usr/include/cyrus/charset.h
/usr/include/cyrus/command.h
/usr/include/cyrus/crc32.h
/usr/include/cyrus/cyr_qsort_r.h
/usr/include/cyrus/glob.h
/usr/include/cyrus/imapurl.h
/usr/include/cyrus/mappedfile.h
/usr/include/cyrus/procinfo.h
/usr/include/cyrus/rfc822tok.h
/usr/include/cyrus/sieve/sieve_err.h
/usr/include/cyrus/sieve/sieve_interface.h
/usr/include/cyrus/sqldb.h
/usr/include/cyrus/tok.h
/usr/include/cyrus/vparse.h
/usr/include/cyrus/wildmat.h
Processed: severity of 1062817 is important
Processing commands for cont...@bugs.debian.org: > severity 1062817 important Bug #1062817 [firmware-amd-graphics] firmware-amd-graphics: Invalid UVD handle causes the graphics driver to crash Severity set to 'important' from 'critical' > thanks Stopping processing here. Please contact me if you need assistance. -- 1062817: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062817 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1058286: marked as done (ncrack: FTBFS: configure: error: *** zlib too old - check config.log ***)
Your message dated Wed, 07 Feb 2024 03:39:19 + with message-id and subject line Bug#1058286: fixed in ncrack 0.7+debian-5 has caused the Debian Bug report #1058286, regarding ncrack: FTBFS: configure: error: *** zlib too old - check config.log *** to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1058286: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058286 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: ncrack Version: 0.7+debian-4 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20231212 ftbfs-trixie Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > checking for getspnam... yes > checking for library containing basename... none required > checking for zlib.h... yes > checking for deflate in -lz... yes > checking for possibly buggy zlib... yes > configure: error: *** zlib too old - check config.log *** > Your reported zlib version has known security problems. It's possible your > vendor has fixed these problems without changing the version number. If you > are sure this is the case, you can disable the check by running > "./configure --without-zlib-version-check". > If you are in doubt, upgrade zlib to version 1.2.3 or greater. > See http://www.gzip.org/zlib/ for details. > configure: error: ./configure failed for opensshlib > tail -v -n \+0 config.log The full build log is available from: http://qa-logs.debian.net/2023/12/12/ncrack_0.7+debian-4_unstable.log All bugs filed during this archive rebuild are listed at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20231212;users=lu...@debian.org or: https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20231212=lu...@debian.org=1=1=1=1#results A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please mark it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with mine so that we can identify if something relevant changed in the meantime. --- End Message --- --- Begin Message --- Source: ncrack Source-Version: 0.7+debian-5 Done: Arnaud Rebillout We believe that the bug you reported is fixed in the latest version of ncrack, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1058...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Arnaud Rebillout (supplier of updated ncrack package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 07 Feb 2024 09:02:26 +0700 Source: ncrack Architecture: source Version: 0.7+debian-5 Distribution: unstable Urgency: medium Maintainer: Debian Security Tools Changed-By: Arnaud Rebillout Closes: 1048666 1058286 Changes: ncrack (0.7+debian-5) unstable; urgency=medium . [ Peter Wienemann ] * Allow zlib versions with two-part version number (Closes: #1058286) * Make source package build after successful build (Closes: #1048666) Checksums-Sha1: 6b09cd49fc8068760455a19eb981a0b63626e4bc 1981 ncrack_0.7+debian-5.dsc 0e8332842101cee65382f64451dbbd8ae530a5a0 16812 ncrack_0.7+debian-5.debian.tar.xz 0105bef4f824ebfd7b6834f6307c68acd1bc0b59 6483 ncrack_0.7+debian-5_source.buildinfo Checksums-Sha256: 8de057f50afd3c91d3873cd2b8f693444e1aed1b0fbf5456b6e8c4bd98985910 1981 ncrack_0.7+debian-5.dsc aa3fe577c76d3a897ffd71605a421a627986d17b808ff02f818f83b2c87aeda8 16812 ncrack_0.7+debian-5.debian.tar.xz f0fc71bfe67192b18aabd4d2d415730b969214feb9eeab98881aa1522717b6a1 6483 ncrack_0.7+debian-5_source.buildinfo Files: 12940dd60c5c6b5c733159c79db8d722 1981 net optional ncrack_0.7+debian-5.dsc d8b1d5146e95620424daac060bc88cb7 16812 net optional ncrack_0.7+debian-5.debian.tar.xz 7a92ffbb682b5ae83cbbcd56bd9ead6c 6483 net optional ncrack_0.7+debian-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAmXC5a4RHGFybmF1ZHJA
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi! On Tue, 2024-02-06 at 15:42:33 +0100, Helmut Grohne wrote: > On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote: > > Providing two APIs makes me quite uneasy due to having core components > > that would behave differently from the rest of the distribution. It > > sounds like something that will come back to bite for a long time. > > Can you elaborate? Yes, I'm not sure I understand either. This is what symbol versioning makes possible, even providing different variants for the same symbol, see for example glibc or libbsd. In any case, if going the bi-ABI path, I think upstream should get involved, and the shape of this decided with them. In addition the library should also be built with LFS by the upstream build system, which it does not currently, to control its ABI. > Keep in mind that for all the 64bit architectures, there is no abi > difference as the symbol is only added for those architectures, that > currently use a 32bit ino_t. > > I checked on codesearch.d.n and there are very few users on this API; > > actually, none I think. Per > > https://codesearch.debian.net/search?q=matchpathcon_filespec_add=1=1 > > - box64 mentions that API but the "code" is commented-out, > > - busybox uses it in the "setfiles" applet which isn't built, > > - android-platform-external-libselinux has it in headers but also has > > its own implementation > > > > That should hopefully give more freedom although I'm not sure what would > > be the preferred route. > > And here you are arguing that there are no practical users of the added > symbol, so with luck, we'd be adding an unused symbol on armhf. With bad > luck, we'd have some users and for those users we'd be ABI-incompatible > with the rest of the world on armhf. I think there are only three ways to go about this, excluding the t64 attempt: 1) Build the library with LFS unconditionally (except on i386). As there are no users in Debian, this would not break there, but would break for any external packages and locally unpackaged users of the library. 2) Bump the SONAME, ideally coordinate with upstream or alternatively with a Debian specific one. This does not break locally built packages nor locally unpackaged code linking against the library. 3) Build the library with LFS support (everywhere including i386), and on systems w/o built-in LFS, make the old symbol use 32-bit ino_t, and add a new symbol that uses 64-bit ino_t. This preserves the ABI, for external packages and locally unpackaged code linking against the library. I think the three options would cause no upgrade issues, as they include either no SONAME bump (option 1 and 3), or an actual SONAME bump (option 2) with no file conflicts involved. Personally I'd like to be able to cleanly and safely build dpkg with time64 everywhere (including i386, otherwise the port will not be even installable), so my preference is for options that make that possible (2 and 3), and from those the one with best backwards compatibility with was the main concern for excluding i386 from the time64 transition would be option 3. So I think that would be the preferred option here. If you'd like assistance with trying to get a proposal for 3 to present upstream I could look into that. But I think they should be involved early on to see what they'd like to see and what they might outright reject. Thanks, Guillem
Bug#1061750: marked as done (python-cliapp ftbfs with Python 3.12 as default)
Your message dated Wed, 07 Feb 2024 02:36:02 +
with message-id
and subject line Bug#1061750: fixed in python-cliapp 1.20180812.1-6
has caused the Debian Bug report #1061750,
regarding python-cliapp ftbfs with Python 3.12 as default
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1061750: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061750
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:python-cliapp
Version: 1.20180812.1-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
With python3-defaults from experimental, the package fails to build:
[...]
==
ERROR: test_exports_all_config_sections_via_as_cp
(cliapp.settings_tests.SettingsTests.test_exports_all_config_sections_via_as_cp)
--
Traceback (most recent call last):
File "/<>/cliapp/settings_tests.py", line 596, in
test_exports_all_config_sections_via_as_cp
self.settings.load_configs(open_file=mock_open)
File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you
mean: 'read'?
==
ERROR: test_handles_defaults_with_ini_files
(cliapp.settings_tests.SettingsTests.test_handles_defaults_with_ini_files)
--
Traceback (most recent call last):
File "/<>/cliapp/settings_tests.py", line 357, in
test_handles_defaults_with_ini_files
self.settings.load_configs(open_file=mock_open)
File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you
mean: 'read'?
==
ERROR: test_handles_overridden_defaults_with_ini_files
(cliapp.settings_tests.SettingsTests.test_handles_overridden_defaults_with_ini_files)
--
Traceback (most recent call last):
File "/<>/cliapp/settings_tests.py", line 387, in
test_handles_overridden_defaults_with_ini_files
self.settings.load_configs(open_file=mock_open)
File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you
mean: 'read'?
==
ERROR: test_handles_values_from_ini_files_overridden_on_command_line
(cliapp.settings_tests.SettingsTests.test_handles_values_from_ini_files_overridden_on_command_line)
--
Traceback (most recent call last):
File "/<>/cliapp/settings_tests.py", line 419, in
test_handles_values_from_ini_files_overridden_on_command_line
self.settings.load_configs(open_file=mock_open)
File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you
mean: 'read'?
==
ERROR: test_load_configs_raises_error_for_unknown_variable_in_ini
(cliapp.settings_tests.SettingsTests.test_load_configs_raises_error_for_unknown_variable_in_ini)
--
Traceback (most recent call last):
File "/<>/cliapp/settings_tests.py", line 451, in
test_load_configs_raises_error_for_unknown_variable_in_ini
self.assertRaises(
File "/usr/lib/python3.12/unittest/case.py", line 780, in assertRaises
return context.handle('assertRaises', args, kwargs)
File "/usr/lib/python3.12/unittest/case.py", line 238, in handle
callable_obj(*args, **kwargs)
File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object
Processed: ttconv doesn't run any tests during the build and as autopkg test
Processing control commands: > severity -1 serious Bug #1061853 [src:ttconv] ttconv fails its autopkg tests with Python 3.12 Severity set to 'serious' from 'important' -- 1061853: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061853 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1061736: marked as done (aubio ftbfs with Python 3.12 as the default)
Your message dated Wed, 07 Feb 2024 00:05:49 +
with message-id
and subject line Bug#1061736: fixed in aubio 0.4.9-4.4
has caused the Debian Bug report #1061736,
regarding aubio ftbfs with Python 3.12 as the default
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1061736: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061736
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:aubio
Version: 0.4.9-4.3
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12
With python3-defaults from experimental, the package fails to build:
[...]
debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
python3 ./waf configure --verbose --destdir=debian/tmp --prefix=/usr
--enable-fftw3f --libdir=/usr/lib/x86_64-linux-gnu
/<>/waflib/Utils.py:443: SyntaxWarning: invalid escape
sequence '\d'
return re.split('\d+$',s)[0]
/<>/waflib/ConfigSet.py:7: SyntaxWarning: invalid escape
sequence '\ '
re_imp=re.compile('^(#)*?([^#=]*?)\ =\ (.*?)$',re.M)
/<>/waflib/ansiterm.py:178: SyntaxWarning: invalid escape
sequence '\['
ansi_tokens=re.compile('(?:\x1b\[([0-9?;]*)([a-zA-Z])|([^\x1b]+))')
Traceback (most recent call last):
File "/<>/./waf", line 164, in
from waflib import Scripting
File "/<>/waflib/Scripting.py", line 7, in
from waflib import
Utils,Configure,Logs,Options,ConfigSet,Context,Errors,Build,Node
File "/<>/waflib/Configure.py", line 6, in
from waflib import ConfigSet,Utils,Options,Logs,Context,Build,Errors
File "/<>/waflib/Options.py", line 6, in
from waflib import Logs,Utils,Context,Errors
File "/<>/waflib/Context.py", line 5, in
import os,re,imp,sys
ModuleNotFoundError: No module named 'imp'
make[1]: *** [debian/rules:45: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary] Error 2
--- End Message ---
--- Begin Message ---
Source: aubio
Source-Version: 0.4.9-4.4
Done: Matthias Klose
We believe that the bug you reported is fixed in the latest version of
aubio, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1061...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Matthias Klose (supplier of updated aubio package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 07 Feb 2024 00:46:01 +0100
Source: aubio
Architecture: source
Version: 0.4.9-4.4
Distribution: unstable
Urgency: medium
Maintainer: Paul Brossier
Changed-By: Matthias Klose
Closes: 1061736
Changes:
aubio (0.4.9-4.4) unstable; urgency=medium
.
* Non-maintainer upload.
.
[ Vladimir Petko ]
* d/p/waflib-py312.patch: cherry-pick waf patch to resolve python 3.12
build failure due to imp module removal. Closes: #1061736.
Checksums-Sha1:
4756d28dfb1e3262ae44c433cb672f3bf360c316 2689 aubio_0.4.9-4.4.dsc
162333efbb6fe6c310e8aadda869499902c9dcc9 19752 aubio_0.4.9-4.4.debian.tar.xz
40d293db3d6b89771516bf7218304d5862db8699 8800 aubio_0.4.9-4.4_source.buildinfo
Checksums-Sha256:
5aa766ad3d1cbdd7141eea615d399ca10e43cd48e0a39ad8ffabd688245d14e1 2689
aubio_0.4.9-4.4.dsc
0a548843782fe1f383c8dbdf62f503844f4f14f1322306970493ae0916c05717 19752
aubio_0.4.9-4.4.debian.tar.xz
217111c1af0fc0be776909db27ac63a0b40f4ec5b572f9dcd5f660fd73f0925c 8800
aubio_0.4.9-4.4_source.buildinfo
Files:
a47a95a49007a5f4489fd528f977e13f 2689 sound optional aubio_0.4.9-4.4.dsc
29c76891877f77dec01fbec2ab8dce28 19752 sound optional
aubio_0.4.9-4.4.debian.tar.xz
c90547bc406c2faa791b87c2e8db134b 8800 sound optional
aubio_0.4.9-4.4_source.buildinfo
-BEGIN PGP SIGNATURE-
iQJEBAEBCgAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAmXCxYAQHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9fbEEAC/Pxbx5uCZtSNk5NhifujP6J8r+VWlfPOM
wLA8rB7nXyCkl11mvHMH/3xTuoZm4gaqVPjLDZoIaZP4ymr9sCMoo5RxI1ghwTbd
giQK1rYuRDIdzQ7xL54d/On+zPdFv5sol7b8pj42Kt0j25uvVijHz0pRCEofGZXK
ACvqH8G2+UYReR+OXY3gO6tq3j1suyyA497j00pu3YkQKoY6BBkr/C++0uLnG0WR
VwBqRV6NL4Uxb1kv8E8WAqjqpCJEdqeIUM2T0ABPHOuWCiH53qYSJa1roFSQkQ6t
FkADkjL42dYMCN6+yh2xx6SIXHbb2SYNONFcMe7osvC3GSP98Iibo3FjTLVlAobC
P2k+/f0gMakuL8HcCyiDVK6v4OD0BP85ILiUj+8BrBCL/jNfbBz/E5Q+3qgNLrZV
Bug#1060173: marked as done (ruby-hiredis FTBFS with hiredis 1.2.0-6)
Your message dated Tue, 06 Feb 2024 22:08:07 +
with message-id
and subject line Bug#1060173: fixed in ruby-hiredis 0.6.3-3
has caused the Debian Bug report #1060173,
regarding ruby-hiredis FTBFS with hiredis 1.2.0-6
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1060173: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060173
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: ruby-hiredis
Version: 0.6.3-2
Severity: serious
Tags: ftbfs trixie sid
https://buildd.debian.org/status/logs.php?pkg=ruby-hiredis=0.6.3-2%2Bb7
...
┌──┐
│ Run tests for ruby3.1 from debian/ruby-tests.rb │
└──┘
RUBYLIB=/<>/debian/ruby-hiredis/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/3.1.0:/<>/debian/ruby-hiredis/usr/lib/ruby/vendor_ruby:.
GEM_PATH=/<>/debian/ruby-hiredis/usr/share/rubygems-integration/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
ruby3.1 debian/ruby-tests.rb
Run options: --seed 8491
# Running:
..DEPRECATED: Use assert_nil if expecting nil from
/<>/test/reader_test.rb:34. This will fail in Minitest 6.
.DEPRECATED: Use assert_nil if expecting nil from
/<>/test/reader_test.rb:104. This will fail in Minitest 6.
./usr/lib/ruby/gems/3.1.0/gems/minitest-5.15.0/lib/minitest/assertions.rb:130:
[BUG] Segmentation fault at 0x00841f27
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu]
...
--- End Message ---
--- Begin Message ---
Source: ruby-hiredis
Source-Version: 0.6.3-3
Done: Lucas Kanashiro
We believe that the bug you reported is fixed in the latest version of
ruby-hiredis, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1060...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Lucas Kanashiro (supplier of updated ruby-hiredis
package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Tue, 06 Feb 2024 18:32:30 -0300
Source: ruby-hiredis
Architecture: source
Version: 0.6.3-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Team
Changed-By: Lucas Kanashiro
Closes: 1060173
Changes:
ruby-hiredis (0.6.3-3) unstable; urgency=medium
.
* Team upload.
.
[ Debian Janitor ]
* Use secure copyright file specification URI.
* Bump debhelper from old 11 to 12.
* Set debhelper-compat version in Build-Depends.
* Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
Repository-Browse.
* Update standards version to 4.5.0, no changes needed.
.
[ Cédric Boutillier ]
* [ci skip] Update team name
* [ci skip] Add .gitattributes to keep unwanted files out of the source
package
.
[ Debian Janitor ]
* Update watch file format version to 4.
* Update standards version to 4.5.1, no changes needed.
* Bump debhelper from old 12 to 13.
* Update standards version to 4.6.1, no changes needed.
* Remove constraints unnecessary since buster (oldstable)
.
[ Lucas Kanashiro ]
* Add patch to skip tests failing with hiredis 1.2.0 (Closes: #1060173)
* Declare compliance with Debian Policy 4.6.2
* d/control: depend on ${ruby:Depends} instead of the ruby interpreter
Checksums-Sha1:
728edc932ff573075c65b548327e146bed67279f 2082 ruby-hiredis_0.6.3-3.dsc
b1c0f57ed04f1dd6b21f5ad95096d108d0cc4fa8 6668
ruby-hiredis_0.6.3-3.debian.tar.xz
Checksums-Sha256:
85e3bf1fd9efed8bd1172b13b31fd1c8ffad676b0cf75fba7a662999365a8aa3 2082
ruby-hiredis_0.6.3-3.dsc
93f2822101558676fe75a59d333e58bcacb5c9245315fa0a05a88e95d82d409e 6668
ruby-hiredis_0.6.3-3.debian.tar.xz
Files:
dfff1e876b415d539fdda0c1daff82bc 2082 ruby optional ruby-hiredis_0.6.3-3.dsc
25f2978bd47b2508cd77a930a371edbf 6668 ruby optional
ruby-hiredis_0.6.3-3.debian.tar.xz
-BEGIN PGP SIGNATURE-
Bug#1058315: marked as done (python-sure: FTBFS: ERROR: Failure: ImportError (cannot import name 'assert_equals' from 'nose.tools' (/usr/lib/python3/dist-packages/nose/tools/__init__.py)))
Your message dated Wed, 7 Feb 2024 01:04:23 +0300
with message-id
and subject line Re: Bug#1058315: python3-nose: from nose.tools import
assert_equals, assert_raises FAILS
has caused the Debian Bug report #1058315,
regarding python-sure: FTBFS: ERROR: Failure: ImportError (cannot import name
'assert_equals' from 'nose.tools'
(/usr/lib/python3/dist-packages/nose/tools/__init__.py))
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1058315: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058315
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: python-sure
Version: 2.0.0-3
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231212 ftbfs-trixie
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> make[1]: pyversions: No such file or directory
> py3versions: no X-Python3-Version in control file, using supported versions
> set -x ; set -e ; for i in 3.12 3.11 ; do \
> python$i -m nose -v --exclude='.*test_context_is_not_optional.*' ; \
> done
> + set -e
> + python3.12 -m nose -v --exclude=.*test_context_is_not_optional.*
> nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$']
> nose.config: INFO: Excluding tests matching
> ['.*test_context_is_not_optional.*']
> nose.plugins.manager: DEBUG: Configuring plugins
> nose.plugins.cover: ERROR: Coverage not available: unable to import coverage
> module
> nose.plugins.manager: DEBUG: Plugins enabled: [ 0x7fc0489ee090>, 0x7fc048297650>, ]
> nose.core: DEBUG: configured Config(addPaths=True, args=(),
> configSection='nosetests', debug=None, debugLog=None, env={},
> exclude=[re.compile('.*test_context_is_not_optional.*')],
> files=['setup.cfg'], firstPackageWins=False, getTestCaseNamesCompat=False,
> ignoreFiles=[re.compile('^\\.'), re.compile('^_'),
> re.compile('^setup\\.py$')], ignoreFilesDefaultStrings=['^\\.', '^_',
> '^setup\\.py$'], include=None, includeExe=False, logStream=<_io.TextIOWrapper
> name='' mode='w' encoding='utf-8'>, loggingConfig=None,
> options= 'verbosity': 4, 'files': None, 'where': None, 'py3where': None, 'testMatch':
> '(?:^|[\\b_\\./-])[Tt]est', 'testNames': None, 'debug': None, 'debugLog':
> None, 'loggingConfig': None, 'ignoreFiles': [], 'exclude':
> ['.*test_context_is_not_optional.*'], 'include': [], 'stopOnError': True,
> 'addPaths': True, 'includeExe': False, 'traverseNamespace': False,
> 'firstPackageWins': False, 'byteCompile': True, 'rednose': True,
> 'rednose_color': 'auto', 'immediate': False, 'attr': None, 'eval_attr': None,
> 'capture': False, 'logcapture': False, 'logcapture_format': '%(name)s:
> %(levelname)s: %(message)s', 'logcapture_datefmt': None,
> 'logcapture_filters': None, 'logcapture_clear': False, 'logcapture_level':
> 'NOTSET', 'enable_plugin_coverage': True, 'cover_packages': ['sure'],
> 'cover_erase': None, 'cover_tests': None, 'cover_min_percentage': None,
> 'cover_inclusive': True, 'cover_html': None, 'cover_html_dir': 'cover',
> 'cover_branches': True, 'cover_xml': None, 'cover_xml_file': 'coverage.xml',
> 'debugBoth': False, 'debugFailures': False, 'debugErrors': False,
> 'noDeprecated': False, 'enable_plugin_doctest': None, 'doctest_tests': None,
> 'doctestExtension': None, 'doctest_result_var': None, 'doctestFixtures':
> None, 'doctestOptions': None, 'enable_plugin_isolation': None,
> 'detailedErrors': None, 'noSkip': False, 'enable_plugin_id': None,
> 'testIdFile': '.noseids', 'failed': False, 'multiprocess_workers': 0,
> 'multiprocess_timeout': 10, 'multiprocess_restartworker': False,
> 'enable_plugin_xunit': None, 'xunit_file': 'nosetests.xml',
> 'xunit_testsuite_name': 'nosetests', 'enable_plugin_allmodules': None,
> 'collect_only': None}>, parser= 0x7fc048233230>, parserClass=,
> plugins=,
> py3where=(), runOnInit=True, srcDirs=('lib', 'src'), stopOnError=True,
> stream=<_io.TextIOWrapper name='' mode='w' encoding='utf-8'>,
> testMatch=re.compile('(?:^|[\\b_\\./-])[Tt]est'),
> testMatchPat='(?:^|[\\b_\\./-])[Tt]est', testNames=[],
> traverseNamespace=False, verbosity=4, where=(), worker=False,
> workingDir='/<>')
> nose.importer: DEBUG: Add path /<>
> nose.core: DEBUG: test loader is 0x7fc0484f13a0>
> nose.core: DEBUG: defaultTest .
> nose.core: DEBUG: Test names are ['.']
> nose.core: DEBUG: createTests called with None
> nose.loader: DEBUG: load from . (None)
> nose.selector: DEBUG: Test name . resolved to file ., module None, call None
> nose.selector:
Bug#1063365: src:python-cryptography: unsatisfied build dependency in testing: librust-pyo3-0.19-dev
Jeremy, please have a look, thanks On Tue, Feb 6, 2024 at 3:39 PM Paul Gevers wrote: > > Source: python-cryptography > Version: 41.0.7-2 > Severity: serious > Tags: sid trixie > User: debian...@lists.debian.org > Usertags: edos-uninstallable > > Dear maintainer(s), > > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. To uphold our social contract, > Debian requires that packages can be rebuild from source in the suite > we are shipping them, so currently this is a serious issue with your > package in testing. > > Can you please investigate the situation and figure out how to resolve > it? Regularly, if the build dependency is available in unstable, > helping the maintainer of your Build-Depends to enable migration to > testing is a great way to solve the issue. If your build dependency is > gone from unstable and testing, you'll have to fix the build process > in some other way. > > Paul > > Note: this bug report was sent after some quick manual checks using a > template. Please reach out to me if you believe I made a mistake in my > process. > > [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Processed: Bug#1060173 marked as pending in ruby-hiredis
Processing control commands: > tag -1 pending Bug #1060173 [src:ruby-hiredis] ruby-hiredis FTBFS with hiredis 1.2.0-6 Added tag(s) pending. -- 1060173: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060173 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1060173: marked as pending in ruby-hiredis
Control: tag -1 pending Hello, Bug #1060173 in ruby-hiredis reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ruby-team/ruby-hiredis/-/commit/0323cc291be8092004645f6dd9d0bbc9e7b97f91 Add patch to skip tests failing with hiredis 1.2.0 (Closes: #1060173) (this message was generated automatically) -- Greetings https://bugs.debian.org/1060173
Processed: src:syncthing: fails to migrate to testing for too long: new Build-Depends not migrating
Processing control commands: > close -1 1.27.2~ds4-1 Bug #1063366 [src:syncthing] src:syncthing: fails to migrate to testing for too long: new Build-Depends not migrating Marked as fixed in versions syncthing/1.27.2~ds4-1. Bug #1063366 [src:syncthing] src:syncthing: fails to migrate to testing for too long: new Build-Depends not migrating Marked Bug as done -- 1063366: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063366 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063366: src:syncthing: fails to migrate to testing for too long: new Build-Depends not migrating
Source: syncthing Version: 1.19.2~ds1-3 Severity: serious Control: close -1 1.27.2~ds4-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:syncthing has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on a new package that needs manual actions before it can migrate. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=syncthing OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063365: src:python-cryptography: unsatisfied build dependency in testing: librust-pyo3-0.19-dev
Source: python-cryptography Version: 41.0.7-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: nvidia-graphics-drivers: autopkgtest needs update for new version of linux
Processing control commands: > affects -1 src:linux Bug #1063363 [src:nvidia-graphics-drivers] nvidia-graphics-drivers: autopkgtest needs update for new version of linux Added indication that 1063363 affects src:linux -- 1063363: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063363 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063363: nvidia-graphics-drivers: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers Version: 525.147.05-5 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers from testing525.147.05-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers/42760274/log.gz 810s # MODPOST /usr/src/modules/nvidia-kernel/Module.symvers 810sscripts/mod/modpost -M -m -o /usr/src/modules/nvidia-kernel/Module.symvers -T /usr/src/modules/nvidia-kernel/modules.order -i Module.symvers -e 811s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 811s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 811s make[6]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /usr/src/modules/nvidia-kernel/Module.symvers] Error 1 811s make[5]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:1890: modpost] Error 2 811s make[4]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:246: __sub-make] Error 2 811s make[4]: Leaving directory '/usr/src/linux-headers-6.6.15-cloud-amd64' 811s make[3]: *** [Makefile:246: __sub-make] Error 2 811s make[3]: Leaving directory '/usr/src/linux-headers-6.6.15-common' 811s make[2]: *** [Makefile:82: modules] Error 2 811s make[2]: Leaving directory '/usr/src/modules/nvidia-kernel' 811s make[1]: *** [debian/rules:39: binary-modules] Error 2 811s make[1]: Leaving directory '/usr/src/modules/nvidia-kernel' 811s make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2 811s tput: No value for $TERM and no -T specified 811s BUILD FAILED! 811s tput: No value for $TERM and no -T specified 811s See /var/cache/modass/nvidia-kernel-source.buildlog.6.6.15-cloud-amd64.1707198843 for details. 811s Build failed. Press Return to continue... 811s I: nvidia-kernel does not support the 6.6.15-rt-amd64 kernel (!CONFIG_PREEMPT_RT) 811s I: Summary: 811s I: FAIL nvidia-kernel 6.6.15-amd64 (7) 811s I: FAIL nvidia-kernel 6.6.15-cloud-amd64 (7) 811s I: SKIP nvidia-kernel 6.6.15-rt-amd64 (!CONFIG_PREEMPT_RT) 811s autopkgtest [05:58:24]: test m-a-autopkgtest OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: nvidia-cuda-samples: autopkgtest needs update for new version of linux
Processing control commands: > affects -1 src:linux Bug #1063364 [src:nvidia-cuda-samples] nvidia-cuda-samples: autopkgtest needs update for new version of linux Added indication that 1063364 affects src:linux -- 1063364: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063364 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063364: nvidia-cuda-samples: autopkgtest needs update for new version of linux
Source: nvidia-cuda-samples Version: 12.1~dfsg-1 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-cuda-samples fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-cuda-samplesfrom testing12.1~dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-cuda-samples/42760273/log.gz 1664s I: Testing binary package nvidia-fs-dkms 1664s I: Trying to install build dependency nvidia-current/525.147.05 for 6.6.15-amd64 1664s Sign command: /lib/modules/6.6.15-amd64/build/scripts/sign-file 1664s Signing key: /var/lib/dkms/mok.key 1664s Public certificate (MOK): /var/lib/dkms/mok.pub 1664s Certificate or key are missing, generating self signed certificate for MOK... 1664s Creating symlink /var/lib/dkms/nvidia-current/525.147.05/source -> /usr/src/nvidia-current-525.147.05 1664s 1664s Building module: 1665s Cleaning build area... 1686s env NV_VERBOSE=1 make -j64 modules KERNEL_UNAME=6.6.15-amd64..(bad exit status: 2) 1686s Error! Bad return status for module build on kernel: 6.6.15-amd64 (x86_64) 1686s Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more information. 1686s autopkgtest [06:12:31]: test dkms-autopkgtest-nvidia-fs OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: nvidia-graphics-drivers-tesla: autopkgtest needs update for new version of linux
Processing control commands: > affects -1 src:linux Bug #1063362 [src:nvidia-graphics-drivers-tesla] nvidia-graphics-drivers-tesla: autopkgtest needs update for new version of linux Added indication that 1063362 affects src:linux -- 1063362: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063362 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063362: nvidia-graphics-drivers-tesla: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers-tesla Version: 525.147.05-5 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers-tesla fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers-tesla from testing525.147.05-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers-tesla/42735533/log.gz 202s # MODPOST /usr/src/modules/nvidia-tesla-kernel/Module.symvers 202sscripts/mod/modpost -M -m -o /usr/src/modules/nvidia-tesla-kernel/Module.symvers -T /usr/src/modules/nvidia-tesla-kernel/modules.order -i Module.symvers -e 203s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 203s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 203s make[6]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /usr/src/modules/nvidia-tesla-kernel/Module.symvers] Error 1 203s make[5]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:1890: modpost] Error 2 203s make[4]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:246: __sub-make] Error 2 203s make[4]: Leaving directory '/usr/src/linux-headers-6.6.15-cloud-amd64' 203s make[3]: *** [Makefile:246: __sub-make] Error 2 203s make[3]: Leaving directory '/usr/src/linux-headers-6.6.15-common' 203s make[2]: *** [Makefile:82: modules] Error 2 203s make[2]: Leaving directory '/usr/src/modules/nvidia-tesla-kernel' 203s make[1]: *** [debian/rules:39: binary-modules] Error 2 203s make[1]: Leaving directory '/usr/src/modules/nvidia-tesla-kernel' 203s make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2 203s tput: No value for $TERM and no -T specified 203s BUILD FAILED! 203s tput: No value for $TERM and no -T specified 203s See /var/cache/modass/nvidia-tesla-kernel-source.buildlog.6.6.15-cloud-amd64.1707107102 for details. 203s Build failed. Press Return to continue... 203s I: nvidia-tesla-kernel does not support the 6.6.15-rt-amd64 kernel (!CONFIG_PREEMPT_RT) 203s I: Summary: 203s I: FAIL nvidia-tesla-kernel 6.6.15-amd64 (7) 203s I: FAIL nvidia-tesla-kernel 6.6.15-cloud-amd64 (7) 203s I: SKIP nvidia-tesla-kernel 6.6.15-rt-amd64 (!CONFIG_PREEMPT_RT) 203s autopkgtest [04:25:29]: test m-a-autopkgtest OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: nvidia-graphics-drivers-tesla-470: autopkgtest needs update for new version of linux
Processing control commands: > affects -1 src:linux Bug #1063361 [src:nvidia-graphics-drivers-tesla-470] nvidia-graphics-drivers-tesla-470: autopkgtest needs update for new version of linux Added indication that 1063361 affects src:linux -- 1063361: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063361 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063361: nvidia-graphics-drivers-tesla-470: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers-tesla-470 Version: 470.223.02-3 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers-tesla-470 fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers-tesla-470 from testing470.223.02-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers-tesla-470/42735534/log.gz 320s # MODPOST /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers 320sscripts/mod/modpost -M -m -o /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers -T /var/lib/dkms/nvidia-tesla-470/470.223.02/build/modules.order -i Module.symvers -e 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 320s make[4]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers] Error 1 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063359: gdb-mingw-w64: FTBFS on arm64 due to arch-specific build flag: -mbranch-protection=standard
Source: gdb-mingw-w64 Version: 13 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid trixie ftbfs patch User: debian-...@lists.debian.org Usertags: arm64 Hi, arm64 now has an architecture-specific flag among the default build flags: -mbranch-protection=standard. gdb-mingw-w64 calls dpkg-buildflags on the build system, which on arm64 looks like this: $ dpkg-buildflags --get CFLAGS -g -O2 -ffile-prefix-map=/tmp/gdb-mingw-w64-13=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard The output of the above command is then passed to the configure script of the various targets (i686-w64-mingw32 and x86_64-w64-mingw32), resulting in the following FTBFS on arm64: checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc-posix checking whether the C compiler works... no configure: error: in `/tmp/gdb-mingw-w64-13/build-gdbserver/i686-w64-mingw32/gnulib': configure: error: C compiler cannot create executables See `config.log' for more details And indeed config.log points out the issue: i686-w64-mingw32-gcc-posix: error: unrecognized command-line option '-mbranch-protection=standard' I propose in the attached patch to use DEB_HOST_ARCH and ensure that i686-specific flags are used when building for i686, ditto for amd64. Emanuele diff -Nru gdb-mingw-w64-13/debian/changelog gdb-mingw-w64-13+nmu1/debian/changelog --- gdb-mingw-w64-13/debian/changelog 2023-09-29 17:54:37.0 +0200 +++ gdb-mingw-w64-13+nmu1/debian/changelog 2024-02-06 20:23:38.0 +0100 @@ -1,3 +1,11 @@ +gdb-mingw-w64 (13+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use DEB_HOST_ARCH to avoid setting potentially arch-specific build flags. +Closes: -1. + + -- Emanuele Rocca Tue, 06 Feb 2024 20:23:38 +0100 + gdb-mingw-w64 (13) unstable; urgency=medium * Switch from the obsolete libncurses5-dev build-dependency to diff -Nru gdb-mingw-w64-13/debian/rules gdb-mingw-w64-13+nmu1/debian/rules --- gdb-mingw-w64-13/debian/rules 2023-09-29 13:47:46.0 +0200 +++ gdb-mingw-w64-13+nmu1/debian/rules 2024-02-06 20:23:38.0 +0100 @@ -69,6 +69,7 @@ override_dh_auto_configure-arch: unpack-stamp set -e; \ for target in $(targets); do \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ mkdir -p $(build_gdb_dir)/$$target; \ cd $(build_gdb_dir)/$$target; \ $(upstream_dir)/configure \ @@ -77,7 +78,7 @@ --with-system-readline --with-system-zlib \ --enable-tui --with-expat --with-python=python3 \ --target=$$target --disable-werror \ - $(shell $(dpkg_buildflags_arch) --export=cmdline); \ + $(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_arch) --export=cmdline); \ done # We're only interested in gdbserver; that also requires gnulib, libiberty, and gdbsupport @@ -85,6 +86,7 @@ override_dh_auto_configure-indep: unpack-stamp set -e; \ for target in $(targets); do \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ for project in $(gdbserver_projects); do \ mkdir -p $(build_gdbserver_dir)/$$target/$$project; \ cd $(build_gdbserver_dir)/$$target/$$project; \ @@ -93,22 +95,24 @@ --host=$$target --target=$$target \ CC=$$target-gcc-posix CXX=$$target-g++-posix \ --disable-werror \ -$(shell $(dpkg_buildflags_indep) --export=cmdline); \ +$(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_indep) --export=cmdline); \ done; \ done override_dh_auto_build-arch: set -e; \ for target in $(targets); do \ - $(shell $(dpkg_buildflags_arch) --export=sh); \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ + $(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_arch) --export=sh); \ dh_auto_build --parallel -B$(build_gdb_dir)/$$target -- V=1; \ done override_dh_auto_build-indep: set -e; \ for target in $(targets); do \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ for project in $(gdbserver_projects); do \ - $(shell $(dpkg_buildflags_indep) --export=sh); \ + $(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_indep) --export=sh); \ dh_auto_build --parallel -B$(build_gdbserver_dir)/$$target/$$project -- V=1; \ done; \ done
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Whilst I am not an expert on this transition or the abi-compliance-checker, a quick look at the logs[1] suggests this is a tool configuration issue and src:consolekit2 may not require t64 migration. Can you clarify? Thanks Mark [1] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libconsolekit-dev/time_t/log.txt
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Michael, On Tue, Jan 30, 2024 at 01:24:19AM +, mwhud...@debian.org wrote: > Source: consolekit2 > Version: 1.2.6-3 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t This patch appears to be broken and all the experimental builds FTBFS[1]. In addition, the bug severity is triggering autoremoval[2] That seems a sub-optimal combination. I am minded to reduce the bug severity. But I will wait for your response if you have a better suggestion. Thanks Mark [1] https://buildd.debian.org/status/package.php?p=consolekit2=experimental [2] https://udd.debian.org/cgi-bin/autoremovals.cgi
Bug#1063170: nettle: NMU diff for 64-bit time_t transition
On 2024-02-05 Niels Möller wrote: > Graham Inggs writes: >> we have identified nettle as a source package shipping runtime >> libraries whose ABI either is affected by the change in size of >> time_t, or could not be analyzed via abi-compliance-checker (and >> therefore to be on the safe side we assume is affected). [...] > However, this code is in the *libhogweed* so-file, so transitioning > *libnettle* is probably not needed. [...] The analysis looked at the headers and ... | In multi-library packages, there is no reliable way to map from a set of | headers in a dev package to specific shared libraries in a runtime library | package that's not additionally computationally prohibitive; we therefore | conservatively assume that if any headers from a source package show | time_t ABI changes, all the runtime library packages from the source | package are affected by the transition. cu Andreas
Bug#1062802: marked as done (libpam0t64: file loss during upgrade due to /usr-move DEP17)
Your message dated Tue, 06 Feb 2024 17:08:03 + with message-id and subject line Bug#1062802: fixed in pam 1.5.3-3 has caused the Debian Bug report #1062802, regarding libpam0t64: file loss during upgrade due to /usr-move DEP17 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1062802: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062802 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libpam0t64 Version: 1.5.3-2 Severity: serious Tags: patch Control: affects -1 + libpam0g User: helm...@debian.org Usertags: dep17p1 Hi Steve, pam also runs in to /usr-move breakage. This one looks fairly straight forward. I'm attaching a patch to avoid interfering with the time64 transition. As with others, the diversions shall be removed in forky. Helmut diff --minimal -Nru pam-1.5.3/debian/changelog pam-1.5.3/debian/changelog --- pam-1.5.3/debian/changelog 2024-02-02 19:27:45.0 +0100 +++ pam-1.5.3/debian/changelog 2024-02-03 12:18:52.0 +0100 @@ -1,3 +1,10 @@ +pam (1.5.3-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Mitigate /usr-move file loss. (Closes: #-1) + + -- Helmut Grohne Sat, 03 Feb 2024 12:18:52 +0100 + pam (1.5.3-2) experimental; urgency=medium * New Swedish Translations, Thanks Martin Bagge / brother, Closes: #1057775 diff --minimal -Nru pam-1.5.3/debian/clean pam-1.5.3/debian/clean --- pam-1.5.3/debian/clean 2023-09-15 19:17:35.0 +0200 +++ pam-1.5.3/debian/clean 2024-02-03 12:17:11.0 +0100 @@ -1 +1,3 @@ debian/local/pam_getenv.8 +debian/libpam0t64.preinst +debian/libpam0t64.postrm diff --minimal -Nru pam-1.5.3/debian/libpam0t64.postrm.in pam-1.5.3/debian/libpam0t64.postrm.in --- pam-1.5.3/debian/libpam0t64.postrm.in 1970-01-01 01:00:00.0 +0100 +++ pam-1.5.3/debian/libpam0t64.postrm.in 2024-02-03 12:18:52.0 +0100 @@ -0,0 +1,13 @@ +#!/bin/sh + +set -e + +if [ "$1" = remove ]; then + for file in libpam.so.0 libpam.so.0.85.1 libpam_misc.so.0 libpam_misc.so.0.82.1 libpamc.so.0 libpamc.so.0.82.1; do + dpkg-divert --package libpam0t64 --no-rename --remove --divert "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" "/lib/#DEB_HOST_MULTIARCH#/$file" + done +fi + +#DEBHELPER# + +exit 0 diff --minimal -Nru pam-1.5.3/debian/libpam0t64.preinst.in pam-1.5.3/debian/libpam0t64.preinst.in --- pam-1.5.3/debian/libpam0t64.preinst.in 1970-01-01 01:00:00.0 +0100 +++ pam-1.5.3/debian/libpam0t64.preinst.in 2024-02-03 12:18:52.0 +0100 @@ -0,0 +1,13 @@ +#!/bin/sh + +set -e + +if [ "$1" = install ]; then + for file in libpam.so.0 libpam.so.0.85.1 libpam_misc.so.0 libpam_misc.so.0.82.1 libpamc.so.0 libpamc.so.0.82.1; do + dpkg-divert --package libpam0t64 --no-rename --add --divert "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" "/lib/#DEB_HOST_MULTIARCH#/$file" + done +fi + +#DEBHELPER# + +exit 0 diff --minimal -Nru pam-1.5.3/debian/rules pam-1.5.3/debian/rules --- pam-1.5.3/debian/rules 2024-01-15 23:58:49.0 +0100 +++ pam-1.5.3/debian/rules 2024-02-03 12:18:50.0 +0100 @@ -76,3 +76,8 @@ override_dh_installchangelogs: dh_installchangelogs NEWS + +debian/%:debian/%.in + sed -e 's/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/g' $< > $@ + +execute_before_dh_installdeb:debian/libpam0t64.preinst debian/libpam0t64.postrm --- End Message --- --- Begin Message --- Source: pam Source-Version: 1.5.3-3 Done: Helmut Grohne We believe that the bug you reported is fixed in the latest version of pam, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1062...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Helmut Grohne (supplier of updated pam package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 03 Feb 2024 12:18:52 +0100 Source: pam Architecture: source Version: 1.5.3-3 Distribution: experimental Urgency: medium Maintainer: Sam Hartman Changed-By: Helmut Grohne Closes: 1062802 Changes: pam (1.5.3-3) experimental; urgency=medium . [ Helmut Grohne ] * Mitigate /usr-move file loss.
Bug#1062356: marked as done (adios2: flaky autopkgtest (host dependent): times out on big host)
Your message dated Tue, 06 Feb 2024 15:35:15 + with message-id and subject line Bug#1062356: fixed in adios2 2.9.2+dfsg1-9 has caused the Debian Bug report #1062356, regarding adios2: flaky autopkgtest (host dependent): times out on big host to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1062356: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062356 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: adios2 Version: 2.9.2+dfsg1-8 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails. The failures seem related to the host that runs the test. ci-worker13 is a beefy machine [1], while the other amd64 workers are much more moderate [2]. The tests that time out after 2:50 hours seem to all run on ci-worker13 (so, lots of CPU's and lots of RAM), while the other runs only take below 10 minutes (and seem to run on one of the other hosts. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [1] https://metal.equinix.com/product/servers/m3-large/ [2] https://aws.amazon.com/ec2/instance-types/m5/ OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Source: adios2 Source-Version: 2.9.2+dfsg1-9 Done: Drew Parsons We believe that the bug you reported is fixed in the latest version of adios2, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1062...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Drew Parsons (supplier of updated adios2 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 06 Feb 2024 13:36:22 +0100 Source: adios2 Architecture: source Version: 2.9.2+dfsg1-9 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Drew Parsons Closes: 1062356 Changes: adios2 (2.9.2+dfsg1-9) unstable; urgency=medium . * debian/tests: skip flakey test insituGlobalArraysReaderNxN_mpi on all arches. Closes: #1062356. Checksums-Sha1: 7564edf2777a0b1f88619e37502b63f0c4a07e4a 4706 adios2_2.9.2+dfsg1-9.dsc 02660f906c2f48d235120e942cb00d3b8196f30f 16292 adios2_2.9.2+dfsg1-9.debian.tar.xz Checksums-Sha256: 7da310be19c1257603dbbe46784db992a390d6274eb642bfda91efae951e0e7c 4706 adios2_2.9.2+dfsg1-9.dsc c3985bc53fdd73f61c15f9e18c7d19661494ff248e7d1e1ff0bbdc9048d35fed 16292 adios2_2.9.2+dfsg1-9.debian.tar.xz Files: ec825ad1057bfde0ed3b5dbf76717705 4706 libs optional adios2_2.9.2+dfsg1-9.dsc bcd3efc9b5bab04eb2bc63b020c98481 16292 libs optional adios2_2.9.2+dfsg1-9.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEI8mpPlhYGekSbQo2Vz7x5L1aAfoFAmXCRhAACgkQVz7x5L1a AfpNCxAAnMjEI7bhXpOmbeYxGJS1nY++zL6pSxaWw96N7ktuXlrULhtCObOSH8wI 2c3A0SCkRn2ZJm/LrronjBi7ncuTJMPdcydndNbmar54GL3aM2uvLseBFlaE/xzJ etix7MzAit2Qmy9ct8Gh9g/Cnejuwrey3tMh7EiDR2OdEacVo3U/koPnEht5tgwf krxOyxZMbb0aC5HA0mdDla2aLuASO0TVIgKjqKJkL2yEHP8NTe021RSE6K+72dqw jGryIPkSc6xhtr4WWNJHJuTSxZ1S5MaFukT+0sodbhR326SNfkfgx++kpEqDXVRX naUXJfkvg0lIcSCp5n6YcI8ASlwtslt33KQ2TeK1wdtiCF5QotPcI/tTTkXvPoB3 Hhiq4Y8nUpSouQUXT+jnNffhThAOT9PWMHuJGHklx7p67EhlPP6geqgt8yYHPbZu JV1sxO9j9CblBLkPAqzI8jhgzG/ttSfCYKsxSiXx2cHpUnqY83kka8xefCZsLGOc seyvHatvLynDYWkSCez+NSq0oJzwjts2Ssr18AcabkqhQp+Tz1abjkPnipQX4/3r SimETnQXFGucsEz40xUXHV+uGhuFYv3KecOpWF5R+q93nN5W/hOAVTbunCd/IEwN TUfj3UwLoSfyAuBiGC71cMP3+vA/JSAFhkbXJdLqQ0VMp5rJ2UE= =PV5Z -END PGP SIGNATURE End Message ---
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote: > Providing two APIs makes me quite uneasy due to having core components > that would behave differently from the rest of the distribution. It > sounds like something that will come back to bite for a long time. Can you elaborate? Keep in mind that for all the 64bit architectures, there is no abi difference as the symbol is only added for those architectures, that currently use a 32bit ino_t. > I checked on codesearch.d.n and there are very few users on this API; > actually, none I think. Per > https://codesearch.debian.net/search?q=matchpathcon_filespec_add=1=1 > - box64 mentions that API but the "code" is commented-out, > - busybox uses it in the "setfiles" applet which isn't built, > - android-platform-external-libselinux has it in headers but also has > its own implementation > > That should hopefully give more freedom although I'm not sure what would > be the preferred route. And here you are arguing that there are no practical users of the added symbol, so with luck, we'd be adding an unused symbol on armhf. With bad luck, we'd have some users and for those users we'd be ABI-incompatible with the rest of the world on armhf. Helmut
Processed: block 1058317 with 1063345
Processing commands for cont...@bugs.debian.org:
> block 1058317 with 1063345
Bug #1058317 [src:celery] celery: FTBFS: dh_auto_test: error: pybuild --test
--test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
1058317 was not blocked by any bugs.
1058317 was not blocking any bugs.
Added blocking bug(s) of 1058317: 1063345
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1058317: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058317
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1061972: gap: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote: > thanks for the heads-up! > The same debdiff should apply to the version in unstable (4.12.1). > We'll make sure to NMU the version from unstable. > > Waiting for libgap.so.9 would also be an option, if timing works out. Fortunately libgap.so.9 was prereleased today. Would that mess anything if I upload it to experimental ? I expect not. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1044055: marked as done (mirtop: test failure with pandas 2.0)
Your message dated Tue, 6 Feb 2024 13:52:03 +0100 with message-id and subject line Re-opening was wrong! has caused the Debian Bug report #1044055, regarding mirtop: test failure with pandas 2.0 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1044055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044055 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:mirtop Version: 0.4.25-3 Control: block 1043240 by -1 mirtop fails its autopkgtest with pandas 2.0, currently in experimental. Log: https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mirtop/36575823/log.gz A common source of failures is that pandas.util.testing has been renamed to pandas.testing. Both names were available in all 1.x versions (and hence in Debian stable and oldstable), so Debian packages that were using this can immediately switch unconditionally. --- End Message --- --- Begin Message --- closing again -- http://fam-tille.de--- End Message ---
Processed: Reopen
Processing control commands:
> reopen -1
Bug #1044055 {Done: Nilesh Patra } [src:mirtop] mirtop: test
failure with pandas 2.0
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions mirtop/0.4.25-5.
--
1044055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044055
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1044055: Reopen
Control: reopen -1 The issue is not closed by latest upload -- http://fam-tille.de
Bug#1062356: adios2: flaky autopkgtest (host dependent): times out on big host
Source: adios2 Followup-For: Bug #1062356 The flakey test is adios2-mpi-examples. debian/tests is building and running them manually, and running on only 3 processors (mpirun -n 3) So the problem can't be overload of the machine. I'll just skip insituGlobalArraysReaderNxN_mpi. For reference, upstream is making some changes to make it more reliable to run tests against the installed library, https://github.com/ornladios/ADIOS2/pull/3906 also https://github.com/ornladios/ADIOS2/pull/3820 Not certain that that directly makes insituGlobalArraysReaderNxN_mpi more reliable though.
Processed: fix bug metadata
Processing commands for cont...@bugs.debian.org:
> # More affected packages discovered for meson bug
> affects 1060838 + src:libdex src:parlatype
Bug #1060838 [meson] meson: should use the host gobject-introspection-1.0.pc
for looking up g-ir-scanner
Added indication that 1060838 affects src:libdex and src:parlatype
> # Reassigned to nose, but affects not added
> affects 1058315 + src:python-sure
Bug #1058315 [python3-nose] python-sure: FTBFS: ERROR: Failure: ImportError
(cannot import name 'assert_equals' from 'nose.tools'
(/usr/lib/python3/dist-packages/nose/tools/__init__.py))
Added indication that 1058315 affects src:python-sure
> # Fix affects
> affects 1058327 - python-limits
Bug #1058327 [python3-protobuf] python-limits: FTBFS: dh_auto_test: error:
pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit
code 13
Removed indication that 1058327 affects python-limits
> affects 1058327 + src:python-limits
Bug #1058327 [python3-protobuf] python-limits: FTBFS: dh_auto_test: error:
pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit
code 13
Added indication that 1058327 affects src:python-limits
> # Bug was cloned. The clone is not a ftbfs bug
> tags 1058335 - ftbfs
Bug #1058335 [pyflakes] python-apt: FTBFS: AssertionError: pyflakes failed
with: 1
Removed tag(s) ftbfs.
> # Reassign from binary to source
> reassign 1056253 src:rust-ripasso-cursive
Bug #1056253 [rust-ripasso-cursive] rust-ripasso-cursive - FTBFS with
rust-ripasso 0.6.4
Bug reassigned from package 'rust-ripasso-cursive' to
'src:rust-ripasso-cursive'.
No longer marked as found in versions 0.6.1-1.
Ignoring request to alter fixed versions of bug #1056253 to the same values
previously set
> # Restore versions
> found 1056253 rust-ripasso-cursive/0.6.1-1
Bug #1056253 [src:rust-ripasso-cursive] rust-ripasso-cursive - FTBFS with
rust-ripasso 0.6.4
Marked as found in versions rust-ripasso-cursive/0.6.1-1.
> # Fix affects
> affects 1050676 - enblend-enfuse
Bug #1050676 [graphviz] enblend-enfuse: FTBFS: dot: maze.c:311: chkSgraph:
Assertion `np->cells[0]' failed.
Removed indication that 1050676 affects enblend-enfuse
> affects 1050676 + src:enblend-enfuse
Bug #1050676 [graphviz] enblend-enfuse: FTBFS: dot: maze.c:311: chkSgraph:
Assertion `np->cells[0]' failed.
Added indication that 1050676 affects src:enblend-enfuse
> # It's not gdb that ftbfs
> reassign 1043445 gdb
Bug #1043445 [src:gdb] gdb-source should be Multi-Arch: foreign (I think)
Bug reassigned from package 'src:gdb' to 'gdb'.
Ignoring request to alter found versions of bug #1043445 to the same values
previously set
Ignoring request to alter fixed versions of bug #1043445 to the same values
previously set
> # More affects
> affects 1040477 + src:netavark src:rust-bkt
Bug #1040477 [librust-syn-1-dev] librust-syn-1-dev fails to coinstall
Added indication that 1040477 affects src:netavark and src:rust-bkt
> # Failed to set usertag
> user debian-cr...@lists.debian.org
Setting user to debian-cr...@lists.debian.org (was hel...@subdivi.de).
> usertags 1034292 + ftcbfs
There were no usertags set.
Usertags are now: ftcbfs.
> # More affects
> affects 1034579 + src:dbus-cpp
Bug #1034579 [cmake-extras] GMock fails to pass a cross compiler again
Added indication that 1034579 affects src:dbus-cpp
> # Reassign to source
> reassign 1029189 src:kpatch
Bug #1029189 [kpatch] kpatch: FTBFS with shellcheck 0.9.0
Bug reassigned from package 'kpatch' to 'src:kpatch'.
No longer marked as found in versions kpatch/0.9.7-2.
Ignoring request to alter fixed versions of bug #1029189 to the same values
previously set
> # Restore versions
> found 1029189 kpatch/0.9.7-2
Bug #1029189 [src:kpatch] kpatch: FTBFS with shellcheck 0.9.0
Marked as found in versions kpatch/0.9.7-2.
> # Bug has a fixed version, but is still considered open.
> close 1027657
Bug #1027657 [src:mk-configure] libmaa: FTBFS: dh_auto_build: error: exec (for
cmd: mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info
SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu
LIBEXECDIR=/usr/lib/x86_64-linux-gnu) failed: No such file or directory
Bug #1027515 [src:mk-configure] paexec: FTBFS: dh_auto_build: error: exec (for
cmd: mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info
SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu
LIBEXECDIR=/usr/lib/x86_64-linux-gnu) failed: No such file or directory
Bug #1027528 [src:mk-configure] runawk: FTBFS: dh_auto_build: error: exec (for
cmd: mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info
SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu
LIBEXECDIR=/usr/lib/x86_64-linux-gnu) failed: No such file or directory
Bug #1027538 [src:mk-configure] herisvm: FTBFS: dh_auto_build: error: exec (for
cmd: mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info
SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu
LIBEXECDIR=/usr/lib/x86_64-linux-gnu) failed: No such file or
Bug#1063265: Bug#1061645: poco: NMU diff for 64-bit time_t transition
Hi Bastian On 2024-02-06 12:34:32 +0100, Bastian Germann wrote: > Hi Lucas, > > Please use the latest experimental QA upload for the 64-bit time_t transition > instead of uploading your NMU. > The other planned transition is documented in #1061645. > All library package names are SO-bumped, which should be enough to fulfill > your intended change. > This is a cross-posting to ensure the release team is aware of that. Please beaware that we are doing time_t first and pause all other transitions until that is complete. We will process the poco transition independently after time_t is done. Please do not entangle them. Cheers -- Sebastian Ramacher
Bug#1062356: adios2: flaky autopkgtest (host dependent): times out on big host
Source: adios2 Followup-For: Bug #1062356 Can't be quite as simple as just the host machine. https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41403641/log.gz completed in 9 minutes, while https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41496866/log.gz failed with timeout. But that was ci-worker13 in both cases. Maybe it's a race condition. Might be simplest to just skip insituGlobalArraysReaderNxN_mpi though I can also review how many CPUs are invoked by the test. Usually safer not to run tests on all 64 available cpus, for instance, if there are that many on the machine.
Bug#1063265: poco: NMU diff for 64-bit time_t transition
Hi Lucas, Please use the latest experimental QA upload for the 64-bit time_t transition instead of uploading your NMU. The other planned transition is documented in #1061645. All library package names are SO-bumped, which should be enough to fulfill your intended change. This is a cross-posting to ensure the release team is aware of that. Thanks, Bastian
Processed: Updating bug ownership
Processing commands for cont...@bugs.debian.org:
> owner 1060933 Nick Morrott
Bug #1060933 {Done: Nick Morrott } [src:valinor] valinor:
FTBFS: AssertionError: 1 != 0
Owner recorded as Nick Morrott .
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1060933: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060933
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Output from gdb (first try with doomsday-dbgsym, doomsday-common-dbgsym, libsdl2-2.0-0-dbgsym) can be found in attachment. Tell me to install more debug packages. ylb doomsday_gdb_output.txt.7z Description: application/7z-compressed
Bug#1061866: adns: NMU diff for 64-bit time_t transition
Steve Langasek writes ("Bug#1061866: adns: NMU diff for 64-bit time_t
transition"):
> Apologies, an oversight in the conversion script caused us to fail to update
> strict versioned dependencies on the previous package name. Please find
> attached a fixed patch.
Hi. Thanks for this project.
I have just got an alert saying adns is now scheduled for autoremoval
due to #1061866.
My understanding was that you were intending to NMU to unstable after
"several days". I have been holding off making an upload myself so as
not to interfere.
FTR, anything which causes autoremoval to be scheduled will attract a
lot of attention, because removal can be a significant setback.
Maintainers such as myself will want to act ASAP to resolve the
situation.
Please advise.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1063333: cardpeek: Built version of cardpeek in Sid use lua5.3 and breaks lua's scripts. Need lua5.2 only.
Package: cardpeek Version: 0.8.4-pacstall2 Severity: grave Tags: newcomer Justification: renders package unusable X-Debbugs-Cc: xdav...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installed cardpeek from sid, try to use tachograph.lua script, give error line 335 * What exactly did you do (or not do) that was effective (or ineffective)? use apt-rdepend and see that cardpeek is built with lua5.3 on debian Sid Here, this is my newly built package. Built with lua5.2 works This package is very important for truck driver and need to work (there is no alternative on linux) Here my pacstall script if it can help : https://raw.githubusercontent.com/Xdavius/vortex-linux/main/vortex-repository/pacscript/packages/cardpeek/cardpeek.pacscript Regards (Sorry for my bad english) -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.3-tkg-eevdf (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cardpeek depends on: ii curl 8.6.0-1 ii libgtk-3-dev 3.24.41-1 ii liblua5.2-0 5.2.4-3 ii libpcsclite-dev 2.0.1-1 cardpeek recommends no packages. cardpeek suggests no packages. -- no debconf information
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
On Tue, 06 Feb 2024 at 10:20:46 +0100, Yves Le Berre wrote: > I am not familiarized with building debian debug packages. > do doomsday and libsdl2 packages need to be rebuilt or do they exist > somewhere ? Their detached debug symbols should already be provided in Debian, so you don't need to rebuild anything. You can either use export DEBUGINFOD_URLS="https://debuginfod.debian.net; (that's the easier option), or add these apt sources: deb http://deb.debian.org/debian-debug/ testing-debug main deb http://deb.debian.org/debian-debug/ unstable-debug main and install the relevant -dbgsym packages: - doomsday-dbgsym - libsdl2-2.0-0-dbgsym - libx11-6-dbgsym - libxcb1-dbgsym - libxext6-dbgsym - libxrandr2-dbgsym - probably others, but I can't tell which ones without seeing a backtrace with partial symbols Thanks, smcv
Processed: tagging 1062484, tagging 1063053
Processing commands for cont...@bugs.debian.org: > tags 1062484 - pending Bug #1062484 [src:libnma] libnma: NMU diff for 64-bit time_t transition Removed tag(s) pending. > tags 1063053 - pending Bug #1063053 [src:volume-key] volume-key: NMU diff for 64-bit time_t transition Removed tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 1062484: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062484 1063053: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063053 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Helmut, Thanks for identifying and raising this issue. After Graham mentioned this to me, I also looked at the reports and came to the same conclusion: the change is actually LFS due to ino_t in matchpathcon_filespec_add(). Providing two APIs makes me quite uneasy due to having core components that would behave differently from the rest of the distribution. It sounds like something that will come back to bite for a long time. I checked on codesearch.d.n and there are very few users on this API; actually, none I think. Per https://codesearch.debian.net/search?q=matchpathcon_filespec_add=1=1 - box64 mentions that API but the "code" is commented-out, - busybox uses it in the "setfiles" applet which isn't built, - android-platform-external-libselinux has it in headers but also has its own implementation That should hopefully give more freedom although I'm not sure what would be the preferred route. -- Adrien
Bug#1063298: xrootd: NMU diff for 64-bit time_t transition
Hi! The proposed change is incomplete, and the build failed on some architectures. You need to update debian/rules due to the changes package names: Line 31 must change from N = -Nlibxrdec1 to N = -Nlibxrdec1t64 Regards, Mattias (package maintainer) signature.asc Description: This is a digitally signed message part
Processed: tags 1063261 -pending
Processing commands for cont...@bugs.debian.org:
> tags 1063261 -pending
Bug #1063261 {Done: Luca Boccassi } [src:xdp-tools]
xdp-tools: NMU diff for 64-bit time_t transition
Removed tag(s) pending.
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
1063261: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063261
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition
Re: Steve Langasek > If you as maintainer want to close this bug report (indicating that no > transition is required) or un-tag it 'pending' (indicating that a transition > may be required but the patch is not ready to upload), and accept any > fallout if it turns out this is incorrect, that will mark it so that we will > not include it in NMUs to unstable. Is there any writeup on what verification steps I have to do to do that assessment? All I could find so far are very long lists of packages without any explanation, and a wiki page that outlines a plan, but doesn't have any instructions for maintainers. Christoph
Bug#1063323: libiw30t64: file loss due to /usr-move (DEP17)
On Tue, Feb 06, 2024 at 07:42:49AM +0100, Helmut Grohne wrote:
> I'm attaching a patch for your convenience. I consider that libiw30 is
> not as central as other packages and hence propose employing Conflicts
> here. Conflicts allow removing the protective diversion in trixie's
> postinst rather than forky's postinst already.
Steve made me aware that such Conflicts and Breaks should be versioned
as they may otherwise interact with Provides and multiarch. Updated
patch attached.
Helmut
diff --minimal -Nru wireless-tools-30~pre9/debian/changelog
wireless-tools-30~pre9/debian/changelog
--- wireless-tools-30~pre9/debian/changelog 2024-02-04 21:34:45.0
+0100
+++ wireless-tools-30~pre9/debian/changelog 2024-02-06 07:33:48.0
+0100
@@ -1,3 +1,9 @@
+wireless-tools (30~pre9-16.1~exp2) UNRELEASED; urgency=medium
+
+ * Fix /usr-move file loss. (Closes: #-1)
+
+ -- Helmut Grohne Tue, 06 Feb 2024 07:33:48 +0100
+
wireless-tools (30~pre9-16.1~exp1) experimental; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru wireless-tools-30~pre9/debian/clean
wireless-tools-30~pre9/debian/clean
--- wireless-tools-30~pre9/debian/clean 1970-01-01 01:00:00.0 +0100
+++ wireless-tools-30~pre9/debian/clean 2024-02-06 07:33:30.0 +0100
@@ -0,0 +1,2 @@
+debian/libiw30t64.preinst
+debian/libiw30t64.postinst
diff --minimal -Nru wireless-tools-30~pre9/debian/control
wireless-tools-30~pre9/debian/control
--- wireless-tools-30~pre9/debian/control 2024-02-04 21:34:45.0
+0100
+++ wireless-tools-30~pre9/debian/control 2024-02-06 07:31:36.0
+0100
@@ -31,8 +31,7 @@
Package: libiw30t64
Provides: ${t64:Provides}
-Replaces: libiw30
-Breaks: libiw30 (<< ${source:Version})
+Conflicts: libiw30 (<< ${source:Version})
Section: libs
Architecture: linux-any
Multi-Arch: same
diff --minimal -Nru wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides
wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides
--- wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides 2024-02-04
21:34:45.0 +0100
+++ wireless-tools-30~pre9/debian/libiw30t64.lintian-overrides 2024-02-06
07:33:48.0 +0100
@@ -1 +1,5 @@
libiw30t64: package-name-doesnt-match-sonames libiw30
+# begin-remove-after: released:trixie
+# DEP17 protective diversion
+diversion-for-unknown-file lib/x86_64-linux-gnu/libiw.so.30 [preinst:*]
+# end-remove-after
diff --minimal -Nru wireless-tools-30~pre9/debian/libiw30t64.postinst.in
wireless-tools-30~pre9/debian/libiw30t64.postinst.in
--- wireless-tools-30~pre9/debian/libiw30t64.postinst.in1970-01-01
01:00:00.0 +0100
+++ wireless-tools-30~pre9/debian/libiw30t64.postinst.in2024-02-06
07:29:28.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if [ "$1" = configure ]; then
+ dpkg-divert --package libiw30t64 --no-rename --remove --divert
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30.usr-is-merged"
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30"
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru wireless-tools-30~pre9/debian/libiw30t64.preinst.in
wireless-tools-30~pre9/debian/libiw30t64.preinst.in
--- wireless-tools-30~pre9/debian/libiw30t64.preinst.in 1970-01-01
01:00:00.0 +0100
+++ wireless-tools-30~pre9/debian/libiw30t64.preinst.in 2024-02-06
07:29:30.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:trixie
+if [ "$1" = install ]; then
+ dpkg-divert --package libiw30t64 --no-rename --add --divert
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30.usr-is-merged"
"/lib/#DEB_HOST_MULTIARCH#/libiw.so.30"
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff --minimal -Nru wireless-tools-30~pre9/debian/rules
wireless-tools-30~pre9/debian/rules
--- wireless-tools-30~pre9/debian/rules 2023-11-28 01:03:11.0 +0100
+++ wireless-tools-30~pre9/debian/rules 2024-02-06 07:33:39.0 +0100
@@ -19,3 +19,8 @@
override_dh_installudev:
dh_installudev --priority=19
+
+debian/%:debian/%.in
+ sed -e 's/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/g' $< > $@
+
+execute_before_dh_installdeb:debian/libiw30t64.preinst
debian/libiw30t64.postinst
Processed: libselinux1t64: /usr-move caused file loss (DEP17)
Processing control commands: > affects -1 + libselinux1 Bug #1063328 [libselinux1t64] libselinux1t64: /usr-move caused file loss (DEP17) Added indication that 1063328 affects libselinux1 -- 1063328: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063328 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Package: libselinux1t64 Version: 3.5-2.1~exp1 Severity: grave X-Debbugs-Cc: vor...@debian.org, debian-de...@lists.debian.org Hi, I was looking into performing an upgrade test of libselinux1 with piuparts and that didn't go well. I spare you the piuparts stuff and go into crafting a minimal reproducer using mmdebstrap: mmdebstrap --variant=apt unstable /dev/null "deb http://deb.debian.org/debian unstable main" "deb http://deb.debian.org/debian experimental main" --chrooted-customize-hook="apt-get -y install libselinux1t64" This looks fairly innocuous. We create a minimal sid chroot and install libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks that it would be a good idea to avoid coinstalling breaking packages and first removes libselinux1 before proceeding to install libselinux1t64. Unfortunately, libselinux1 is transitively essential and dpkg links it, so this is what you get: | Reading package lists... Done | Building dependency tree... Done | The following packages will be REMOVED: | libselinux1 | The following NEW packages will be installed: | libselinux1t64 | 0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded. | Need to get 75.2 kB of archives. | After this operation, 4096 B of additional disk space will be used. | Get:1 http://deb.debian.org/debian experimental/main amd64 libselinux1t64 amd64 3.5-2.1~exp1 [75.2 kB] | Fetched 75.2 kB in 0s (6067 kB/s) | debconf: delaying package configuration, since apt-utils is not installed | dpkg: libselinux1:amd64: dependency problems, but removing anyway as you requested: | util-linux depends on libselinux1 (>= 3.1~). | tar depends on libselinux1 (>= 3.1~). | sed depends on libselinux1 (>= 3.1~). | libpam-modules-bin depends on libselinux1 (>= 3.1~). | libpam-modules:amd64 depends on libselinux1 (>= 3.1~). | libmount1:amd64 depends on libselinux1 (>= 3.1~). | findutils depends on libselinux1 (>= 3.1~). | dpkg depends on libselinux1 (>= 3.1~). | coreutils depends on libselinux1 (>= 3.1~). | base-passwd depends on libselinux1 (>= 3.1~). | | (Reading database ... 6230 files and directories currently installed.) | Removing libselinux1:amd64 (3.5-2) ... | /usr/bin/dpkg: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory | E: Sub-process /usr/bin/dpkg returned an error code (127) At that point stuff is fairly broken and we cannot easily recover as both dpkg and tar are now broken. This is pretty bad. To make matters worse, the situation arises from the combination of Breaks + Provides and there is nothing libselinux1t64 could do in maintainer scripts to prevent this from happening, because no libselinux1t64 maintainer script has been run by the time damage has happened. I also looked into whether I could reproduce a similar failure with other packages such as libpam0t64 or libaudit1, but in no other case, I was able to construct a comparable outcome. I also looked into why libselinux was being time-bumped. Do I understand correctly that libselinux is entirely unaffected by time64? https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libselinux1-dev/lfs_to_time_t/compat_report.html It still is affected by LFS due to using ino_t in the public ABI of matchpathcon_filespec_add: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libselinux1-dev/base_to_lfs/compat_report.html Since we also complete the LFS transition here, not bumping it would result in an ABI break regarding this symbol. If we were to opt libselinux out of the LFS transition (e.g. by removing the flags in debian/rules), then other packages being rebuilt against libselinux-dev with these flags enabled would be ABI-incompatible though. An option I see here is to provide ABI-duality for libselinux: -extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file); +typedef unsigned long libselinux_ino_t; +typedef uint64_t libselinux_ino64_t; +extern int matchpathcon_filespec_add(libselinux_ino_t ino, int specind, const char *file); +#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 && sizeof(unsigned long) < 8 +extern int matchpathcon_filespec_add64(libselinux_ino64_t ino, int specind, const char *file); +#define matchpathcon_filespec_add matchpathcon_filespec_add64 +#endif Looking at the implementation, it would be fairly possible to implement this. Of course, doing this comes at its own cost: We are extending the libselinux1 ABI in a Debian-specific way and thus programs built on Debian will not run on non-Debian. Another option of course is doing a proper soname bump of libselinux1 to a Debian-specific soname. I really hope, I am missing something. Helmut
Bug#1063328: libselinux1t64: /usr-move caused file loss (DEP17)
Package: libselinux1t64 Version: 3.5-2.1~exp1 Severity: serious Tags: patch User: helm...@debian.org Usertags: dep17p1 Control: affects -1 + libselinux1 X-Debbugs-Cc: vor...@debian.org Hi, The time64 bump for libselinux1 also causes a /usr-move file loss. Since it is essential, we cannot use Conflicts and hence the protective diversion has to persist into trixie. I'm attaching a patch for your convenience. I note that I could *not* test this patch using piuparts. I am filing a separate issue about that problem. Helmut diff --minimal -Nru libselinux-3.5/debian/changelog libselinux-3.5/debian/changelog --- libselinux-3.5/debian/changelog 2024-02-05 09:25:54.0 +0100 +++ libselinux-3.5/debian/changelog 2024-02-06 08:49:30.0 +0100 @@ -1,3 +1,10 @@ +libselinux (3.5-2.1~exp1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add DEP17 protective diversion for /usr-move file loss. (Closes: #-1) + + -- Helmut Grohne Tue, 06 Feb 2024 08:49:30 +0100 + libselinux (3.5-2.1~exp1) experimental; urgency=medium * Non-maintainer upload. diff --minimal -Nru libselinux-3.5/debian/clean libselinux-3.5/debian/clean --- libselinux-3.5/debian/clean 1970-01-01 01:00:00.0 +0100 +++ libselinux-3.5/debian/clean 2024-02-06 08:45:34.0 +0100 @@ -0,0 +1,2 @@ +debian/libselinux1t64.preinst +debian/libselinux1t64.postrm diff --minimal -Nru libselinux-3.5/debian/libselinux1t64.lintian-overrides libselinux-3.5/debian/libselinux1t64.lintian-overrides --- libselinux-3.5/debian/libselinux1t64.lintian-overrides 2024-02-05 09:25:54.0 +0100 +++ libselinux-3.5/debian/libselinux1t64.lintian-overrides 2024-02-06 08:49:30.0 +0100 @@ -1 +1,2 @@ libselinux1t64: package-name-doesnt-match-sonames libselinux1 +diversion-for-unknown-file lib/x86_64-linux-gnu/libselinux.so.1 [preinst:*] diff --minimal -Nru libselinux-3.5/debian/libselinux1t64.postrm.in libselinux-3.5/debian/libselinux1t64.postrm.in --- libselinux-3.5/debian/libselinux1t64.postrm.in 1970-01-01 01:00:00.0 +0100 +++ libselinux-3.5/debian/libselinux1t64.postrm.in 2024-02-06 08:48:09.0 +0100 @@ -0,0 +1,11 @@ +#!/bin/sh + +set -e + +if [ "$1" = remove ]; then + dpkg-divert --package libselinux1t64 --no-rename --remove --divert "/lib/#DEB_HOST_MULTIARCH#/libselinux.so.1.usr-is-merged" "/lib/#DEB_HOST_MULTIARCH#/libselinux.so.1" +fi + +#DEBHELPER# + +exit 0 diff --minimal -Nru libselinux-3.5/debian/libselinux1t64.preinst.in libselinux-3.5/debian/libselinux1t64.preinst.in --- libselinux-3.5/debian/libselinux1t64.preinst.in 1970-01-01 01:00:00.0 +0100 +++ libselinux-3.5/debian/libselinux1t64.preinst.in 2024-02-06 08:48:39.0 +0100 @@ -0,0 +1,12 @@ +#!/bin/sh + +set -e + +if [ "$1" = install ]; then + # This DEP17 protective diversion should be removed after trixie is released. + dpkg-divert --package libselinux1t64 --no-rename --add --divert "/lib/#DEB_HOST_MULTIARCH#/libselinux.so.1.usr-is-merged" "/lib/#DEB_HOST_MULTIARCH#/libselinux.so.1" +fi + +#DEBHELPER# + +exit 0 diff --minimal -Nru libselinux-3.5/debian/rules libselinux-3.5/debian/rules --- libselinux-3.5/debian/rules 2024-02-05 09:25:54.0 +0100 +++ libselinux-3.5/debian/rules 2024-02-06 08:49:30.0 +0100 @@ -97,3 +97,8 @@ override_dh_makeshlibs: dh_makeshlibs -plibselinux1t64 --add-udeb="libselinux1-udeb" -V dh_makeshlibs --remaining-packages + +debian/%:debian/%.in + sed 's/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/g' $< > $@ + +execute_before_dh_installdeb:debian/libselinux1t64.preinst debian/libselinux1t64.postrm
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Sorry, your answer on Sun, 4 Feb 2024 12:31:35 + was marked 'spam' by my provider, so i didn't notice it until now. Here are some informations about my environment : System: Host: jupiter Kernel: 6.6.13-amd64 arch: x86_64 bits: 64 Desktop: Xfce v: 4.18.1 Distro: Debian GNU/Linux trixie/sid CPU: Info: 6-core model: AMD Ryzen 5 2600X bits: 64 type: MT MCP cache: L2: 3 MiB Graphics: Device-1: NVIDIA TU116 [GeForce GTX 1660] driver: nvidia v: 525.147.05 Display: x11 server: X.Org v: 21.1.11 driver: X: loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia resolution: 1920x1080~60Hz API: EGL v: 1.5 drivers: nvidia,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.6.0 vendor: nvidia v: 525.147.05 renderer: NVIDIA GeForce GTX 1660/PCIe/SSE2 I use alternatively compiz and xfwm4 as WM and compositor. Crash was in compiz session. I am not familiarized with building debian debug packages. do doomsday and libsdl2 packages need to be rebuilt or do they exist somewhere ? ylb
Bug#1061531: marked as done (sugar: Stop using webkit2gtk 4.0)
Your message dated Tue, 06 Feb 2024 09:25:22 + with message-id and subject line Bug#1061531: fixed in sugar 0.121-1 has caused the Debian Bug report #1061531, regarding sugar: Stop using webkit2gtk 4.0 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1061531: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061531 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: sugar Version: 0.120-1 Severity: serious Tags: trixie sid User: pkg-webkit-maintain...@lists.alioth.debian.org Usertags: webkit-4.0 The webkit2gtk maintainers intend to stop building the 4.0 API soon. Please switch to using the 4.1 API which is the same as the 4.0 API except that it uses libsoup3 instead of libsoup2.4. There is some documentation and many examples of libsoup2.4 porting at https://gitlab.gnome.org/GNOME/libsoup/-/issues/218 By the way, it is not possible to use libsoup2.4 and libsoup3 in the same process. I don't think this is a problem in the Debian archive for Sugar beyond sugar-browse-activity. And in that case, sugar-browse-activity was ported to libsoup3 first and appears to still work fine. On behalf of the webkit2gtk maintainers, Jeremy Bícha --- End Message --- --- Begin Message --- Source: sugar Source-Version: 0.121-1 Done: Jonas Smedegaard We believe that the bug you reported is fixed in the latest version of sugar, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1061...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jonas Smedegaard (supplier of updated sugar package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 06 Feb 2024 09:55:54 +0100 Source: sugar Architecture: source Version: 0.121-1 Distribution: unstable Urgency: medium Maintainer: Debian Sugar Team Changed-By: Jonas Smedegaard Closes: 1061531 Changes: sugar (0.121-1) unstable; urgency=medium . [ upstream ] * new release . [ Jonas Smedegaard ] * drop patch obsoleted by upstream changes * build-depend on libsoup-3.0-dev; tighten dependency on gir1.2-webkit2; have sugar-session break older sugar-browse-activity; closes: bug#1061531, thanks to Jeremy Bícha * update copyright info: update coverage Checksums-Sha1: f831c48c7b953b3a7d3073fbbbe01eaf691f9976 2175 sugar_0.121-1.dsc ae068921377ef5838ad9c34134a2f83318a31a03 752012 sugar_0.121.orig.tar.xz 26a135e8c3594983cf01da3244da5d7af954df99 22440 sugar_0.121-1.debian.tar.xz 4775c1d68ba0ce30a913fcee6ff2e0bb131d8377 16737 sugar_0.121-1_amd64.buildinfo Checksums-Sha256: 0d7bc04f3f043d8398fb6003b9f134d8bc0d3604fa3f3be05cf250ac9a1702ce 2175 sugar_0.121-1.dsc 823b0463eaa7d6aac8311c1f9b961150ff13dbbc4e9399bcd9b425850b05ee9c 752012 sugar_0.121.orig.tar.xz 4d0051b4581b75898c9254ac9e53534dc077113e5f5f43fd88eb488d26ac6b06 22440 sugar_0.121-1.debian.tar.xz 17d2d024d2ffd8e4078db11d73c6d3f02e2a18d49315ead4d9215b0dfc5accd7 16737 sugar_0.121-1_amd64.buildinfo Files: 8d9fb3643403d330f1fe92c5f5129735 2175 x11 optional sugar_0.121-1.dsc 66a7b74d4181791fb4bbf0117f90f9f6 752012 x11 optional sugar_0.121.orig.tar.xz b7df50a66e2aba58277f2a597bf40a38 22440 x11 optional sugar_0.121-1.debian.tar.xz 7bb888a433cac3a33fc302fa51e170b4 16737 x11 optional sugar_0.121-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXB9Z0ACgkQLHwxRsGg ASH5Ag/+KINvr3F1AKiUpP/MXt1UoZdrKyV5rI/DfRpk3IGPGUw2lZQzZinZ+3cC nSHzpf/RYZU5VB6LPgmlSqx10caURP06nunDGw239BoRoHqkH2EgE5eV21v6rVPE 81guckKA9+MSpEEislF3muXvrRqMz7o0VqDSk3MiJorl2ZCLc6r3kBu/dl01o4ax 4WT1rM76kCClzLI+cZJMt0edC+dFHgUyS15lBgj9q5E5Z+sUe6Wzn/7mI6zV5xa5 JK8ncLtfewDmTGMSWIpunKacnXBrNyon+Je6x5KfP3/Qrnx2jjCA4rpGPK0wpqSa n2ET2OJgKxKEZyp/+gt4DoqqW4+6iPSrjUzjWReB4KVhvDPYOkx6BnDd6snnRj7u a+8wsSPxP/YmcR2qLoRgqgvmAb7EHdR8bmBQvZbibMIVDdw1OC2ylalcj5pxLkwO TuLoQ7boRNPJOjcaQKyanfQHQyfEuUtOA/Zw45FzEgY6M5RzdyCo/qo5Ku1Cb0ie 5qj0Or7wbLbjzOaWSB3ZTKz6T4IvPgAtrQbn12Fh1Y5hcDGQ7m/1UAyuuyyshkqZ OCE/JhG9loeVcHmDfY8pSGn6JQBjp+audTBYmNLO7FrRNbOeEebWkCLI75CS1mR/ a9XlSmJtyj+csiht4Egdya1JHGJzN41+EV2XMkfpVhzvLCbtBqQ= =2HcO -END PGP SIGNATURE End Message ---
Processed (with 1 error): ukwm: undeclared dependency on libqt5-ukui-style1
Processing commands for cont...@bugs.debian.org: > Control: Unknown command or malformed arguments to command. > reassign 1051425 ukui-session-manager 3.22.0.2-1 Bug #1051425 [src:ukwm] ukwm: undeclared dependency on libqt5-ukui-style1 Bug reassigned from package 'src:ukwm' to 'ukui-session-manager'. No longer marked as found in versions ukwm/1.2.0-1. Ignoring request to alter fixed versions of bug #1051425 to the same values previously set Bug #1051425 [ukui-session-manager] ukwm: undeclared dependency on libqt5-ukui-style1 Marked as found in versions ukui-session-manager/3.22.0.2-1. > thanks. Stopping processing here. Please contact me if you need assistance. -- 1051425: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051425 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1051425: ukwm: undeclared dependency on libqt5-ukui-style1
Control: reassign 1051425 ukui-session-manager 3.22.0.2-1 Hi, The bug was present in ukui-session-manager version 3.22.0.2-1 but has been resolved in the recently uploaded version 4.0.0.0-1. thanks.
Bug#1063322: marked as done (libmapcache-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libmapcache.so)
Your message dated Tue, 06 Feb 2024 08:50:25 + with message-id and subject line Bug#1063322: fixed in mapcache 1.14.0-3~exp2 has caused the Debian Bug report #1063322, regarding libmapcache-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libmapcache.so to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1063322: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063322 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libmapcache-dev Version: 1.14.0-3~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libmapcache1-dev libmapcache-dev has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/x86_64-linux-gnu/libmapcache.so is contained in the packages * libmapcache-dev/1.14.0-3~exp1 as present in experimental * libmapcache1-dev * 1.10.0-2+b1 as present in bullseye * 1.14.0-1 as present in bookworm * 1.14.0-1~bpo11+1 as present in bullseye-backports * 1.14.0-2+b2 as present in trixie|unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance. --- End Message --- --- Begin Message --- Source: mapcache Source-Version: 1.14.0-3~exp2 Done: Bas Couwenberg We believe that the bug you reported is fixed in the latest version of mapcache, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1063...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Bas Couwenberg (supplier of updated mapcache package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 06 Feb 2024 09:19:37 +0100 Source: mapcache Architecture: source Version: 1.14.0-3~exp2 Distribution: experimental Urgency: medium Maintainer: Debian GIS Project Changed-By: Bas Couwenberg Closes: 1063322 Changes: mapcache (1.14.0-3~exp2) experimental; urgency=medium . * Add Break/Replaces for renamed -dev package. (closes: #1063322) * Switch pkg-config build dependency to pkgconf. Checksums-Sha1: 27411a78a9c76e6239bafed134513ce6a0a314c1 2841 mapcache_1.14.0-3~exp2.dsc 3ad49386ed22ac6d11c02c3a773b55e1a285ac68 17244 mapcache_1.14.0-3~exp2.debian.tar.xz ed5bd29b393f91f943cdb7418cebd9670354ecaf 20967 mapcache_1.14.0-3~exp2_amd64.buildinfo Checksums-Sha256: 9ebf61c6101ed32ef9b9b48466c41e80160e471c554cd5ed8f3c99368b5484f9 2841 mapcache_1.14.0-3~exp2.dsc 338d1d77fe797aa9d675fb1b6dce8fce3fe247f1b55523ba9f9494afbd7a5bdc 17244 mapcache_1.14.0-3~exp2.debian.tar.xz 9016c022c29989b67019f53daad30d58a4e4ce848b7e658eb69fa0fccb6bec95 20967 mapcache_1.14.0-3~exp2_amd64.buildinfo Files: e345d6c965642a833e1055f58f3b84a8 2841 devel optional mapcache_1.14.0-3~exp2.dsc 47c102717d2acc5092d08ec202a67a31 17244 devel optional mapcache_1.14.0-3~exp2.debian.tar.xz 954cf6feed778abacd044aa5a197356f 20967 devel optional mapcache_1.14.0-3~exp2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEgYLeQXBWQI1hRlDRZ1DxCuiNSvEFAmXB7RIACgkQZ1DxCuiN SvF2/w//RQcyhE6nqrPaoR1CfqDWgTy0b85TNagwYIrU20Ew4Pjj5niBhhc5gRDt 8mn4C0+S/2OyNvYWcZs/mnyI+XO9HOFbwLsLss9ZpxjukW25TxsFqEPnp8yEzO+A c+VppdgNgtJGHUHoMLAL3OMPzqIeqFPaxilYG9Qf5V6JtfU5UVnHCBkjbsHEP0eE Yso7Mqg00FuxzKMNcyqMrh7I2nzFbA2zhLVdwglXQBnkNezS1ZKjlt7VwGyHfOHg ZtXg/Zq8IsCb5MSKGeSnbDmp6UV296547GY4vkV2lpIgLyeEKdAZjk65ZqC4/LFR jeR0zq576RZT+5hWahwK8CoOHCTp0rmH7ZtesKs8FMP6f1dtBljJKLj4DH1vGj9h W2rRg5UNGes0ZE8lKOQ4TyLCTgdfRHXzLA5+PoaSUlJEPzeeg+WdEn2bCGRVH8L3 MPTnqmkrU+MdNK36ZzBWq/bMnI4KfgAMzp2UuvNf02rrF4FOPmQMdZJdnfO/hvhL zExgnqGd8n7BQp+62S78eN6kg7K6Yy8zcBtBkLz9/zQ8oC3Z4UYhRgX7Tfwp/rDP JKQcUnaRb06/ea1K6bH/emILF199+tgvz4rcUiKtgx0WZAJUc9YEH1rVgg/1iucm
Processed: tags 1053865 + patch pending
Processing commands for cont...@bugs.debian.org: > tags 1053865 + patch pending Bug #1053865 [src:prody] prody: incompatible with python3-biopython > 1.79 Added tag(s) patch and pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 1053865: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053865 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
