Bug#1070421: marked as pending in mac-widgets
Control: tag -1 pending Hello, Bug #1070421 in mac-widgets 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/java-team/mac-widgets/-/commit/3fc653d3c0b9e886d5bf9f78d901e17b8b1139df Import Debian changes 0.10.0+svn416-dfsg1-4 mac-widgets (0.10.0+svn416-dfsg1-4) unstable; urgency=medium . * Team upload. * Drop libmac-widgets-doc (Closes: #1070421) * Update Vcs URLs to point to Salsa (this message was generated automatically) -- Greetings https://bugs.debian.org/1070421
Bug#1067916: FTBFS: tests failed
Thank you very much to Arnd Bergmann and Wookey for the assistance
off-list. Arnd's explanation of the root cause and the patch required
is reproduced below. I suspect others will also find it helpful.
On Sun, Apr 14, 2024 at 5:33 AM Arnd Bergmann wrote:
> This is the same problem that any application has when using
> syscall() with libc-provided data structures. In general, one
> should use libc syscall wrappers and libc data structures, but
> there is no such wrapper for futex, so one should use the kernel
> structures instead: __kernel_old_timespec for __NR_futex
> and __kernel_timespec for __NR_futex_time64.
>
> The bug here is in
> https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L40
> which contains the incorrect
>
> #ifndef SYS_futex
> // Missing on Android/Bionic.
> #ifdef __NR_futex
> #define SYS_futex __NR_futex
> #elif defined(SYS_futex_time64)
> #define SYS_futex SYS_futex_time64
> #else
> #error "Need working SYS_futex"
> #endif
> #endif
>
> This above only works on musl because it has no __NR_futex
> definition for 32-bit, while the kernel headers used
> by glibc contain both __NR_futex and __NR_futex_time64.
>
> The kernel timespec definitions are intentionally done to
> be compatible with the libc ones, but you have to use the
> correct one. There are many ways to write this, depending
> how many corner cases you want to handle. This version
> should work on any Linux kernel after 5.6 and any glibc
> and musl libc:
>
> #if defined(__USE_TIME_BITS64) && (__BITS_PER_LONG == 32)
> #define MY_FUTEX __NR_futex_time64
> #else
> #define MY_FUTEX __NR_futex
> #endif
>
> Alternatively (avoiding the dependency on libc macros)
> you can use
>
> #if __BITS_PER_LONG == 32
> #define MY_FUTEX (sizeof(long) < sizeof(time_t)) ? \
>__NR_futex_time64 : __NR_futex
> #else
> #define MY_FUTEX __NR_futex
> #define
>
> > And now I'm well beyond my depth, but does it make sense that
> > timespec_tz_nsec is still 4 bytes after the t64 transtition? I get it
> > that it's supposed to represent up to 10^9 fractional seconds and thus
> > can fit into 32-bits, but maybe the optimization isn't worth the
> > discrepancy with 64-bit userspace?
> >
> > armhf before the t64 transition:
> >
> > Size of timespec.tz_sec: 4 byte
> > Size of timespec.tz_nsec: 4 byte
> >
> > armhf after the t64 transition:
> >
> > Size of timespec.tz_sec: 8 byte
> > Size of timespec.tz_nsec: 4 byte
> >
> > 64-bit architectures:
> >
> > Size of timespec.tz_sec: 8 byte
> > Size of timespec.tz_nsec: 8 byte
>
> The kernel interfaces are defined with an 8 byte tv_nsec,
> same as the 64-bit ones for any data returned by the kernel:
>
> struct __kernel_timespec {
> __kernel_time64_t tv_sec; /* seconds */
> long long tv_nsec;/* nanoseconds */
> };
>
> The libc definitions on the other hand use a POSIX and
> C99 compliant definition with a 'long tv_nsec':
>
> struct timespec
> {
> #ifdef __USE_TIME_BITS64
> __time64_t tv_sec;/* Seconds. */
> #else
> __time_t tv_sec; /* Seconds. */
> #endif
> #if __WORDSIZE == 64 \
> || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) \
> || (__TIMESIZE == 32 && !defined __USE_TIME_BITS64)
> __syscall_slong_t tv_nsec;/* Nanoseconds. */
> #else
> # if __BYTE_ORDER == __BIG_ENDIAN
> int: 32; /* Padding. */
> long int tv_nsec; /* Nanoseconds. */
> # else
> long int tv_nsec; /* Nanoseconds. */
> int: 32; /* Padding. */
> # endif
> #endif
> };
>
> All the complexity in there is done to ensure that the two
> structures put the nanoseconds in the same bits as the kernel
> while still keeping the type of the userspace tv_nsec member
> 'long int'. The kernel ignores the top 32 bits of tv_nsec
> when called from a 32-bit process but produces an error
> when any of those bits are set when called from a 64-bit
> process.
signature.asc
Description: PGP signature
Bug#1068512: marked as pending in welle.io
Control: tag -1 pending Hello, Bug #1068512 in welle.io 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/debian-hamradio-team/welle.io/-/commit/6f4eb3d6357ecf6a660a5e57df3202e5602556b9 No longer define MPG123_NO_LARGENAME to fix FTBFS (Closes: #1068512) (this message was generated automatically) -- Greetings https://bugs.debian.org/1068512
Bug#1067916: FTBFS: tests failed
On Sun, Apr 07, 2024 at 02:43:20PM +, tony mancill wrote: > > > > Source: capnproto > > > > Version: 1.0.1-3 > > > > Severity: serious > > > > Tags: ftbfs > > > > > > > > https://buildd.debian.org/status/fetch.php?pkg=capnproto=armhf=1.0.1-3%2Bb2=1711652087=0 > > I am assuming that if the futux syscall here: > > https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L250 > > which also gets passed a timespec, was the culprit, that more things would be > broken on armhf than just a few tests. But that's an area I need to explore > further. So assumptions can be wrong... :) Many thanks to Tom Lee for creating a simple test case [1] that demonstrates the futex syscall returning early on armhf + t64, while being successful on the same architecture with the pre-t64 userspace and other architectures. Results on the porter box with t64 userspace: (sid_armhf-dchroot)$ uname -a Linux abel 4.19.0-21-armmp-lpae #1 SMP Debian 4.19.249-2 (2022-06-30) armv7l GNU/Linux (sid_armhf-dchroot)$ ./futex-test futex returned too early: 26640 ns (sid_armhf-dchroot)$ ./futex-test futex returned too early: 34560 ns (sid_armhf-dchroot)$ ./futex-test futex returned too early: 23920 ns (sid_armhf-dchroot)$ ./futex-test futex returned too early: 33560 ns Running the same code compiled against the bookworm userspace on the same armhf porterbox is successful: (bookworm_armhf-dchroot)$ uname -a Linux abel 4.19.0-21-armmp-lpae #1 SMP Debian 4.19.249-2 (2022-06-30) armv7l GNU/Linux (bookworm_armhf-dchroot)$ ./futex-test-bookworm ok: 10069107 (bookworm_armhf-dchroot)$ ./futex-test-bookworm ok: 10067586 (bookworm_armhf-dchroot)$ ./futex-test-bookworm ok: 10068587 (bookworm_armhf-dchroot)$ ./futex-test-bookworm ok: 10068187 (bookworm_armhf-dchroot)$ ./futex-test-bookworm ok: 10069026 This may be a naive question, but since we're dealing with a syscall that passes a timespec, is there a minimum kernel version required for the time_t 64 userspace? In any event, I'm not sure about the next steps here. Any suggestions? Should I work with DSA to try to get a porter box with a newer kernel to confirm that that resolves the issue with the test? (I think this would have eventual implications for the buildds.) Thank you, tony [1] https://gist.githubusercontent.com/thomaslee/e8484eeae64004e2a3be8be88e2e25e8/raw/e9edc3025d54afbff6b0492998ee624d8b2ac317/futex-test.c signature.asc Description: PGP signature
Bug#1066649: libtritonus-java: diff for NMU version 20070428-14.2
On Fri, Mar 29, 2024 at 12:50:03AM +0500, Andrey Rakhmatullin wrote: > Control: tags 1066649 + patch > Control: tags 1066649 + pending > > Dear maintainer, > > I've prepared an NMU for libtritonus-java (versioned as 20070428-14.2) and > uploaded it to unstable. Thank you for the NMU. The debdiff has been applied to the Salsa repo.
Bug#1067929: marked as pending in java-package
Control: tag -1 pending Hello, Bug #1067929 in java-package 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/java-team/java-package/-/commit/601be79c5ba92dc49e970bb197626779095c5d87 Update java-package Depends for time64 transition (Closes: #1067929) (this message was generated automatically) -- Greetings https://bugs.debian.org/1067929
Bug#1067916: FTBFS: tests failed
On Sun, Apr 07, 2024 at 01:49:35PM +0500, Andrey Rakhmatullin wrote: > On Sat, Apr 06, 2024 at 10:31:52PM +0000, tony mancill wrote: > > On Fri, Mar 29, 2024 at 12:13:57AM +0500, Andrey Rakhmatullin wrote: > > > Source: capnproto > > > Version: 1.0.1-3 > > > Severity: serious > > > Tags: ftbfs > > > > > > https://buildd.debian.org/status/fetch.php?pkg=capnproto=armhf=1.0.1-3%2Bb2=1711652087=0 > > > > Thank you for the bug report. I'm not able to reproduce the test > > failure when cross-building on amd64, so am in the process of triaging > > on a porter box. > Does it fail on a porter box? > As a (useless?) data point I've just tried building it in a qemu chroot > and some other tests failed, e.g. AsyncIo/AncillaryMessageHandler and > AsyncIo/ScmRightsTruncatedOdd so it's not useful. Yes, the failure is consistent on the porter box. It's still quite early in my investigation (and I'm not slow at this sort of stuff). My first hypothesis was that usleep() might behave differently, but there is no evidence to support that. Now I'm trying to decide whether the difference in the timespec struct contributes to the issue: on armhf: Size of timespec.tz_sec: 8 byte Size of timespec.tz_nsec: 4 byte Everywhere else: Size of timespec.tz_sec: 8 byte Size of timespec.tz_nsec: 8 byte I'm focused on this code: https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L157-L173 But I'm haven't yet found a clear issue, or an explanation as why this is behaving differently now, since this code has worked on 32-bit architectures in the past. I am assuming that if the futux syscall here: https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L250 which also gets passed a timespec, was the culprit, that more things would be broken on armhf than just a few tests. But that's an area I need to explore further. Thank you, tony signature.asc Description: PGP signature
Bug#1067916: FTBFS: tests failed
On Fri, Mar 29, 2024 at 12:13:57AM +0500, Andrey Rakhmatullin wrote: > Source: capnproto > Version: 1.0.1-3 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=capnproto=armhf=1.0.1-3%2Bb2=1711652087=0 Thank you for the bug report. I'm not able to reproduce the test failure when cross-building on amd64, so am in the process of triaging on a porter box. signature.asc Description: PGP signature
Bug#1068068: bobcat, time_t transition lead to apparent ABI break (was: Need rebootstrapping on armel and armhf).
On Wed, Apr 03, 2024 at 11:37:20AM +0200, Frank B. Brokken wrote: > Dear Peter Green, you wrote: > > > Also, the bootstrapping procedure is only required when icmake isn't > > > available ... > > Thanks for your bugreport: I'm about to update icmake so that the circular > dependency between bobcat and icmake is removed. Shortly after icmake's > update bobcat will also be updated. icmake 12.0.01-1 [1] has landed in the archive and is being chewed on by the buildds now [2]. Once it is installed on armhf and armel, I will trigger givebacks for bobcat. As noted in the icmake changelog, the icmake bootstrap was accomplished by vendoring in the bobcat sources. This interim measure seemed warranted to get the r-build-deps unstuck. The long-term approach will be addressed by a separate bobcat-source package (#1068510 [3]). Thank you for your help and patience with this one. tony [1] https://tracker.debian.org/news/1517256/accepted-icmake-120001-1-source-into-unstable/ [2] https://buildd.debian.org/status/package.php?p=icmake [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068510 signature.asc Description: PGP signature
Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2
On Wed, Mar 13, 2024 at 01:50:47PM -0400, Jeremy Bícha wrote: > The 3 test cases pass for me now with the uploaded 1.50+nmu2. Maybe my > earlier test build used the old version of xz-utils. Thank you for > your upload! Given what has unfolded over the past few days regarding xz-utils and CVE-2024-3094 [0], should we revisit the patches applied here and for #1063252? Are they still needed? I'm not making any assertions about the validity of the changes, only suggesting that we should review changes made to accommodate the xz-utils versions related to the CVE. (It is still not clear why some gbp workflows using pristine-tar started failing [1] around the same time that changes were being introduced to xz-utils and pristine-tar. Perhaps it is a coicidence, but it seems potentially related.) Thank you, tony [0] https://security-tracker.debian.org/tracker/CVE-2024-3094 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065445 signature.asc Description: PGP signature
Bug#1068068: Need rebootstrapping on armel and armhf
On Sat, Mar 30, 2024 at 01:29:42PM +0500, Andrey Rakhmatullin wrote: > Package: icmake,libbobcat6 > Severity: serious > Tags: ftbfs > > As src:icmake B-D:libbobcat-dev, src:bobcat B-D:icmake, there seems to be zero > packaging-level support for bootstrapping, the packages are not > cross-buildable > and the upstream bootstrapping instructions are too tedious, I'm filing this > for visibility (as there are ~14 packages B-D:libbobcat-dev). Thank you for the bug report. Frank (the upstream author) is in the process of updating icmake to no longer depend on bobcat, thus breaking the cycle. signature.asc Description: PGP signature
Bug#1066215: marked as pending in soundmodem
Control: tag -1 pending Hello, Bug #1066215 in soundmodem 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/debian-hamradio-team/soundmodem/-/commit/a90a68aa72b15f277f08fbef758c08fbbeed04e8 Add patch for implicit-declaration warning (Closes: #1066215) (this message was generated automatically) -- Greetings https://bugs.debian.org/1066215
Bug#1066486: marked as pending in icom
Control: tag -1 pending Hello, Bug #1066486 in icom 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/debian-hamradio-team/icom/-/commit/6202780aa55b0c7c2a7039777e7d298bc7a4d85c Clean-up compiler warnings (Closes: #1066486) (this message was generated automatically) -- Greetings https://bugs.debian.org/1066486
Bug#1066628: marked as pending in tlf
Control: tag -1 pending Hello, Bug #1066628 in tlf 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/debian-hamradio-team/tlf/-/commit/2ad251e045d3841e84128fbf8bce6987b3ea9962 Update warnings-as-errors.patch (Closes: #1066628) (this message was generated automatically) -- Greetings https://bugs.debian.org/1066628
Bug#1065108: marked as pending in java3d
Control: tag -1 pending Hello, Bug #1065108 in java3d 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/java-team/java3d/-/commit/769fd9765156d230867a4e372e8c8cbbc72b6ede Add Build-Dep on libnsl-dev (Closes: #1065108) (this message was generated automatically) -- Greetings https://bugs.debian.org/1065108
Bug#1060940: marked as pending in libfreemarker-java
Control: tag -1 pending Hello, Bug #1060940 in libfreemarker-java 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/java-team/libfreemarker-java/-/commit/03791e28faa7867140e405b48dccc498204b2735 Migrate ivy.xml DOCTYPE decl to ivysettings.xml (Closes: #1060940) (this message was generated automatically) -- Greetings https://bugs.debian.org/1060940
Bug#1057683: marked as pending in libpdfbox-java
Control: tag -1 pending Hello, Bug #1057683 in libpdfbox-java 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/java-team/libpdfbox-java/-/commit/c45215e7bfc5931129180b0303a5b6d6a3d0fce5 Update BouncyCastle patch for BC 1.77 (Closes: #1057683) (this message was generated automatically) -- Greetings https://bugs.debian.org/1057683
Bug#1058273: gpredict: FTBFS: dh_install: error: missing files, aborting
On Tue, Dec 12, 2023 at 05:47:46PM -0700, Bdale Garbee wrote: > tony mancill writes: > > > So this is very possibly a bug in libreoffice-writer-nogui. > > Sure seems like it. My guess would be that what files go in what > libreoffice binary packages got refactored somehow? Not sure what the > point of the nogui package is if it can't be used here any more. The soffice wrapper script is good enough to include an --strace option, from which it looks like libcuilo.so is the missing library: $ dpkg -S /usr/lib/libreoffice/program/libcuilo.so libreoffice-core: /usr/lib/libreoffice/program/libcuilo.so However, libreoffice-core is the proverbial kitchen sink - it pulls in almost everything you'd get from libreoffice-writer - so for the time-being, I'll use the latter to work around the FTBFS and have filed a bug against libreoffice-writer-nogui (#1058653).
Bug#1057167: marked as pending in libapache-poi-java
Control: tag -1 pending Hello, Bug #1057167 in libapache-poi-java 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/java-team/libapache-poi-java/-/commit/42f8d757b0bfa2a1261447912e0aba6f5f1ae6d7 Add patch for BouncyCastle 1.77 (Closes: #1057167) (this message was generated automatically) -- Greetings https://bugs.debian.org/1057167
Bug#1057165: libitext-java: FTBFS with bouncycastle 1.77
On Thu, Nov 30, 2023 at 10:47:18PM +0100, Markus Koschany wrote: > Source: libitext-java > Version: 2.1.7-14 > Severity: serious > Tags: ftbfs sid > User: a...@debian.org > Usertags: bouncycastle-1.77 > X-Debbugs-Cc: a...@debian.org > > Dear maintainer, > > libitext-java fails to build from source with bouncycastle 1.77. The reason > is the removal of long deprecated methods. The (hopefully) relevant > error message from the build log. I have added a patch to address the FTBFS. Unfortunately, this package doesn't run tests and getting them working is going to take some effort. The patch is straight-forward. It eliminates usage of a few long-deprecated classes in favor of their replacements, or uses some factory-like methods to instantiate objects. However, it would be nice to have at least some sort of runtime checks before uploading, which may take me a few days. I have pushed the changes to the repo if anyone is ready to move ahead with an upload. If not, I will try to upload by early next week. Thanks, tony signature.asc Description: PGP signature
Bug#1057165: marked as pending in libitext-java
Control: tag -1 pending Hello, Bug #1057165 in libitext-java 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/java-team/libitext-java/-/commit/82e6f29bde6ce5dc5393b4161a9496e2ce7ddda6 Add patch for BouncyCastle 1.77 (Closes: #1057165) (this message was generated automatically) -- Greetings https://bugs.debian.org/1057165
Bug#1058273: gpredict: FTBFS: dh_install: error: missing files, aborting
On Tue, Dec 12, 2023 at 09:35:44AM +0100, Lucas Nussbaum wrote: > Source: gpredict > Version: 2.3-115-g0f3beb6-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231212 ftbfs-trixie It feels slightly icky because it pulls in a much larger set of build-deps, but this FTBFS is easily fixed by relaxing the B-D-I on libreoffice-writer-nogui to libreoffice-writer. So this is very possibly a bug in libreoffice-writer-nogui. I went ahead and pushed a patch to packaging repo. If someone feels strongly about keeping the build-deps small for this arch-all package and sticking with libreoffice-writer-nogui, you can reproduce by starting with a clean chroot and running this bit of the build: soffice --writer --headless --convert-to pdf doc/um/gpredict-user-manual.odt And adding build-deps until you no longer get this error. Error: source file could not be loaded I will try to take another look at it before uploading. Cheers, tony
Bug#1058273: marked as pending in gpredict
Control: tag -1 pending Hello, Bug #1058273 in gpredict 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/debian-hamradio-team/gpredict/-/commit/d328dfc309849afad975e9eb44e7096c970bc67a Build-dep on libreoffice-writer (Closes: #1058273) (this message was generated automatically) -- Greetings https://bugs.debian.org/1058273
Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77
On Thu, Nov 30, 2023 at 11:06:56PM +0100, Markus Koschany wrote: > Source: libitext5-java > Version: 5.5.13.3-2 > Severity: serious > Tags: ftbfs sid > User: a...@debian.org > Usertags: bouncycastle-1.77 There are PDF signature and encryption test cases running as part of the build, and I did some desk-testing of programs that depend on libitext5-java: jameica/hibiscus and mobile-atlas-creator, which I was able to use to generates a PDF - and everything seems fine at runtime. I'll keep an eye out for any runtime issues with digitally signed PDFs and move on to libitext-java.
Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77
On Sat, Dec 09, 2023 at 12:50:33PM +0100, Andreas Tille wrote: > I tried the latest upstream version of libitext5-java and commited the > change to Git. Unfortunately the problem persists. Some Debian Med > packages are depending from this package so I'd be happy if someone > could have a look. You can find the latest log in Salsa CI[1]. Hi Andreas, Thank you for your efforts here. I just pushed a patch that resolves the FTBFS, and the tests are passing. I plan to do a bit more poking at the upstream tests to make sure that the patched classes are exercised by the test cases, but will either update this bug or upload in the 2-3 days. Regards, tony
Bug#1057171: marked as pending in libitext5-java
Control: tag -1 pending Hello, Bug #1057171 in libitext5-java 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/java-team/libitext5-java/-/commit/76a0d51dda07cd09211479918b0bd71184209936 Add patch to compile against BouncyCastle 1.77 (Closes: #1057171) (this message was generated automatically) -- Greetings https://bugs.debian.org/1057171
Bug#1057933: libjose4j-java: FTBFS: IOException: Only named ECParameters supported
On Sun, Dec 10, 2023 at 08:18:03PM +0100, Santiago Vila wrote: > Package: src:libjose4j-java > Version: 0.7.12-2 > Severity: serious > Tags: ftbfs > > [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.063 > s <<< FAILURE! - in org.jose4j.jwk.EllipticCurveJsonWebKeyTest > [ERROR] > testParseExampleWithPrivate256(org.jose4j.jwk.EllipticCurveJsonWebKeyTest) > Time elapsed: 0.031 s <<< FAILURE! > java.lang.AssertionError: > expected: [8b:e2:14:0f:3a:17:e9:25:d1:ae:df:18:a3:b2:9a:fd:63:04:41:11] > X: > 7fcdce2770f6c45d4183cbee6fdb4b7b580733357be9ef13bacf6e3c7bd15445 > Y: > c7f144cd1bbd9b7e872cdfedb9eeb9f4b3695d6ea90b24ad8a4623288588e5ad > > but was: > at > org.jose4j.jwk.EllipticCurveJsonWebKeyTest.testParseExampleWithPrivate256(EllipticCurveJsonWebKeyTest.java:53) > ... > > If required, the full build log is available here: > > https://people.debian.org/~sanvila/build-logs/202312/ Thank you for making this available. > About the archive rebuild: The build was made using virtual machines > from AWS, with enough memory, enough disk, and either one or two > CPUs, using a reduced chroot with only build-essential packages. I'm not able to reproduce this locally, and the only potentially relevant difference I see between the AWS testbed and my local environment is that I am running Intel and the AWS system is AMD. > If you could not reproduce the bug please contact me privately, as I > am willing to provide ssh access to a virtual machine where the bug is > fully reproducible. Will do, as time permits. This package has a low popcon, and is a build-dependency of libcallstats-java, which also has a low popcon, and has no reverse dependencies. I believe both are part of an effort to get Jitsi back into Debian. If that's not likely to happen, an alternative is to file RM bugs for both of them. (I am adding the Uploaders to the cc:) Thanks, tony signature.asc Description: PGP signature
Bug#1055049: libtakari-polyglot-groovy-java: missing Breaks+Replaces: libtakari-polyglot-maven-java (<< 0.4.11-2)
On Sat, Dec 09, 2023 at 04:39:35PM -0500, Jérôme Charaoui wrote: > On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann wrote: > > during a test with piuparts I noticed your package fails to upgrade from > > 'testing'. > > It installed fine in 'testing', then the upgrade to 'sid' fails > > because it tries to overwrite other packages files without declaring a > > Breaks+Replaces relation. > > > > See policy 7.6 at > > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces > > > > From the attached log (scroll to the bottom...): > > > > Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb > > ... > > Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... > > dpkg: error processing archive > > /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb > > (--unpack): > >trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which > > is also in package libtakari-polyglot-maven-java 0.4.11-1 > > Errors were encountered while processing: > >/var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb > > Thanks for the heads up. > > I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was indeed > split away from "libtakari-polyglot-maven-java" and into > "libtakari-polyglot-groovy-java", however the new version of > "libtakari-polyglot-maven-java" does *not* depend on/recommend > "libtakari-polyglot-groovy-java". > > So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in the > first place, during the piuparts upgrade. It's not present in testing, and > it has currently zero reverse-dependencies. > > I did my own testing and on a bare system with > "libtakari-polyglot-maven-java" installed, upgrading to sid does not include > an installation of "libtakari-polyglot-groovy-java". > > Any idea what's going on? Hi Jérôme, I believe you're correct that in the normal upgrade case, this is unlikely to occur. Here's the test case I ran instead a clean trixie chroot: 1. Install libtakari-polyglot-maven-java (0.4.11-1) 2. Update sources.list to unstable and then apt-get update 3. apt-get -y install libtakari-polyglot-groovy-java Step (3) will upgrade libtakari-polyglot-maven-java to 0.4.11-2 *before* installing libtakari-polyglot-groovy-java, so there's no problem. However, the issue can occur when using dpkg directly, or some other factor influences the ordering such that libtakari-polyglot-groovy-java is installed *before* libtakari-polyglot-maven-java is upgraded. For example: 1. Install libtakari-polyglot-maven-java (0.4.11-1) 2. wget http://ftp.us.debian.org/debian/pool/main/t/takari-polyglot-maven/libtakari-polyglot-groovy-java_0.4.11-2_all.deb 3. dpkg -i libtakari-polyglot-groovy-java_0.4.11-2_all.deb Preparing to unpack libtakari-polyglot-groovy-java_0.4.11-2_all.deb ... Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... dpkg: error processing archive libtakari-polyglot-groovy-java_0.4.11-2_all.deb (--install): trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is also in package libtakari-polyglot-maven-java 0.4.11-1 Errors were encountered while processing: libtakari-polyglot-groovy-java_0.4.11-2_all.deb This is the reason that the relationship needs to be explicit. I'm not 100% certain, but perhaps we can get away with only adding a versioned depends on libtakari-polyglot-maven-java (>= 0.4.11-2) to the libtakari-polyglot-groovy-java package. The problem as I see it is that the current unversioned Depends can be satisfied by any version of libtakari-polyglot-maven-java, including older versions with the file conflict. Requiring the newer libtakari-polyglot-maven-java would prevent this. Cheers, tony
Bug#1052831: python-agate: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13
On Tue, Sep 26, 2023 at 02:44:16PM +0200, Lucas Nussbaum wrote:
> Source: python-agate
> Version: 1.6.3-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230925 ftbfs-trixie
> > Traceback (most recent call last):
> > File
> > "/<>/.pybuild/cpython3_3.11_agate/build/tests/test_data_types.py",
> > line 364, in test_cast_parser_timezone
> > tzinfo = pytz.timezone('US/Pacific')
> > ^^^
> > File "/usr/lib/python3/dist-packages/pytz/__init__.py", line 202, in
> > timezone
> > raise UnknownTimeZoneError(zone)
> > pytz.exceptions.UnknownTimeZoneError: 'US/Pacific'
Hi,
I have prepared an NMU to address this test failure; debdiff attached.
Please let me know if you have any concerns about an upload to address
this build failure.
Thank you,
tony
diff -Nru python-agate-1.6.3/debian/changelog
python-agate-1.6.3/debian/changelog
--- python-agate-1.6.3/debian/changelog 2022-10-14 03:16:54.0 -0700
+++ python-agate-1.6.3/debian/changelog 2023-10-25 06:41:55.0 -0700
@@ -1,3 +1,10 @@
+python-agate (1.6.3-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Update TZ used in tests for tzdata 2023c-8 (Closes: #1052831)
+
+ -- tony mancill Wed, 25 Oct 2023 06:41:55 -0700
+
python-agate (1.6.3-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru python-agate-1.6.3/debian/patches/1052831-pytz.patch
python-agate-1.6.3/debian/patches/1052831-pytz.patch
--- python-agate-1.6.3/debian/patches/1052831-pytz.patch1969-12-31
16:00:00.0 -0800
+++ python-agate-1.6.3/debian/patches/1052831-pytz.patch2023-10-25
06:41:55.0 -0700
@@ -0,0 +1,16 @@
+Description: update for tzdata (2023c-8) (see Debian: #1040997)
+Author: tony mancill
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052831
+Forwarded: no
+
+--- a/tests/test_data_types.py
b/tests/test_data_types.py
+@@ -361,7 +361,7 @@
+ ))
+
+ def test_cast_parser_timezone(self):
+-tzinfo = pytz.timezone('US/Pacific')
++tzinfo = pytz.timezone('America/Los_Angeles')
+ datetime_type = DateTime(timezone=tzinfo)
+
+ values = ('3/1/1994 12:30 PM', '2/17/2011 06:30', None, 'January 5th,
1984 22:37', 'n/a')
diff -Nru python-agate-1.6.3/debian/patches/series
python-agate-1.6.3/debian/patches/series
--- python-agate-1.6.3/debian/patches/series2022-10-14 03:16:54.0
-0700
+++ python-agate-1.6.3/debian/patches/series2023-10-25 06:41:55.0
-0700
@@ -1,2 +1,3 @@
Use-packaged-docs.patch
No-privacy-breach.patch
+1052831-pytz.patch
signature.asc
Description: PGP signature
Bug#1039985: libjson-smart-java: buster-lts has a newer version than bullseye/bookworm/sid
On Fri, Jun 30, 2023 at 06:46:06PM +0200, Andreas Beckmann wrote: > Package: libjson-smart-java > Version: 2.2-2 > Severity: serious > Tags: bullseye bookworm trixie sid > > Hi, > > during a test with piuparts I noticed your package cannot be upgraded > from buster-lts to any newer release since buster-lts has a version > newer than any later release: > > json-smart | 2.2-1 | stretch | source > json-smart | 2.2-2 | buster | source > json-smart | 2.2-2 | bullseye| source > json-smart | 2.2-2 | bookworm| source > json-smart | 2.2-2 | trixie | source > json-smart | 2.2-2 | sid | source > json-smart | 2.2-2+deb10u1 | buster-security | source I am working on an upload of a new upstream version 2.5.0 that will take care of trixie and sid. Bastien, are you planning on uploading a patched 2.2 to bullseye and bookworm? Thanks, tony
Bug#941808: java-package: depends on transitional libgl1-mesa-glx
On Sun, Sep 10, 2023 at 11:08:19AM +0200, Sebastian Ramacher wrote: > Control: severity -1 serious > Control: tags -1 sid trixie > > On 2019-10-05 23:28:58 +0200, Thorsten Glaser wrote: > > Package: java-package > > Version: 0.62 > > Severity: important > > > > libgl1-mesa-glx is a transitional dummy package for > > Depends: libgl1, libglx-mesa0 > > and could be safely uninstalled except java-package > > Depends on it. > > > > Please change the dependency to the depended-on packages. > > libgl1-mesa-glx got removed from unstable and java-package is holding it > back from being removed from testing. Raising the severity accordingly. Hi Sebastian, Thank you for the reminder. We've had an update sitting in the Salsa repo, ready to go for a while now. I will upload today. Cheers, tony signature.asc Description: PGP signature
Bug#1037724: marked as pending in libcm256cc
Control: tag -1 pending Hello, Bug #1037724 in libcm256cc 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/debian-hamradio-team/libcm256cc/-/commit/0b917dc1154a84e2aa43c9aca287c92c57006784 Fix FTBFS with GCC-13 (Closes: #1037724) (this message was generated automatically) -- Greetings https://bugs.debian.org/1037724
Bug#1037661: marked as pending in flrig
Control: tag -1 pending Hello, Bug #1037661 in flrig 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/debian-hamradio-team/flrig/-/commit/055308b778550579c8f570584efddf6606f3fa56 Add patch for FTBFS on GCC-13 (Closes: #1037661) (this message was generated automatically) -- Greetings https://bugs.debian.org/1037661
Bug#1041387: marked as pending in libpdfbox-java
Control: tag -1 pending Hello, Bug #1041387 in libpdfbox-java 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/java-team/libpdfbox-java/-/commit/5ff86861b8907e1ad4c8275f5b838e1ec1ed6acb Drop examples from libpdfbox-java (Closes: #1041387) (this message was generated automatically) -- Greetings https://bugs.debian.org/1041387
Bug#1021894: openjfx: FTBFS on arm64 and armhf
On Sat, Jul 15, 2023 at 01:46:02PM -0700, tony mancill wrote: > I intend to build and upload in the next few days, but you are welcome > to NMU if you would prefer. Uploaded as 11.0.11+1-3.1. (The version number was a slight mistake on my part; I meant to remove the NMU suffix in the changelog before the upload. I will fix it on the next upload.)
Bug#1021894: marked as pending in openjfx
Control: tag -1 pending Hello, Bug #1021894 in openjfx 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/java-team/openjfx/-/commit/f2d3ac36ed45d414a8b7751588a5f02ec9358680 Add patch for FTBFS on arm64 and armhf (Closes: #1021894) Thank you to Wookey for identifying the issue and a temporary workaround. (this message was generated automatically) -- Greetings https://bugs.debian.org/1021894
Bug#1021894: openjfx: FTBFS on arm64 and armhf
Hi Wookey, Thank you for the investigation and the patch! I intend to build and upload in the next few days, but you are welcome to NMU if you would prefer. Cheers, tony On Fri, Jul 14, 2023 at 02:28:14PM +0100, Wookey wrote: > Source: openjfx > Followup-For: Bug #1021894 > > I was surprised to find that this package was missing on arm64 (making josm > uninstallable) so I investigated. > > 11.0.11+0-1 built OK on 2021-02-03. But 11.0.11+1-3 FTBFS. > > 11.0.11+0-1 no longer builds either. Failing in: > Execution failed for task ':media:buildAVPlugin' > ../../../plugins/av/decoder.c:79:5: error: implicit declaration of function > 'avcodec_register_all' > which seems to be a problem with ffmpeg, but lets ignore that for now - it > seems to be fixed with a patch in +1-3 > > 11.0.11+1-3 fails with: > [ 28%] Building CXX object > Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o > Gradle is still running, please be patient... > In file included from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:30, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssembler.h:46, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/GPRInfo.h:28, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArithProfile.h:28, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: > In static member function ‘static void > JSC::ARM64Assembler::replaceWithJump(void*, void*)’: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2576:51: > error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ > 2576 | to = > ExecutableAllocator::singleton().getJumpIslandTo(where, to); > | ^~~ > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: > In static member function ‘static void* > JSC::ARM64Assembler::prepareForAtomicRelinkJumpConcurrently(void*, void*)’: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2781:49: > error: ‘class JSC::ExecutableAllocator’ has no member named > ‘getJumpIslandToConcurrently’ > 2781 | return > ExecutableAllocator::singleton().getJumpIslandToConcurrently(from, to); > | > ^~~ > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: > In static member function ‘static void > JSC::ARM64Assembler::linkJumpOrCall(int*, const int*, void*)’: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:3024:51: > error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ > 3024 | to = > ExecutableAllocator::singleton().getJumpIslandTo(bitwise_cast(fromInstruction), > to); > | ^~~ > > (Which is actually a different failure point from the one Sebastian posted in > this bug) > > So all this jumpisland stuff comes from webkit's JavaScript JIT. > > It turns out that this upstream Webkit bug explains what's going on: > https://bugs.webkit.org/show_bug.cgi?id=217079 > jumpislands allow +-128MB jumps to get to the whole 1GB executable space by > having a particular memory layout. > And the build should use _either_ the JIT or 'CLOOP', but not both. > > Applying the patch in that bug (which gates JUMP_ISLANDS on the JIT > being enabled, and avoids compiling in a call to dumpJITMemory if JIT > is disabled) allows everything to get compiled. However it then fails > to link: > > [100%] Linking CXX shared library ../../lib/libjfxwebkit.so > /usr/include/c++/11/ext/new_allocator.h:116: error: undefined reference to > 'std::__throw_bad_array_new_length()' > collect2: error: ld returned 1 exit status > gmake[4]: *** > [Source/WebKitLegacy/CMakeFiles/WebKitLegacy.dir/build.make:2237: > lib/libjfxwebkit.so] Error 1 > > Which seems to be a problem with compiling with gcc11/12, but then trying > to link to the gcc-libstd++ from gcc10. Removing all the gcc-10 > packages from the build environment fixed this. I think this means > the package should get a build-conflict on libstdc++-10-dev > > Also the discussion in the above bug suggests that the JIT should in fact be > enabled on debian arm64. > It only needs to be turned off on iOS and 64k aarch64 kernel (RHEL). I will > test that next. > > Attached is the debdiff that at least makes the build work again for now. > Happy to do an NMU if that's helpful > diff -Nru openjfx-11.0.11+1/debian/changelog >
Bug#1037754: marked as pending in limesuite
Control: tag -1 pending Hello, Bug #1037754 in limesuite 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/debian-hamradio-team/limesuite/-/commit/5856ba8001d2e9c3278d7ac20709935822631bac Fix FTBFS with GCC-13 (Closes: #1037754) (this message was generated automatically) -- Greetings https://bugs.debian.org/1037754
Bug#1037857: closing 1037857
close 1037857 15.02.00-1 thanks Upstream 15.02.00 addressed the FTBFS with GCC-13.
Bug#1037598: closing 1037598
close 1037598 15.02.00-1 thanks Upstream release 15.02.00 addressed the FTBFS with GCC-13.
Bug#1037064: maven-verifier depends on downloading sources at build time
On Sat, Jun 03, 2023 at 12:58:17PM +0200, gregor herrmann wrote: > On Fri, 02 Jun 2023 21:40:10 -0700, Steve Langasek wrote: > > > While this is not a build failure, it does mean building the package has a > > dependency on software outside of main, which I believe is a serious policy > > violation. > > The network access during build is a policy violation in itself: > > 4.9 > … > For packages in the main archive, required targets must not > attempt network access, except, via the loopback interface, to > services on the build host that have been started by the build. For posterity, I tested locally using network namespaces and described here [1]. Specifically: # create a chroot including the build-deps # (maybe there's an easier way?) sudo sbuild-createchroot --no-deb-src --chroot-mode=schroot \ --chroot-prefix=1037064 \ --include=debhelper,default-jdk,junit4,libeclipse-sisu-maven-plugin-java,libmaven-parent-java,libmaven-resolver-transport-http-java,libmaven-shared-utils-java,libmodello-maven-plugin-java,maven-debian-helper \ unstable /data/chroot/1037064-amd64-sbuild http://localhost:3142/debian # create the namespace sudo ip netns add no-net # build sudo ip netns exec no-net sbuild --no-apt-update --no-apt-upgrade \ --no-apt-distupgrade --no-run-lintian --chroot=1037064-amd64-sbuild # clean up /usr/sbin/sbuild-destroychroot 1037064-amd64-sbuild [1] https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage
Bug#1037064: marked as pending in maven-verifier
Control: tag -1 pending Hello, Bug #1037064 in maven-verifier 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/java-team/maven-verifier/-/commit/c761ab42ddbdd883306e9d72a27096a2123d0752 Disable tests requiring network access (Closes: #1037064) (this message was generated automatically) -- Greetings https://bugs.debian.org/1037064
Bug#1030129: ca-certificates-java - Fails to install with OpenJDK 21: Error loading java.security file
On Mon, Jun 12, 2023 at 06:55:49AM +0200, Sebastiaan Couwenberg wrote: > On Tue, 31 Jan 2023 13:56:42 +0100 Bastian Blank wrote: > > | dpkg: error processing package openjdk-21-jdk:arm64 (--configure): > > | dependency problems - leaving unconfigured > > It also fails to install with openjdk-17: > > Setting up ca-certificates-java (20230103) ... > Exception in thread "main" java.lang.InternalError: Error loading > java.security file > at java.base/java.security.Security.initialize(Security.java:106) > at java.base/java.security.Security$1.run(Security.java:84) > at java.base/java.security.Security$1.run(Security.java:82) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:318) > at java.base/java.security.Security.(Security.java:82) > at > java.base/sun.security.jca.ProviderList.(ProviderList.java:178) > at > java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:96) > at > java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:318) > at > java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:93) > at java.base/sun.security.jca.Providers.(Providers.java:55) > at > java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:156) > at > java.base/java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:193) > at > org.debian.security.KeyStoreHandler.(KeyStoreHandler.java:50) > at > org.debian.security.UpdateCertificates.(UpdateCertificates.java:65) > at > org.debian.security.UpdateCertificates.main(UpdateCertificates.java:51) I am not able to reproduce the failure in a clean unstable schroot with either openjdk-17 or openjdk-21 yet - for example: $ sudo sbuild-createchroot --no-deb-src --chroot-mode=schroot --chroot-prefix=test --include=default-jdk unstable /data/chroot/test-amd64-sbuild $ schroot -c test-amd64-sbuild -u root --directory /tmp /bin/bash (test-amd64-sbuild)root@lark:/tmp# dpkg -l | grep -E 'openjdk|ca-cert|default-jdk' ii ca-certificates 20230311 all Common CA certificates ii ca-certificates-java 20230103 all Common CA certificates (JKS keystore) ii default-jdk 2:1.17-74 amd64Standard Java or Java compatible Development Kit ii default-jdk-headless 2:1.17-74 amd64Standard Java or Java compatible Development Kit (headless) ii openjdk-17-jdk:amd64 17.0.7+7-1 amd64OpenJDK Development Kit (JDK) ii openjdk-17-jdk-headless:amd64 17.0.7+7-1 amd64OpenJDK Development Kit (JDK) (headless) ii openjdk-17-jre:amd64 17.0.7+7-1 amd64OpenJDK Java runtime, using Hotspot JIT ii openjdk-17-jre-headless:amd64 17.0.7+7-1 amd64OpenJDK Java runtime, using Hotspot JIT (headless) Maybe some environmental difference is causing the failure. Could it be that the java.security file has been modified on the systems where the failure is occurring? (Just a guess...) If so, could someone share the file from a system where the bug manifests? Thanks, tony
Bug#1036737: libsoapysdr0.8: please add Breaks: libsoapysdr0.7 for smoother upgrades from bullseye
On Fri, May 26, 2023 at 10:18:50PM +0200, Christoph Berg wrote: > Re: tony mancill > > In any event, I think the change is good and am planning to upload, > > provided there are no concerns from the Debian Hams. > > Looks good to me. > > Christoph Thank you Christoph. I should have run lintian sooner - it comes back: W: libsoapysdr0.8: breaks-without-version libsoapysdr0.7 N: N: This package declares a Breaks relationship with another package that has no version number. Normally, Breaks should be used to indicate an N: incompatibility with a specific version of another package, or with all versions predating a fix. If the two packages can never be installed at the same N: time, Conflicts should normally be used instead. N: N: Note this tag can also be issued if a package has been split into two completely new ones. In this case, this package is missing a Replaces on the old N: package. N: N: Please refer to Packages which break other packages - Breaks (Section 7.3) in the Debian Policy Manual, Conflicting binary packages - Conflicts (Section N: 7.4) in the Debian Policy Manual, and Bug#605744 for details. N: N: Visibility: warning N: Show-Always: no N: Check: fields/package-relations However, I trust Andreas on this one, and we can adjust as needed later. Cheers, tony signature.asc Description: PGP signature
Bug#1036737: libsoapysdr0.8: please add Breaks: libsoapysdr0.7 for smoother upgrades from bullseye
On Thu, May 25, 2023 at 03:08:22AM +0200, Andreas Beckmann wrote: > Package: libsoapysdr0.8 > Version: 0.8.1-2 > Severity: serious > Tags: patch > User: debian...@lists.debian.org > Usertags: piuparts > > The soapysdr library stacks from bullseye and bookworm are not > co-installable, but the transitive conflict behind longer dependency > chains is not always easy detectable by apt. Therefore several upgrade > paths result in old libraries being kept installed and some upgradable > packages being kept at an older version. > > Making the conflict explicit between higher scoring packages helps apt > finding a better upgrade path. > > Please consider applying the attached patch. Hi Andreas, Thank you for the patch. I have prepared a package for upload. I didn't see any problems with piuparts with the new package, but in the interest of full disclosure, I also couldn't reproduce the piuparts failure with 0.8.1-2. (Perhaps you could share the invocation you used to identify the problem?) In any event, I think the change is good and am planning to upload, provided there are no concerns from the Debian Hams. Cheers, tony signature.asc Description: PGP signature
Bug#1035850: marked as pending in groovy
Control: tag -1 pending Hello, Bug #1035850 in groovy 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/java-team/groovy/-/commit/a070c99c65ef1a1e48287bf8a34c0ab62c2a4a93 Add dependency on libjsp-api-java (Closes: #1035850) (this message was generated automatically) -- Greetings https://bugs.debian.org/1035850
Bug#1035850: groovy: missing Depends/Recommends/Suggests: libjsp-api-java ?
On Wed, May 10, 2023 at 09:15:40AM +0200, Andreas Beckmann wrote: > Package: groovy > Version: 2.4.21-7 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > 0m28.4s ERROR: FAIL: Broken symlinks: > /usr/share/groovy/lib/jsp-api.jar -> ../../java/jsp-api.jar (groovy) Thank you for the bug report Andreas. This bug was introduced when I updated the package to switch to depend on libservlet-api-java instead of libservlet3.1-java. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020429) I will add the missing dependency. Cheers, tony signature.asc Description: PGP signature
Bug#1034059: marked as pending in zstd-jni-java
On Sat, Apr 08, 2023 at 09:13:00PM +, Markus Koschany wrote: > Control: tag -1 pending > > Hello, > > Bug #1034059 in zstd-jni-java 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/java-team/zstd-jni-java/-/commit/67b4cbfab56dc775db01963cae87ca223b969b4a Hi Markus, Thank you for fixing this, both in unstable and experimental, and to Andreas for pinpointing the problem. I wanted to ask you your thoughts on whether the fix should also include updating debian/control to strictly depend on the version(s) specified in the patched pom. Without some explicit declaration of dependencies, it seems like this is going to break again, right? Thanks, tony signature.asc Description: PGP signature
Bug#1033170: libitext-rups-java: Does not work at all
Bug#1033170: marked as pending in libitext-java
Control: tag -1 pending Hello, Bug #1033170 in libitext-java 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/java-team/libitext-java/-/commit/f67a1b8530b8a46f99ef56d89e8f0a148698cae8 Remove libitext-rups-java binary package (Closes: #1033170) (this message was generated automatically) -- Greetings https://bugs.debian.org/1033170
Bug#1033170: libitext-rups-java: Does not work at all
On Mon, Mar 20, 2023 at 07:37:48AM -0700, tony mancill wrote: > However, given the low popcon count and the brokenness of the package, > that may be the best path. If there are users of libitext-rups-java who > think otherwise, now would be the time to speak up. > > ... > > Returning to the focus of this bug, let's wait to see if there are > other opinions regarding rups. If not, I will prepare an upload of the > libitext-java source package that removes the libitext-rups-java and > file the bugs needed to remove the binary. The upload is ready. Any concerns? $ reverse-depends libitext-rups-java No reverse dependencies found $ reverse-depends -b libitext-rups-java No reverse dependencies found Thanks, tony signature.asc Description: PGP signature
Bug#1033170: libitext-rups-java: Does not work at all
Hi Jorge, On Sun, Mar 19, 2023 at 10:45:32PM -0400, Jorge Moraleda wrote: > Hello Tony, > > I propose that we either reduce the severity, ignore the bug for the > > bookworm release cycle, or remove only the libitext-rups-java binary > > package from bookworm. > > > Thank you. I believe the appropriate action is #3 (remove libitext-rups-java > binary > package from bookworm) because it is useless as it stands. Action #3 (removing libitext-rups-java) makes it much more difficult to fix the bug in unstable or experimental, and will make it impossible to introduce the fix to a bookworm point release. It means that the package will have to go through NEW again to be be part of Debian. However, given the low popcon count and the brokenness of the package, that may be the best path. If there are users of libitext-rups-java who think otherwise, now would be the time to speak up. > Two other comments for the record > (1) An apt list libitext* > reveals > libitext-java/testing,unstable,testing,now 2.1.7-13 all > [installed,automatic] > libitext-rtf-java/testing,unstable,testing 2.1.7-13 all > libitext-rups-java/testing,unstable,testing 2.1.7-13 all > libitext1-java/testing,unstable,testing 1.4-7 all > libitext5-java/testing,unstable,testing 5.5.13.3-2 all > > I am not familiar with libitext, so I don't know if we really need to > maintain multiple versions of it in the repo. From the comments on the > ubuntu bug report. It appears that versions 1 and 2 are hopelessly updated, > but I do see that there are indeep packages that depend on the older > versions. Not everything is going to run on the latest version, and there are multiple versions of the package in Debian because they are needed. libitext1-java is a dependency of libdoxia-java, which is part of Maven. I don't see how the multiple itext packages are directly related to the problem with rups. > > (2) If there is a maintainer for libitext-rups-java I would suggest they > upgrade to use at least libitext5-java and then reupload to > experimental. (Version 5 is not so old, but upstream is already at 7). Upgrade requests should be filed as wishlist bugs against the source package. However, if we're going to remove libitext-rups-java from the distribution, then a potential packager could start fresh with a new, separate package for https://github.com/itext/i7j-rups. Returning to the focus of this bug, let's wait to see if there are other opinions regarding rups. If not, I will prepare an upload of the libitext-java source package that removes the libitext-rups-java and file the bugs needed to remove the binary. Thank you, tony signature.asc Description: PGP signature
Bug#1033170: libitext-rups-java: Does not work at all
On Sat, Mar 18, 2023 at 05:42:12PM -0400, Jorge Moraleda wrote: > Package: libitext-rups-java > Version: 2.1.7-13 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: jorge.moral...@gmail.com > > Dear Maintainer, > > The package does not work at all. Based on the following Ubuntu bug report it > appears the version packaged is too old to work: > https://bugs.launchpad.net/ubuntu/+source/libitext-java/+bug/802021 Hi Jorge, Thanks for filing the bug. You don't describe the desired behavior, but when I run "java -jar /usr/share/java/itext-rups.jar" I don't get a GUI for PDF manipulation, so there is definitely something broken there. By filing a severity grave [0] bug against this binary package you have created a release-critical bug that also affects libitext-java [1], which has almost 3 installs [2] and impacts multiple reverse dependencies. And we're in the midst of the freeze for the bookwork release [3]. I propose that we either reduce the severity, ignore the bug for the bookworm release cycle, or remove only the libitext-rups-java binary package from bookworm. Thank you, tony [0] https://www.debian.org/Bugs/Developer#severities [1] https://tracker.debian.org/pkg/libitext-java [2] https://qa.debian.org/popcon.php?package=libitext-java [3] https://release.debian.org/bookworm/freeze_policy.html signature.asc Description: PGP signature
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
On Tue, Feb 28, 2023 at 11:13:35PM +0100, Markus Koschany wrote: > Control: reassign -1 shrinksafe > Control: severity -1 serious > > I uploaded a new version of rhino a while ago and it seems this bug is still > relevant. I have rebuilt dojo with rhino 1.7.14 and all shrinksafe tests pass. > However the same tests fail with autopkgtest and block the migration of rhino > to testing. Could you take a look at that please? I'm not able to reproduce the autopkgtest failure locally running in clean sid chroots. First, I build the dojo source package and ran the autopkgtest against those binaries. When that didn't fail, I pulled the binary packages from the archive and ran the autopkgtest against those. Again, no failures. I see the autopkgtest failure when I run against a bookworm chroot. So it seems like the migration of rhino will resolve the test failure. (Or I'm missing something fundamental.) signature.asc Description: PGP signature
Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors
On Sun, Feb 05, 2023 at 08:14:31PM +, James Addison wrote: > Source: openjfx > Followup-For: Bug #1026962 > > Could the following build-related scripting be something to do with it? > > - > https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm#L494-499 I don't think it's this one, because nproc returns the right value on a s390x porterbox, as does /proc/cpuinfo. > - > https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/build-webkit#L300-305 YES! > (perhaps something about the way that numberOfCPUs is being evaluated on s390x > hosts isn't matching the expectations of the build script) I will try another build on the porterbox defining NUMBER_OF_PROCESSORS. Thank you for this pointer. signature.asc Description: PGP signature
Bug#1028720: marked as pending in wss4j
Control: tag -1 pending Hello, Bug #1028720 in wss4j 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/java-team/wss4j/-/commit/3f2c258f8da61894fa5bb310c4bedb70e16ab2f2 Add build-dep on liblog4j1.2-java (Closes: #1028720) (this message was generated automatically) -- Greetings https://bugs.debian.org/1028720
Bug#1026494: marked as pending in eclipse-wtp
Control: tag -1 pending Hello, Bug #1026494 in eclipse-wtp 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/java-team/eclipse-wtp/-/commit/f2b349c8d79ced9961dcf58f89cb1d22f3eff7d1 Replace IPluginRegistry with IExtensionRegistry (Closes: #1026494) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026494
Bug#1030414: marked as pending in jalview
Control: tag -1 pending Hello, Bug #1030414 in jalview 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/java-team/jalview/-/commit/261569045aacc1983b676d00d7b2ea017c401680 Update log4j dependency to use log4j2 (Closes: #1030414) (this message was generated automatically) -- Greetings https://bugs.debian.org/1030414
Bug#1028772: marked as pending in apache-directory-jdbm
Control: tag -1 pending Hello, Bug #1028772 in apache-directory-jdbm 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/java-team/apache-directory-jdbm/-/commit/8728abeab9629024acabe958a1e5a498f7d306cc Add build-dep on liblog4j1.2-java (Closes: #1028772) (this message was generated automatically) -- Greetings https://bugs.debian.org/1028772
Bug#1028752: marked as pending in openid4java
Control: tag -1 pending Hello, Bug #1028752 in openid4java 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/java-team/openid4java/-/commit/76f8613e83c51682c14044bc4cb80aacd68678f8 Add build-dep on liblog4j1.2-java (Closes: #1028752) (this message was generated automatically) -- Greetings https://bugs.debian.org/1028752
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
On Sat, Jan 28, 2023 at 11:12:15PM +0100, Alexandre Rossi wrote: > Hi, > > > The update looks good to me and a rebuild of rdeps with ratt was > > successful. Or more precisely, was successful for the packages that > > also build against 5.12.1. So I have just uploaded to the archive. > > Thanks a lot but looks like the fix was not complete. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029908 > > Can you upload a version with the fix available in the bug report? Done. This time I merged the commit from your repo on Salsa, and also ran the autopkgtest on armhf. Thank you for the quick update.
Bug#1021739: nekohtml: CVE-2022-24839
On Sat, Jan 28, 2023 at 11:35:30PM +0100, David Prévot wrote: > Hi, > > Le Thu, Oct 13, 2022 at 09:17:02PM +0200, Moritz Mühlenhoff a écrit : > > Source: nekohtml > […] > > The following vulnerability was published for nekohtml. > > > > CVE-2022-24839[0]: > > I prepared an upload (new upstream release) of this package in order to > fix this RC-bug as part of the BSP currently happening in St-Cergue, > Switzerland. A merge request has been submitted. > > https://salsa.debian.org/java-team/nekohtml/-/merge_requests/1 > > Unless advised otherwise, I intend to upload the updated package > tomorrow. Please go ahead with the upload. Thank you! signature.asc Description: PGP signature
Bug#1029622: marked as pending in tuxguitar
Control: tag -1 pending Hello, Bug #1029622 in tuxguitar 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/java-team/tuxguitar/-/commit/302bddd1ccab8dccbdb3b25014f7c727d9ffd86c Don't install maven coords in arch-any package (Closes: #1029622) (this message was generated automatically) -- Greetings https://bugs.debian.org/1029622
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
On Thu, Jan 26, 2023 at 10:55:09PM +0100, Alexandre Rossi wrote: > https://mentors.debian.net/package/libjna-java/ > > My commits are available at: https://salsa.debian.org/niol/libjna-java/ Hi Alex, The update looks good to me and a rebuild of rdeps with ratt was successful. Or more precisely, was successful for the packages that also build against 5.12.1. So I have just uploaded to the archive. I started with gbp import-dsc from the source package on mentors, so your commits are all squashed into a single commit in the update pushed to the packaging repo. If you really want them in the commit history, I can revert that commit and merge from your fork. Thank you for your work! tony signature.asc Description: PGP signature
Bug#1028374: marked as pending in libjna-java
Control: tag -1 pending Hello, Bug #1028374 in libjna-java 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/java-team/libjna-java/-/commit/2fa30b773accbe2c7cf2453ac89c77c1ca3b4163 Import Debian changes 5.13.0-0.1 libjna-java (5.13.0-0.1) unstable; urgency=medium . * Non-maintainer upload. * add basic quickstart autopkgtest * add debug output to autopkgtest helloworld log * fix getMultiArchPath() for aarch64, armhf and ppc64el (Closes: #1028374) * New upstream version 5.13.0 * unfuzz patches * use dpkg facilities for multiarch vars * declare compliance to standards-version 4.6.2 (no change) * add Rules-Require-Root * force creation of lib symlinks to avoid build error * source-is-missing for HTML is false positive (this message was generated automatically) -- Greetings https://bugs.debian.org/1028374
Bug#1029622: tuxguitar-alsa fails to install
On Wed, Jan 25, 2023 at 08:45:55PM +0100, Helmar Gerloni wrote: > Hi Tony, > > sorry for causing so much work with tuxguitar, and thanks for your efforts! > > Do you think it would make sense to merge all the tuxguitar* packages into > one package tuxguitar with arch-any? Maybe this would solve these build > problems. > > I could try this out and put a new package on mentors; just let me know. Hi Helmar, I think a patch like the one below is going to take care of the conflicting files. I need to do some piuparts testing and then I will upload again. Also, I'm considering of excluding mipsel and mips64el from the build architectures in the next upload. Any concerns? Thank you, tony -- diff --git a/debian/rules b/debian/rules index 9482c1d..d6c3076 100755 --- a/debian/rules +++ b/debian/rules @@ -21,3 +21,7 @@ override_dh_auto_configure: override_dh_auto_build: dh_auto_build --sourcedirectory=build-scripts/tuxguitar-linux-x86_64 -- -e clean verify -Dnative-modules=true docbook-to-man misc/tuxguitar.sgml > debian/tuxguitar.1 + +override_dh_install-arch: + dh_auto_install + -rf -rfv ./debian/tuxguitar-alsa/usr/share/maven-repo signature.asc Description: PGP signature
Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64
Hi Alex, On Thu, Jan 26, 2023 at 10:55:09PM +0100, Alexandre Rossi wrote: > Hi, > > I prepared an updated package with the new upstream version. > > https://mentors.debian.net/package/libjna-java/ > > My commits are available at: https://salsa.debian.org/niol/libjna-java/ I will take a look. Thank you for contribution to Debian! Cheers, tony signature.asc Description: PGP signature
Bug#1029622: tuxguitar-alsa fails to install
Hi Helmar, On Wed, Jan 25, 2023 at 08:45:55PM +0100, Helmar Gerloni wrote: > Hi Tony, > > sorry for causing so much work with tuxguitar, and thanks for your efforts! No worries at all! You've done a lot of work on the package, so we will get it ironed out in time for the release. > Do you think it would make sense to merge all the tuxguitar* packages > into one package tuxguitar with arch-any? Maybe this would solve these > build problems. This is similar to my original proposal for 1029476, except I was merely switching all of the arch-all packages to arch-any. I can confirm that that approach builds correctly and the package installs and can be upgraded. It has the disadvantage of using more space on the mirrors and also a bit more time on the buildd machines, since the arch-all bits are duplicated. The advantage to your proposal of a single package is that it would also resolve the build issue, be be a bit simpler for users, and also make it easier for us to add new modules, since the package wouldn't have to go back through the NEW queue. The disadvantage would be the same in terms of space, but more importantly that installing tuxguitar would require installing the transitive dependencies of all of the plugins. I assume they are all co-installable, but I can imagine bug reports from ALSA or OSS users not wanting to have to install jack libraries. The question of the transitive dependencies from a single tuxguitar package is probably the most important one to consider. Maybe it's not so bad? I need to try to see. > I could try this out and put a new package on mentors; just let me know. Do you have a Salsa user account? If so, you could push a branch of https://salsa.debian.org/java-team/tuxguitar and we could collaborate that way. But mentors is fine too. But either mechanism works fine. If you have thoughts about the transitive dependencies of the single package vs. converting tuxguitar and tuxguitar-jsa to arch-any, let me know. Otherwise I will take a look at the single package approach over the next couple days. Cheers, tony signature.asc Description: PGP signature
Bug#1028170: marked as pending in maven-doxia-tools
Control: tag -1 pending Hello, Bug #1028170 in maven-doxia-tools 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/java-team/maven-doxia-tools/-/commit/76b2cb1d123a914a31d4ffaed44ce0b77684a1c7 Drop libmaven-doxia-tools-java-doc package (Closes: #1028170) (this message was generated automatically) -- Greetings https://bugs.debian.org/1028170
Bug#1028166: commons-configuration: Build-depends on NBS package about to FTBFS
On Sat, Jan 07, 2023 at 05:24:30PM -0800, tony mancill wrote: > $ reverse-depends -b -l libcommons-vfs-java > commons-configuration > commons-configuration2 > ivy > mondrian > sbt-ivy Bah, this should have been: $ reverse-depends -l -b libcommons-vfs-java-doc commons-configuration commons-configuration2 So even less to fix-up than I initially thought.
Bug#1028168: marked as pending in commons-configuration2
Control: tag -1 pending Hello, Bug #1028168 in commons-configuration2 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/java-team/commons-configuration2/-/commit/3f994132b1204a09b608a6be582bae13f58772a1 Drop libcommons-configuration2-java-doc (Closes: #1028168) (this message was generated automatically) -- Greetings https://bugs.debian.org/1028168
Bug#1028166: commons-configuration: Build-depends on NBS package about to FTBFS
Hi Scott, On Sat, Jan 07, 2023 at 07:08:10PM -0500, Scott Kitterman wrote: > Source: commons-configuration > Version: 1.10-5 > Severity: serious > Tags: ftbfs > Justification: fails to build from source > > > * source package commons-vfs version 2.1-4 no longer builds > binary package(s): libcommons-vfs-java-doc > on all > - broken Build-Depends: > commons-configuration: libcommons-vfs-java-doc > > Once libcommons-vfs-java-doc is decrufted, this package will not longer > build. Thank you for filing these bugs. I will take care of them, as this is some left-over work from my upload of commons-vfs in response to its FTBFS when libcommons-net-java-doc was dropped. Assuming I've caught them all (below), the transitive dependency graph doesn't have too many nodes, and we should be able to remove these Java -doc packages fairly quickly. For context, cleaning up these -doc packages is something that members of the Java Team have proposed in the past. Now is the time... Thanks, tony $ reverse-depends -b -l libcommons-vfs-java commons-configuration commons-configuration2 ivy mondrian sbt-ivy $ reverse-depends -b -l libcommons-configuration-java-doc doxia libowasp-esapi-java $ reverse-depends -b -l libcommons-configuration2-java-doc (null) $ reverse-depends -b -l ivy-doc (null) $ reverse-depends -b -l libowasp-esapi-java-doc (null) There is no libmondrian-java-doc package. And on the doxia side: $ reverse-depends -b -l libdoxia-java-doc doxia-sitetools maven-doxia-tools maven-reporting-impl $ reverse-depends -b -l libdoxia-sitetools-java-doc (null) $ reverse-depends -b -l libmaven-doxia-tools-java-doc (null) $ reverse-depends -b -l libmaven-reporting-impl-java-doc (null) signature.asc Description: PGP signature
Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors
On Sat, Dec 24, 2022 at 05:25:40PM -0800, tony mancill wrote:
> On Sat, Dec 24, 2022 at 08:22:43PM +0100, Aurelien Jarno wrote:
> > Source: openjfx
> > Version: 11.0.11+0-1.1
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the
> > past)
> >
> > openjfx tries to build with -j64 on zani.debian.org, which only has 2
> > processors and 8GB of RAM:
> >
> > buildd 3853047 0.0 0.0 67668 4 ?S11:07 0:00 cmake
> > --build
> > /build/openjfx-fzmlCD/openjfx-11.0.11+1/modules/javafx.web/build/linux/Release
> > --config Release -- -j64
> > buildd 3853048 0.0 0.0 3200 272 ?S11:07 0:00
> > /usr/bin/gmake -f Makefile -j64
> >
> > This hogs the buildd resources and we had to kill the build.
>
> Yeah, that seems excessive. FWIW, the most recent upload didn't change
> anything related to the build options, so this has built successfully in
> the past.
>
> It built successfully on armel with the auto-detected value -j4, so it's
> surprising to see it pick 64 if there are only 2 processors. The only
> reference to the number of compile threads is this bit of Groovy from
> build.gradle:
>
> defineProperty("NUM_COMPILE_THREADS",
> "${Runtime.runtime.availableProcessors()}")
>
> I will have a look to try to determine where the value of 64 is coming
> from. We can clamp the value if need be.
I have been poking at this and the issue isn't with NUM_COMPILE_THREADS.
It appears that cmake is picking the value of 64 all by itself, and it
doesn't respect CMAKE_BUILD_PARALLEL_LEVEL when it is set in the build
environment. So perhaps cmake has changed.
In any event, I will continue to look for a way to avoid this on s390x.
Bug#1027484: marked as pending in commons-vfs
Control: tag -1 pending Hello, Bug #1027484 in commons-vfs 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/java-team/commons-vfs/-/commit/7fee8074bb22c05e9ba80bae54402b3278f3492d Drop libcommons-vfs-java-doc (Closes: #1027484) (this message was generated automatically) -- Greetings https://bugs.debian.org/1027484
Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors
On Sat, Dec 24, 2022 at 08:22:43PM +0100, Aurelien Jarno wrote:
> Source: openjfx
> Version: 11.0.11+0-1.1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>
> openjfx tries to build with -j64 on zani.debian.org, which only has 2
> processors and 8GB of RAM:
>
> buildd 3853047 0.0 0.0 67668 4 ?S11:07 0:00 cmake
> --build
> /build/openjfx-fzmlCD/openjfx-11.0.11+1/modules/javafx.web/build/linux/Release
> --config Release -- -j64
> buildd 3853048 0.0 0.0 3200 272 ?S11:07 0:00
> /usr/bin/gmake -f Makefile -j64
>
> This hogs the buildd resources and we had to kill the build.
Yeah, that seems excessive. FWIW, the most recent upload didn't change
anything related to the build options, so this has built successfully in
the past.
It built successfully on armel with the auto-detected value -j4, so it's
surprising to see it pick 64 if there are only 2 processors. The only
reference to the number of compile threads is this bit of Groovy from
build.gradle:
defineProperty("NUM_COMPILE_THREADS",
"${Runtime.runtime.availableProcessors()}")
I will have a look to try to determine where the value of 64 is coming
from. We can clamp the value if need be.
Cheers,
tony
signature.asc
Description: PGP signature
Bug#1026726: apache-directory-api: FTBFS: [ERROR] /<>/ldap/client/api/src/main/java/org/apache/directory/ldap/client/api/LdapNetworkConnection.java:[4018,22] cannot find symbol
On Tue, Dec 20, 2022 at 06:32:07PM +0100, Lucas Nussbaum wrote: > Source: apache-directory-api > Version: 1.0.0-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20221220 ftbfs-bookworm The FTBFS is due to the recent upload of mina2 [1] that updates the library from 2.1.x. When addressing this bug, also see #1026713. [1] https://tracker.debian.org/news/1399061/accepted-mina2-221-1-source-into-unstable/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026713
Bug#1026510: marked as pending in openjfx
Control: tag -1 pending Hello, Bug #1026510 in openjfx 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/java-team/openjfx/-/commit/e24ba0fd908e63ed6c241f80898e09f0c76894df Add patch to address javadoc FTBFS (Closes: #1026510) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026510
Bug#1026685: marked as pending in streamex
Control: tag -1 pending Hello, Bug #1026685 in streamex 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/java-team/streamex/-/commit/7b9d35e3a7ffdee89230974fa20b8622315c33bf Address test failures on Java 17 (Closes: #1026685) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026685
Bug#1026735: clusterssh: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255
Hi Gregor,
On Tue, Dec 20, 2022 at 07:31:55PM +0100, gregor herrmann wrote:
> Control: tag -1 + confirmed upstream
>
> On Tue, 20 Dec 2022 18:28:10 +0100, Lucas Nussbaum wrote:
>
> > Source: clusterssh
> > Version: 4.16-3
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20221220 ftbfs-bookworm
>
> > > # Failed test 'returned ok'
> > > # at t/15config.t line 546.
> > > # got: 'die'
> > > # expected: 'return'
> > >
> > > # Failed test 'Expecting no STDERR'
> > > # at t/15config.t line 550.
> > > # got: ''
> > > # expected: 'Unable to write default $HOME/.clusterssh/config: Is a
> > > directory
> > > #
> > > # '
> > > # Looks like you failed 2 tests of 155.
> > > t/15config.t ..
>
> > > # check failure to write default config is caught
> > > not ok 147 - returned ok
> > > ok 148 - An object of class 'App::ClusterSSH::Config' isa
> > > 'App::ClusterSSH::Config'
> > > ok 149 - An object of class 'App::ClusterSSH::Config' isa
> > > 'App::ClusterSSH::Config'
> > > ok 150 - Expecting no STDOUT
> > > not ok 151 - Expecting no STDERR
>
> > > Test Summary Report
> > > ---
>
> > > t/15config.t(Wstat: 512 (exited 2) Tests: 155 Failed: 2)
> > > Failed tests: 147, 151
> > > Non-zero exit status: 2
>
> This reminds me of #1025722 in duck and is probably also caused by
> this change in perl:
>
> perl (5.36.0-5) unstable; urgency=medium
>
> * Backported upstream changes:
> + only clear the stream error state in readline() for glob()
> (Closes: #1016369)
>
> The problem seems to be in lines 384 ff in write_user_config_file()
> in lib/App/ClusterSSH/Config.pm:
>
>341 sub write_user_config_file {
>
>384 # Debian #673507 - migrate clusters prior to writing
> ~/.clusterssh/config
>385 # in order to update the extra_cluster_file property
>386 if (%old_clusters) {
>387 if ( open( my $fh, ">", "$ENV{HOME}/.clusterssh/clusters" ) )
> {
>388 print $fh '# '
>389 . $self->loc('Tag definitions moved from old .csshrc
> file'),
>390 $/;
>391 foreach ( sort( keys(%old_clusters) ) ) {
>392 print $fh $_, ' ', join( ' ', $old_clusters{$_} ), $/;
>393 }
>394 close($fh);
>395 }
>396 else {
>397 croak(
>398 App::ClusterSSH::Exception::Config->throw(
>399 error => $self->loc(
>400 'Unable to write [_1]: [_2]' . $/,
>401 '$HOME/.clusterssh/clusters',
>402 $!
>403 ),
>404 ),
>405 );
>406 }
>407 }
>
>
> As #673507 is from 2012, I guess this code (and the tests) can be
> removed?
I think reference to #673507 is merely for context and that the behavior
implemented (with respect to the configuration file location and logic)
is the desired behavior.
Thank you for the pointer to the bug in duck [1]. I'll work on a patch.
Cheers,
tony
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025722
signature.asc
Description: PGP signature
Bug#1026666: marked as pending in apache-log4j2
Control: tag -1 pending Hello, Bug #102 in apache-log4j2 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/java-team/apache-log4j2/-/commit/09c0a7960e19ebad434b181d5b66f7932b815fde Ignore junit-bom (Closes: #102) (this message was generated automatically) -- Greetings https://bugs.debian.org/102
Bug#1026666: Please make liblog4j2-java depend on junit5
Hi Pierre, On Thu, Dec 22, 2022 at 07:31:30AM +0100, Pierre Gruet wrote: > Hi tony, > > Le 21/12/2022 à 22:58, tony mancill a écrit : > > On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote: > > > Control: retitle -1 Please make liblog4j2-java depend on junit5 > > > > > > Hello, > > > > > > In version 2.19.0-1 of liblog4j2-java, the file > > > > > > /usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom > > > declares the junit-bom artifact as a dependency. It is shipped in junit5. > > > > > > If this dependency is not added, reverse dependencies of liglog4j2-java > > > fail > > > to build (see logs above) as the junit-bom artifact is not found. > > > > Hi Pierre, > > > > I'm wondering if it wouldn't better to remove junit-bom from log4j pom. > > I don't believe we actually need junit5 at runtime for log4j2, so > > packages depending on liblog4j2-java should not have to install junit5. > > > > Any concerns with taking that approach and addressing the bug by > > adjusting the pom shipped with liblog4j2-java? > > Thanks for having a look; I haven't looked further but I also fail to > imagine why junit5 would be needed, so I agree with the proposed fix! I am spot-checking a few of the reverse dependencies now and will upload today. Thank you for identifying the root cause for this set of build failures. Cheers, tony signature.asc Description: PGP signature
Bug#1026710: marked as pending in libspin-java
Control: tag -1 pending Hello, Bug #1026710 in libspin-java 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/java-team/libspin-java/-/commit/deb647bf1470caf642b7e44a99b29b9e9042ac08 Address FTBFS by exporting modules to tests (Closes: #1026710) (this message was generated automatically) -- Greetings https://bugs.debian.org/1026710
Bug#1026666: Please make liblog4j2-java depend on junit5
On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote: > Control: retitle -1 Please make liblog4j2-java depend on junit5 > > Hello, > > In version 2.19.0-1 of liblog4j2-java, the file > > /usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom > declares the junit-bom artifact as a dependency. It is shipped in junit5. > > If this dependency is not added, reverse dependencies of liglog4j2-java fail > to build (see logs above) as the junit-bom artifact is not found. Hi Pierre, I'm wondering if it wouldn't better to remove junit-bom from log4j pom. I don't believe we actually need junit5 at runtime for log4j2, so packages depending on liblog4j2-java should not have to install junit5. Any concerns with taking that approach and addressing the bug by adjusting the pom shipped with liblog4j2-java? Thanks, tony signature.asc Description: PGP signature
Bug#1026617: marked as pending in libjt400-java
Control: tag -1 pending Hello, Bug #1026617 in libjt400-java 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/java-team/libjt400-java/-/commit/951604f34305c1bfb004d407bd54812c18202394 Add patch to complie on Java 17 (Closes: #1026617) Thank you to Hans Joachim Desserud for the patch. (this message was generated automatically) -- Greetings https://bugs.debian.org/1026617
Bug#1026617: libjt400-java: FTBFS: [javac] /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:149: error: reference to Record is ambiguous
On Wed, Dec 21, 2022 at 12:07:24PM +0100, Hans Joachim Desserud wrote: > tags 1026617 patch > thanks > > > [javac] both class com.ibm.as400.access.Record in > > com.ibm.as400.access and class java.lang.Record in java.lang match > > [javac] > > /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:1375: > > error: reference to Record is ambiguous > > Looks like the ambiguity stems from the new Record class introduced in new > JDKS which hit when rebuilt with JDK 17. See the attached patch which adds > an explicit import to the "local" Record class, which has been the one > imported up until now. > > With this patch in place, the package builds successfully again on Debian > Sid. Thank you for the patch! Applied and uploaded. Cheers, tony signature.asc Description: PGP signature
Bug#1025836: byte-buddy: build-depends on dropped package
Hi Peter, On Sat, Dec 10, 2022 at 09:17:50AM +, Peter Green wrote: > Source: byte-buddy > Version: 1.8.2-2 > Severity: serious > Tags: bookworm, sid > Justification: rc policy - "Packages must be buildable within the same > release" > User:debian...@lists.debian.org > Usertags: edos-uninstallable > > byte-buddy build-depends on libasm-java-doc which is longer built by the asm > source > package. It is still present in unstable as a cruft package, but is > completely gone > from testing. This means that byte-buddy in testing is in violation of the rc > policy. Thank you for the bug report. I will upload an update to byte-buddy that drops its -doc package, and since nothing depends on it, that should stop the cascade... $ reverse-depends -b libbyte-buddy-java-doc No reverse dependencies found Cheers, tony
Bug#1024768: libphonenumber: FTBFS after switch to debhelper
Source: libphonenumber Version: 8.12.57+ds-2 Severity: serious Creating this for tracking and coordination purposes. After this [1] upload, libphonenumber is FTBFS. Please refer to the buildd logs [2]. [1] https://tracker.debian.org/news/1389357/accepted-libphonenumber-81257ds-2-source-into-unstable/ [2] https://buildd.debian.org/status/package.php?p=libphonenumber
Bug#1024701: libphonenumber8 update breaks evolution
On Wed, Nov 23, 2022 at 03:26:12PM +, Stephan Verbücheln wrote: > From changelog: > > libphonenumber (8.12.57+ds-1+b1) sid; urgency=low, binary-only=yes > > * Binary-only non-maintainer upload for amd64; no source changes. > * Rebuild against libicu72 > > -- amd64 / i386 Build Daemon (x86-csail-01) > Wed, 09 Nov 2022 > 09:06:01 + Yes. That build is from a previous transition, the one prior to the protobuf transition. signature.asc Description: PGP signature
Bug#1024701: libphonenumber8 update breaks evolution
On Wed, Nov 23, 2022 at 01:45:26PM +, Stephan Verbücheln wrote: > Evolution gives the following confusing error message. > > $ evolution > evolution: symbol lookup error: /lib/x86_64-linux-gnu/libebook- > contacts-1.2.so.4: undefined symbol: > _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE > > However, libebook-contacts has not changed recently. Hello Stephan, libebook-contacts needs a rebuild as part of the protobuf transition. The reason for the recent breakage is that libphonenumber, which also hasn't changed recently, was rebuilt for the transition [1]. You can find more information in Debian bug #1024674 [2]. Thank you for opening this bug against libphonenumber8 for better visibility. Cheers, tony [1] https://buildd.debian.org/status/fetch.php?pkg=libphonenumber=amd64=8.12.57%2Bds-1%2Bb2=1669158118=0 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024674 signature.asc Description: PGP signature
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 06:28:04AM +0100, Christoph Anton Mitterer wrote: > On Tue, 2022-11-22 at 21:11 -0800, tony mancill wrote: > > I guess it must be doing some kind of dynamic loading stuff? OTOH, it > seems to be just linked as a plain shared lib: > $ libtree /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4.0.0 > libebook-contacts-1.2.so.4 > ├── libedataserver-1.2.so.27 [ld.so.conf] > ... > ├── libphonenumber.so.8 [ld.so.conf] > │ ├── libprotobuf.so.23 [ld.so.conf] > │ │ └── libz.so.1 [ld.so.conf] > │ ├── libabsl_throw_delegate.so.20220623 [ld.so.conf] > │ ├── libabsl_strings.so.20220623 [ld.so.conf] > │ │ ├── libabsl_strings_internal.so.20220623 [ld.so.conf] > │ │ │ └── libabsl_raw_logging_internal.so.20220623 [ld.so.conf] > │ │ ├── libabsl_raw_logging_internal.so.20220623 [ld.so.conf] > │ │ └── libabsl_throw_delegate.so.20220623 [ld.so.conf] > │ ├── libabsl_raw_hash_set.so.20220623 [ld.so.conf] > │ ├── libabsl_hash.so.20220623 [ld.so.conf] > │ │ ├── libabsl_city.so.20220623 [ld.so.conf] > │ │ └── libabsl_low_level_hash.so.20220623 [ld.so.conf] > │ ├── libicui18n.so.72 [ld.so.conf] > │ └── libicuuc.so.72 [ld.so.conf] > ... > > > Yes... at least evolution, but that's the only thing I have, which > depends on it. I notice that libebook-contacts wasn't part of of the protobuf transition [1], but it seems like it should have been a level 3 dependency. I'm not sure whether that's an issue with the transition tooling or if we're missing sufficient linkage between the packages. [1] https://release.debian.org/transitions/html/auto-protobuf.html > Maybe we should increase the severity, so that people will see it at > least via apt-listbugs? Ah, that's a good idea if we want to notify folks not to install libphonenumber8. Perhaps I shouldn't have reassigned the bug to evolution-data-server. Maybe we should create a new bug (or clone this one) and assign it to libphonenumber8?
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 05:02:16AM +0100, Christoph Anton Mitterer wrote: > Package: libphonenumber8 > Version: 8.12.57+ds-1+b2 > Severity: serious > > After the upgrade, evolution crashes when started: > $ evolution > evolution: symbol lookup error: > /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: > _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE This issue goes away for me after a rebuild of src:evolution-data-server and installing the freshly rebuilt libebook-contacts-1.2-4. Maybe we can kick off a rebuild via the transition. If not that, would you be willing to do a sourceful upload Jeremy? signature.asc Description: PGP signature
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 05:02:16AM +0100, Christoph Anton Mitterer wrote: > After the upgrade, evolution crashes when started: > $ evolution > evolution: symbol lookup error: > /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: > _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE Weird that it didn't fail the first time, but I'm seeing the same failure now, both with the auto-transition build and with a rebuild on my local system.
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 05:51:50AM +0100, Christoph Anton Mitterer wrote: > Hey Tony. > > On Tue, 2022-11-22 at 20:40 -0800, tony mancill wrote: > > Thank you for the bug report. libphonenumber 8.12.57+ds-1 has been > > in > > testing for longer than a month at this point [1]. Has it been > > broken > > all of this time? If not, I suspect this is related the protobuf > > transition [2]. > > No, it was fine all the time with 8.12.57+ds-1+b1 (and backporting to > it fixes the issue, too). Only 8.12.57+ds-1+b2 introduced the problem. Good to know. I will start by picking through the build logs here: https://buildd.debian.org/status/fetch.php?pkg=libphonenumber=amd64=8.12.57%2Bds-1%2Bb2=1669158118=0 > But given that the dependency for evolution (or rather libebook- > contacts-1.2-4) I thought the starting point of "responsibility" (in > terms of package dependencies) should be there. Yes, totally. I didn't mean to imply that the bug shouldn't be here. > > I'm not seeing the crash here, but I'm running vanilla unstable and > > not > > unstable-debug > > I don't think this makes a difference... the unstable-debug is just > there because I have the debug repo enabled, but the packages are from > unstable: > > APT policy: (500, 'unstable-debug'), (500, 'unstable') (nodding) > I had evolution running, while I've upgraded. And didn't restart it > afterwards (at least not immediately). > > I then noticed some weird things... when replying to a mail, there was > no quoting of the mail I replied to (i.e. I got a new compose window, > but no text in it). > Also I couldn't save my composed mail as draft (some strange error > popup within evolution itself). Interesting... > Since I suspected some issues, I restarted evolution, and only then > I've noticed the libphonenumber related error I've mentioned in the > initial mail. Ugh, so it's completely broken for you now. > Perhaps we should get the protobuf people on board in this issue? I have added Laszlo to the cc: I'm rebuilding locally against the 3.21.9-4 protobuf sources to attempt to reproduce the bug. Thank you, tony signature.asc Description: PGP signature
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 05:02:16AM +0100, Christoph Anton Mitterer wrote: > Package: libphonenumber8 > Version: 8.12.57+ds-1+b2 > Severity: serious > > > Hey. > > After the upgrade, evolution crashes when started: > $ evolution > evolution: symbol lookup error: > /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: > _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE > > and it even ended up in a weird state while it was still running. Hi Chris, Thank you for the bug report. libphonenumber 8.12.57+ds-1 has been in testing for longer than a month at this point [1]. Has it been broken all of this time? If not, I suspect this is related the protobuf transition [2]. I'm not seeing the crash here, but I'm running vanilla unstable and not unstable-debug, so perhaps that's a clue. You mention that it crashes and that it ends up in a weird state while it's running. Does that mean it crashes and exits sometimes? Or that logs an error and continues running? Thank you, tony P.S. Not directly related, but I have a package for 8.13.0 ready to upload, but have been waiting for the transition to complete. [1] https://tracker.debian.org/pkg/libphonenumber [2] https://release.debian.org/transitions/html/auto-protobuf.html signature.asc Description: PGP signature
Bug#1022388: marked as pending in jacoco
Control: tag -1 pending Hello, Bug #1022388 in jacoco 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/java-team/jacoco/-/commit/8bebb2cfb6235a3ac2539fdef9de611680314be9 Add patch to skip license check for interim pom (Closes: #1022388) (this message was generated automatically) -- Greetings https://bugs.debian.org/1022388
Bug#1021935: syncany: FTBFS: Could not resolve javax.servlet:javax.servlet-api:4.0.1.
On Mon, Oct 17, 2022 at 05:06:01PM +0200, Andreas Beckmann wrote: > Source: syncany > Version: 0.4.9~alpha-4 > Severity: serious > Tags: ftbfs > Justification: fails to build from source > > Hi, > > syncany recently started to FTBFS: Hello Andreas, Thank you for the bug report. I'm not sure what has changed recently in the toolchain to explain this, but it was fairly easy to get it building again. For any syncany users out there, is there any reason to continue to upload to experimental? Is there anything preventing an upload to unstable? Cheers, tony signature.asc Description: PGP signature
Bug#1019340: Segfaults on startup
On Wed, Sep 07, 2022 at 04:57:14PM +0200, Christoph Berg wrote: > Package: tucnak > Version: 4.36-1 > Severity: grave > > tucnak doesn't start here: > > $ LC_ALL=C tucnak Hi Christoph, Hmm... it starts and runs here, so I don't think it is broken for everyone. I uninstalled and reinstalled to be sure that I'm running the binaries from the archive. Perhaps related to differences in windowing setups? I'm running xwayland and Gnome. Looking at your stack trace, my first guess is that this is an issue introduced in libzia based on this bit. > #11 0x7febdc0654f8 n/a (libSDL2-2.0.so.0 + 0x314f8) > #12 0x5586f25c0438 tucnak_crash (tucnak + 0xb0438) > #13 0x7febdc3589d4 z_sig_segv (libzia-4.36.so + 0x169d4) > #14 0x7febdaa3daf0 __restore_rt (libc.so.6 + 0x3daf0) > #15 0x7febd5ead5ee n/a (crocus_dri.so + 0xad5ee) > #16 0x7febd80836e6 glPrimitiveBoundingBox > (libGLX_mesa.so.0 + 0x4e6e6) > #17 0x7febd8085d32 glPrimitiveBoundingBox > (libGLX_mesa.so.0 + 0x50d32) > #18 0x7febd80860d3 glPrimitiveBoundingBox > (libGLX_mesa.so.0 + 0x510d3) > #19 0x7febd5eaf0df n/a (crocus_dri.so + 0xaf0df) I will poke through the libzia changes. Thanks, tony
Bug#1014310: src:openjfx: fails to migrate to testing for too long: FTBFS on arm64 and armhf
Hi Paul, On Sat, Aug 13, 2022 at 09:51:03PM +0200, Paul Gevers wrote: > Hi, > > On Sun, 3 Jul 2022 21:25:49 +0200 Paul Gevers wrote: > > Your package failed to build from source on arm64 and armhf while it > > built there successfully in the past. > > I just checked to see if there would be a commit upstream to fix the FTBFS, > but it seems that upstream is active and is at release 20+1 (from 16 days > ago), but in a new place (so the debian/watch file isn't working). > > https://github.com/openjdk/jfx For JDK 11, I believe we want https://github.com/openjdk/jfx11u For JDK 17, it would be https://github.com/openjdk/jfx17u > You may want to look into this. Agreed. Java Team, should we be targeting OpenJFX 17 for bookworm, or is an updated build of OpenJFX 11 of use? signature.asc Description: PGP signature
Bug#1014597: libitext5-java: new version 5.5.13.3 addresses CVE-2021-43113
Hello Thomas, On Fri, Jul 08, 2022 at 04:00:20PM +0200, Thomas Uhle wrote: > Package: libitext5-java > Version: 5.5.13.2-1 > Severity: serious > Tags: security upstream > X-Debbugs-Cc: t...@security.debian.org > Control: found -1 5.5.13-1 > > Dear maintainers, > > there is a new bugfix release upstream for iText 5. In particular, it > addresses CVE-2021-43113. The new version 5.5.13.3 has been announced on > Maven as well as on Github at https://github.com/itext/itextpdf/releases for > instance. Please consider to also update the binary package for bullseye and > perhaps for buster too. Thank you for the bug report. I am preparing an upload of 5.5.13.3 now. > Could you please also pay attention to my other bug ticket #983715 and > consider to package itext-xtra along with the other jar files, at least for > bookworm. I will take a look at this after the version update. Thank you for the reminder. Best regards, tony signature.asc Description: PGP signature
Bug#1010657: google-oauth-client-java: CVE-2021-22573 - IdTokenVerifier does not verify the signature of ID Token
Hi Markus, On Mon, May 16, 2022 at 12:52:59AM +0200, Markus Koschany wrote: > Hi tony, > > Am Sonntag, dem 15.05.2022 um 11:17 -0700 schrieb tony mancill: > > > [...] > > Any thoughts? It's a tad messy either way, but using current versions > > simplifies the porting of patches. > > I haven't investigated the CVE closely enough but the current reverse- > dependencies in Bullseye don't seem to be severely affected by it. bazel- > bootstrap and libgoogle-api-client-java are more like leaf packages unless we > take openrefine in bullseye-backports into consideration as well. > > We could also mark the CVE as ignored for Bullseye because of the minor > impact, > or just upload the new google-http-client-java package to bullseye after > approval by the release team and then update google-oauth-java-client as well. > We just have to check if this breaks the two other packages in Bullseye > (bazel- > bootstrap and google-api-client-java). > > So yes, a newer upstream version is fine, if it does not break any existing > packages and there is no other way or the alternative would be way too time > consuming and inconvenient. That is a good suggestion to potentially mark the CVE as ignored. Unless there is a specific need for the updates in bullseye, I don't have a reason to push the issue. I wanted to address the CVE in testing/unstable, and didn't want to just disappear and ignore the issue for the other suites. And if there is a compelling need for the updates to land in bullseye, we can revisit. Thanks! signature.asc Description: PGP signature
