Bug#1072516: "command -v" prints to the terminal
Package: mailcap Version: 3.71gg Severity: important X-Debbugs-Cc: jcris...@debian.org, anto...@debian.org Control: affects -1 mutt After upgrading mailcap, when opening a message with mutt I see strings like "/usr/bin/vim" and "/usr/bin/evince" printed in random places. Looks like it is caused by this change: 79285fc update-mime: convert .desktop file's TryExec to a test= field for the mailcap entry (Closes: #964173) On a more general note, I am not sure that it is a good idea to automatically add entries for text/plain since they cause a useless shell exec in mutt every time a message is opened (maybe the mutt maintainer can add some insight?). -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.11-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 mailcap depends on: ii media-types 10.1.0 ii perl 5.38.2-5 Versions of packages mailcap recommends: ii bzip2 1.0.8-5.1 ii file 1:5.45-3 ii xz-utils 5.6.1+really5.4.5-1 mailcap suggests no packages. -- Configuration Files: /etc/mailcap.order changed [not included] -- no debconf information -- ciao, Marco signature.asc Description: PGP signature
Bug#1072035: bookworm-pu: package dns-root-data/2024041801
On May 30, Emilio Pozuelo Monfort wrote:
> This looks reasonable to me. Should a similar update be proposed for bullseye?
Yes, uploaded.
diff --git a/debian/changelog b/debian/changelog
index 97fdbf8..98e603c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,28 @@
+dns-root-data (2024041801) unstable; urgency=medium
+
+ * Add myself to the Uploaders field, as discussed with Ondřej.
+ * Fix the package description. (Closes: #1064829)
+ * Update the expired Verisign GRS PGP key.
+ * Update the root hints file to version 2024041801, with:
++ updated A and records for B. (Closes: #1054393)
+
+ -- Marco d'Itri Tue, 21 May 2024 16:25:44 +0200
+
+dns-root-data (2023010101) unstable; urgency=medium
+
+ * merge current root hints and signatures (same contents as before)
+ * d/copyright: bump to 2023
+
+ -- Daniel Kahn Gillmor Wed, 11 Jan 2023 10:00:11
-0500
+
+dns-root-data (2022120101) unstable; urgency=medium
+
+ * Updated upstream root data (same contents as before)
+ * d/copyright: update for 2022
+ * Standards-Version: bump to 4.6.1 (no changes needed)
+
+ -- Daniel Kahn Gillmor Tue, 20 Dec 2022 18:51:44
-0500
+
dns-root-data (2021011101) unstable; urgency=medium
* updated upstream root data (same contents as before)
diff --git a/debian/control b/debian/control
index ac3736a..cd14d8a 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Priority: optional
Maintainer: dns-root-data packagers
Uploaders:
Daniel Kahn Gillmor ,
+ Marco d'Itri ,
Ondřej Surý ,
Robert Edmonds ,
Build-Depends:
@@ -13,7 +14,7 @@ Build-Depends:
openssl,
unbound-anchor,
xml2,
-Standards-Version: 4.5.1
+Standards-Version: 4.7.0.0
Homepage: https://data.iana.org/root-anchors/
Vcs-Git: https://salsa.debian.org/dns-team/dns-root-data.git
Vcs-Browser: https://salsa.debian.org/dns-team/dns-root-data
@@ -24,7 +25,7 @@ Architecture: all
Multi-Arch: foreign
Depends:
${misc:Depends},
-Description: DNS root data including root zone and DNSSEC key
+Description: DNS root hints and DNSSEC trust anchor
This package contains various root zone related data as published
by IANA to be used by various DNS software as a common source
of DNS root zone data, namely:
diff --git a/debian/copyright b/debian/copyright
index 83463f6..d389c35 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -3,7 +3,7 @@ Upstream-Name: IANA Root Zone Management
Source: https://www.iana.org/domains/root/files
Files: *
-Copyright: Copyright (c) 2010-2018 Internet Corporation For Assigned Names and
Numbers
+Copyright: Copyright (c) 2010-2023 Internet Corporation For Assigned Names and
Numbers
License: ICANN-Public
ICANN asserts no property rights to any of the IANA registries or
public keys we maintain. You are free to redistribute the IANA
@@ -14,7 +14,7 @@ License: ICANN-Public
Files: debian/*
Copyright: 2014 Ondřej Surý ,
- 2018 Daniel Kahn Gillmor
+ 2018-2023 Daniel Kahn Gillmor
License: Expat
License: Expat
diff --git a/registry-admin.key b/registry-admin.key
index 9c0fb78..22f087a 100644
Binary files a/registry-admin.key and b/registry-admin.key differ
diff --git a/root-anchors.p7s b/root-anchors.p7s
index ff40c7a..fc6cd07 100644
Binary files a/root-anchors.p7s and b/root-anchors.p7s differ
diff --git a/root.hints b/root.hints
index 6d39aad..f0a0934 100644
--- a/root.hints
+++ b/root.hints
@@ -8,9 +8,9 @@
; file/domain/named.cache
; on server FTP.INTERNIC.NET
; -OR-RS.INTERNIC.NET
-;
-; last update: January 11, 2021
-; related version of root zone: 2021011101
+;
+; last update: April 18, 2024
+; related version of root zone: 2024041801
;
; FORMERLY NS.INTERNIC.NET
;
@@ -21,8 +21,8 @@ A.ROOT-SERVERS.NET. 360
2001:503:ba3e::2:30
; FORMERLY NS1.ISI.EDU
;
.360 NSB.ROOT-SERVERS.NET.
-B.ROOT-SERVERS.NET. 360 A 199.9.14.201
-B.ROOT-SERVERS.NET. 360 2001:500:200::b
+B.ROOT-SERVERS.NET. 360 A 170.247.170.2
+B.ROOT-SERVERS.NET. 360 2801:1b8:10::b
;
; FORMERLY C.PSI.NET
;
diff --git a/root.hints.sig b/root.hints.sig
index 389c1ac..630ff8a 100644
Binary files a/root.hints.sig and b/root.hints.sig differ
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1072035: bookworm-pu: package dns-root-data/2024041801
On May 27, Jonas Meier wrote:
> [ ] attach debdiff against the package in (old)stable
diff -Nru dns-root-data-2023010101/debian/changelog
dns-root-data-2024041801~deb12u1/debian/changelog
--- dns-root-data-2023010101/debian/changelog 2023-01-11 16:00:11.0
+0100
+++ dns-root-data-2024041801~deb12u1/debian/changelog 2024-05-30
14:02:49.0 +0200
@@ -1,3 +1,19 @@
+dns-root-data (2024041801~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm. (Closes: #1072035)
+
+ -- Marco d'Itri Thu, 30 May 2024 14:02:49 +0200
+
+dns-root-data (2024041801) unstable; urgency=medium
+
+ * Add myself to the Uploaders field, as discussed with Ondřej.
+ * Fix the package description. (Closes: #1064829)
+ * Update the expired Verisign GRS PGP key.
+ * Update the root hints file to version 2024041801, with:
++ updated A and records for B. (Closes: #1054393)
+
+ -- Marco d'Itri Tue, 21 May 2024 16:25:44 +0200
+
dns-root-data (2023010101) unstable; urgency=medium
* merge current root hints and signatures (same contents as before)
diff -Nru dns-root-data-2023010101/debian/control
dns-root-data-2024041801~deb12u1/debian/control
--- dns-root-data-2023010101/debian/control 2022-12-21 00:52:11.0
+0100
+++ dns-root-data-2024041801~deb12u1/debian/control 2024-05-21
16:25:42.0 +0200
@@ -4,6 +4,7 @@
Maintainer: dns-root-data packagers
Uploaders:
Daniel Kahn Gillmor ,
+ Marco d'Itri ,
Ondřej Surý ,
Robert Edmonds ,
Build-Depends:
@@ -13,7 +14,7 @@
openssl,
unbound-anchor,
xml2,
-Standards-Version: 4.6.1
+Standards-Version: 4.7.0.0
Homepage: https://data.iana.org/root-anchors/
Vcs-Git: https://salsa.debian.org/dns-team/dns-root-data.git
Vcs-Browser: https://salsa.debian.org/dns-team/dns-root-data
@@ -24,7 +25,7 @@
Multi-Arch: foreign
Depends:
${misc:Depends},
-Description: DNS root data including root zone and DNSSEC key
+Description: DNS root hints and DNSSEC trust anchor
This package contains various root zone related data as published
by IANA to be used by various DNS software as a common source
of DNS root zone data, namely:
Binary files /tmp/osYYJAlpQA/dns-root-data-2023010101/registry-admin.key and
/tmp/1ohQbBsBE0/dns-root-data-2024041801~deb12u1/registry-admin.key differ
diff -Nru dns-root-data-2023010101/root.hints
dns-root-data-2024041801~deb12u1/root.hints
--- dns-root-data-2023010101/root.hints 2023-01-11 08:22:00.0 +0100
+++ dns-root-data-2024041801~deb12u1/root.hints 2024-05-21 16:25:42.0
+0200
@@ -9,8 +9,8 @@
; on server FTP.INTERNIC.NET
; -OR-RS.INTERNIC.NET
;
-; last update: January 01, 2023
-; related version of root zone: 2023010101
+; last update: April 18, 2024
+; related version of root zone: 2024041801
;
; FORMERLY NS.INTERNIC.NET
;
@@ -21,8 +21,8 @@
; FORMERLY NS1.ISI.EDU
;
.360 NSB.ROOT-SERVERS.NET.
-B.ROOT-SERVERS.NET. 360 A 199.9.14.201
-B.ROOT-SERVERS.NET. 360 2001:500:200::b
+B.ROOT-SERVERS.NET. 360 A 170.247.170.2
+B.ROOT-SERVERS.NET. 360 2801:1b8:10::b
;
; FORMERLY C.PSI.NET
;
Binary files /tmp/osYYJAlpQA/dns-root-data-2023010101/root.hints.sig and
/tmp/1ohQbBsBE0/dns-root-data-2024041801~deb12u1/root.hints.sig differ
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On May 28, Andreas Metzler wrote: > I think it is bad choice to deliberately have different behavior for > freshly installed and upgraded systems. Offering upgrades has always > been one of the major selling points of Debian, and imho this > implicitely includes that you do not get a worse or second class Debian > installation when you upgrade it than if you installed from scratch. I strongly disagree: it is a bad choice to change on upgrades a default which may cause data loss. -- ciao, Marco signature.asc Description: PGP signature
Bug#1033012:
On Jan 12, Yangfl wrote: > Please kindly check 2.3.4-1 to see if that fixed your problem. It does not. The problem is that TasksMax in miniupnpd.service is set too low. Set it to something like 10, because it makes no sense to count every single process and it is hard anyway when spawning shell scripts. -- ciao, Marco signature.asc Description: PGP signature
Bug#1070472: Uses the obsolete /sbin/route without a dependency
Package: miniupnpd
Version: 2.3.1-1
Severity: serious
Tags: patch
Pseudo-patch for miniupnpd.config:
- MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C /sbin/route | grep -m 1 default
| awk -- '{ print $8 }')
+ MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C ip -o route show | sed -nre
'/^default /s/^default .*dev ([^ ]+).*/\1/p')
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1036908: expect: Broken use of \c in man page
On May 29, Helge Kreutzmann wrote: > The usage of \c is in mkpasswd(1) is incorrect. It fails when trying > to use po4a to provide translations of the man pages. Im currently > "patching around this" in manpages-l10n. > > For a full explanation of the problem (the man page is different, but > the problem is the same) see Debian #1036826 and the explanations by I have read #1036826 and tested multiple proposed solutions but I could not managed to reproduce the original output. Are you able to propose a patch which does not change the generated man page? > Bjarni, especially in message #25. That solution has been rejected by Branden. -- ciao, Marco signature.asc Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
On Apr 26, Michael Tokarev wrote: > So, should I disable module utils in busybox-udeb now? I think so. > Is kmod udeb ready and used in d-i already, or does it need some > prep first? AFAIK it works. -- ciao, Marco signature.asc Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
On Jan 06, Michael Tokarev wrote: > Yes, some utils in busybox aren't as good as regular implementations. For Yes. Nowadays kmod has many more features related to compressed modules and verification of signatures. Can we agree that kmod should provide these programs for d-i? Or can the d-i maintainers just tell us what they want? -- ciao, Marco signature.asc Description: PGP signature
Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack
On Apr 04, Salvatore Bonaccorso wrote: > While I do agree (and it was filled with this severity), the bug > severity would not be RC, varnish currently seem to lack active > maintainership. Not anymore: https://salsa.debian.org/md/varnish/ . -- ciao, Marco signature.asc Description: PGP signature
Bug#782691: varnishncsa sometimes does not start after reboot
On Apr 16, Oskar Liljeblad wrote: > varnishncsa sometimes does not start after reboot. > I suspect varnishncsa fails because it cannot contact varnish, which has not > started completely yet. This bug is 9 years old: can you still reproduce it? -- ciao, Marco signature.asc Description: PGP signature
Bug#1068311: tcp-wrappers: Can anything be done to avoid the libnsl dependency?
On Apr 03, Colin Watson wrote: > I wondered if anything could be done to avoid this or refactor it > somehow? Sure: I think that it makes sense to just disable NETGROUP (which is the conditional for yp_get_default_domain), because I do not think that anybody in 2024 still uses NIS and if they do then we are only doing them a favour by disabling netgroups support here. -- ciao, Marco signature.asc Description: PGP signature
Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack
Control: found -1 5.0.0-1 Control: fixed -1 7.4.2 On Nov 17, Salvatore Bonaccorso wrote: > CVE-2023-44487[0]: > | The HTTP/2 protocol allows a denial of service (server resource > | consumption) because request cancellation can reset many streams > | quickly, as exploited in the wild in August through October 2023. Fixing this issue would require backporting a significant amount of new features in varnish and I do not believe that it would be practical. I am inclined to downgrade this bug because: - this is just a DoS attack - it only concerns people using hitch for TLS termination instead of a full web server like nginx or haproxy nginx in stable is also vulnerable, BTW. -- ciao, Marco signature.asc Description: PGP signature
Bug#1068184: RM: gup -- ROM; popcon 0
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gup User: ftp.debian@packages.debian.org Usertags: remove As much as I like retrocomputing, let's not waste space in the archive. -- ciao, Marco signature.asc Description: PGP signature
Bug#1067932: usrmerge is dangerous : lost bash and other commands
On Mar 29, Denis Migdal wrote: > Maybe I was better off reinstalling, indeed, but I prefer to properly > plan/prepare for it. This is why the conversion procedure stopped. Then you started thinkering with your system to "fix" it and did worse. > It'd help me if, at least, usrmerge printed the number of duplicates and sym > links. Maybe with a more explicit error message, indicating what to do, "we > strongly advise to reinstall your system", "remove duplicates, but be > careful of symlinks", or whatever. This does not happen frequently enough (only you reported this) to justify investing development resources. -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
On Mar 13, Michael Biebl wrote: > > So I propose this content for a file like > > /usr/lib/udev/rules.d/75-insecure-fs.rules: > Just curious: Why did you pick priority 75? I can't remember. -- ciao, Marco signature.asc Description: PGP signature
Bug#1064798: kmod: installs same filename to both bin and sbin
On Mar 09, ca...@allfreemail.net wrote: > I believe the fix is incomplete, because both /usr/bin/lsmod and > /usr/sbin/lsmod are still being created. Actually it has been this way at least since Debian 7. I will not break compatibility for no good reason. -- ciao, Marco signature.asc Description: PGP signature
Bug#1061516: Please add a sshd@.service template for socket activation
On Mar 04, Colin Watson wrote: > Does this patch look workable? It mostly just resurrects the template > unit we used to ship, under a different name. Looks good to me! -- ciao, Marco signature.asc Description: PGP signature
Bug#1065192: RM: gortr -- ROM; abandoned by upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: go...@packages.debian.org Control: affects -1 + src:gortr User: ftp.debian@packages.debian.org Usertags: remove Development of cfrpki and gortr has been discontinued by the upstream maintainers, so there is no reason to keep them in Debian. Users can migrate to rpki-client and stayrtr as suggested by upstream. Another bug has been filed for removal of cfrpki. -- ciao, Marco signature.asc Description: PGP signature
Bug#1065191: RM: cfrpki -- ROM; abandoned by upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: cfr...@packages.debian.org Control: affects -1 + src:cfrpki User: ftp.debian@packages.debian.org Usertags: remove Development of cfrpki and gortr has been discontinued by the upstream maintainers, so there is no reason to keep them in Debian. Users can migrate to rpki-client and stayrtr as suggested by upstream. Another bug has been filed for removal of gortr. -- ciao, Marco signature.asc Description: PGP signature
Bug#1061516: Please add a sshd@.service template for socket activation
On Jan 25, Marco d'Itri wrote: > systemd currently expects the template to be named sshd@.service > (because that is what Fedora uses), but if you prefer to keep the > ssh@.service name then I suppose that we could patch systemd as well. Is there any way I can help with this? The major issue is deciding how you want the template to be called. -- ciao, Marco signature.asc Description: PGP signature
Bug#1064798: kmod: installs same filename to both bin and sbin
On Feb 26, ca...@allfreemail.net wrote: > This causes a problem on a filesystem layout where bin and sbin are > merged into a single real directory, typically by sbin being a symlink > to bin. Such a filesystem layout has become standard on some > distributions now, and others are moving onto in their next releases. This is not supported by Debian and we have no such plans. But obviously it is still a bug, and I will fix in whenever I will do a new upload. -- ciao, Marco signature.asc Description: PGP signature
Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory
On Feb 12, Salvatore Bonaccorso wrote: > --with-module-directory=/usr/lib/modules > > Looping in Marco for comments. I can revert it if it causes too much trouble, but maybe this is just the right time to switch the kernel packages to /usr/lib/modules/ as well? Please let me know if I am missing anything... -- ciao, Marco signature.asc Description: PGP signature
Bug#1063476: the sanesecurity configuration is not suitable for a release
Source: fangfrisch Version: 1.7.0-1 Severity: grave Tags: upstream Control: forwarded -1 https://github.com/rseichter/fangfrisch/issues/30 The sanesecurity section of default configuration, if enabled, relies on an unofficial HTTP mirror which is seriously overloaded and probably seriously expensive for their operators, since it is located in Australia. The only other known HTTP mirror is mentioned on https://wiki.gentoo.org/wiki/ClamAV_Unofficial_Signatures, with a vague note about it being available to the public. Until fangfrisch will implement rsync support, I do not think that it is safe to include fangfrisch in a Debian release due to the possible effect on unsuspecting third party mirrors. This has also been discussed upstream: https://github.com/rseichter/fangfrisch/issues/30 -- ciao, Marco signature.asc Description: PGP signature
Bug#1061516: Please add a sshd@.service template for socket activation
Package: openssh-server Version: 1:9.6p1-3 Severity: normal Control: affects -1 systemd The next release of systemd will contain support to connect to the system with SSH over an AF_VSOCK socket: https://github.com/systemd/systemd/pull/30777/files The server side of this uses what Ubuntu currently ships as ssh@.service, i.e. a template for socket activation of per-connection sshd daemons. systemd currently expects the template to be named sshd@.service (because that is what Fedora uses), but if you prefer to keep the ssh@.service name then I suppose that we could patch systemd as well. -- ciao, Marco signature.asc Description: PGP signature
Bug#1054393: dns-root-data: New IPs for b.root-servers-net 2023-11-27
This is annoying and needs to be fixed in stable too. Do you want me to make a NMU? -- ciao, Marco signature.asc Description: PGP signature
Bug#1061178: usrmerge: Usrmerge fails with a staticly-linked cp command
On Jan 20, Ajax Dong wrote: > Days ago I upgraded one of my machines (I use sudo machinectl shell > network-service to get its shell) from Debian Buster to Debian Bookworm. > The cp and mv command on that machine was staticly-linked and > self-contained. (It does not require any shared library.) UseMerge This does not look like any Debian system I know. > Because /bin/cp is staticly linked, ldd exited with error, $fh is not Not on any of the Debian 10, 11 and 12 systems that I checked: md:~$ ldd /sbin/ldconfig statically linked md:~$ And this ldd output does not cause early_conversion_files() to fail. What's up then? -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
On Jan 10, Michael Biebl wrote: > While we could ship such a udev rule for udisks, I don't think it will > properly solve the issue. The device will still show up in nautilus, plasma > etc and mounting is just an additional click away. The threat model here is: somebody connects a crafted USB stick to a computer with a locked screen. Also, the listed file systems are not used or not used anymore on removable devices. Certainly not on removable devices used by regular users. -- ciao, Marco signature.asc Description: PGP signature
Bug#1060002: usrmerge: support working with a moved coreutils and policycoreutils
On Jan 04, Helmut Grohne wrote: > the way usrmerge works now prevents us from moving /bin/cp and > /sbin/restorecon to /usr for DEP17. I'm attaching a patch that makes > both of them movable and thus decouples their move from when base-files > switches. Do you have any objections? Please just describe in detail why these changes will be needed. -- ciao, Marco signature.asc Description: PGP signature
Bug#1059920: DEP17: move all kmod files to /usr
On Jan 03, Helmut Grohne wrote: > We want to finalize the /usr-merge transition via DEP17 by moving all > the files to /usr. kmod is involved now, because it is installed by > debootstrap. Hence, I'm sending you a patch for the move. I don't think > this is going to cause any flags from dumat, but the patch is > non-trivial nonetheless, so I recommend doing an experimental upload in > order to have other QA systems and volunteer testers try it. I also note I like to keep unstable unstable... But what about d-i? Is it merged now? -- ciao, Marco signature.asc Description: PGP signature
Bug#1059841: DDPO: backports-new show in the wrong column
Package: qa.debian.org Severity: normal I have uploaded fort-validator 1.6.1-1~bpo12+2 to bookworm-backports, but it is shown in the testing/unstable column instead of in the stable one. -- ciao, Marco signature.asc Description: PGP signature
Bug#1059768: CapabilityBoundingSet breaks fileOwner/fileGroup
Package: rsyslog Version: 8.2310.0-1 Severity: normal Tags: upstream forwarded -1 https://github.com/rsyslog/rsyslog/pull/5223 affects -1 inn inn2 CapabilityBoundingSet in /usr/lib/systemd/system/rsyslog.service lacks CAP_DAC_OVERRIDE, which is needed to make fileOwner/fileGroup work. -- ciao, Marco signature.asc Description: PGP signature
Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup
On Dec 31, YunQiang Su wrote: > Upstream Contact: YunQiang Su > * URL : https://github.com/wzssyqa/cryptsetup-2fa/ What are the benefits of this compared to systemd-cryptenroll? -- ciao, Marco signature.asc Description: PGP signature
Bug#1058761: cheese segfaulted
Package: cheese Version: 44.1-1 Severity: normal Tags: upstream I do not remember exactly what I did to cause this. #0 0x7f5d4cf46c83 in find_root (node=0xdd74dc3c3606beee) at ../../../glib/gsequence.c:1615 Download failed: Invalid argument. Continuing without source file ./debian/build/deb/../../../glib/gsequence.c. 1615../../../glib/gsequence.c: No such file or directory. [Current thread is 1 (Thread 0x7f5d4ad32ac0 (LWP 1474281))] (gdb) where #0 0x7f5d4cf46c83 in find_root (node=0xdd74dc3c3606beee) at ../../../glib/gsequence.c:1615 #1 node_get_last (node=) at ../../../glib/gsequence.c:1682 #2 get_sequence (node=) at ../../../glib/gsequence.c:187 #3 g_sequence_iter_get_sequence (iter=) at ../../../glib/gsequence.c:1193 #4 0x7f5d4d3f783f in iter_is_valid (iter=iter@entry=0x7ffe4e42cba0, list_store=0x56334ae4f9c0 [GtkListStore]) at ../../../gtk/gtkliststore.c:398 #5 0x7f5d4d3f7fb0 in gtk_list_store_get_value (tree_model=, iter=0x7ffe4e42cba0, column=1, value=0x7ffe4e42c9f0) at ../../../gtk/gtkliststore.c:678 #6 0x7f5d4d51153e in gtk_tree_model_get_valist (tree_model=tree_model@entry=0x56334ae4f9c0, iter=iter@entry=0x7ffe4e42cba0, var_args=var_args@entry=0x7ffe4e42caa0) at ../../../gtk/gtktreemodel.c:1810 #7 0x7f5d4d5118e1 in gtk_tree_model_get (tree_model=0x56334ae4f9c0, iter=iter@entry=0x7ffe4e42cba0) at ../../../gtk/gtktreemodel.c:1774 #8 0x563349f78184 in ___lambda6_ (device=0x56334ac7b020 [CheeseCameraDevice], _data2_=0x56334acd21f0) at src/cheese.p/cheese-preferences.c:1050 #9 lambda6__gfunc (data=0x56334ac7b020, self=0x56334acd21f0) at src/cheese.p/cheese-preferences.c:1075 #10 0x7f5d4cef0cda in g_ptr_array_foreach --Type for more, q to quit, c to continue without paging--c (array=array@entry=0x56334a65b000, func=func@entry=0x563349f78110, user_data=user_data@entry=0x56334acd21f0) at ../../../glib/garray.c:2690 #11 0x563349f78428 in cheese_preferences_dialog_on_camera_update_num_camera_devices (self=0x56334addf500 [CheesePreferencesDialog]) at src/cheese.p/cheese-preferences.c:1145 #12 _cheese_preferences_dialog_on_camera_update_num_camera_devices_g_object_notify (_sender=, pspec=, self=0x56334addf500) at src/cheese.p/cheese-preferences.c:217 #17 0x7f5d4da40243 in (instance=instance@entry=0x56334ac146b0, signal_id=, detail=) at ../../../gobject/gsignal.c:3675 #13 0x7f5d4da25540 in g_closure_invoke (closure=0x56334add9290, return_value=0x0, n_param_values=2, param_values=0x7ffe4e42cf10, invocation_hint=0x7ffe4e42ce60) at ../../../gobject/gclosure.c:832 #14 0x7f5d4da38afc in signal_emit_unlocked_R (node=node@entry=0x7ffe4e42cfe0, detail=detail@entry=4464, instance=instance@entry=0x56334ac146b0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe4e42cf10) at ../../../gobject/gsignal.c:3980 #15 0x7f5d4da3a501 in signal_emit_valist_unlocked (instance=instance@entry=0x56334ac146b0, signal_id=signal_id@entry=1, detail=detail@entry=4464, var_args=var_args@entry=0x7ffe4e42d140) at ../../../gobject/gsignal.c:3612 #16 0x7f5d4da40186 in g_signal_emit_valist (instance=0x56334ac146b0, signal_id=1, detail=4464, var_args=0x7ffe4e42d140) at ../../../gobject/gsignal.c:3355 #18 0x7f5d4da29734 in g_object_dispatch_properties_changed (object=0x56334ac146b0 [CheeseCamera], n_pspecs=, pspecs=) at ../../../gobject/gobject.c:1427 #19 0x7f5d4da2c790 in g_object_notify_by_spec_internal (pspec=, object=0x56334ac146b0 [CheeseCamera]) at ../../../gobject/gobject.c:1551 #20 g_object_notify_by_pspec (object=0x56334ac146b0 [CheeseCamera], pspec=) at ../../../gobject/gobject.c:1657 #25 0x7f5d4da40243 in (instance=instance@entry=0x56334a9ebc30, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3675 #21 0x7f5d4da25540 in g_closure_invoke (closure=0x56334ac2b510, return_value=0x0, n_param_values=2, param_values=0x7ffe4e42d450, invocation_hint=0x7ffe4e42d3a0) at ../../../gobject/gclosure.c:832 #22 0x7f5d4da38afc in signal_emit_unlocked_R (node=node@entry=0x7ffe4e42d520, detail=detail@entry=0, instance=instance@entry=0x56334a9ebc30, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe4e42d450) at ../../../gobject/gsignal.c:3980 #23 0x7f5d4da3a501 in signal_emit_valist_unlocked (instance=instance@entry=0x56334a9ebc30, signal_id=signal_id@entry=384, detail=detail@entry=0, var_args=var_args@entry=0x7ffe4e42d680) at ../../../gobject/gsignal.c:3612 #24 0x7f5d4da40186 in g_signal_emit_valist (instance=0x56334a9ebc30, signal_id=384, detail=0, var_args=0x7ffe4e42d680) at ../../../gobject/gsignal.c:3355 #26 0x7f5d4dbe9c6a in cheese_camera_device_monitor_removed (device=, monitor=0x56334a9ebc30
Bug#1058760: assertion failed in isc_signal_stop()
Package: bind9-host
Version: 1:9.19.17-1
Severity: normal
Tags: upstream
This happened after I pressed ^C:
#0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument. Continuing without source file
./nptl/./nptl/pthread_kill.c.
44 ./nptl/pthread_kill.c: No such file or directory.
[Current thread is 1 (Thread 0x7f04feaf0480 (LWP 1416976))]
(gdb) where
#0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x7f04ffaa815f in __pthread_kill_internal (signo=6,
threadid=) at ./nptl/pthread_kill.c:78
#2 0x7f04ffa5a472 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/posix/raise.c:26
#3 0x7f04ffa444b2 in __GI_abort () at ./stdlib/abort.c:79
#4 0x7f04fffc9355 in isc_assertion_failed (
file=file@entry=0x7f058129 "signal.c", line=line@entry=78,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7f051480 "((signal) != ((void *)0) && ((const
isc__magic_t *)(signal))->magic == ((('S') << 24 | ('I') << 16 | ('G') << 8 |
(' '") at ./lib/isc/assertions.c:49
#5 0x7f04fffe8521 in isc_signal_stop (signal=)
at ./lib/isc/signal.c:78
#6 0x7f04fffdd89e in isc_loopmgr_blocking (loopmgr=0x7f04fc208600)
at ./lib/isc/loop.c:587
#7 0x5624a7a1b056 in get_address (host=0x7f04fc272a00 "127.0.0.1",
myport=53, sockaddr=0x7f04fc29f7d8) at ./bin/dig/dighost.c:4521
#8 0x5624a7a1d31d in start_udp (query=)
at ./bin/dig/dighost.c:3263
#9 0x5624a7a1e8ef in clear_current_lookup () at ./bin/dig/dighost.c:1820
#10 0x5624a7a2028a in recv_done (handle=0x7f04fc29fa80,
eresult=, region=0x7fffab553870, arg=0x7f04fc29f700)
--Type for more, q to quit, c to continue without paging--c
at ./bin/dig/dighost.c:3915
#11 0x7f04fffbadfc in isc___nm_readcb (arg=)
at netmgr/netmgr.c:1783
#12 isc__nm_readcb (sock=sock@entry=0x7f04fc274800, uvreq=,
eresult=eresult@entry=ISC_R_SHUTTINGDOWN, async=async@entry=false)
at netmgr/netmgr.c:1798
#13 0x7f04fffc8146 in isc__nm_udp_failed_read_cb (sock=0x7f04fc274800,
result=ISC_R_SHUTTINGDOWN, async=false) at netmgr/udp.c:865
#14 0x7f04ffef767b in uv_walk (loop=loop@entry=0x7f04fc272020,
walk_cb=walk_cb@entry=0x7f04fffb8b10 , arg=arg@entry=0x0)
at ./src/uv-common.c:549
#15 0x7f04fffbb758 in networker_teardown (arg=0x7f04fc20f2f0)
at netmgr/netmgr.c:140
#16 0x7f04fffc96a7 in isc__async_cb (handle=)
at ./lib/isc/async.c:111
#17 0x7f04ffef8633 in uv__async_io (loop=0x7f04fc272020,
w=, events=) at ./src/unix/async.c:176
#18 0x7f04fff0c065 in uv__io_poll (loop=loop@entry=0x7f04fc272020,
timeout=) at ./src/unix/linux.c:1476
#19 0x7f04ffef92f8 in uv_run (loop=loop@entry=0x7f04fc272020,
mode=mode@entry=UV_RUN_DEFAULT) at ./src/unix/core.c:447
#20 0x7f04fffdbd30 in loop_thread (arg=0x7f04fc272000)
at ./lib/isc/loop.c:282
#21 0x5624a7a14fc8 in main (argc=2, argv=0x7fffab557dd8)
at ./bin/dig/host.c:914
(gdb)
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 bind9-host depends on:
ii bind9-libs 1:9.19.17-1
ii libc6 2.37-13
ii libidn2-0 2.3.4-1+b1
bind9-host recommends no packages.
bind9-host suggests no packages.
-- no debconf information
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1057089: bullseye-pu: package usrmerge/37~deb12u1
On Nov 29, Andreas Beckmann wrote: > Improve the usrmerge experience in bookworm. Great idea, thank you for working on this! -- ciao, Marco signature.asc Description: PGP signature
Bug#1056698: should not depend on the Javascript libraries
Package: restic Version: 0.16.2-1 Severity: normal Having a 100% console-based backup program depend on tens of MBs of Javascript libraries and fonts just for the HTML manual that almost nobody will access there is really wasteful. Please make these recommends, or else move the HTML to a restic-doc package. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 restic depends on: ii libc62.37-12 ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-sphinxdoc 7.2.6-2 ii sphinx-rtd-theme-common 2.0.0~rc3+dfsg-2 Versions of packages restic recommends: ii fuse3 [fuse] 3.14.0-4 restic suggests no packages. -- no debconf information -- ciao, Marco signature.asc Description: PGP signature
Bug#810018: New Essential package procps-base
On Nov 20, Craig Small wrote: > Also why is killall5 not a candidate too? Probably because it makes no sense outside of sysvinit, except that as a footgun. (Also, is it equivalent to pkill --inverse?) -- ciao, Marco signature.asc Description: PGP signature
Bug#706918: pppd stopped passing ipparam value to /etc/ppp/ip-up after an upgrade to Wheezy
On May 06, Evgeny Kapun wrote: > Package: ppp > Version: 2.4.5-5.1+b1 > > If ipparam option is supplied to pppd, pppd is supposed to pass its > argument to scripts like /etc/ppp/ip-up. However, after a system > upgrade from Squeeze to Wheezy, this stopped working. Previously, > ip-up was invoked like this: Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#736851: ppp: Please ship logcheck rules
Control: severity -1 wishlist Control: tag -1 help On Jan 27, Jonathan Wiltshire wrote: > Please ship snippets for consumption by the logcheck package. Please provide sensible rules. -- ciao, Marco signature.asc Description: PGP signature
Bug#514274: Bad ppp frames for certain TCP package lengths
On Feb 05, Eckhart Wörner wrote: > With a UMTS connection to o2 Germany, connections sometimes dropped. Looking > into that issue with wireshark, I found out that the > connection drops because a TCP package of length 187 + k * 240 bytes (with k > in 0,1,...) never makes it to the TCP stack of the > receiver (i.e. the computer where PPP is running). This can be reproduced > using netcat and a 187 byte file. Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#555477: /usr/sbin/pppd: ppp with persist does not redial after error
On Nov 09, Alex S Kurilo wrote: > ppp does not redial if pppoe server return 'No client slots available' > (persist turned on, after other errors it tries to reconnect) > The following line appears in the syslog before pppd dies: > > PADS: System-Error: RP-PPPoE: Server: No client slots available Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#650634: pppd eats all cpu in tdb_allocate()
On Dec 01, onehalf3544 wrote: > Problem is reproducible (nobody is able to establish connection =(( ). > I'll continue debugging, but would appreciate any advice. Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#451363: ppp: radius plugin stops talking to radius server
On Nov 15, B Thompson wrote: > I am having problems with the radius plugin supplied with ppp (I am using this > to authenticate users of my (poptop) pptp vpn. Here are the logs from a failed > login :- Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#384998: rp-pppoe plugin and MLPPP don't play well together - tiny fragments are sent
On Aug 28, James Harper wrote: > When using the rp-pppoe plugin and pppoe, the fragments used are tiny (8 > bytes of ppp data), and consequently the link behaves really really poorly. > The correct behaviour is that MLPPP fragments should be (packet size) / > (number of links), but less than MTU. When using /usr/sbin/pppoe, it works > fine. Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#374698: pppd exits despite 'persist' option
On Jun 20, Claus Fischer wrote: > Summary: The persist option does not work properly. Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#203620: ppp: pppstats returns 0 for IN (incoming bytes) after a while
On Jul 31, Christian Schoenebeck wrote: > I encountered that pppstats displays 0 for incoming bytes after a while. Here > is an example output of pppstats: Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#325746: pppd 2.4.3 (+pptpd) bug - error count recive and transmit bytes
On Aug 30, Женя Дрюков wrote: > Error count VPN traffic client disconnect after 10 secconds width only > Send bytes 113 Megabytes !!! Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#518624: /usr/sbin/pppd: ppp authentication mschapv2 doesn't work after upgrading winbind to 2:3.2.5-4
On Mar 07, Sergey Dorofeev wrote: > Both upgraded. > Windows clients also affected. Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#627088: ppp: reconnect after hangup fails with many Protocol-Reject messages
On May 17, Richard wrote: > after upgrading to wheezy a previously functioning PPTP connection has > problems. > when the connection hangs up and the daemon tries to reconnect, the > connection fails > with the following log messages: Are you still able to reproduce this issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#1034053: segfaulted on quit
Control: version -1 2.2.12-0.1 Again: #0 0x7f4fd963a11a in __GI___libc_free (mem=0x54495f7469) at ./malloc/malloc.c:3344 Download failed: Argomento non valido. Continuing without source file ./malloc/./malloc/malloc.c. 3344./malloc/malloc.c: File o directory non esistente. (gdb) where #0 0x7f4fd963a11a in __GI___libc_free (mem=0x54495f7469) at ./malloc/malloc.c:3344 #1 0x55b62120b685 in safe_free (ptr=0x55b622c3c7d0) at ../../lib.c:198 #2 0x55b6211f0bf0 in rfc822_free_address (p=0x55b622ee2da0) at ../../rfc822.c:140 #3 0x55b62120e9a0 in mutt_free_envelope (p=0x55b622ee2d80) at ../../muttlib.c:875 #4 0x55b62120edf7 in mutt_free_body (p=0x55b622d46c38) at ../../muttlib.c:208 #5 0x55b62120ee0c in mutt_free_body (p=0x55b622d46ac8) at ../../muttlib.c:211 #6 0x55b62120ebba in mutt_free_header (h=0x55b622d66500) at ../../muttlib.c:382 #7 0x55b6211d70e1 in mx_fastclose_mailbox (ctx=ctx@entry=0x55b621fa95d0) at ../../mx.c:736 #8 0x55b6211d7bab in mx_close_mailbox (ctx=0x55b621fa95d0, index_hint=index_hint@entry=0x7fff63f24274) at ../../mx.c:1014 #9 0x55b6211ac799 in mutt_index_menu () at ../../curs_main.c:1414 #10 0x55b62118c157 in main (argc=1, argv=0x7fff63f25508, environ=) at ../../main.c:1400 (gdb) -- ciao, Marco signature.asc Description: PGP signature
Bug#1053156: libmnl is 18 months out of date
Source: libmnl Version: 1.0.4-3 Severity: wishlist 1.0.5 was released in April 2022. -- ciao, Marco signature.asc Description: PGP signature
Bug#704435: varnish: Pushing vcls failed:#012CLI communication error (hdr)
On Apr 01, "Rune K. Svendsen" wrote: > Apr 1 06:40:17 raspberrypi varnishd[28809]: Pushing vcls failed:#012CLI > communication error (hdr) This bug is 10 years old: can you still reproduce this? -- ciao, Marco signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Sep 17, Bill Allombert wrote: > Does not that would break users expectation that the system image contains > /var > before the first boot ? I am not aware of such expectations. > A lot of things in /var are caches that are mostly instance-independent and > can > be prefilled, but for that, users expect a minimal directory hierarchy to be > present before first boot. Can you show some examples of how this would work in practice? > It seems your scheme favors some usecase over some others. There are always tradeoffs, but my use case does not forbid the other one: worst case it requires one more mkdir while copying that data. -- ciao, Marco signature.asc Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Sep 17, Russ Allbery wrote: > (I am a little confused by this wording, but I think what you're saying is > that /usr is encrypted and read-only, and /var is recreated on each boot. > That at least is my understanding of the pattern that you're trying to > enable.) The general idea is to be able to create /var on the first boot. If /var can be populated programmatically then a system can be trivially replicated by sharing (or copying) /usr and by copying /etc. BTW, I do not expect that tmpfiles.d(5) will be the standard method used to create most directories below /var. Usually the CacheDirectory, LogsDirectory and StateDirectory directives are more convenient and flexible. > The benefit we gain from this is attribution of the directories in the > dpkg database, which is useful (although I understand that one can argue > about how useful). Not enough to justify having multiple sources of truth is my opinion. -- ciao, Marco signature.asc Description: PGP signature
Bug#885698: What licenses should be included in /usr/share/common-licenses?
On Sep 10, Enrico Zini wrote: > I like this. I'd say that even if a license is shorter than 25 lines I'd > appreciate to be able to link to it instead of copypasting it. Me too. > I like to be able to fill the license field with a value, after checking > that the upstream license didn't diverge from what it looks like. I'd > love to use SPDX IDs there, for example. In an ideal world, I'd like to > autofill debian/copyright with SPDX IDs from upstream metadata. Having a > link to a file goes closer to having a declarative license ID. Agreed. -- ciao, Marco signature.asc Description: PGP signature
Bug#1050901: libc6:amd64: install /usr/lib64 without including it
> As the issue is actually introduced by the usrmerge package, I am > reassigning the bug there. I am also tagging it wontfix as I don't > believe the usrmerge maintainer will want to rollback the usrmerge > transition, but feel free to change that if I am wrong. Indeed. I have used TSM for many years but I have never noticed this issue because the upstream Debian packages are so much awful that I repackaged the software: https://github.com/rfc1036/tivsm-deb . -- ciao, Marco signature.asc Description: PGP signature
Bug#1043456: tecla: shows nothing and segfaults on keypress
On Sep 07, Jeremy Bícha wrote: > This popup window is Tecla. Does it work correctly? This way it does not crash anymore. Still, it should be fixed to either not crash or not start if it can only be called by gnome-control-center. (BTW, it does not react to left-alt, while it correctly reports pressing right-alt as Alt_R / Meta_R.) -- ciao, Marco signature.asc Description: PGP signature
Bug#1043456: tecla: shows nothing and segfaults on keypress
Control: reopen -1 Still broken. ||/ Name Version Architecture Description +++-==---==> ii tecla 45~rc-1 amd64keyboard layout viewer for the GNO> [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `tecla'. Program terminated with signal SIGSEGV, Segmentation fault. warning: Section `.reg-xstate/1963868' in core file too small. #0 tecla_model_get_keycode_key (model=0x0, keycode=24) at ../src/tecla-model.c:338 Download failed: Argomento non valido. Continuing without source file ./obj-x86_64-linux-gnu/../src/tecla-model.c. 338 ../src/tecla-model.c: File o directory non esistente. [Current thread is 1 (Thread 0x7effd81ee2c0 (LWP 1963868))] (gdb) where #0 tecla_model_get_keycode_key (model=0x0, keycode=24) at ../src/tecla-model.c:338 #1 0x55e0f78b72a8 in key_pressed_cb (controller=, keyval=, keycode=, modifiers=, view=0x55e0f84828c0 [TeclaView]) at ../src/tecla-view.c:343 #6 0x7effdb17a243 in (instance=instance@entry=0x55e0f8516490, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3675 #2 0x7effdb4bcb0b in _gtk_marshal_BOOLEAN__UINT_UINT_FLAGSv (closure=, return_value=0x7ffe1c328650, instance=, args=, marshal_data=, n_params=, param_types=0x55e0f85113c0) at gtk/gtkmarshalers.c:1748 #3 0x7effdb15f749 in _g_closure_invoke_va (closure=0x55e0f85663c0, return_value=0x7ffe1c328650, instance=0x55e0f8516490, args=0x7ffe1c328750, n_params=3, param_types=0x55e0f85113c0) at ../../../gobject/gclosure.c:895 #4 0x7effdb173913 in signal_emit_valist_unlocked (instance=instance@entry=0x55e0f8516490, signal_id=signal_id@entry=99, detail=detail@entry=0, var_args=var_args@entry=0x7ffe1c328750) at ../../../gobject/gsignal.c:3516 #5 0x7effdb17a186 in g_signal_emit_valist (instance=0x55e0f8516490, signal_id=99, detail=0, var_args=0x7ffe1c328750) --Type for more, q to quit, c to continue without paging--c at ../../../gobject/gsignal.c:3355 #7 0x7effdb53c0fd in gtk_event_controller_key_handle_event (controller=0x55e0f8516490 [GtkEventControllerKey], event=, x=, y=) at ../../../gtk/gtkeventcontrollerkey.c:121 #8 0x7effdb53b09a in gtk_event_controller_handle_event (controller=controller@entry=0x55e0f8516490 [GtkEventControllerKey], event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], target=target@entry=0x55e0f84828c0 [TeclaView], x=x@entry=0, y=y@entry=0) at ../../../gtk/gtkeventcontroller.c:362 #9 0x7effdb67e55c in gtk_widget_run_controllers (widget=widget@entry=0x55e0f84828c0 [TeclaView], event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], target=target@entry=0x55e0f84828c0 [TeclaView], x=0, y=0, phase=phase@entry=GTK_PHASE_BUBBLE) at ../../../gtk/gtkwidget.c:4581 #10 0x7effdb685db1 in gtk_widget_event (widget=widget@entry=0x55e0f84828c0 [TeclaView], event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], target=target@entry=0x55e0f84828c0 [TeclaView]) at ../../../gtk/gtkwidget.c:4775 #11 0x7effdb5ac5de in gtk_propagate_event_internal (widget=widget@entry=0x55e0f84828c0 [TeclaView], event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent], topmost=) at ../../../gtk/gtkmain.c:1947 #12 0x7effdb5ac676 in gtk_propagate_event (widget=widget@entry=0x55e0f84828c0 [TeclaView], event=event@entry=0x55e0f8e5c7b0 [GdkKeyEvent]) at ../../../gtk/gtkmain.c:1997 #13 0x7effdb5acd03 in gtk_main_do_event (event=0x55e0f8e5c7b0 [GdkKeyEvent]) at ../../../gtk/gtkmain.c:1689 #14 0x7effdb6921f0 in surface_event (surface=surface@entry=0x55e0f858c730 [GdkX11Toplevel], event=, widget=) at ../../../gtk/gtkwindow.c:4830 #15 0x7effdb80a5ea in _gdk_marshal_BOOLEAN__POINTER (closure=closure@entry=0x55e0f82bb050, return_value=return_value@entry=0x7ffe1c328c90, n_param_values=n_param_values@entry=2, param_values=param_values@entry=0x7ffe1c328d20, invocation_hint=invocation_hint@entry=0x7ffe1c328c70, marshal_data=marshal_data@entry=0x0) at gdk/gdkmarshalers.c:258 #21 0x7effdb17a243 in (instance=instance@entry=0x55e0f858c730, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3675 #16 0x7effdb87f5f3 in gdk_surface_event_marshaller (closure=0x55e0f82bb050, return_value=0x7ffe1c328c90, n_param_values=2, param_values=0x7ffe1c328d20, invocation_hint=0x7ffe1c328c70, marshal_data=0x0) at ../../../gdk/gdksurface.c:433 #17 0x7effdb15f540 in g_closure_invoke (closure=0x55e0f82bb050, return_value=0x7ffe1c328c90, n_param_values=2, param_values=0x7ffe1c328d20, invocation_hint=0x7ffe1c328c70) at ../../../gobject/gclosure.c:832 #18 0x7effdb172afc in signal_emit_unlocked_R (node=node@entry=0x7ffe1c328df0, detail=detail@entry=0, instance=instance@entry=0x55e0f858c730,
Bug#1051119: NM reports fake Wi-Fi BSSIDs
Package: network-manager Version: 1.44.0-1 Severity: important "nmcli device wifi list" reports obviously fake BSSIDs for all networks to which I have not connected to: IN-USE BSSID SSIDMODE CHAN RATE SIGNAL > B4:4B:D6:..:..:.. (omitted) Infra 2 65 Mbit/s 87 > 00:01:02:00:03:90 (omitted) Infra 2 65 Mbit/s 77 > 00:01:02:00:03:91 WOW FI - FASTWEBInfra 2 65 Mbit/s 77 > 00:01:02:00:03:FD (omitted) Infra 2 65 Mbit/s 75 > * B4:4B:D6:..:..:.. (omitted) Infra 3665 Mbit/s 59 > 00:01:02:00:03:B3 (omitted) 461 Infra 2 65 Mbit/s 57 > 00:01:02:00:03:8E FRITZ!Box 7530 WB Infra 2 65 Mbit/s 55 > 82:8F:34:..:..:.. Vodafone-WiFi Infra 3 65 Mbit/s 54 > 00:01:02:00:03:93 TIM-29740309Infra 2 65 Mbit/s 35 > 00:01:02:00:03:96 (omitted) 045 Infra 2 65 Mbit/s 30 > 00:01:02:00:04:AE Sala da pranzo.v, Infra 2 65 Mbit/s 27 > 00:01:02:00:04:71 (omitted) Infra 2 65 Mbit/s 25 > 00:01:02:00:04:BC (omitted) Infra 2 65 Mbit/s 25 > 00:01:02:00:04:A1 (omitted) Infra 2 65 Mbit/s 20 > (The real BSSIDs and the non-generic SSIDs have been elided for paranoia reasons.) This breaks the Mozilla Location Services API (used, among others, by Firefox and Geoclue), which once it sees at least two of these 00:01:02:00:03:* BSSIDs it will happily geolocate me either in Vietnam or (less frequently) in Germany. I do not believe this to be a kernel issue because "iwlist scanning" properly reports the BSSIDs of all networks. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 network-manager depends on: ii adduser 3.137 ii dbus [default-dbus-system-bus] 1.14.10-1 ii dbus-broker [dbus-system-bus] 33-1 ii libaudit1 1:3.1.1-1 ii libbluetooth3 5.69-1 ii libc6 2.37-7 ii libcurl3-gnutls 8.2.1-2 ii libglib2.0-02.77.2-1 ii libgnutls30 3.8.1-4 ii libjansson4 2.14-2 ii libmm-glib0 1.20.6-2 ii libndp0 1.8-1 ii libnewt0.52 0.52.23-1+b1 ii libnm0 1.44.0-1 ii libpsl5 0.21.2-1 ii libreadline88.2-1.3 ii libselinux1 3.5-1 ii libsystemd0 254.1-3 ii libteamdctl01.31-1 ii libudev1254.1-3 ii policykit-1 123-1 ii polkitd 123-1 ii udev254.1-3 Versions of packages network-manager recommends: ii dnsmasq-base [dnsmasq-base] 2.89-1 ii libpam-systemd 254.1-3 pn modemmanager ii ppp 2.4.9-1+1.1+b1 ii wireless-regdb 2022.06.06-1 ii wpasupplicant2:2.10-15 Versions of packages network-manager suggests: ii iptables 1.8.9-2 pn libteam-utils Versions of packages network-manager is related to: ii isc-dhcp-client 4.4.3-P1-2 -- Configuration Files: /etc/NetworkManager/NetworkManager.conf changed [not included] /etc/NetworkManager/dispatcher.d/01-ifupdown changed [not included] -- no debconf information -- ciao, Marco signature.asc Description: PGP signature
Bug#1050681: bookworm-pu: package inn2/2.7.1-1~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: i...@packages.debian.org
Control: affects -1 + src:inn2
This stable upload contains two patches backported from the upstream
repository on request of the upstream maintainer.
The patches are also part of the package which is currently in testing.
One patch fixes hangs in nnrpd, while the other allows the package to
process the high-precision syslog timestamps format which is currently
the default for Debian.
The package also contains a minor security fix which changes the default
permissions of two configuration files which contain secrets, which has
already been added to the next unstable upload.
For a better view of the changes please see
https://salsa.debian.org/md/inn2/-/commits/bookworm .
--
ciao,
Marco
diff -Nru inn2-2.7.1/debian/changelog inn2-2.7.1/debian/changelog
--- inn2-2.7.1/debian/changelog 2023-05-01 19:25:42.0 +0200
+++ inn2-2.7.1/debian/changelog 2023-08-28 02:04:59.0 +0200
@@ -1,3 +1,13 @@
+inn2 (2.7.1-1~deb12u1) bookworm; urgency=medium
+
+ * Added patch backport_a1f2e9323: this upstream commit fixes nnrpd hangs
+when compression is enabled.
+ * Added patch backport_f7d111aad: this upstream commit adds support for
+high-precision syslog timestamps which now are the default in Debian.
+ * Made inn-{radius,secrets}.conf not world readable.
+
+ -- Marco d'Itri Mon, 28 Aug 2023 02:04:59 +0200
+
inn2 (2.7.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru inn2-2.7.1/debian/patches/backport_a1f2e9323 inn2-2.7.1/debian/patches/backport_a1f2e9323
--- inn2-2.7.1/debian/patches/backport_a1f2e9323 1970-01-01 01:00:00.0 +0100
+++ inn2-2.7.1/debian/patches/backport_a1f2e9323 2023-08-28 02:04:59.0 +0200
@@ -0,0 +1,154 @@
+From: Enrik Berkhan
+Subject: nnrpd: avoid hang due to misplaced select()
+Origin: upstream, commit:a1f2e932338a17eb4111243f29fcade52d39e0a7
+
+The select() call in nnrpd's input data processing is moved right
+before the related read() call to avoid blocking when it shouldn't.
+
+Without this change, there could still remain data to be inflated, that
+has already been read, if compression had been activated. The select()
+can then time out because the client might already have sent all data
+before, and the yet to be inflated data will not be used until after
+the timeout.
+
+Resolves: #269
+
+diff --git a/nnrpd/line.c b/nnrpd/line.c
+index fc68b15dd..6c048720c 100644
+--- a/nnrpd/line.c
b/nnrpd/line.c
+@@ -79,12 +79,11 @@ line_reset(struct line *line)
+ }
+
+ /*
+-** Timeout is used only if HAVE_OPENSSL is defined.
+ ** Returns -2 on timeout, -1 on read error, and otherwise the number of
+ ** bytes read.
+ */
+ static ssize_t
+-line_doread(void *p, size_t len, int timeout UNUSED)
++line_doread(void *p, size_t len, int timeout)
+ {
+ ssize_t n;
+
+@@ -122,6 +121,22 @@ line_doread(void *p, size_t len, int timeout UNUSED)
+ }
+ #endif /* HAVE_ZLIB */
+
++/* It seems that the SSL_read cannot be mixed with select()
++ * as in the current code. TLS communicates in its own data
++ * blocks and handshaking. The line_doread using SSL_read
++ * could return, but still with a partial line in the SSL_read
++ * buffer. Then the server TLS routine would sit there waiting
++ * for completion of that data block while nnrpd sat at the
++ * select() routine waiting for more data from the server.
++ *
++ * Here, we decide to just bypass the select() wait. Unlike
++ * innd with multiple threads, the select on nnrpd is just
++ * waiting on a single file descriptor, so it is not really
++ * essential with blocked read like SSL_read. Using an alarm
++ * signal around SSL_read for non active timeout, TLS works
++ * without dead locks. However, without the select() wait,
++ * the IDLE timer stat won't be collected...
++ */
+ #ifdef HAVE_OPENSSL
+ if (tls_conn) {
+ int err;
+@@ -152,9 +167,38 @@ line_doread(void *p, size_t len, int timeout UNUSED)
+ xsignal(SIGALRM, SIG_DFL);
+ } else
+ #endif /* HAVE_OPENSSL */
++{
++fd_set rmask;
++int i;
++
++/* Wait for activity on stdin, updating timer stats as we go. */
++do {
++struct timeval t;
++
++FD_ZERO();
++FD_SET(STDIN_FILENO, );
++t.tv_sec = timeout;
++t.tv_usec = 0;
++TMRstart(TMR_IDLE);
++i = select(STDIN_FILENO + 1, , NULL, NULL, );
++TMRstop(TMR_IDLE);
++if (i == -1 && errno != EINTR) {
++syswarn("%s can't select", Client.host);
++break;
++}
++} while (i == -1);
++
++
Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed
Control: retitle -1 kmod does not work with XZ in-kernel module decompression On Aug 27, Jon Westgate wrote: > Note that I already had "Support in-kernel module decompression" selected > when the compression method was XZ. > > Would you like me to try without it? No need to: we know that everything works fine without in-kernel decompression, because this is how the Debian kernel is configured. -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
On Aug 27, Diederik de Haas wrote: > While I agree that "orphan" does mean that it is NOT actively maintained, > AFAICT the situation is a bit more blurry for "odd fixes". All these file systems are either rare enough and/or not used on removable media, so I do not believe that it is unreasonable to ask the few users that want them to be mounted automatically to disable this policy with a symlink like ln -s /dev/null /etc/udev/rules.d/75-insecure-fs.rules . > Previously not knowing about that status, I looked up the commits where the > status was set to "odd fixes" and found that for some the reason was that the > maintainer didn't have the hardware to test it themselves. > I do not think that's the same as 'unmaintained'. It means that they are not tested enough... > I'm not sure if it would actually result in unbootable systems, but I do think > a bit more care should be taken before blacklisting modules. Did you actually read the thread? No modules are being blacklisted, the plan is just to stop udisks2 from automatically mounting such removable media. I am quite sure that routers file systems are not mounted with udisks2. -- ciao, Marco signature.asc Description: PGP signature
Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed
On Aug 26, Jon Westgate <0...@fsck.tv> wrote: > The error message it gave was "decompresson failed with status 6" Status 6 is XZ_OPTIONS_ERROR, which means "Input was encoded with settings that are not supported by this XZ decoder". So it looks like you have compressed the modules (how?) with XZ settings which are supported by the userspace loader but not by the kernel one. -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
Control: reassign -1 udisks2
Control: retitle -1 do not mount automatically unmaintained file systems
On Jul 20, md wrote:
> You are totally correct.
> Kernel team, please blacklist HFS/HFS+ for automounting.
As discussed on debian-devel@, this policy should not be handled by the
kernel because modules autoloading of file systems drivers should not be
disabled.
So I propose this content for a file like
/usr/lib/udev/rules.d/75-insecure-fs.rules:
# Do not automatically mount these file systems because their drivers are
# marked as "orphan" or "odd fixes" in the kernel MAINTAINERS file and so
# are more at risk of having security-sensitive defects which could be
# exploited by a crafted file system.
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="affs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="ecryptfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="efs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jffs2", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="qnx6", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="sysv", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed
On Aug 26, Jon Westgate wrote: > Yes I am using compressed modules And are these modules compressed with xz or something else? This new code was introduced in the latest snapshot, and apparently it fails when used with kernels with compressed modules support enabled (which so far is not the default for Debian kenrels). -- ciao, Marco signature.asc Description: PGP signature
Bug#1050582: kmod update corrupts systemd uefi boot
On Aug 26, antonio wrote: > Kernel: Linux 6.4.12-1-liquorix-amd64 (SMP w/24 CPU threads; PREEMPT) I see that you are using a custom kernel. What is the status of the CONFIG_MODULE_COMPRESS_* kernel configuration options? -- ciao, Marco signature.asc Description: PGP signature
Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed
On Aug 26, Jon Westgate <0...@fsck.tv> wrote: > Kernel: Linux 6.4.11 (SMP w/12 CPU threads; PREEMPT) I see that you are using a custom kernel. What is the status of the CONFIG_MODULE_COMPRESS_* kernel configuration options? -- ciao, Marco signature.asc Description: PGP signature
Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed
On Aug 26, Jon Westgate <0...@fsck.tv> wrote: > The system partially booted but systemd then prevented boot due to missing > modules, > The error message it gave was "decompresson failed with status 6" Are you using compressed modules? -- ciao, Marco signature.asc Description: PGP signature
Bug#1050542: bookworm-pu: package openbsd-inetd/0.20221205-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:openbsd-inetd
This is needed to fix #1050208, introduced in bookworm, which makes
inetd crash on configuration reloads.
The fix is in the change to patches/default_v4v6, everything else is
improvements to the test suite and more tests (also to catch this
specific problem).
0.20221205-2+deb12u1 is a no changes rebuild of the package currently in
testing.
For a better view of the changes please see
https://salsa.debian.org/md/openbsd-inetd/-/commits/master .
--
ciao,
Marco
diff -Nru openbsd-inetd-0.20221205/debian/changelog openbsd-inetd-0.20221205/debian/changelog
--- openbsd-inetd-0.20221205/debian/changelog 2023-01-02 14:33:50.0 +0100
+++ openbsd-inetd-0.20221205/debian/changelog 2023-08-26 00:34:16.0 +0200
@@ -1,8 +1,21 @@
+openbsd-inetd (0.20221205-2+deb12u1) bookworm; urgency=medium
+
+ * Rebuilt for bookworm.
+
+ -- Marco d'Itri Sat, 26 Aug 2023 00:34:16 +0200
+
+openbsd-inetd (0.20221205-2) unstable; urgency=medium
+
+ * Updated the Debian patch default_v4v6 to fix fix a double free and
+a memory leak on configuration reloads. (Closes: #1050208)
+
+ -- Marco d'Itri Wed, 23 Aug 2023 12:49:41 +0200
+
openbsd-inetd (0.20221205-1) unstable; urgency=medium
* New CVS snapshot.
* When just "tcp" or "udp" is specified in inetd.conf, now inetd defaults
-to runnning two servers: one for IPv4 and one for IPv6 traffic.
+to running two servers: one for IPv4 and one for IPv6 traffic.
This is identical to specifying both e.g. "tcp4" and "tcp6".
The old semantics of only accepting IPv4 connections can be restored
by using "tcp4" or "udp4".
diff -Nru openbsd-inetd-0.20221205/debian/copyright openbsd-inetd-0.20221205/debian/copyright
--- openbsd-inetd-0.20221205/debian/copyright 2023-01-01 22:49:25.0 +0100
+++ openbsd-inetd-0.20221205/debian/copyright 2023-08-23 03:00:22.0 +0200
@@ -29,10 +29,3 @@
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
-setproctitle.c and discard_stupid_environment() come from netkit 0.17,
-patched by the USAGI project.
-
-strlcpy.c comes from the openbsd source tree, slightly edited.
-
-bsd-closefrom.c comes from the openssh source tree, slightly edited.
-
diff -Nru openbsd-inetd-0.20221205/debian/NEWS openbsd-inetd-0.20221205/debian/NEWS
--- openbsd-inetd-0.20221205/debian/NEWS 2023-01-02 03:09:21.0 +0100
+++ openbsd-inetd-0.20221205/debian/NEWS 2023-08-23 12:46:59.0 +0200
@@ -1,7 +1,7 @@
openbsd-inetd (0.20221205-1) unstable; urgency=medium
* When just "tcp" or "udp" is specified in inetd.conf, now inetd defaults
-to runnning two servers: one for IPv4 and one for IPv6 traffic.
+to running two servers: one for IPv4 and one for IPv6 traffic.
This is identical to specifying both e.g. "tcp4" and "tcp6".
The old semantics of only accepting IPv4 connections can be restored
by using "tcp4" or "udp4".
diff -Nru openbsd-inetd-0.20221205/debian/openbsd-inetd.preinst openbsd-inetd-0.20221205/debian/openbsd-inetd.preinst
--- openbsd-inetd-0.20221205/debian/openbsd-inetd.preinst 2023-01-02 02:45:43.0 +0100
+++ openbsd-inetd-0.20221205/debian/openbsd-inetd.preinst 2023-08-23 03:06:12.0 +0200
@@ -54,14 +54,6 @@
install)
create_inetd
;;
-
-upgrade|abort-upgrade)
-;;
-
-*)
-echo "$0 called with unknown argument '$1'" >&2
-exit 1
-;;
esac
#DEBHELPER#
diff -Nru openbsd-inetd-0.20221205/debian/patches/default_v4v6 openbsd-inetd-0.20221205/debian/patches/default_v4v6
--- openbsd-inetd-0.20221205/debian/patches/default_v4v6 2023-01-02 02:30:41.0 +0100
+++ openbsd-inetd-0.20221205/debian/patches/default_v4v6 2023-08-23 02:45:43.0 +0200
@@ -44,37 +44,35 @@
int val;
int argc;
+ static int proto_override;
-+ static char *saved_cp;
++ static char saved_line[1024];
sep = calloc(1, sizeof(struct servtab));
if (sep == NULL) {
-@@ -1165,6 +1167,14 @@ getconfigent(void)
+@@ -1165,6 +1167,11 @@ getconfigent(void)
more:
freeconfig(sep);
+ if (proto_override) {
+ /* process again the same configuration entry */
-+ cp = saved_cp;
-+ saved_cp = NULL;
++ cp = saved_line;
+ } else {
-+ if (saved_cp)
-+ free(saved_cp);
+
while ((cp = nextline(fconfig)) && *cp == '#')
;
if (cp == NULL) {
-@@ -1172,6 +1182,10 @@ more:
+@@ -1172,6 +1179,11 @@ more:
return (NULL);
}
-+ /* keep a copy of the configuration entry */
-+ saved_cp = newstr(cp);
-+ } /* proto_override */
++ /* keep a copy of the configuration entry */
++ strcpy(saved_line, cp);
++
++ } /* !proto_override */
+
memset(sep, 0, sizeof *sep);
Bug#1050208: libc6: double free detected in tcache 2, then abort
In one or two weeks I will also do a stable upload. -- ciao, Marco signature.asc Description: PGP signature
Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
On Aug 14, Stephen Frost wrote: >If someone has some idea how to get them to care about ARC, I'd love to >hear about it, as I have folks on the one hand who view DKIM/DMARC as >too painful to set up but then they end up with bounces from gmail due >to my forwarding of messages through my server (which are being >ARC-signed by it and pass on that the SPF check was successful when they >arrived to my server)... I do not know of any situation in which DMARC adoption would improve deliverability, and most people that configure it are just engaging in cargo cult sysadmining. DMARC with p=reject is useful when the sender domain is a phishing victim, e.g. a financial organization, but most users do not need it. In other words: if these people want to support use cases like forwarding and participating to mailing lists then they should adopt DKIM and ignore DMARC. -- ciao, Marco signature.asc Description: PGP signature
Bug#1043094: gnome-flashback segfaults after unlocking the screen
Package: gnome-flashback Version: 3.46.0-2 Severity: important This started on August 2 and I have already seen 3 crashes. (gdb) where #0 0x55841ae65d2a in check_volume_queue (manager=0x55841bf80270 [GsdAutomountManager]) at ./gnome-flashback/libautomount-manager/gsd-automount-manager.c:211 #1 screensaver_signal_callback (proxy=, sender_name=, signal_name=, user_data=0x55841bf80270, parameters=) at ./gnome-flashback/libautomount-manager/gsd-automount-manager.c:365 #2 screensaver_signal_callback (proxy=, sender_name=, signal_name=, parameters=, user_data=0x55841bf80270) at ./gnome-flashback/libautomount-manager/gsd-automount-manager.c:353 #7 0x7f374612f5ff in (instance=instance@entry=0x55841c0bf530, signal_id=, detail=) at ../../../gobject/gsignal.c:3675 #3 0x7f37461153f8 in g_closure_invoke (closure=0x55841c0e2bb0, return_value=0x0, n_param_values=4, param_values=0x7ffea1ae19c0, invocation_hint=0x7ffea1ae1910) at ../../../gobject/gclosure.c:832 #4 0x7f374612801c in signal_emit_unlocked_R (node=node@entry=0x7ffea1ae1ac0, detail=detail@entry=0, instance=instance@entry=0x55841c0bf530, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffea1ae19c0) at ../../../gobject/gsignal.c:3980 #5 0x7f3746129951 in signal_emit_valist_unlocked --Type for more, q to quit, c to continue without paging--c (instance=instance@entry=0x55841c0bf530, signal_id=signal_id@entry=165, detail=detail@entry=0, var_args=var_args@entry=0x7ffea1ae1c20) at ../../../gobject/gsignal.c:3612 #6 0x7f374612f552 in g_signal_emit_valist (instance=0x55841c0bf530, signal_id=165, detail=0, var_args=0x7ffea1ae1c20) at ../../../gobject/gsignal.c:3355 #8 0x7f3746279da5 in on_signal_received (connection=, sender_name=0x7f370c0301b0 ":1.45", object_path=, interface_name=, signal_name=0x7f370c038b50 "ActiveChanged", parameters=0x7f370c0244d0, user_data=0x55841c0c3860) at ../../../gio/gdbusproxy.c:890 #9 0x7f3746267afb in emit_signal_instance_in_idle_cb (data=0x7f370c04e640) at ../../../gio/gdbusconnection.c:3802 #10 0x7f3746012449 in g_main_dispatch (context=context@entry=0x55841bc4cfc0) at ../../../glib/gmain.c:3476 #11 0x7f37460155b7 in g_main_context_dispatch_unlocked (context=0x55841bc4cfc0) at ../../../glib/gmain.c:4284 #12 g_main_context_iterate_unlocked (context=0x55841bc4cfc0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4349 #13 0x7f3746015e6f in g_main_loop_run (loop=0x55841bc81750) at ../../../glib/gmain.c:4551 #14 0x55841ae3d483 in main (argc=1, argv=0x7ffea1ae1fe8) at ./gnome-flashback/gf-main.c:203 (gdb) Module libudev.so.1 from deb systemd-254-1.amd64 Module libsystemd.so.0 from deb systemd-254-1.amd64 Stack trace of thread 8937: #0 0x55841ae65d2a n/a (gnome-flashback + 0x4dd2a) #1 0x7f37461153f8 g_closure_invoke (libgobject-2.0.so.0 + 0x163f8) #2 0x7f374612801c n/a (libgobject-2.0.so.0 + 0x2901c) #3 0x7f3746129951 n/a (libgobject-2.0.so.0 + 0x2a951) #4 0x7f374612f552 g_signal_emit_valist (libgobject-2.0.so.0 + 0x30552) #5 0x7f374612f5ff g_signal_emit (libgobject-2.0.so.0 + 0x305ff) #6 0x7f3746279da5 n/a (libgio-2.0.so.0 + 0x11ada5) #7 0x7f3746267afb n/a (libgio-2.0.so.0 + 0x108afb) #8 0x7f3746012449 n/a (libglib-2.0.so.0 + 0x56449) #9 0x7f37460155b7 n/a (libglib-2.0.so.0 + 0x595b7) #10 0x7f3746015e6f g_main_loop_run (libglib-2.0.so.0 + 0x59e6f) #11 0x55841ae3d483 n/a (gnome-flashback + 0x25483) #12 0x7f3745e016ca __libc_start_call_main (libc.so.6 + 0x276ca) #13 0x7f3745e01785 __libc_start_main_impl (libc.so.6 + 0x27785) #14 0x55841ae3d561 n/a (gnome-flashback + 0x25561) Stack trace of thread 8994: #0 0x7f37460015b5 g_hash_table_lookup (libglib-2.0.so.0 + 0x455b5) #1 0x7f374612e6e1 g_signal_handlers_destroy (libgobject-2.0.so.0 + 0x2f6e1) #2 0x7f374611994d n/a (libgobject-2.0.so.0 + 0x1a94d) #3 0x7f374611a3c0 g_object_unref (libgobject-2.0.so.0 + 0x1b3c0) #4 0x7f374627f987 n/a (libgio-2.0.so.0 + 0x120987) #5 0x7f37462127c3 n/a (libgio-2.0.so.0 + 0xb37c3) #6 0x7f37462127f9 n/a (libgio-2.0.so.0 + 0xb37f9) #7 0x7f3746012449 n/a (libglib-2.0.so.0 + 0x56449) #8 0x7f37460155b7 n/a (libglib-2.0.so.0 + 0x595b7) #9 0x7f3746015e6f g_main_loop_run (libglib-2.0.so.0 + 0x59e6f) #10 0x7f374627d8a6 n/a (libgio-2.0.so.0 + 0x11e8a6) #11 0x7f374604207d n/a (libglib-2.0.so.0 + 0x8607d) #12 0x7f3745e623ec start_thread (libc.so.6 + 0x883ec) #13 0x7f3745ee2a1c __clone3 (libc.so.6 + 0x108a1c) Stack trace of thread 8976: #0 0x7f3745e5f156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7f3745e61818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x7f3740111369 n/a (radeonsi_dri.so + 0x111369) #3 0x7f37400c502b n/a (radeonsi_dri.so + 0xc502b) #4
Bug#1041892: debchange --bpo ignores -D
Package: devscripts Version: 2.23.5 Severity: normal If I run e.g. "debchange -D bullseye-backports --bpo" then debchange should be smart enough to use the correct value for the changelog entry and for the package version, but instead it defaults to the current stable release: package (8.1-1~bpo12+1) bullseye-backports; urgency=medium * Rebuild for bookworm-backports. -- ciao, Marco signature.asc Description: PGP signature
Bug#1041552: HFS/HFS+ are insecure
On Jul 21, Matthew Garrett wrote: > > You are totally correct. > > Kernel team, please blacklist HFS/HFS+ for automounting. > Isn't this a userland policy decision? udisks will happily trigger a > module load for hfsplus if udev has identified it, and I don't think > there's a trivial mechanism for the kernel to disable that. I believe Yes, I was also thinking about this and I believe that you are right. The kernel team did this in the past for some uncommon network protocols, but they could do it themselves because these modules are autoloaded using aliases. Since I happen to be the kmod maintainer it looks like that solving this is on me. :-) Unless somebody has a better idea then then my plan is to ship in the next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist directive to prevent automatically loading some file system modules. By looking at the MAINTAINERS file I have identified these file systems marked as "orphan" and "odd fixes": efs hfs hfaplus qnx6 sysv affs ecryptfs jffs2 jfs And I think that I can also safely add a few more which while actively maintained I believe are only used in a retrocomputing context or are generally uncommon anyway: befs bfs hpfs omfs qnx4 reiserfs spu ufs Did i miss anything? I think that all of these have enough of a niche usage that it would not be an unreasonable burden for the affected users to manually load the modules when needed (ad hoc or using /etc/modules-load.d/). -- ciao, Marco signature.asc Description: PGP signature
Bug#1039919: Please consider the ssh-agent socket activation patch
Source: openssh Severity: wishlist Tags: patch It would be nice to have this patch added to the Debian package: http://lists.mindrot.org/pipermail/openssh-unix-dev/2023-June/040812.html -- ciao, Marco signature.asc Description: PGP signature
Bug#1039913: Please add hook for self-signing systemd-boot after upgrade
On Jun 29, Jan Naumann wrote: > Could you please add a hook to the postinst that either a local script can be > called on installation time which takes care of signing the image (similar to > the `/etc/kernel/postinst.d/ mechamism) or add some call to `sbsign` yourself > if > e.g. the signing key is available at a specific path. I am working on packaging sbctl (which I believe is *much* nicer[1] than sbsigntool and mokutil), so I plan to do some work in this area in the future. But I am not sure yet of which shape this interface should have. Part of the issue is that at least sbctl signs the installed binaries in place, while bootctl looks for .efi.signed files in the source directory, and "bootctl install" could also be run manually at any time. But since systemd-bootx64.efi comes from /usr/lib/systemd/boot/efi/ it would not be right to have something which is not the package manager install a .efi.signed file there, so I suspect that this cannot be solved just with some shell scripting. And for the time being there are zero chances that Debian (or anybody else, I understand) will be able to ship a signed systemd-boot, so this is not a useful interface right now. [1] https://blog.bofh.it/debian/id_465 -- ciao, Marco signature.asc Description: PGP signature
Bug#1039522: usrmerge: cannot complete upgrade to bookworm because of #842145
On Jun 26, Giuseppe Sacco wrote: > Warning: NFS detected, /usr/lib/usrmerge/convert-usrmerge will not be run > automatically. See #842145 for details. What is the purpose of opening this new bug about the same issue? -- ciao, Marco signature.asc Description: PGP signature
Bug#1038853: usrmerge: clean up the unused empty biarch directories
Release managers, I would like to upload to 12.1 a new package to fix
this (and other minor issues).
On Jun 22, Andreas Beckmann wrote:
> Package: usrmerge
> Version: 35
> Severity: important
> Tags: patch
>
> bootstrapping a merged-/usr system or earlier conversions may have
> created empty biarch directories and links to them, e.g.
> /usr/libx32
> /libx32 -> /usr/libx32
>
> Since glibc 2.35-4 this is handled by the respective glibc packages
> and usrmerge has stopped creating them.
>
> So let's clean them up (once) on upgrades of the usrmerge/usr-is-merged
> packages if they are not owned by any package according to the dpkg
> database. Otherwise they might suddenly disappear after installation and
> removal of a package "owning" them.
>
> While the existence/disappearance of these directories and links is
> harmless for a regular system, it is nasty for doing QA testing since
> that may trigger an error on sudden disappearance of files/directories
> (at non-volatile locations). Ignoring these locations is not a good
> idea, since it might hide actual bugs mishandling the biarc locations.
>
> I've been running piuparts bullseye -> bookworm upgrade tests with this
> patch applied and that solved all the unexpected disappearance of biarch
> directories and links.
>
>
> Andreas
> >From 6a07b047055ef2d05ab3381f9f7ce64c21f6b60b Mon Sep 17 00:00:00 2001
> From: Andreas Beckmann
> Date: Sun, 28 May 2023 14:20:21 +0200
> Subject: [PATCH] postinst: Clean up the unused empty biarch directories
>
> bootstrapping or earlier conversions may have created empty biarch
> directories and links. glibc 2.35-4 or later will create them if
> needed, so clean up the unused (and unowned) ones
>
> Closes: #
> ---
> debian/usr-is-merged.postinst | 28
> debian/usrmerge.postinst | 22 +-
> 2 files changed, 49 insertions(+), 1 deletion(-)
> create mode 100644 debian/usr-is-merged.postinst
>
> diff --git a/debian/usr-is-merged.postinst b/debian/usr-is-merged.postinst
> new file mode 100644
> index 000..3d0e0c5
> --- /dev/null
> +++ b/debian/usr-is-merged.postinst
> @@ -0,0 +1,28 @@
> +#!/bin/sh
> +set -e
> +
> +cleanup_biarch_dirs() {
> + # bootstrapping or earlier conversions may have created empty biarch
> + # directories and links. glibc 2.35-4 or later will create them if needed,
> + # so clean up the unused (and unowned) ones
> + local arch_directories="/lib64 /lib32 /libo32 /libx32"
> + for dir in $arch_directories; do
> +[ -e "$dir" ] || continue
> +if ! dpkg-query -S $dir >/dev/null 2>&1; then
> + rm -v $dir
> + if [ -e /usr$dir ] && ! dpkg-query -S /usr$dir >/dev/null 2>&1 ; then
> +rmdir --ignore-fail-on-non-empty -v /usr$dir
> + fi
> +fi
> + done
> +}
> +
> +case "$1" in
> +configure)
> + if dpkg --compare-versions "$2" lt "36~" ; then
> +cleanup_biarch_dirs
> + fi
> +;;
> +esac
> +
> +#DEBHELPER#
> diff --git a/debian/usrmerge.postinst b/debian/usrmerge.postinst
> index 257f0e5..057b7f1 100644
> --- a/debian/usrmerge.postinst
> +++ b/debian/usrmerge.postinst
> @@ -1,4 +1,5 @@
> -#!/bin/sh -e
> +#!/bin/sh
> +set -e
>
> is_fs() {
>local fs_type
> @@ -49,6 +50,22 @@ END
>/usr/lib/usrmerge/convert-usrmerge || return $?
> }
>
> +cleanup_biarch_dirs() {
> + # bootstrapping or earlier conversions may have created empty biarch
> + # directories and links. glibc 2.35-4 or later will create them if needed,
> + # so clean up the unused (and unowned) ones
> + local arch_directories="/lib64 /lib32 /libo32 /libx32"
> + for dir in $arch_directories; do
> +[ -e "$dir" ] || continue
> +if ! dpkg-query -S $dir >/dev/null 2>&1; then
> + rm -v $dir
> + if [ -e /usr$dir ] && ! dpkg-query -S /usr$dir >/dev/null 2>&1 ; then
> +rmdir --ignore-fail-on-non-empty -v /usr$dir
> + fi
> +fi
> + done
> +}
> +
> case "$1" in
> configure)
> # Skip the conversion for buildds.
> @@ -59,6 +76,9 @@ case "$1" in
> echo "W: /etc/unsupported-skip-usrmerge-conversion exists." >&2
> else
> maybe_convert "$@" || { echo "E: usrmerge failed." >&2; exit 1; }
> + if dpkg --compare-versions "$2" lt "36~" ; then
> + cleanup_biarch_dirs
> + fi
> /usr/lib/usrmerge/convert-etc-shells
> fi
> ;;
> --
> 2.20.1
>
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Jun 13, Bill Allombert wrote: > Conversely, sometimes I need to use chroots to test init scripts. > start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows > it. I suggest that you try systemd-nspawn for this purpose. -- ciao, Marco signature.asc Description: PGP signature
Bug#1037362: usrmerge: Can not run due to an open file handle (GLOB) that it seems is not possible to close
retitle -1 1037362 usrmerge: fails to run ldd On Jun 13, Lawrence Bayly wrote: > Spoke too soon, usrmerge broke my system worse than I could have > imagined, /usr/bin/init went to systemd but in the old place > /lib/systemd (the lib folder was either empty or not there, likely > because of the usrmerge), fixing that didn't really do much as > I suspect a whole bunch of other stuff was moved without the system > really knowing where it all was. (I could have sat there moving stuff > around or symlinking to hopefully solve the problem but in the end it > seemed like alot of work) At this point it is not really clear to me what you have done, but please note that since convert-usrmerge failed running ldd it means that it did not modify your system in any way. So this looks like auto-inflicted damage to me. I will keep this bug around for a while to see if anybody else shows up with the same problem and to improve the error message. -- ciao, Marco signature.asc Description: PGP signature
Bug#1037362: usrmerge: Can not run due to an open file handle (GLOB) that it seems is not possible to close
On Jun 12, Lawrence Bayly wrote: > root@cg-sg:/tmp/coreutils/bin# ldd /bin/cp > not a dynamic executable > root@cg-sg:/tmp/coreutils/bin# file /bin/cp > /bin/cp: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically > linked, interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=e8f03b272b3dbd03cc8748cf2b52744a58d0cf5c, for GNU/Linux 3.2.0, > stripped This is the correct file. Is your ldd weird then? It should look like this: -rwxr-xr-x 1 root root 5398 Apr 10 10:35 /usr/bin/ldd Please also report the output of: - dpkg -l libc-bin - which ldd - ldd --version -- ciao, Marco signature.asc Description: PGP signature
Bug#1037362: usrmerge: Can not run due to an open file handle (GLOB) that it seems is not possible to close
On Jun 12, Lawrence Bayly wrote: > root@cg-sg:~# file /bin/cp > /bin/cp: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically > linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=3a0bad79264ea6b37c1b8d4dd2b206b8001097dc, stripped Interesting. I am still trying to figure out why ldd does not work on it. > The upgrade did kinda go badly and I did lose libcrypt.so.1 at one > point earlier in the upgrade for some odd reason which meant perl > wouldn't run (and that script wouldn't run either as it depended on > perl) until I copied it back, so it potentially could be that /bin/cp > is also an outdated binary. This happened because you upgraded while skipping a release, and this is not supported. > Should I copy /bin/cp from another debian system and try again? Reinstalling the coreutils package should be enough, but I wonder at this point what else is broken on your system. -- ciao, Marco signature.asc Description: PGP signature
Bug#1037362: usrmerge: Can not run due to an open file handle (GLOB) that it seems is not possible to close
On Jun 12, Lawrence Bayly wrote: > The output is as follows:- > > root@cg-sg:~# ldd /bin/cp >not a dynamic executable Weird. Is /bin/cp a script then? Where does it come from? -- ciao, Marco
Bug#1037362: usrmerge: Can not run due to an open file handle (GLOB) that it seems is not possible to close
On Jun 12, Lawrence Bayly wrote: > FATAL ERROR: > Can't close(GLOB(0x564e905c3aa0)) filehandle: '' at > /usr/lib/usrmerge/convert-usrmerge line 222 This is not an open file but the call to ldd, the default error message is stupid. Please report the output and exit status of "ldd /bin/cp". -- ciao, Marco signature.asc Description: PGP signature
Bug#1037257: is 5 years out of date, has warnings
Package: python3-junos-eznc
Version: 2.1.7-5
Severity: normal
2.1.7 was released in 2017.
Running a playbook which depends on this package makes Ansible emit
these warning:
/usr/lib/python3/dist-packages/jnpr/junos/device.py:838: SyntaxWarning: "is
not" with a literal. Did you mean "!="?
if rpc_rsp_e.text is not None and rpc_rsp_e.text.strip() is not '':
/usr/lib/python3/dist-packages/jnpr/junos/device.py:1222: SyntaxWarning: "is
not" with a literal. Did you mean "!="?
if auto_probe is not 0:
/usr/lib/python3/dist-packages/jnpr/junos/rpcmeta.py:145: SyntaxWarning: "is
not" with a literal. Did you mean "!="?
if model and filter_xml is None and options.get('format') \
/usr/lib/python3/dist-packages/jnpr/junos/utils/start_shell.py:147:
SyntaxWarning: "is not" with a literal. Did you mean "!="?
self.last_ok = got is not ''
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On May 29, Luca Boccassi wrote: > Does it matter that much if the empty directory is removed? Next time > a package shipping a modules-load config is installed it will be just > re-added, no? Or are there functional issues? I do not think that it is a big deal if /usr/lib/modules-load.d/ disappears from time to time. Local users are expected to install local files in /etc/modules-load.d/ anyway. -- ciao, Marco signature.asc Description: PGP signature
Bug#1034053: segfaulted on quit
> This happened while/after saving a mailbox on quit. > Apparently nothing was corrupted. Again: warning: Section `.reg-xstate/3368169' in core file too small. #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 Download failed: Argomento non valido. Continuing without source file ./nptl/./nptl/pthread_kill.c. 44 ./nptl/pthread_kill.c: File o directory non esistente. (gdb) where #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7f765179ad2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7f765174bef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7f7651736472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7f765178f2d0 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f76518a9459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #5 0x7f76517a464a in malloc_printerr ( str=str@entry=0x7f76518ac118 "double free or corruption (out)") at ./malloc/malloc.c:5660 #6 0x7f76517a66b0 in _int_free (av=0x7f76518e2c60 , p=0x7f76518e2d40 , have_lock=, have_lock@entry=0) at ./malloc/malloc.c:4584 #7 0x7f76517a8d2f in __GI___libc_free (mem=) at ./malloc/malloc.c:3385 #8 0x5653d28c5fe1 in safe_free (ptr=0x7f76518e2d60 ) at ../../lib.c:198 #9 0x5653d28ab928 in rfc822_free_address (p=0x5653d4eae8a0) at ../../rfc822.c:140 #10 0x5653d28c916c in mutt_free_envelope (p=0x5653d4eae880) at ../../muttlib.c:875 #11 0x5653d28c95a7 in mutt_free_body (p=0x5653d53298d8) --Type for more, q to quit, c to continue without paging--c at ../../muttlib.c:208 #12 0x5653d28c95bc in mutt_free_body (p=0x5653d5329768) at ../../muttlib.c:211 #13 0x5653d28c9376 in mutt_free_header (h=0x5653d4bd0908) at ../../muttlib.c:382 #14 0x5653d2891dd1 in mx_fastclose_mailbox (ctx=ctx@entry=0x5653d4d9ada0) at ../../mx.c:736 #15 0x5653d289288b in mx_close_mailbox (ctx=0x5653d4d9ada0, index_hint=index_hint@entry=0x7fffdc35a814) at ../../mx.c:1014 #16 0x5653d2862040 in mutt_index_menu () at ../../curs_main.c:1414 #17 0x5653d2842107 in main (argc=1, argv=0x7fffdc35baa8, environ=) at ../../main.c:1400 (gdb) -- ciao, Marco signature.asc Description: PGP signature
Bug#1036523: should not enable non-free-firmware on virtualized systems
On May 22, Cyril Brulebois wrote: > For the record: non-free-firmware can be enabled because (1) the kernel logs > firmware requests, (2) available hardware matches modalias information, (3) > CPU matches one with microcode. > > (1) and (2) definitely make sense in a virtualized system as well: you can > have whatever passthrough configuration to access hardware from the host, > e.g. some USB Wi-Fi adapter (that's how I've tested many changes before > switching to baremetal for final tests). Fair enough: if somebody is exposing the hardware devices to the guest OS then they can surely deal with the consequences. > > microcode packages should not be installed on virtualized systems because > > guests never have the privileges required to update the CPU microcode. > > Otherwise guests could influence the whole system and possibly undermine > > its security. > Is that true for absolutely all virtualization systems detected by the file > linked to above? Your latest message on IRC suggests we might have to pick > and choose? Did it? I am not aware of any scenario in which it would make sense for an hypervisor to allow guests to change the CPU microcode. I am not familiar with HyperV, but from what I remember from the my Xen times the dom0 is for most practical purposes the host, not a guest, so I am not sure that it is useful al all to report it do d-i as a virtualized environment. -- ciao, Marco signature.asc Description: PGP signature
Bug#1036523: should not enable non-free-firmware on virtualized systems
Source: hw-detect Version: 1.155 Severity: normal Tags: d-i When bookworm is installed on a virtualized system, the non-free-firmware component will be enabled even if this is not needed: firmwares cannot be loaded on virtualized systems because guests usually lack direct access to the hardware. As a workaround I had to preseed: d-i hw-detect/firmware-lookup string never As discussed on IRC with kibi, this is caused by hw-detect trying to install the microcode packages. This is the relevant code: https://salsa.debian.org/installer-team/hw-detect/-/blob/master/hw-detect.post-base-installer.d/50install-firmware#L51 https://salsa.debian.org/installer-team/hw-detect/-/blob/master/hw-detect.finish-install.d/08hw-detect microcode packages should not be installed on virtualized systems because guests never have the privileges required to update the CPU microcode. Otherwise guests could influence the whole system and possibly undermine its security. -- ciao, Marco signature.asc Description: PGP signature
Bug#1035673: unblock: whois/5.5.17
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: wh...@packages.debian.org Control: affects -1 + src:whois Please unblock package whois It contains a few database updates. unblock whois/5.5.17 diff --git a/debian/changelog b/debian/changelog index 741c74a..13123bc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +whois (5.5.17) unstable; urgency=medium + + [ Robert Scheck ] + * Added the .cd TLD server. + * Updated the -kg NIC handles server name. + + [ Marco d'Itri ] + * Removed 2 new gTLDs which are no longer active. + + -- Marco d'Itri Wed, 03 May 2023 14:24:37 +0200 + whois (5.5.16) unstable; urgency=medium * Add bash completion support, courtesy of Ville Skyttä. diff --git a/new_gtlds_list b/new_gtlds_list index 760c79f..12ff5b8 100644 --- a/new_gtlds_list +++ b/new_gtlds_list @@ -573,7 +573,6 @@ lilly limited limo lincoln -linde link lipsy live @@ -596,7 +595,6 @@ ltda lundbeck luxe luxury -macys madrid maif maison diff --git a/nic_handles_list b/nic_handles_list index 870ebd6..3fae1dd 100644 --- a/nic_handles_list +++ b/nic_handles_list @@ -8,7 +8,7 @@ -dkwhois.dk-hostmaster.dk -ilwhois.isoc.org.il -iswhois.isnic.is --kgwhois.domain.kg +-kgwhois.kg -coop whois.nic.coop -frnic whois.nic.fr -lrms whois.afilias.info diff --git a/servers_charset_list b/servers_charset_list index cc81a38..fa85e4e 100644 --- a/servers_charset_list +++ b/servers_charset_list @@ -38,7 +38,7 @@ whois.isnic.isiso-8859-1 whois.nic.it utf-8 whois.jprs.jp iso-2022-jp whois.nic.ad.jpiso-2022-jp -whois.domain.kgcp1251 +whois.kg cp1251 whois.nic.or.krutf-8 whois.kr utf-8 whois.nic.kz utf-8 diff --git a/tld_serv_list b/tld_serv_list index 948f005..cb480da 100644 --- a/tld_serv_list +++ b/tld_serv_list @@ -113,7 +113,7 @@ .co.ca whois.co.ca .cawhois.cira.ca .ccVERISIGN ccwhois.verisign-grs.com -.cdNONE +.cdwhois.nic.cd .cfNONE .cgNONE# www.nic.cg .chwhois.nic.ch -- ciao, Marco signature.asc Description: PGP signature
Bug#1035672: unblock: inn2/2.7.1-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: i...@packages.debian.org
Control: affects -1 + src:inn2
Please unblock package inn2
This is the diff betwwen 2.7.1 RC1 and 2.7.1.
It contains many documentation fixes, small fixes to pullnews and
a significant for ovsqlite-util.
It also adds a versioned Breaks on manpages-dev which fixes the RC bug
#1035098.
The 2.7.1 package is being used in production on one of my news servers.
Follows the git diff between debian/2.7.1_20230322-1 and debian/2.7.1-1,
abridged of whitespace and documentation changes.
The full changelog can be consulted at
https://salsa.debian.org/md/inn2/-/commits/master .
The package has a fairly decent autopkgtest but it currently cannot work
on the Debian infrastructure, because the workers do not have valid
hostnames. I will find a solution after the release, so please bear with
me once more. :-)
unblock inn2/2.7.1-1
diff --git a/Makefile.global.in b/Makefile.global.in
index db42dee2e..3a84f23e7 100644
--- a/Makefile.global.in
+++ b/Makefile.global.in
@@ -20,7 +20,7 @@
## be complying with the NNTP protocol.
VERSION= 2.7.1
-VERSION_EXTRA = rc1 version
+VERSION_EXTRA =
## The absolute path to the top of the build directory, used to find the
## libraries built as part of INN. Using relative paths confuses libtool
diff --git a/backends/news2mail.in b/backends/news2mail.in
index bef6ca86a..952cf4610 100644
--- a/backends/news2mail.in
+++ b/backends/news2mail.in
@@ -104,9 +104,15 @@ sub mailto {
my ($t, $s, @a) = @_;
my $sendmail = $INN::Config::mta;
+# Remove %s and -f from the mta command line (we'll explicitly set
+# recipients and an envelope sender below).
+# Remove -oem as we'll set -oee so that sendmail exits with a
+# non-zero status only if the mail cannot be sent.
$sendmail =~ s!\s*%s!!;
+$sendmail =~ s!(^|\s+)-f\s*\S*!!;
+$sendmail =~ s!(^|\s+)-oem!!;
my @command = (
-split(' ', $sendmail), '-ee', '-odq', "-f$s",
+split(' ', $sendmail), '-oee', '-odq', "-f$s",
"-pNNTP:$INN::Config::pathhost", @a
);
diff --git a/debian/changelog b/debian/changelog
index eff319e64..eeaf10caa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+inn2 (2.7.1-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Breaks manpages-dev << 6.03-2 to make upgrades smoother, because of
+file(3) and list(3) removed from inn2-dev 2.6.5-1. (Closes: #1035098)
+
+ -- Marco d'Itri Mon, 01 May 2023 19:25:42 +0200
+
inn2 (2.7.1~20230322-1) unstable; urgency=medium
* New release candidate 1 of the stable branch.
diff --git a/debian/control b/debian/control
index 93d37618c..8d7089372 100644
--- a/debian/control
+++ b/debian/control
@@ -63,6 +63,7 @@ Package: inn2-dev
Section: devel
Architecture: any
Depends: ${misc:Depends}
+Breaks: manpages-dev (<< 6.03-2)
Conflicts: inn
Description: libinn.a library, headers and man pages
You will only need this if you are going to compile programs that
diff --git a/frontends/pullnews.in b/frontends/pullnews.in
index b21ce29b4..0d8809cec 100644
--- a/frontends/pullnews.in
+++ b/frontends/pullnews.in
@@ -100,6 +100,7 @@ my $defaultRetryTime = 1;
my $defaultProgressWidth = 50;
my $defaultMaxArts;
my $lockfile;
+my $runEndBlock = 0;
# Check whether pullnews is run inside INN.
my $use_inn_shlock = 0;
@@ -120,6 +121,8 @@ if (not $use_inn_shlock) {
}
END {
+return unless $runEndBlock;
+
# In case we bail out, while holding a lock.
if ($use_inn_shlock) {
INN::Utils::Shlock::releaselocks();
@@ -423,7 +426,7 @@ if ($use_inn_shlock) {
INN::Utils::Shlock::lock($lockfile)
or die "cannot create lockfile $lockfile\n";
} else {
-sysopen(LOCK, "$lockfile", O_RDWR | O_CREAT, 0700)
+sysopen(LOCK, "$lockfile", O_RDWR | O_CREAT, 0644)
or die "cannot create lockfile $lockfile: $!\n";
$oldfh = select;
select LOCK;
@@ -439,6 +442,9 @@ if ($use_inn_shlock) {
print LOCK "$$\n";
}
+# Now that a lock file has been created, ensure we release it when this process
+# ends or is stopped.
+$runEndBlock = 1;
print LOG scalar(localtime(time)), " start\n\n" unless $quiet;
@@ -554,6 +560,7 @@ if (not $quiet and not $quietness) {
}
my $connectionAttempts = 0;
+my %groupsStarted = ();
UPSTREAM:
foreach my $server (@servers) {
@@ -683,6 +690,7 @@ foreach my $server (@servers) {
} continue {
# Reinitialize the counter for the next server.
$connectionAttempts = 0;
+%groupsStarted = ();
}
saveConfig();
@@ -768,7 +776,8 @@ sub stats {
sub saveConfig {
return if $no_op;
-$SIG{INT} = $SIG{QUIT} = 'IGNORE';
+local $SIG{INT} = 'IGNORE';
+local $SIG{QUIT} = 'IGNORE';
open(FILE, ">$groupFile"
Bug#1035390: mirror submission for mirrors.qontinuum.space
On May 03, Qontinuum wrote: > The server is plugged on the ISP's router which is itself linked on fiber > optics. Why such question? Because this looks very much like some kind of consumer/small business internet service, unsuitable for hosting a public mirror. -- ciao, Marco signature.asc Description: PGP signature
Bug#1035390: mirror submission for mirrors.qontinuum.space
On May 03, Qontinuum wrote: > It isn't located in a datacenter and it has 1Gbps uplink bandwidth. Please describe what kind of connectivity. -- ciao, Marco signature.asc Description: PGP signature
Bug#1035390: mirror submission for mirrors.qontinuum.space
On May 02, Qontinuum wrote: > Country: MC Monaco > Location: Monaco > Sponsor: Q Continuum https://qontinuum.space > Comment: This site replaces debian.qontinuum.space that no longer exist Can you clarify which data center is hosting this server and how much bandwidth is available to it? -- ciao, Marco signature.asc Description: PGP signature
Bug#1034958: Consequence of #951598
On Apr 29, Helge Kreutzmann wrote: > Reverse, I believe manpages-dev should declare: > Breaks: inn2-dev (<< 2.7.0-1) > Replaces: inn2-dev (<< 2.7.0-1) > > Is this fine for you? Yes. -- ciao, Marco signature.asc Description: PGP signature
Bug#1034958: Consequence of #951598
Would this work for you? Please let me know ASAP since the hard freeze is very close. Package: inn2-dev Breaks: manpages-dev (<< 6.03-2) -- ciao, Marco signature.asc Description: PGP signature
Bug#1034468: unblock: inn2/2.7.1~20230322-1
On Apr 26, Paul Gevers wrote: > PS: have you considered adding a non-superficial autopkgtest to your package > such that you don't need to wait for us to unblock your package? Yes, long story. There is actually one but it is not run, because it needs to be significantly modified to actually work on our CI infrastructure, because inn2 cannot be installed on systems without a valid hostname. -- ciao, Marco signature.asc Description: PGP signature
Bug#1034586: always reports inactive/expired certificate on armhf
On Apr 21, gs-debian@gluelogic.com wrote: > I probably should have started with the most basic thing: > > What is the date on your device? NTP-accurate. -- ciao, Marco signature.asc Description: PGP signature
Bug#1034586: always reports inactive/expired certificate on armhf
On Apr 21, gs-debian@gluelogic.com wrote: > What your `uname -a` ? Linux omitted.mi.bofh.it 6.1.0-7-arm64 #1 SMP Debian 6.1.20-2 (2023-04-08) aarch64 GNU/Linux > What is the output of the following for you? > $ lighttpd -V | grep "Y2038 support" > + Y2038 support Same. Thank you for your help. -- ciao, Marco signature.asc Description: PGP signature
