Bug#985891: [bastula/dicompyler] Please do not use private module matplotlib._cntr (#137)
Hi Aditya, On Fri, Apr 09, 2021 at 08:18:15PM -0700, Aditya Panchal wrote: > Hope you are doing well. It is possible to use the `legacycontour` package > available here: https://github.com/matplotlib/legacycontour and follow the > instructions by Alan listed here: > https://github.com/bastula/dicompyler/issues/122. That should at least allow > the program to function correctly with `matplotlib >= 2.2`. This will not the problem for the Debian package. The module `legacycontour` is not (yet) packaged for Debian and since we are in freeze currently no new packages are permitted. > Another option that is possible is to swap to `measure_contours` from > `scikit-image` as outlined here: > https://github.com/bastula/dicompyler/issues/122#issuecomment-570842862 but > introduces a much heavier dependency. One of the goals of dicompyler is to be > lightweight. I admit I have no idea about the goals and features of dicompyler. I'm not using it and simply took over the maintenance in Debian from some developer who left the team to salvage it for the users of the Debian package. So if you can provide a working patch I will include it in the Debian package which will safe it for the next stable release - otherwise it will be removed from there which would be a shame. Kind regards, Andreas.
Bug#986619: linux-image-5.10.0-5-amd64: bonding broken on 5.10.0-5 (5.10.26)
Hi! Just hit this, great time, I'd just like to narrow down this regression, the previous 5.10.0-5 (5.10.24) works fine, but 5.10.26 is broken. Best, наб signature.asc Description: PGP signature
Bug#986717: google-compute-engine: Should fail gracefully when installed in non-GCE environment
Package: google-compute-engine Severity: wishlist X-Debbugs-Cc: je...@sney.ca Dear Maintainer, If the google-compute-engine package is installed on a system not part of the google cloud, the included services are started by the postinst script, and apt hangs indefinitely (presumably because the services can't contact the google infrastructure). The only way to recover at that point is to kill the associated python3 processes from a different tty. Removing the package has an almost identical result, with systemctl hanging instead. Sometimes people make mistakes. It's entirely reasonable to imagine someone moving a service from google to a different cloud provider, and trying to mimic their environment as closely as possible with a 'dpkg --get-selections' or so, and accidentally ending up in this state. It should be possible to install this package in error and not have to kill postinst subprocesses manually in order to recover. Behavior is present in the buster (20190124-3) and sid/testing (20190916-1) versions of google-compute-engine. sney -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages google-compute-engine depends on: pn google-compute-engine-oslogin pn python3-google-compute-engine google-compute-engine recommends no packages. google-compute-engine suggests no packages.
Bug#986656: ITP: runit-services -- a collection of services for runit
On Fri, 9 Apr 2021 03:32:38 + Paul Wise wrote: > Please note the extra steps required when reintroducing packages: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs > Useful link, thanks :) Reminder for myself, if this get uploaded unarchive reopen and deal with the following bugs: #351051 #359106 #507087 #609426
Bug#986713: gpsd: please stop build-depending on makedev
Source: gpsd Version: 3.22-2 Dear Maintainer, your package build-depends on makedev, which itself is long obsolete. Please consider replacing makedev. Thanks, Chris
Bug#986712: varmon: please stop depending on makedev
Source: varmon Version: 1.2.1-2 Dear Maintainer, your package depends on makedev, which itself is long obsolete. Please replace this dependency. Thanks, Chris
Bug#986711: z8530-utils2: please stop depending on makedev
Source: z8530-utils2 Version: 3.0-1-10 Dear Maintainer, your package depends on makedev, which itself is long obsolete. Please replace this dependency. Thanks, Chris
Bug#986710: RM: djtools -- RoQA; long obsolete hardware, no upstream, basically no users
Package: ftp.debian.org Severity: normal Dear FTP Team, please remove djtools -- support tools for HP DeskJet 500/560C printers. These printers have been manufactured from 1990 to ca. 1997, so any surviving models are 20+ years old. HP has long stopped selling ink for them. The package is orphaned in Debian for 13 years, there is no upstream. Thanks, Chris
Bug#986701: mosquitto: CVE-2021-28166
This will be fixed soon, I would like to include an autopkgtest in the package, otherwise this would have been updated already. On Fri, 9 Apr 2021 at 20:27, Salvatore Bonaccorso wrote: > > Source: mosquitto > Version: 2.0.9-1 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for mosquitto. > > CVE-2021-28166[0]: > | In Eclipse Mosquitto version 2.0.0 to 2.0.9, if an authenticated > | client that had connected with MQTT v5 sent a crafted CONNACK message > | to the broker, a NULL pointer dereference would occur. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2021-28166 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28166 > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=572608 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore
Bug#986693: sbuild: unshare chroot: support unsharing network
Thank you for the quick reply. On 4/9/21 8:46 PM, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting bauen1 (2021-04-09 18:58:37) >> Please add support to the unshare chroot backend to unshare the network >> namespace. >> >> As per debian policy v4.5.1.0 >> https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules: >> >>> For packages in the main archive, no required targets may attempt network >>> access, except, via the loopback interface, to services on the build host >>> that have been started by the build. >> >> For these and similar scenarios It would be useful if sbuild unshare could be >> configured to prevent network access except for the loopback interface, by >> unsharing the network namespace and bringing up the loopback interface while >> still root. > > I don't understand. What bug do you see? The network namespace is already > unshared and only the loopback interface active in the unshare backend: > > https://sources.debian.org/src/sbuild/0.81.2/lib/Sbuild/Build.pm/?hl=2470#L2470 I'm sorry, I missed that. > Where is the bug? You can close it then :) > Thanks! -- bauen1 https://dn42.bauen1.xyz/
Bug#986708: Orphan sispmctl
Package: wnpp Severity: normal The package maintainer of package sispmctl has not shown any activity since 2012: * Bug reports remain unanswered. * Upstream releases are ignored. The current release is available at https://sourceforge.net/projects/sispmctl/files/sispmctl/sispmctl-4.9/ For repackaging you could use https://github.com/xypron/sispmctl/tree/debian/debian as a starting point. Best regards Heinrich
Bug#986707: rt4-db-mysql: should declare an incompatibility with mysql 8
Package: rt4-db-mysql Version: 4.4.4+dfsg-2 request-tracker4 as shipped with Ubuntu 20.04 is broken when used with the MySQL release also shipped in Ubuntu. Whilst we can't fix that directly in Debian, we an arrange for the dependencies to correctly reflect this, maybe by conflicting with mysql-server-8.0, and/orrequiring mariadb explicitly. Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/request-tracker4/+bug/1923264
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Control: reassign -1 kaptive 0.7.3-1 Andreas Tille writes: > Thanks a lot. Its very relieving to know a competent person behind > this I appreciate the kind words, but am alas unclear on where precisely BLAST+ is going wrong here. That said, I do see that future releases will incorporate an overhaul of some of the relevant portions of libseqdb, which with any luck will help in the long term, but which I'd rather not try to backport at this stage of the release cycle. The good news is that in response to previous issues along these lines (e.g., https://bugs.debian.org/970344), kleborate already supports retrying in single-threaded mode under some circumstances; kaptive just needs to indicate that it should do so, which it currently does only for much older versions. I'll extend the relevant version range shortly, and am reassigning this bug accordingly. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986472: gretl: broken symlink: /usr/share/gretl/examples -> ../doc/gretl-doc/examples
On 09/04/2021 23.23, Dirk Eddelbuettel wrote: | The --doc-main-package option can be used when the | auto-detection is insufficient or to reset the path to its previous | value if there is a reason to diverge from Debian policy recommendation. Spot on. What is most expedient way to correct this? dh_movefiles? --doc-main-package gretl-doc Andreas
Bug#943370: linux: Regression in testing kernel
Source: linux Followup-For: Bug #943370 X-Debbugs-Cc: omarpura...@gmail.com Also latest kernel update in Debian testing (5.10.26-1) proved to have some regressions with these elantech touchpads. When it stops working dmesg reports "IRQ triggeres but there's not data" also trying to restart or reload the device using modprobe doesn't work. Kernel reports: i2c_hid i2c-ELAN2204:00: failed to reset device. i2c_hid i2c-ELAN2204:00: can't hid device: -61 i2c_hid: probe of i2c.ELAN2204:00 failed with error -61 Haven't found anything of use in the kernel bugzilla, id be happy to test patches if the maintainer needs help with this issue :) -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Locale: LANG=es_MX.UTF-8, LC_CTYPE=es_MX.UTF-8 (charmap=UTF-8), LANGUAGE=es_MX:es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#986472: gretl: broken symlink: /usr/share/gretl/examples -> ../doc/gretl-doc/examples
On 9 April 2021 at 22:33, Andreas Beckmann wrote: | On 09/04/2021 22.19, Dirk Eddelbuettel wrote: | > That is ... quite possible. It's actually the same with line above in | > debian/rules. The actual underlying problem, though, is that a lot of | > content that once appears to have in gretl-doc is now in gretl itself :-/ | | dh_installdocs changed behavior from compat level 11 onwards: | | from debhelper(7): | | - The dh_installdocs and dh_installexamples tools may | now install most of the documentation in a different path to comply with | the recommendation from Debian policy §12.3 (since version 3.9.7). | | Note that if a given source package only contains a | single binary package in debian/control or none of the packages are -doc | packages, then this change is not relevant for that source package and | you can skip to the next change. | | By default, these tools will now attempt to | determine a "main package for the documentation" (called a | doc-main-package from here on) for every -doc package. If they find | such a doc-main-package, they will now install the | documentation into the path | /usr/share/doc/doc-main-package in the given doc package. I.e. the path | can change but the documentation is still shipped in the -doc package. | | The --doc-main-package option can be used when the | auto-detection is insufficient or to reset the path to its previous | value if there is a reason to diverge from Debian policy recommendation. | | Some documentation will not be affected by this | change. These exceptions include the copyright file, changelog files, | README.Debian, etc. These files will still be installed in the path | /usr/share/doc/package. Spot on. What is most expedient way to correct this? dh_movefiles? Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#986706: unblock: makedumpfile/1:1.6.8-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package makedumpfile
[ Reason ]
Adds necessary fixes for supporting current kernels.
[ Impact ]
makedumpfile will be unable to extract the dmesg from the 5.10 kernel,
and does not support 5.4 and newer kernels on arm64.
[ Tests ]
Forcing a crash dump in an x86 VM and verifying that the dmesg file
is produced and the crash utility is able to analyze the dump.
[ Risks ]
The biggest risk I can think of is that we may have broken support with
some earlier kernel version. But things do work with the kernel version
we're currently planning to release.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
N/A
unblock makedumpfile/1:1.6.8-4
diff -Nru makedumpfile-1.6.8/debian/changelog
makedumpfile-1.6.8/debian/changelog
--- makedumpfile-1.6.8/debian/changelog 2021-01-18 07:50:02.0 -0700
+++ makedumpfile-1.6.8/debian/changelog 2021-04-07 16:32:38.0 -0600
@@ -1,3 +1,13 @@
+makedumpfile (1:1.6.8-4) unstable; urgency=medium
+
+ [ Ioanna Alifieraki ]
+ * Fix failure of dmesg. creation on 5.10+ kernels.
+(Closes: #985896) (LP: #1921403).
+ * Fix makedumpfile failure on arm64 with 5.4 kernels.
+(Closes: #986594) (LP: #1879214)
+
+ -- dann frazier Wed, 07 Apr 2021 16:32:38 -0600
+
makedumpfile (1:1.6.8-3) unstable; urgency=medium
* Drop kdump-tools, which has been split into its own source package.
diff -Nru
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
---
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
1969-12-31 17:00:00.0 -0700
+++
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
2021-04-07 16:32:38.0 -0600
@@ -0,0 +1,587 @@
+From: John Ogness
+Date: Thu, 19 Nov 2020 02:41:21 +
+Subject: [PATCH 1/2] printk: add support for lockless ringbuffer
+
+* Required for kernel 5.10
+
+Linux 5.10 introduces a new lockless ringbuffer. The new ringbuffer
+is structured completely different to the previous iterations.
+Add support for retrieving the ringbuffer from debug information
+and/or using vmcoreinfo. The new ringbuffer is detected based on
+the availability of the "prb" symbol.
+
+Signed-off-by: John Ogness
+Signed-off-by: Kazuhito Hagio
+
+Origin: upstream,
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985896
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1921403
+---
+ Makefile | 2 +-
+ dwarf_info.c | 36 +-
+ makedumpfile.c | 103 ++--
+ makedumpfile.h | 58
+ printk.c | 207 +
+ 5 files changed, 399 insertions(+), 7 deletions(-)
+ create mode 100644 printk.c
+
+diff --git a/Makefile b/Makefile
+index b12bbb0..6f4d0e0 100644
+--- a/Makefile
b/Makefile
+@@ -45,7 +45,7 @@ CFLAGS_ARCH += -m32
+ endif
+
+ SRC_BASE = makedumpfile.c makedumpfile.h diskdump_mod.h sadump_mod.h
sadump_info.h
+-SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c
cache.c tools.c
++SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c
cache.c tools.c printk.c
+ OBJ_PART=$(patsubst %.c,%.o,$(SRC_PART))
+ SRC_ARCH = arch/arm.c arch/arm64.c arch/x86.c arch/x86_64.c arch/ia64.c
arch/ppc64.c arch/s390x.c arch/ppc.c arch/sparc64.c
+ OBJ_ARCH=$(patsubst %.c,%.o,$(SRC_ARCH))
+diff --git a/dwarf_info.c b/dwarf_info.c
+index e42a9f5..543588b 100644
+--- a/dwarf_info.c
b/dwarf_info.c
+@@ -614,6 +614,7 @@ search_structure(Dwarf_Die *die, int *found)
+ {
+ int tag;
+ const char *name;
++ Dwarf_Die die_type;
+
+ /*
+* If we get to here then we don't have any more
+@@ -622,9 +623,31 @@ search_structure(Dwarf_Die *die, int *found)
+ do {
+ tag = dwarf_tag(die);
+ name = dwarf_diename(die);
+- if ((tag != DW_TAG_structure_type) || (!name)
+- || strcmp(name, dwarf_info.struct_name))
++ if ((!name) || strcmp(name, dwarf_info.struct_name))
++ continue;
++
++ if (tag == DW_TAG_typedef) {
++ if (!get_die_type(die, _type)) {
++ ERRMSG("Can't get CU die of DW_AT_type.\n");
++ break;
++ }
++
++ /* Resolve typedefs of typedefs. */
++ while ((tag = dwarf_tag(_type)) == DW_TAG_typedef) {
++ if (!get_die_type(_type,
Bug#986686: missing b-d netpbm?
Am 09.04.2021 um 15:57 teilte Matthias Klose mit: Hi Matthias, On the Ubuntu buildd, the package ftbfs with a missing b-d. Adding netpbm fixes this, although I don't yet see why it doesn't fail on the Debian buildds. netpbm only shows as a Recommends in the Debian build log. https://launchpad.net/ubuntu/+source/texworks-manual/20210308-1/+build/21339493 On Debian I can convert png to eps files using convert: hille@debian-amd64-sid:~$ ls -l replaceDialog.* -rw-rw-r-- 1 hille hille 26755 May 7 2015 replaceDialog.png hille@debian-amd64-sid:~$ convert replaceDialog.png replaceDialog.eps hille@debian-amd64-sid:~$ ls -l replaceDialog.* -rw-r--r-- 1 hille hille 774464 Apr 9 23:04 replaceDialog.eps -rw-rw-r-- 1 hille hille 26755 May 7 2015 replaceDialog.png Doing the same on Ubuntu 20.10 fails: ubuntu@ubuntu2010:~$ convert replaceDialog.png replaceDialog.eps convert-im6.q16: attempt to perform an operation not allowed by the security policy `EPS' @ error/constitute.c/IsCoderAuthorized/408. b/c the /etc/ImageMagick-6/policy.xml differs between Debian & Ubuntu. The Makefile has a fallback to netpbm, but this does not work as we do not declare a B-D on netpbm. We could simply add it. What do you think? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#986705: unblock: chrony/4.0-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Please unblock package chrony
[ Reason ]
The IP_TOS socket option is currently missing in chronyd's seccomp filter
which prevents users from using the 'dscp' directive in the chronyd
configuration file while the seccomp filter is enabled. This directive allows
one to set the Differentiated Services Code Point to a specific value.
[ Impact ]
Since chronyd's seccomp filter is enabled by default in Debian, chronyd would be
killed right after being started when using the 'dscp' directive. Consequently,
to use this feature, users have to disable the seccomp filter.
[ Tests ]
Since the issue is easy to trigger, I manually tested the proposed fix while
ensuring that autopkgtest reports no regressions. Here are some steps to
reproduce the issue encountered by chrony 4.0-6:
# echo 'dscp 22' > /etc/chrony/conf.d/dscp.conf
# systemctl restart chrony.service
# systemctl is-active chrony.service
failed
With chrony 4.0-7, the last command reports chrony.service as active.
[ Risks ]
Harmless. We just allow the IP_TOS setsockopt() option in the seccomp filter.
[ Checklist ]
[✓] all changes are documented in the d/changelog
[✓] I reviewed all changes and I approve them
[✓] attach debdiff against the package in testing
unblock chrony/4.0-7
Cheers,
Vincent
-BEGIN PGP SIGNATURE-
iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYHC9bQAKCRAQn1qAt/bg
AbvgAQCCCKwtSJ/J5u9UJFT0KFVLrBo2b7wYV/uHY20Mq+WHZAEA0xNSEF/09KJi
JIMz/mzm/PGJ3Q9K3BT5zSewfjmLBwI=
=skob
-END PGP SIGNATURE-
diff -Nru chrony-4.0/debian/changelog chrony-4.0/debian/changelog
--- chrony-4.0/debian/changelog 2021-02-21 21:59:22.0 +0100
+++ chrony-4.0/debian/changelog 2021-04-08 16:21:16.0 +0200
@@ -1,3 +1,11 @@
+chrony (4.0-7) unstable; urgency=medium
+
+ * debian/patches/:
+- Add allow-IP_TOS-socket-option-in-seccomp-filter.patch to enable the use
+of the 'dscp' directive.
+
+ -- Vincent Blut Thu, 08 Apr 2021 16:21:16 +0200
+
chrony (4.0-6) unstable; urgency=medium
* debian/tests/helper-functions:
diff -Nru
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch
---
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch
1970-01-01 01:00:00.0 +0100
+++
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch
2021-04-08 16:21:16.0 +0200
@@ -0,0 +1,33 @@
+From 966e6fd939df724235a93e7a89dd7cf67178f99d Mon Sep 17 00:00:00 2001
+From: Foster Snowhill
+Date: Sun, 4 Apr 2021 15:12:17 +0200
+Subject: sys_linux: allow setsockopt(SOL_IP, IP_TOS) in seccomp
+
+This system call is required by the DSCP marking feature introduced in commit
+6a5665ca5877 ("conf: add dscp directive").
+
+Before this change, enabling seccomp filtering (chronyd -F 1) and specifying a
+custom DSCP value in the configuration (for example "dscp 46") caused the
+process to be killed by seccomp due to IP_TOS not being allowed by the filter.
+
+Tested before and after the change on Ubuntu 21.04, kernel 5.11.0-13-generic.
+IP_TOS is available since Linux 1.0, so I didn't add any ifdefs for it.
+
+Signed-off-by: Foster Snowhill
+
+Bug:
https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-dev/2021/04/msg0.html
+Applied-Upstream:
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=966e6fd939df724235a93e7a89dd7cf67178f99d
+Last-Update: 2021-04-08
+Index: chrony/sys_linux.c
+===
+--- chrony.orig/sys_linux.c
chrony/sys_linux.c
+@@ -615,7 +615,7 @@ SYS_Linux_EnableSystemCallFilter(int lev
+ };
+
+ const static int socket_options[][2] = {
+-{ SOL_IP, IP_PKTINFO }, { SOL_IP, IP_FREEBIND },
++{ SOL_IP, IP_PKTINFO }, { SOL_IP, IP_FREEBIND }, { SOL_IP, IP_TOS },
+ #ifdef FEAT_IPV6
+ { SOL_IPV6, IPV6_V6ONLY }, { SOL_IPV6, IPV6_RECVPKTINFO },
+ #endif
diff -Nru chrony-4.0/debian/patches/series chrony-4.0/debian/patches/series
--- chrony-4.0/debian/patches/series2021-02-21 21:59:22.0 +0100
+++ chrony-4.0/debian/patches/series2021-04-08 16:21:16.0 +0200
@@ -1 +1,2 @@
+allow-IP_TOS-socket-option-in-seccomp-filter.patch
nm-dispatcher-dhcp_Move-server_dir-to-run.patch
Bug#986690: triplane FTCBFS -- executes dksbuild during build
On Fri, Apr 09, 2021 at 09:44:20PM +0200, Helmut Grohne wrote: > Control: tags -1 - patch > > Hi Nilesh, > > On Fri, Apr 09, 2021 at 09:07:31PM +0530, Nilesh Patra wrote: > > Since fokker.dks binary is not being installed, such a compilation would > > not give any exec format problems. And building it via build compiler > > does not seem a problem > > As far as I can see, dksbuild.cc produces a binary format. You can > easily spot that by searching for fread and fwrite. This format is > composed of structures that happen to contain elements of type unsigned > long int. The size of this type is architecture-dependent. Unless I am > mistaken, the output becomes dependent on the bits of the architecture. Right. > If you download triplane for various architectures and compare > /usr/share/games/triplane/fokker.dks, you'll spot that e.g. amd64 vs > i386 differs, but amd64 vs arm64 does not. Also s390x (which is big > endian) yields yet a different result. ACK, this is probably because of my poor testing there. Admittedly, I did not test extensively. > > I'm attaching my patch along, and will commit to salsa if it looks good. > > NACK. Thanks for the review! > Also shipping the file in /usr/share is a lie. It's > architecture-dependent and therefore should go to /usr/lib. Better still > would be using an architecture-independent file format. Righty Nilesh signature.asc Description: PGP signature
Bug#986472: gretl: broken symlink: /usr/share/gretl/examples -> ../doc/gretl-doc/examples
On 09/04/2021 22.19, Dirk Eddelbuettel wrote: That is ... quite possible. It's actually the same with line above in debian/rules. The actual underlying problem, though, is that a lot of content that once appears to have in gretl-doc is now in gretl itself :-/ dh_installdocs changed behavior from compat level 11 onwards: from debhelper(7): - The dh_installdocs and dh_installexamples tools may now install most of the documentation in a different path to comply with the recommendation from Debian policy §12.3 (since version 3.9.7). Note that if a given source package only contains a single binary package in debian/control or none of the packages are -doc packages, then this change is not relevant for that source package and you can skip to the next change. By default, these tools will now attempt to determine a "main package for the documentation" (called a doc-main-package from here on) for every -doc package. If they find such a doc-main-package, they will now install the documentation into the path /usr/share/doc/doc-main-package in the given doc package. I.e. the path can change but the documentation is still shipped in the -doc package. The --doc-main-package option can be used when the auto-detection is insufficient or to reset the path to its previous value if there is a reason to diverge from Debian policy recommendation. Some documentation will not be affected by this change. These exceptions include the copyright file, changelog files, README.Debian, etc. These files will still be installed in the path /usr/share/doc/package. Andreas
Bug#986704: xaw3dg: FTCBFS -- uses build compiler during cross build
Package: xaw3dg Version: 1.5+F-1 Severity: normal Tags: patch User: debian-cr...@lists.debian.org X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, debian-cr...@lists.debian.org Dear Maintainer, xaw3dg fails to cross build because it uses build compiler rather than the host compiler whilst cross building. The attached patch fixes the situation, please consider applying Nilesh -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xaw3dg depends on: ii libc6 2.31-3 ii libice6 2:1.0.9-2 ii libsm62:1.2.3-1 ii libx11-6 2:1.7.0-2 ii libxext6 2:1.3.3-1+b2 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt61:1.1.5-1+b3 xaw3dg recommends no packages. xaw3dg suggests no packages. -- no debconf information diff --git a/debian/rules b/debian/rules index f8f65f3..bdc2ae6 100755 --- a/debian/rules +++ b/debian/rules @@ -12,7 +12,7 @@ SOURCE=xc/lib/Xaw3d override_dh_auto_build: rm -rf $(SOURCE)/X11 && install -m755 -d $(SOURCE)/X11 cd $(SOURCE) && ln -sf ../ X11/Xaw3d && xmkmf - $(MAKE) -C $(SOURCE) \ + dh_auto_build -- -C $(SOURCE) \ EXTRA_DEFINES="-D_REENTRANT -DARROW_SCROLLBAR" SHLIBDEF="-D_REENTRANT -DARROW_SCROLLBAR" override_dh_auto_clean: @@ -22,7 +22,7 @@ override_dh_auto_clean: dh_clean `find . -name Makefile` override_dh_auto_install: - $(MAKE) -C $(SOURCE) install \ + dh_auto_install -- -C $(SOURCE) install \ DESTDIR=$(CURDIR)/debian/tmp INCDIR=/usr/include \ SHLIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \ USRLIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
Bug#986472: gretl: broken symlink: /usr/share/gretl/examples -> ../doc/gretl-doc/examples
On 6 April 2021 at 17:18, Andreas Beckmann wrote: | Package: gretl | Version: 2021a-1 | Severity: normal | User: debian...@lists.debian.org | Usertags: piuparts | | Hi, | | during a test with piuparts I noticed your package ships (or creates) | a broken symlink. | | >From the attached log (scroll to the bottom...): | | 1m11.8s ERROR: FAIL: Broken symlinks: | /usr/share/gretl/examples -> ../doc/gretl-doc/examples (gretl) | | Did you mean to target ../doc/gretl/examples instead? That is ... quite possible. It's actually the same with line above in debian/rules. The actual underlying problem, though, is that a lot of content that once appears to have in gretl-doc is now in gretl itself :-/ I have fixed debian/rules. Should be better in next upload (roughly quarterly). Thanks, Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x
On 8 April 2021 at 11:29, Graham Inggs wrote: | Control: forwarded -1 https://deb.li/6f4z | | TMB upstream have submitted a bug report [1] to R-forge. | | > Headers need update corresponding to new SuiteSparse version 5.7.1 | > | > SuiteSparse was recently updated from version 4.2.1 to 5.7.1, however without updating the header `inst/cholmod.h` accordingly. Notably the cholmod_common struct no longer has a member 'print_function'. See also https://github.com/glmmTMB/glmmTMB/issues/665 | | | [1] https://r-forge.r-project.org/tracker/index.php?func=detail=6714_id=61=294 Fantastic. On 9 April 2021 at 10:43, Graham Inggs wrote: | Control: tags -1 + fixed-upstream | | Fixed in Matrix upstream svn rev 3376 [1]. | | | [1] https://r-forge.r-project.org/scm/viewvc.php?view=rev=matrix=3376 Even better. Big BIG Thank You for persistently chasing that to the end. Thank you! Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#986690: triplane FTCBFS -- executes dksbuild during build
Hi, On 4/9/21 10:44 PM, Helmut Grohne wrote: As far as I can see, dksbuild.cc produces a binary format. You can easily spot that by searching for fread and fwrite. This format is composed of structures that happen to contain elements of type unsigned long int. The size of this type is architecture-dependent. Unless I am mistaken, the output becomes dependent on the bits of the architecture. Yes I think that is correct. The data could be inside the executable nowadays since the original reasons for keeping it separate have disappeared. Also shipping the file in /usr/share is a lie. It's architecture-dependent and therefore should go to /usr/lib. Better still would be using an architecture-independent file format. /usr/share is indeed probably a separate bug. I don't think we (speaking as upstream here) are keen on changing the data format though as this is an original game from 1990s and is essentially in a maintenance-only mode. -Timo
Bug#986703: homebank: Homebank 5.5.1 in Debian bullseye
Package: homebank Version: 5.5-2 Severity: minor X-Debbugs-Cc: ma...@straka.info Hi. Could you get Homebank 5.5.1 in to Debian bullseye? There are nearly only bugfixes. http://homebank.free.fr/ChangeLog
Bug#986692: crash at startup
I can confirm this, and the backtrace looks similar: #0 0x00080005 in ?? () #1 0x77a1d879 in _Unwind_ForcedUnwind_Phase2 (exc=0x55614e90, context=0x7fffdd70, frames_p=0x7fffdc78) at ../../../src/libgcc/unwind.inc:170 #2 0x77a1e14d in _Unwind_Resume (exc=exc@entry=0x55614e90) at ../../../src/libgcc/unwind.inc:243 #3 0x55560c65 in __gnu_cxx::new_allocator::~new_allocator (this=, __in_chrg=) at /usr/include/c++/9/ext/new_allocator.h:89 #4 std::allocator::~allocator (this=0x7fffdeb0, __in_chrg=) at /usr/include/c++/9/bits/allocator.h:153 #5 std::__cxx11::basic_string, std::allocator >::_Alloc_hider::~_Alloc_hider (this=, __in_chrg=) at /usr/include/c++/9/bits/basic_string.h:150 #6 std::__cxx11::basic_string, std::allocator >::~basic_string (this=, __in_chrg=) at /usr/include/c++/9/bits/basic_string.h:658 #7 Levels::addLevel (this=, file="/usr/share/numptyphysics/L99_Gravity_Test.nph", rank=99, index=-1) at Levels.cpp:117 valgrind says: Invalid read of size 8 at 0x4DFA810: ??? (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1) by 0x4DFB14C: _Unwind_Resume (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1) by 0x114C64: ~new_allocator (new_allocator.h:89) by 0x114C64: ~allocator (allocator.h:153) by 0x114C64: ~_Alloc_hider (basic_string.h:150) by 0x114C64: ~basic_string (basic_string.h:658) by 0x114C64: Levels::addLevel(std::__cxx11::basic_string, std::allocator > const&, int, int) [clone .cold] (Levels.cpp:117) by 0x11C9B3: Levels::addPath(char const*) (Levels.cpp:93) by 0x11C8CD: Levels::addPath(char const*) (Levels.cpp:104) by 0x12C7FE: runGame (App.cpp:184) by 0x12C7FE: run (App.cpp:110) by 0x12C7FE: npmain(int, char**) (App.cpp:372) by 0x1174FA: main (OsFreeDesktop.cpp:133) Address 0x68ec6b8 is 0 bytes after a block of size 24 alloc'd at 0x4838DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x12BD89: runGame (App.cpp:173) by 0x12BD89: run (App.cpp:110) by 0x12BD89: npmain(int, char**) (App.cpp:372) by 0x1174FA: main (OsFreeDesktop.cpp:133) Some debugging suggests that the string being destroyed when it crashes is the "My Levels" std::string created from the static const char MISC_COLLECTION[] in Levels::addLevel() (no idea what is the problem with this code). -- WBR, wRAR signature.asc Description: PGP signature
Bug#984762: /usr/bin/setterm: Setterm, Please Add an Option to Increase PC-Speaker Volume
Control: tags -1 + upstream Control: reassign -1 src:linux Hello Chime Hart, * Chime Hart [210409 19:48]: > Setterm is quite good at altering the frequency-and-length of a beep, > however, a volume option would be `most appreciated. Thank you for your report. setterm only sends so called "escape codes" to the terminal to change these settings. The current Linux virtual terminal driver does not seem to support changing the volume. Reassigning to linux, as implementing this would need to start there. If you think this is an important feature, I would however suggest engaging the Linux virtual terminal driver maintainers directly. Chris
Bug#986702: openafs-fileserver: Upgrade from stretch broken (missing dependency)
On Fri, Apr 09, 2021 at 03:29:48PM -0400, Chaskiel Grundman wrote: > Package: openafs-fileserver > Version: 1.8.2-1+deb10u1 > Severity: important > > Dear Maintainer, > While upgrading a system from stretch (9.9) to buster (10.9), I had a > failure in this package: > > Setting up openafs-fileserver (1.8.2-1+deb10u1) ... > /var/lib/dpkg/info/openafs-fileserver.postinst: 24: > /var/lib/dpkg/info/openafs-fileserver.postinst: akeyconvert: not found > dpkg: error processing package openafs-fileserver (--configure): > installed openafs-fileserver package post-installation script > subprocess returned error exit status 127 > dpkg: dependency problems prevent configuration of openafs-dbserver: > openafs-dbserver depends on openafs-fileserver; however: > Package openafs-fileserver is not configured yet. > > dpkg: error processing package openafs-dbserver (--configure): > dependency problems - leaving unconfigured > Errors were encountered while processing: > openafs-fileserver > openafs-dbserver > E: Sub-process /usr/bin/dpkg returned an error code (1) > > It appears that this package needs to depend on openafs-krb5, or that > the postinst needs to not attempt to convert the keys. or only convert the keys if akeyconvert is available, yes. Thanks, this is a good catch. -Ben
Bug#986690: triplane FTCBFS -- executes dksbuild during build
Control: tags -1 - patch Hi Nilesh, On Fri, Apr 09, 2021 at 09:07:31PM +0530, Nilesh Patra wrote: > Since fokker.dks binary is not being installed, such a compilation would > not give any exec format problems. And building it via build compiler > does not seem a problem As far as I can see, dksbuild.cc produces a binary format. You can easily spot that by searching for fread and fwrite. This format is composed of structures that happen to contain elements of type unsigned long int. The size of this type is architecture-dependent. Unless I am mistaken, the output becomes dependent on the bits of the architecture. If you download triplane for various architectures and compare /usr/share/games/triplane/fokker.dks, you'll spot that e.g. amd64 vs i386 differs, but amd64 vs arm64 does not. Also s390x (which is big endian) yields yet a different result. > I'm attaching my patch along, and will commit to salsa if it looks good. NACK. Also shipping the file in /usr/share is a lie. It's architecture-dependent and therefore should go to /usr/lib. Better still would be using an architecture-independent file format. Helmut
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
Hello Václav Doležal, * Václav Doležal [210409 19:39]: > can you verify that the bug is still present in current libblkid? > > It should be fixed since commit cdb9140967 [1] (v2.35 or higher). Thanks for your followup. The original submitter sent this info in message #27: # lsblk --version lsblk from util-linux 2.35.1 # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sda sda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCER ntfs Looks like the referenced commit doesnt fix it for them. Chris
Bug#986702: openafs-fileserver: Upgrade from stretch broken (missing dependency)
Package: openafs-fileserver Version: 1.8.2-1+deb10u1 Severity: important Dear Maintainer, While upgrading a system from stretch (9.9) to buster (10.9), I had a failure in this package: Setting up openafs-fileserver (1.8.2-1+deb10u1) ... /var/lib/dpkg/info/openafs-fileserver.postinst: 24: /var/lib/dpkg/info/openafs-fileserver.postinst: akeyconvert: not found dpkg: error processing package openafs-fileserver (--configure): installed openafs-fileserver package post-installation script subprocess returned error exit status 127 dpkg: dependency problems prevent configuration of openafs-dbserver: openafs-dbserver depends on openafs-fileserver; however: Package openafs-fileserver is not configured yet. dpkg: error processing package openafs-dbserver (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: openafs-fileserver openafs-dbserver E: Sub-process /usr/bin/dpkg returned an error code (1) It appears that this package needs to depend on openafs-krb5, or that the postinst needs to not attempt to convert the keys. -- System Information: Debian Release: 10.9 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-11-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openafs-fileserver depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libhcrypto4-heimdal7.5.0+dfsg-3 ii libroken18-heimdal 7.5.0+dfsg-3 ii lsb-base 10.2019051400 ii openafs-client 1.8.2-1+deb10u1 Versions of packages openafs-fileserver recommends: ii ntp 1:4.2.8p12+dfsg-4 Versions of packages openafs-fileserver suggests: pn openafs-doc -- debconf information: openafs-fileserver/thiscell: grand.central.org openafs-fileserver/alpha-broken:
Bug#986701: mosquitto: CVE-2021-28166
Source: mosquitto Version: 2.0.9-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for mosquitto. CVE-2021-28166[0]: | In Eclipse Mosquitto version 2.0.0 to 2.0.9, if an authenticated | client that had connected with MQTT v5 sent a crafted CONNACK message | to the broker, a NULL pointer dereference would occur. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-28166 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28166 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=572608 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#986698: unblock: gavodachs2-server/2.3+dfsg-1
Control: retitle -1 unblock: gavodachs/2.3+dfsg-1 (pre-approval) Control: tag -1 moreinfo Hi Markus On 09-04-2021 20:09, Markus Demleitner wrote: > Please unblock package gavodachs2-server unblocks are against source packages, so it's "unblock gavodachs" > In case this makes the decision easier for you: I've now set up a CI > autopkgtest on salsa; while the test code (also in the debdiff) > relatively compact, I contend it's exercising quite a few parts of > wthe software, and it would certainly have spotted the problem at hand. non-key packages with successful non-trivial autopkgtests don't need an unblock at this stage of the freeze (albeit, I do hope that the window to have your package migrate in this stage ends soon). > unblock gavodachs2-server/2.3+dfsg-1 You didn't upload yet I think, so I have retitle this bug as "pre-approval". However, if the autopkgtest stays and passes if/when you upload, there's nothing for us to do, so no approval needed. So, if you as a maintainer think this is the best for your/our users, you should make the call yourself, keeping in mind our freeze policy [1]. Paul [1] https://release.debian.org/bullseye/freeze_policy.html#hard OpenPGP_signature Description: OpenPGP digital signature
Bug#986700: nouveau: Suspend hangs for 5 minutes before completing
Package: src:linux
Version: 5.10.26-1
Followup-For: Bug #979340
Dear Maintainer,
My issue is very similar to the original reporter's, and as addressed in this
thread[1], by adding init_on_alloc=0 to kernel parameters, suspend goes
fast as normal.
Unlike the original reporter, I can find which debian versions cause
suspend slow:
- 5.7.17-1(linux-image-5.7.0-3-amd64) and older versions don't have the bug.
- 5.8.7-1(linux-image-5.8.0-1-amd64) and newer versions have the bug.
(I do not test 5.8.3-1~exp1 which is from the experimental suit.)
>From changelogs and /boot/config-*, INIT_ON_ALLOC_DEFAULT_ON is enabled in
Debian packages starting from 5.8, which seems to consistent with my test
result.
Another note: besides adding nouveau.noaccel=1 or init_on_alloc=0 to kernel
parameters, if /dev/dri/card0 were deleted before starting lightdm or startx,
suspend also goes fast as normal. Although this has side effects.
[1] https://bbs.archlinux.org/viewtopic.php?id=250863
Regards,
Roy Clark
-- Package-specific info:
** Version:
Linux version 5.10.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.26-1 (2021-03-27)
** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-5-amd64
root=UUID=da162e90-eb35-4f39-8114-db1d2a5e0669 ro acpi_osi=Linux
acpi_backlight=vendor slab_common.usercopy_fallback=y init_on_alloc=0 quiet
root=/dev/mapper/cryptroot
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[ 68.453474] input: ACPI Virtual Keyboard Device as
/devices/virtual/input/input33
[ 72.458501] zram: Added device: zram0
[ 73.003295] zram0: detected capacity change from 0 to 268435456
[ 73.041097] Adding 262140k swap on /dev/zram0. Priority:100 extents:1
across:262140k SSFS
[ 92.436565] RTL8211B Gigabit Ethernet r8169-c00:00: attached PHY driver
[RTL8211B Gigabit Ethernet] (mii_bus:phy_addr=r8169-c00:00, irq=IGNORE)
[ 92.503471] r8169 :0c:00.0 eth0: Link is Down
[ 95.545914] wlan0: authenticate with 5c:63:bf:bb:24:64
[ 95.557065] wlan0: send auth to 5c:63:bf:bb:24:64 (try 1/3)
[ 95.562459] wlan0: authenticated
[ 95.569053] wlan0: associate with 5c:63:bf:bb:24:64 (try 1/3)
[ 95.574225] wlan0: RX AssocResp from 5c:63:bf:bb:24:64 (capab=0x431 status=0
aid=1)
[ 95.574378] wlan0: associated
[ 95.812718] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 109.989313] kauditd_printk_skb: 26 callbacks suppressed
[ 109.989318] audit: type=1400 audit(1617990614.847:38): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/proc/1268/coredump_filter"
pid=1268 comm="java" requested_mask="wr" denied_mask="wr" fsuid=136 ouid=136
[ 109.989392] audit: type=1400 audit(1617990614.847:39): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/proc/1268/coredump_filter"
pid=1268 comm="java" requested_mask="wr" denied_mask="wr" fsuid=136 ouid=136
[ 113.372958] audit: type=1400 audit(1617990618.227:40): apparmor="ALLOWED"
operation="file_mmap" profile="system_i2p"
name="/usr/lib/jvm/java-11-openjdk-amd64/lib/server/classes.jsa" pid=1268
comm="java" requested_mask="m" denied_mask="m" fsuid=136 ouid=0
[ 126.129782] audit: type=1400 audit(1617990631.858:41): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/usr/share/java/libintl-0.21.jar"
pid=1268 comm="java" requested_mask="r" denied_mask="r" fsuid=136 ouid=0
[ 126.592357] audit: type=1400 audit(1617990632.318:42): apparmor="ALLOWED"
operation="open" profile="system_i2p"
name="/usr/share/java/eclipse-jdt-core-3.24.0.jar" pid=1268 comm="java"
requested_mask="r" denied_mask="r" fsuid=136 ouid=0
[ 127.144409] audit: type=1400 audit(1617990632.874:43): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/usr/share/java/servlet-api.jar"
pid=1268 comm="java" requested_mask="r" denied_mask="r" fsuid=136 ouid=0
[ 129.132235] audit: type=1400 audit(1617990634.858:44): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/usr/share/java/jsp-api.jar"
pid=1268 comm="java" requested_mask="r" denied_mask="r" fsuid=136 ouid=0
[ 129.400223] audit: type=1400 audit(1617990635.126:45): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/usr/share/java/libintl-0.21.jar"
pid=1268 comm="java" requested_mask="r" denied_mask="r" fsuid=136 ouid=0
[ 145.854173] audit: type=1400 audit(1617990651.585:46): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/proc/1412/coredump_filter"
pid=1412 comm="java" requested_mask="wr" denied_mask="wr" fsuid=136 ouid=136
[ 145.854190] audit: type=1400 audit(1617990651.585:47): apparmor="ALLOWED"
operation="open" profile="system_i2p" name="/proc/1412/coredump_filter"
pid=1412 comm="java" requested_mask="wr" denied_mask="wr" fsuid=136 ouid=136
[ 145.905138] audit: type=1400 audit(1617990651.633:48): apparmor="ALLOWED"
Bug#986693: sbuild: unshare chroot: support unsharing network
Hi, Quoting bauen1 (2021-04-09 18:58:37) > Please add support to the unshare chroot backend to unshare the network > namespace. > > As per debian policy v4.5.1.0 > https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules: > > > For packages in the main archive, no required targets may attempt network > > access, except, via the loopback interface, to services on the build host > > that have been started by the build. > > For these and similar scenarios It would be useful if sbuild unshare could be > configured to prevent network access except for the loopback interface, by > unsharing the network namespace and bringing up the loopback interface while > still root. I don't understand. What bug do you see? The network namespace is already unshared and only the loopback interface active in the unshare backend: https://sources.debian.org/src/sbuild/0.81.2/lib/Sbuild/Build.pm/?hl=2470#L2470 Where is the bug? Thanks! cheers, josch signature.asc Description: signature
Bug#986699: thunar: Thunar default dir and file sort is reversed. Manual changes not persistent.
Package: thunar Version: 4.16.3-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Don't know. Just began to notice reverse sort. * What exactly did you do (or not do) that was effective (or ineffective)? Tried to adjust sort in settings. No adjustment possible, except "Sort dirs before files", which had no effect. Also checked /etc/default/locale, which is as pasted in: LANG="en_US.UTF-8" LC_COLLATE=C * What was the outcome of this action? No effect. * What outcome did you expect instead? Sort dirs before files, in ascending order. This used to be the default. *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunar depends on: ii desktop-file-utils 0.26-1 ii exo-utils4.16.0-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-11 ii libcairo21.16.0-5 ii libexo-2-0 4.16.0-1 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-3 ii libgudev-1.0-0 234-1 ii libice6 2:1.0.10-1 ii libnotify4 0.7.9-3 ii libpango-1.0-0 1.46.2-3 ii libsm6 2:1.2.3-1 ii libthunarx-3-0 4.16.3-1 ii libxfce4ui-2-0 4.16.0-1 ii libxfce4util74.16.0-1 ii libxfconf-0-34.16.0-2 ii shared-mime-info 2.0-1 ii thunar-data 4.16.3-1 Versions of packages thunar recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii gvfs 1.46.2-1 ii libxfce4panel-2.0-4 4.16.2-1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7 ii thunar-volman 4.16.0-1 ii tumbler 4.16.0-1 ii udisks2 2.9.2-1 ii xdg-user-dirs 0.17-2 Versions of packages thunar suggests: ii gvfs-backends 1.46.2-1 ii thunar-archive-plugin 0.4.0-2 ii thunar-media-tags-plugin 0.3.0-2
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
No problem, My apologies that I am asking, I am just not DD so long, so I'd rather ask so that everything is clear to me :) , I promise I'll be shorter next time :) Thank you again and have a nice weekend. Michal Arbet (kevko) Dne pá 9. 4. 2021 19:53 uživatel Adam D. Barratt napsal: > Hi, > > On Fri, 2021-04-09 at 19:46 +0200, Michal Arbet wrote: > > I've already added fixed tag to original bugreport > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645 > > The only fixed version I can see there right now, fwiw, was the result > of my mail to which you replied. [ > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645;msg=7 ]. In > any case, it's done, so I guess it doesn't really matter who did it > when. :) > > > Does it mean that I can upload now ? > > Yes. Apologies for any possible ambiguity, but that is indeed what I > meant by: > > > > Please feel free to go ahead. > > Regards, > > Adam > >
Bug#984975: gedit 3.30.2-2 segmentation fault
Hello Nenad Cvetkovic, > Hi Bernhard Übelacker, > I hope I managed to create a proper backtrace, this is my first time. > > As for your question about rebuilt packages, I have no idea when this happened. I didn't build many things, I remember building ubuntu's Yaru theme. > > Thread 1 (Thread 0x7f7711e8ea80 (LWP 18322)): > #0 0x007f198f in () > #1 0x7f7715fee669 in g_main_context_prepare () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x7f7715fef06b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #3 0x7f7715fef25c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #4 0x7f77171a5a2d in g_application_run () at /lib/x86_64-linux-gnu/libgio-2.0.so.0 > #5 0x55e52ad2d1fa in main () thank you for the backtrace, at least it is equal to what your core file generated in my test. I still guess this might be a manifestation of upstream bug [1]. Unfortunately this got closed as it could no longer be reproduced with at least gedit-3.30.2 and glib-2.60.6. Unfortunately in Buster/stable is glib-2.58.3 in use. Kind regards, Bernhard [1] https://gitlab.gnome.org/GNOME/gedit/-/issues/51
Bug#984614: snort in Bullseye
Control: found -1 2.9.15.1-2 Hi, it appears this conffile handling problem is caused by a not good enough attempt to move the old conffile /etc/cron.daily/5snort to /etc/cron.daily/snort-common. This was introduced in version 2.9.15.1-2 commit 8780db8c, to snort-common.preinst: +# rename probably existing cron job with old name +if [ -e /etc/cron.daily/5snort ]; then +mv /etc/cron.daily/5snort /etc/cron.daily/snort-common +fi It would appear trivial to change this to use dpkg-maintscript-helper mv_conffile instead. Someone with enough interest in snort should probably just make this change and upload it. Chris
Bug#986671: aoe-sancheck and interface names
Dear Christoph, thank you very much for your quick response and your insightful comments in the upstream bug report. > Just in case, adding "net.ifnames=0" to the kernel command line restores the > old behaviour - but I understand there are various reasons, up to and > including > layer 9, to not do that. Of course... Up to now we managed to get around systemd and all the extra effects it has. As we are afraid that bullseye may be the last usable debian version that can be operated without systemd, we at least need to test an upgrade path. > > Looking into the source revealed that "eth" is hardcoded in aoe-sancheck.c > > to find valid interfaces. > Yeah, that doesn't make much sense nowadays. The code really should probe the > interface's capabilities instead, I've made a suggestion in the related > upstream bug. You are absolutely right; I refreshed the patch to check for: * IFF_NOARP * IFF_UP * IFF_LOOPBACK > > The trivial patch attached fixes the issue while still being able to > > correctly identify old interface names as well. > > We'd be very glad if this patch could still make it into bullseye... ;-) > Understood. I'll see what upstream will do about that, quite frankly, > your patch is rather last resort - and I know we're in a time frame > here. Thank you for asking for better solutions... :) I hope, the attache version two of the patch better fits the bill! all the best, Adi --- a/aoe-sancheck.c +++ b/aoe-sancheck.c @@ -513,8 +513,18 @@ ethlist(char **ifs, int nifs) ifr.ifr_ifindex = i; if (ioctl(s, SIOCGIFNAME, ) < 0) continue; - if (strncmp(ifr.ifr_name, "eth", 3)) +// get interface flags + if (ioctl(s, SIOCGIFFLAGS, ) < 0) continue; +// only use interfaces that use arp protocol +if (ifr.ifr_flags & IFF_NOARP) +continue; +// only use interfaces that are up +if (!(ifr.ifr_flags & IFF_UP)) +continue; +// skip loopback interfaces +if (ifr.ifr_flags & IFF_LOOPBACK) +continue; inserteth(ifs, nifs, ifr.ifr_name); n++; } signature.asc Description: PGP signature
Bug#986697: qreator crashes at startup
Package: qreator
Version: 16.06.1-5
Severity: important
qreator crashes at startup with the following error message:
/usr/share/qreator/qreator_lib/Builder.py:21: PyGIWarning: Gtk was
imported without specifying a version first. Use
gi.require_version('Gtk', '3.0') before import to ensure that the right
version gets loaded.
from gi.repository import GObject, Gtk # pylint: disable=E0611
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:20: PyGIWarning:
GtkChamplain was imported without specifying a version first. Use
gi.require_version('GtkChamplain', '0.12') before import to ensure that
the right version gets loaded.
from gi.repository import (
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:20: PyGIWarning:
GtkClutter was imported without specifying a version first. Use
gi.require_version('GtkClutter', '1.0') before import to ensure that the
right version gets loaded.
from gi.repository import (
/usr/share/qreator/qreator/qrcodes/QRCodeWifiGtk.py:20: PyGIWarning: NM
was imported without specifying a version first. Use
gi.require_version('NM', '1.0') before import to ensure that the right
version gets loaded.
from gi.repository import Gtk, GLib, GdkPixbuf, NM
Traceback (most recent call last):
File "/usr/bin/qreator", line 46, in
qreator.main()
File "/usr/share/qreator/qreator/__init__.py", line 69, in main
window = QreatorWindow.QreatorWindow()
File "/usr/share/qreator/qreator_lib/Window.py", line 46, in __new__
builder = get_builder('QreatorWindow')
File "/usr/share/qreator/qreator_lib/helpers.py", line 54, in get_builder
builder.add_from_file(ui_filename)
File "/usr/share/qreator/qreator_lib/Builder.py", line 86, in
add_from_file
ele_widgets = tree.getiterator("object")
AttributeError: 'ElementTree' object has no attribute 'getiterator'
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages qreator depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
ii geoclue-2.0 2.5.7-3
ii gir1.2-champlain-0.12 0.12.20-1
ii gir1.2-clutter-1.0 1.26.4+dfsg-2
ii gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1
ii gir1.2-geoclue-2.0 2.5.7-3
ii gir1.2-glib-2.0 1.66.1-1+b1
ii gir1.2-gtk-3.0 3.24.24-3
ii gir1.2-gtkchamplain-0.12 0.12.20-1
ii gir1.2-gtkclutter-1.0 1.8.4-4
ii gir1.2-nm-1.0 1.30.0-1
ii python3 3.9.2-2
ii python3-cairo 1.16.2-4+b2
ii python3-dbus 1.2.16-5
ii python3-gi 3.38.0-2
ii python3-gi-cairo 3.38.0-2
ii python3-pil 8.1.2-1
ii python3-qrencode 1.2-5+b4
ii python3-requests 2.25.1+dfsg-2
ii python3-vobject 0.9.6.1-0.2
ii python3-xdg 0.27-2
qreator recommends no packages.
qreator suggests no packages.
-- no debconf information
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
Hi, On Fri, 2021-04-09 at 19:46 +0200, Michal Arbet wrote: > I've already added fixed tag to original bugreport > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645 The only fixed version I can see there right now, fwiw, was the result of my mail to which you replied. [ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645;msg=7 ]. In any case, it's done, so I guess it doesn't really matter who did it when. :) > Does it mean that I can upload now ? Yes. Apologies for any possible ambiguity, but that is indeed what I meant by: > > Please feel free to go ahead. Regards, Adam
Bug#985402: libgconf-2-4: found segmentation fault
Hello Antonio, this directory should contain a file: /etc/gconf/2/path The content should most probably what is shown here: https://sources.debian.org/src/gconf/3.2.6-7/debian/default.path/ (And can be downloaded in the upper right corner.) Kind regards, Bernhard Am 09.04.21 um 15:26 schrieb Antonio: The path "/etc/gconf/2" is empty: totale 8 drwxr-xr-x 2 root root 4096 1 mar 15.36 . drwxr-xr-x 6 root root 4096 1 mar 15.36 .. However, even if I remove it or remove "/etc/gconf" occurs the same problem. I note if I remove the entire directory "usr/share/GConf/gsettings" then the bug does not occur, but it does not seem to be related to a specific file: just remains one file that the problem returns.
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
Hello, I've already added fixed tag to original bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645 Does it mean that I can upload now ? Thank you, Michal Arbet (kevko) Dne pá 9. 4. 2021 18:42 uživatel Adam D. Barratt napsal: > Control: close 986645 2.0.0-1 > Control: tags -1 -moreinfo +confirmed > > On Fri, 2021-04-09 at 18:33 +0200, Michal Arbet wrote: > > First Debian uploaded version where patch was included was/is 2.0.0-1 > > which is also version currently in sid as you can see in changelog > > below > > > > > https://salsa.debian.org/python-team/packages/dnspython/-/blob/debian/master/debian/changelog > > > > OK, then let's do as I requested originally, and tell the BTS that (as > above). > > Please feel free to go ahead. > > Regards, > > Adam > >
Bug#986696: ITP: ohai -- Detects data about your operating system and reports it in JSON
Package: wnpp Severity: wishlist Owner: Pirate Praveen Packaging of ohai gem from https://packagecloud.io/cinc-project/stable since chef is removed due to trademark issues https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 and cinc is a fork of chef without the trademark issues.
Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows
Hello Russel, thanks for the fast answer, unfortunately the backtrace is not yet enough expressive. Maybe you could also install the following debug symbol packages? libqt5qml5-dbgsym libqt5core5a-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym kwin-common-dbgsym kwin-x11-dbgsym These are located in a separate debug symbol repository, which has to be enabled first and is described here: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols Kind regards, Bernhard [KCrash Handler] #4 0x7f42259bee08 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #5 0x7f4225acd3cc in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #6 0x001e0009 in ?? () #7 0x55623023d9d0 in ?? () #8 0x7f421a2d in ?? () #9 0x556230c214a0 in ?? ()
Bug#986695: prometheus-mongodb-exporter: MongoDB exporter segfaults when connecting with relatively recent MongoDB databases
Package: prometheus-mongodb-exporter Version: 1.0.0+git20180522.e755a44-1+b20 Severity: grave Tags: upstream Justification: renders package unusable Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Paragoumba To: Debian Bug Tracking System Subject: prometheus-mongodb-exporter: Mongodb Exporter segfaults with new versions of MongoDB Message-ID: <161798894396.8376.16006048479438587500.report...@5h4d0w-tp.pulseheberg.com> X-Mailer: reportbug 7.5.3~deb10u1 Date: Fri, 09 Apr 2021 19:22:23 +0200 Package: prometheus-mongodb-exporter Version: 1.0.0+git20180522.e755a44-1+b20 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, * What led up to the situation? I tried to install prometheus-mongodb-exporter to export statistics about my MongoDB instance. After multiple attempt to make it connect to the database, I stopped the systemd service and ran it by hand and noticed it segfaults upon connecting. * What exactly did you do (or not do) that was effective (or ineffective)? I checked multiple times the config and that proved to be ineffective. The problem doesn't come from a faulty configuration. The package is incompatible with the newer versions of MongoDB * What was the outcome of this action? It still segfaults * What outcome did you expect instead? I expect the software to connect successfully and export data It appears that the upstream github repository (https://github.com/dcu/mongodb_exporter) from which this package is built hasn't been updated in two years. This other repo (https://github.com/percona/mongodb_exporter) contains the same sources but is actively maintained. I know it's not unusual for the Debian packages to be several version late but this version is completely unusable and the only solution for now is to not use the package in the Debian repositories and to install it from source. -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prometheus-mongodb-exporter depends on: ii daemon 0.6.4-1+b2 ii libc6 2.28-10 prometheus-mongodb-exporter recommends no packages. prometheus-mongodb-exporter suggests no packages. -- Configuration Files: /etc/default/prometheus-mongodb-exporter changed [not included] -- debconf-show failed -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prometheus-mongodb-exporter depends on: ii daemon 0.6.4-1+b2 ii libc6 2.28-10 prometheus-mongodb-exporter recommends no packages. prometheus-mongodb-exporter suggests no packages. -- Configuration Files: /etc/default/prometheus-mongodb-exporter changed [not included] -- debconf-show failed
Bug#985197: kwin-wayland: Drag and drop a file in Dolphin makes KDE Plasma Wayland crash
Hello Silvério, Reading symbols from /usr/bin/kwin_wayland... (No debugging symbols found in /usr/bin/kwin_wayland) BFD: warning: /tmp/user/1000/coredump-ySV5m6 is truncated: expected core file size >= 2365169664, found: 2147483648 it looks like for some reason the kwin_wayland exceeds the address space limit of systemd-coredump, therefore the results are not good. If you want to give it another try, then please uncomment and raise this limit from e.g. 2GB to 3GB like this: /etc/systemd/coredump.conf ... ProcessSizeMax=3G ExternalSizeMax=3G ... systemctl daemon-reload Then the size warning hopefully goes away on the next attempt, and a better backtrace might be printed. Kind regards, Bernhard
Bug#985402: libgconf-2-4: found segmentation fault
Hello Antonio, thank you for the detailed informations. Am 01.04.21 um 19:15 schrieb Antonio: $ gdb gsettings-data-convert Starting program: /usr/bin/gsettings-data-convert (gsettings-data-convert:4756): GConf-CRITICAL **: 19:00:31.514: gconf_engine_get_local_for_addresses: assertion 'addresses != NULL' failed I guess the above line is causing the issue, which results in "client->engine" being a null pointer [1] [2]. The interesting function for the addresses seems to be get_writable_client [3]. It looks like upstream applied a patch to exit the process immediately in the case of addresses being a null pointer. Therefore is just the question left why get_writable_source_path/gconf_load_source_path returns a null pointer... Which leads to the question what the content of this path might be: /etc/gconf/2 Kind regards, Bernhard Thread 1 "gsettings-data-" received signal SIGSEGV, Segmentation fault. gconf_engine_get_entry (conf=0x0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", locale=0x77b70b6e <_nl_C_name> "C", use_schema_default=use_schema_default@entry=1, err=err@entry=0x7fffde60) at gconf-dbus.c:1293 1293 gconf-dbus.c: File o directory non esistente. (gdb) bt #0 gconf_engine_get_entry (conf=0x0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", locale=0x77b70b6e <_nl_C_name> "C", use_schema_default=use_schema_default@entry=1, err=err@entry=0x7fffde60) at gconf-dbus.c:1293 #1 0x77f4d7a6 in get (client=client@entry=0xd2a0, key=0x555917d0 "/system/pulseaudio/modules/combine/args0", use_default=0, error=error@entry=0x7fffde60) at gconf-client.c:1493 #2 0x77f4ee93 in gconf_client_get_full (client=client@entry=0xd2a0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", use_schema_default=use_schema_default@entry=0, err=err@entry=0x7fffdef8, locale=0x0) at gconf-client.c:1543 #3 0x77f4efbf in gconf_client_get_without_default (client=client@entry=0xd2a0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", err=err@entry=0x7fffdef8) at gconf-client.c:1605 #4 0x715d in handle_file (filename=filename@entry=0x5556b490 "/usr/share/GConf/gsettings/pulseaudio.convert") at gsettings-data-convert.c:214 #5 0x6912 in handle_dir (converted=0xc980, stored_mtime=0, dirname=0x5556a3e0 "/usr/share/GConf/gsettings") at gsettings-data-convert.c:436 #6 main (argc=, argv=) at gsettings-data-convert.c:670 [1] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gconf/gconf-dbus.c#L1293 [2] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gconf/gconf-client.c#L1491 [3] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gsettings/gsettings-data-convert.c#L98 [4] https://gitlab.gnome.org/Archive/gconf/-/commit/98ff7acca7595f508b094506195aeffaf2e8b74c
Bug#986694: sbuild: unshare: allow access to local repositories or bind mounting additional directories
Package: sbuild Version: 0.81.2 Severity: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, I'm currently using sbuild with the unshare chroot backend with a local repository. Currently this means running a webserver and pointing sbuilds mirror at localhost, this is annoying and unnecessary. It would be nice if sbuild with the unshare backend would support a filesystem mirror or bind mounting arbitrary paths into the chroot. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_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:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages sbuild depends on: ii adduser 3.118 ii libsbuild-perl 0.81.2 ii perl5.32.1-3 Versions of packages sbuild recommends: ii autopkgtest 5.16 ii debootstrap 1.0.123 ii schroot 1.6.10-12 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.46.2-1 ii kmod 28-1 ii wget 1.21-1+b1 -- no debconf information
Bug#986693: sbuild: unshare chroot: support unsharing network
Package: sbuild Version: 0.81.2 Severity: wishlist Justification: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, Please add support to the unshare chroot backend to unshare the network namespace. As per debian policy v4.5.1.0 https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules: > For packages in the main archive, no required targets may attempt network > access, except, via the loopback interface, to services on the build host > that have been started by the build. For these and similar scenarios It would be useful if sbuild unshare could be configured to prevent network access except for the loopback interface, by unsharing the network namespace and bringing up the loopback interface while still root. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_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:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages sbuild depends on: ii adduser 3.118 ii libsbuild-perl 0.81.2 ii perl5.32.1-3 Versions of packages sbuild recommends: ii autopkgtest 5.16 ii debootstrap 1.0.123 ii schroot 1.6.10-12 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.46.2-1 ii kmod 28-1 ii wget 1.21-1+b1 -- no debconf information
Bug#896067: Constitution A.6 - "V(A,D) is strictly great"
Hi all I have changed the constitution files in the website repo to match the updated text currently now in doc-debian package: https://salsa.debian.org/webmaster-team/webwml/-/commit/e3d525d9f092f9014e00417cc847900ac5a99649 The fix will be available online after the next build. I didn't close the bug because I don't know if a decision has been taken about which one of the two sources (website repo or debian-doc package repo) should be the "canonical" one. In my opinion, the website, but I'm biased of course :-) Kind regards, El 4/4/21 a las 11:05, Kurt Roeckx escribió: > On Sun, Apr 04, 2021 at 09:31:46AM +0200, Niels Thykier wrote: >> Hi, >> >> In https://www.debian.org/devel/constitution#item-A, there is the >> following sentence under A.6. bullet 3.2.: >> >>> An option A defeats the default option D by a majority ratio N, if V(A,D) >>> is greater or equal to N * V(D,A) and V(A,D) is strictly great >> >> The "... and V(A,D) is strictly great" looks like an incomplete >> sentence. Is that something we can fix as an editorial correction (i.e. >> without a vote)? > > See #896067. > > > Kurt > -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
Control: close 986645 2.0.0-1 Control: tags -1 -moreinfo +confirmed On Fri, 2021-04-09 at 18:33 +0200, Michal Arbet wrote: > First Debian uploaded version where patch was included was/is 2.0.0-1 > which is also version currently in sid as you can see in changelog > below > > https://salsa.debian.org/python-team/packages/dnspython/-/blob/debian/master/debian/changelog > OK, then let's do as I requested originally, and tell the BTS that (as above). Please feel free to go ahead. Regards, Adam
Bug#985402: Fwd: Bug#985402: libgconf-2-4: found segmentation fault
[ ! -f "/etc/gconf/2/path" ] && cp -a "/usr/share/gconf/default.path" "/etc/gconf/2/path" Il 09/04/21 16:12, Antonio ha scritto: I confirm that by downloading this file and copying it as "/etc/gconf/2/path" the bug is solved. I had already noticed the check of this file via strace. I think the post-installation script, of the package gconf2-common, should be changed so that if there is no file "/etc/gconf/2/path" then execute the copy from "/usr/share/gconf/default.path" (provided from this package, the same as what I downloaded): [ -f "/etc/gconf/2/path" ] && cp -a "/usr/share/gconf/default.path" "/etc/gconf/2/path" This would avoid bug for those who do not have this file (whatever the reason for his absence). Thanks, Bernhard
Bug#986692: crash at startup
here the backtrace Type "apropos word" to search for commands related to "word"... Reading symbols from numptyphysics... Reading symbols from /usr/lib/debug/.build-id/1c/669beb5cdc6578b37b1e53e575baefe21524ff.debug... (gdb) r Starting program: /usr/games/numptyphysics [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x762e7700 (LWP 724966)] Thread 1 "numptyphysics" received signal SIGSEGV, Segmentation fault. 0x779f308f in _Unwind_Resume () from /lib/x86_64-linux-gnu/libgcc_s.so.1 (gdb) l 118 OsFreeDesktop.cpp: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x779f308f in _Unwind_Resume () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #1 0x55560c58 in __gnu_cxx::new_allocator::~new_allocator (this=, __in_chrg=) at /usr/include/c++/10/ext/new_allocator.h:89 #2 std::allocator::~allocator (this=, __in_chrg=) at /usr/include/c++/10/bits/allocator.h:162 #3 std::__cxx11::basic_string, std::allocator >::_Alloc_hider::~_Alloc_hider (this=out>, __in_chrg=) at /usr/include/c++/10/bits/basic_string.h:150 #4 std::__cxx11::basic_string, std::allocator >::~basic_string (this=, __in_chrg=) at /usr/include/c++/10/bits/basic_string.h:658 #5 Levels::addLevel (this=, file="/usr/share/numptyphysics/L99_Gravity_Test.nph", rank=99, index=-1) at Levels.cpp:117 #6 0x555682f1 in Levels::addPath (this=0x5560cff0, path=0x555f3ef0 "/usr/share/numptyphysics/L99_Gravity_Test.nph") at Levels.cpp:93 #7 0x55568070 in Levels::addPath (this=this@entry=0x5560cff0, path=path@entry=0x5559ba6a "/usr/share/numptyphysics") at /usr/include/c++/10/bits/basic_string.h:186 #8 0x55575214 in App::runGame (height=480, width=800, files=..., this=0x7fffdfe0) at App.cpp:184 #9 App::run (this=0x7fffdfe0) at App.cpp:110 #10 0x55573726 in npmain (argc=argc@entry=1, argv=argv@entry=0x7fffe1b8) at App.cpp:372 #11 0x55562c0b in main (argc=1, argv=0x7fffe1b8) at OsFreeDesktop.cpp:133
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
First Debian uploaded version where patch was included was/is 2.0.0-1 which is also version currently in sid as you can see in changelog below https://salsa.debian.org/python-team/packages/dnspython/-/blob/debian/master/debian/changelog Cheers, Michal Dne pá 9. 4. 2021 17:58 uživatel Adam D. Barratt napsal: > On Fri, 2021-04-09 at 17:26 +0200, Michal Arbet wrote: > > Fistly thank you for quick response. > > > > In unstable there is python3-dnspython in version 2.0.0-1 which has > > this patch already included. > > Source code for dnspython 2.0.0 on github -> > > https://github.com/rthalley/dnspython/blob/v2.0.0/dns/query.py#L947-L948 > > So, unstable has it *fixed already*. > > OK, thanks for confirming that. Do you know which upload to Debian the > patch was first included in? > > Regards, > > Adam > >
Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6
Hi Andreas, On 09-04-2021 10:50, Andreas Tille wrote: > On Thu, Apr 08, 2021 at 10:02:02PM +0200, Paul Gevers wrote: >> On 08-04-2021 21:52, Andreas Tille wrote: >>> Ahhh, I assumed that basic autopkgtest-pkg-r is consider superficial. >> >> That's an interesting point. Should they (they're not)? Maybe with R >> packages autopkgtest-pkg-r may or may not be very extensive? If that's >> true, than it's currently basically up to individual packages to mark >> themselves superficial when using autopkgtest-pkg-r. > > We are working on it makeing them non-superficial. Its the case for > r-bioc-* currently[1] and the plan is to do this for all R packages. Aha, so non r-bioc-* packages are superficial at this moment. > However, this is for the next release. Marking those packages > superficial that do not come with a proper test can be done as well, > but not in the current freeze period. I'll think about what this means for the Release Team. Normally when I learn of packages that try to migrate to testing with superficial tests not marked as such I would add a manual block. Maybe I'll see if I can generate such a list for all autopkgtest-pkg-r using packages (without bioc in the name). Thanks for letting us know. And yes, please fix this. While typing this, I have one suggestion, we should make autopkgtest-pkg-r skippable and pkg-r-autopkgtest should exit 77 if there's no hook nor any tests to run (and without bioc currently). The overall result of skipped tests is equal to successful tests marked as superficial. I believe we can/could/should very well do that now in the freeze, after we fix autodep8. What do you think? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983865: [l10n-de] unbenutzte Variable ... verwandt
Hello Guilllem, On Thu, Apr 08, 2021 at 10:49:17PM +0200, Guillem Jover wrote: > On Thu, 2021-04-08 at 19:49:42 +0200, Helge Kreutzmann wrote: > > Done (locally); any specific commit message requested? > > Great, thanks. Hmm typo or other similar translation fixes do not have > a standardized format, so use whatever you feel like with a "po: " > prefix for now as I'll have to massage it manually when generating the > debian/changelog no matter what. > > Depending on whether the change was integrated as is, or not you might > want to use --author to set proper attribution, otherwise perhaps one of > the other meta-fields might make more sense (from the list at > https://wiki.debian.org/Teams/Dpkg/GitUsage). I used the exmple with "Closes:" --author is not appropriate, because in the end I did not use the specific version proposed. Also I fixed a few other typos as well. I was able to push it just now, so it is in the repository. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#986692: crash at startup
Package: numptyphysics Version: 0.2+svn157-0.4 Severity: grave X-Debbugs-Cc: pi...@debian.org the prgram do not start and crash at startup -- System Information: Debian Release: bullseye/sid APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages numptyphysics depends on: ii fonts-femkeklaver1.0-3 ii libc62.31-11 ii libfontconfig1 2.13.1-4.2 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libsdl-image1.2 1.2.12-12 ii libsdl-ttf2.0-0 2.0.11-6 ii libsdl1.2debian 1.2.15+dfsg2-6 ii libstdc++6 10.2.1-6 ii libx11-6 2:1.7.0-2 ii zlib1g 1:1.2.11.dfsg-2 numptyphysics recommends no packages. numptyphysics suggests no packages. -- no debconf information
Bug#986671: aoe-sancheck and interface names
Control: tags 986671 confirmed upstream Control: severity 986671 important Control: forward 986671 https://github.com/OpenAoE/aoetools/issues/6 Adi Kriegisch wrote... > we recently tested aoe on a newly created bullseye test system and noticed > that aoe-sancheck did not detect any interfaces. Up to now, we used bios > device names and had no problems with this whatsoever but the test system > uses the default interface names (enp*). Just in case, adding "net.ifnames=0" to the kernel command line restores the old behaviour - but I understand there are various reasons, up to and including layer 9, to not do that. > Looking into the source revealed that "eth" is hardcoded in aoe-sancheck.c > to find valid interfaces. Yeah, that doesn't make much sense nowadays. The code really should probe the interface's capabilities instead, I've made a suggestion in the related upstream bug. > The trivial patch attached fixes the issue while still being able to > correctly identify old interface names as well. > We'd be very glad if this patch could still make it into bullseye... ;-) Understood. I'll see what upstream will do about that, quite frankly, your patch is rather last resort - and I know we're in a time frame here. Christoph signature.asc Description: PGP signature
Bug#889290: If NTP is installed, then systemd-timesyncd should be disabled.
Control: fixed -1 systemd 245.4-2 Control: fixed -1 ntp 1:4.2.8p14+dfsg-2 Hi, On Mon, 18 Nov 2019 18:16:58 +0100 Daniel Swarbrick wrote: > I am also witnessing multiple hosts where ntp is failing to start, > however the disable-with-time-daemon.conf file /is/ present on these > systems: > > $ dpkg -S disable-with-time-daemon.conf > systemd: > /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf > > System is buster 10.2, systemd package version 241-7~deb10u2. > > And it is clearly doing what it should: > > $ systemctl status systemd-timesyncd > ● systemd-timesyncd.service - Network Time Synchronization > Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; > enabled; vendor preset: enabled) >Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d > └─disable-with-time-daemon.conf > Active: inactive (dead) > Condition: start condition failed at Mon 2019-11-18 15:38:08 UTC; 1h > 26min ago > Docs: man:systemd-timesyncd.service(8) > > Nov 18 15:38:08 lhr-ceph02 systemd[1]: Condition check resulted in > Network Time Synchronization being skipped. > > However, ntp does not start, and doesn't even appear to log any errors. > I'm wondering if it's a race condition, caused by this in the ntp unit file: > > Conflicts=systemd-timesyncd.service > > But I would sort of expect a failure message to be logged. I have tried > to replicate the setup in a VM, however there, ntp is starting as it > should - making me suspect a race condition even more. > > On Thu, 1 Nov 2018 03:42:03 -0700 Rick Thomas wrote: > > > Hmmm… > > > > It appears that the systemd package in stretch (9.5) has a patch for > this: > > > /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf > > > > But this is not present in buster. I believe this is fixed now since ntp and systemd-timesyncd are not conistallable. Cheers, Balint
Bug#986691: smarty3: PHP syntax error in /usr/share/php/smarty3/sysplugins/smarty_security.php
Package: smarty3 Version: 3.1.31+20161214.1.c7d42e4+selfpack1-2+deb9u2 Severity: important Dear Maintainer, In the last update on Stretch, there is a PHP syntax error in the /usr/share/php/smarty3/sysplugins/smarty_security.php file: a semicolon is missing at the end of line 531. This is causes a fatal PHP error for any software using this library. -- System Information: Debian Release: 9.13 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-14-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages smarty3 depends on: ii php 1:7.0+49 ii php-cli 1:7.0+49 ii php-common1:49 ii php7.0 [php] 7.0.33-0+deb9u10 ii php7.0-cli [php-cli] 7.0.33-0+deb9u10 smarty3 recommends no packages. smarty3 suggests no packages. -- no debconf information
Bug#986683: shim-signed-common: /usr/sbin/update-secureboot-policy ignores unknown arguments
Package: shim-signed-common Version: 1.33+15+1533136590.3beb971-7 Severity: normal Dear Maintainer, the script /usr/sbin/update-secureboot-policy ignores unknown arguments. But there are scripts which call it with other arguments. (--new-key and --enroll-key in vboxdrv.sh from oracle virtualbox (see in https://www.virtualbox.org/changeset/79186/vbox)). One such call managed to block a command on my computer, so it was running forever and blocking manual started related commands. (Looking as described in https://superuser.com/questions/1493050/update- secureboot-policy-enroll-key-running-on-every-new-startup-eating-reso , but my key was already registered manually.) Could you please abort show an error message on unsupported arguments? My work around is to add a wrapper script around /usr/sbin/update-secureboot- policy which aborts on unsupported arguments with an error message. So the script should not hang anymore, and hopefully log a nice error message. Currently my compiled kernel modules are signed again, maybe because of the wrapper, maybe already since I killed the hanging process. Thank you very much for your work. Greetings, Simon -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages shim-signed-common depends on: ii debconf [debconf-2.0] 1.5.71 ii mokutil0.3.0+1538710437.fb6250f-1 shim-signed-common recommends no packages. shim-signed-common suggests no packages. -- debconf information: shim/error/secureboot_key_mismatch: shim/enable_secureboot: false shim/title/secureboot: * shim/disable_secureboot: false * shim/error/bad_secureboot_key: * shim/secureboot_explanation:
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
On Fri, 2021-04-09 at 17:26 +0200, Michal Arbet wrote: > Fistly thank you for quick response. > > In unstable there is python3-dnspython in version 2.0.0-1 which has > this patch already included. > Source code for dnspython 2.0.0 on github -> > https://github.com/rthalley/dnspython/blob/v2.0.0/dns/query.py#L947-L948 > So, unstable has it *fixed already*. OK, thanks for confirming that. Do you know which upload to Debian the patch was first included in? Regards, Adam
Bug#820310: dh_lintian doesn't copy overrides for automatic -dbgsym packages
Hi, Marga Manterola (2016-04-07): > On Thu, Apr 7, 2016, 19:18 Niels Thykier wrote: > > > What tags are you observing with your dbgsym packages? Ideally the > > debhelper generated packages should be fully policy compliant with no > > lintian warnings (provided you use an up to date lintian). > > > > It was an internal package that shipped binaries that had been > pre-compiled, thus missing debugging symbols (the .debug files did > have the strings though, as the original binaries were unstripped). I'm seeing the same issue on buster when preparing a customer's package that relies on an external supplier's shared object that's unstripped initially but doesn't seem to output anything interesting in the auto -dbgsym package. I resorted to manually creating this directory and shipping the debian/my-package-dbgsym.lintian-overrides through a dh_lintian override: debian/.debhelper/my-package/dbgsym-root/usr/share/lintian/overrides/ Looking at https://sources.debian.org/ it seems some other maintainers have tried stashing such a debian/their-package-dbsym.lintian-overrides in their source tree… ;) Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#986690: triplane FTCBFS -- executes dksbuild during build
Package: triplane Version: 1.0.8-3 Severity: normal Tags: patch X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org Dear Maintainer, Since bioawk seems to execute dksbuild in order to generate data in fokker.dks which is not allowed during cross build it could be simply built with build compiler Since fokker.dks binary is not being installed, such a compilation would not give any exec format problems. And building it via build compiler does not seem a problem I'm attaching my patch along, and will commit to salsa if it looks good. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- a/Makefile +++ b/Makefile @@ -2,6 +2,7 @@ DESTDIR ?= CXX ?= g++ +CXX_FOR_BUILD ?= g++ OPTIFLAG = -O2 -g SDL_CONFIG ?= sdl-config VERSION = 1.0.8 @@ -73,7 +74,7 @@ $(CXX) -o $@ $(CFLAGS) $(LDFLAGS) $^ $(LIBS) tools/dksbuild: src/tools/dksbuild/dksbuild.cc - $(CXX) -o tools/dksbuild -g src/tools/dksbuild/dksbuild.cc + $(CXX_FOR_BUILD) -o tools/dksbuild -g src/tools/dksbuild/dksbuild.cc install: mkdir -p $(DESTDIR)$(PREFIX)/games signature.asc Description: PGP signature
Bug#986689: [PATCH] gnome-nettool: SVG icon is invalid
Package: gnome-nettool Version: 3.8.1-3 Severity: minor Tags: patch The gnome-nettool SVG icon is invalid and therefore no longer shown in the current GNOME release. The attached patch fixes this issue. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-nettool depends on: ii bind9-dnsutils [dnsutils] 1:9.16.13-1 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii dnsutils 1:9.16.13-1 ii finger 0.17-17 ii iputils-ping [ping] 3:20210202-1 ii iputils-tracepath 3:20210202-1 ii libc6 2.31-11 ii libcairo2 1.16.0-5 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-3 ii libgtop-2.0-11 2.40.0-2 ii libpango-1.0-0 1.46.2-3 ii net-tools 1.60+git20181103.0eebece-1 ii nmap 7.91+dfsg1+really7.80+dfsg1-2 ii whois 5.5.8 gnome-nettool recommends no packages. gnome-nettool suggests no packages. -- no debconf information From 217075331273b06b119b6d1cf36728b2b7466fc2 Mon Sep 17 00:00:00 2001 From: Ronny Standtke Date: Fri, 9 Apr 2021 00:06:24 +0200 Subject: [PATCH] fixed broken SVG icon --- pixmaps/icons/scalable/apps/gnome-nettool.svg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pixmaps/icons/scalable/apps/gnome-nettool.svg b/pixmaps/icons/scalable/apps/gnome-nettool.svg index 06de271..efaa25c 100644 --- a/pixmaps/icons/scalable/apps/gnome-nettool.svg +++ b/pixmaps/icons/scalable/apps/gnome-nettool.svg @@ -7,7 +7,7 @@ xmlns:svg="http://www.w3.org/2000/svg; xmlns="http://www.w3.org/2000/svg; xmlns:xlink="http://www.w3.org/1999/xlink; - xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/s odipodi-0.dtd" + xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd; xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape; width="48px" height="48px" -- 2.30.2
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
Hello Adam, Fistly thank you for quick response. In unstable there is python3-dnspython in version 2.0.0-1 which has this patch already included. Source code for dnspython 2.0.0 on github -> https://github.com/rthalley/dnspython/blob/v2.0.0/dns/query.py#L947-L948 So, unstable has it *fixed already*. I've just taken this tiny fix and patched buster 1.16.0-1 version. Cheers, Michal Arbet (kevko) pá 9. 4. 2021 v 13:54 odesílatel Adam D. Barratt napsal: > Control: tags -1 + moreinfo > > On Fri, 2021-04-09 at 12:51 +0200, Michal Arbet wrote: > > This python library breaks creation of secondary zone in > > Openstack's designate project included in buster. > > > > This is known issue and already fixed in upstream. > > > > Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645 > > > > The metadata of that bug indicates that it also affects the package in > unstable and is not yet fixed there. Is that correct? If so, the issue > needs to be fixed in unstable first; otherwise, please add an > appropriate "fixed" version so that the BTS knows which versions are > actually affected. > > Regards, > > Adam > >
Bug#985739: unblock: krb5/1.18.3-5
Control: tags 986051 confirmed moreinfo Hi Sam, On Sun, Mar 28, 2021 at 02:13:29PM -0400, Sam Hartman wrote: > [ Reason ] > In #985739 it was pointed out that internal symbols disappeared from > libk5crypto. > My bad; I noticed this, confirmed they were not externally visible, approved > the symbols file change, but didn't think about the upgrade implications. > > What happens is that if the new libk5crypto3 is unpacked before the > new libkrb5-3, the old libkrb5-3 breaks. In the bug, the user managed > to get into a position where pam_krb5 was broken and logins didn't > work. I was able to reproduce this issue with the following steps: I started from the debian-10-generic-amd64-20210208-542.qcow2 buster cloud image, and made sure root was able to login on the console (by setting a password). After this, installing libk5crypto3 and libpam-modules from bullseye (and the dependencies pulled in by apt) triggers this issue. At that point, root is no longer able to log in on the console (I was able to login via ssh using a key). Installing libkrb5-3 from bullseye fixes the issue. The issue can also be triggered by installing libpam-krb5 (from buster), and only upgrading libk5crypto3 to bullseye. > So, update the breaks, or add an equals binary:Version depends, no big, right? > > While I wasn't looking, krb5 has apparently become part of > pseudo-essential. > login->libpam-modules->libnsl->libtirpc3->libgssapi-krb5-2->libk5crypto3|libkrb5-3 > The only reason I even know that is because I've been tracking pam. > > Long term, we don't want that. > > As a result, it's probably the case in #985739 that pam_unix is broken as > well as pam_krb5. > > I'm not really an expert on all the ways that dependency resolution > gets complex for essential packages. I do know that dependencies for > essential packages are supposed to be pre-depends. That's not > currently the case for anything in krb5, or for libkeyutils, > libcomerr-2, etc. > > So, we have a few options. > > 1) Add the breaks. Things are fairly stable in this part of the > dependency graph; it was 2016 when libk5crypto last had an > internally-incompatible break. That will probably work in practice. > > On #debian-devel, Adrian Bunk argues that it should be a versioned conflicts > not a break > because it's essential. I'm not sure--I think in most situations the > fact that you cannot unpack the breaking package without deconfiguring > the broken package means that apt will simply reorder things so that > libk5crypto3 comes before libkrb5-3 and all happens to be well with > the breaks. I did some tests with modified binaries with either the breaks or the conflicts. Both result in the same upgrade order. Looking at policy 7.4, the argument for conflicts could be that this is a case "that must prevent both packages from being unpacked at the same time, not just configured". https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts I don't know if there is any situation where apt/dpkg would unpack libk5crypto3 before libkrb5-3 if the breaks is present, so I don't know if it makes any difference in practice. Note that it's possible to install only libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 from bullseye on a buster system, and have a working system (note that I didn't test if kerberos is actually working in this case, as I don't have a kerberos setup). This means that I'm fairly confident that apt will be able to solve this issue without creating other breakage, by just upgrading these packages first (which it does in my tests). I would unblock an upload with either the breaks or the conflicts. > 2) Do we also want to add the pre-depends to krb5. I'm nervous adding > additional pre-depends this late in the process. > > 3) Do we want to add pre-depends to the entire dependency chain from > libpam-modules to libkeyutils|libcom-err2? I think this is > technically correct, but I am uncomfortable with it. I agree that adding pre-depends at this point doesn't sound like something that we should try. > 4) Do we want to do enough surgery to pam to avoid krb5 being > essential. With my pam hat on in January, I concluded it was too late > in the process for me to feel comfortable adequately testing a (not > yet developed) patch. That was before I realized how big of a deal it > might be that krb5 had become essential. > The solution basically involves making pam_unix dlopen its dependencies for > nis rather than link-time dependencies. So, ugly games with c macros or > wrappers trying to get some internally typed NIS APIs right. > I definitely do not have time to develop the patch, although I could > potentially make time to review and help test. > I consider this risky for bullseye. I agree here as well. > I think my recommendation is go approve the breaks change, and hope that's > good enough in practice. OK. Please remove the moreinfo tag from the unblock bug when the
Bug#986688: libpam-fscrypt: fscrypt : default PAM config prevents pulseaudio from starting up on encrypted home directory
Package: libpam-fscrypt Version: 0.2.9-1+b3 Severity: important Dear Maintainer, If you encrypt your home directory and then log into it using PAM-fscrypt, pulseaudio won't start. Fix is to edit file /usr/share/pam-configs/fscrypt and set the priority to 252. Could you please integrate the fix in libpam-fscrypt package ? More info : https://github.com/google/fscrypt/issues/270 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-fscrypt depends on: ii fscrypt 0.2.9-1+b3 ii libc6 2.31-11 ii libpam0g 1.4.0-7 libpam-fscrypt recommends no packages. libpam-fscrypt suggests no packages.
Bug#986286: diaspora-installer: fails to install: Your bundle is locked to mimemagic (0.3.5), but that version could not be found
Control: forwarded -1 https://github.com/diaspora/diaspora/issues/8229 On Fri, 02 Apr 2021 14:21:14 +0200 Andreas Beckmann > Fetching gem metadata from https://gems.diasporafoundation.org/.. > Fetching gem metadata from https://rubygems.org/.. > [ESC][31mYour bundle is locked to mimemagic (0.3.5), but that version could not be found > in any of the sources listed in your Gemfile. If you haven't changed sources, > that means the author of mimemagic (0.3.5) has removed it. You'll need to update > your bundle to a version other than mimemagic (0.3.5) that hasn't been removed > in order to install.[ESC][0m > dpkg: error processing package diaspora-installer (--configure): A lot of projects are affected by this change, https://www.theregister.com/2021/03/25/ruby_rails_code/
Bug#985402: libgconf-2-4: found segmentation fault
I confirm that by downloading this file and copying it as "/etc/gconf/2/path" the bug is solved. I had already noticed the check of this file via strace. I think the post-installation script, of the package gconf2-common, should be changed so that if there is no file "/etc/gconf/2/path" then execute the copy from "/usr/share/gconf/default.path" (provided from this package, the same as what I downloaded): [ -f "/etc/gconf/2/path" ] && cp -a "/usr/share/gconf/default.path" "/etc/gconf/2/path" This would avoid bug for those who do not have this file (whatever the reason for his absence). Thanks, Bernhard Il 09/04/21 15:48, Bernhard Übelacker ha scritto: Hello Antonio, this directory should contain a file: /etc/gconf/2/path The content should most probably what is shown here: https://sources.debian.org/src/gconf/3.2.6-7/debian/default.path/ (And can be downloaded in the upper right corner.) Kind regards, Bernhard Am 09.04.21 um 15:26 schrieb Antonio: The path "/etc/gconf/2" is empty: totale 8 drwxr-xr-x 2 root root 4096 1 mar 15.36 . drwxr-xr-x 6 root root 4096 1 mar 15.36 .. However, even if I remove it or remove "/etc/gconf" occurs the same problem. I note if I remove the entire directory "usr/share/GConf/gsettings" then the bug does not occur, but it does not seem to be related to a specific file: just remains one file that the problem returns.
Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows
On Friday, 9 April 2021 19:57:40 AEST Bernhard Übelacker wrote: > Hello Russell, > could you still see this issue? Yes, here's a trace of one I just did for you! Application: KWin (kwin_x11), signal: Segmentation fault [KCrash Handler] #4 0x7f42259bee08 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #5 0x7f4225acd3cc in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #6 0x001e0009 in ?? () #7 0x55623023d9d0 in ?? () #8 0x7f421a2d in ?? () #9 0x556230c214a0 in ?? () #10 0x7f421a2d in ?? () #11 0x556230c214a0 in ?? () #12 0x7f4225b0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #13 0x556230c214a0 in ?? () #14 0x02c4 in ?? () #15 0x7f421a2d in ?? () #16 0x7fff507a42d0 in ?? () #17 0x7fff507a4238 in ?? () #18 0x7fff507a4590 in ?? () #19 0xf927f64bde692500 in ?? () #20 0x0080 in ?? () #21 0x0001 in ?? () #22 0x7fff507a4450 in ?? () #23 0x556230d27da0 in ?? () #24 0x556230274a30 in ?? () #25 0x7f4225aba83c in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #26 0x7f4225914460 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #27 0x7f422591464c in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #28 0x7f422595b4a6 in QV4::ExecutableCompilationUnit::linkToEngine(QV4::ExecutionEngine*) () from / usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #29 0x7f422595e3a3 in QV4::ExecutableCompilationUnit::instantiate(QV4::ExecutionEngine*) () from / usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #30 0x7f42259d11a9 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #31 0x7f4225a6caf2 in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*, int) () from /usr/lib/x86_64-linux-gnu/ libQt5Qml.so.5 #32 0x7f4225a6bf4f in QQmlObjectCreator::createInstance(int, QObject*, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #33 0x7f4225a6c8bf in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*, int) () from /usr/lib/x86_64-linux-gnu/ libQt5Qml.so.5 #34 0x7f4225a6bf4f in QQmlObjectCreator::createInstance(int, QObject*, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #35 0x7f4225a6e848 in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*) () from /usr/lib/x86_64-linux-gnu/ libQt5Qml.so.5 #36 0x7f4225a6ecf4 in QQmlObjectCreator::setupBindings(bool) () from /usr/ lib/x86_64-linux-gnu/libQt5Qml.so.5 #37 0x7f4225a6ac8b in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*) () from /usr/lib/x86_64-linux-gnu/ libQt5Qml.so.5 #38 0x7f4225a6bc55 in QQmlObjectCreator::createInstance(int, QObject*, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #39 0x7f4225a6e848 in QQmlObjectCreator::setPropertyBinding(QQmlPropertyData const*, QV4::CompiledData::Binding const*) () from /usr/lib/x86_64-linux-gnu/ libQt5Qml.so.5 #40 0x7f4225a6ecf4 in QQmlObjectCreator::setupBindings(bool) () from /usr/ lib/x86_64-linux-gnu/libQt5Qml.so.5 #41 0x7f4225a6ac8b in QQmlObjectCreator::populateInstance(int, QObject*, QObject*, QQmlPropertyData const*) () from /usr/lib/x86_64-linux-gnu/ libQt5Qml.so.5 #42 0x7f4225a6bc55 in QQmlObjectCreator::createInstance(int, QObject*, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #43 0x7f4225a6c8bf in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*, int) () from /usr/lib/x86_64-linux-gnu/ libQt5Qml.so.5 #44 0x7f42259fd89b in QQmlComponentPrivate::beginCreate(QQmlContextData*) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #45 0x7f42259fec7a in QQmlComponent::create(QQmlContext*) () from /usr/ lib/x86_64-linux-gnu/libQt5Qml.so.5 #46 0x7f42288a3553 in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5 #47 0x7f42288a40e2 in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5 #48 0x7f42288a4339 in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5 #49 0x7f4227431580 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #50 0x7f422743545a in QTimer::timeout(QTimer::QPrivateSignal) () from / usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #51 0x7f4227426ecf in QObject::event(QEvent*) () from /usr/lib/x86_64- linux-gnu/libQt5Core.so.5 #52 0x7f4227ebc15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #53 0x7f42273faf6a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #54 0x7f4227451883 in QTimerInfoList::activateTimers() () from /usr/lib/ x86_64-linux-gnu/libQt5Core.so.5 #55 0x7f422744fd17 in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #56 0x7f4220eb2b7e in ?? () from /usr/lib/x86_64-linux-gnu/ libQt5XcbQpa.so.5 #57 0x7f42273f992b in QEventLoop::exec(QFlags) () from /usr/lib/ x86_64-linux-gnu/libQt5Core.so.5 #58
Bug#986687: ITP: go-isemoji -- Go library to test if a string is an emoji.
Package: wnpp Severity: wishlist Owner: Micheal Waltz * Package name: go-isemoji Version : 1.1.0-1 Upstream Author : makeworld * URL : https://github.com/makeworld-the-better-one/go-isemoji * License : Expat Programming Lang: Go Description : Go library to test if a string is an emoji. Go package isemoji helps you determine whether a string is an emoji. -- Micheal Waltz https://keybase.io/ecliptik GPG Fingerprint: 5F70 F2AC BD58 F580 DF15 3D1F 4FA2 70F5 CD36 71F9 signature.asc Description: PGP signature
Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows
Hello Russell, could you still see this issue? Stack trace of thread 120123: #0 0x7f49c3823ce1 n/a (/lib/x86_64-linux-gnu/libc-2.31.so (deleted) + 0x3bce1) Were there more lines following in the "Stack trace of thread 120123"? And as libc-2.31 is shown as deleted, I assume this happened while libc package got updated while the kwin-x11 process was still using the previous version. Kind regards, Bernhard
Bug#986686: missing b-d netpbm?
Package: src:texworks-manual
Version: 20210308-1
Severity: minor
Tags: patch
On the Ubuntu buildd, the package ftbfs with a missing b-d. Adding netpbm fixes
this, although I don't yet see why it doesn't fail on the Debian buildds.
netpbm only shows as a Recommends in the Debian build log.
https://launchpad.net/ubuntu/+source/texworks-manual/20210308-1/+build/21339493
make[4]: Entering directory '/packages/tmp/texworks-manual-20210308/src/en/html'
Creating image images/MacCmdKey.eps (from ../images/MacCmdKey.pdf)
Creating image images/MacOptKey.eps (from ../images/MacOptKey.pdf)
Creating image images/interface-summary.eps (from
../images/interface-summary.pdf)
Creating image images/consoleOutput.eps (from ../images/consoleOutput.pdf)
Creating image images/errorParsingScript.eps (from
../images/errorParsingScript.pdf)
Creating image images/LMB.eps (from ../images/LMB.pdf)
Creating image images/RMB.eps (from ../images/RMB.pdf)
Creating image images/toolbar1.eps (from ../images/toolbar1.png)
# Some versions of convert refuse to produce .eps files due to security concerns
/bin/sh: 1: pnmtops: not found
Creating image images/toolbar2.eps (from ../images/toolbar2.png)
# Some versions of convert refuse to produce .eps files due to security concerns
/bin/sh: 1: pnmtops: not found
Creating image images/iconTypeset.eps (from ../images/iconTypeset.png)
# Some versions of convert refuse to produce .eps files due to security concerns
/bin/sh: 1: pnmtops: not found
Creating image images/iconAbortTypesetting.eps (from
../images/iconAbortTypesetting.png)
# Some versions of convert refuse to produce .eps files due to security concerns
/bin/sh: 1: pnmtops: not found
Creating image images/replaceDialog.eps (from ../images/replaceDialog.png)
# Some versions of convert refuse to produce .eps files due to security concerns
/bin/sh: 1: pnmtops: not found
Creating image images/screenshotHardWrapDlg.eps (from
../images/screenshotHardWrapDlg.png)
# Some versions of convert refuse to produce .eps files due to security concerns
/bin/sh: 1: pnmtops: not found
Creating image images/TeXworks.eps (from ../images/TeXworks.png)
# Some versions of convert refuse to produce .eps files due to security concerns
/bin/sh: 1: pnmtops: not found
Creating image images/Linux.eps (from ../images/Linux.pdf)
Creating image images/Mac.eps (from ../images/Mac.pdf)
Creating image images/Windows.eps (from ../images/Windows.pdf)
[...]
[13]) [14] [15] [16] (./firststeps.tex [17] [18]
Chapter 3.
(./index.tmp) (./index.tmp)
! Dimension too large.
\relax
l.13 ...egraphics[scale=.6]{toolbar1}\hspace{1em}}
?
! Emergency stop.
\relax
l.13 ...egraphics[scale=.6]{toolbar1}\hspace{1em}}
Output written on index.dvi (25 pages, 57568 bytes).
Transcript written on index.log.
make[4]: *** [Makefile:66: index.ind] Error 1
patch to add the b-d:
http://launchpadlibrarian.net/532676391/texworks-manual_20210308-1_20210308-1ubuntu1.diff.gz
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
On Fri, Apr 09, 2021 at 08:13:52AM -0400, Aaron M. Ucko wrote: > Don't worry, I am still looking into this crash, and had primarily > intended that comment as a public note to myself -- the crash occured > within a (presumably valid) call to ncbi-blast+, and wound up taking > quite a few tries to reproduce on the porterbox I was using (amdahl), so > once I finally obtained more details, I wanted to make very sure I > wouldn't be able to lose them. Sorry for any resulting confusion. Thanks a lot. Its very relieving to know a competent person behind this Andreas. -- http://fam-tille.de
Bug#985402: libgconf-2-4: found segmentation fault
The path "/etc/gconf/2" is empty: totale 8 drwxr-xr-x 2 root root 4096 1 mar 15.36 . drwxr-xr-x 6 root root 4096 1 mar 15.36 .. However, even if I remove it or remove "/etc/gconf" occurs the same problem. I note if I remove the entire directory "usr/share/GConf/gsettings" then the bug does not occur, but it does not seem to be related to a specific file: just remains one file that the problem returns. Il 09/04/21 15:03, Bernhard Übelacker ha scritto: Hello Antonio, thank you for the detailed informations. Am 01.04.21 um 19:15 schrieb Antonio: $ gdb gsettings-data-convert Starting program: /usr/bin/gsettings-data-convert (gsettings-data-convert:4756): GConf-CRITICAL **: 19:00:31.514: gconf_engine_get_local_for_addresses: assertion 'addresses != NULL' failed I guess the above line is causing the issue, which results in "client->engine" being a null pointer [1] [2]. The interesting function for the addresses seems to be get_writable_client [3]. It looks like upstream applied a patch to exit the process immediately in the case of addresses being a null pointer. Therefore is just the question left why get_writable_source_path/gconf_load_source_path returns a null pointer... Which leads to the question what the content of this path might be: /etc/gconf/2 Kind regards, Bernhard Thread 1 "gsettings-data-" received signal SIGSEGV, Segmentation fault. gconf_engine_get_entry (conf=0x0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", locale=0x77b70b6e <_nl_C_name> "C", use_schema_default=use_schema_default@entry=1, err=err@entry=0x7fffde60) at gconf-dbus.c:1293 1293 gconf-dbus.c: File o directory non esistente. (gdb) bt #0 gconf_engine_get_entry (conf=0x0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", locale=0x77b70b6e <_nl_C_name> "C", use_schema_default=use_schema_default@entry=1, err=err@entry=0x7fffde60) at gconf-dbus.c:1293 #1 0x77f4d7a6 in get (client=client@entry=0xd2a0, key=0x555917d0 "/system/pulseaudio/modules/combine/args0", use_default=0, error=error@entry=0x7fffde60) at gconf-client.c:1493 #2 0x77f4ee93 in gconf_client_get_full (client=client@entry=0xd2a0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", use_schema_default=use_schema_default@entry=0, err=err@entry=0x7fffdef8, locale=0x0) at gconf-client.c:1543 #3 0x77f4efbf in gconf_client_get_without_default (client=client@entry=0xd2a0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", err=err@entry=0x7fffdef8) at gconf-client.c:1605 #4 0x715d in handle_file (filename=filename@entry=0x5556b490 "/usr/share/GConf/gsettings/pulseaudio.convert") at gsettings-data-convert.c:214 #5 0x6912 in handle_dir (converted=0xc980, stored_mtime=0, dirname=0x5556a3e0 "/usr/share/GConf/gsettings") at gsettings-data-convert.c:436 #6 main (argc=, argv=) at gsettings-data-convert.c:670 [1] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gconf/gconf-dbus.c#L1293 [2] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gconf/gconf-client.c#L1491 [3] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gsettings/gsettings-data-convert.c#L98 [4] https://gitlab.gnome.org/Archive/gconf/-/commit/98ff7acca7595f508b094506195aeffaf2e8b74c
Bug#986037: kdenlive: crashes on audio setup
Am 07.04.21 um 16:16 schrieb Norbert Preining: Hi Patrick, good that you remind me of that ... Since (for myself?) this issue does not affect Debian bullseye downgrading the severity, because this release could not migrate then.. Fine with me. I actually found the problem, I guess I have to report it upstream: I have changed monitor and the new monitor has a higher resolution. Now what has happened that in the kdenliverc (.config/) there was a section [MainWindow] HDMI-A-0 Height 1080=1024 HDMI-A-0 Height 2048x1152=480 HDMI-A-0 Width 1920=1920 HDMI-A-0 Width 2048x1152=664 HDMI-A-0 Window-Maximized 1080x1920=true HDMI-A-0 XPosition=0 HDMI-A-0 XPosition 2048x1152=0 HDMI-A-0 YPosition=29 HDMI-A-0 YPosition 2048x1152=30 Height 1080=702 RestorePositionForNextInstance=false State=/wD9AQIAAAKYAAABN/wBD/sYAG4AbwB0AGUAcwBfAHcAaQBkAGcAZQB0AAD/ZwEAAAP7DgBsAGkAYgByAGEAcgB5AAD/ZwEAAAP7FABzAGMAcgBlAGUAbgBnAHIAYQBiAAD/YAEAAAP7GgBhAHUAZABpAG8AcwBwAGUAYwB0AHIAdQBtAQBmZgEAAAP7FgBwAHIAbwBqAGUAYwB0AF8AYgBpAG4BZwAAAGBgAQAAA/wAAADIiwAAAIsA+gEBAvsYAGUAZgBmAGUAYwB0AF8AcwB0AGEAYwBrAQD/VwEAAAP7HgBjAGwAaQBwAF8AcAByAG8AcABlAHIAdABpAGUAcwEA/wAAAFcBAAAD/n0AAAGAAAD6/wEC+wAAAB4AdAByAGEAbgBzAGkAdABpAG8AbgBfAGwAaQBzAHQAAP8AAABgAQAAA/sWAGUAZgBmAGUAYwB0AF8AbABpAHMAdAAA/wAAAGABAAAD/VQAAAFEAAABRAD6AQEC+wAAABgAYwBsAGkAcABfAG0AbwBuAGkAdABvAHIBAP8AAAFEAQAAA/seAHAAcgBvAGoAZQBjAHQAXwBtAG8AbgBpAHQAbwByAQD/AAABRAEAAAP7GAB1AG4AZABvAF8AaABpAHMAdABvAHIAeQAA/wAAAGABAAAD+woAbQBpAHgAZQByBlwAAAEkYwEAAAP7FgB2AGUAYwB0AG8AcgBzAGMAbwBwAGUAAP8AAAEyAQAAA/sQAHcAYQB2AGUAZgBvAHIAbQAA/wAAAKgBAAAD+wAAABQAcgBnAGIAXwBwAGEAcgBhAGQAZQAA/wAAAKQBAAAD+wAAABIAaABpAHMAdABvAGcAcgBhAG0AAP8AAAFKAQAAA/sSAFMAdQBiAHQAaQB0AGwAZQBzAAD/9AEAAAMAAAKYOAQECAj8AQICFgBtAGEAaQBuAFQAbwBvAGwAQgBhAHIBAP8AABgAZQB4AHQAcgBhAFQAbwBvAGwAQgBhAHIBAAACHv8AAA== ToolBarsMovable=Disabled Width 1920=1280 Window-Maximized 1080x1920=true eDP-1 Height 1080=702 eDP-1 Width 1920=1280 eDP-1 XPosition=640 eDP-1 YPosition=29 but the new monitor has different resolution (2560x1440) and with that monitor kdenlive simply crashed. Removing this section made kdenlive start up again. Looking into the newly generate kdenlive I actually don't see entries about eDP-1 HDMI-A-0 etc but only: [MainWindow] HDMI-A-0 Height 2048x1152=1020 HDMI-A-0 Width 2048x1152=1540 HDMI-A-0 XPosition 2048x1152=0 HDMI-A-0 YPosition 2048x1152=30 State=/wD9AQIAAAYEAAAByfwBD/sYAG4AbwB0AGUAcwBfAHcAaQBkAGcAZQB0AAD/ZwEAAAP7DgBsAGkAYgByAGEAcgB5AAD/ZwEAAAP7EgBTAHUAYgB0AGkAdABsAGUAcwAA/wAAAPQBAAAD+wAAABQAcwBjAHIAZQBlAG4AZwByAGEAYgAA/wAAAGABAAAD+wAAABoAYQB1AGQAaQBvAHMAcABlAGMAdAByAHUAbQAA/wAAAGYBAAAD+wAAABYAcAByAG8AagBlAGMAdABfAGIAaQBuAQDiYAEAAAP84wAAANwAAABgAPoAAQL7GABlAGYAZgBlAGMAdABfAHMAdABhAGMAawEA/wAAAGABAAAD+wAAAB4AYwBsAGkAcABfAHAAcgBvAHAAZQByAHQAaQBlAHMAAP8AAABgAQAAA/wAAAHBTwAAAIsA+gEBAvseAHQAcgBhAG4AcwBpAHQAaQBvAG4AXwBsAGkAcwB0AQD/BAEAAAP7FgBlAGYAZgBlAGMAdABfAGwAaQBzAHQBAP8EAQAAA/wAAAMQAAAC9UQA+gEBAvsYAGMAbABpAHAAXwBtAG8AbgBpAHQAbwByAQD/AAABRAEAAAP7HgBwAHIAbwBqAGUAYwB0AF8AbQBvAG4AaQB0AG8AcgEA/wAAAUQBAAAD+wAAABgAdQBuAGQAbwBfAGgAaQBzAHQAbwByAHkAAP8AAABgAQAAA/sKAG0AaQB4AGUAcgAA/wAAAGMBAAAD+wAAABYAdgBlAGMAdABvAHIAcwBjAG8AcABlAAD/AAABMgEAAAP7EAB3AGEAdgBlAGYAbwByAG0AAP8AAACoAQAAA/sUAHIAZwBiAF8AcABhAHIAYQBkAGUAAP8AAACkAQAAA/sSAGgAaQBzAHQAbwBnAHIAYQBtAAD/AAABSgEAAAMAAAYEAAABwgQECAj8AQICFgBtAGEAaQBuAFQAbwBvAGwAQgBhAHIBAP8AABgAZQB4AHQAcgBhAFQAbwBvAGwAQgBhAHIBAAACMf8AAA== ToolBarsMovable=Disabled so maybe some info of that couldn't be digested by kdenlive. Anyway - feel free to close the bug or do whatever you think is correct. If you want, I can reproduce this - just tried it and adding the section makes it crash again ;-) Best Norbert -- PREINING Norbert https://www.preining.info Fujitsu + IFMGA Guide + TU Wien + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 Oh nice bug, good that you have found the reason! :) Could you set the bug to forwarded here after your report, then we can track this issue here as well and add the patch later OpenPGP_0x12D9B04A90CBD8E4.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#986685: RFP: gps-share -- Utility to share your GPS device
Package: wnpp Severity: wishlist * Package name: gps-share Version : 0.2.0 Upstream Author : Zeeshan Ali * URL : https://github.com/zeenix/gps-share * License : GPLv2 Programming Lang: Rust Description : Utility to share your GPS device Contrary to the description, gps-share can now also share the GPS stream locally via a UNIX socket. We want to use in PureOS to feed geoclue with it. The package needs 2 dependencies which are not in debian yet: serial and libudev. https://lib.rs/crates/serial https://lib.rs/crates/libudev PS. sending it from my MUA since it doesn't seem to have gone through from CLI pgpFJeEBxiTYx.pgp Description: OpenPGP digital signature
Bug#986684: qtwebengine-opensource-src: does not honour DEB_BUILD_OPTIONS=parallel=3 when calling ninja
Source: qtwebengine-opensource-src Version: 5.15.3+dfsg-5 Severity: important Hi, I'm not sure whether this a an error of qtwebengine-opensource-src or rather some underlying build tools it uses, please reassign if needed. I think that happens with other qt packages as well, but I haven't checked in detail While rebuilding experimental I just found again some excessive load: 1234 3192 0.0 0.0 2560 1336 pts/18 SN+ 08:24 0:00 /bin/sh 1234 1938 0.0 0.0 15220 10196 pts/18 SN+ 11:56 0:00 /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc 1234 3977 0.0 0.0 2708 1932 pts/18 SN+ 12:28 0:00 /usr/bin/make -f debian/rules build 1234 4485 0.0 0.0 13856 9892 pts/18 SN+ 12:28 0:00 /usr/bin/perl /usr/bin/dh build --with pkgkde_symbolshelper 1234 6 0.0 0.0 2844 1928 pts/18 SN+ 12:28 0:00 /usr/bin/make -f debian/rules override_dh_auto_build-arch 1234 12149 0.0 0.0 13760 9980 pts/18 SN+ 12:28 0:00 /usr/bin/perl /usr/bin/dh_auto_build -- -Onone 1234 12325 0.0 0.0 4124 3408 pts/18 SN+ 12:28 0:00 make -j3 -Onone 1234 12438 0.0 0.0 2568 536 pts/18 SN+ 12:28 0:00 /bin/sh -c cd src/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile /build/qtwebengine-opensource-src-5.15.3+dfsg/src/src.pro QT_BUILD_PARTS+=tests 'QMAKE_EXTRA_ARGS+=-proprietary-cod 1234 12459 0.0 0.0 4316 3456 pts/18 SN+ 12:28 0:00 make -f Makefile 1234 14230 0.0 0.0 2568 540 pts/18 SN+ 12:28 0:00 /bin/sh -c cd core/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile /build/qtwebengine-opensource-src-5.15.3+dfsg/src/core/core.pro QT_BUILD_PARTS+=tests 'QMAKE_EXTRA_ARGS+=-propriet 1234 14236 0.0 0.0 4148 3420 pts/18 SN+ 12:28 0:00 make -f Makefile 1234 15330 0.0 0.0 2568 524 pts/18 SN+ 12:28 0:00 /bin/sh -c ( test -e Makefile.gn_run || /usr/lib/qt5/bin/qmake -o Makefile.gn_run /build/qtwebengine-opensource-src-5.15.3+dfsg/src/core/gn_run.pro QT_BUILD_PARTS+=tests 'QMAKE_EXTRA_ARGS+=-prop 1234 15343 0.0 0.0 4116 3332 pts/18 SN+ 12:28 0:00 make -f Makefile.gn_run 1234 4179 0.2 0.4 278576 269500 pts/18 SN+ 12:28 0:12 ninja -v -C /build/qtwebengine-opensource-src-5.15.3+dfsg/src/core/release QtWebEngineCore ninja(4179)─┬─sh(7105)───g++(7108)─┬─as(7110) │ └─cc1plus(7109) ├─sh(10106)───g++(10110)─┬─as(10114) │└─cc1plus(10112) ├─sh(11878)───g++(11880)─┬─as(11884) │└─cc1plus(11883) ├─sh(12229)───g++(12230)─┬─as(12232) │└─cc1plus(12231) ├─sh(12532)───g++(12533)─┬─as(12535) │└─cc1plus(12534) ├─sh(14164)───g++(14165)─┬─as(14173) │└─cc1plus(14169) ├─sh(14519)───g++(14521)─┬─as(14526) │└─cc1plus(14525) ├─sh(14843)───g++(14844)─┬─as(14847) │└─cc1plus(14845) ├─sh(15375)───g++(15377)─┬─as(15380) │└─cc1plus(15378) ├─sh(16167)───g++(16168)─┬─as(16171) │└─cc1plus(16169) ├─sh(17887)───g++(17891)─┬─as(17896) │└─cc1plus(17892) ├─sh(17894)───g++(17895)─┬─as(17904) │└─cc1plus(17903) ├─sh(18172)───g++(18173)─┬─as(18176) │└─cc1plus(18174) ├─sh(19554)───g++(19556)─┬─as(19559) │└─cc1plus(19557) ├─sh(20054)───g++(20055)─┬─as(20059) │└─cc1plus(20057) ├─sh(20247)───g++(20248)─┬─as(20253) │└─cc1plus(20249) ├─sh(21800)───g++(21801)─┬─as(21807) │└─cc1plus(21804) └─sh(21931)───g++(21933)─┬─as(21942) └─cc1plus(21937) The build starts nicely honoring the DEB_BUILD_OPTIONS=parallel=3 until ninja gets invoked without a limiting -j option, so it forks off $(nproc)+x processes (nproc is 16, but there are 18 forks). And 18 g++ compilations each taking 1GB+ of memory is not a nice background load. Andreas
Bug#866183: Compliment of the season
-- Compliment of the season Greetings from Mr John Zengo i have something to discuss with you and it is very important and urgent. please feel free to reach me on my e-mail Address( johnzeng...@gmail.com) for further clarifications yours sincerely John Zengo
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Andreas Tille writes: > Thanks a lot for your investigation. Unfortunately I have no idea how > to proceed from here. Does anybody have an idea? I mean a better idea > than just stating this package does not work on arm64 which would > probably some last resort. Don't worry, I am still looking into this crash, and had primarily intended that comment as a public note to myself -- the crash occured within a (presumably valid) call to ncbi-blast+, and wound up taking quite a few tries to reproduce on the porterbox I was using (amdahl), so once I finally obtained more details, I wanted to make very sure I wouldn't be able to lose them. Sorry for any resulting confusion. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986674: dkms: wrong-path-for-interpreter etc/dkms/kernel_install.d_dkms (#!/usr/bin/bash != /bin/bash)
* Andreas Beckmann [210409 12:11]: > E: dkms: wrong-path-for-interpreter etc/dkms/kernel_install.d_dkms > (#!/usr/bin/bash != /bin/bash) > > I couldn't find any reference that this script is being used on Debian > based systems. [..] Given this is a Fedora support script [1], I would say it should not be installed on Debian at all. [1] https://github.com/dell/dkms/pull/118
Bug#986662: ossp-padsp not working with recent Pulseaudio
Package: osspd-pulseaudio
Severity: important
Dear Maintainer,
The current osspd packages isn't working with current pulseaudio and it
hasn't
for more than a year. I didn't file a bug back then, but I can confirm
that
at the time it was a pulseaudio update that broke osspd.
Downgrading to an earlier version fixed the problem.
Here is what the osspd logs says:
ossp-padsp[] WARN: failed to subscribe to context events (Bad state)
ossp-padsp[] ERR: failed to connect context, state=5 (Bad state)
This bug has also been reported on launchpad for Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/osspd/+bug/1857810
Almost 18 months later, I did found (by pure luck) that the ArchLinux
package
has a fix for this problem.
Please find a debdiff in attachment so that you can upload the fix in
Debian.
Best Regards,
Sébastien
diff -Nru osspd-1.3.2/debian/changelog osspd-1.3.2/debian/changelog
--- osspd-1.3.2/debian/changelog 2019-01-25 15:36:20.0 +0100
+++ osspd-1.3.2/debian/changelog 2021-04-08 09:01:51.0 +0200
@@ -1,3 +1,13 @@
+osspd (1.3.2-12) UNRELEASED; urgency=low
+
+ * cherrypick 2 commits from upstream GIT:
++ d/p/GIT-fix-adsp_se.patch
++ d/p/GIT-fix-compiler-warnings.patch
+ * Add workaround for pulseaudio >= 13
+d/p/Hack-to-work-with-modern-PulseAudio.patch
+
+ -- Sébastien Noel Thu, 08 Apr 2021 09:01:51 +0200
+
osspd (1.3.2-11) unstable; urgency=medium
* Update Standards-Version to 4.3.0. No changes needed.
diff -Nru osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch
--- osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch 1970-01-01 01:00:00.0 +0100
+++ osspd-1.3.2/debian/patches/GIT-fix-adsp_se.patch 2021-04-08 09:01:51.0 +0200
@@ -0,0 +1,24 @@
+From 4c6161d951daa98f6463904f76b3fa2ce7216194 Mon Sep 17 00:00:00 2001
+From: Tejun Heo
+Date: Mon, 21 Feb 2011 11:54:06 +0100
+Subject: [PATCH] adsp_se was incorrectly created with dsp_ops. Create it with
+ adsp_ops.
+
+Reported-by: Aaron
+---
+ osspd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/osspd.c b/osspd.c
+index 37c9b35..df1cfc4 100644
+--- a/osspd.c
b/osspd.c
+@@ -2253,7 +2253,7 @@ int main(int argc, char **argv)
+ param.mixer_major, param.mixer_minor,
+ args.argc, args.argv);
+ if (strlen(param.adsp_name))
+- adsp_se = setup_ossp_cuse(_ops, param.adsp_name,
++ adsp_se = setup_ossp_cuse(_ops, param.adsp_name,
+ param.adsp_major, param.adsp_minor,
+ args.argc, args.argv);
+
diff -Nru osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch
--- osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch 1970-01-01 01:00:00.0 +0100
+++ osspd-1.3.2/debian/patches/GIT-fix-compiler-warnings.patch 2021-04-08 08:58:42.0 +0200
@@ -0,0 +1,251 @@
+From 37eb730a452f0ded2ed1c174feb438e3df041581 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi
+Date: Fri, 11 Nov 2011 14:19:32 +0100
+Subject: [PATCH] fix compiler warnings
+
+---
+ ossp-padsp.c | 3 ---
+ osspd.c | 75 ++--
+ 2 files changed, 44 insertions(+), 34 deletions(-)
+
+diff --git a/ossp-padsp.c b/ossp-padsp.c
+index 1871f5b..3143960 100644
+--- a/ossp-padsp.c
b/ossp-padsp.c
+@@ -972,16 +972,13 @@ static void do_mmap_read(size_t bytes)
+
+ static void stream_rw_callback(pa_stream *s, size_t length, void *userdata)
+ {
+- int dir;
+ size_t size;
+
+ if (s == stream[PLAY]) {
+- dir = PLAY;
+ size = pa_stream_writable_size(s);
+ if (mmap_map[PLAY])
+ do_mmap_write(size);
+ } else if (s == stream[REC]) {
+- dir = REC;
+ size = pa_stream_readable_size(s);
+ if (mmap_map[REC])
+ do_mmap_read(size);
+diff --git a/osspd.c b/osspd.c
+index df1cfc4..4be1ad5 100644
+--- a/osspd.c
b/osspd.c
+@@ -469,15 +469,6 @@ static int ioctl_prep_uarg(fuse_req_t req, void *in, size_t in_sz, void *out,
+ return; \
+ } while (0)
+
+-#define IOCTL_RETURN(result, outp) do { \
+- if ((outp) != NULL) \
+- fuse_reply_ioctl(req, result, (outp), sizeof(*(outp))); \
+- else\
+- fuse_reply_ioctl(req, result, NULL, 0); \
+- return;\
+-} while (0)
+-
+-
+ /***
+ * Mixer implementation
+ */
+@@ -709,7 +700,8 @@ static void mixer_simple_ioctl(fuse_req_t req, struct ossp_mixer *mixer,
+ strncpy(info.id, id, sizeof(info.id) - 1);
+ strncpy(info.name, name, sizeof(info.name) - 1);
+ info.modify_counter = mixer->modify_counter;
+- IOCTL_RETURN(0, );
++ fuse_reply_ioctl(req, 0, , sizeof(info));
++ break;
+ }
+
+ case SOUND_OLD_MIXER_INFO: {
+@@ -718,7 +710,8 @@ static void mixer_simple_ioctl(fuse_req_t req, struct ossp_mixer *mixer,
+ PREP_UARG(NULL, );
+ strncpy(info.id, id, sizeof(info.id) - 1);
+ strncpy(info.name, name, sizeof(info.name) - 1);
+- IOCTL_RETURN(0, );
++ fuse_reply_ioctl(req,
Bug#986682: Debian installer alpha 3 on Targa circa 2009
Package: installation-reports Boot method: USB Stick Image version: https://cdimage.debian.org/cdimage/bullseye_di_alpha3/i386/iso-cd/debian-bullseye-DI-alpha3-i386-netinst.iso Date: 2021-04-07 Hi, I wasn't able to install from Debian Installer Bullseye Alpha 3 because it fails to detect the hard drive, so I reverted to Debian Stable installer. Machine: Targa, from ~2008-2009 Processor: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (32bits) Memory: $ free -h total utilisé libre partagé tamp/cache disponible Mem: 988Mi 338Mi 218Mi64Mi 431Mi 558Mi Partition d'échange: 1,0Gi 1,0Mi 1,0Gi $ df -Tl Sys. de fichiers Type blocs de 1K Utilisé Disponible Uti% Monté sur udev devtmpfs 492068 0 492068 0% /dev tmpfs tmpfs 101204 800 100404 1% /run /dev/mapper/z--vg-root ext428703652 1971168 25251372 8% / tmpfs tmpfs 506020 11216 494804 3% /dev/shm tmpfs tmpfs 5120 4 5116 1% /run/lock /dev/sda1 ext2 240972 76730 151801 34% /boot /dev/mapper/z--vg-home ext4 123192904 162436 116729592 1% /home tmpfs tmpfs 1012042492 98712 3% /run/user/1000 $ lspci -knn 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GSE Express Memory Controller Hub [8086:27ac] (rev 03) Subsystem: Micro-Star International Co., Ltd. [MSI] Mobile 945GSE Express Memory Controller Hub [1462:0110] 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) Subsystem: Micro-Star International Co., Ltd. [MSI] Mobile 945GSE Express Integrated Graphics Controller [1462:0110] Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03) Subsystem: Micro-Star International Co., Ltd. [MSI] Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [1462:0110] 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] NM10/ICH7 Family High Definition Audio Controller [1462:0110] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 02) Kernel driver in use: pcieport 00:1c.2 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 3 [8086:27d4] (rev 02) Kernel driver in use: pcieport 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] NM10/ICH7 Family USB UHCI Controller [1462:0110] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] NM10/ICH7 Family USB UHCI Controller [1462:0110] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] NM10/ICH7 Family USB UHCI Controller [1462:0110] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] NM10/ICH7 Family USB UHCI Controller [1462:0110] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] NM10/ICH7 Family USB2 EHCI Controller [1462:0110] Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] 82801GBM (ICH7-M) LPC Interface Bridge [1462:0110] Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00:1f.2 SATA controller [0106]: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] [8086:27c5] (rev 02) Subsystem: Micro-Star International Co., Ltd. [MSI] 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] [1462:0110] Kernel driver in use:
Bug#986681: ITP: libodfdom-java -- OpenDocument Format (ODF) framework
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, a...@debian.org * Package name: libodfdom-java Version : 0.9.0~RC2 Upstream Author : The Document Foundation * URL : https://odftoolkit.org/odfdom/ * License : Apache-2.0 Programming Lang: Java Description : OpenDocument Format (ODF) framework ODFDOM is an OpenDocument Format (ODF) framework. Its purpose is to provide an easy common way to create, access and manipulate ODF files, without requiring detailed knowledge of the ODF specification. It is designed to provide the ODF developer community with an easy lightwork programming API portable to any object-oriented language. The current reference implementation is written in Java.
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
Control: tags -1 + moreinfo On Fri, 2021-04-09 at 12:51 +0200, Michal Arbet wrote: > This python library breaks creation of secondary zone in > Openstack's designate project included in buster. > > This is known issue and already fixed in upstream. > > Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645 > The metadata of that bug indicates that it also affects the package in unstable and is not yet fixed there. Is that correct? If so, the issue needs to be fixed in unstable first; otherwise, please add an appropriate "fixed" version so that the BTS knows which versions are actually affected. Regards, Adam
Bug#986680: ITP: libsecondstring-java -- approximate string-matching routines
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, a...@debian.org * Package name: libsecondstring-java Version : 0.1 Upstream Author : 2003 Carnegie Mellon University * URL : https://github.com/TeamCohen/secondstring * License : Expat Programming Lang: Java Description : approximate string-matching routines SecondString is a Java toolkit for developing and evaluating approximate string comparison operators. It includes abstract classes for various edit-distance based comparators and concrete implementations of several published approximate comparators.
Bug#986679: ITP: openrefine-vicino -- near-neighbor search tool for Java
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, a...@debian.org * Package name: openrefine-vicino Version : 1.2 Upstream Author : 2006-2010 Massachusetts Institute of Technology and Contributors * URL : https://github.com/OpenRefine/simile-vicino * License : BSD-3-clause Programming Lang: Java Description : near-neighbor search tool for Java Vicino is a library to perform nearest neighbor searching and clustering. The idea is being able to query data by distance search with pluggable distance functions.
Bug#986665: $HOME not writable when using schroot
Le 9/04/21 à 11:09, Simon McVittie a écrit :
On Fri, 09 Apr 2021 at 10:37:59 +0200, Laurent Bigonville wrote:
The dep8 specification says:
Tests can expect that the ``$HOME`` environment variable to be set
to a directory that exists and is writeable by the user running the test.
But when using schroot (not tried anythong else), $HOME is set to the
HOME of the user running the autopkgtest and does not exists in the
schroot. So either the spec is wrong or the implementation.
What schroot configuration are you using? Relevant information:
* your user's home directory
* the file in /etc/schroot/chroot.d defining the chroot you're using
* /etc/schroot/${profile}/fstab, where ${profile} is taken from the
chroot's configuration
If you are using profile=default (which is the default if left unspecified),
/etc/schroot/default/fstab usually bind-mounts the real /home.
If you are using profile=sbuild, /etc/schroot/sbuild/fstab usually does
not, making it unsuitable for autopkgtest-virt-schroot.
Using a chroot that contains a pre-created home directory for the user
running autopkgtest is also an option, but this is not currently something
that can be set up automatically.
I'm indeed using the "sbuild" profile, but I don't think that anybody
would want to have their real home bind mounted in the chroot and mixed
with the one from the tests
Shouldn't HOME be pointing a temporary directory like for AUTOPKGTEST_TMP ?
I would recommend using autopkgtest-virt-lxc or autopkgtest-virt-qemu:
those are considerably better-tested in practice than -schroot.
I should maybe look at that, but my schroot setup is usually enough for me
Bug#986678: ITP: openrefine-arithcode -- Java implementation of arithmetic coding and PPM compression
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, a...@debian.org * Package name: openrefine-arithcode Version : 1.2 Upstream Author : Bob Carpenter * URL : https://github.com/bob-carpenter/java-arithcode * License : BSD-3-clause Programming Lang: Java Description : Java implementation of arithmetic coding and PPM compression Arithmetic coding is a general technique for coding the outcome of a stochastic process based on an adaptive model. The expected bit rate is the cross-entropy rate of the model versus the actual process. PPM, prediction by partial matching, is an adaptive statistical model of a symbol sequence which models the likelihood of the next byte based on a (relatively short) suffix of the sequence of previous bytes.
Bug#986677: ITP: libmarc4j-java -- API for working with MARC and MARCXML in Java
Package: wnpp Severity: wishlist Owner: Markus Koschany X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, a...@debian.org * Package name: libmarc4j-java Version : 2.9.1 Upstream Author : Robert Haschart, Bas Peters, Bill Dueber, et.al. * URL : https://github.com/marc4j/marc4j * License : LGPL-2.1 Programming Lang: Java Description : API for working with MARC and MARCXML in Java The goal of MARC4J is to provide an easy to use Application Programming Interface (API) for working with MARC and MARCXML in Java. MARC stands for MAchine Readable Cataloging and is a widely used exchange format for bibliographic data. MARCXML provides a loss-less conversion between MARC (MARC21 but also other formats like UNIMARC) and XML.
Bug#986676: ITP: ruby-chef-config - Chef Infra's default configuration and config loading library
Package: wnpp Severity: wishlist Owner: Pirate Praveen Packaging of chef-config gem from https://packagecloud.io/cinc-project/stable since chef is removed due to trademark issues https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 and cinc is a fork of chef without the trademark issues. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#986675: unblock: puppet/5.5.22-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, The current version of puppet is very annoyingly displaying "$SAFE will become a normal global variable" all the time in the logs (and "puppet-agent -t" output), to a point that it really makes it irritating and frustrating. Intri every wrote on IRC "puppet is no useable this way" because he was so much annoyed by it! :) The Puppet packaging team picked-up a patch from upstream fixing the issue. We would really like (as in: at least 5 DDs) appreciate if the patch could be included in Bullseye, and probably the DSA team (who's using puppet a lot) will appreciate it as well. Debdiff attached (it's a *very* small patch). Please unblock puppet/5.5.22-2. Cheers, Thomas Goirand (zigo) diff -Nru puppet-5.5.22/debian/changelog puppet-5.5.22/debian/changelog --- puppet-5.5.22/debian/changelog 2020-10-25 18:04:24.0 +0100 +++ puppet-5.5.22/debian/changelog 2021-03-20 20:37:05.0 +0100 @@ -1,3 +1,9 @@ +puppet (5.5.22-2) unstable; urgency=medium + + * Add 0013-fix-SAFE-deprecation-warning.patch (Closes: #973248) + + -- Micah Anderson Sat, 20 Mar 2021 15:37:05 -0400 + puppet (5.5.22-1) unstable; urgency=medium * New upstream bugfix release diff -Nru puppet-5.5.22/debian/patches/0013-fix-SAFE-deprecation-warning.patch puppet-5.5.22/debian/patches/0013-fix-SAFE-deprecation-warning.patch --- puppet-5.5.22/debian/patches/0013-fix-SAFE-deprecation-warning.patch 1970-01-01 01:00:00.0 +0100 +++ puppet-5.5.22/debian/patches/0013-fix-SAFE-deprecation-warning.patch 2021-03-20 20:37:05.0 +0100 @@ -0,0 +1,22 @@ +From: intrigeri +Date: Mon, 08 Mar 2021 08:50:20 +0100 +Subject: Deprecation warning in Ruby 2.7: $SAFE will become a normal global variable in Ruby 3.0 + +Last-Updated: 20-03-2021 +Forwarded: no +Index: puppet/bin/puppet +=== +--- puppet.orig/bin/puppet 2021-03-20 15:36:54.0 -0400 puppet/bin/puppet 2021-03-20 15:52:49.355574608 -0400 +@@ -1,5 +1,11 @@ + #!/usr/bin/env ruby + ++def Warning.warn(w) ++ return if w =~ /warning: \$SAFE will become a normal global variable/ ++ ++ super w ++end ++ + begin + require 'puppet/util/command_line' + Puppet::Util::CommandLine.new.execute diff -Nru puppet-5.5.22/debian/patches/series puppet-5.5.22/debian/patches/series --- puppet-5.5.22/debian/patches/series 2020-10-21 21:39:08.0 +0200 +++ puppet-5.5.22/debian/patches/series 2021-03-20 20:37:05.0 +0100 @@ -10,3 +10,5 @@ 0010-maint-Delete-sync-requires.patch 0011-PUP-10391-Quiet-Ruby-2.7-URI.escape-warning.patch 0012-fix-ruby27-warning.patch +0013-fix-SAFE-deprecation-warning.patch +
Bug#986674: dkms: wrong-path-for-interpreter etc/dkms/kernel_install.d_dkms (#!/usr/bin/bash != /bin/bash)
Package: dkms Version: 2.8.4-3 Severity: important Lintian emits E: dkms: wrong-path-for-interpreter etc/dkms/kernel_install.d_dkms (#!/usr/bin/bash != /bin/bash) I couldn't find any reference that this script is being used on Debian based systems. If I missed something, please raise the severity to serious. Andreas
Bug#986673: buster-pu: package python3-dnspython/1.16.0-1 -> 1.16.0-1deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Dear stable release team, This python library breaks creation of secondary zone in Openstack's designate project included in buster. This is known issue and already fixed in upstream. Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986645 Upstream-Bug: https://github.com/rthalley/dnspython/issues/390 Upstream-Patch: https://github.com/nrhall/dnspython/commit/9403c1bdbdf562cb01ee492b207b1f26191976ca Could you please approve upload to buster ? Debdiff attached. Cheers, Michal Arbet (kevko) diff -Nru dnspython-1.16.0/debian/changelog dnspython-1.16.0/debian/changelog --- dnspython-1.16.0/debian/changelog 2018-12-23 02:13:05.0 +0100 +++ dnspython-1.16.0/debian/changelog 2021-04-08 19:09:26.0 +0200 @@ -1,3 +1,11 @@ +dnspython (1.16.0-1+deb10u1) buster; urgency=medium + + * Team upload. + * d/patches: Add fix-do-not-compare-with-expiration- +if-None.patch from upstream (Closes: #986645) + + -- Michal Arbet Thu, 08 Apr 2021 19:09:26 +0200 + dnspython (1.16.0-1) unstable; urgency=medium * Update debian/watch to use Github diff -Nru dnspython-1.16.0/debian/patches/fix-do-not-compare-with-expiration-if-None.patch dnspython-1.16.0/debian/patches/fix-do-not-compare-with-expiration-if-None.patch --- dnspython-1.16.0/debian/patches/fix-do-not-compare-with-expiration-if-None.patch 1970-01-01 01:00:00.0 +0100 +++ dnspython-1.16.0/debian/patches/fix-do-not-compare-with-expiration-if-None.patch 2021-04-08 19:08:31.0 +0200 @@ -0,0 +1,22 @@ +Description: When doing xfr, do not compare with + expiration if it is None. +Author: Bob Halley +Date: Sun, 29 Sep 2019 13:39:41 -0700 +Origin: upstream, https://github.com/nrhall/dnspython/commit/9403c1bdbdf562cb01ee492b207b1f26191976ca +Bug-Report: https://github.com/rthalley/dnspython/issues/390 +Last-Update: 2020-04-08 + +diff --git a/dns/query.py b/dns/query.py +index c0c517c..2a06c33 100644 +--- a/dns/query.py b/dns/query.py +@@ -608,7 +608,8 @@ def xfr(where, zone, rdtype=dns.rdatatype.AXFR, rdclass=dns.rdataclass.IN, + first = True + while not done: + mexpiration = _compute_expiration(timeout) +-if mexpiration is None or mexpiration > expiration: ++if mexpiration is None or \ ++ (expiration is not None and mexpiration > expiration): + mexpiration = expiration + if use_udp: + _wait_for_readable(s, expiration) diff -Nru dnspython-1.16.0/debian/patches/series dnspython-1.16.0/debian/patches/series --- dnspython-1.16.0/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ dnspython-1.16.0/debian/patches/series 2021-04-08 19:08:49.0 +0200 @@ -0,0 +1 @@ +fix-do-not-compare-with-expiration-if-None.patch
Bug#985820: python3-cryptography: Core dump in buster openssl binding
Hi Bernhard, Thanks for looking into this. On Thu, Apr 08, 2021 at 05:07:43PM +0200, Bernhard Übelacker wrote: > I found following ticket [2] that shows in later entries > similarities to the given backtrace. Yes, this looks pretty much like what I'm seeing (assuming Glyph's speculation it could be related to python2.7 is wrong, as this is on python3; but I'm going with openssl as the central culprit). > Further running the server with valgrind might show something > related, if the crash happens there too. Since this appears to be a known problem, there's reason to hope it will go away when moving to bullseye, disabling https upgrading made the crashes disappear, and I can live with http for this particular service, I think at this point I'm willing to risk something that feels rather exploitable for another few weeks. These considerations would change if others were seriously concerned; given the twisted ticket has indications on how to trigger the bug outside of production, I might try to organise a windows client to trigger it on a development system. Thanks, Markus
Bug#986672: golang-k8s-sigs-yaml: tests fail on armhf
Source: golang-k8s-sigs-yaml Version: 1.2.0-2 Severity: important Dear Maintainer, I’m observing this issue while trying to build golang-k8s-sigs-yaml on armhf: ... encoding/binary os regexp/syntax encoding/base64 fmt regexp encoding/json gopkg.in/yaml.v2 sigs.k8s.io/yaml dh_auto_test -O--buildsystem=golang cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 3 sigs.k8s.io/yaml # sigs.k8s.io/yaml [sigs.k8s.io/yaml.test] src/sigs.k8s.io/yaml/yaml_test.go:28:26: constant 9223372036854775807 overflows int FAILsigs.k8s.io/yaml [build failed] dh_auto_test: cd obj-arm-linux-gnueabihf && go test -vet=off -v -p 3 sigs.k8s.io/yaml returned exit code 2 make: *** [debian/rules:4: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- Cheers, Andrej
