Bug#1071675: duplicity: SSH broken with Paramiko 3.4
On Fri, May 24, 2024 at 09:05:17AM +1000, Alexander Zangerl wrote:
> tags 1071675 +moreinfo +unreproducible
> severity 1071675 normal
> thanks
>
> On Thu, 23 May 2024 18:16:58 +0200, Fiona Klute writes:
> >When trying to do backup to an sftp:// target Duplicity fails since
> >python3-paramiko was updated to 3.4.0-1, with the following error which
> >looks like an API change in Paramiko:
>
> i cannot reproduce this problem. please provide the output of a
> duplicity -v9 run and the ssh key types involved on your target machine.
Hi,
It's happening here too, for backups using an ed25519 SSH key that has
worked with duplicity in the past. The same key works correctly with
the backend via openssh-client. If it makes a difference, the ssh
server is rsync.net.
Requested debug output attached. Thank you for taking a look. (I think
the severity should be important; duplicity fails for one of its primary
use cases.)
Thanks,
tony
duplicity -v9 backup --name foo /some/path
scp://u...@user.rsync.net/some/other/path
GPG binary is /usr/bin/gpg, version 2.2.43
Import of duplicity.backends.adbackend Succeeded
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.b2backend Succeeded
Import of duplicity.backends.boxbackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.dpbxbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.gdrivebackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.idrivedbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.jottacloudbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.mediafirebackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.megav2backend Succeeded
Import of duplicity.backends.megav3backend Succeeded
Import of duplicity.backends.multibackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Succeeded
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pcabackend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rclonebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.s3_boto3_backend Succeeded
Import of duplicity.backends.slatebackend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.xorrisobackend Succeeded
ssh: starting thread (client mode): 0xca27ed0
ssh: Local version/idstring: SSH-2.0-paramiko_3.4.0
ssh: Remote version/idstring: SSH-2.0-OpenSSH_8.9-hpn14v15
FreeBSD-openssh-portable-8.9.p1_3,1
ssh: Connected (version 2.0, client OpenSSH_8.9-hpn14v15)
ssh: === Key exchange possibilities ===
ssh: kex algos: curve25519-sha256, curve25519-sha...@libssh.org,
ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521,
sntrup761x25519-sha...@openssh.com, diffie-hellman-group-exchange-sha256,
diffie-hellman-group16-sha512, diffie-hellman-group18-sha512,
diffie-hellman-group14-sha256
ssh: server key: ecdsa-sha2-nistp256, ssh-ed25519, rsa-sha2-512, rsa-sha2-256,
ssh-rsa
ssh: client encrypt: chacha20-poly1...@openssh.com, aes128-ctr, aes192-ctr,
aes256-ctr, aes128-...@openssh.com, aes256-...@openssh.com, none
ssh: server encrypt: chacha20-poly1...@openssh.com, aes128-ctr, aes192-ctr,
aes256-ctr, aes128-...@openssh.com, aes256-...@openssh.com, none
ssh: client mac: umac-64-...@openssh.com, umac-128-...@openssh.com,
hmac-sha2-256-...@openssh.com, hmac-sha2-512-...@openssh.com,
hmac-sha1-...@openssh.com, umac...@openssh.com, umac-...@openssh.com,
hmac-sha2-256, hmac-sha2-512, hmac-sha1
ssh: server mac: umac-64-...@openssh.com, umac-128-...@openssh.com,
hmac-sha2-256-...@openssh.com, hmac-sha2-512-...@openssh.com,
hmac-sha1-...@openssh.com, umac...@openssh.com, umac-...@openssh.com,
hmac-sha2-256, hmac-sha2-512, hmac-sha1
ssh: client compress: none, z...@openssh.com
ssh: server compress: none, z...@openssh.com
ssh: client lang:
ssh: server lang:
ssh: kex follows: False
ssh: === Key exchange agreements ===
ssh: Kex: curve25519-sha...@libssh.org
ssh: HostKey: ssh-ed25519
ssh: Cipher: aes128-ctr
ssh: MAC: hmac-sha2-256
ssh: Compression: none
ssh: === End of kex handshake ===
ssh: kex engine KexCurve25519 specified hash_algo
ssh: Switch to new keys ...
ssh: Got EXT_INFO: {'server-sig-algs':
Bug#1068510: bobcat: provide a separate bobcat-source package for bootstrapping icmake
On Sat, Apr 06, 2024 at 12:00:48PM -0700, tony mancill wrote: > A separate bobcat-source binary package will enable icmake 12.x to be > bootstrapped without having to vendor in a copy of the bobcat sources. The upstream has decided to pursue a different strategy that removes any direct coupling between icmake and bobcat. This has been accomplished with icmake 12.01.00-1: https://tracker.debian.org/news/1522903/accepted-icmake-120100-1-source-into-unstable/
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Please excuse the top-post and the slow response-time. I am fully in agreement with the vendoring approach for jtreg7. If there aren't any concerns from the team, I will review the MR and prepare an upload in the next few days. Cheers, tony On Tue, Apr 09, 2024 at 02:02:13PM +1200, Vladimir Petko wrote: > Hi, > > I have realized that I have not submitted the bug report for this > issue, so the decision to try vendoring dependencies for JTREG is not > visible anywhere. > > Starting from the April OpenJDK release, JTREG 7.3 will be used for > openjdk-11 and up, which will require having it in Buster and up. > > In Ubuntu, the January OpenJDK update used the vendored version, and > we have not found any test regression issues caused by it. > > I have an MR open[1] that does not update the source tree and a > branch[2] with imported sources. > > Best Regards, > Vladimir. > > [1] https://salsa.debian.org/java-team/jtreg7/-/merge_requests/1 > [2] > https://salsa.debian.org/vpa1977/jtreg7/-/tree/jtreg_with_sources?ref_type=heads > > On Sun, Oct 22, 2023 at 10:01 AM Emmanuel Bourg wrote: > > > > Le 21/10/2023 à 20:55, tony mancill a écrit : > > > > > My secondary concern is how we would respond to CVEs in the vendored > > > components. We can debate whether the attack surface area in a tool > > > like jtreg warrants patching the vendored components, but as a general > > > principle, that's why we avoid vendoring in the first place. > > > > > > But if vendoring is acceptable in some circumstances, I can imagine > > > cases where it helps with bootstrapping too, but that's probably a topic > > > for a different thread. > > > > > > In any event, I'm glad that we're having the discussion and that the > > > Security Team has taken a look. Let's see how it goes with jtreg7. > > > > jtreg is only used to run the openjdk tests, that's not a security > > sensitive package, so embedding the package isn't a concern. > > > > Emmanuel Bourg > > signature.asc Description: PGP signature
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#1057531: openjfx: diff for NMU version 11.0.11+1-3.2
On Sat, Apr 13, 2024 at 03:15:15PM +0200, Sebastian Ramacher wrote: > I've prepared an NMU for openjfx (versioned as 11.0.11+1-3.2). The diff > is attached to this message. Hi Sebastian, Thank you for the upload. I imported dsc for your upload into the packaging repo. Cheers, tony signature.asc Description: PGP signature
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#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#1068522: icmake: cross-build support for icmake
Source: icmake Version: 12.00.01-1 Severity: normal cross-building for armhf fails on amd64: $ sbuild --host=armhf -d unstable ... dh_dwz -a install -m0755 -d debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf dwz -mdebian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug -M/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug -- debian/icmake/usr/bin/icmake debian/icmake/usr/bin/icmbuild debian/icmake/usr/libexec/icmake/icm-comp debian/icmake/usr/libexec/icmake/icm-dep debian/icmake/usr/libexec/icmake/icm-exec debian/icmake/usr/libexec/icmake/icm-multicomp debian/icmake/usr/libexec/icmake/icm-pp debian/icmake/usr/libexec/icmake/icm-spch debian/icmake/usr/libexec/icmake/icmun arm-linux-gnueabihf-objcopy --compress-debug-sections debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug arm-linux-gnueabihf-objcopy: debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug: file format not recognized dh_dwz: error: arm-linux-gnueabihf-objcopy --compress-debug-sections debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug returned exit code 1 dh_dwz: error: Aborting due to earlier error make: *** [debian/rules:21: binary] Error 25
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#1068233: snappy-java: please add support for loong64
On Tue, Apr 02, 2024 at 11:44:10AM +, wuruilong wrote: > Source: snappy-java > Severity: wishlist > X-Debbugs-Cc: wuruil...@loongson.cn > > Dear Maintainer, > > According to the upstream commit, the loong64 architecture needs to update > the attachment code to compile correctly. > The attached binary file libsnappyjava.so needs to be placed in the following > directory > src/main/resources/org/xerial/snappy/native/Linux/loongarch64/libsnappyjava.so > > wuruilong Hi, Thank you for the bug report and the reference to the PR against snappy-java. It would be helpful if upstream would include this in a tagged release. In the meantime, we can patch the build system for snappy-java to support building JNI bindings for loong64. We don't require the libsnappyjava.so. That'll be built and link to the loong64 build of snappy [1]. Thank you, tony [1] https://buildd.debian.org/status/logs.php?pkg=snappy=1.1.10-1=loong64 signature.asc Description: PGP signature
Bug#1068510: bobcat: provide a separate bobcat-source package for bootstrapping icmake
Source: bobcat Version: 6.04.00-1 Severity: important A separate bobcat-source binary package will enable icmake 12.x to be bootstrapped without having to vendor in a copy of the bobcat sources. Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051966 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068068 signature.asc Description: PGP signature
Bug#1039607: libjansi-java: causes maven to always output escape character
On Sat, Apr 06, 2024 at 11:09:07AM +0200, Emmanuel Bourg wrote:
> Le 05/01/2024 à 07:22, tony mancill a écrit :
>
> > However, for the short-term, I believe we can achieve the desired
> > behavior and fix the issue for most use cases by
> >
> > 1. Patching the mvn wrapper script in our maven package to set
> > jansi.mode=force (and thus colorize output) unless the --batch-mode
> > option is provided.
> >
> > 2. Moving forward with the current jansi package in experimental.
> >
> > That restores the desired --batch-mode behavior but maintains
> > colorized output by default and during Debian package builds.
> >
> > Would that be acceptable?
>
> Hi Tony,
>
> Was this plan fully implemented? Maven builds from the command line and
> inside pbuilder are no longer colorized currently.
Hi Emmanuel,
The uploads of src:maven and src:jansi were completed in mid-February.
I ended up not uploading the change to maven-debian-helper in
experimental because I didn't think it was necessary.
mvn on the command-line produced colorized output by default on my
system and in clean unstable and trixie chroots (attached screenshot).
If that's not working for you, then let me know. Perhaps more work is
needed on the patch in src:maven.
However, I'm not seeing colorized output on my system during sbuild, so
there are still something amiss. I notice that "--batch-mode" is being
explicitly passed to the maven invocation via this code [1], which
explains that behavior.
> dh_auto_build -O--buildsystem=maven
>/usr/lib/jvm/default-java/bin/java -noverify -cp
> /usr/share/maven/boot/plexus-classworlds-2.x.jar
> -Dmaven.home=/usr/share/maven
> -Dmaven.multiModuleProjectDirectory=/<>
> -Dclassworlds.conf=/etc/maven/m2-debian.conf
> -Dproperties.file.manual=/<>/debian/maven.properties
> org.codehaus.plexus.classworlds.launcher.Launcher
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian
> -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package
> -DskipTests -Dnotimestamp=true -Dlocale=en_US
I will have to look into why the tput (no longer?) succeeds during sbuild.
In fact, it's failing for plain `dpkg-buildpackage` in my terminal, even
though the following (negated condition) test generates output:
$ perl -e "if ((`tput colors 2>/dev/null` >= 8)) { print 'foo'; }"
So I think the issue is in maven-debian-helper and that the other
changes are working as expected.
You should be seeing colorized output on the terminal unless you
explicitly override it. Let me know if you're seeing something else.
Thank you,
tony
[1]
https://salsa.debian.org/java-team/maven-debian-helper/-/blob/c03c5403539eb4dc35947b35f51d72d74620637a/share/perl/maven.pm#L53-55
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#1066045: maven-bundle-plugin: diff for NMU version 3.5.1-2.1
On Wed, Mar 27, 2024 at 09:24:34PM -0700, tony mancill wrote: > Thank you for the patch and the NMU. Feel free to proceed with a 0-day > upload if you'd prefer. Resending - the prior reply was from me, but didn't have the correct From: header. Cheers, tony signature.asc Description: PGP signature
Bug#1066045: maven-bundle-plugin: diff for NMU version 3.5.1-2.1
On Wed, Mar 27, 2024 at 06:18:51PM +0100, Mattia Rizzolo wrote: > I've prepared an NMU for maven-bundle-plugin (versioned as 3.5.1-2.1) and > uploaded it to DELAYED/15. Please feel free to tell me if I > should delay it longer. Hi Mattia, hi James, Thank you for the patch and the NMU. Feel free to proceed with a 0-day upload if you'd prefer. I will import the changes into the repo and ACK the NMU with the next upload. Cheers, tony signature.asc Description: PGP signature
Bug#1065455: additional information
On Thu, Mar 07, 2024 at 03:31:26PM +1300, Vladimir Petko wrote: > Dear Maintainers, > > I have mistakenly submitted it as a Java 21 issue as it seems to be > caused by commons-compress 1.25. > Would it be possible to consider a merge request[1] that addresses this issue? > > Best Regards, > Vladimir. > > [1] https://salsa.debian.org/java-team/libapache-poi-java/-/merge_requests/2 Thank you for the MR - applied, and I will upload shortly.
Bug#1064780: pgpainless: fails to build from source with Java 21 due to SecurityManager UnsupportedException
On Mon, Feb 26, 2024 at 09:47:15AM +1300, Vladimir Petko wrote: > [1] https://salsa.debian.org/java-team/pgpainless/-/merge_requests/2 Merged and uploaded. Thank you for the patch, tony
Bug#1057536: tiles-autotag: FTBFS with default Java 21
On Fri, Feb 16, 2024 at 04:22:14PM +1300, Vladimir Petko wrote: > Hi, > > The issue is caused by the outdated version of the byte-buddy. Upgrading it > to 1.14 should solve the issue. > The issue can be worked around by adding -Dnet.bytebuddy.experimental=true > to the argLine in maven-surefire-plugin. FTBFS with Java 21 fixed via the work-around for now.
Bug#1057533: qpid-proton-j-extensions: FTBFS with default Java 21
On Fri, Feb 16, 2024 at 04:10:16PM +1300, Vladimir Petko wrote: > [1] > https://salsa.debian.org/java-team/qpid-proton-j-extensions/-/merge_requests/1 Merged and uploaded. Thank you for patch!
Bug#1064305: fop: new upstream version 2.9
Source: fop Version: 1:2.8-3 Severity: minor This bug is for visibility; fop 2.9 is now available. I am working on an update and will upload to experimental soon.
Bug#1052566: additional information
On Mon, Feb 19, 2024 at 03:10:09PM +1300, Vladimir Petko wrote: > [1] > https://salsa.debian.org/java-team/libnative-platform-java/-/merge_requests/4 Merged and uploaded. Cheers, tony
Bug#1039607: libjansi-java: causes maven to always output escape character
On Sat, Jan 13, 2024 at 05:46:58PM -0800, tony mancill wrote: > > > Feedback welcome. We can coordinate here before any migrations from > > > experimental to unstable. > > > > Thank you for the fix. To test we created a chroot environment with the > > following upgrades: > > > > apt install libjansi-java/experimental > > apt install maven/experimental libmaven3-core-java/experimental > > libcommons-cli-java/unstable libcommons-lang3-java/unstable > > > > The issue reported in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 as well as our > > original issue are resolved. > > Thank you for your testing. > > Are there any concerns before I upload maven and jansi to unstable? We > can always revisit the changes if we discover any issues. I have uploaded maven_3.8.7-2 to unstable. Once it is in the archive and made it out to the mirrors, I will upload jansi. signature.asc Description: PGP signature
Bug#1063558: pgpainless 1.6.6 is available
On Fri, Feb 09, 2024 at 10:19:59AM -0500, Daniel Kahn Gillmor wrote: > Package: src:pgpainless > Version: 1.6.5-1 > Severity: wishlist > > pgpainless 1.6.6 is available upstream. it would be great to have it in > debian. Hi, I pulled the new version and prepared the update, but I'm not seeing anything that would affect Debian users of this package (because we only have logback 1.2.x anyway): diff -Nru pgpainless-1.6.5/CHANGELOG.md pgpainless-1.6.6/CHANGELOG.md --- pgpainless-1.6.5/CHANGELOG.md 2023-12-15 08:35:50.0 -0800 +++ pgpainless-1.6.6/CHANGELOG.md 2024-02-02 13:06:11.0 -0800 @@ -5,6 +5,9 @@ # PGPainless Changelog +## 1.6.6 +- Downgrade `logback-core` and `logback-classic` to `1.2.13` to fix #426 + ## 1.6.5 - Add `SecretKeyRingEditor.setExpirationDateOfSubkey()` However, since the packaging update is done, I will go ahead and upload soonish. Cheers, tony signature.asc Description: PGP signature
Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1
On Tue, Feb 06, 2024 at 06:01:43PM +, Jonathan Wiltshire wrote: > On Tue, Jul 25, 2023 at 10:19:50PM +0100, Jonathan Wiltshire wrote: > > Control: tag -1 moreinfo > > > > On Mon, Dec 05, 2022 at 11:22:51PM -0800, tony mancill wrote: > > > As the upstream author notes in [3], the issue is present in inlined > > > code, thus applications built against capnproto must be rebuilt against > > > the patched version. > > > > This doesn't immediately make any of us enthusiastic, it has to be said... > > Can we get the proposed debdiff at least please? > > > > The hazards are: > > - ftbfs in the rdeps in stable > > - much reduced testing of proposed-updates vs. for example sid/testing > > > > > The issue for unstable and bookworm is being addressed via an > > > upload to experimental [4] and a subsequent transition [5]. Easy > > > enough... > > > > > > For stable (and old-stable), we need to introduce 0.7.1, a new upstream > > > version that generates a (new) libcapnp-0.7.1 binary package to address > > > the vulnerability. Once those are present in the archive, we can > > > trigger rebuilds of the reverse dependencies. At this time I am asking > > > for bullseye. > > > > > > [ Reason ] > > > This is to address CVE-2022-46149 [1]. > > > > > > [ Impact ] > > > Packages built with capnproto in bullseye will remain potentially > > > vulnerable to the CVE. > > > > > > [ Tests ] > > > I have built the package in a clean bullseye chroot and then used ratt to > > > rebuilt the (8) bullseye r-deps: > > > > > > - clickhouse_18.16.1+ds-7.2 > > > - harvest-tools_1.3-6 > > > - laminar_1.0-3 > > > - librime_1.6.1+dfsg1-1 > > > - mash_2.2.2+dfsg-2 > > > - mir_1.8.0+dfsg1-18 > > > - rr_5.4.0-2 > > > - sonic-visualiser_4.2-1 > > > > laminar in particular doesn't seem to have much maintainer attention. If > > there are problems with the rdeps on rebuild are you going to be in a > > position to resolve them? That's a fair question and I don't have a ready answer other than it depends on how much attention is needed. I am a member of the backports ACL now (I wasn't when this was filed), so I can help with uploads, but I don't have a history with the r-deps. > > > [ Risks ] > > > The upstream author has stated that there are no known vulnerable > > > applications, yet advises that all capnproto users rebuild their > > > applications using patched versions of capnproto. > > > > An abundance of caution? Otherwise the statements seem at odds with each > > other. Agreed. I don't have a strong sense for the security risk to end users. > > > If this is not amenable to stable-proposed-updates, would you recommend > > > backports? > > > > I'm not sure a transition in backports is going to be well received either. > > Let's start with the debdiff and at least know what we're looking at. > > Ping? Thank you for the gentle reminder. I parsed the "not well received" comment and somehow skimmed past the request for the debdiff, got busy, etc... The full debdiff is attached, but it's mostly comprised of non-functional build system and autoconf drift. A pared-down diff with only the packaging and true (semantic) upstream changes is attached as well. Thank you, tony diff -Nru capnproto-0.7.0/aclocal.m4 capnproto-0.7.1/aclocal.m4 --- capnproto-0.7.0/aclocal.m4 2018-08-28 18:13:57.0 -0700 +++ capnproto-0.7.1/aclocal.m4 2022-11-29 07:55:16.0 -0800 @@ -1,6 +1,6 @@ -# generated automatically by aclocal 1.16.1 -*- Autoconf -*- +# generated automatically by aclocal 1.16.3 -*- Autoconf -*- -# Copyright (C) 1996-2018 Free Software Foundation, Inc. +# Copyright (C) 1996-2020 Free Software Foundation, Inc. # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, @@ -20,7 +20,7 @@ If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically 'autoreconf'.])]) -# Copyright (C) 2002-2018 Free Software Foundation, Inc. +# Copyright (C) 2002-2020 Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, @@ -35,7 +35,7 @@ [am__api_version='1.16' dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to dnl require some minimum version. Point them to the right macro. -m4_if([$1], [1.16.1], [], +m4_if([$1], [1.16.3], [], [AC_FATAL([Do not
Bug#1057521: libminidns-java: FTBFS with default Java 21
On Wed, Jan 31, 2024 at 09:32:29AM +1300, Vladimir Petko wrote: > [1] https://salsa.debian.org/debian/libminidns-java/-/merge_requests/1 Merged and uploaded. Thank you for your contribution to Debian.
Bug#1057491: Additional information
On Fri, Jan 05, 2024 at 09:07:28PM +1300, Vladimir Petko wrote: > [1] https://salsa.debian.org/java-team/beansbinding/-/merge_requests/3 Uploaded. Thank you for the patch.
Bug#1057509: jcabi-log: FTBFS with default Java 21
On Thu, Jan 25, 2024 at 02:19:34PM +1300, Vladimir Petko wrote: > The issue is no longer reproducible when built against lombok 1.18.24-2 The updated lombok package has been uploaded with your patch. Thank you for contributing to Debian!
Bug#1057511: Additional information
On Fri, Jan 26, 2024 at 11:48:23AM +1300, Vladimir Petko wrote: > [1] https://salsa.debian.org/java-team/jtreg/-/merge_requests/3 Merged and uploaded. Thank you for the patch!
Bug#1061475: icmake: version 11.01.01 FTBFS on 32-bit architectures
Source: icmake Version: 11.01.01-1 Severity: important Filing this bug for visibility. The upstream author is aware of the issue. The latest version FTBFS on 32-bit architectures. Refer to https://buildd.debian.org/status/package.php?p=icmake and https://buildd.debian.org/status/fetch.php?pkg=icmake=i386=11.01.01-1=1706141080=0 for logs.
Bug#1061267: transition: unixcw
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: uni...@packages.debian.org Control: affects -1 + src:unixcw Dear Release Team, I am requesting a transition for unixcw [1]. The one reverse dependency, cwdaemon, builds correctly against the package in experimental. The auto-transition page is [2]. Thank you, tony [1] https://tracker.debian.org/pkg/unixcw [2] https://release.debian.org/transitions/html/auto-unixcw.html Ben file: title = "unixcw"; is_affected = .depends ~ "libcw7" | .depends ~ "libcw8"; is_good = .depends ~ "libcw8"; is_bad = .depends ~ "libcw7";
Bug#1057507: Additional information
On Thu, Jan 18, 2024 at 01:49:44PM +1300, Vladimir Petko wrote: > Would it be possible to consider a merge request[1] that addresses this > issue? > [1] > https://salsa.debian.org/java-team/jackson-datatype-joda/-/merge_requests/2 Uploaded. Thank you for the patch.
Bug#1057499: exec-maven-plugin: FTBFS with default Java 21
On Wed, Jan 17, 2024 at 05:30:24PM +1300, Vladimir Petko wrote: > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > Alternatively, we can update the package to the upstream version 3.1.1. > > Best Regards, > Vladimir. > > [1]https://salsa.debian.org/java-team/exec-maven-plugin/-/merge_requests/2 Hello Vladimir, Thank you for locating and packaging the patch. I will upload the current version with the patch and then look at updating 3.1.1 (after reviewing all of the changes in the release). Cheers, tony
Bug#1057506: intellij-community-idea: FTBFS with default Java 21
On Mon, Jan 15, 2024 at 05:08:13PM +1300, Vladimir Petko wrote: > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > > Best Regards, > Vladimir. > > [1] > https://salsa.debian.org/java-team/intellij-community-idea/-/merge_requests/5 Merged and uploaded. Thank you for your contribution!
Bug#1039607: libjansi-java: causes maven to always output escape character
On Wed, Jan 10, 2024 at 10:13:38AM +0100, Clemens Ballarin wrote: > Am 08.01.2024 um 07:03 schrieb tony mancill: > > > I am preparing an upload of maven to experimental (version 3.8.7-2~exp1) > > that implements the changes described above. I will push the packaging > > changes to the debian/experimental branch in the Salsa repo. The patch > > for mvn can be found here: > > > > [...] > > > > I believe this will address the issues reported in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039607 and > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 > > > > Feedback welcome. We can coordinate here before any migrations from > > experimental to unstable. > > Thank you for the fix. To test we created a chroot environment with the > following upgrades: > > apt install libjansi-java/experimental > apt install maven/experimental libmaven3-core-java/experimental > libcommons-cli-java/unstable libcommons-lang3-java/unstable > > The issue reported in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 as well as our > original issue are resolved. Thank you for your testing. Are there any concerns before I upload maven and jansi to unstable? We can always revisit the changes if we discover any issues. signature.asc Description: PGP signature
Bug#1039607: libjansi-java: causes maven to always output escape character
On Thu, Jan 04, 2024 at 10:22:02PM -0800, tony mancill wrote: > However, for the short-term, I believe we can achieve the desired > behavior and fix the issue for most use cases by > > 1. Patching the mvn wrapper script in our maven package to set > jansi.mode=force (and thus colorize output) unless the --batch-mode > option is provided. > > 2. Moving forward with the current jansi package in experimental. > > That restores the desired --batch-mode behavior but maintains > colorized output by default and during Debian package builds. I am preparing an upload of maven to experimental (version 3.8.7-2~exp1) that implements the changes described above. I will push the packaging changes to the debian/experimental branch in the Salsa repo. The patch for mvn can be found here: https://salsa.debian.org/java-team/maven/-/blob/4501966b3678135deacca45bc1a918380f6dac47/debian/patches/03_jansi_behavior.patch When used in conjunction with the jansi package in experimental, the behavior is: **output is colorized** mvn **output is non-colorized** mvn -B mvn --batch-mode The patched mvn script also checks for MAVEN_JANSI_PROPERTY in the environment, which allows users to override the behavior if desired. I don't expect this to be needed very often, but it may be useful if we modify the behavior of jansi in the future, and I wanted there to be an escape valve if the patched behavior is problematic for some unforeseen use case. The invocations below demonstrate the behavior of Debian's jansi that led to the patch in 2.4.0-2, i.e., that without the native jansi libraries or -Djansi.mode=force, the default TTY detection fails and results in non-colorized output. MAVEN_JANSI_PROPERTY="" mvn MAVEN_JANSI_PROPERTY= mvn For completeness: MAVEN_JANSI_PROPERTY="-Djansi.mode=default" mvn --> non-colorized MAVEN_JANSI_PROPERTY="-Djansi.mode=strip" mvn--> non-colorized MAVEN_JANSI_PROPERTY="-Djansi.mode=force" mvn--> colorized With these changes, we shouldn't need the patched maven-debian-helper I proposed previously, since the output of Maven invoked during builds will be colorized. I believe this will address the issues reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039607 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 Feedback welcome. We can coordinate here before any migrations from experimental to unstable. Thanks, tony signature.asc Description: PGP signature
Bug#1039607: libjansi-java: causes maven to always output escape character
On Sun, Dec 31, 2023 at 03:27:53PM -0800, tony mancill wrote: > On Fri, Dec 29, 2023 at 07:23:35AM -0800, tony mancill wrote: > > On Fri, Dec 29, 2023 at 12:27:07PM +0100, Emmanuel Bourg wrote: > > > On 28/12/2023 00:48, tony mancill wrote: > > > > > > > - Maven output is colorized by default when invoked during Debian > > > >package builds that depend on maven-debian-helper. > > > > > > Good > > > > > > > - Direct `mvn` Maven output is not colorized by default. > > > > > > That's an issue, mvn output should be colorized on a terminal by default, > > > that's the upstream behaviour. > > My intuition is that it will be better to update the Debian jansi > package to create the necessary arch-any packages so our version more > closely resembles upstream, and we are better positioned if/when jansi > merges into jline, as mentioned here [4]. After giving this some more thought, I don't think we want a jansi source package that builds arch-any packages. jansi (already) has a circular build dependency on itself via maven, but there's no bootstrapping problem because the packages are currently arch-all. Since the native library is desired but optional, we could create a separate source package and add a Recommends dependency to libjansi-java. It may even be possible leverage the existing jansi-native, but I haven't looked into the question of compatibility yet. However, for the short-term, I believe we can achieve the desired behavior and fix the issue for most use cases by 1. Patching the mvn wrapper script in our maven package to set jansi.mode=force (and thus colorize output) unless the --batch-mode option is provided. 2. Moving forward with the current jansi package in experimental. That restores the desired --batch-mode behavior but maintains colorized output by default and during Debian package builds. Would that be acceptable?
Bug#1057019: openjdk-17-jdk: SIGSEGV on i386 during lz4-java tests (PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x14e)
On Mon, Nov 27, 2023 at 09:22:44PM -0800, tony mancill wrote: > Package: openjdk-17-jdk > Version: 17.0.9+9-2 > Severity: normal > > Dear Maintainer, > > lz4-java tests are failing consistently (well, twice so far on the > buildds) with a JVM segfault, on the i386 arch only. I am not able to > reproduce when cross-building on amd64 with --arch=i386 in a sbuild > chroot, so I can't provide the error report or compiler replay data > (yet), but the failure message is: > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xf758ddce, pid=634517, tid=634556 > # > # JRE version: OpenJDK Runtime Environment (17.0.9+9) (build > 17.0.9+9-Debian-2) > # Java VM: OpenJDK Server VM (17.0.9+9-Debian-2, mixed mode, sharing, tiered, > g1 gc, linux-x86) > # Problematic frame: > # V [libjvm.so+0x880dce] PhaseIdealLoop::build_loop_late_post_work(Node*, > bool)+0x14e This is no longer occurring with openjdk 17.0.10~6ea-1. I will close the bug.
Bug#1039607: libjansi-java: causes maven to always output escape character
On Fri, Dec 29, 2023 at 07:23:35AM -0800, tony mancill wrote: > On Fri, Dec 29, 2023 at 12:27:07PM +0100, Emmanuel Bourg wrote: > > On 28/12/2023 00:48, tony mancill wrote: > > > > > - Maven output is colorized by default when invoked during Debian > > >package builds that depend on maven-debian-helper. > > > > Good > > > > > > > - Direct `mvn` Maven output is not colorized by default. > > > > That's an issue, mvn output should be colorized on a terminal by default, > > that's the upstream behaviour. > > Ah, that's right. And it's a little odd, because at this point jansi > is no longer patched and our maven packaging doesn't patch for this > behavior. > > Thank you for bringing this up. I will figure out why this is > occurring. It's likely what led to the jansi patch in the first > place. After looking a bit closer, it's not so odd after all. Debian's jansi (2.x) JAR differs from the upstream version bundled with Maven in that it doesn't include the jansi-native libraries and doesn't depend on anything that could provide them. The Debian jansi-native package is for 1.x and doesn't actually provide the arch-dependent bits anyway (see [1]), so the default TTY detection (jansi.mode=default) functionality is broken because all of the native calls are broken. Perhaps it's more surprising that jansi.mode=force or the patch work as well as they do. This will take a bit to sort out, since we either need to build the arch-specific packages, which will need to go through NEW, or come up with a pure-Java implementation that behaves like upstream. (Not directly related, but it would be nice to migrate to upstream 2.4.1 [2], which uses moditect [3], which would need to be packaged.) My intuition is that it will be better to update the Debian jansi package to create the necessary arch-any packages so our version more closely resembles upstream, and we are better positioned if/when jansi merges into jline, as mentioned here [4]. Thanks, tony [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921994 [2] https://github.com/fusesource/jansi/releases/tag/jansi-2.4.1 [3] https://github.com/moditect/moditect [4] https://github.com/fusesource/jansi/issues/277
Bug#1057276: pat: PACTOR mode is broken
On Sat, Dec 02, 2023 at 03:53:58PM +0100, Joshua Hoffmann | DC7IA wrote: > Package: pat > Version: 0.15.0-1+b3 > Severity: important > X-Debbugs-Cc: martin.h.peder...@gmail.com, d...@dc7ia.eu > > Dear Debian Hamradio Maintainers, > > connecting to a station using PACTOR is broken. This bug is not present when > using upstream packages. > > ``` > pat-winlink connect "pactor:///DB0ZAV" > 2023/12/02 15:38:18 Connecting to DB0ZAV (pactor)... > 2023/12/02 15:38:18 Unable to establish connection to remote: No dialer has > been registered for this scheme > ``` A new package has been uploaded to experimental (pat_0.15.1-2~exp1) that build-depends on the recently accepted golang-github-harenber-ptc-go. As noted previously in the bug report, I don't have access to hardware to test this, so I can only note that the non-PACTOR smoke-tests still pass and that you should no longer see the "No dialer" error message. If users who have access to PACTOR modems could test this, that would be appreciated. Binaries built by the buildd's should be available soon; refer to the PTS [1]. Thank you, tony [1] https://tracker.debian.org/pkg/pat signature.asc Description: PGP signature
Bug#1039607: libjansi-java: causes maven to always output escape character
On Fri, Dec 29, 2023 at 12:27:07PM +0100, Emmanuel Bourg wrote: > On 28/12/2023 00:48, tony mancill wrote: > > > - Maven output is colorized by default when invoked during Debian > >package builds that depend on maven-debian-helper. > > Good > > > > - Direct `mvn` Maven output is not colorized by default. > > That's an issue, mvn output should be colorized on a terminal by default, > that's the upstream behaviour. Ah, that's right. And it's a little odd, because at this point jansi is no longer patched and our maven packaging doesn't patch for this behavior. Thank you for bringing this up. I will figure out why this is occurring. It's likely what led to the jansi patch in the first place.
Bug#1039607: libjansi-java: causes maven to always output escape character
On Sat, Dec 23, 2023 at 03:54:45PM -0800, tony mancill wrote: > On Sat, Jul 15, 2023 at 03:56:01PM +0200, Emmanuel Bourg wrote: > > On 08/07/2023 20:22, tony mancill wrote: > > > > > Emmanuel, do you recall what prompted the change? > > > > I think the issue is that when Maven runs in pbuilder, the TTY isn't > > detected and colors get disabled (batch mode isn't used for Debian builds > > though). If anything is changed please ensure that building with pdebuild > > preserves the colors. > > Looking at the sources (finally), jansi already supports a mode to > "force" [1] escape sequences, even when the output is not a terminal. I > propose that we revert the patch and update the Java build tooling to > set the property as desired for our builds. > > Once I get this tested and the property configured, I'll upload to > experimental. The following are now available in experimental: libjansi-java_2.4.0-3_all.deb maven-debian-helper_2.6.5~exp1_all.deb The maven-debian-helper change is here [1]. The two packages have been tested in conjunction to ensure that: - Maven output is colorized by default when invoked during Debian package builds that depend on maven-debian-helper. - Direct `mvn` Maven output is not colorized by default. - MAVEN_OPTS, or any other mechanism to set the JVM property jansi.mode, can be used to specify the mode and override the default behavior. I believe this covers the (large) majority of Debian build cases and restores the upstream behavior, but please let me know if I've missed something. The version of gradle in Debian depends on libjansi1-java, and so wasn't impacted by the patch to jansi (version 2.x). Assuming there aren't any concerns, I plan to upload maven-debian-helper and then the jansi package to unstable on January 7th. Thanks, tony [1] https://salsa.debian.org/java-team/maven-debian-helper/-/commit/082b5b639880e8b3b1c1e98f5ae4f649e3b83b67 signature.asc Description: PGP signature
Bug#1039607: libjansi-java: causes maven to always output escape character
On Sat, Jul 15, 2023 at 03:56:01PM +0200, Emmanuel Bourg wrote: > On 08/07/2023 20:22, tony mancill wrote: > > > Emmanuel, do you recall what prompted the change? > > I think the issue is that when Maven runs in pbuilder, the TTY isn't > detected and colors get disabled (batch mode isn't used for Debian builds > though). If anything is changed please ensure that building with pdebuild > preserves the colors. Looking at the sources (finally), jansi already supports a mode to "force" [1] escape sequences, even when the output is not a terminal. I propose that we revert the patch and update the Java build tooling to set the property as desired for our builds. Once I get this tested and the property configured, I'll upload to experimental. Thanks, tony [1] https://salsa.debian.org/java-team/jansi/-/blob/738159f052f027fc0816c95ecc38a424f8aa3637/src/main/java/org/fusesource/jansi/AnsiConsole.java#L83-86
Bug#1059147: maven: successful invocation of mvn writes unexpeceted output to stderr
On Wed, Dec 20, 2023 at 03:13:23PM +0100, Clemens Ballarin wrote:
> Package: maven
> Version: 3.8.7-1
> Severity: normal
> X-Debbugs-Cc: debian-bugrepo...@ankordata.de
>
> Dear Maintainer,
>
> Maven writes an ansi control sequence to an otherwise empty stderr:
>
> $ mvn --help 2>&1 >/dev/null | hexdump -C
> 1b 5b 30 6d |.[0m|
> 0004
>
> Apache's upstream version does not exhibit this behaviour, there is no output:
>
> $ PATH=${HOME}/software/apache-maven-3.8.7/bin:${PATH} mvn --help 2>&1
> >/dev/null | hexdump -C
>
> This is also a regression from Debian 11.8 and Maven 3.6.3-5.
>
> It complicates a somewhat pedantic test scenario. Fix would be appreciated.
This appears related to (and perhaps a duplicate of) #1039607 [1].
As I noted there, I think the strategy should be to revert the
default behavior to match upstream and add functionality as needed for
colorized output in pdebuild.
I will try to allocate some time to work on this next week.
Thanks,
tony
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039607
Bug#1057276: pat: PACTOR mode is broken
On Wed, Dec 13, 2023 at 08:48:02AM -0500, Federico Grau wrote: > Greetings pat users -- > > I'm the author of the PACTOR patch-out, given I do not have access to that > non-free software. This is documented in the file > /usr/share/doc/pat/README.Debian: > > ... > # ptc-go disabled > The current Debian packaging of pat has "ptc-go" pactor modem support > disabled. > If there is interest in this feature please submit a bug report. > ... > > Thanks for the feedback. Exciting to learn others have interest and possible > cycles to progress that component. Ideally there will be follow-up test > results helping confirm if things work or not. Hi donfede, That's a good point. I also don't have access to that software. Once we have the prerequisites for PACTOR support, we can generate a preliminary package for testing and document any limitations. For what it's worth, I didn't intend to imply that there was anything amiss with the patch-out. My motivation is merely to support useful features to users where we can. Cheers, tony signature.asc Description: PGP signature
Bug#1058653: libreoffice-writer-nogui: fails to convert ODT to PDF "Error: source file could not be loaded"
Hi Rene, On Thu, Dec 14, 2023 at 07:57:46AM +0100, Rene Engelhard wrote: > Am 14.12.23 um 06:01 schrieb tony mancill: > > A FTBFS bug [1] cropped up in gpredict recently that appears to be to a > > change in libreoffice-writer-nogui. The build step that fails is: > > > > $ soffice --strace --writer --headless --convert-to pdf > > gpredict-user-manual.odt > > Warning: failed to launch javaldx - java may not function correctly > > Error: source file could not be loaded > > > > strace output shows a failed attempt to find libcuilo.so (shipped with > > libreoffice-core) just before "Error: source file could not be loaded" > > is output. Should libcuilo.so be included in libreoffice-core-nogui? > > No it should not because it is *common UI*. > > That LibreOffice upstream adds options and then let it bit-rot to the point > that that they don't work as intended without adding totally unrelated stuff > unfortunately is a fact. :( > > Here it is adding a dependency on UI stuff for something not needing UI. Thank you for the explanation. (I didn't spend enough time digging into whether the library *should* be there, I only noted that it was missing.) > In the meanwhile I actually reget having added -nogui for this reason. Yeah, I can appreciate that it leads to confusion and potentially more work for you as a maintainer. > > For the time-being, we are working around this by using > > libreoffice-writer as the build-dep, > That is wrong imho. > > but the -nogui package should be > > sufficient and has worked in the past. > > Yeah. Or just adding libreoffice-core (since you *can* mix them.) See also > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052052 Yes, that works. I had opted for libreoffice-writer because its transitive dependency set is only marginally larger (70MB) than libreoffice-core, and it allows me to specify a single build-dep related to libreoffice, but mixing them does result is fewer overall build-deps. (unstable-amd64-sbuild) apt-get install libreoffice-writer ... 0 upgraded, 560 newly installed, 0 to remove and 0 not upgraded. Need to get 372 MB of archives. After this operation, 1320 MB of additional disk space will be used. (unstable-amd64-sbuild) apt-get install libreoffice-core ... 0 upgraded, 545 newly installed, 0 to remove and 0 not upgraded. Need to get 355 MB of archives. After this operation, 1253 MB of additional disk space will be used. (unstable-amd64-sbuild) apt-get install libreoffice-writer-nogui ... 0 upgraded, 263 newly installed, 0 to remove and 0 not upgraded. Need to get 185 MB of archives. After this operation, 642 MB of additional disk space will be used. Thank you for the response and filing the bug upstream. Cheers, tony
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#1058653: libreoffice-writer-nogui: fails to convert ODT to PDF "Error: source file could not be loaded"
Package: libreoffice-writer-nogui Version: 4:7.6.4~rc1-1 Severity: normal Dear Maintainer, A FTBFS bug [1] cropped up in gpredict recently that appears to be to a change in libreoffice-writer-nogui. The build step that fails is: $ soffice --strace --writer --headless --convert-to pdf gpredict-user-manual.odt Warning: failed to launch javaldx - java may not function correctly Error: source file could not be loaded strace output shows a failed attempt to find libcuilo.so (shipped with libreoffice-core) just before "Error: source file could not be loaded" is output. Should libcuilo.so be included in libreoffice-core-nogui? For the time-being, we are working around this by using libreoffice-writer as the build-dep, but the -nogui package should be sufficient and has worked in the past. Thank you, tony [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058273
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#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#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#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#1057276: pat: PACTOR mode is broken
On Sat, Dec 09, 2023 at 06:37:35PM +0100, DC7IA wrote: > Hello Tony, > > that's less than ideal. Currently, as a user, I just notice that the > software does not work. I do exactly what should work, but for some reason > it does not. I cannot see that a feature was intentionally removed. > > And yes, there's definitely interest, as currently there is no other > software for PACTOR that is available in the repos. So if that feature can > be re-added in relatively simple way, that'd be great. > > The reason I was asking the author of pat to talk to some Debian folks and > get it in the repo, two years ago, was because I thought it'd be great if we > had a software for this. :) Hi Joshua, Yes, I agree that the disable functionality could be better documented. For example, we could augment the patch to display a more helpful message when pactor is used and also update the manpage. But since it's not much more effort to enable pactor, I have started down that path. Bug #1057882 [1] is the ITP bug for golang-github-howeyc-crc16 and the packaging is in process. There was already an ITP bug (#956547 [2]) for golang-github-harenber-ptc-go, which I also have ready to upload once howeyc/crc16 is accepted into the archive. Both of those packages will need to go through the NEW queue before we can update pat, but they are fairly simple packages, so it shouldn't take too long. Thanks for bringing this to the list. Cheers, tony [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057882 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956547
Bug#956547: ITP: golang-github-harenber-ptc-go -- A driver for SCS PACTOR modems for Pat
On Sun, Apr 12, 2020 at 12:13:35PM -0400, Taowa Munene-Tardif wrote: > On Sun, Apr 12, 2020 at 11:59:49AM -0400, Taowa Munene-Tardif wrote: > > [1] Unfortunately, I have to write to the three upstream authors to get > > them to license ptc-go. I'll ask that they reply to the bug to have it > > on record :). > > Here's the github issue: https://github.com/harenber/ptc-go/issues/28 The licensing issue has been addressed upstream. I am in the process of packaging the necessary build-deps - see #1057882. Thanks, tony signature.asc Description: PGP signature
Bug#1057884: ITP: golang-github-harenber-ptc-go -- A driver for SCS PACTOR modems for Pat
Package: wnpp Severity: wishlist Owner: tony mancill * Package name: golang-github-harenber-ptc-go Version : 2.2.3-1 Upstream Author : * URL : https://github.com/harenber/ptc-go * License : Expat Programming Lang: Go Description : A driver for SCS PACTOR modems for Pat ptc-go - SCS PACTOR modems driver for the Pat Winlink-client . Documentation has been moved to the Wiki (https://github.com/harenber/ptc-go/wiki). -- The rationale for packaging golang-github-harenber-ptc-go will permit enabling PACTOR modem support in pat - see: #1057276 [1] This package depends on wnpp bug #1057882 [2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057276 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057882
Bug#1057882: ITP: golang-github-howeyc-crc16 -- Implements the 16-bit cyclic redundancy check, or CRC-16, checksum
Package: wnpp
Severity: wishlist
Owner: tony mancill
* Package name: golang-github-howeyc-crc16
Version : 0.0~git20171223.2b2a61e-1
Upstream Author : Chris Howey
* URL : https://github.com/howeyc/crc16
* License : BSD-3-clause
Programming Lang: Go
Description : Implements the 16-bit cyclic redundancy check, or CRC-16,
checksum
GoDoc (https://godoc.org/github.com/howeyc/crc16) Build Status
(http://travis-ci.org/howeyc/crc16)
.
CRC16
.
A Go package implementing the 16-bit Cyclic Redundancy Check, or CRC-16,
checksum.
.
Usage
.
To generate the hash of a byte slice, use the crc16.Checksum()
(https://godoc.org/github.com/howeyc/crc16#Checksum) function:
.
import "github.com/howeyc/crc16"
.
data := byte("test")
checksum := crc16.Checksum(data, crc16.IBMTable)
.
The package provides the following
(https://godoc.org/github.com/howeyc/crc16#pkg-variables) hashing tables.
For each of these tables, a shorthand can be used.
.
// This is the same as crc16.Checksum(data, crc16.IBMTable)
checksum := crc16.ChecksumIBM(data)
.
Using the hash.Hash (https://godoc.org/hash#Hash) interface also works.
.
h := crc16.New(crc16.IBMTable)
data := byte("test")
data2 := byte("data")
h.Write(data)
h.Write(data2)
checksum := h.Sum(nil)
.
Changelog
.
* 2017.03.27 - Added MBus checksum
* 2017.05.27 - Added checksum function without XOR
* 2017.12.08 - Implement encoding.BinaryMarshaler and
encoding.BinaryUnmarshaler to allow saving and recreating their
internal state.
--
The rationale for packaging is github.com/howeyc/crc16 is that it is a
dependency of github.com/harenber/ptc-go, which will permit enabling
PACTOR modem support in pat (winlink), as discussed in #1057276:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057276
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#1057276: pat: PACTOR mode is broken
On Sat, Dec 02, 2023 at 03:53:58PM +0100, Joshua Hoffmann | DC7IA wrote: > Package: pat > Version: 0.15.0-1+b3 > Severity: important > X-Debbugs-Cc: martin.h.peder...@gmail.com, d...@dc7ia.eu > > Dear Debian Hamradio Maintainers, > > connecting to a station using PACTOR is broken. This bug is not present when > using upstream packages. Hello Joshua, This is expected for the current packaging, as documented in this patch: https://salsa.debian.org/debian-hamradio-team/pat/-/blob/debian/sid/debian/patches/01_remove_ptc-go.patch I'm not the author of the patch, so my assessment may be incorrect. However, at first glance the only reverse dependency missing from Debian needed to package ptc-go is github.com/howeyc/crc16, which doesn't look too difficult to package. So it's doable if there is interest. Cheers, tony KG7IEL
Bug#1057686: groovy: The package fails to build from source due to the missing file
On Thu, Dec 07, 2023 at 05:34:01PM +1300, Vladimir Petko wrote: > Source: groovy > Version: 2.4.21-8 > Severity: important > Tags: ftbfs > > Dear Maintainer, > > The package fails to build from source due to the missing AntBuilder path: Hi Vladimir, I was seeing a slightly different (but reproducible) build failure with Java 21 related to javadoc generation that was occurring just after the AntBuilder check in this bug report. I added a patch and the package is building successfully on both Java 17 and 21 for me now, so I went ahead and marked this bug is closed. If this was a distinct issue and you're still seeing FTBFS, please let me know and I will reopen the bug. Thank you, tony
Bug#1056754: marked as done (bouncycastle: CVE-2023-33202)
On Thu, Nov 30, 2023 at 09:51:09PM +, Debian Bug Tracking System wrote: > Subject: Bug#1056754: fixed in bouncycastle 1.77-1 > > Source: bouncycastle > Version: 1.77-1 > Distribution: unstable > Changed-By: Markus Koschany >* New upstream version 1.77. (Closes: #1049356) Hi Markus, Thank you for your efforts to get BC updated. >* Remove backward-compatibility.patch. It is time to fix those issues > properly in our reverse-dependencies. I agree completely. And thank you for filing bugs for the r-deps that need to be addressed. Cheers, tony
Bug#1057021: lz4-java: FTBFS on i386 (only) due to JVM SIGSEGV
Source: lz4-java Severity: important lz4-java is FTBFS on i386 due to JVM segfaults during the test-suite: https://buildd.debian.org/status/logs.php?pkg=lz4-java=1.8.0-4=i386 The following bug has been filed against openjdk-17-jdk: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057019
Bug#1057019: openjdk-17-jdk: SIGSEGV on i386 during lz4-java tests (PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x14e)
Package: openjdk-17-jdk Version: 17.0.9+9-2 Severity: normal Dear Maintainer, lz4-java tests are failing consistently (well, twice so far on the buildds) with a JVM segfault, on the i386 arch only. I am not able to reproduce when cross-building on amd64 with --arch=i386 in a sbuild chroot, so I can't provide the error report or compiler replay data (yet), but the failure message is: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xf758ddce, pid=634517, tid=634556 # # JRE version: OpenJDK Runtime Environment (17.0.9+9) (build 17.0.9+9-Debian-2) # Java VM: OpenJDK Server VM (17.0.9+9-Debian-2, mixed mode, sharing, tiered, g1 gc, linux-x86) # Problematic frame: # V [libjvm.so+0x880dce] PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x14e # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /tmp/J0/hs_err_pid634517.log # # Compiler replay data is saved as: # /tmp/J0/replay_pid634517.log # # If you would like to submit a bug report, please visit: # https://bugs.debian.org/openjdk-17 The buildd logs are available here [1,2]; both fail with: # V [libjvm.so+0x880dce] PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x14e [1] https://buildd.debian.org/status/fetch.php?pkg=lz4-java=i386=1.8.0-4=1701066936=0 [2] https://buildd.debian.org/status/fetch.php?pkg=lz4-java=i386=1.8.0-4=1700852759=0 I will try to reproduce with QEMU. Thank you, tony
Bug#1056692: libhamlib4: Add protective diversion for udev rules shared file
On Mon, Nov 27, 2023 at 11:09:50AM +, Miguel Landaeta wrote: > On Mon, Nov 27, 2023 at 6:54 AM tony mancill wrote: > > An override like the following should work for this: > https://salsa.debian.org/debian/libnjb/-/blob/master/debian/libnjb5.lintian-overrides > > Thanks for looking at this patch. Thank you for providing the patch and a bug report with good background documentation. Applied and uploaded. Cheers, tony
Bug#1056692: libhamlib4: Add protective diversion for udev rules shared file
On Fri, Nov 24, 2023 at 04:59:48PM +, MigueL Landaeta wrote: > Package: libhamlib4 > Version: 4.5.5-2 > Severity: important > Tags: patch > User: helm...@debian.org > Usertags: dep17p7 > X-Debbugs-Cc: helm...@debian.org Hello Miguel, Thank you for the patch. I have applied it and tested locally and everything appears to be working correctly. I have an upload ready prepared, but wanted to confirm with you that this lintian error is expected after applying the patch: E: libhamlib4: diversion-for-unknown-file lib/udev/rules.d/60-libhamlib4.rules [preinst:14] N: N: The named maintainer script adds a diversion for a file that is not being provided by this package. N: N: Visibility: error N: Show-Always: no N: Check: maintainer-scripts/diversion Should I add a lintian-override for it? Thank you, tony
Bug#1055737: gpodder don't start , claim abandon
On Fri, Nov 10, 2023 at 12:23:13PM +0100, GT wrote: > Package: gpodder > Version: 3.11.3-1 > Severity: important > > 'gpodder.plugins.soundcloud.SoundcloudFavFeed'>> > Abandon > > >* What outcome did you expect instead? > The GUI should appear Hello and thank you for the bug report. I have not yet been able to reproduce this behavior on my system - including after removing recommended and suggested dependencies to match the bug report. And the only difference between the Settings.json you shared and mine is that "state" has been initialized with window geometries, but even if I use your Settings.json, gPodder starts up normally for me. All of the output logging you shared looks like normal startup output, up until the string "Abandon," which doesn't appear in the gPodder sources. So I'm not sure how to start triaging the problem you're seeing. Is it correct to assume that other Python GTK applications are working as expected? Thanks, tony signature.asc Description: PGP signature
Bug#1056779: derby-doc: some javadoc missing from derby-doc
Package: derby-doc Severity: normal I noticed during the preparation of 10.14.2.0-3 that the javadoc installed in the derby-doc binary package is much less than what is provided in 10.14.2.0-2. This must be due to some change in the toolchain, since rebuilding 10.14.2.0-2 against sid, trixie, or bookworm results in the same discrepancy.
Bug#1043471: pgpainless: FTBFS: make[1]: *** [debian/rules:40: override_dh_auto_test] Error 1
On Sat, Nov 04, 2023 at 12:01:48AM +0100, Santiago Vila wrote: > # also happens in bookworm > tags 1054771 + bookworm > thanks The cause of the FTBFS is that keys used as during the test suite have expired, so it will fail everywhere a build is attempted (unless the build system clock is rewound to before 2023-10-26). As a temporary measure, I have uploaded a work-around to ignore the impacted tests and keep the package in testing, but the real fix is to update pgpainless, as reported in Debian bug #1043471 [1], which is turn blocked by an update for BouncyCastle [2]. Cheers, tony [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043471 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049356 signature.asc Description: PGP signature
Bug#1056615: capnproto: CVE-2023-48230: WebSocket message can cause crash
On Thu, Nov 23, 2023 at 10:42:24PM +0100, Salvatore Bonaccorso wrote: > Source: capnproto > Version: 1.0.1-1 > Severity: important > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for capnproto. > > CVE-2023-48230[0]: > > (SNIP) > > [0] https://security-tracker.debian.org/tracker/CVE-2023-48230 > https://www.cve.org/CVERecord?id=CVE-2023-48230 > [1] > https://github.com/capnproto/capnproto/security/advisories/GHSA-r89h-f468-62w3 > [2] > https://github.com/capnproto/capnproto/commit/5d5d734b0350c6f2e36c3155753e6a19fbfeda9a Thank you for the bug report and for the Security Tracker entry. I have prepared a package for 1.0.1.1, but want to take a moment before uploading to experimental to consider whether there is a way to patch the vulnerability in 1.0.1 and thereby not have to perform a transition from 1.0.1 -> 1.0.1.1. Cheers, tony
Bug#1056554: mvel: FTBFS Java 21 due to removal of java.lang.Compiler interface
On Thu, Nov 23, 2023 at 02:56:18PM +1300, Vladimir Petko wrote: > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > > [1] https://salsa.debian.org/java-team/mvel/-/merge_requests/1 Merged and uploaded. Thank you for the patch.
Bug#1052589: Additional information
On Mon, Nov 20, 2023 at 03:02:26PM +1300, Vladimir Petko wrote: > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > Note: alternatively a new upstream release (M27) does not have this problem. > > Best Regards, > Vladimir. > > [1] > https://salsa.debian.org/java-team/apache-directory-server/-/merge_requests/1 The patch looks good to me. Markus, do you have a preference for this patch over updating to M27? I haven't looked closely at the efforts to update to M27 aside from the fact that our (other) patches will need to be ported, and there could be some build adjustments for the dependency on BouncyCastle. Thanks, tony signature.asc Description: PGP signature
Bug#1053023: Additional information
On Tue, Nov 21, 2023 at 09:58:40AM +1300, Vladimir Petko wrote: > [1] https://salsa.debian.org/java-team/gnome-split/-/merge_requests/1 Uploaded. Thank you for the patch.
Bug#1053021: Additional information
On Mon, Nov 20, 2023 at 05:06:22PM +1300, Vladimir Petko wrote: > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? > > Best Regards, > Vladimir. > > [1] https://salsa.debian.org/java-team/dbus-java/-/merge_requests/1 Yes, and thank you for the update. I will upload with this patch soon. Cheers, tony signature.asc Description: PGP signature
Bug#1056214: RM: doctorj -- ROM; dead upstream; obsolete
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: doct...@packages.debian.org Control: affects -1 + src:doctorj doctorj [1] has a low popcon, is dead upstream (the latest upstream release is May of 2013, and the last commit was January of 2014 [2]), and its functionality has (long) been supplanted by the linter that comes with the JDK's built-in javadoc command. For these reasons, I don't think the package should be included in trixie. This is a team-maintained package. I proposed the RM one week ago [3]. Thank you, tony [1] https://tracker.debian.org/pkg/doctorj [2] https://github.com/jpace/doctorj [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052498#25 signature.asc Description: PGP signature
Bug#1056070: hibiscus: Please package new version
On Sat, Nov 18, 2023 at 09:26:13PM +0100, Jochen Sprickerhof wrote: > Hi Tony, > > * tony mancill [2023-11-18 12:18]: > > Since this is a team-maintained package, I prepared an update; no > > packaging changes required. I have uploaded it to DELAYED-5 out of > > deference to Jochen, who has performed all of the uploads prior to now. > > > > Jochen, let me know if you would like me to dcut my upload. Otherwise, > > I will the push the updated branches to the packaging repo. > > Thanks for working on it! Did you also update hbci4java to the version used > by hibiscus? If yes, then feel free change the delay to 0. Otherwise I can > take care of both in the next days. Hi Jochen, Thank you for the pointer. No, I didn't update hbci4java. My upload has been canceled: > > cancel hibiscus_2.10.15+dfsg-1_source.changes > Files removed from 5-day: hibiscus_2.10.15+dfsg-1_source.changes > hibiscus_2.10.15+dfsg-1.dsc hibiscus_2.10.15+dfsg.orig.tar.xz > hibiscus_2.10.15+dfsg-1.debian.tar.xz hibiscus_2.10.15+dfsg-1_amd64.buildinfo Thank you, tony signature.asc Description: PGP signature
Bug#1056070: hibiscus: Please package new version
On Thu, Nov 16, 2023 at 06:49:11PM +0100, Martin Dosch wrote: > Package: hibiscus > Version: 2.10.12+dfsg-1 > Severity: wishlist > > Dear Jochen, > > could you please consider updating hibiscus to the current upstream > version? > > I checked out the git repo from salsa and locally built 2.10.15 without > any issue so it should be easy to update the version in the debian > repos. Hi, Since this is a team-maintained package, I prepared an update; no packaging changes required. I have uploaded it to DELAYED-5 out of deference to Jochen, who has performed all of the uploads prior to now. Jochen, let me know if you would like me to dcut my upload. Otherwise, I will the push the updated branches to the packaging repo. Cheers, tony signature.asc Description: PGP signature
Bug#1052498: Merge request
On Thu, Nov 09, 2023 at 12:25:17PM +0200, Pushkar Kulkarni wrote: > Submitted https://salsa.debian.org/java-team/doctorj/-/merge_requests/2 > for this. Hello Pushkar, Thank you for the merge request. It looks good, so I went ahead and merged it. However instead of preparing an upload, I propose that we remove doctorj from Debian. The upstream project has been inactive for 10 years, it has a low popcon score, and developers have other tools to accomplish the same goal - e.g, doclint + a spellchecker. If anyone on-list disagrees, please prepare an upload. Otherwise, I will file the RM bug. Thanks, tony signature.asc Description: PGP signature
Bug#1023047: wsjtx: No transmit audio
On Fri, Oct 13, 2023 at 08:57:38PM +0100, Christoph Berg wrote: > Re: erebion > > According to Pavucontrol there is no audio, as wsjtx does not show up. That > > is while transmitting, haven't tried to receive last time as I did not have > > the required cable with me. > > > > I think input was broken as well, but to be sure I'd need to have another > > look. > > You don't need the radio connected, you can also let wsjtx record > audio from the local mic and check if the ambient noise shows up on > the waterfall. (Same for TX and local speaker of course.) > > If wsjtx doesn't show up, I don't really know where to look further. > (Frustratingly, I have the same issue atm with wfview. I currently > blame pipewire, but I think it did work before.) I'm not claiming that this thread from the wsjt-devel [1] list is related, but perhaps it's a helpful hint? (I still can't reproduce the issue.) [1] https://sourceforge.net/p/wsjt/mailman/message/51780237/
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#1053983: dos2unix: Man page should mention that UTF-16 is converted to UTF-8 by default
Hi Ben, On Sun, Oct 15, 2023 at 02:22:43AM -0700, Ben Wong wrote: > Package: dos2unix > Version: 7.5.1-1 > Severity: normal > X-Debbugs-Cc: bugs.debian@wongs.net > > Dear Maintainer, > > The dos2unix man page claims that the default mode is "ASCII" and that > in ASCII mode only line endings will be changed. This is no longer > true. In the default mode, UTF-16 is converted to UTF-8 and the BOM is > removed. > > I do not know if this is still considered an "ASCII" mode or if the > default is some new UTF-8 mode. Please consider updating the > documentation to match the current behavior. Thank you for your bug report. I believe the portion of the manpage you are referring to is: CONVERSION MODES ascii In mode "ascii" only line breaks are converted. This is the default conversion mode. [**Missing information about UTF-16 behavior.**] Although the name of this mode is ASCII, which is a 7 bit standard, the actual mode is 8 bit. Use always this mode when converting Unicode UTF-8 files. Is this where you are expecting to see the manpage updated? It is perhaps somewhat hidden in the manpage, but I think this at least partially addresses the use case you describe: -u, --keep-utf16 Keep the original UTF-16 encoding of the input file. The output file will be written in the same UTF-16 encoding, little or big endian, as the input file. This prevents transformation to UTF-8. An UTF-16 BOM will be written accordingly. This option can be disabled with the "-ascii" option. That is, the use of -ascii (the default) negates --keep-utf16 and thus *does* perform the transformation to UTF-8 and *does not* write the UTF-16 BOM. I will forward the report to the upstream author. Thank you, tony
Bug#1053765: transition: capnproto
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: capnpr...@packages.debian.org Control: affects -1 + src:capnproto Hello Release Team, I am filing a transition bug for capnproto [1]. The new version is in experimental and all of the reverse build dependencies build successfully in a clean unstable chroot + the new capnproto binaries. The auto-transition page is here [2]. Please let me know if you have any questions. Thank you, tony [1] https://tracker.debian.org/pkg/capnproto [2] https://release.debian.org/transitions/html/auto-capnproto.html Ben file: title = "capnproto"; is_affected = .depends ~ "libcapnp-0.9.2" | .depends ~ "libcapnp-1.0.1"; is_good = .depends ~ "libcapnp-1.0.1"; is_bad = .depends ~ "libcapnp-0.9.2"; signature.asc Description: PGP signature
Bug#1053685: fcoe-utils FTBFS on 32-bit archs with gcc-13, successful with gcc-12
Source: fcoe-utils Severity: important With the most recent upload, the auto-builders detected a build failure on 32-bit architectures that appears to be a regression between gcc-12 and gcc-13. I'm starting the bug report here but will reassign or merge and add an affects once I am able to pin down the root cause or a case that reproduces it outside of fcoe-utils. Builds on i386, armhf, and armel fail with: > fcoemon.c:1347:9: error: ‘__builtin_strncpy’ output may be truncated copying > between 0 and 15 bytes from a string of length 15 > [-Werror=stringop-truncation] > 1347 | strncpy(msg.ifname, ff->ifname, iflen); > | ^ > cc1: all warnings being treated as errors The same build succeeds on 64-bit architectures, and on 32-bit architectures if you set CC=gcc-12. The only current bug against gcc-13 that looks plausibly related is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050589, but it's not clear to me that they are the same.
Bug#1053474: snappy-java: CVE-2023-43642
On Wed, Oct 04, 2023 at 09:41:10PM +0200, Salvatore Bonaccorso wrote: > Source: snappy-java > Version: 1.1.8.3-1 > Severity: important > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > The following vulnerability was published for snappy-java. > > CVE-2023-43642[0]: > > ...(SNIP)... > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2023-43642 > https://www.cve.org/CVERecord?id=CVE-2023-43642 > [1] > https://github.com/xerial/snappy-java/commit/9f8c3cf74223ed0a8a834134be9c917b9f10ceb5 > [2] > https://github.com/xerial/snappy-java/security/advisories/GHSA-55g7-9cwv-5qfv The latest upstream version 1.1.10.5 has been uploaded to unstable. I will look into what is required to apply the patch referenced above against 1.1.8.3 for bookworm and bullseye. signature.asc Description: PGP signature
Bug#1023047: wsjtx: No transmit audio
On Mon, Oct 02, 2023 at 07:08:23PM +0200, erebion wrote: > Just wanted to note that the issue persists with Debian Trixie as well. Hi, I'm tagging this moreinfo because I'm not able reproduce this on any recent Debian release. If you have provide any additional about your configuration, that could be helpful. Thanks, tony signature.asc Description: PGP signature
Bug#1051305: Request to Add 'loong64' to java-common's debian/java_defaults.mk
On Wed, Sep 13, 2023 at 12:39:50PM +0800, panxuefeng wrote: > Source: java-common > Version: 0.74 > Tags: patch > Severity: wishlist > Usertags: loongarch64 > User: debian-de...@lists.debian.org > I'm going to add loong64 support to the java-common package. Specifically, > added loong64 support for java17_architectures and jvm_archdir_map variables > in debian/java_defaults.mk file. Any concerns from the OpenJDK team about adding this architecture? If not, I can upload this change this weekend. signature.asc Description: PGP signature
Bug#1053088: Modify changelog message
On Wed, Sep 27, 2023 at 05:38:42PM +0800, panxuefeng wrote: > Package: service-wrapper-java > Version: 3.5.51 > Severity: wishlist > Tags: patch > User: debian-de...@lists.debian.org > Usertags: loongarch64 > > Dear Maintainers, > > I adjust unstable to unreleased in debian/changelog in > LoongArch-support-v3.patch. Hello Xuefeng Pan, Thank you for the updated patch. I have applied it and uploaded a new package revision to the archive. Cheers, tony signature.asc Description: PGP signature
Bug#967729: ripperx: depends on deprecated GTK 2
On Sun, Sep 24, 2023 at 12:53:01AM +0200, Bastian Germann wrote: > I suggest removing ripperx in favour of grimripper. Yes, given the state of ripperx upstream, I agree that this is a good course of action. I tested grimripper, and the functionality is nearly identical. I went ahead and filed a new wishlist bug against ripperx so we can discuss the removal there. Thank you for suggesting this. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052578 Regards, tony
Bug#1052578: ripperx: proposed-removal in favor of grimripper
Source: ripperx Version: 2.8.0-3 Severity: wishlist Given the inactivity of the ripperx project upstream and the fact that grimripper [1] is a suitable, modern replacement, I am filing this proposed-removal bug for ripperx (as per [2]). Thank you to Bastian Germann for suggesting this [3]. If folks have suggestions regarding how we can help ripperx users find the replacement, please provide feedback here. In the meantime, I will upload a ripperx package with a NEWS file suggesting that users install grimripper. For the trixie release, perhaps the ripperx package should be empty except for a manpage, the NEWS file, and a Recommends in debian/control? Thanks, tony [1] https://tracker.debian.org/pkg/grimripper [2] https://wiki.debian.org/qa.debian.org/removals [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967729#12
Bug#1052446: msktutil: invalid argument unwrapping for AUTOUPDATE_OPTIONS
On Fri, Sep 22, 2023 at 09:02:55AM +0200, Francesco wrote:
> Package: msktutil
> Version: 1.2-2
>
>
> bug fix for issue #1009904 doesn't look good for me:
>
> "/etc/cron.daily/msktutil:
> Error: unknown parameter: -N -h ldap-pp-01.example.org --service host
> --computer-name ldap-pp-01
>
> For help, try running msktutil --help
>
> run-parts: /etc/cron.daily/msktutil exited with return code 1"
>
> On my Debian GNU/Linux 12 (bookworm) the following script update works:
>
> $ cat /etc/cron.daily/msktutil
> #!/bin/sh
>
> test -x /usr/sbin/msktutil || exit 0
>
> # These options are overridden in /etc/default/msktutil.
> # Edit there, not here.
> AUTOUPDATE_ENABLED="false"
> AUTOUPDATE_OPTIONS=""
>
> [ -r /etc/default/msktutil ] && . /etc/default/msktutil
>
> [ "$AUTOUPDATE_ENABLED" = "true" ] || exit 0
> cmd="/usr/sbin/msktutil --auto-update ${AUTOUPDATE_OPTIONS}"
>
> exec $cmd
Hello François,
Thank you for the bug report. It is timely, because I am in the process
of preparing an upload of 1.2.1. I will get this fixed against 1.2 so
it is a candidate for stable-proposed-updates.
The expansion of $cmd in your version has the same impact as the eval
suggested in the bug report. My mistake, and thank you for the
correction.
Cheers,
tony
Bug#920111: Updating the cscope Uploaders list
On Wed, Sep 20, 2023 at 12:16:10AM +0200, Bastian Germann wrote: > Control: tags -1 pending > X-Debbugs-Cc: tmanc...@debian.org > > Tony, would you please upload a new version of the package including the > following commit? > https://salsa.debian.org/debian/cscope/-/commit/86d078bee598db0d87634cd53d82f2d868bee68c Hello Bastian, Yes, gladly! Thank you for the reminder. Cheers, tony
Bug#1041973: capnproto: not usable with gcc-13 and c++20
On Tue, Jul 25, 2023 at 01:32:18PM +0200, Andre Naujoks wrote: > Source: capnproto > Version: 0.9.2-3 > Severity: normal > Tags: upstream,fixed-upstream > X-Debbugs-Cc: andre.nauj...@keysight.com > > Currently the C++ generated code from capnproto does not work with gcc-13 and > C++20. > This can be reproduced by generating and compiling code for e.g. the sample > addressbook capnp file > (https://github.com/capnproto/capnproto/tree/v0.9.2/c%2B%2B/samples), which is > part of capnproto, like this: > > # capnpc -oc++ addressbook.capnp > # g++ -std=c++20 -c addressbook.capnp.c++ -o a.o > ^^^ this fails > > This seems to be fixed upstream in the current version (0.10.4). Hello Andre, Thank you for reporting the issue. I agree that the upstream fix [1] is more involved, and is part of a PR [2] that requires C++20. That's probably okay for unstable, but I need to take a look at the reverse dependencies before making the change. We could accommodate more users if the header conditionally did the right thing for c++20. Thank you, tony [1] https://github.com/capnproto/capnproto/commit/4f8bf494bbe5491cd2ff3c809bf986162dfb7387 [2] https://github.com/capnproto/capnproto/pull/1732 signature.asc Description: PGP signature
Bug#1051182: wsjtx: new upstream version 2.7.x
On Mon, Sep 04, 2023 at 12:07:49PM -0700, tony mancill wrote: > On Sun, Sep 03, 2023 at 08:39:38PM -0700, tony mancill wrote: > > This bug is for coordination purposes. I am in the process of preparing > > an upload of WSJT-X 2.7.0-rc2 to experimental, but I believe that it > > may require an upload of hamlib 4.6 (which will also likely need to go > > to experimental first). > > > > The debian branch will be pushed to debian/experimental to follow DEP-14 > > (https://dep-team.pages.debian.net/deps/dep14/), and if the team is okay > > with it, I propose switching from master -> debian/latest when the > > package is ready for upload to unstable. > > I have built wsjtx_2.7.0~rc2+repack-1 against bookworm and tested WSJT-X > running against the current version of hamlib in bookworm without any > issues, so I don't think there is a requirement for this to be > coordinated with an upload of hamlib. > > I'll do some more testing in trixie/unstable, but based on what I've > seen so far, I think 2.7.0~rc2 is a candidate for an upload to unstable. > Please let me know if there are any concerns. After successful testing with this version on trixie/unstable, I have uploaded 2.7.0~rc2 to unstable and updated the default branch in the Salsa repo to debian/latest. As always, thank you for filing bug reports and suggestions. Perhaps of interest to WSJT-X users is this recent thread [1] on wsjt-devel regarding new functionality added to PSKReporter for the upcoming solar eclipse [2]. Cheers, tony https://sourceforge.net/p/wsjt/mailman/message/37896251/ https://solarsystem.nasa.gov/eclipses/2023/oct-14-annular/where-when/ signature.asc Description: PGP signature
Bug#1051704: capnproto: Large File Support not enabled on 32 bits systems
On Mon, Sep 11, 2023 at 03:19:34PM +0200, Antonin Décimo wrote: > Package: capnproto > Version: 0.9.2 > Severity: important > > Dear Maintainer, > > capnproto doesn't define the _FILE_OFFSET_BITS=64 [1] feature test macro for > Large File Support on 32 bits systems. As a reminder, this macro switches > types such as off_t (size of a file) and ino_t (inode number) from 32 to 64 > bits. If capnproto encounters a file where these values exceed 32 bits, it'll > exit with an error. > > # kj/filesystem-disk-unix.c++:305: failed: ::fstat(fd, ): > Value too large for defined data type > > The issue has been fixed upstream since v1.0.0, in commit 7c8802f [2]. > I suggest capnproto be updated to the latest version, or the macro > _FILE_OFFSET_BITS=64 be defined globally at compile-time for this package, or > apply the commit as a patch. > > [1]: > https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fFILE_005fOFFSET_005fBITS > [2]: > https://github.com/capnproto/capnproto/commit/7c8802fb9bec8818f289a44b0ec22419a845b249 Hi Antonin, Thank you for the bug report. For the short-term, I'll apply the patch since it's so simple. Longer-term, I'll coordinate with Tom (the maintainer) on getting 1.0 into trixie. Cheers, tony signature.asc Description: PGP signature
Bug#1051966: icmake: Please add bootstrap build profile to break circular build dependency
On Fri, Sep 15, 2023 at 12:50:37AM +0200, John Paul Adrian Glaubitz wrote: > Source: icmake > Version: 10.04.01-2 > Severity: normal > User: debian-de...@lists.debian.org > Usertags: loong64 > X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn > > Hi! > > The changelog entry for icmake 10.03.02-1 reads: > > * New upstream version 10.03.02 adds bobcatbootstrap to build icmake > on systems that haven't installed the bobcat library > > However, looking at debian/control, the build dependency on libbobcat-dev is > actually unconditional and there is currently no way to build the icmake > Debian package without having libbobcat-dev installed. This is in particular > problematic because src:bobcat build-depends on icmake to build. > > A build profile which allows to disable the libbobcat-dev build dependency > temporarily and use the aforementioned bootstrap mechanism would be very > helpful for bootstrapping icmake on new architectures such as loong64. Hi Adrian, The bootstrap instructions are included in the source package [1]. This is new to me, so I'm looking for some guidance here. Is the expectation an upload of an icmake source package that can build itself? It would have to have build-deps libbobcat-dev | bobcat-src in order to avoid having to download the bobcat sources. In this scenario, I believe we would need to introduce a new bobcat-src (binary) package. Or, should it build-dep on libbobcat-dev | (something always available) and then in debian/rules detect the lack of libbobcat-dev and perform the bootstrap by downloading the bobcat sources tarball? Or something else? In any case, we can a script to the icmake source to perform the bootstrap once we have decided on a way to obtain the bobcat sources. Thank you, tony [1] https://salsa.debian.org/debian/icmake/-/blob/debian/latest/README.bobcatbootstrap signature.asc Description: PGP signature
Bug#1051966: icmake: Please add bootstrap build profile to break circular build dependency
On Fri, Sep 15, 2023 at 12:50:37AM +0200, John Paul Adrian Glaubitz wrote: > Source: icmake > Version: 10.04.01-2 > Severity: normal > User: debian-de...@lists.debian.org > Usertags: loong64 > X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn > > The changelog entry for icmake 10.03.02-1 reads: > > * New upstream version 10.03.02 adds bobcatbootstrap to build icmake > on systems that haven't installed the bobcat library > > However, looking at debian/control, the build dependency on libbobcat-dev is > actually unconditional and there is currently no way to build the icmake > Debian package without having libbobcat-dev installed. This is in particular > problematic because src:bobcat build-depends on icmake to build. > > A build profile which allows to disable the libbobcat-dev build dependency > temporarily and use the aforementioned bootstrap mechanism would be very > helpful for bootstrapping icmake on new architectures such as loong64. Hi Adrian, Oh, good catch! Thank you for reporting the bug. I will follow up. Cheers, tony 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#1051411: fcoe-utils: Cyclic systemd unit dependencies
On Sun, Sep 10, 2023 at 05:53:23PM +0200, Valentin Vidic wrote: > On Thu, Sep 07, 2023 at 07:55:56PM -0700, tony mancill wrote: > > Thank you for the bug report. My initial instinct is to use the same > > unit file and service dependencies as upstream. Looking at the history > > of Debian's patch [2] of the unit file, and specifically this commit > > [3], it appears that the change was made to resolve an issue. > > > > The patch to the systemd unit file predates my involvement with this > > package, so Valentin may be able to provide more context. Perhaps > > there was a bug in fcoe-utils that necessitated the change at that time, > > but we can now revert to the unit file patch? > > > > Valentin, do you have any insight on this? Without a link to the > > original bug, I'm unsure what regression reverting to the upstream unit > > file dependencies might cause. > > Hi, as the comment on commit 1519b5cd suggests, I think there was some > race condition with getting FCoE working reliably on boot. It is > possible this is not required and can be reverted, but I don't have > access to the hardware anymore to test it. > > Another option would be to move both services to start before the > network, if the testing shows that this is still required. I also don't have access to the hardware to test it. My assumption is that upstream would see bug reports if the race condition still exists, but that's merely conjecture on my part. Do you have any concerns with an upload to unstable (or experimental) to revert the unit file change? Thank you, tony signature.asc Description: PGP signature
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
