Bug#466758: [Foo2zjs-maintainer] Bug#466758: foo2zjs: up-to-date upstream release
Ciao Luca! No problem! Certainly, I don't mind that much. As I already pointed out, that was unnecessary double-work of mine because I just came across your version after I had finished my changes. There may be little differences between your changes and mine though. So it could be worth to check these patches with your patches by diff. But I am not quite sure about this. It's more than a month ago. Nevertheless, it might be a good idea to get a fresh upstream release if you are willing to build a new package release. After all, your unreleased package is built on the code base of last autumn. Bye, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524149: RFH: Bug#524149: blt and segmentation faults
Hi folks, can you please add --enable-jpeg to CONFIGURE in debian/rules:14 and libjpeg8-dev to Build-Depends in debian/control:5. Thanks in advance, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631147: inline-octave: missing package libinline-octave-perl after update to current Debian/stable, but new upstream release found in CPAN
Package: inline-octave Severity: normal Recent Perl bindings for Octave are missing in current stable/testing/unstable Debian releases. The statement in bug #516112 as can be viewed at http://bugs.debian.org/516112 is not true any longer. The latest version 0.31 supports at least Octave 3.2 and can be downloaded from CPAN at http://search.cpan.org/~aadler/Inline-Octave/ . Is there any chance of re-adding this package to Debian's package repository? -- System Information: Debian Release: 6.0.1 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631147: inline-octave: missing package libinline-octave-perl after update to current Debian/stable, but new upstream release found in CPAN
Hi folks, is there anyone willing to relaunch the package inline-octave that was last included in lenny which is now oldstable. The Perl module is only one file and there is a current update available at http://search.cpan.org/~aadler/Inline-Octave/ . Thanks in advance for your support and maintainership, Thomas Uhle On Thu, 30 Jun 2011, Thomas Uhle wrote: On Sun, 26 Jun 2011, Thomas Weber wrote: Hi Thomas, On Mon, Jun 20, 2011 at 08:33:37PM +0200, Thomas Uhle wrote: Recent Perl bindings for Octave are missing in current stable/testing/unstable Debian releases. The statement in bug #516112 as can be viewed at http://bugs.debian.org/516112 is not true any longer. The latest version 0.31 supports at least Octave 3.2 and can be downloaded from CPAN at http://search.cpan.org/~aadler/Inline-Octave/ . Is there any chance of re-adding this package to Debian's package repository? Someone will need to step up and do the necessary work. As you haven't received an answer so far about it, I'd say that no one of the current members in the group is interested in the Perl bindings - I know that I'm definitely not interested. You might want to check with the Perl packagers in Debian. There are a lot of CPAN packages in Debian, maybe they are interested in maintaining the package. Thomas Hi Thomas, thanks a lot for your message. I think that the task to update the old Debian package with the new upstream release is quickly done by someone who knows about the current Lintian stuff, etc. I cannot do it in due time since it is too long ago when I was building Debian packages myself and I am not up-to-date for sure. Moreover, I could imagine that it is no mess for a current Debian package maintainer because the Perl module consists of only one file. I will try to contact and ask Debian's Perl package maintainers. That's actually a good idea. Thanks again, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631147: [Pkg-octave-devel] Bug#631147: inline-octave: missing package libinline-octave-perl after update to current Debian/stable, but new upstream release found in CPAN
On Sun, 26 Jun 2011, Thomas Weber wrote: Hi Thomas, On Mon, Jun 20, 2011 at 08:33:37PM +0200, Thomas Uhle wrote: Recent Perl bindings for Octave are missing in current stable/testing/unstable Debian releases. The statement in bug #516112 as can be viewed at http://bugs.debian.org/516112 is not true any longer. The latest version 0.31 supports at least Octave 3.2 and can be downloaded from CPAN at http://search.cpan.org/~aadler/Inline-Octave/ . Is there any chance of re-adding this package to Debian's package repository? Someone will need to step up and do the necessary work. As you haven't received an answer so far about it, I'd say that no one of the current members in the group is interested in the Perl bindings - I know that I'm definitely not interested. You might want to check with the Perl packagers in Debian. There are a lot of CPAN packages in Debian, maybe they are interested in maintaining the package. Thomas Hi Thomas, thanks a lot for your message. I think that the task to update the old Debian package with the new upstream release is quickly done by someone who knows about the current Lintian stuff, etc. I cannot do it in due time since it is too long ago when I was building Debian packages myself and I am not up-to-date for sure. Moreover, I could imagine that it is no mess for a current Debian package maintainer because the Perl module consists of only one file. I will try to contact and ask Debian's Perl package maintainers. That's actually a good idea. Thanks again, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740192: gtklp: request to update to recent release 1.3.0
Package: gtklp Version: 1.2.7-2.3 Severity: wishlist X-Debbugs-CC: Zak B. Elep zak...@zakame.net GtkLP is somewhat outdated in Debian. The recent upstream release of GtkLP is 1.3.0 which fixes a lot of bugs (see http://gtklp.sirtobi.com/changelog.shtml ). Could you please consider to update the Debian package gtklp to the upstream release 1.3.0. Thank you in advance! Thomas Uhle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740194: ngspice: request to update to recent upstream release 26
Package: ngspice Version: 24-1 Severity: wishlist X-Debbugs-CC: Debian Science Team debian-science-maintain...@lists.alioth.debian.org The new upstream release 26 for ngspice provides building a shared library libngspice.so. So could you please update to this new version and provide an additional Debian package for ngspice's shared library (e.g., libngspice0 + libngspice-dev). In addition, ngspice release 26 allows to compile and link using the faster FFTW3. Could you please consider it in the build dependencies. Thank you in advance! Thomas Uhle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
Package: libopenconnect2
Version: 5.03-1
Severity: important
Tags: patch upstream
X-Debbugs-CC: openconnect-de...@lists.infradead.org
The changes in gnutls.c from v5.01 to v5.02 concerning support of CA
certificates from PKCS#11 tokens (with GnuTLS 3.2.7+) break functionality
in openconnect at least if compiled with GnuTLS 2.12.x. Therefore, it also
affects libopenconnect2 (= 5.02-1) in Ubuntu 14.04LTS.
I have tried to investigate on this issue with GDB and have come as far as
to gnutls.c:1517 where err is not the return value of any call to
gnutls_pkcs11_get_raw_issuer() or gnutls_x509_crt_import() within the
code guarded by
#if defined(HAVE_P11KIT) defined(HAVE_GNUTLS_PKCS11_GET_RAW_ISSUER)
if compiled with GnuTLS 2.12.x as in Debian and Ubuntu Linux.
So I thought to shift the lines 1517-1518 if (err) break; upwards to
its original position, but then it crashes in gnutls.c:1522 invoking
function gnutls_x509_crt_check_issuer(). Finally, I have given up and,
although I know this is far from being smart, I reverted all changes in
gnutls.c to v5.01 which works perfectly for me. The patch for reverting
changes in gnutls.c is attached.
Could you please find a smarter fix or at least apply the given patch
temporarily.
Thank you in advance!
Thomas Uhle--- openconnect-5.03/gnutls.c 2014-02-03 14:11:19 +0100
+++ openconnect-5.01/gnutls.c 2014-04-10 14:10:52 +0200
@@ -499,7 +499,8 @@ static int assign_privkey(struct opencon
gnutls_privkey_t pkey,
gnutls_x509_crt_t *certs,
unsigned int nr_certs,
- uint8_t *free_certs)
+ gnutls_x509_crt_t *extra_certs,
+ unsigned int nr_extra_certs)
{
int i;
@@ -507,21 +508,28 @@ static int assign_privkey(struct opencon
if (!vpninfo-my_certs)
return GNUTLS_E_MEMORY_ERROR;
- vpninfo-free_my_certs = gnutls_malloc(nr_certs);
- if (vpninfo-free_my_certs) {
- gnutls_free(vpninfo-my_certs);
- vpninfo-my_certs = NULL;
- return GNUTLS_E_MEMORY_ERROR;
- }
-
- memcpy(vpninfo-free_my_certs, free_certs, nr_certs);
memcpy(vpninfo-my_certs, certs, nr_certs * sizeof(*certs));
vpninfo-nr_my_certs = nr_certs;
/* We are *keeping* the certs, unlike in GnuTLS 3 where our caller
can free them after gnutls_certificate_set_key() has been called.
- So wipe the 'free_certs' array. */
- memset(free_certs, 0, nr_certs);
+ So first wipe the 'certs' array (which is either 'cert' or
+ 'supporting_certs' in load_certificate())... */
+ memset(certs, 0, nr_certs * sizeof(*certs));
+
+ /* ... and then also zero out the entries in extra_certs[] that
+ correspond to the certs that we're stealing.
+ We know certs[0] was already stolen by the load_certificate()
+ function so we might as well start at certs[1]. */
+ for (i = 1; i nr_certs; i++) {
+ int j;
+ for (j = 0; j nr_extra_certs; j++) {
+ if (vpninfo-my_certs[i] == extra_certs[j]) {
+extra_certs[j] = NULL;
+break;
+ }
+ }
+ }
gnutls_certificate_set_retrieve_function(vpninfo-https_cred,
gtls_cert_cb);
@@ -539,7 +547,8 @@ static int assign_privkey(struct opencon
gnutls_privkey_t pkey,
gnutls_x509_crt_t *certs,
unsigned int nr_certs,
- uint8_t *free_certs)
+ gnutls_x509_crt_t *extra_certs,
+ unsigned int nr_extra_certs)
{
gnutls_pcert_st *pcerts = calloc(nr_certs, sizeof(*pcerts));
int i, err;
@@ -891,7 +900,7 @@ static int load_certificate(struct openc
gnutls_x509_crt_t last_cert, cert = NULL;
gnutls_x509_crt_t *extra_certs = NULL, *supporting_certs = NULL;
unsigned int nr_supporting_certs = 0, nr_extra_certs = 0;
- uint8_t *free_supporting_certs = NULL;
+ unsigned int certs_to_free = 0; /* How many of supporting_certs */
int err; /* GnuTLS error */
int ret;
int i;
@@ -1002,12 +1011,6 @@ static int load_certificate(struct openc
else if (!ret) {
if (nr_supporting_certs) {
cert = supporting_certs[0];
-free_supporting_certs = gnutls_malloc(nr_supporting_certs);
-if (!free_supporting_certs) {
- ret = -ENOMEM;
- goto out;
-}
-memset(free_supporting_certs, 1, nr_supporting_certs);
goto got_key;
}
vpn_progress(vpninfo, PRG_ERR,
@@ -1428,35 +1431,19 @@ static int load_certificate(struct openc
choose the _right_ one. (RT#1942)
Pick the right ones for ourselves and add them manually. */
- /* We may have already got a bunch of certs from PKCS#12
- file. Remember how many need to be freed when we're done,
- since we'll expand the supporting_certs array with more
- from the cafile and extra_certs[] array if we can, and
- those extra certs must not be freed (twice). */
- if (!nr_supporting_certs) {
- supporting_certs = gnutls_malloc(sizeof(*supporting_certs));
- if (!supporting_certs) {
- vpn_progress(vpninfo, PRG_ERR,
- _(Failed to allocate memory for certificate\n));
- ret = -ENOMEM;
- goto out;
- }
- supporting_certs[0] = cert;
- nr_supporting_certs = 1;
-
- free_supporting_certs = gnutls_malloc(1
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
On Fri, 11 Apr 2014, David Woodhouse wrote:
Thanks for the bug report. Please could you describe the exact failure
mode? Can you provide output with '-v' both before and after the
offending change?
[...]
Please could you confirm that building that version from git is failing,
and building the previous version from before that patch is working? I'd
like to be sure it isn't one of the other changes in gnutls.c between
v5.01 and v5.02.
Thank you for the immediate response! So, to cut a long story short: I
have spent some more time on debugging the code changes in gnutls.c, and
you were right. Both versions from git are failing. The bug was hiding
in the code you had changed before. Eventually, the bug was found in the
function assign_privkey() (line 510), please see the attached patch.
Regards,
Thomas Uhle--- openconnect-5.03/gnutls.c~ 2014-02-03 14:11:19 +0100
+++ openconnect-5.03/gnutls.c 2014-04-12 18:14:56 +0200
@@ -501,14 +501,12 @@ static int assign_privkey(struct opencon
unsigned int nr_certs,
uint8_t *free_certs)
{
- int i;
-
vpninfo-my_certs = gnutls_calloc(nr_certs, sizeof(*certs));
if (!vpninfo-my_certs)
return GNUTLS_E_MEMORY_ERROR;
vpninfo-free_my_certs = gnutls_malloc(nr_certs);
- if (vpninfo-free_my_certs) {
+ if (!vpninfo-free_my_certs) {
gnutls_free(vpninfo-my_certs);
vpninfo-my_certs = NULL;
return GNUTLS_E_MEMORY_ERROR;
@@ -1004,6 +1002,8 @@ static int load_certificate(struct openc
cert = supporting_certs[0];
free_supporting_certs = gnutls_malloc(nr_supporting_certs);
if (!free_supporting_certs) {
+ vpn_progress(vpninfo, PRG_ERR,
+ _(Failed to allocate memory for supporting certificates\n));
ret = -ENOMEM;
goto out;
}
@@ -1437,7 +1437,7 @@ static int load_certificate(struct openc
supporting_certs = gnutls_malloc(sizeof(*supporting_certs));
if (!supporting_certs) {
vpn_progress(vpninfo, PRG_ERR,
- _(Failed to allocate memory for certificate\n));
+ _(Failed to allocate memory for supporting certificates\n));
ret = -ENOMEM;
goto out;
}
@@ -1447,7 +1447,7 @@ static int load_certificate(struct openc
free_supporting_certs = gnutls_malloc(1);
if (!free_supporting_certs) {
vpn_progress(vpninfo, PRG_ERR,
- _(Failed to allocate memory for certificate\n));
+ _(Failed to allocate memory for supporting certificates\n));
ret = -ENOMEM;
goto out;
}
@@ -1514,9 +1514,9 @@ static int load_certificate(struct openc
gnutls_free(t.data);
}
#endif
+
if (err)
break;
-
}
if (gnutls_x509_crt_check_issuer(issuer, issuer)) {
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
On Mon, 14 Apr 2014, Mike Miller wrote: Additionally, the current 5.99 package in Debian experimental is built using GnuTLS 3.x, so AFAICT this bug does not affect these packages. Can you install 5.99-2 from experimental and verify that the bug is not present? You are right, the bug is only present if compiled with libgnutls-dev ( 3.0.0), your build from experimental is therefore not affected. As far as Ubuntu is concerned, could you please submit a launchpad bug and we can apply this fix as an SRU for the next 14.04 update? Here is the Launchpad bug ticket: https://bugs.launchpad.net/debian/+source/openconnect/+bug/1308054 Regards, Thomas Uhle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744214: Fix compiler warning by removing unused variable amend failure messages in gnutls.c (was: Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x)
remaining changes from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744214
- remove unused variable in assign_privkey() to prevent compiler warning with
-Wall
- amend some failure messages which could otherwise be misleading
- initial bug was already fixed in commit
#43e514b4f53c147936a7379e8e6fc67f78cae2fb
Signed-off-by: Thomas Uhle thomas.u...@mailbox.tu-dresden.de
---
David, if you like, you are free to merge these changes upstream.
Regards,
Thomas Uhle--- openconnect-5.03/gnutls.c~ 2014-02-03 14:11:19 +0100
+++ openconnect-5.03/gnutls.c 2014-04-12 18:14:56 +0200
@@ -501,8 +501,6 @@ static int assign_privkey(struct opencon
unsigned int nr_certs,
uint8_t *free_certs)
{
- int i;
-
vpninfo-my_certs = gnutls_calloc(nr_certs, sizeof(*certs));
if (!vpninfo-my_certs)
return GNUTLS_E_MEMORY_ERROR;
@@ -1004,6 +1002,8 @@ static int load_certificate(struct openc
cert = supporting_certs[0];
free_supporting_certs = gnutls_malloc(nr_supporting_certs);
if (!free_supporting_certs) {
+ vpn_progress(vpninfo, PRG_ERR,
+ _(Failed to allocate memory for supporting certificates\n));
ret = -ENOMEM;
goto out;
}
@@ -1437,7 +1437,7 @@ static int load_certificate(struct openc
supporting_certs = gnutls_malloc(sizeof(*supporting_certs));
if (!supporting_certs) {
vpn_progress(vpninfo, PRG_ERR,
- _(Failed to allocate memory for certificate\n));
+ _(Failed to allocate memory for supporting certificates\n));
ret = -ENOMEM;
goto out;
}
@@ -1447,7 +1447,7 @@ static int load_certificate(struct openc
free_supporting_certs = gnutls_malloc(1);
if (!free_supporting_certs) {
vpn_progress(vpninfo, PRG_ERR,
- _(Failed to allocate memory for certificate\n));
+ _(Failed to allocate memory for supporting certificates\n));
ret = -ENOMEM;
goto out;
}
@@ -1514,9 +1514,9 @@ static int load_certificate(struct openc
gnutls_free(t.data);
}
#endif
+
if (err)
break;
-
}
if (gnutls_x509_crt_check_issuer(issuer, issuer)) {
Bug#749908: RFP: python3-usb -- USB interface for Python
Package: wnpp Severity: wishlist Owner: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org * Package name: python3-usb Source name : PyUSB Version : 1.0.0b1 Upstream Author : Wander Lairson * URL : http://sourceforge.net/apps/trac/pyusb * License : BSD Programming Lang: Python Description : USB interface for Python -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740194: closed by Andreas Beckmann <a...@debian.org> (Re: ngspice: request to update to recent upstream release 26)
Andreas, you are right that version 26 was released in July 2014, but AFAICS without compiling it with FFTW3 support which I also asked for. Best regards, Thomas Uhle
Bug#910764: openjfx: segmentation fault in GtkNativeMainLoopThread with GTK 3
Hello Markus, it seems that the bugfix has been backported upstream to OpenJFX 11.0.2 as well. Please see https://bugs.openjdk.java.net/browse/JDK-8216292 for further reference. Regards, Thomas
Bug#514453: , #757535: [caja|nautilus]: should properly unmount fuse mounts
On Fri, 28 May 2021, Simon McVittie wrote: On Fri, 28 May 2021 at 15:00:04 +0200, Thomas Uhle wrote: > As far as I can confirm, it is working with sshfs/3.7.1+repack-1 together > with mount/2.36.1-7 and libmount1/2.36.1-7 resp. which are the currently > packaged versions for bullseye. I have never tested an older version of > mount from util-linux after version 2.33.1-0.1 because I am basically still > on Debian 10 (buster) To confirm, does this mean you are still using buster's version of either caja or nautilus, and the mount upgrade resolved this for you? If yes, Yes, you're right. It's still the older version of Nautilus. Yet it's not just mount, libmount1 and other binary packages from util-linux but also libselinux1, libsepol1 and libsemanage1 that I had to update because of binary dependencies. that seems like good evidence that this was a limitation of older versions of mount (util-linux), rather than a limitation of older versions of caja and nautilus. I think it's hard to tell where the limitations are if several tools and libraries interact together. It is certainly not Nautilus because it just calls GMount::unmount_with_operation() from GIO (in nautilus_file_operations_unmount_mount_full() for instance). I assume that is the same for all of its descendants (Caja, Pantheon Files and alike). So it makes sense to solve this further down in GIO/GVFS, FUSE or mount. It is arguable where best and how exactly to fix this as you can see in various discussions, e.g., https://gitlab.gnome.org/GNOME/gvfs/issues/133, https://gitlab.gnome.org/GNOME/glib/issues/633, https://github.com/libfuse/libfuse/issues/246 and https://github.com/karelzak/util-linux/pull/705. In the end, it was done in mount and libmount respectively. But this does not necessarily mean that mount had a limitation. Best regards, Thomas Uhle
Bug#514453: #514453 - nautilus: should properly unmount fuse mounts
Hello, according to https://github.com/karelzak/util-linux/pull/705, this old issue seems to finally have been fixed natively in mount/libmount1 from util-linux (since version 2.34). That was too late for Debian 10 (buster), but it should work with the upcoming Debian 11 (bullseye). Best regards, Thomas Uhle
Bug#514453: Bug#757535: #514453 - nautilus: should properly unmount fuse mounts
Hi Mike, I guess I'm not in the position to make such a decision but for me it sounds reasonable. As far as I can confirm, it is working with sshfs/3.7.1+repack-1 together with mount/2.36.1-7 and libmount1/2.36.1-7 resp. which are the currently packaged versions for bullseye. I have never tested an older version of mount from util-linux after version 2.33.1-0.1 because I am basically still on Debian 10 (buster) and, thus, just recently faced the same problem and on my way for a solution came upon PR 705 for util-linux on Github that made its way into version 2.34. So as there aren't any newer packages in buster-backports, I manually updated all the binary packages of util-linux, sshfs, libselinux, etc. to the current versions from bullseye. Et voilà, it is working like it is supposed to be. Long story short, there is strong evidence that it's also working with the binary packages from util-linux/2.34-0.1 but I haven't tested those. Best regards, Thomas
Bug#991012: tor: still suggests tor-arm instead of nyx
Package: tor Version: 0.4.5.9-1 Severity: normal Dear maintainers, tor still suggests tor-arm which is a transitional package since 2017. tor-arm depends on nyx in turn. Maybe you could update "Suggests" dependencies by using nyx instead of tor-arm. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-7-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tor depends on: ii adduser 3.118 ii libc6 2.31-12 ii libcap2 1:2.44-1 ii libevent-2.1-7 2.1.12-stable-1 ii liblzma55.2.5-2 ii libssl1.1 1.1.1k-1 ii libsystemd0 247.3-5 ii libzstd11.4.8+dfsg-2.1 ii lsb-base11.1.0 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages tor recommends: ii logrotate3.18.0-2 ii tor-geoipdb 0.4.5.9-1 ii torsocks 2.3.0-3 Versions of packages tor suggests: pn apparmor-utils pn mixmaster pn obfs4proxy pn socat pn tor-arm pn torbrowser-launcher
Bug#991010: i2c-tools: still suggests python-smbus instead of python3-smbus
Package: i2c-tools Version: 4.2-1+b1 Severity: important Dear maintainers, the package i2c-tools (currently in bullseye) still suggests python-smbus although it has been dropped almost two years ago. Could you please update "Suggests" dependencies using python3-smbus instead of python-smbus. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-7-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages i2c-tools depends on: ii adduser 3.118 ii libc62.31-12 ii libi2c0 4.2-1+b1 ii perl 5.32.1-4 ii udev 247.3-5 Versions of packages i2c-tools recommends: pn read-edid Versions of packages i2c-tools suggests: ii libi2c-dev4.2-1+b1 pn python-smbus
Bug#991007: libchromaprint1: still suggests python-acoustid instead of python3-acoustid
Package: libchromaprint1 Version: 1.5.0-2 Severity: important Dear maintainers, the package libchromaprint1 (currently in bullseye) still suggests python-acoustid although it has been removed last year. Could you please update "Suggests" dependencies using python3-acoustid instead of python-acoustid. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-7-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libchromaprint1 depends on: ii libavcodec58 10:4.3.2-dmo0~bpo10+5 ii libavutil56 10:4.3.2-dmo0~bpo10+5 ii libc6 2.31-12 ii libgcc-s1 10.2.1-6 ii libstdc++610.2.1-6 libchromaprint1 recommends no packages. libchromaprint1 suggests no packages.
Bug#991009: dh-python: upgrade or install breaks python-is-python2
Package: dh-python Version: 4.20201102+nmu1 Severity: important Dear maintainers, while upgrading from buster to bullseye, I recognised that the new dh-python package breaks the python-is-python2 package. Though with python-is-python3 it is working. Unlike "Replaces", python in the "Breaks" statement is missing version information. With the same version information as in "Replaces" it is working. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-7-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dh-python depends on: ii python33.9.2-3 ii python3-distutils 3.9.2-1 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.20.9 ii libdpkg-perl 1.20.9
Bug#985742: qttools5-dev-tools: Please provide application desktop file for qdbusviewer
Package: qttools5-dev-tools Version: 5.11.3-4 Severity: normal Dear maintainers, could you please add an application desktop file for qdbusviewer. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qttools5-dev-tools depends on: ii libc6 2.28-10 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg1-1+deb10u4 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u4 ii libqt5designer5 5.11.3-4 ii libqt5designercomponents5 5.11.3-4 ii libqt5gui55.11.3+dfsg1-1+deb10u4 ii libqt5help5 5.11.3-4 ii libqt5network55.11.3+dfsg1-1+deb10u4 ii libqt5printsupport5 5.11.3+dfsg1-1+deb10u4 ii libqt5quickwidgets5 5.11.3+dfsg1-1+deb10u4 ii libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u4 ii libqt5webkit5 5.212.0~alpha2-21 ii libqt5widgets55.11.3+dfsg1-1+deb10u4 ii libqt5xml55.11.3+dfsg1-1+deb10u4 ii libstdc++68.3.0-6 ii qdoc-qt5 5.11.3-4 ii qt5-assistant 5.11.3-4 ii qtchooser 66-2 qttools5-dev-tools recommends no packages. qttools5-dev-tools suggests no packages.
Bug#985747: qttools5-dev-tools: Qt Designer and Qt Linguist as separate packages
Package: src:qttools-opensource-src Version: 5.11.3-4 Severity: normal Dear maintainers, could you please put Qt Designer as well as Qt Linguist in separate packages qt5-designer and qt5-linguist resp. (similar to qt5-assistant and qdoc-qt5) and then lower the dependencies to 'Recommends: qt5-assistant, qt5-designer, qt5-linguist'. The hard dependency on qt5-assistant would be moved to both new packages in turn. Next to the linguist executable, package qt5-linguist should also include its companions like lrelease, lupdate, etc., the corresponding man pages, the phrase books, the Linguist pixmap icon and its application desktop file. So its dependencies would then just look like this for instance: Versions of packages qt5-linguist depends on: ii libc6 2.28-10 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg1-1+deb10u4 ii libqt5gui55.11.3+dfsg1-1+deb10u4 ii libqt5printsupport5 5.11.3+dfsg1-1+deb10u4 ii libqt5widgets55.11.3+dfsg1-1+deb10u4 ii libqt5xml55.11.3+dfsg1-1+deb10u4 ii libstdc++68.3.0-6 ii qt5-assistant 5.11.3-4 ii qtchooser 66-2 For qt5-designer, this would be alike. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qttools5-dev-tools depends on: ii libc6 2.28-10 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg1-1+deb10u4 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u4 ii libqt5designer5 5.11.3-4 ii libqt5designercomponents5 5.11.3-4 ii libqt5gui55.11.3+dfsg1-1+deb10u4 ii libqt5help5 5.11.3-4 ii libqt5network55.11.3+dfsg1-1+deb10u4 ii libqt5printsupport5 5.11.3+dfsg1-1+deb10u4 ii libqt5quickwidgets5 5.11.3+dfsg1-1+deb10u4 ii libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u4 ii libqt5webkit5 5.212.0~alpha2-21 ii libqt5widgets55.11.3+dfsg1-1+deb10u4 ii libqt5xml55.11.3+dfsg1-1+deb10u4 ii libstdc++68.3.0-6 ii qdoc-qt5 5.11.3-4 ii qt5-assistant 5.11.3-4 ii qtchooser 66-2 qttools5-dev-tools recommends no packages. qttools5-dev-tools suggests no packages.
Bug#985734: cantata: Please update build dependencies
Package: src:cantata Version: 2.3.3.ds1-1 Severity: normal Dear maintainers, can you please update the build dependencies to build a full-grown binary release of Cantata. That would need to add libavahi-common-dev, libavahi-client-dev and libdbus-1-dev as build dependencies as well as to replace libcdparanoia-dev by libcdio-paranoia-dev. On the other hand you could remove some build dependencies that are no longer used, that is libphonon4qt5-dev, libvlc-dev, libvlccore-dev and libx11-dev because QtMultimedia has been used instead of Phonon since more than 8 years for instance. Also qtbase5-dev no longer directly depends on libx11-dev, and Cantata does also not need X11 headers to be compiled having a Qt version without X11 support. So I think an indirect dependency on libx11-dev via qtbase5-dev (which in turn depends on libxext-dev ...) would be sufficient. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cantata depends on: ii fonts-font-awesome5.0.10+really4.7.0~dfsg-1 ii libavcodec58 7:4.1.6-1~deb10u1 ii libavformat58 7:4.1.6-1~deb10u1 ii libavutil56 7:4.1.6-1~deb10u1 ii libc6 2.28-10 ii libcddb2 1.3.2-6 ii libcdparanoia03.10.2+debian-13 ii libebur128-1 1.2.4-2 ii libgcc1 1:8.3.0-6 ii libmpg123-0 1.25.10-2 ii libmtp9 1.1.16-2 ii libmusicbrainz5cc2v5 5.1.0+git20150707-9 ii libqt5concurrent5 5.11.3+dfsg1-1+deb10u4 ii libqt5core5a 5.11.3+dfsg1-1+deb10u4 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u4 ii libqt5gui55.11.3+dfsg1-1+deb10u4 ii libqt5multimedia5 5.11.3-2 ii libqt5network55.11.3+dfsg1-1+deb10u4 ii libqt5sql55.11.3+dfsg1-1+deb10u4 ii libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u4 ii libqt5svg55.11.3-2 ii libqt5widgets55.11.3+dfsg1-1+deb10u4 ii libqt5xml55.11.3+dfsg1-1+deb10u4 ii libstdc++68.3.0-6 ii libtag1v5 1.11.1+dfsg.1-2 ii libudev1 241-7~deb10u6 ii zlib1g1:1.2.11.dfsg-1 Versions of packages cantata recommends: ii liburi-perl 1.76-1 ii perl-base [libio-socket-ip-perl] 5.28.1-6+deb10u1 Versions of packages cantata suggests: ii media-player-info 24-2 ii mpd0.21.11-1
Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev
On Sat, 13 Jul 2019, Dmitry Bogatov wrote: control: tags -1 +moreinfo control: user kact...@debian.org control: usertags -1 +objections [2019-03-07 14:45] Dmitry Bogatov > [2019-03-05 23:41] Michael Biebl > > Control: reassign -1 insserv > > > I think insserv should depend on initscripts. It requires that to > > > actually do anything. > > > > > > Adding Conflicts will likely make switching inits much more difficult. > > > > Nod, reassigning back to insserv. > > Bug is in incorrect usage of insserv, not within insserv. You may want to > add check, that /etc/init.d/mountkernfs.sh exists. > > If it will help you, I can add 'Recommends' (not Depends) on > bin:initscripts into insserv. > > If if you disagree, please close + wontfix this bug. On second thought, maybe it is okay to add dependency of insserv on initscripts? After all, we already have initscripts installed, and systemd users are unlikely to complain about bloat... Opinions? It might be a bit late but I had encountered the same situation after dist-upgrading from an older Debian release. So maybe I can somehow shed some additional light on this issue. The actual culprit is rcconf which is marked as manually installed and depends on sysv-rc which in turn depends on insserv and startpar; and so all these packages remain installed after the migration to systemd. At the same time sysvinit-core (which depends on initscripts) is removed and so is initscripts because the package systemd-sysv has corresponding entries for 'Conflicts:' and 'Replaces:'. But if you manually remove rcconf, the other three packages can be automatically removed afterwards as none of them is needed by systemd. So I think both would make sense, add 'Recommends: initscripts' to insserv because initscripts is somehow needed for insserv as well as adding 'Conflicts: sysv-rc' to systemd-sysv to help migrating to systemd. Anyway, systemd-sysv already conflicts with file-rc and openrc, so additionally conflicting with sysv-rc shouldn't really make things worse. Best regards, Thomas Uhle
Bug#983715: libitext5-java: Please add itext-xtra too
Package: libitext5-java Version: 5.5.13-1 Severity: normal Dear maintainers, when building a binary package next time, please also add the jar file and Maven files for itext-xtra. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) libitext5-java depends on no packages. libitext5-java recommends no packages. Versions of packages libitext5-java suggests: ii libbcpkix-java1.60-1 ii libbcprov-java1.60-1 pn libitext5-java-doc pn libxml-security-java
Bug#983581: lirc: Please fix dependencies
Package: lirc Version: 0.10.1-6.2~deb10u1 Severity: normal Dear maintainers, the referenced package gir1.2-vte does not exist because its correct name is gir1.2-vte-2.91. Moreover, gir1.2-glib-2.0 and gir1.2-gtk-3.0 are also used in the lirc setup tool. So at the moment you need to manually install these packages. It would be good if you could update the corresponding 'Recommends' dependencies. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lirc depends on: ii libasound2 1.1.8-1 ii libc62.28-10 ii libftdi1-2 1.4-1+b2 ii libgcc1 1:8.3.0-6 ii liblirc-client0 0.10.1-6.2~deb10u1 ii liblirc0 0.10.1-6.2~deb10u1 ii libportaudio219.6.0-1 ii libstdc++6 8.3.0-6 ii libsystemd0 241-7~deb10u6 ii libusb-0.1-4 2:0.1.12-32 ii libusb-1.0-0 2:1.0.22-2 ii lsb-base 10.2019051400 ii python3 3.7.3-1 Versions of packages lirc recommends: pn gir1.2-vte ii python3-gi3.30.4-1 ii python3-yaml 3.13-2 ii systemd 241-7~deb10u6 Versions of packages lirc suggests: ii ir-keytable 1.16.6-2 pn lirc-compat-remotes pn lirc-doc pn lirc-drv-irman ii lirc-x 0.10.1-6.2~deb10u1 pn setserial
Bug#991570: policykit-1-gnome: still depends on transitional package libgdk-pixbuf2.0-0
Version: 0.105-7+b1 The binNMU has been built in connection with #981141. Thanks to Sebastian Ramacher! Best regards, Thomas Uhle
Bug#991780: mc: still depends on transitional package mime-support
Package: mc Version: 3:4.8.26-1.1 Severity: normal Dear maintainers, mc internally uses run-mailcap which used to be in mime-support but has been moved to package mailcap (new in bullseye). Package mime-support has become a transitional package. Could you please update dependencies by replacing mime-support with mailcap? Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mc depends on: ii libc6 2.31-13 ii libext2fs21.46.2-2 ii libglib2.0-0 2.66.8-1 ii libgpm2 1.20.7-8 ii libslang2 2.3.2-5 ii libssh2-1 1.9.0-2 ii mc-data 3:4.8.26-1.1 Versions of packages mc recommends: ii mime-support3.66 ii perl5.32.1-4 ii sensible-utils 0.0.14 ii unzip 6.0-26 Versions of packages mc suggests: pn arj ii bzip21.0.8-4 pn catdvi | texlive-binaries pn dbview pn djvulibre-bin ii epub-utils 0.2.2-4+b4 ii evince [pdf-viewer] 3.38.2-1 ii file 1:5.39-3 pn genisoimage pn gv ii imagemagick-7 [imagemagick] 8:7.1.0.4-dmo1 pn libaspell-dev pn odt2txt ii poppler-utils20.09.0-3.1 pn python-boto ii python-is-python2 [python] 2.7.18-9 ii python-tz2020.4-1 pn unar ii w3m 0.5.3+git20210102-6 pn wimtools ii zip 3.0-12
Bug#991777: solaar: depends on udev file 42-logitech-unify-permissions.rules that is yet 60-solaar.rules
Package: solaar Version: 1.0.4+dfsg-1 Severity: normal Dear maintainer, after upgrading from buster to bullseye I have the following error message in $HOME/.xsession-errors everytime when Solaar starts: Solaar depends on a udev file that is not present For more information see the Solaar installation directions at https://pwr-solaar.github.io/Solaar/installation Having a look at the code, it is quite obvious that Solaar requests a udev rules file with the name "42-logitech-unify-permissions.rules", but for some reason this file has been named "60-solaar.rules" in Debian. So there are two possible solutions: (a) Rename 60-solaar.rules to 42-logitech-unify-permissions.rules to be in line with upstream. (b) If it cannot be position 42 but has to stay at position 60 for some reason whatsoever, then you need to adapt line 141 in /usr/share/solaar/lib/solaar/gtk.py from udev_file = '42-logitech-unify-permissions.rules' to udev_file = '60-solaar.rules' Moreover, 60-solaar.rules is missing the following lines compared to upstream's 42-logitech-unify-permissions.rules at least: --- /lib/udev/rules.d/60-solaar.rules 2020-10-22 16:02:24 +0200 +++ /home/thomas/solaar/rules.d/42-logitech-unify-permissions.rules 2020-03-30 16:56:11 +0200 @@ -20,6 +48,9 @@ LABEL="solaar_apply" +# don't apply to the paired peripherals, just the receivers +DRIVERS=="logitech-djdevice|logitech-hidpp-device", GOTO="solaar_end" + # Allow any seated user to access the receiver. # uaccess: modern ACL-enabled udev # udev-acl: for Ubuntu 12.10 and older It really would be great if you could fix this for the version in bullseye given that there are already several bug reports on Github and Launchpad with respect to systems running Solaar on Ubuntu 20.04 LTS and I would expect that there will be new reports once bullseye is released. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages solaar depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.77 ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2 ii gir1.2-gtk-3.0 3.24.24-4 ii gir1.2-notify-0.70.7.9-3 ii passwd 1:4.8.1-1 ii python3 3.9.2-3 ii python3-gi 3.38.0-2 ii python3-pyudev 0.22.0-2 ii udev 247.3-6 Versions of packages solaar recommends: ii python3-dbus 1.2.16-5 ii upower0.99.11-2 solaar suggests no packages.
Bug#991410: blueman: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
Package: blueman Version: 2.1.4-1+b1 Severity: normal Dear maintainers, after upgrading from buster to bullseye, I see the following error message in syslog every time when blueman-mechanism.service is started (timestamp and host name stripped): blueman-mechani[812]: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed From what I understand, blueman-mechanism.service is started as a system unit before user login, i.e. also before the X11 server has started. So this error message seems to be comprehensible. I guess it comes from calling Gtk.IconTheme.get_default() which can be found several times in the blueman code. But as I am not familiar with the blueman code, I cannot tell why, where and what for blueman-mechanism is calling it. I assume that this error message is nothing to worry about, but it is annoying to have it in syslog. Do you know whether this is something that should be addressed upstream? Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-7-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages blueman depends on: ii adwaita-icon-theme 3.38.0-1 ii bluez5.55-3.1 ii bluez-obexd 5.55-3.1 ii dbus 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2 ii gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1 ii gir1.2-glib-2.0 1.66.1-1+b1 ii gir1.2-gtk-3.0 3.24.24-4 ii gir1.2-nm-1.01.30.0-2 ii gir1.2-pango-1.0 1.46.2-3 ii gnome-icon-theme 3.12.0-3 ii libbluetooth35.55-3.1 ii libc62.31-12 ii libglib2.0-0 2.66.8-1 ii libpulse-mainloop-glib0 14.2-2 ii librsvg2-common 2.50.3+dfsg-1 ii notify-osd [notification-daemon] 0.9.35+15.04.20150126-1+b1 ii policykit-1 0.105-31 ii python3 3.9.2-3 ii python3-cairo1.16.2-4+b2 ii python3-gi 3.38.0-2 ii python3-gi-cairo 3.38.0-2 Versions of packages blueman recommends: ii pulseaudio-module-bluetooth 14.2-2 blueman suggests no packages.
Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service
On Thu, 22 Jul 2021, Michael Biebl wrote: Are you booting with systemd.unified_cgroup_hierarchy=false under bullseye. If so, why? No, I'm not. I guess it's because of the legacy kernel which still has cgroups v1. But I really don't understand so much about this. Best regards, Thomas Uhle
Bug#991406: systemd: proc: unrecognized mount option "hidepid=invisible" or missing value
Package: systemd Version: 247.3-6 Severity: important Dear maintainers, after upgrading from buster to bullseye, I see the following error message in syslog multiple times (timestamp and host name stripped): kernel: proc: unrecognized mount option "hidepid=invisible" or missing value In some forum posts, it has been stated that it is due to /lib/systemd/systemd-remount-fs which seems to require a pretty recent Linux kernel like version 5.10 in bullseye. So everyone with a legacy kernel will get this error message in syslog several times because older kernels require a numerical value such as "hidepid=1" or "hidepid=2" instead of "hidepid=invisible". Do you know whether this has already been fixed in a newer systemd version or whether this has already been dealt with upstream? I could not find anything with respect to this issue but I guess it should not be hard for a systemd developer to change systemd-remount-fs' behaviour depending on the running kernel version. It really would be great if this could be fixed. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-10 ii libapparmor1 2.13.6-10 ii libaudit11:3.0-2 ii libblkid12.36.1-7 ii libc62.31-12 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libcryptsetup12 2:2.3.5-1 ii libgcrypt20 1.8.7-6 ii libgnutls30 3.7.1-5 ii libgpg-error01.38-2 ii libip4tc21.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount12.36.1-7 ii libpam0g 1.4.0-9 ii libseccomp2 2.5.1-1 ii libselinux1 3.1-3 ii libsystemd0 247.3-6 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.36.1-7 ii systemd-timesyncd [time-daemon] 247.3-6 ii util-linux 2.36.1-7 Versions of packages systemd recommends: ii dbus 1.12.20-2 Versions of packages systemd suggests: ii policykit-10.105-31 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 ii libnss-systemd 247.3-6 ii libpam-systemd 247.3-6 ii udev 247.3-6
Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service
On Thu, 22 Jul 2021, Michael Biebl wrote: Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT) Oh, right. This is not a Debian supported kernel. Please ask your vendor to update it to something more recent. Unfortunately, Hardkernel won't put any more effort into upgrading the Linux kernel for Odroid-C2 at the moment (according to https://forum.odroid.com/viewtopic.php?t=39474#p298277). That is why I asked for cherrypicking the patch from Github for the systemd version in bullseye because I hoped that this would also be a suitable solution for this issue. Best regards, Thomas Uhle
Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service
Package: systemd Version: 247.3-6 Severity: important Dear maintainers, after upgrading from buster to bullseye, I have the following new error message in syslog every time after login: systemd[1375]: -.slice: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service, ignoring: Permission denied Down below I have added a more comprehensive excerpt from syslog for you to see when this error message occurs (timestamps and host name stripped). From what I understand, this issue has already been brought up upstream by Michael Biebl (see https://github.com/systemd/systemd/issues/18047), but the patch at https://github.com/systemd/systemd/pull/18553 went into systemd version 248 which was obviously too late for bullseye. Since I still get the same error message, I guess that this patch yet has not been cherrypicked for the current binary release 247.3-6 in Debian and I would like to ask you if you could do so because I would like to stay with a stable Debian release after the release of bullseye. Thank you in advance! Thomas Uhle -- Package-specific info: <#part type="text/plain" disposition=attachment description="Bug script output"> systemd[1]: Created slice User Slice of UID 1000. systemd-logind[648]: New session c1 of user thomas. systemd[1]: Starting User Runtime Directory /run/user/1000... systemd[1]: Finished User Runtime Directory /run/user/1000. systemd[1]: Starting User Manager for UID 1000... systemd[1375]: pam_unix(systemd-user:session): session opened for user thomas(uid=1000) by (uid=0) systemd[1375]: Queued start job for default target Main User Target. systemd[1375]: -.slice: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service, ignoring: Permission denied systemd[1375]: Created slice User Application Slice. [...] systemd[1]: Started User Manager for UID 1000. systemd[1]: Started Session c1 of user thomas. <#/part> -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-10 ii libapparmor1 2.13.6-10 ii libaudit11:3.0-2 ii libblkid12.36.1-7 ii libc62.31-12 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libcryptsetup12 2:2.3.5-1 ii libgcrypt20 1.8.7-6 ii libgnutls30 3.7.1-5 ii libgpg-error01.38-2 ii libip4tc21.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount12.36.1-7 ii libpam0g 1.4.0-9 ii libseccomp2 2.5.1-1 ii libselinux1 3.1-3 ii libsystemd0 247.3-6 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.36.1-7 ii systemd-timesyncd [time-daemon] 247.3-6 ii util-linux 2.36.1-7 Versions of packages systemd recommends: ii dbus 1.12.20-2 Versions of packages systemd suggests: ii policykit-10.105-31 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 ii libnss-systemd 247.3-6 ii libpam-systemd 247.3-6 ii udev 247.3-6
Bug#991406: systemd: proc: unrecognized mount option "hidepid=invisible" or missing value
On Fri, 23 Jul 2021, Michael Biebl wrote: On Thu, 22 Jul 2021 21:09:33 +0200 Thomas Uhle wrote: > Do you know whether this has already been fixed in a newer systemd version > or whether this has already been dealt with upstream? I could not find > anything with respect to this issue There is https://github.com/systemd/systemd/issues/16896 It was closed wontfix. Thanks a lot for the hint! I had a look at the explanation and the corresponding commit, and I understand that it is not possible to have support on a per-mount basis for the ProtectProc setting if the running Linux kernel is older than version 5.8. But I have also learned that the old behaviour of systemd (before version 245) can be retained at least just by replacing "ProtectProc=invisible" with "ProtectProc=default" in the systemd service units in question (after copying these files to /etc/systemd/system/ of course). Then systemd does not try to mount /proc with option "hidepid=invisible" and, thus, there is also no error message in syslog any longer. Best regards, Thomas Uhle
Bug#991410: blueman: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
On Fri, 23 Jul 2021, Christopher Schramm wrote: Hi Thomas, I just created https://github.com/blueman-project/blueman/pull/1572 upstream. Cheers Thank you! Thomas
Bug#991570: policykit-1-gnome: still depends on transitional package libgdk-pixbuf2.0-0
Package: policykit-1-gnome Version: 0.105-7 Severity: normal Dear maintainers, the current version of policykit-1-gnome still depends on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages policykit-1-gnome depends on: ii libc6 2.31-13 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4 ii libpolkit-agent-1-00.105-31 ii libpolkit-gobject-1-0 0.105-31 ii policykit-10.105-31 policykit-1-gnome recommends no packages. policykit-1-gnome suggests no packages.
Bug#991574: midori: still depends on transitional package libgdk-pixbuf2.0-0
Package: midori Version: 7.0-2.1 Severity: normal Dear maintainers, the current version of midori still depends on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Moreover, midori still recommends gnome-icon-theme instead of adwaita-icon-theme which is the default icon theme since GTK3. Maybe you want to change that too after the release of Debian 11. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages midori depends on: ii libc6 2.31-13 ii libcairo2 1.16.0-5 ii libgcr-base-3-1 3.38.1-2 ii libgcr-ui-3-1 3.38.1-2 ii libgdk-pixbuf2.0-02.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4 ii libpeas-1.0-0 1.28.0-2+b1 ii libsoup2.4-1 2.72.0-2 ii libsqlite3-0 3.34.1-3 ii libwebkit2gtk-4.0-37 2.32.1-2 Versions of packages midori recommends: ii gnome-icon-theme 3.12.0-3 ii gnome-keyring 3.36.0-1 midori suggests no packages.
Bug#991575: mtr: still depends on transitional package libgdk-pixbuf2.0-0
Package: mtr Version: 0.94-1 Severity: normal Dear maintainers, the current version of mtr still depends on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mtr depends on: ii libc6 2.31-13 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-02.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libncurses6 6.2+20201114-2 ii libtinfo6 6.2+20201114-2 mtr recommends no packages. mtr suggests no packages.
Bug#991565: python2.7: still depends on transitional package mime-support
Package: python2.7 Version: 2.7.18-8 Severity: normal Dear maintainers, the current versions of python2.7 as well as of libpython2.7-stdlib still depend on the transitional package mime-support. Could you please change the dependency to "media-types | mime-support" like it has been done for python3.9 to possibly get rid of mime-support? Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python2.7 depends on: ii libpython2.7-stdlib 2.7.18-8 ii mime-support 3.66 ii python2.7-minimal2.7.18-8 python2.7 recommends no packages. Versions of packages python2.7 suggests: ii binutils 2.35.2-2 pn python2.7-doc
Bug#969329: systemd-cron: Special user nobody configured, this is not safe!
Dear maintainers, given that the current version in bullseye is still configured with "User=nobody" which causes this syslog message, I would like to ask if there is something going to happen yet before bullseye release. Thank you in advance! Thomas Uhle
Bug#991568: libdbusmenu-gtk3-4: still depends on transitional package libgdk-pixbuf2.0-0
Package: libdbusmenu-gtk3-4 Version: 18.10.20180917~bzr492+repack1-2 Severity: normal Dear maintainers, both packages libdbusmenu-gtk3-4 and libdbusmenu-gtk4 still depend on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libdbusmenu-gtk3-4 depends on: ii libatk1.0-0 2.36.0-2 ii libc6 2.31-13 ii libdbusmenu-glib4 18.10.20180917~bzr492+repack1-2 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-02.66.8-1 ii libpango-1.0-0 1.46.2-3 libdbusmenu-gtk3-4 recommends no packages. libdbusmenu-gtk3-4 suggests no packages.
Bug#991569: libwnck-3-0: still depends on transitional package libgdk-pixbuf2.0-0
Package: libwnck-3-0 Version: 3.36.0-1 Severity: normal Dear maintainers, the current version of libwnck-3-0 still depend on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libwnck-3-0 depends on: ii libatk1.0-0 2.36.0-2 ii libc6 2.31-13 ii libcairo2 1.16.0-5 ii libgdk-pixbuf2.0-02.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4 ii libpango-1.0-01.46.2-3 ii libstartup-notification0 0.12-6+b1 ii libwnck-3-common 3.36.0-1 ii libx11-6 2:1.7.1-1 ii libxrender1 1:0.9.10-1 ii libxres1 2:1.2.0-4 libwnck-3-0 recommends no packages. libwnck-3-0 suggests no packages.
Bug#991573: notify-osd: still depends on transitional package libgdk-pixbuf2.0-0
Package: notify-osd Version: 0.9.35+15.04.20150126-1+b1 Severity: normal Dear maintainers, the current version of notify-osd still depends on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a new binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages notify-osd depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii gsettings-desktop-schemas3.38.0-2 ii libatk1.0-0 2.36.0-2 ii libc62.31-13 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpixman-1-00.40.0-1 ii libwnck-3-0 3.36.0-1 ii libx11-6 2:1.7.1-1 notify-osd recommends no packages. notify-osd suggests no packages.
Bug#991567: libcanberra-gtk3-0: still depends on transitional package libgdk-pixbuf2.0-0
Package: libcanberra-gtk3-0 Version: 0.30-7 Severity: normal Dear maintainers, both packages libcanberra-gtk3-0 and libcanberra-gtk3-module still depend on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libcanberra-gtk3-0 depends on: ii libatk1.0-0 2.36.0-2 ii libc62.31-13 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libx11-6 2:1.7.1-1 Versions of packages libcanberra-gtk3-0 recommends: ii libcanberra-gtk3-module 0.30-7 libcanberra-gtk3-0 suggests no packages.
Bug#991571: pasystray: still depends on transitional package libgdk-pixbuf2.0-0
Package: pasystray Version: 0.7.1-1 Severity: normal Dear maintainers, the current version of pasystray still depends on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pasystray depends on: ii adwaita-icon-theme 3.38.0-1 ii libatk1.0-0 2.36.0-2 ii libavahi-client30.8-5 ii libavahi-common30.8-5 ii libavahi-glib1 0.8-5 ii libayatana-appindicator3-1 0.5.5-2 ii libc6 2.31-13 ii libcairo-gobject2 1.16.0-5 ii libcairo2 1.16.0-5 ii libdbusmenu-glib4 18.10.20180917~bzr492+repack1-2 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-02.66.8-1 ii libgtk-3-0 3.24.24-4 ii libnotify4 0.7.9-3 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpulse-mainloop-glib0 14.2-2 ii libpulse0 14.2-2 ii libx11-62:1.7.1-1 pasystray recommends no packages. Versions of packages pasystray suggests: ii paman 0.9.4-1+b3 pn paprefs ii pavucontrol 4.0-2 ii pavumeter 0.9.3-4+b3 ii pulseaudio-module-zeroconf 14.2-2
Bug#991572: pavumeter: still depends on transitional package libgdk-pixbuf2.0-0
Package: pavumeter Version: 0.9.3-4+b3 Severity: normal Dear maintainers, the current version of pavumeter still depends on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pavumeter depends on: ii gnome-icon-theme 3.12.0-3 ii libatk1.0-0 2.36.0-2 ii libatkmm-1.6-1v5 2.28.0-3 ii libc62.31-13 ii libcairo21.16.0-5 ii libcairomm-1.0-1v5 1.12.2-4 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc1 [libgcc-s1] 10.2.1-6 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libglibmm-2.4-1v52.64.2-2 ii libgtk2.0-0 2.24.33-2 ii libgtkmm-2.4-1v5 1:2.24.5-4 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpangoft2-1.0-01.46.2-3 ii libpangomm-1.4-1v5 2.42.1-1 ii libpulse-mainloop-glib0 14.2-2 ii libpulse014.2-2 ii libsigc++-2.0-0v52.10.4-2 ii libstdc++6 10.2.1-6 pavumeter recommends no packages. pavumeter suggests no packages.
Bug#991576: gtk2-engines: still depends on transitional package libgdk-pixbuf2.0-0
Package: gtk2-engines Version: 1:2.20.2-5 Severity: normal Dear maintainers, the current version of gtk2-engines still depends on the transitional package libgdk-pixbuf2.0-0 instead of libgdk-pixbuf-2.0-0. You might want to trigger a binNMU build to fix dependencies. Best regards, Thomas Uhle -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gtk2-engines depends on: ii libc6 2.31-13 ii libcairo2 1.16.0-5 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-02.66.8-1 gtk2-engines recommends no packages. gtk2-engines suggests no packages.
Bug#991568: libdbusmenu-gtk3-4: still depends on transitional package libgdk-pixbuf2.0-0
On Tue, 27 Jul 2021, Sebastian Ramacher wrote: Hi Thomas Please see #981141. There is no need to file bugs against each package that still depends on the transitional package. Cheers Oh sorry, I did not know about this ticket. One question though: Does your answer to #981141 mean that binNMU builds are planned once Debian 11 is released? Best regards, Thomas
Bug#700610: bsh (BeanShell) security vulnerability (CVE-2016-2510)
Dear maintainers, there was published a new release of BeanShell 14 months ago. You can find the sources of version 2.1.0 on GitHub at https://github.com/beanshell/beanshell/releases/tag/2.1.0 The new version has not been published on Maven though (where versions from 2.0b4 to 2.0b6 are still the newest releases), but this is explained on GitHub at https://github.com/beanshell/beanshell/issues/603 . Anyway, version 2.1.0 is an official release linked from https://www.beanshell.org/download.html and there is also stated that version 2.0b4 is now merely a legacy release. What do you think, wouldn't it be time for an update in Debian? Best regards, Thomas Uhle
Bug#700610: bsh (BeanShell) security vulnerability (CVE-2016-2510)
On Wed, 23 Feb 2022, Thorsten Glaser wrote: On Tue, 22 Feb 2022, Thomas Uhle wrote: > What do you think, wouldn't it be time for an update in Debian? The comment > at https://github.com/beanshell/beanshell/issues/603 . reads for me more like a “maybe remove it instead…”. Honestly though, if it’s not available in Central, upstreams will not use it and stick to old beta versions. If Debian has a newer one, which may be incompatible, we’re inviting problems. That might be true although the BeanShell developers claim in their announcment of version 2.1.0 to be backward compatible with version 2.0b6, and only suitable backports from the upcoming version 3.0 of BeanShell have made it into version 2.1.0. But even then Debian could move on to version 2.0b6 at least. It is the latest version of BeanShell on Maven Central. Perhaps we might have a better picture after a look at other Linux distributions. Arch, Fedora and Mageia for instance already have version 2.1.0 onboard whereas Gentoo, OpenMandriva, openSUSE and Red Hat stay with version 2.0b6 (... to name just a few). So it is quite mixed. But I haven't seen any Linux distribution so far (apart from those derived from Debian like Linux Mint, Ubuntu, etc.) that still have version 2.0b4. It seems that both decisions (either to update to version 2.1.0 or to version 2.0b6) are reasonable. Best regards, Thomas Uhle
Bug#1005394: dvb-apps: AleVT crashes immediately after start
Package: dvb-apps Version: 1.1.1+rev1500-1.4 Severity: normal X-Debbugs-Cc: Göran Weinholt Dear maintainers, the version of AleVT bundled in binary package dvb-apps is crashing immediately after start whereas the version from binary package alevt is not and is working as can be expected. Would it be an option to no longer package a broken alevt and its companions (alevt-cap and alevt-date) with dvb-apps but let dvb-apps recommend alevt instead? Best regards, Thomas Uhle -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-11-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages alevt depends on: ii libc62.31-13+deb11u2 ii libpng16-16 1.6.37-3 ii libx11-6 2:1.7.2-1 alevt recommends no packages. alevt suggests no packages.
Bug#1005407: xawtv: ttv, scantv, streamer and webcam miss dependency on v4l-conf
Package: src:xawtv Version: 3.107-1 Severity: normal Dear maintainers, like fbtv and xawtv, the binaries ttv, scantv, streamer and webcam also depend on v4l-conf, but its binary packages don't have the corresponding 'Depends: v4l-conf' statement. So it is necessary to manually install v4l-conf unless it's already been installed as dependency of xawtv or fbtv. Would you please update the dependencies of those four binary packages. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-11-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#1005409: xawtv: Please split mtt from xawtv
Package: src:xawtv Version: 3.107-1 Severity: wishlist Dear maintainers, can you please put mtt (together with /etc/X11/app-defaults/mtt, etc.) into a separate binary package so that mtt can be installed and used without having to install xawtv as well? This has already been done with other programs from the xawtv bundle like alevtd, scantv, fbtv, etc. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-11-arm64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#991565: fixed in python2.7 2.7.18-10
reopen -1 = thanks Hello Matthias, I guess it's a spelling mistake. But it seems to me that the name of the new binary package is "media-types" instead of "mime-types". Best regards, Thomas Uhle
Bug#1054291: wget2: Please enable tests during build
Source: wget2 Version: 2.1.0-2 Severity: normal Tags: patch Dear maintainer, currently the tests don't run when building the binary packages. That is because '$(MAKE) check' is missing in debian/rules and it also needs libmicrohttpd-dev as another build-dependency to avoid the following lines when running configure: checking for libmicrohttpd... no checking for library containing MHD_start_daemon... no configure: WARNING: *** LIBMICROHTTPD was not found. Several tests will not run. checking for MHD_free... no So could you please enable the tests? In addition, libidn-dev is no longer needed as a build-dependency because wget2 prefers libidn2-dev which appears to be already a build-dependency. For your convenience, I have prepared the attached patch that addresses all of these issues and adds dh_dwz for packaging the debug information as well. Thank you in advance for considering these changes! Best regards, Thomas Uhle wget2-enable-testsuite.diff.gz Description: GNU Zip compressed data
Bug#1014597: libitext5-java: new version 5.5.13.3 addresses CVE-2021-43113
On Sun, 10 Jul 2022, tony mancill wrote: Hello Thomas, On Fri, Jul 08, 2022 at 04:00:20PM +0200, Thomas Uhle wrote: > [...] > Could you please also pay attention to my other bug ticket #983715 and > consider to package itext-xtra along with the other jar files, at least for > bookworm. I will take a look at this after the version update. Thank you for the reminder. Best regards, tony Hello Tony, that would be great. Thank you! Best regards, Thomas
Bug#1014597: libitext5-java: new version 5.5.13.3 addresses CVE-2021-43113
Package: libitext5-java Version: 5.5.13.2-1 Severity: serious Tags: security upstream X-Debbugs-Cc: t...@security.debian.org Control: found -1 5.5.13-1 Dear maintainers, there is a new bugfix release upstream for iText 5. In particular, it addresses CVE-2021-43113. The new version 5.5.13.3 has been announced on Maven as well as on Github at https://github.com/itext/itextpdf/releases for instance. Please consider to also update the binary package for bullseye and perhaps for buster too. Could you please also pay attention to my other bug ticket #983715 and consider to package itext-xtra along with the other jar files, at least for bookworm. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) libitext5-java depends on no packages. libitext5-java recommends no packages. Versions of packages libitext5-java suggests: ii libbcpkix-java1.68-2 ii libbcprov-java1.68-2 pn libitext5-java-doc ii libxml-security-java 2.0.10-2+deb11u1
Bug#1014823: junit5: Please update to upstream version 5.8.2
Package: junit5 Version: 5.3.2-4 Severity: normal X-Debbugs-Cc: Tony Mancill Dear maintainers, there is a new release upstream for JUnit 5. The new version 5.8.2 has been published on Maven Central as well as on Github at https://github.com/junit-team/junit5/releases for instance, and it would be needed to package the recent version of libcommons-imaging-java. Could you please update the binary package junit5 in Debian. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages junit5 depends on: ii libapiguardian-java 1.1.0-2 ii libopentest4j-java 1.2.0-2 ii libunivocity-parsers-java2.8.3-2 junit5 recommends no packages. junit5 suggests no packages.
Bug#1014824: libhamcrest-java: Please update to upstream version 2.2
Package: libhamcrest-java Version: 1.3-9 Severity: normal X-Debbugs-Cc: Tony Mancill Dear maintainers, there is a new release upstream for Hamcrest. The new version 2.2 has been published on Maven Central as well as on Github at https://github.com/hamcrest/JavaHamcrest/releases for instance, and it would be needed to package the recent version of libcommons-imaging-java. Could you please update the binary package libhamcrest-java in Debian. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) libhamcrest-java depends on no packages. libhamcrest-java recommends no packages. libhamcrest-java suggests no packages.
Bug#1014825: libapiguardian-java: Please update to upstream version 1.1.2
Package: libapiguardian-java Version: 1.1.0-2 Severity: normal X-Debbugs-Cc: Tony Mancill Control: block 1014823 -1 Dear maintainers, there is a new release upstream for Hamcrest. The new version 1.1.2 has been published on Maven Central as well as on Github at https://github.com/apiguardian-team/apiguardian/releases for instance, and it would be needed to package the recent version of junit5 (cf. #1014823). Could you please update the binary package libapiguardian-java in Debian. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) libapiguardian-java depends on no packages. libapiguardian-java recommends no packages. libapiguardian-java suggests no packages.
Bug#983715: libitext5-java: Please add itext-xtra too
On Tue, 12 Jul 2022, tony mancill wrote: Hi Thomas, itext-xtra has Apache Commons Imaging [1] as a build dependency, which is not yet packaged for Debian. However, the build system and dependencies for Commons Imaging look okay, so this feasible for bookworm (assuming the copyright is clear). Cheers, tony [1] https://commons.apache.org/proper/commons-imaging/index.html Hi Tony, thank you for having a look into this! Honestly, I hasn't been aware of this dependency. Having a look at https://commons.apache.org/proper/commons-imaging/dependencies.html, I see that Commons Imaging in turn also depends on the newest versions of JUnit 5 (version 5.8.2) and Hamcrest (version 2.2) whereas in Debian, the package junit5 still uses upstream version 5.3.2 and the package libhamcrest-java uses upstream version 1.3. It would be necessary to go back to version 1.0-alpha1 of Commons Imaging from May 2019 to meet the version requirements of the dependencies if junit5 and libhamcrest-java cannot be updated. The license of Commons Imaging is the Apache License 2.0, that shouldn't be a problem. So what's next: Should I open a new ticket to request the packaging of libcommons-imaging-java or should I wait until the packages junit5 and libhamcrest-java are updated? Best regards, Thomas
Bug#1015192: libqrcodegen-java: Please update dependencies in debian/control
Package: libqrcodegen-java
Version: 1.8.0-1
Severity: normal
X-Debbugs-Cc: Boyuan Yang
Dear maintainers,
could you please remove ${maven:CompileDepends} from libqrcodegen-java's
runtime dependencies in debian/control because the package
libmaven-compiler-plugin-java is only needed for building the JAR file.
You may also want to fix a typo in the description, it's not spelled
"libarary" but just "library".
Thank you in advance!
Best regards,
Thomas Uhle
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libqrcodegen-java depends on:
ii libmaven-compiler-plugin-java 3.8.1-4
libqrcodegen-java recommends no packages.
libqrcodegen-java suggests no packages.
Bug#981886: intellij-community-idea build depends on openjdk-8-jdk-headless that will not be in bullseye
Dear maintainers, more recent versions than the one packaged in Debian no longer use JDK 1.8 according to README.md that comes bundled with the upstream tarballs. Moreover, now it seems to depend on JDK 11 or newer. Beginning with version 2020.3, the build system relies on JDK 11. The newest release of this series was published on Github at https://github.com/JetBrains/intellij-community/releases/tag/idea/203.8084.24 . With version 2022.1, the build system has changed and might need Kotlin. So it seems that any version with a release tag between 203.3645.34 (cf. https://github.com/JetBrains/intellij-community/releases/tag/idea/203.3645.34 ) and 213.7172.25 (most recent version published on March 15th, 2022, cf. https://github.com/JetBrains/intellij-community/releases/tag/idea/213.7172.25 ) might be suitable to get rid of the JDK 1.8 dependency. Unfortunately, all these versions require IDEA 2020.1 at least for the build process (according to README.md). So an intermediate step might be necessary, e.g. building the latest release from the 201.8743 branch (cf. https://github.com/JetBrains/intellij-community/releases/tag/idea/201.8743.12 ). Best regards, Thomas Uhle
Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1
Tags: patch Dear maintainers, I have prepared a patch for changing the order in which the libraries are built and to fix linking. Best regards, Thomas UhleDescription: Fix build order and linking of libraries Author: Thomas Uhle Bug-Debian: https://bugs.debian.org/889114 --- dbus-c++-0.9.0.orig/src/Makefile.am +++ dbus-c++-0.9.0/src/Makefile.am @@ -37,6 +37,7 @@ $(ecore_CFLAGS) SUBDIRS = \ + . \ integration HEADER_DIR = $(top_srcdir)/include/dbus-c++ --- dbus-c++-0.9.0.orig/src/integration/ecore/Makefile.am +++ dbus-c++-0.9.0/src/integration/ecore/Makefile.am @@ -11,6 +11,7 @@ -Wno-unused-parameter libdbus_c___ecore_1_la_LIBADD = \ + $(top_builddir)/src/libdbus-c++-1.la \ $(dbus_LIBS) \ $(ecore_LIBS) --- dbus-c++-0.9.0.orig/src/integration/glib/Makefile.am +++ dbus-c++-0.9.0/src/integration/glib/Makefile.am @@ -11,6 +11,7 @@ -Wno-unused-parameter libdbus_c___glib_1_la_LIBADD = \ + $(top_builddir)/src/libdbus-c++-1.la \ $(dbus_LIBS) \ $(glib_LIBS)
Bug#1019281: libnet-dns-perl: please adapt dependencies
Package: libnet-dns-perl Version: 1.29-1 Severity: normal Control: found -1 1.34-1 Dear maintainers, libnet-dns-perl has an unnecessary dependency on libnet-ip-perl because the module Net::IP is nowhere used nor is it referenced in META.json or META.yml (cf. https://metacpan.org/dist/Net-DNS) as far as I can see. And Test::More from libtest-simple-perl is just a build-time dependency. So this dependency could also be removed although it does not necessarily install another Debian package since it is also provided by package perl. Net::DNS has support for and prefers Net::LibIDN2 since version 1.13 which means for already some years. But libnet-dns-perl still only recommends libnet-libidn-perl. I know libnet-libidn2-perl has not yet been packaged (cf. RFP #1019279). Even though could you please replace libnet-libidn-perl by 'libnet-libidn2-perl | libnet-libidn-perl'. All this is also still true for the currently packaged version 1.34-1 in bookworm and sid. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-17-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libnet-dns-perl depends on: ii libdigest-hmac-perl1.03+dfsg-2.1 ii libdigest-sha-perl 6.02-1+b3 ii libnet-ip-perl 1.26-2 ii perl [libencode-perl] 5.32.1-4+deb11u2 ii perl [libtest-simple-perl] 5.32.1-4+deb11u2 ii perl-base [libio-socket-ip-perl] 5.32.1-4+deb11u2 ii perl-base [libscalar-list-utils-perl] 5.32.1-4+deb11u2 Versions of packages libnet-dns-perl recommends: ii libdigest-bubblebabble-perl 0.02-2.1 ii libnet-dns-sec-perl 1.18-1+b1 ii libnet-libidn-perl 0.12.ds-3+b3 pn libperl4-corelibs-perl libnet-dns-perl suggests no packages.
Bug#1019279: RFP: libnet-libidn2-perl -- Perl bindings for GNU libidn2
Package: wnpp Severity: wishlist X-Debbugs-CC: Debian Perl Group * Package name: libnet-libidn2-perl Version : 1.01 Upstream Author : Thomas Jacob * URL or Web page : https://metacpan.org/release/Net-LibIDN2 * License : Artistic or GPL-1+ Description : Perl bindings for GNU libidn2 Net::LibIDN2 provides Perl bindings for GNU libidn2, a C library for handling internationalized domain names according to IDNA 2008, Punycode and Unicode TR46. It closely follows the original C API of that library. Dear developers, there are Perl modules in Debian packages that already support Net::LibIDN2 (libnet-dns-perl for instance). As libidn2 implements the revised algorithm for internationalized domain names in contrast to its predecessor libidn, it would make sense to also have libnet-libidn2-perl as a Debian package next to libnet-libidn-perl. Thank you in advance! Best regards, Thomas Uhle
Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1
On Wed, 31 Aug 2022, Paul Wise wrote: Thanks for the patch, please consider sending it upstream too, even though upstream doesn't appear to be very active. You're welcome. And thank you for fixing the typo in the URL to upstream's bug ticket. Now I have attached the patch to upstream's bug ticket as requested after recovering my Sourceforge account. Anyway, I don't have hope that there is going to happen much. Yet it would be good if Debian's libdbus-c++-* packages could be updated at least. Best regards, Thomas Uhle
Bug#1018772: libdbus-c++-1-0v5: please put each library into its own package
Package: libdbus-c++-1-0v5 Version: 0.9.0-8.2 Severity: wishlist Dear maintainers, could you please split libdbus-c++-1-0v5 into three separate packages and put the GLib an Ecore related libraries into libdbus-c++-glib-1-0 and libdbus-c++-ecore-1-0 respectively. `apt-cache rdepends libdbus-c++-1-0v5` reveals that besides libdbus-c++-bin and libdbus-c++-dev, only ffado-dbus-server and jami-daemon currently depend on libdbus-c++-1-0v5. As far as I can see, these two packages just depend on libdbus-c++-1.so.0, so there is no need to recompile these packages. That means then only libdbus-c++-dev needs to depend on the new packages libdbus-c++-ecore-1-0 and libdbus-c++-glib-1-0 next to libdbus-c++-1-0v5. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-17-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libdbus-c++-1-0v5 depends on: ii libc62.31-13+deb11u4 ii libdbus-1-3 1.12.20-2 ii libecore11.25.1-1 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libglib2.0-0 2.66.8-1 ii libstdc++6 10.2.1-6 libdbus-c++-1-0v5 recommends no packages. libdbus-c++-1-0v5 suggests no packages.
Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1
Dear maintainers, as you can see from the build log, both libraries libdbus-c++-ecore-1.so.0 and libdbus-c++-glib-1.so.0 are built before libdbus-c++-1.so.0 instead of after. That is the main reason why they cannot be linked to it. I think it would be best if the build order could be adapted accordingly upstream, so that it would be possible to explicitly link to libdbus-c++-1.so.0. However, pkg-config does the right thing and appends '-ldbus-c++-1' after '-ldbus-c++-ecore-1' as well as after '-ldbus-c++-glib-1'. And due to dbus-c++'s documentation, using pkg-config is the recommended way to get compiler and linker flags. Best regards, Thomas Uhle
Bug#1018771: libdbus-c++-dev: missing dependency on libdbus-1-dev
Package: libdbus-c++-dev Version: 0.9.0-8.2 Severity: normal Dear maintainers, pkg-config reports the following for any of the three dbus-c++ libraries unless you also install the package libdbus-1-dev: Package dbus-1 was not found in the pkg-config search path. Perhaps you should add the directory containing `dbus-1.pc' to the PKG_CONFIG_PATH environment variable Package 'dbus-1', required by 'dbus-c++-1', not found Please update the dependencies of libdbus-c++-dev. Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-17-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libdbus-c++-dev depends on: ii libdbus-c++-1-0v5 0.9.0-8.2 ii libdbus-c++-bin0.9.0-8.2 libdbus-c++-dev recommends no packages. libdbus-c++-dev suggests no packages.
Bug#1020912: libbdplus0: still references libbluray1
Package: libbdplus0 Version: 0.1.2-3 Severity: normal Dear maintainers, libbluray1 was replaced by libbluray2 more than five years ago, but here in debian/control there is still 'Enhances: libbluray1' instead of 'Enhances: libbluray2'. Could you please adapt this line? Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-18-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libbdplus0 depends on: ii libc6 2.31-13+deb11u4 ii libgcrypt201.8.7-6 ii libgpg-error0 1.38-2 Versions of packages libbdplus0 recommends: ii libaacs0 0.11.0-2 libbdplus0 suggests no packages.
Bug#1020911: libaacs0: still references libbluray1
Package: libaacs0 Version: 0.9.0-2 Severity: normal Dear maintainers, libbluray1 was replaced by libbluray2 more than five years ago, but here in debian/control there is still 'Enhances: libbluray1' instead of 'Enhances: libbluray2'. Could you please adapt this line? Thank you in advance! Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-18-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libaacs0 depends on: ii libc6 2.31-13+deb11u4 ii libgcrypt201.8.7-6 ii libgpg-error0 1.38-2 Versions of packages libaacs0 recommends: ii libbdplus0 0.1.2-3 libaacs0 suggests no packages.
Bug#1020916: RFP: libcommons-imaging-java -- Apache Commons Imaging - Pure-Java Image Library
Package: wnpp Severity: wishlist Control: block 983715 by -1 X-Debbugs-CC: Debian Java Maintainers * Package name: libcommons-imaging-java Version : 1.0-alpha3 Upstream Author : The Apache Software Foundation * URL or Web page : https://commons.apache.org/imaging/ * License : Apache 2.0 Description : Apache Commons Imaging - Pure-Java Image Library Apache Commons Imaging is a library that reads and writes a variety of image formats, including fast parsing of image information (size, color space, ICC profile, etc.) and metadata. This library is pure Java. Compared to typical image I/O libraries in native code, it is more portable, and should be more reliable and more secure against corrupt/malicious images, yet still performs reasonably well. It is easier to use than ImageIO/JAI/java.awt.Toolkit (Sun/Java's image support), supports more formats (and supports them more correctly). It also provides easy access to metadata. Dear maintainers, this library is needed for a complete build of libitext5-java that also includes itext-extra (cf. https://bugs.debian.org/983715). Thank you in advance! Best regards, Thomas Uhle
Bug#1022729: RFP: luau -- A fast, small, safe, gradually typed embeddable scripting language derived from Lua
Package: wnpp Severity: wishlist X-Debbugs-CC: Debian Lua Team * Package name: luau Version : 0.550 Upstream Author : Roblox Corporation * URL or Web page : https://luau-lang.org/ * License : MIT Description : A fast, small, safe, gradually typed embeddable scripting language derived from Lua As a language, Luau is designed to be a full superset of Lua 5.1 that incorporates features from later Lua releases as well, but it also expands the feature set (most notably with type annotations). It is largely implemented from scratch, with the language runtime being a very heavily modified version of the Lua 5.1 runtime, with completely rewritten interpreter and other performance innovations. Whenever possible, it aims to be backwards-compatible with Lua 5.1 API, so existing bindings should be more or less compatible with a few caveats. Luau limits the set of standard libraries exposed to the users and implements extra sandboxing features to be able to run unprivileged code side by side with privileged code. This results in an execution environment that is different from what is common in Lua. To make it easier to write correct code, Luau also comes with a set of script analysis tools being a type checker and linter integrated into the command-line executable 'luau-analyze'. Given a set of input files, it produces errors and warnings according to the configuration that can be customized by using --! comments in the files or by .luaurc files.
Bug#1023148: desktop-base: missing links in joy-inksplat-theme
Package: desktop-base Version: 11.0.3 Severity: important Dear maintainers, via /etc/alternatives, /usr/share/images/desktop-base/login-background.svg links to /usr/share/desktop-base/active-theme/login/background.svg and /usr/share/images/desktop-base/desktop-grub.png links to /usr/share/desktop-base/active-theme/grub/grub-4x3.png by default. Now if I would switch desktop-theme to joy-inksplat-theme, both links are no longer valid because of these two missing links: /usr/share/desktop-base/joy-inksplat-theme/grub -> ../joy-theme/grub /usr/share/desktop-base/joy-inksplat-theme/login -> ../joy-theme/login Could you please add these links (similar to /usr/share/desktop-base/joy-inksplat-theme/lockscreen) so that joy-inksplat-theme could be used like all the other themes without separately setting /etc/alternatives/desktop-login-background and /etc/alternatives/desktop-grub as well. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-19-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages desktop-base depends on: ii fonts-quicksand 0.2016-2.1 ii librsvg2-common 2.50.3+dfsg-1 Versions of packages desktop-base recommends: pn plymouth-label Versions of packages desktop-base suggests: ii xfce4 4.16
Bug#1023151: xapps-common: Recommends unneeded gist instead of netcat
Package: xapps-common Version: 2.0.7-1 Severity: normal Dear maintainers, nothing in xapps-common needs gist to be installed. But the Python script /usr/share/xapps-common/bin/pastebin needs netcat to be installed instead. So could you please replace gist by netcat in debian/control. Moreover, if there is a reason for putting the executable binaries in /usr/share/xapps-common/bin/ instead of /usr/bin/ (which is what upstream does), then you should also adapt the path in upload-system-info (line 7) from '/usr/bin/pastebin' to '/usr/share/xapps-common/bin/pastebin'. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-19-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xapps-common depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii python3 3.9.2-3 ii python3-gi 3.38.0-2 ii xdg-utils1.1.3-4.1 Versions of packages xapps-common recommends: pn gist ii inxi 3.3.22-1-1~bpo11+1 xapps-common suggests no packages.
Bug#1023154: RFP: hypnotix -- IPTV player
Package: wnpp Severity: wishlist X-Debbugs-CC: Debian Cinnamon Team * Package name: hypnotix Version : 2.9 Upstream Author : Linux Mint * URL or Web page : https://github.com/linuxmint/hypnotix * License : GPL-3+ Description : IPTV player Hypnotix is an application to watch TV by streaming from M3U sources. It is primarily developed for the Cinnamon desktop in Linux Mint but could be used in any other desktop environment as well.
Bug#842850: vpnc: please support main mode
On Wed, 23 Nov 2016, Florian Schlichting wrote: Hi Benoit, > While debugging an issue connecting with vpnc to a mikrotik firewall, I more > or less pinpointed the problem in vpnc only trying aggressive mode > and not 'main' mode. > > Could a config option be added to also allow main mode? I'm not sure what 'aggressive mode' is and I cannot find anything about that in the source. But if you're able to develop a patch (and if possible, post that patch to the upstream development list in addition to this bug report), I can certainly add that patch to the Debian package. Florian Well, maybe it's too late for some explanations. Anyway, these three documents on the internet (among others) may explain the difference between main mode and aggressive mode: * https://www.ipsec-howto.org/x202.html#AEN283 * https://www.internet-computer-security.com/VPN-Guide/Aggressive-Mode.html * https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/217432-understand-ipsec-ikev1-protocol.html I've searched the internet because I am not quite sure about it; but if I remember correctly then Cisco has preferred or used by default aggressive mode. Please remember that vpnc was developed as a replacement to Cisco's proprietary client to have a free alternative for connecting to Cisco IPSec/VPN servers from any platform having similar simplicity in terms of configuration and usage. Yet you may decide for a different VPN software that provides much more features for tweaking the IPSec connection exactly the way you need or want it, libreswan or strongswan for instance. Both support main mode and aggressive mode and are packaged for Debian. Best regards, Thomas Uhle
Bug#890490: "auth" and "cipher" configuration directives not available on Debian
On Thu, 15 Feb 2018, vitaminx wrote: On Thu, Feb 15, 2018 at 10:39:56AM +0100, vitaminx wrote: > Today our employer changed security settings on the gateways and told us to add following options: > > auth SHA1 > cipher AES-128-CBC > > This seems to work on Mac OS X, but the options are not available in the Linux version of vpnc: On Thu, Feb 15, 2018 at 11:05:16AM +0100, Florian Schlichting wrote: > you mean vpnc on Mac OS X? Which version of vpnc is that? I found e.g. > https://github.com/breiter/vpnc which doesn't seem to support those > configuration options, and I'm unaware of patches adding those options. It might be a little late for an answer. Anyway, vpnc supports both the SHA1 hash algorithm for integrity protection (RFC 4109) and also the AES cipher with 128 bit, 192 bit or 256 bit keys for encryption (RFC 3602). vpnc has no such options to select a specific hash algorithm or cipher because it is decided on the cryptographic parameters for the IPSec connection during an initial handshake between vpnc and its peer. So vpnc should work out of the box. Please remember that vpnc was developed as a replacement to Cisco's proprietary client and as such should be as simple and easy to configure and use as the Cisco client itself. However, you might want to start vpnc in a terminal with the option '--debug 1' and recognise among other messages a line similar to this: IKE SA selected psk+xauth+aes128-sha1 And so everything is fine ... There seems to be a native client on Mac OS X which supports these options. https://faq.oit.gatech.edu/content/how-do-i-configure-os-x-integrated-ipsec-vpn-client > Are you sure this is still an ipsec based VPN, rather than an SSL based > VPN like "AnyConnect", for which you'll need to switch from vpnc to > openconnect? We are using Global Protect which supports both SSL and Ipsec based connections: https://www.paloaltonetworks.com/products/globalprotect/subscription They are actually recommending vpnc or strongSwan for Linux. strongswan and also libreswan provide much more configuration options for tweaking the IPSec connection exactly the way you need or want it. There are packages in Debian's repositories for both libreswan and strongswan. Best regards, Thomas Uhle
Bug#763199: RFP: libpdl-fftw3-perl -- PDL interface to the Fastest Fourier Transform in the West v3
Control: retitle -1 RFP: libpdl-fftw3-perl -- PDL interface to the Fastest Fourier Transform in the West v3 * Package name: libpdl-fftw3-perl Version : 0.18 Upstream Author : Ed J , Dima Kogan , Craig DeForest , Chris Marshall * URL or Web page : https://metacpan.org/dist/PDL-FFTW3/ * License : GPL-3 Description : PDL interface to the Fastest Fourier Transform in the West v3 This is a PDL interface to version 3 of the FFTW library. It is similar to the standard FFT routine but usually much faster and it supports complex <-> complex and real <-> complex FFTs. PDL::FFTW used to be part of the standard PDL distribution but the days of FFTW v2.x are long gone, also in Debian's repositories. As PDL::FFTW3 interfaces the successor which is verion 3 of the FFTW library, it would be possible and really great to have FFTW back for use with PDL.
Bug#1019942: pacpl: has unnecessary dependency; please update package's dependencies
Package: pacpl Version: 6.1.2-2 Severity: normal Dear maintainer, by installing pacpl, also libcddb-perl was to be installed but has never been used. pacpl uses libcddb-get-perl instead that was also installed. So could you please update debian/control and drop libcddb-perl from dependencies. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-17-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pacpl depends on: ii libaudio-flac-header-perl 2.4-3+b3 ii libaudio-scan-perl1.01-1+b3 ii libcddb-perl 1.222-1.1 ii libcddb-get-perl 2.28-3 ii libmp3-tag-perl 1.13-1.2 ii libparallel-forkmanager-perl 2.02-1 ii libstring-shellquote-perl 1.04-1 ii perl 5.32.1-4+deb11u2 ii vorbis-tools 1.4.0-11+b1 Version of packages pacpl recommends: ii cdparanoia3.10.2+debian-13.1 ii faad 2.10.0-1 ii ffmpeg10:4.4.2-dmo0~bpo11+3 ii flac 1.3.3-2+deb11u1 ii lame 1:3.100-dmo2 un mplayer un musepack-tools ii normalize-audio 0.7.7-16 ii opus-tools0.1.10-1 ii sndfile-programs 1.0.31-2 un sox un speex un wavpack Version of packages pacpl suggests: un faac un flake un twolame
Bug#495911: override rather than replace default route
Control: reassign -1 vpnc-scripts Dear maintainers, I don't know whether or not this is still an issue after so many years, but I know that routing is handled by vpnc-script which was moved to its own Debian package vpnc-scripts in 2012. Thus, I thought to better reassign it, so it might not become forgotten. Best regards, Thomas Uhle
Bug#1000281: net-tools: New upstream version
Control: retitle -1 net-tools: New upstream version On Sat, 20 Nov 2021, Alexis PM wrote: Package: net-tools Version: 1.60+git20181103.0eebece-1 Severity: normal Hello New upstream version: net-tools-2.10 2021-01-07 https://sourceforge.net/projects/net-tools/files/ Packaging can help to close several open Debian bugs. Thank you very much. Dear maintainers, in addition there are yet another seven commits in the git repository on top of version 2.10, also addressing bugfixes. What do you think, isn't it time for an update (as the currently packaged version in Debian seems to be almost two years old)? Thank you in advance for your effort! Best regards, Thomas Uhle
Bug#951354: wget2: Please package new 2.0.0 version
On Wed, 1 Jun 2022, Boyuan Yang wrote: X-Debbugs-CC: n...@debian.org Hi Noel, I believe the a upstream version 2.0.1 was just released. It has been more than 4 years since last maintainer upload; are you still going to maintain wget2 in Debian? If not, please feel free to let us know so that others can work on it and package new versions. Thanks, Boyuan Yang On Sat, 08 Jan 2022 18:59:56 -0500 Boyuan Yang wrote: > X-Debbugs-CC: n...@debian.org > > Dear maintainer, > > It has been a while; is there any update on packaging new wget2? If you are in > lack of time doing packaging, please let us know so that those interested can > have a chance to step in. > > Thanks, > Boyuan Yang > Dear maintainers, are there any recent news on this? I am asking because I would also pretty much welcome an update of wget2 in Debian. So thank you in advance for your effort! Best regards, Thomas Uhle
Bug#1019279: RFP: libnet-libidn2-perl -- Perl bindings for GNU libidn2
On Wed, 7 Sep 2022, Yadd wrote: Hi, ready (https://salsa.debian.org/perl-team/modules/packages/libnet-libidn2-perl). Hi Yadd, thank you for the immediate response and for packaging libnet-libidn2-perl. Maybe a review before push ? I wonder whom you were asking, me or your fellow maintainers? If it's me then I could tell you that I have flawlessly build the binary package for bullseye from your repository and it is well working. Anyway, I guess that you have a lot more packaging skills than I do. For example, I don't know whether or not it should be necessary to explicitly have libextutils-parsexs-perl as a build dependency in debian/control. Is it not needed because there are already perl-xs-dev and perl as dependencies which in turn depend on perl-modules which provides libextutils-parsexs-perl? However, I hope it's not on me to decide if libnet-libidn2-perl is ready for release but I definitely welcome it. Therefore, thanks again! Regards, Thomas
Bug#1021554: RFP: vocal -- modern and simple podcast client
Package: wnpp Severity: wishlist * Package name: vocal Version : 2.4.2 Upstream Author : Vocal Podcast Project * URL or Web page : https://vocalproject.net/ * License : GPL-3+ Description : modern and simple podcast client Vocal is a powerful, beautiful, and simple podcast client for the modern free desktop. It features smart library management, position saving, light and dark themes, iTunes Store integration, and much more ...
Bug#1021572: RFP: la-capitaine-icon-theme -- icon theme inspired by macOS and Google's material design
Package: wnpp Severity: wishlist X-Debbugs-CC: Debian Developers * Package name: la-capitaine-icon-theme Version : 0.6.2 Upstream Author : Keefer Rourke * URL or Web page : https://krourke.org/projects/art/la-capitaine-icon-theme/ * License : GPL-3+, MIT Description : icon theme inspired by macOS and Google's material design La Capitaine is basically an icon theme for the modern Linux desktop, designed to integrate with most desktop environments. It is inspired by macOS and Google's material design through the use of visually pleasing gradients, shadowing, and simple icon geometry.
Bug#963101: RFP: cozy -- modern and slick GUI audiobook player
Control: retitle -1 RFP: cozy -- modern and slick GUI audiobook player * Package name: cozy Version : 1.2.1 Upstream Author : Julian Geywitz * URL or Web page : https://cozy.sh/ * License : GPL-3+ Description : modern and slick GUI audiobook player Rename the package to align the name with the one used upstream and also on Launchpad. Best regards, Thomas Uhle
Bug#1021568: RFP: gnome-shell-extension-unite -- makes GNOME Shell look like Ubuntu's Unity Shell
Package: wnpp Severity: wishlist X-Debbugs-CC: Debian GNOME Maintainers * Package name: gnome-shell-extension-unite Version : 68 Upstream Author : Hardpixel * URL or Web page : https://github.com/hardpixel/unite-shell * License : GPL-3+ Description : makes GNOME Shell look like Ubuntu's Unity Shell Unite is a GNOME Shell extension that makes a few layout tweaks to the top panel and removes window decorations to make it look like Ubuntu's Unity Shell.
Bug#1021570: RFP: antu-icon-theme -- smooth theme designed for Plasma and KDE
Package: wnpp Severity: wishlist X-Debbugs-CC: Debian Qt/KDE Maintainers * Package name: antu-icon-theme Version : 0.9.4 Upstream Author : Fabián Alexis * URL or Web page : https://gitlab.com/froodo_alexis/Antu-icons * License : CC BY-NC-SA 3.0 Description : smooth theme designed for Plasma and KDE Antü is a beautiful icon theme for Plasma and KDE that redesigns the drab, default Breeze look into a colorful and stylish one with inspirations from macOS and Google's material design.
Bug#970797: ITP: libjiconfont-google-material-design-icons-java -- jIconFont - Google Material Design Icons
Control: retitle -1 ITP: libjiconfont-google-material-design-icons-java -- jIconFont - Google Material Design Icons Rename the package because the icon font files are already packaged for Debian as part of the binary package fonts-material-design-icons-iconfont and this new binary package would contain the JAR file that is a wrapper for Java projects. Best regards, Thomas Uhle
Bug#934811: webrtc-audio-processing 1.0 available
On Tue, 1 Feb 2022, Jonas Smedegaard wrote: I have continued the work of Laurent Bigonville and believe to have a worthy candidate targeted experimental. One potential issue remaining is a lintian warning: > W: libwebrtc-audio-processing1: package-name-doesnt-match-sonames libwebrtc-audio-coding-1-0 libwebrtc-audio-processing-1-0 I guess it is harmless, but I have been wrong before about SONAME handling. Well, I guess what lintian is trying to tell you is that the library name has changed with version 1.0. Before the current version, it has been 'libwebrtc_audio_processing.so.1', and now it is 'libwebrtc-audio-processing-1.so.0'. That is why lintian proposes to rename the binary package 'libwebrtc-audio-processing1' (which has been correct for the former library name) to 'libwebrtc-audio-processing-1-0'. Keeping the package name 'libwebrtc-audio-processing1' would risk to break any other binary packages like pulseaudio or libspa-0.2-modules because those binaries for the AEC module still link to libwebrtc_audio_processing.so.1 which is but removed during a version update. By renaming the binary package, you could have both versions of the library installed side by side. Please tell if someone from the Pulseaudio team is gonna take it from here. There has been quite silent on this bugreport for some time, so if I don't hear a response I am likely to release what I have as an NMU targeted experimental, with a follow-up targeted unstable (if all goes well, obviously), but I would prefer to not take over maintenance of this package. Pushing the current version in experimental to unstable as-is would break pulseaudio, libspa-0.2-modules and gstreamer1.0-plugins-bad at least and scheduling a binNMU for these packages would not help as they are not yet ready for version 1.0 of webrtc-audio-processing. It seems that the effort for PipeWire would be less than for PulseAudio, but at this very moment none of these would compile out of the box. It might even make sense to consider to also rename 'libwebrtc-audio-processing-dev' to 'libwebrtc-audio-processing-1-dev' if you want to push the new version to unstable because the path to the header files has changed as well as the name of the data file for pkg-config. This way you could also install the development files from both versions side by side which might help the other projects to migrate to the new webrtc-audio-processing version at their own pace. Last but not least, the binary package libwebrtc-audio-processing-dev needs to depend on libabsl-dev because some of the header files include header files from Abseil. Best regards, Thomas Uhle
Bug#1021834: libwebrtc-audio-processing1: please split into libwebrtc-audio-coding-1-0 and libwebrtc-audio-processing-1-0
Package: libwebrtc-audio-processing1 Version: 1.0-0.2 Severity: normal Tags: patch, fixed-upstream Followup-For: Bug #934811 X-Debbugs-Cc: Jonas Smedegaard Dear maintainers, could you please introduce two new binary packages for the libraries libwebrtc-audio-coding-1.so.0 and libwebrtc-audio-processing-1.so.0 built from version 1.0 of the source package webrtc-audio-processing that would replace the current binary package so that the new packages could be installed next to the current libwebrtc-audio-processing1. That would be necessary because the library names have changed as well as the API and the current versions of PulseAudio, PipeWire and GStreamer's Bad Plugins still need the older version 0.3.x of webrtc-audio-processing to compile. Cherry-picking the following commit from upstream will help you in doing so: * build: Split out iSAC VAD sources into a separate dependency https://gitlab.freedesktop.org/pulseaudio/webrtc-audio-processing/-/commit/6e37f37c4ea8790760b4c55d9ce9024a7e7bf260 Thank you in advance! Best regads, Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-18-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libwebrtc-audio-processing1 depends on: ii libabsl20200923 0~20200923.3-2 ii libc62.31-13+deb11u4 ii libgcc-s110.2.1-6 ii libstdc++6 10.2.1-6 libwebrtc-audio-processing1 recommends no packages. libwebrtc-audio-processing1 suggests no packages.
Bug#1021835: libwebrtc-audio-processing-dev: missing dependencies
Package: libwebrtc-audio-processing-dev Version: 1.0-0.2 Severity: normal Tags: patch, fixed-upstream Followup-For: Bug #934811 X-Debbugs-Cc: Jonas Smedegaard Dear maintainers, some of the header files from version 1.0 of webrtc-audio-processing directly include header files from Abseil. Thus, the binary package libwebrtc-audio-processing-dev should also depend on libabsl-dev. Another issue is that the generated pkg-config data files webrtc-audio-coding-1.pc and webrtc-audio-processing-1.pc yet do not include the dependencies on the needed Abseil libraries because the current Meson build script still figures out these dependencies via CMake instead of using pkg-config. This has already been fixed upstream as well as the missing dependency for using absl::optional<>. You could pick up the following commits: * Use pkg-config for abseil-cpp detection if available https://gitlab.freedesktop.org/pulseaudio/webrtc-audio-processing/-/commit/8bf9efad15bdb8438eb858d3f8ed4a8ea2b21ff0 * Add missing absl library for bad_optional_access https://gitlab.freedesktop.org/pulseaudio/webrtc-audio-processing/-/commit/0cc2ebeda2faf60f3367bd5e88e1247455dfcfee If you don't like to pick up partial commits, you'll probably also need to pick up this commit from upstream: * build: Add library-based absl detection as a fallback https://gitlab.freedesktop.org/pulseaudio/webrtc-audio-processing/-/commit/e74894baebe0bba7a7fe37ae0a46a2e9b1b2e021 Thank you in advance! Best regads, Thomas Uhle -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 5.10.0-18-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libwebrtc-audio-processing-dev depends on: ii libwebrtc-audio-processing1 1.0-0.2 libwebrtc-audio-processing-dev recommends no packages. libwebrtc-audio-processing-dev suggests no packages.
Bug#1025975: RFP: deepin-log-viewer -- Useful tool for viewing system logs
On Thu, 29 Dec 2022, Arun Kumar Pariyar wrote: The package deepin-log-viewer was already uploaded and available in Debian [1]. That is why I am closing this bug. 1. https://tracker.debian.org/pkg/deepin-log-viewer Regards, ~ Arun Kumar Pariyar I haven't noticed that. So sorry for this ticket and thank you for the hint. Best regards, Thomas Uhle
Bug#1026775: ITP: libdevice-i2c-perl -- Control and read hardware devices with I2C (SMBus)
Hello Gregor, sorry for still having another question. I just wanted to try the "official" binary build, but these just happen to exist for the x86/x86_64 architectures at this moment (next to unofficial builds). Especially the builds for the ARM architectures are missing. Do you know why? Do I just have to wait for them a little longer and be patient? So I have downloaded the sources from Debian today and have built libdevice-i2c-perl locally on my Odroid SBC which is working. I guess this binary package would be equal to an "official" build. Cheers, Thomas
Bug#1026776: ITP: libio-termios-perl -- Supply termios(3) methods to IO:Handle objects
On Wed, 4 Jan 2023, gregor herrmann wrote: On Wed, 04 Jan 2023 18:08:42 +0100, Thomas Uhle wrote: > thank you for packaging IO::Termios for Debian! You're welcome. It helped me to test a change I had made in dh-make-perl and for which I wanted to test it on a new package :) > Could you please also add liblinux-termios2-perl to Recommends in > debian/control (or maybe to Suggests). I don't know whether there is a > general rule for how to correctly handle this. Added to Recommends, thanks for the suggestion. Hello Gregor, autopkgtest complains about not being able to install liblinux-termios2-perl on ppc64el because this package is not available for the PowerPC architectures, and so it will likely prevent libio-termios-perl's migration to bookworm. However, all the other tests are just fine. So is it possible to ignore this test result from ppc64el? Cheers, Thomas
Bug#1026775: RFP: libdevice-i2c-perl -- Control and read hardware devices with I2C (SMBus)
Thanks a lot! On Tue, 3 Jan 2023, Debian FTP Masters wrote: Source: libdevice-i2c-perl Source-Version: 0.06-1 Done: gregor herrmann We believe that the bug you reported is fixed in the latest version of libdevice-i2c-perl, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1026...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. gregor herrmann (supplier of updated libdevice-i2c-perl package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 02 Jan 2023 23:58:52 +0100 Source: libdevice-i2c-perl Binary: libdevice-i2c-perl libdevice-i2c-perl-dbgsym Architecture: source amd64 Version: 0.06-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Description: libdevice-i2c-perl - module to control and read hardware devices with i2c(SMBus) Closes: 1026775 Changes: libdevice-i2c-perl (0.06-1) unstable; urgency=medium . * Initial release. (Closes: #1026775) Checksums-Sha1: ff7ee47de1363df7605a89c15fa356dbc7347a67 2264 libdevice-i2c-perl_0.06-1.dsc 09941a18a18fc718d671f8e50e1f40ab4adff4bd 72328 libdevice-i2c-perl_0.06.orig.tar.gz 5a431e3eed173b2c0f6823d03a96a031a518786c 1924 libdevice-i2c-perl_0.06-1.debian.tar.xz 92cecf68e09080924d610c03f19f179aa198f5e4 37040 libdevice-i2c-perl-dbgsym_0.06-1_amd64.deb 88ce8c035fa1ed7a469f783d2fac6603eb8c754b 6593 libdevice-i2c-perl_0.06-1_amd64.buildinfo 28cff68fed56852418a47a7784d310f81261d2e4 15092 libdevice-i2c-perl_0.06-1_amd64.deb Checksums-Sha256: 116a3a32852c9eba7b9059746b2e80dd5f6691860cdaa57ef56c8c440b3e4a53 2264 libdevice-i2c-perl_0.06-1.dsc 9a228bbf070966caece738579634be85f8c288ce14569053533001737da2a469 72328 libdevice-i2c-perl_0.06.orig.tar.gz dfc8bb01102b49a8e39fddb40882242fa99d9c56f3f7109f2e3c6084bd682c7c 1924 libdevice-i2c-perl_0.06-1.debian.tar.xz 380b1acfbe9ac00fc46ffd88440a66658d04cc8bf3f31a557f3ddcfc077af511 37040 libdevice-i2c-perl-dbgsym_0.06-1_amd64.deb 11aec816b16d8e66bc0ecee15820e58467010d26b8e40810844d7130da6c92ea 6593 libdevice-i2c-perl_0.06-1_amd64.buildinfo 786cd44afef324bf389c21158b165088165495e99d8205ae87ef736cf491ee87 15092 libdevice-i2c-perl_0.06-1_amd64.deb Files: c1da55886d0eb8ffafc1a3d5fd29bbf1 2264 perl optional libdevice-i2c-perl_0.06-1.dsc 05bf015fb76445350ee413260f1021f8 72328 perl optional libdevice-i2c-perl_0.06.orig.tar.gz a6779b213ab6014c2c7694a78d65df5f 1924 perl optional libdevice-i2c-perl_0.06-1.debian.tar.xz 4dceb039bf93d2ea3fcb9859a8f29f2e 37040 debug optional libdevice-i2c-perl-dbgsym_0.06-1_amd64.deb 972edaa27ebf5b5e8916ec615e672c33 6593 perl optional libdevice-i2c-perl_0.06-1_amd64.buildinfo 0df565e0307390cb8091efcdfbe29ad6 15092 perl optional libdevice-i2c-perl_0.06-1_amd64.deb -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmOzYf5fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgaGsw//WwBUV90ItPrQRuYts8HrpVBUSENJIznM/aDPdcqujRUahCaSl4Uzbey9 6JH1OneYEM1mrZCjcQJi3DEBrgBtq8AdrQfKI31xNAHZ+U8jPnrMphgBeD37Ae45 cU6ag1AvLEiIUUAgn6fO29WF63x2u37CfxIHomBrJFmZZrqPCRsGzYh4X7gPGzAZ q2cysXILaN2JVfae2LPxktpdXMYhVn1lh2fnJ4v8SV6dFr0aNXckaGZAGhGlPHIo MelPFfsgThZ0kK/Sb3m9FcKfs/dUNOxRwZu0o1sMf2jKpRk8fQN/Dxp82MHiJRf2 cb6LeKzxDhgv97C7bFFMon8PxvcEWn7Bo9NzmLTxkmXvaWNHC1sTCj91PmNjMWuF jy7rVDrU1krT4MP3X34nMSpRhxKI64SVdFpGbe6Oq/uvr5vp7Ji44s2/M/IKweXe vNylq8eac2f0LHXyWYnbspi7WqCt5eLD0N8AoTWMu/xy6avUAJVc/cwaz+8+rn3r b4dcyeBaYx/AO+5rpC7WcQv12y3/0jW+OOeHoZp5laxywrSAmlA2ZNd2XzflepNI kM9m5LxuvgH8gRcgcEXqtfObjj4cAi/slh4rqpm5YRtSeZ5S6xs/V1Pv8OGUKlC1 Xpj6nyGBcxy9Q4gWwH3tBkKYK6vC5zL8RSfRdzakoC3730baJXU= =JfLs -END PGP SIGNATURE-
