Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers

[Salvatore Bonaccorso]

Hi Christoph,

On Fri, Apr 30, 2021 at 05:32:43PM +0200, Christoph Martin wrote:
> 
> 
> Am 30.04.21 um 14:32 schrieb Salvatore Bonaccorso:
> > 
> > is this problem still relevant?
> > 
> 
> I think so. My upstream request was never really considered.
> You still have the problem that a kernel-nfs server with only few memory
> runs out of sessions with a lot of clients.

Ack thans for confirming. So either someone tries to bring that issue
again to upstream or alternatively we could then close this bug
marking (and possibly marking it wontfix).

> > Side note that we would anyway not apply a patch which would not have
> > been accepted upstream, likely unless there are very valid reasons.
> > 
> 
> Yes I also think so.
> 
> We changed to nfs-ganesha as a user level NFS server, which does not
> have this restriction.

Thanks for this additional comment.

Thanks as well for your promt reply back!

Regards,
Salvatore

Bug#741663: G4 MDD report (finally) Re: Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Here's the data from the G4 MDD.  Sorry for the delay getting it out!

rbthomas@macswell:~$ cat /proc/cpuinfo 
processor   : 0
cpu : 7455, altivec supported
clock   : 1416.61MHz
revision: 3.3 (pvr 8001 0303)
bogomips: 83.31

processor   : 1
cpu : 7455, altivec supported
clock   : 1416.61MHz
revision: 3.3 (pvr 8001 0303)
bogomips: 83.31

total bogomips  : 166.63
timebase: 41659125
platform: PowerMac
model   : PowerMac3,6
machine : PowerMac3,6
motherboard : PowerMac3,6 MacRISC3 Power Macintosh
detected as : 129 (PowerMac G4 Windtunnel)
pmac flags  : 0010
L2 cache: 256K unified
pmac-generation : NewWorld
Memory  : 2048 MB

rbthomas@macswell:~$ cat /proc/version 
Linux version 5.10.0-6-powerpc-smp (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.28-1 (2021-04-09)

rbthomas@macswell:~$ lsmod | grep wind
therm_windtunnel7229  0

The fans come on at low speed when I give the CPU a short workout.  I haven't 
tried a long-term CPU intensive task yet.

Hope this helps!
Rick

On Tue, Apr 27, 2021, at 3:55 PM, Rick Thomas wrote:
> 
> 
> On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> 
> > On 4/27/21 8:54 AM, Rick Thomas wrote:
> > > I'll look around and see if I have any MDD (mirror drive door -- the type 
> > > in the
> > > original bugreport) machines.  If so, I'll try to find some time to 
> > > install Adrian's
> > > latest and report back.
> > 
> > OK, thank you. Maybe someone else with a machine that previously had 
> > this issue can also
> > comment so that we can be sure the issue has been fixed.
> > 
> > Rick, maybe you can check whether the windfarm module(s) get(s) loaded 
> > on your machine?
> > 
> > # lsmod |grep windfarm
> 
> On the G4 (which is _not_ the MDD) I get nothing from that
> 
> On the G5 I get:
> 
> rbthomas@kmac:~$ lsmod | grep wind
> windfarm_smu_sat8626  0
> windfarm_ad7417_sensor 7755  0
> windfarm_fcu_controls12227  0
> windfarm_cpufreq_clamp 3881  0
> windfarm_pm72  14329  0
> windfarm_pid3256  1 windfarm_pm72
> windfarm_lm75_sensor 5350  0
> windfarm_max6690_sensor 4600  0
> windfarm_core  11920  7 
> windfarm_cpufreq_clamp,windfarm_fcu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_ad7417_sensor,windfarm_pm72,windfarm_lm75_sensor
> 
> Hope that helps.
> Rick
> 
> PS: I do have a MDD, but I haven't yet tried Adrian's latest on it.  
> Maybe later today, maybe it'll have to wait for the weekend.
> 

Bug#987759: RFS: color-picker/1.0.1-1 [ITP] -- Powerful screen color picker based on Qt

[Hugo Torres]

Necessary the creation of the Debian repository in Salsa.

I created the repository in my account to make the migration: 
https://salsa.debian.org/f9kill/colorpicker

--
Hugo Torres de Lima
GPG: 4AF1 1173 DCAD 0380 CC43 A5C6 365C 8CEF 4233 E3D8

Sent with ProtonMail Secure Email.

signature.asc
Description: OpenPGP digital signature

Bug#987863: unblock: debian-reference/2.78

[Osamu Aoki]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package debian-reference

[ Reason ]
Need to be unblocked since this is a key package

[ Impact ]
1. Miss translation updates (es, zh_CN, nb, it, po)
2. Miss updates for CUPS 1.6 #941801
3. Miss updates for copyright. #979863

[ Tests ]
This is documentation package.

[ Risks ]
None.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach diff against the source package in testing (excluding PO)

[ Other info ]

unblock debian-reference/2.78
diff -Nru debian-reference-2.77/debian/changelog 
debian-reference-2.78/debian/changelog
--- debian-reference-2.77/debian/changelog  2021-01-10 15:36:06.0 
+0900
+++ debian-reference-2.78/debian/changelog  2021-04-10 22:44:39.0 
+0900
@@ -1,3 +1,14 @@
+debian-reference (2.78) unstable; urgency=medium
+
+  [ xiao sheng wen (肖盛文) ]
+  * Update the copyright to 2021. Closes: #979863
+  * Update printing for post-CUPS 1.6. Closes: #941801 (reopened)
+
+  [ Osamu Aoki ]
+  * Many translation updates (es, zh_CN, nb, it, po)
+
+ -- Osamu Aoki   Sat, 10 Apr 2021 22:44:39 +0900
+
 debian-reference (2.77) unstable; urgency=medium
 
   [ Holger Wansing ]
diff -Nru debian-reference-2.77/debian/rules debian-reference-2.78/debian/rules
--- debian-reference-2.77/debian/rules  2021-01-10 15:36:06.0 +0900
+++ debian-reference-2.78/debian/rules  2021-01-16 21:32:57.0 +0900
@@ -81,4 +81,3 @@
-rm -f $(addsuffix .doc-base, $(addprefix  debian/$(MANUAL)-, 
$(LANGALL)))
-rm -f $(addsuffix .install,  $(addprefix  debian/$(MANUAL)-, 
$(LANGALL)))
$(MAKE) "LANGALL=$(LANGALL)" "LANGPO=$(LANGPO)"  clean
-
diff -Nru debian-reference-2.77/Makefile debian-reference-2.78/Makefile
--- debian-reference-2.77/Makefile  2021-01-10 15:36:06.0 +0900
+++ debian-reference-2.78/Makefile  2021-01-16 21:32:57.0 +0900
@@ -66,7 +66,7 @@
 #DEBM  :=  http://ftp.jp.debian.org/debian/dists
 DEBM   :=  http://deb.debian.org/debian/dists
 # Debian popcon data source URL
-UPOPC  :=  http://popcon.debian.org/all-popcon-results.txt.gz
+UPOPC  :=  https://popcon.debian.org/all-popcon-results.txt.gz
 # Debian release name and arch used
 CODE   :=  sid
 ARCH   :=  amd64
diff -Nru debian-reference-2.77/po/es.po debian-reference-2.78/po/es.po
diff -Nru debian-reference-2.77/po/it.po debian-reference-2.78/po/it.po
diff -Nru debian-reference-2.77/po/nb.po debian-reference-2.78/po/nb.po
diff -Nru debian-reference-2.77/po/pt.po debian-reference-2.78/po/pt.po
diff -Nru debian-reference-2.77/po/zh-cn.po debian-reference-2.78/po/zh-cn.po
diff -Nru debian-reference-2.77/rawxml/00_bookinfo.rawxml 
debian-reference-2.78/rawxml/00_bookinfo.rawxml
--- debian-reference-2.77/rawxml/00_bookinfo.rawxml 2021-01-10 
15:36:06.0 +0900
+++ debian-reference-2.78/rawxml/00_bookinfo.rawxml 2021-04-10 
22:31:38.0 +0900
@@ -9,7 +9,7 @@
   This book is free; you may redistribute it and/or modify it under 
the terms of the GNU General Public License of any version compliant to the 
Debian Free Software Guidelines (DFSG).
 
 
-  2013-2018
+  2013-2021
   Osamu Aoki
 
 
diff -Nru debian-reference-2.77/rawxml/06_network_applications.rawxml 
debian-reference-2.78/rawxml/06_network_applications.rawxml
--- debian-reference-2.77/rawxml/06_network_applications.rawxml 2021-01-10 
15:36:06.0 +0900
+++ debian-reference-2.78/rawxml/06_network_applications.rawxml 2021-04-10 
22:31:38.0 +0900
@@ -1853,9 +1853,10 @@
 
 
   The print server and utilities
-  In the old Unix-like system, the BSD https://en.wikipedia.org/wiki/Line_Printer_Daemon_protocol;>Line printer 
daemon was the standard.  Since the standard print out format of the 
free software is PostScript on the Unix like system, some filter system was 
used along with https://en.wikipedia.org/wiki/Ghostscript;>Ghostscript to enable 
printing to the non-PostScript printer.
-  Recently, https://en.wikipedia.org/wiki/Common_Unix_Printing_System;>Common UNIX 
Printing System (CUPS) is the new de facto standard.  The CUPS uses 
https://en.wikipedia.org/wiki/Internet_Printing_Protocol;>Internet 
Printing Protocol (IPP). The IPP is now supported by other OSs such as 
Windows XP and Mac OS X and has became new cross-platform de facto standard for 
remote printing with bi-directional communication capability.
-  The standard printable data format for the application on the 
Debian system is the https://en.wikipedia.org/wiki/PostScript;>PostScript (PS) which is 
a page description language.  The data in PS format is fed into the Ghostscript 
PostScript interpreter to produce the printable data specific to the printer.  
See .
+  In the old Unix-like system, the BSD 

Bug#987862: dbus: messagebus homedir out of sync on legacy installations

[Christoph Anton Mitterer]

Package: dbus
Version: 1.12.20-2
Severity: normal


Hi.

It seems that previously, the homedir for messagebus used to be /var/run/dbus
while nowadays it is /nonexistent for new installations.

Could some logic be added to an upcoming version, that all existing 
installations
are aligned with that?

Thanks,
Chris.

Bug#987861: clamav-base: leftovers on purge

[Christoph Anton Mitterer]

Package: clamav-base
Severity: normal


Hi.

When purging the pagacke, the user/group clamav is left over.

I guess it should be deleted since all files owened by it are
deleted, too, aren't they?


Cheers,
Chris.

Bug#987860: openssh-server: homedir not updated

[Christoph Anton Mitterer]

Package: openssh-server
Version: 1:8.4p1-5
Severity: minor



Hi.

Seems in some version, the homedir of sshd was changed from /var/run/sshd
to /run/sshd.

However, old installations didn't receive that upgrade, would be nice
if this could be done in a future version of the package.


Cheers,
Chris.

Bug#665917: ntp: don't use /home/ for the users homedir

[Christoph Anton Mitterer]

Anything new on that?

It seems fresh installations nowadays get a proper homedir, however all
legacy installations are still left out.

e.g. nfs-common.postinst shows how old installations can be easily
updated.


Cheers,
Chris

Bug#987859: buster-pu: package mumble/1.3.0~git20190125.440b173+dfsg-2

[Chris Knadle]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Greetings.

Attached is a debdiff for mumble to fix CVE-2021-27229 in Buster marked no-dsa
by the security team, bug #982904.

As the upload to buster-proposed-updates only contains one patch and a
changelog entry (the same patch used for mumble in Sid), I'm going to go
ahead and do the upload as suggested in Debian Developers Reference §5.5.1
paragraph 3.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
diff -Nru mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog 
mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog
--- mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog  2019-02-28 
16:36:21.0 +
+++ mumble-1.3.0~git20190125.440b173+dfsg/debian/changelog  2021-04-30 
22:24:25.0 +
@@ -1,3 +1,16 @@
+mumble (1.3.0~git20190125.440b173+dfsg-2+deb10u1) buster; urgency=medium
+
+  * debian/patches:
+- Add 67-only-http-https-URLs-in-Connect.diff to fix CVE-2021-27229
+  "Mumble before 1.3.4 allows remote code execution if a victim navigates
+   to a crafted URL on a server list and clicks on the Open Webpage text."
+  This patch only allows "http"/"https" URLs in ConnectDialog
+  (Closes: #982904)
+  Thanks to Salvatore Bonaccorso  for reporting the bug
+  and giving links to the fix.
+
+ -- Christopher Knadle   Fri, 30 Apr 2021 22:24:25 
+
+
 mumble (1.3.0~git20190125.440b173+dfsg-2) unstable; urgency=medium
 
   * debian/patches:
diff -Nru 
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
 
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
--- 
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
1970-01-01 00:00:00.0 +
+++ 
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/67-only-http-https-URLs-in-Connect.diff
2021-03-04 08:44:10.0 +
@@ -0,0 +1,61 @@
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982904
+Last-Updated: 2021-03-04
+From e59ee87abe249f345908c7d568f6879d16bfd648 Mon Sep 17 00:00:00 2001
+From: Davide Beatrici 
+Date: Fri, 5 Feb 2021 20:01:04 +0100
+Subject: [PATCH] FIX(client): Only allow "http"/"https" for URLs in
+ ConnectDialog
+
+Our public server list registration script doesn't have an URL scheme
+whitelist for the website field.
+
+Turns out a malicious server can register itself with a dangerous URL in
+an attempt to attack a user's machine.
+
+User interaction is required, as the URL has to be opened by
+right-clicking on the server entry and clicking on "Open Webpage".
+
+This commit introduces a client-side whitelist, which only allows "http"
+and "https" schemes. We will also implement it in our public list.
+
+In future we should probably add a warning QMessageBox informing the
+user that there's no guarantee the URL is safe (regardless of the
+scheme).
+
+Thanks a lot to https://positive.security for reporting the RCE
+vulnerability to us privately.
+---
+ src/mumble/ConnectDialog.cpp | 20 +---
+ 1 file changed, 17 insertions(+), 3 deletions(-)
+
+--- a/src/mumble/ConnectDialog.cpp
 b/src/mumble/ConnectDialog.cpp
+@@ -1259,11 +1259,25 @@
+ }
+ 
+ void ConnectDialog::on_qaUrl_triggered() {
+-  ServerItem *si = static_cast(qtwServers->currentItem());
+-  if (! si || si->qsUrl.isEmpty())
++  auto *si = static_cast< const ServerItem * >(qtwServers->currentItem());
++  if (!si || si->qsUrl.isEmpty()) {
+   return;
++  }
+ 
+-  QDesktopServices::openUrl(QUrl(si->qsUrl));
++  const QStringList allowedSchemes = { QLatin1String("http"), 
QLatin1String("https") };
++
++  const auto url = QUrl(si->qsUrl);
++  if (allowedSchemes.contains(url.scheme())) {
++  QDesktopServices::openUrl(url);
++  } else {
++  // Inform user that the requested URL has been blocked
++  QMessageBox msgBox;
++  msgBox.setText(QObject::tr("Blocked URL scheme 
\"%1\"").arg(url.scheme()));
++  msgBox.setInformativeText(QObject::tr("The URL uses a scheme 
that has been blocked for security reasons."));
++  msgBox.setDetailedText(QObject::tr("Blocked URL: 
\"%1\"").arg(url.toString()));
++  msgBox.setIcon(QMessageBox::Warning);
++  msgBox.exec();
++  }
+ }
+ 
+ void ConnectDialog::onFiltersTriggered(QAction *act) {
diff -Nru mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series 
mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series
--- mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series 2019-02-28 
16:36:21.0 +
+++ mumble-1.3.0~git20190125.440b173+dfsg/debian/patches/series 2021-03-04 
08:21:39.0 +
@@ -8,3 +8,4 @@
 52-use-update-rc.d-for-disable.diff
 60-crossbuild.diff
 65-fix-sample-path.diff
+67-only-http-https-URLs-in-Connect.diff

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Hi,

Ritesh Raj Sarraf  (2021-04-30):
> The upload I prepped failed on some of the architectures.
> https://buildd.debian.org/status/logs.php?pkg=open-iscsi=2.1.3-3

It's lacking a push to the Git repository (git fetch didn't get anything
new from a few days ago).

> In d/control, there is:
> 
> ```
> Package: open-iscsi-udeb
> # Note: the (virtual) udeb package scsi-modules (provided by different
> #   linux kernel udebs) must exist for these architectures - so
> #   check that before adding them to this list; the other
> #   scsi-(core|common|...)-modules are NOT sufficient!
> Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
> ppc64el s390x
> Section: debian-installer
> Package-Type: udeb
> ```
> 
> 
> The udeb package was introduced by Colin Watson from Ubuntu. I extended
> the architecture list, based on the supported architectures by d-i. But
> I really don't use or test this functionality of the package.
> 
> 
> How would you like to see this fixed Cyril ?
> 
> The easiest option, if d-i supports, would be to extend architecture
> list to: `linux-any`, keeping it in line with what the actual open-
> iscsi package supports.

Yes, I think that would be a good idea, so that you don't have to keep
the list in sync between debian/control and debian/rules. We don't have
many examples of packages maintained by the d-i team that use it, but
at least src:haveged and src:systemd have similar udebs (after all, that
only matters at build-time, d-i only sees the results of the build).

Regarding your conditional, you could check whether you're building for
linux (once you switch to linux-any) or you could check whether the udeb
is being built: dh_listpackages (-a) can be use to determine that.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987848: Security issue: SQL injection with Microsoft SQL

[Thorsten Glaser]

Hi Robin,

considering you took over maintenance and know the code in
question better, it would be _much_ appreciated if you could
also take care of this for buster.

Thanks in advance,
//mirabilos
-- 
Thorsten Glaser (Founding Member)
Teckids e.V. — Digital freedom with youth and education
https://www.teckids.org/

Bug#936935: libvirt-sandbox: Python2 removal in sid/bullseye

[Christoph Anton Mitterer]

Hey.

AFAICS, all python script have been adapted to Python3 upstream (or
dropped)... so I guess this could be solved by upgrading to the current
version.


Cheers,
Chris.

Bug#987203: gitlab: can not set user avatar

[Antoine Le Gonidec]

I do not reproduce my initial issue on a fresh install of GitLab using Buster 
Fast Track, so I think it was due to some misconfiguration of my previous 
instance.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987745: apt-listbugs: please clarify, what ruby-httpclient is needed/used for

[Christoph Anton Mitterer]

On Sat, 2021-05-01 at 00:06 +0200, Francesco Poli wrote:
> [#792639]: 

Ah I even made some comments to that in the very beginning...
completely forgot about it.




> Since it's only a recommendation (and not a strong dependency), you
> can
> remove or purge it, while keeping apt-listbugs installed.
> 
> 
> If you have no objections, I will close this bug report.

Sure,...feel free to close.

But, if we cannot even name what it does (and AFAICS it doesn't really
change anything, except how things are handled under the hood?),... it
may make sense to further demote the dependency to Suggests... or
perhaps even drop it?


Cheers,
Chris.

Bug#987848: Security issue: SQL injection with Microsoft SQL

[Robin Gustafsson]

Package: src:php-illuminate-database
Version: 5.7.27-1
Severity: important
Tags: security upstream

Dear Maintainer,

Upstream has published a security advisory [1,2] regarding an SQL
injection vulnerability when used with Microsoft SQL Server.

The vulnerability was fixed upstream in version 6.20.26 and 8.40.0.

Looking at the package, this vulnerability probably exists in the
version that is currently in stable, too.

[1] https://blog.laravel.com/security-sql-injection-in-sql-server-limit-offset
[2] https://github.com/laravel/framework/security/advisories/GHSA-4mg9-vhxq-vm7j

Regards,
Robin

Bug#987847: unblock: php-laravel-framework/6.20.14+dfsg-2

[Robin Gustafsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package php-laravel-framework

[ Reason ]
Security fix. See bug #987831 [1].

[ Impact ]
If the security vulnerability remains, users could be vulnerable
to SQL injections.

[ Tests ]
Tested with a subset* of upstream's automated test suite.
The patch is taken from upstream and has passed their QA.

* The test suite is not yet functional in Debian due to its
dependencies, thus no autopkgtest yet, but I can run much of it
locally.

[ Risks ]
I consider it a low-risk change.

The patch was taken from upstream. Their code is still close to the
packaged version in general and identical in this case. The change
is also small and uncomplicated.

Additionally, while the source package builds many binary packages,
only one of them is actually affected by this.


[1] https://bugs.debian.org/987831

Regards,
Robin



diff -Nru php-laravel-framework-6.20.14+dfsg/debian/changelog 
php-laravel-framework-6.20.14+dfsg/debian/changelog
--- php-laravel-framework-6.20.14+dfsg/debian/changelog 2021-01-22 
17:39:34.0 +
+++ php-laravel-framework-6.20.14+dfsg/debian/changelog 2021-04-30 
16:23:38.0 +
@@ -1,6 +1,14 @@
+php-laravel-framework (6.20.14+dfsg-2) unstable; urgency=medium
+
+  * Fix security issue: SQL injection with Microsoft SQL Server
+(Closes: #987831)
+
+ -- Robin Gustafsson   Fri, 30 Apr 2021 18:23:38 +0200
+
 php-laravel-framework (6.20.14+dfsg-1) unstable; urgency=medium

   * New upstream version 6.20.14+dfsg
+- Fix security issue: More unexpected bindings in QueryBuilder
   * Replace git attributes with uscan's gitexport=all

  -- Robin Gustafsson   Fri, 22 Jan 2021 18:39:34 +0100
@@ -9,7 +17,8 @@

   * Set upstream metadata fields: Security-Contact.
   * New upstream version 6.20.11+dfsg
-- Fix security issue: Unexpected bindings in QueryBuilder (Closes: #980095)
+- Fix security issue: Unexpected bindings in QueryBuilder
+  (CVE-2021-21263, Closes: #980095)
   * Bump Standards-Version

  -- Robin Gustafsson   Fri, 15 Jan 2021 00:35:41 +0100
diff -Nru 
php-laravel-framework-6.20.14+dfsg/debian/patches/0001-cast-to-int.patch 
php-laravel-framework-6.20.14+dfsg/debian/patches/0001-cast-to-int.patch
--- php-laravel-framework-6.20.14+dfsg/debian/patches/0001-cast-to-int.patch
1970-01-01 00:00:00.0 +
+++ php-laravel-framework-6.20.14+dfsg/debian/patches/0001-cast-to-int.patch
2021-04-30 16:23:38.0 +
@@ -0,0 +1,38 @@
+From: Taylor Otwell 
+Date: Wed, 28 Apr 2021 08:18:19 -0500
+Subject: cast to int
+
+Origin: 
https://github.com/laravel/framework/commit/09bf1457e9df53e172e6fd5929cbafb539677c7c
+Applied-Upstream: 6.20.26
+---
+ src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php 
b/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php
+index f0a0bfc..88a7df3 100755
+--- a/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php
 b/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php
+@@ -60,8 +60,8 @@ class SqlServerGrammar extends Grammar
+ // If there is a limit on the query, but not an offset, we will add 
the top
+ // clause to the query, which serves as a "limit" type clause within 
the
+ // SQL Server system similar to the limit keywords available in MySQL.
+-if ($query->limit > 0 && $query->offset <= 0) {
+-$select .= 'top '.$query->limit.' ';
++if (is_numeric($query->limit) && $query->limit > 0 && $query->offset 
<= 0) {
++$select .= 'top '.((int) $query->limit).' ';
+ }
+
+ return $select.$this->columnize($columns);
+@@ -221,10 +221,10 @@ class SqlServerGrammar extends Grammar
+  */
+ protected function compileRowConstraint($query)
+ {
+-$start = $query->offset + 1;
++$start = (int) $query->offset + 1;
+
+ if ($query->limit > 0) {
+-$finish = $query->offset + $query->limit;
++$finish = (int) $query->offset + (int) $query->limit;
+
+ return "between {$start} and {$finish}";
+ }
diff -Nru php-laravel-framework-6.20.14+dfsg/debian/patches/series 
php-laravel-framework-6.20.14+dfsg/debian/patches/series
--- php-laravel-framework-6.20.14+dfsg/debian/patches/series1970-01-01 
00:00:00.0 +
+++ php-laravel-framework-6.20.14+dfsg/debian/patches/series2021-04-30 
16:23:38.0 +
@@ -0,0 +1 @@
+0001-cast-to-int.patch


unblock php-laravel-framework/6.20.14+dfsg-2

Bug#922666: confirmed bug report

[Antoine Beaupré]

On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi Tollef, Antoine,
>
> On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> Control: forcemerge 922666 928189
>> Control: severity 922666 important
>> Control: tags 922666 +patch +confirmed
>> 
>> I also see a regression with touchpads and trackpoint on a Thinkpad E431
>> after upgrading from Debian stretch to buster. My research indicates
>> this is a kernel regression, as yet to be fixed.
>> 
>> This is the result of my research, as available online at:
>> 
>> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> 
>> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> freezes after sleep. Keyboard still works but not mouse until a
>> reboot.
>> 
>> There's [bug 922666][] in Debian buster, without a fix. It also says
>> it eventually recovers, which is not our experience. Possible dupe is
>> [bug 928189][].
>> 
>> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> 
>> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> which proposes the following workarounds:
>> 
>>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> disabled`
>> 
>>  * A .service file:
>> 
>> # /etc/systemd/system/touchpad-sleep.service
>> # restore touchpad on suspend
>> 
>> [Unit]
>> Description=Restore Touchpad on suspend
>> Before=sleep.target
>> StopWhenUnneeded=yes
>> 
>> [Service]
>> #Type=oneshot
>> Type=idle
>> RemainAfterExit=yes
>> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> /sys/bus/pci/drivers/i801_smbus/unbind'
>> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> /sys/bus/pci/drivers/i801_smbus/bind'
>> 
>> [Install]
>> WantedBy=sleep.target
>> 
>>  * "Maybe try xserver-xorg-input-evdev instead of 
>> xserver-xorg-input-libinput?"
>> 
>>  * reloading `psmouse`:
>>  
>> sudo modprobe -r psmouse
>> sudo modprobe psmouse
>> 
>>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` seems to 
>> solve the issue."
>> 
>>  * whatever this is:
>>  
>> # echo 1 > /sys/devices/rmi4-00/nosleep
>> 
>>  * "Anyone who still affected by touchpad issues after S3. Please
>>switch back to suspend-to-idle in BIOS if s2idle is
>>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>>suspend-to-idle in BIOS->config->power menu."
>> 
>> [bug 1791427]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
>> 
>> There's also [bug 1442699][] in Fedora, which suggests those
>> workarounds:
>> 
>>  * another module reload:
>>  
>> sudo rmmod i2c_hid
>> sudo modprobe i2c_hid
>> 
>>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
>>and this issue seems to have been resolved (for me)."
>> 
>>  * another `/proc` hack:
>>  
>> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
>> 
>>  * "The `psmouse.synaptics_intertouch=0` workaround still works for me."
>> 
>> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
>> 
>> Also related is this [libinput bug][] that's closed as "not our bug"
>> because they claim it's a bug in the kernel.
>> 
>> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149
>> 
>> There are [two][] [patches][] on the Linux kernel which apparently fix the
>> issue, still pending approval:
>> 
>> [two]: https://lkml.org/lkml/2019/2/20/700
>> [patches]: https://lkml.org/lkml/2019/2/20/701
>> 
>> Possibly related: https://lkml.org/lkml/2016/8/18/134
>> 
>> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
>> [pull request][] has been merged in mainline with two other fixes on
>> the module./ [5.0.11][] also has fixes on the module. It's clearly a
>> regression from Debian stretch (kernel 4.9) since it was working fine
>> before.
>> 
>> Possibly related, [two-finger scrolling bug in Ubuntu][], which
>> identifies [this commit][] as the source of the regression. [Upstream
>> kernel bug][], still open.
>> 
>> [5.1rc7]: https://lkml.org/lkml/2019/4/28/270
>> [pull request]: https://lkml.org/lkml/2019/7/12/19
>> [5.0.11]: https://lkml.org/lkml/2019/5/2/287
>> [Upstream kernel bug]: https://bugzilla.kernel.org/show_bug.cgi?id=196719
>> [this commit]: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e839ffab028981ac77f650faf8c84f16e1719738
>> [two-finger scrolling bug in Ubuntu]: 
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1722478
>> 
>> I haven't tried any of those workarounds. I hope this helps!
>
> Can you confirm if this issue is still present with a recent kernel?

e.g. buster-backports?

-- 
The flesh you so fancifully fry
Is not succulent, tasty or kind
It's death for no reason
And death for no reason is murder
  

Bug#987858: FTBFS: dh_makeshlibs: error: The udeb open-iscsi-udeb does not contain any shared libraries but --add-udeb=open-iscsi-udeb was passed!?

[Aurelien Jarno]

Package: open-iscsi
Version: 2.1.3-3
Severity: serious
Tags: d-i ftbfs patch
Justification: fails to build from source (but built successfully in the past)

open-iscsi fails to build on mips64el:

| dh_missing --fail-missing
| make[1]: Leaving directory '/<>'
|dh_strip -a
|debian/rules override_dh_makeshlibs
| make[1]: Entering directory '/<>'
| dh_makeshlibs --add-udeb=open-iscsi-udeb
| dh_makeshlibs: error: The udeb open-iscsi-udeb does not contain any shared 
libraries but --add-udeb=open-iscsi-udeb was passed!?
| make[1]: *** [debian/rules:104: override_dh_makeshlibs] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:13: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build-log is available here:
https://buildd.debian.org/status/fetch.php?pkg=open-iscsi=mips64el=2.1.3-3=1619796879=0

This happens as the open-iscsi-udeb package is not build on this
architecture. The reason for that is indicated in the debian/control
file:

| Package: open-iscsi-udeb
| # Note: the (virtual) udeb package scsi-modules (provided by different
| #   linux kernel udebs) must exist for these architectures - so
| #   check that before adding them to this list; the other
| #   scsi-(core|common|...)-modules are NOT sufficient!
| Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64 ppc64el 
s390x

However it happens that mips64el do have such scsi-module packages
containing the iscsi and libiscsi modules:
- 
https://packages.debian.org/search?suite=sid=mips64el=scsi-modules
 

At least the following architectures also have this package:
- alpha: 
https://packages.debian.org/search?suite=sid=alpha=scsi-modules
- hppa: 
https://packages.debian.org/search?suite=sid=hppa=scsi-modules
- m68k: 
https://packages.debian.org/search?suite=sid=m68k=scsi-modules
- riscv64: 
https://packages.debian.org/search?suite=sid=riscv64=scsi-modules 
- sparc64: 
https://packages.debian.org/search?suite=sid=sparc64=scsi-modules

The patch below therefore updates the debian/control file so that
open-iscsi builds correctly on those architecture:

--- open-iscsi-2.1.3/debian/control
+++ open-iscsi-2.1.3/debian/control
@@ -139,7 +139,7 @@
 #   linux kernel udebs) must exist for these architectures - so
 #   check that before adding them to this list; the other
 #   scsi-(core|common|...)-modules are NOT sufficient!
-Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64 ppc64el 
s390x
+Architecture: alpha amd64 arm64 armhf hppa i386 ia64 m68k mips mipsel mips64el 
powerpc ppc64 ppc64el riscv64 s390x sparc64
 Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},


Regards,
Aurelien

Bug#987745: apt-listbugs: please clarify, what ruby-httpclient is needed/used for

[Francesco Poli]

On Fri, 30 Apr 2021 21:59:42 +0200 Christoph Anton Mitterer wrote:

> On Thu, 2021-04-29 at 18:31 +0200, Francesco Poli wrote:
[...]
> > I am under the impression that ruby-httpclient is more sophisticated
> > than the basic net/http Ruby library. It should support more features
> > (but I don't remember which ones...).
> > This also means that it is somewhat slower.
> 
> Hmm I was just trying out a few things... and noted that regardless of
> whether or not ruby-httpclient is installed - the communication with
> Debian server seems to be completely in plain HTTP[0]? :-o
[...]

That's an old, long and complicated story.
If you are looking for a way to kill some time, please read bug
[#792639] and the other two which are merged with it.

[#792639]: 

I agree that using HTTPS would not solve all security issues, but it would a 
step forward...

[...]
> Anyway... I didn't notice any difference at all, whether ruby-
> httpclient is there.
> Also I didn't find any obvious references to it in the apt-listbugs
> sources... so nothing like a "require httpclient" or so - but I don't
> speak ruby, so there might be some auto-magic, which I just don't know
> about.

The auto-magic is behind the scenes (if I recall correctly, it's the
ruby-soap4r library that automatically uses ruby-httpclient, if
present, otherwise falling back to net/http).

Anyway, if ruby-httpclient is superfluous for your use case, you should
be able to do without it.
Since it's only a recommendation (and not a strong dependency), you can
remove or purge it, while keeping apt-listbugs installed.


If you have no objections, I will close this bug report.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpoxtGDGNhmF.pgp
Description: PGP signature

Bug#987839: apt-listbugs: daily cleanup runs hourly

[Francesco Poli]

Control: tags -1 + moreinfo


On Fri, 30 Apr 2021 10:46:04 -0700 Ross Boylan wrote:

[...]
> Dear Maintainer,

Hello Ross,
thanks for your bug report.

> 
> It would be nice to clean up this minor annoyance before buster's release.

I am afraid that we are too late for *buster* release.
Maybe you meant *bullseye*?!?;-)
Anyway, it's late for bullseye, as well: Debian testing is already in
hard freeze...

But I don't think there's anything really in need for a fix.
Please read on.

> 
>* What led up to the situation?
> 
>Installed apt-listbugs and logcheck on a debian testing system.
>Every *hour* I get email from logcheck that includes lines like this:
>Apr 30 08:37:06 debtest systemd[1]: Starting Daily apt-listbugs
> preferences cleanup...
>Apr 30 08:37:06 debtest systemd[1]: Finished Daily apt-listbugs
> preferences cleanup.
> (Obviously logcheck and the email are incidental; the point is the
>"Daily" cleanup is actually run hourly.  However, the emails are
>part of why I find it annoying.)

Does logcheck send e-mail messages for all the other systemd timers?

As you may already know, you can get a list of active systemd timers on
your box with the following command:

  $ systemctl list-timers

> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  Investigated why this is happening.  The package has an entry in
>/etc/cron.daily, which seems correct.  But it also has
>/lib/systemd/system/apt-listbugs.timer which includes
>OnCalendar=*-*-* *:20
>I believe this is telling it to trigger something at 20 minutes
>after the hour for every hour.  There is also
>RandomizedDelaySec=20min
>in the same file, which may explain why it seems to run between 20
>and 40 minutes after the hour for me.

Yes, that is correct.
Please read bug [#932995] for a more detailed discussion about the same
surprise you experienced.

[#932995]: 

> 
>This seems more like a task for anacron for systems that may not be
>up all the time, but I don't know enough about systemd to be sure
>how to turn it off, or if it can handle these situations.

If you use systemd as your init system (PID 1), please do not turn it
off. It's the only apt-listbugs cleanup routine running, since the
cron.daily job does nothing, if systemd is PID 1.  

> 
>* What was the outcome of this action?
>Only observations so far, and so no change.  I might change to
>OnCalendar=*-*-* 20:20
>which I think means run at 8:20pm every day.  But the VM is not up
>all the time and so that might miss some times it should run,
>unless the /etc/cron.daily/ entry acts as a safety net.

That is exactly the reason why the cleanup is attempted hourly, but
performed at most once a day.
Again, see [#932995] for an explanation.

> 
>* What outcome did you expect instead?
>That a daily cleanup job would only run once a day.

That's already happening: the cleanup runs at most once a day.

> 
> Another work-around for the visible annoyance would be for me to tell
> logcheck to ignore the relevant messages.

I think this should be the way to avoid the annoyance.
I am not knowledgeable enough about logcheck to help you in this.
Sorry about that.

> 
> Thanks for your work on the package:)

You're welcome, I try to do my best...

If you do not object, I will close this bug report.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpbMqLTlSKbo.pgp
Description: PGP signature

Bug#987857: words lists should be sorted

[Marco d'Itri]

Package: wamerican
Version: 2019.10.06-1
Severity: normal

Since about one year look(1) switched to a different algorithm which 
requires words list to be sorted (the man page mentions "sort -d").

Please see #973471 for details.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#987856: lz4: CVE-2021-3520

[Salvatore Bonaccorso]

Source: lz4
Version: 1.9.3-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/lz4/lz4/pull/972
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for lz4.

CVE-2021-3520[0]:
| memory corruption due to an integer overflow bug caused by memmove
| argument

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3520
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3520
[1] https://github.com/lz4/lz4/pull/972

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#982904: mumble: CVE-2021-27229

[Chris Knadle]

Note: for the three messages recently sent (Benedikt, Salvatorie, Chris/me) that 
have recently been sent, none went to #982904 because the bug had been archived. 
I've unarchived the bug since fixing it for Buster is still pending.


  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#987855: RFS: sane-backends/1.0.32-1 -- API library for scanners

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sane-backends":

Package name : sane-backends
Version : 1.0.32-1
   I. Upstream Author : 
URL : http://www.sane-project.org
License : GPL-3+, GPL-2+, GPL-2+ with sane exception, Artistic, GFDL-
1.1, GPL-2, LGPL-2.1+
Vcs : https://jff.email/cgit/sane-backends.git
Section : graphics

It builds those binary packages:

 libsane - API library for scanners [transitional package]
 libsane-dev - API development library for scanners [development files]
 libsane1 - API library for scanners
 libsane-common - API library for scanners -- documentation and support files
 sane-utils - API library for scanners -- utilities

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/sane-backends/

Alternatively, one can download the package with dget using this
command:

 dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.32-1.dsc

or from

 git https://jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.0.32-1

Changes since the last upload:

 sane-backends (1.0.32-1) experimental; urgency=medium
 .
 * New Upstream release:
 - Refresh patches:
 + patches/0040-remove_git.patch
 + patches/0045-disable_lock_test_at_build_time.patch
 + patches/0060-cross.patch
 + patches/0140-avahi.patch
 + patches/0145-avahi.patch
 + patches/0150-i386-test.patch
 + patches/0155-hurd_PATH_MAX.patch
 + patches/0600-scanimage_manpage.patch
 + patches/0705-kfreebsd.patch
 + patches/0725-fix_link_60-libsane_rule.patch
 - Remove not longer needed patches:
 + patches/0100-source_spelling.patch
 + patches/0125-multiarch_dll_search_path.patch
 + patches/0055-Fix_build_error.patch
 + patches/0165-respect_local_only_parameter.patch
 + patches/0170-return_empty_list_when_local_devices_requested.patch
 - New Patches:
 + patches/0175-fix_tests.patch to fix build - tests.
 + patches/0605-fix_groff-warnings.patch to fix groff warnings.
 * debian/copyright:
 - Refresh to the new upstream release.
 * debian/libsane1.symbols:
 - Add 1 new symbol.
 - Remove MISSING from last release.
 * debian/libsane-common.lintian-overrides:
 - Remove double lines.
 * New debian/libsane1.lintian-overrides to override afe spelling.
 * TROUBLESHOOTING.Debian:
 - Add part if sane-backends and tlp runs on the same system
 (Closes: #954096, #887745).
 * Declare compliance with Debian Policy 4.5.1 (No changes needed).
 * Fix FTCBFS: Annotate python3-minimal dependency :any. (Closes: #984747).
 - Thanks to Helmut Grohne .
 * debian/sane-utils.postrm:
 - Fix package doesn't purge cleanly (user/group not purged)
 (Closes: #987837).
 - Fix package doesn't purge cleanly (fix test with pathfind())
 (Closes: #987805).
 * Fix filtering out libsane-dll (Closes: #971592):
 - Cherry-picked from 1.0.25-4.1+deb9u2 (Thanks to
 Sylvain Beucler ).


CU
Jörg


-- 
New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D GPG 
key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 
0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst 
D-54470 Lieser git:  https://jff.email/cgit/ Threema: SYR8SJXB Wire: 
@joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst 
My wish list:   - Please send me a picture from the nature at your home.


signature.asc
Description: This is a digitally signed message part

Bug#987854: libpackagekit-glib2-18: consider backporting libpackagekit-glib2 upstream fix

[Sophie Herold]

Package: libpackagekit-glib2-18
Version: 1.2.2-2
Severity: important
X-Debbugs-Cc: sop...@hemio.de

Dear Maintainer,

there exists an upstream patch that potentially fixes many hangs, also reported
in the issues here. For example, it probably fixes an issue that makes GNOME
Software unusable. Please consider including it in the upcoming stable release

https://github.com/hughsie/PackageKit/pull/464

Best,
Sophie

Bug#987853: wireshark: CVE-2021-22207

[Salvatore Bonaccorso]

Source: wireshark
Version: 3.4.4-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/wireshark/wireshark/-/issues/17331
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wireshark.

CVE-2021-22207[0]:
| Excessive memory consumption in MS-WSP dissector in Wireshark 3.4.0 to
| 3.4.4 and 3.2.0 to 3.2.12 allows denial of service via packet
| injection or crafted capture file


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-22207
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22207
[1] https://gitlab.com/wireshark/wireshark/-/issues/17331
[2] https://www.wireshark.org/security/wnpa-sec-2021-04.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987852: .uuid file stuck there

[積丹尼 Dan Jacobson]

Package: ttf-xfree86-nonfree

dpkg: warning: unable to delete old directory 
'/usr/share/fonts/truetype/ttf-xfree86-nonfree': Directory not empty
Due to .uuid file.

Bug#987851: linux-version sort: argv and stdin behaviors differ

[dann frazier]

Package: linux-base
Version: 4.6
Severity: normal
Tags: patch

Using argv:
$ linux-version sort 5.8.0-50-generic 5.8.0-50-generic-64k
5.8.0-50-generic
5.8.0-50-generic-64k

Using stdin:
$ cat versions.txt
5.8.0-50-generic
5.8.0-50-generic-64k
$ cat versions.txt | linux-version sort
5.8.0-50-generic-64k
5.8.0-50-generic

It seems the trailing "\n" is unexpectedly being used in the comparison.
Now, perl and I have never really gotten along, but this patch seems to work:

--- /usr/bin/linux-version.orig 2020-06-25 17:23:24.0 +
+++ /usr/bin/linux-version  2021-04-30 20:39:13.708560573 +
@@ -70,7 +70,7 @@
@versions = map({[$_, "\n"]} @_);
 } else {
while () {
-   /^([^ ]*)(.*\n?)$/ or die;
+   /^([^ \n]*)(.*\n?)$/ or die;
push @versions, [$1, $2];
}
 }


-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.76

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
* linux-base/removing-running-kernel: true
  linux-base/removing-title:

Bug#987850: .uuid file stuck there

[積丹尼 Dan Jacobson]

Package: ttf-xfree86-nonfree-syriac

dpkg: warning: unable to delete old directory 
'/usr/share/fonts/truetype/ttf-xfree86-nonfree-syriac': Directory not empty
stuck there: /usr/share/fonts/truetype/ttf-xfree86-nonfree-syriac/.uuid

Bug#987849: ssh: misleading "invalid format" message about public key when using private key

[xavier renaut]

Package: ssh
Version: 1:7.9p1-10+deb10u2
Severity: wishlist

Dear Maintainer,


   * What led up to the situation?

I deployed a new set of ssh-keys on a machine. 
I installed (not on purpose) id_ed25519.pub with the from="ip" in front of the 
key.



   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I'm trying to ssh from the host_1 to host_2

when running ssh from host_1 :
load pubkey "/home/devops/.ssh/id_ed25519": invalid format
x...@y.com: Permission denied (publickey,password).

I assumed my private key was wrong here, thus ending in authentication failure
(turns out it was not related, it was an issue on host_2)

   * What was the outcome of this action?

I started investigating my private key.

   * What outcome did you expect instead?

instead of : 
load pubkey "/home/devops/.ssh/id_ed25519": invalid format

I would like to see a .pub at the end, and also something that says 
"informational, non-critical, non-related to current operation"

Something like :
+FYI not related
+ .pub at the end of the file name :
+ s/pub/loading Public/

FYI, not related : loading Public key "/home/devops/.ssh/id_ed25519.pub": 
invalid format





-- System Information:
Debian Release: 10.8
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ssh depends on:
ii  dpkg1.19.7
ii  openssh-client  1:7.9p1-10+deb10u2
ii  openssh-server  1:7.9p1-10+deb10u2

ssh recommends no packages.

ssh suggests no packages.

-- no debconf information

Bug#973793: DoH support in Unbound

[Cam Eliot]

Can this patch be merged please? Ubuntu Hirsute has launched with
Ubuntu's DoH support disabled.

Apr 30 20:56:10 server systemd[1]: Starting Unbound DNS server...
Apr 30 20:56:11 server unbound: [2593:0] notice: init module 0: subnet
Apr 30 20:56:11 server unbound: [2593:0] notice: init module 1: validator
Apr 30 20:56:11 server unbound: [2593:0] notice: init module 2: iterator
Apr 30 20:56:11 server unbound: [2593:0] warning: Unbound is not
compiled with nghttp2. This is required to use DNS-over-HTTPS.
Apr 30 20:56:11 server systemd[1]: Started Unbound DNS server.

Bug#987845: hardwired proxy settings by debian-installer with network-auto-config in proxy-auto-config network

[Geert Stappers]

On Fri, Apr 30, 2021 at 09:25:47PM +0200, Rado Q wrote:
> Installation network setup was auto-configured while the system was
> in a network with proxy-auto-config active.
> 
> Expectation:
> when choosing auto-configure-network during installation, the
> resulting system should be operative in every foreign environment.
> (think of notebook in roaming use)
> 
> Result:
> applications strictly following those hardwired configs can't operate
> outside the original installation network, where the given proxy exists,
> but nowhere else. PAC results during installation shouldn't be
> 'hardwired' into the system to last when moving to another network.
> 
> I tried to reproduce with WPAD or PAC in dhcp at home, but my knowledge
> of those technologies didn't suffice to set it up properly.
> If more info/details of the original network environment is required,
> then I must ask for permission to reproduce, can take time (school in 
> lockdown).
> 
> If the result is intentional for 'local use only', then this is no
> defect but feature-request to add another option to choose between
> 'automatic config for local use' and '... roaming use'.
> 

Acknowledge on the problem.

Which possible solutions do we see?


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#949767: arrayfire update fails in configure step

[Andreas Tille]

On Thu, Apr 29, 2021 at 04:45:20PM +0200, Gard Spreemann wrote:
> The capitalization typo seems to be present also in arrayfire's
> use_debian_packaged_libs.patch: I believe line 64 of
> 
>  
> https://salsa.debian.org/science-team/arrayfire/-/blob/a11a6fef7dadf8ce594920626058990fe0caeb2a/debian/patches/use_debian_packaged_libs.patch#L64
> 
> should read
> 
>  +find_package(CLBlast)
> 
> instead of
> 
>  +find_package(CLBLast)
> 
> as it currently does.

This works now.  I decided to commit
   libclblast-dev (>= 1.5.2-2~)
assuming you will upload this version sooner or later.  Now I / someone
who intends to keep on maintaining this package (ping Ghislain are you
actively maintaing this package any more?) needs to deal with the Debian
packaged gtest - I'm afraid I'm currently busy with other things since
I think it is OK to remove clblas from Debian since arrayfire probably
can go without it.  This was the main purpose why I checked this package.
 
> > BTW, It would be great if [1] would feature a pristine-tar branch.
> 
> I'll look into creating pristine-tar branches for my packages. Thanks
> for the nudge!

You are welcome.  I'd recommend reading the chapter about importing
upstream sources of Debian Science policy[1].

Thanks a lot for your very helpful hints

  Andreas.


[1] https://science-team.pages.debian.net/policy/#idm306

-- 
http://fam-tille.de

Bug#987745: apt-listbugs: please clarify, what ruby-httpclient is needed/used for

[Christoph Anton Mitterer]

On Thu, 2021-04-29 at 18:31 +0200, Francesco Poli wrote:
> But the fact is: I am not sure.
> 
;-)


> I am under the impression that ruby-httpclient is more sophisticated
> than the basic net/http Ruby library. It should support more features
> (but I don't remember which ones...).
> This also means that it is somewhat slower.

Hmm I was just trying out a few things... and noted that regardless of
whether or not ruby-httpclient is installed - the communication with
Debian server seems to be completely in plain HTTP[0]? :-o


That's generally a bit concerning... I mean I haven't looked at the
code, but I'd guess listbugs parses some output from the BTS...?

Even if that parsing is 100% safe,... an attacker could still do a
blocking attack, e.g. by preventing a bug like "don't install newest
SSH... it contains a backdoor" to arrive at the user.


That said,.. even TLS wouldn't make things much better here, at least
if it doesn't require a CA which is fully under the control of Debian
(which Debian unfortunately gave up).
So even with TLS, there'd be some >100 root CAs in ca-certificates...
and several thousands of intermediate CAs, which could possibly do some
forgery.
Still, do you think it's feasible to add a strict requirement for TLS
(perhaps with at least only considering the root CA, that debian uses -
which I guess is letsencrypt)?



Anyway... I didn't notice any difference at all, whether ruby-
httpclient is there.
Also I didn't find any obvious references to it in the apt-listbugs
sources... so nothing like a "require httpclient" or so - but I don't
speak ruby, so there might be some auto-magic, which I just don't know
about.


Cheers,
Chris.



[0] I did see some TLS stuff at the time frame, but that went to some
servers at cloudflare (with no reverse DNS pointer set, so I kinda
guess it's nothing from Debian?)...

Bug#987766: unblock: open-iscsi/2.1.3-2

[Paul Gevers]

Hi,

On 30-04-2021 17:03, Ritesh Raj Sarraf wrote:
> I will go ahead with the upload now and will untag this bug report of
> `moreinfo`.

That's not what I meant. I'll try to be more clear next time.

You're debdiff showed only the content of the open-iscsi binary package
(which wasn't affected by your changes). My request was intended for
*all* binary packages. You can get that by running debdiff on the
changes files IIRC.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987846: ITP: libcallstats-java -- Library to integrate with callstats.io

[Sunil Mohan Adapa]

Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libcallstats-java
  Version : 5.2.0
  Upstream Author : Karthik Budigere , Marcin Nagy

* URL : https://github.com/callstats-io/callstats.java
* License : Expat
  Programming Lang: Java
  Description : Library to integrate with callstats.io

callstats.io is a web service for storing and analying WebRTC call quality
statistics. This library helps Java programs such as jitsi-videobridge and
kurento to publish statistics to the online service.

This is part of a larger effort to package Jitsi Videobridge in Debian. Jitsi
Videobridge has submission of statistics to callstats.io server disable by
default. However, this library appears to be a hard dependency. I intend to
maintain the package as part of the Debian Java team.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmCMYGERHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfKqKQ//RguZnNA89pa4rEV+hQtky0Mf6NEGOTZA
XlVgF/1FrnvMlf79riwq6gHJDuC02KYUb1SJZVK14hW4SMN8zlQizWLyxF8XRzSS
Si0WSdqTCaLbcod6zfeNv902ojkYaJL5WEeuxmRp7LdbqeCUv6zVUJA2hMk4TGBV
jxLct+1Vg62qs37BX+/1114evKDNDGmnTCY9FLhk/9YZsW163G5W79pG1NHrUsZg
qtHJKe3jSCFfaj4fiJoU+VhH5FFxKhQ/l3GuatIx/hGTlpI9pPWpnA1cvtbCnu9s
xIu6DljAwhP5bGjx0mSCqJ1q3Fe1NOq3dgrFb4urCZi8cOQb6Ko4SRqGZQYzCZm8
K/ZvG90mp2eJmAFFn9ex8vTaJ6AaPKiOGpropV8rdUpK5byQ3TK7i1upF9nlcvjN
eiHKDW1LwqbKeEW82vzoQwGqPAqFRo4erYqN0sezlsNAIJ5n4ky2au3UovGLEQg/
VNP7y+X6Tac2JWUDCJFTI1S5IfQ1biKeL5L+jzbn1eMqQqG+fJb1MPM8a2KwX1eP
oHVkrFzDohWPGQ2lZ99DHVBW4CfPr4N/Yt1/uZWUopMwur4GgdrxkHSCGmixXe3c
OsdaoyyXTn70auY77I4lSupcYqZ7giGdPde9Mjd6PAnOWxkFNJwh5ETQL0ovltWB
3DFINor9ZNI=
=gTm4
-END PGP SIGNATURE-

Bug#987803: geoclue-2.0: package doesn't purge cleanly

[Christoph Anton Mitterer]

On Fri, 2021-04-30 at 20:50 +0200, Chris Hofstaedtler wrote:
> Cleanup works only in trivial cases. For everything else, you will
> end up with a free uid and existing files or existing running
> processes owned by this uid. A following useradd by the local admin
> or a package install will "reassign" ownership of these files to a
> user who was never supposed to have access to them, creating a
> security problem.
> 
> It could be argued that most packages trying to cleanup users have a
> security hole.
Indeed... and typically I'm always on the security-hardening side ;-)
... but does geoclue create any files with it's UID or GID, which are
not also deleted upon purge?

Cause if not,... I might be justifiable to do such a cleanup. Anyway...
it's up to you :-)


Cheers,
Chris.

Bug#987658: unblock: openjdk-11-jre-dcevm/11.0.11+9-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Emmanuel,

On 27-04-2021 13:47, Emmanuel Bourg wrote:
> Please unblock package openjdk-11-jre-dcevm

 333 files changed, 8389 insertions(+), 2196 deletions(-)
That's not reviewable.

> openjdk-11-jre-dcevm/11.0.10+1-1 in testing is currently unusable, it
> throws an error because the version isn't aligned with the openjdk-11
> package (#984725).

Can't that bug be fixed by cherry-picking? A new upstream is not
acceptable like this at this stage of the release. Please read our FAQ
[1] and act accordingly.

Paul

[1] https://release.debian.org/bullseye/FAQ.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#955434: moreinfo

[Holger Levsen]

control: tags -1 newcomer
thanks

from #debian-qa, with buxy's permission:

  h01ger: really, if you just want a fixed link to the parent directory, 
it should be as easy as adding another class like PopconLink here:

https://salsa.debian.org/qa/distro-tracker/-/blob/master/distro_tracker/vendor/debian/tracker_panels.py#L151
adding it in the buildd list would require a bit more work,
changing the BuildLogCheckLinks class just above:

https://salsa.debian.org/qa/distro-tracker/-/blob/master/distro_tracker/vendor/debian/tracker_panels.py#L64
like adding one method, and changing the template


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If secure encryption is outlawed, only criminals will have it.


signature.asc
Description: PGP signature

Bug#987845: hardwired proxy settings by debian-installer with network-auto-config in proxy-auto-config network

[Rado Q]

Package: installation-reports

Boot method: network
Image version: mini.iso with files within of Nov 30 09:49 2020
Date: sometime in Dec 2020

Machine: various
Processor: various
Memory: 8gb
Partitions: basically 2 ext4 parts, / + /home


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

After complete and successful installation, the following files have
these proxy config lines stored in them to be used with apt(titude)
and every application reacting to those environment variables.
Installation network setup was auto-configured while the system was
in a network with proxy-auto-config active.

Expectation:
when choosing auto-configure-network during installation, the
resulting system should be operative in every foreign environment.
(think of notebook in roaming use)

Result:
applications strictly following those hardwired configs can't operate
outside the original installation network, where the given proxy exists,
but nowhere else. PAC results during installation shouldn't be
'hardwired' into the system to last when moving to another network.

I tried to reproduce with WPAD or PAC in dhcp at home, but my knowledge
of those technologies didn't suffice to set it up properly.
If more info/details of the original network environment is required,
then I must ask for permission to reproduce, can take time (school in lockdown).

If the result is intentional for 'local use only', then this is no
defect but feature-request to add another option to choose between
'automatic config for local use' and '... roaming use'.

This is the result of 'fgrep -r proxy-IP /etc'.

-- QUOTE BEGIN --
/etc/apt/apt.conf:Acquire::http::Proxy "http://10.x.x.x:8080;;
/etc/apt/apt.conf:Acquire::ftp::Proxy "http://10.x.x.x:8080;;
/etc/environment:http_proxy=http://10.x.x.x:8080
/etc/environment:ftp_proxy=http://10.x.x.x:8080
/etc/environment:https_proxy=http://10.x.x.x:8080
--- QUOTE END ---

Bug#982845: [Pkg-ayatana-devel] Bug#982845: Acknowledgement (Build tests are failed but ignored)

[Mike Gabriel]

Hi Sebastien,

On  Fr 30 Apr 2021 10:28:10 CEST, Sebastien Bacher wrote:


Hey there,

Any chance you could check on this one? That's a blocker if we want to
switch to the ayatana indicators in Ubuntu, which we should do this
cycle if we want to do it before the next LTS

Thanks,


I have just uploaded a libayatana-appindicator version that should fix  
this problem.


I also filed a PR upstream for this:
https://github.com/AyatanaIndicators/libayatana-appindicator/pull/19

Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpiAe51ou1Jw.pgp
Description: Digitale PGP-Signatur

Bug#922666: confirmed bug report

[Tollef Fog Heen]

]] Salvatore Bonaccorso 

> Can you confirm if this issue is still present with a recent kernel?

I haven't seen it for quite some time on my Buster machine, so from my
point of view, it can be closed.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#987844: libtangence-perl: flaky autopkgtest: Lost 135168 bytes of memory over 1000 calls, average of 135.17 per call

[Paul Gevers]

Source: libtangence-perl
Version: 0.25-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed it fails regularly
(all with the same error) amd64, arm64 and armhf.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Paul

[1] https://ci.debian.net/packages/libt/libtangence-perl/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtangence-perl/9968742/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtangence-perl/10158148/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtangence-perl/11511120/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtangence-perl/12014480/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/libt/libtangence-perl/12009148/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/libt/libtangence-perl/11400077/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/libt/libtangence-perl/10694595/log.gz


   Failed test 'Connect/watch/disconnect does not grow memory'
#   at t/90close-leak.t line 40.
# Lost 135168 bytes of memory over 1000 calls, average of 135.17 per call
1..1
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

Test Summary Report
---
t/90close-leak.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=15, Tests=573,  4 wallclock secs ( 0.08 usr  0.04 sys +  3.88 cusr
 0.22 csys =  4.22 CPU)
Result: FAIL



OpenPGP_signature
Description: OpenPGP digital signature

Bug#944092: linux-image-5.3.0-1-amd64: i915 gpu hang, system freezes for seconds every few minutes

[Salvatore Bonaccorso]

Control: tags -1 + moreinof

On Mon, Nov 04, 2019 at 08:39:15AM +0100, Philipp Marek wrote:
> Package: src:linux
> Version: 5.3.7-1
> Severity: normal
> Tags: patch upstream
> 
> Whole machine hangs, but recovers after a few seconds; no visible 
> association to CPU or memory load.
> 
> Please include the patch from 
> 
> https://patchwork.freedesktop.org/patch/300891/
> 
> it claims to fix a bug that is reported since about a year in many different 
> bug reports and -trackers.

AFAICS, the patch was not applied, but could you confirm if the issue
still persist with recent kernel?

Regards,
Salvatore

Bug#987832: opendnssec: patch to build against mysql

[Mathieu Mirmont]

control: tags -1 +pending

On Fri, Apr 30, 2021 at 04:08:03PM +0200, Mattia Rizzolo wrote:
> Please consider applying this in Debian too, so that the package can be
> built without extra changes in Ubuntu too.

Sure, will do along with the new upstream version 2.1.8 as soon as
bullseye is released.

Cheers,

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#922666: confirmed bug report

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Tollef, Antoine,

On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
> Control: forcemerge 922666 928189
> Control: severity 922666 important
> Control: tags 922666 +patch +confirmed
> 
> I also see a regression with touchpads and trackpoint on a Thinkpad E431
> after upgrading from Debian stretch to buster. My research indicates
> this is a kernel regression, as yet to be fixed.
> 
> This is the result of my research, as available online at:
> 
> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
> 
> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
> freezes after sleep. Keyboard still works but not mouse until a
> reboot.
> 
> There's [bug 922666][] in Debian buster, without a fix. It also says
> it eventually recovers, which is not our experience. Possible dupe is
> [bug 928189][].
> 
> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
> 
> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
> which proposes the following workarounds:
> 
>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
> disabled`
> 
>  * A .service file:
> 
> # /etc/systemd/system/touchpad-sleep.service
> # restore touchpad on suspend
> 
> [Unit]
> Description=Restore Touchpad on suspend
> Before=sleep.target
> StopWhenUnneeded=yes
> 
> [Service]
> #Type=oneshot
> Type=idle
> RemainAfterExit=yes
> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
> /sys/bus/pci/drivers/i801_smbus/unbind'
> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
> /sys/bus/pci/drivers/i801_smbus/bind'
> 
> [Install]
> WantedBy=sleep.target
> 
>  * "Maybe try xserver-xorg-input-evdev instead of 
> xserver-xorg-input-libinput?"
> 
>  * reloading `psmouse`:
>  
> sudo modprobe -r psmouse
> sudo modprobe psmouse
> 
>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` seems to 
> solve the issue."
> 
>  * whatever this is:
>  
> # echo 1 > /sys/devices/rmi4-00/nosleep
> 
>  * "Anyone who still affected by touchpad issues after S3. Please
>switch back to suspend-to-idle in BIOS if s2idle is
>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>suspend-to-idle in BIOS->config->power menu."
> 
> [bug 1791427]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
> 
> There's also [bug 1442699][] in Fedora, which suggests those
> workarounds:
> 
>  * another module reload:
>  
> sudo rmmod i2c_hid
> sudo modprobe i2c_hid
> 
>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
>and this issue seems to have been resolved (for me)."
> 
>  * another `/proc` hack:
>  
> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
> 
>  * "The `psmouse.synaptics_intertouch=0` workaround still works for me."
> 
> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
> 
> Also related is this [libinput bug][] that's closed as "not our bug"
> because they claim it's a bug in the kernel.
> 
> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149
> 
> There are [two][] [patches][] on the Linux kernel which apparently fix the
> issue, still pending approval:
> 
> [two]: https://lkml.org/lkml/2019/2/20/700
> [patches]: https://lkml.org/lkml/2019/2/20/701
> 
> Possibly related: https://lkml.org/lkml/2016/8/18/134
> 
> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
> [pull request][] has been merged in mainline with two other fixes on
> the module./ [5.0.11][] also has fixes on the module. It's clearly a
> regression from Debian stretch (kernel 4.9) since it was working fine
> before.
> 
> Possibly related, [two-finger scrolling bug in Ubuntu][], which
> identifies [this commit][] as the source of the regression. [Upstream
> kernel bug][], still open.
> 
> [5.1rc7]: https://lkml.org/lkml/2019/4/28/270
> [pull request]: https://lkml.org/lkml/2019/7/12/19
> [5.0.11]: https://lkml.org/lkml/2019/5/2/287
> [Upstream kernel bug]: https://bugzilla.kernel.org/show_bug.cgi?id=196719
> [this commit]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e839ffab028981ac77f650faf8c84f16e1719738
> [two-finger scrolling bug in Ubuntu]: 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1722478
> 
> I haven't tried any of those workarounds. I hope this helps!

Can you confirm if this issue is still present with a recent kernel?

Regards,
Salvatore

Bug#987805: Clone #987805

[Chris Hofstaedtler]

* Jörg Frings-Fürst  [210430 18:51]:
> Hi,
> 
> I split this bug into 2 Parts (user / group) and (update-inetd).

If sane-utils creates, possibly dynamically named, files or
processes, cleanup of the user and group is not preferable. Removing
the user may lead to files owned by a stale uid, which can be
reassigned by a following useradd call, introducing a local security
problem.

If you want to improve the situation, please investigate if
switching to dynamic users is possible instead.

Chris

Bug#987803: geoclue-2.0: package doesn't purge cleanly

[Chris Hofstaedtler]

* Christoph Anton Mitterer  [210430 18:47]:
> On Fri, 2021-04-30 at 18:02 +0200, Chris Hofstaedtler wrote:
> > > 1) The user/group geoclue aren't removed at all.
> > 
> > This is correct behaviour for Debian packages.
> 
> Is this anywhere in the policy?

Nothing in policy says the users are supposed to be removed once
created.

> There seem to be quite a number of
> packages which do clean up properly:
> /var/lib/dpkg/info$ grep "deluser " *.*rm -l
> davfs2.postrm
> dnsmasq-base.postrm
> libvirt-daemon-system.postrm
> lightdm.postrm
> logcheck.postrm
> ntp.postrm
> openssh-server.postrm
> privoxy.postrm
> pulseaudio.postrm
> strongswan-starter.postrm


> And what sense would it make to leave it behind?

Cleanup works only in trivial cases. For everything else, you will
end up with a free uid and existing files or existing running
processes owned by this uid. A following useradd by the local admin
or a package install will "reassign" ownership of these files to a
user who was never supposed to have access to them, creating a
security problem.

It could be argued that most packages trying to cleanup users have a
security hole.

Policy however says that dynamic UIDs are to be used if possible.

Chris

Bug#987843: caribou-antler: describe what the package actually does

[Christoph Anton Mitterer]

Package: caribou-antler
Version: 0.4.21-7.1
Severity: wishlist



Hey.

I've recently cleaned up my installed packages and noted that I've had 
caribou-antler
installed for years whitout even knowing what it actually does.

caribou itself seems to run just fine without it (i.e. it doesn't seem to 
provide
more features).
Also I couln'd find anythin in the documentation or on the web.


Perhaps it would be nice to have the package's documentation tell what it 
actually
adds to caribou :-)


Thanks,
Chris.

Bug#987842: ifenslave: non-trivial bonding configuration fails

[Chris Hofstaedtler]

Package: ifenslave
Version: 2.11
Severity: serious

Only trivial configurations with no per-slave configurations seem to
work. I.e. the example in /usr/share/doc/ifenslave/examples/two_ethernet
works.

However, the example in /usr/share/doc/ifenslave/examples/two_hotplug_ethernet
does not - the slave devices are never added to the bondX device.

I believe this is caused by ifup bringing up the slave interfaces,
and the kernel refuses to add "UP" interfaces to a bondX device.

Version 2.9 in buster does not exhibit this problem, and can be used
on bullseye to demonstrate this regression from buster.

Chris

Bug#986866: apacheds: ApacheDS fails to start after clean install

[Chris Hofstaedtler]

Control: severity -1 serious
Control: tags -1 + confirmed

I can also trivially reproduce this problem.

Chris

Bug#987841: xsane: FTBFS on hppa - SANE_LDFLAGS is blank

[John David Anglin]

Source: xsane
Version: 0.999-10
Severity: normal

Dear Maintainer,

The xsane package fails to build on hppa.  The following errors occurs
during configuration:

checking for png_create_info_struct in -lpng... yes

ERROR: SANE-1.0.0 or newer is needed for compiling xsane
 - if you installed SANE as rpm make sure you also included
   sane-devel


This occurs with latest version of sane-backends.

HAVE_SANE isn't set to yes because SANE_LDFLAGS is empty.  These are
the SANE varibles that I see in config.log:

SANE_CFLAGS=''
SANE_LDFLAGS=''
SANE_LIBS='-lsane'
SANE_MAJOR=''
SANE_PREFIX='/usr'

The following lines set HAVE_SANE in configure.in:

PKG_CHECK_VAR([SANE_LDFLAGS], [sane-backends >= 1.0.0], [ldflags],
  [HAVE_SANE=yes])

If I force HAVE_SANE=yes, xsane builds okay.

Regards,
Dave Anglin

-- System Information:
Debian Release: 11.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.10.33+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#983475: shim-signed-common: failure to install w/o SetVariable()

[Heinrich Schuchardt]

Am 30. April 2021 20:06:22 MESZ schrieb Steve McIntyre :
>Control: reassign -1 grub2-common
>
>Hi Heinrich,
>
>[ reassigning to grub2-common, the package which includes grub-install
>]
>
>On Wed, Feb 24, 2021 at 09:08:15PM +0100, Heinrich Schuchardt wrote:
>>Package: shim-signed-common
>>Version: 1.33+15+1533136590.3beb971-7
>>Severity: normal
>>
>>Dear Maintainer,
>>
>>on systems using U-Boot as firmware the UEFI runtime service
>>SetVariable() is not available. Variable Boot has to be set
>manually
>>from the U-Boot console.
>>
>>The installation of shim-signed-common fails with:
>>
>>The following NEW packages will be installed:
>>  shim-signed-common
>>0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
>>Need to get 0 B/13.3 kB of archives.
>>After this operation, 50.2 kB of additional disk space will be used.
>>Preconfiguring packages ...
>>Can't exec "/tmp/shim-signed-common.config.PoZZwF": Permission denied
>at
>>/usr/lib/aarch64-linux-gnu/perl-base/IPC/Open3.pm line 178.
>>open2: exec of /tmp/shim-signed-common.config.PoZZwF configure 
>failed:
>>Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.
>>Selecting previously unselected package shim-signed-common.
>>(Reading database ... 149437 files and directories currently
>installed.)
>>Preparing to unpack
>>.../shim-signed-common_1.33+15+1533136590.3beb971-7_all.deb ...
>>Unpacking shim-signed-common (1.33+15+1533136590.3beb971-7) ...
>>Setting up shim-signed-common (1.33+15+1533136590.3beb971-7) ...
>>Installing for arm64-efi platform.
>>grub-install: warning: Cannot set EFI variable Boot.
>>grub-install: warning: efivarfs_set_variable: failed to create
>>/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c
>>for writing: Read-only file system.
>>grub-install: warning: _efi_set_variable_mode: ops->set_variable()
>>failed: Read-only file system.
>>grub-install: error: failed to register the EFI boot entry: Read-only
>>file system.
>>dpkg: error processing package shim-signed-common (--configure):
>> installed shim-signed-common package post-installation script
>>subprocess returned error exit status 1
>>Errors were encountered while processing:
>> shim-signed-common
>>
>>To make the package usable with U-Boot the installation should not
>fail
>>but complete with a warning.
>
>Apologies for not responding earlier...
>
>This is a complicated situation, and there is no single right answer
>at the moment. On platforms where EFI variables are settable
>(e.g. most x86 machines, arm64 server machines), we absolutely *must*
>report failure to install boot variables - this will make the system
>fail to boot after installation. But on other platforms (e.g. most
>current U-Boot systems), we can't install variables and instead we'll
>have to install to the removable media path. AFAIK the U-Boot
>developers are trying to add support for setting EFI variables on many
>of their platforms, so hopefully this problem will go away soon.

This will require OP-TEE and StandAloneMM. The problem will persist on most 
boards

>
>In the meantime, to do a better job we need a reliable way to detect
>if the platform can't support writing of EFI variables. Suggestions
>welcome. :-/

SetVariable() must return EFI_UNSUPPORTED in this case. With UEFI 2.8+ you 
could also look at the EFI_RT_PROPERTIES_TABLE configuration table to identify 
unsupported runtime services. But Linux will only provide access to the table 
with CONFIG_EFI_TEST=y.

Best regards

Heinrich

Bug#987831: php-illuminate-database: Security issue: SQL injection with Microsoft SQL Server

[Robin Gustafsson]

Package: php-illuminate-database
Version: 6.20.14+dfsg-1
Severity: important
Tags: security

Upstream has published a security advisory [1,2] regarding an SQL
injection vulnerability when used with Microsoft SQL Server.

The vulnerability was fixed upstream in version 6.20.26 and 8.40.0.

[1] https://blog.laravel.com/security-sql-injection-in-sql-server-limit-offset
[2] https://github.com/laravel/framework/security/advisories/GHSA-4mg9-vhxq-vm7j

Bug#987840: RFP: elpa-nhexl -- Emacs minor mode to edit files via hex-dump format

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-nhexl
  Version : 1.5
  Upstream Author : Stefan Monnier 
* URL : https://elpa.gnu.org/packages/nhexl-mode.html
* License : GPL-3+
  Programming Lang: Emacs-Lisp
  Description : Emacs minor mode to edit files via hex-dump format

This package implements NHexl mode, a minor mode for editing files
in hex dump format. The mode command is called `nhexl-mode'.

This minor mode implements similar functionality to `hexl-mode',
but using a different implementation technique, which makes it
usable as a "plain" minor mode. It works on any buffer, and does
not mess with the undo log or with the major mode.

Bug#932087: Bug#987695: dig/kdig alternatives

[Ondřej Surý]

Yes, this has been discussed before and rejected for this exact reason. I am 
not going to implement this.

Ondrej 
--
Ondřej Surý  (He/Him)

> On 30. 4. 2021, at 18:03, Chris Hofstaedtler  wrote:
> 
> Hello,
> 
> please do not use alternatives for dig/kdig. These tools are
> *debugging* tools, and while they are mostly compatible, they
> diverge in certain ways, including various default settings.
> 
> kdig also does not print its version number or identifies itself as
> kdig.
> 
> Its extremely important when debugging DNS problems or anything
> else, that the tools one is using, are exactly the tools one expects
> to be using, and not "transparently" something else.
> 
> Please reconsider.
> 
> Thanks,
> Chris
> 

Bug#983475: shim-signed-common: failure to install w/o SetVariable()

[Steve McIntyre]

Control: reassign -1 grub2-common

Hi Heinrich,

[ reassigning to grub2-common, the package which includes grub-install ]

On Wed, Feb 24, 2021 at 09:08:15PM +0100, Heinrich Schuchardt wrote:
>Package: shim-signed-common
>Version: 1.33+15+1533136590.3beb971-7
>Severity: normal
>
>Dear Maintainer,
>
>on systems using U-Boot as firmware the UEFI runtime service
>SetVariable() is not available. Variable Boot has to be set manually
>from the U-Boot console.
>
>The installation of shim-signed-common fails with:
>
>The following NEW packages will be installed:
>  shim-signed-common
>0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
>Need to get 0 B/13.3 kB of archives.
>After this operation, 50.2 kB of additional disk space will be used.
>Preconfiguring packages ...
>Can't exec "/tmp/shim-signed-common.config.PoZZwF": Permission denied at
>/usr/lib/aarch64-linux-gnu/perl-base/IPC/Open3.pm line 178.
>open2: exec of /tmp/shim-signed-common.config.PoZZwF configure  failed:
>Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.
>Selecting previously unselected package shim-signed-common.
>(Reading database ... 149437 files and directories currently installed.)
>Preparing to unpack
>.../shim-signed-common_1.33+15+1533136590.3beb971-7_all.deb ...
>Unpacking shim-signed-common (1.33+15+1533136590.3beb971-7) ...
>Setting up shim-signed-common (1.33+15+1533136590.3beb971-7) ...
>Installing for arm64-efi platform.
>grub-install: warning: Cannot set EFI variable Boot.
>grub-install: warning: efivarfs_set_variable: failed to create
>/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c
>for writing: Read-only file system.
>grub-install: warning: _efi_set_variable_mode: ops->set_variable()
>failed: Read-only file system.
>grub-install: error: failed to register the EFI boot entry: Read-only
>file system.
>dpkg: error processing package shim-signed-common (--configure):
> installed shim-signed-common package post-installation script
>subprocess returned error exit status 1
>Errors were encountered while processing:
> shim-signed-common
>
>To make the package usable with U-Boot the installation should not fail
>but complete with a warning.

Apologies for not responding earlier...

This is a complicated situation, and there is no single right answer
at the moment. On platforms where EFI variables are settable
(e.g. most x86 machines, arm64 server machines), we absolutely *must*
report failure to install boot variables - this will make the system
fail to boot after installation. But on other platforms (e.g. most
current U-Boot systems), we can't install variables and instead we'll
have to install to the removable media path. AFAIK the U-Boot
developers are trying to add support for setting EFI variables on many
of their platforms, so hopefully this problem will go away soon.

In the meantime, to do a better job we need a reliable way to detect
if the platform can't support writing of EFI variables. Suggestiong
welcome. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Bug#987839: apt-listbugs: daily cleanup runs hourly

[Ross Boylan]

Package: apt-listbugs
Version: 0.1.35
Severity: minor
X-Debbugs-Cc: rossboy...@stanfordalumni.org

Dear Maintainer,

It would be nice to clean up this minor annoyance before buster's release.

   * What led up to the situation?

   Installed apt-listbugs and logcheck on a debian testing system.
   Every *hour* I get email from logcheck that includes lines like this:
   Apr 30 08:37:06 debtest systemd[1]: Starting Daily apt-listbugs
preferences cleanup...
   Apr 30 08:37:06 debtest systemd[1]: Finished Daily apt-listbugs
preferences cleanup.
(Obviously logcheck and the email are incidental; the point is the
   "Daily" cleanup is actually run hourly.  However, the emails are
   part of why I find it annoying.)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 Investigated why this is happening.  The package has an entry in
   /etc/cron.daily, which seems correct.  But it also has
   /lib/systemd/system/apt-listbugs.timer which includes
   OnCalendar=*-*-* *:20
   I believe this is telling it to trigger something at 20 minutes
   after the hour for every hour.  There is also
   RandomizedDelaySec=20min
   in the same file, which may explain why it seems to run between 20
   and 40 minutes after the hour for me.

   This seems more like a task for anacron for systems that may not be
   up all the time, but I don't know enough about systemd to be sure
   how to turn it off, or if it can handle these situations.

   * What was the outcome of this action?
   Only observations so far, and so no change.  I might change to
   OnCalendar=*-*-* 20:20
   which I think means run at 8:20pm every day.  But the VM is not up
   all the time and so that might miss some times it should run,
   unless the /etc/cron.daily/ entry acts as a safety net.

   * What outcome did you expect instead?
   That a daily cleanup job would only run once a day.

Another work-around for the visible annoyance would be for me to tell
logcheck to ignore the relevant messages.

Thanks for your work on the package:)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt 2.2.3
ii  ruby1:2.7+2
ii  ruby-debian 0.3.10+b4
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-5
ii  ruby-unicode0.4.4.4-1+b1
ii  ruby-xmlparser  0.7.3-4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2

Versions of packages apt-listbugs suggests:
ii  konqueror [www-browser]  4:20.12.0-4
ii  reportbug7.10.3
ii  sensible-utils   0.0.14
ii  xdg-utils1.1.3-4

-- no debconf information

Bug#986866: apacheds: ApacheDS fails to start after clean install

[Elias Batek - IT Kaufmann GmbH]

Can confirm.
Unfortunately, same here.

Regards,
Elias

Bug#852749: Bug still present, patches work on modules in kernel package 4.9.0-9

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Fri, May 10, 2019 at 10:10:05PM -0400, AJ Milne wrote:
> Realizing this thread is now a few years old: I had the same error
> (transfer buffer not dma capable, coming from usb_hcd_map_urb_for_dma)
> using a Line6 Pod XT through the snd-usb-pod kernel module (uses
> snd-usb-line6), the machine running stock kernel package 4.9.0-9.
> 
> Inspecting the source, it appears the message buffers are still coming from
> the stack as of this kernel package. Applying Ben Hutchings' patches as of
> message:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852749#10
> 
> ... these moving the message buffers off the stack and adding error checks
> to the toneport set, doing so corrected the problem. Device is now
> functional; thanks much.

Can you check with more recent kernels if the issue still persist
without the patches from Ben? (I.e. has the issue in meanwhile been
fixed upstream directly)?

Regards,
Salvatore

Bug#987838: unblock: gnupg2/2.2.27-2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-gnupg-ma...@lists.alioth.debian.org

Please unblock package gnupg2

Being fully aware about the signifiance of the gnupg2 package and the
advanced progress of the bullseye release, I am asking to unblock
gnupg2/2.2.27-2. As there are no changes to the code, just a
documentation update, there shouldn't be any risk of introducing
regressions.

[ Reason ]
Document the fact the gnupg suite no longer reads a configuration file
at "~/.gnupg/options".

This fixes Debian bug is . Related,
mentioning this in the release notes has been requested in
.

[ Impact ]
Without that information, users have less chance to learn about that
change, and might more likely experience regressions or breakage in
their GnuPG-based workflows.

[ Risks ]
There shouldn't be any risks as no code was changed.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  (did not mention I'd added myself to uploaders, though)
  [X] I reviewed all changes and I approve them
  (TBH, they were done by yours truly)
  [X] attach debdiff against the package in testing

unblock gnupg2/2.2.27-2

diff -Nru gnupg2-2.2.27/debian/changelog gnupg2-2.2.27/debian/changelog
--- gnupg2-2.2.27/debian/changelog  2021-02-08 23:57:00.0 +0100
+++ gnupg2-2.2.27/debian/changelog  2021-04-22 20:40:36.0 +0200
@@ -1,3 +1,10 @@
+gnupg2 (2.2.27-2) unstable; urgency=medium
+
+  * Add a NEWS entry about the end of support for ~/.gnupg/options.
+Closes: #985158
+
+ -- Christoph Biedl   Thu, 22 Apr 2021 
20:40:36 +0200
+
 gnupg2 (2.2.27-1) unstable; urgency=medium
 
   [ NIIBE Yutaka ]
diff -Nru gnupg2-2.2.27/debian/control gnupg2-2.2.27/debian/control
--- gnupg2-2.2.27/debian/control2021-02-08 23:56:55.0 +0100
+++ gnupg2-2.2.27/debian/control2021-04-22 20:40:36.0 +0200
@@ -5,6 +5,7 @@
 Uploaders:
  Eric Dorland ,
  Daniel Kahn Gillmor ,
+ Christoph Biedl ,
 Standards-Version: 4.5.1
 Build-Depends:
  automake,
diff -Nru gnupg2-2.2.27/debian/NEWS gnupg2-2.2.27/debian/NEWS
--- gnupg2-2.2.27/debian/NEWS   2021-02-08 20:38:26.0 +0100
+++ gnupg2-2.2.27/debian/NEWS   2021-04-22 20:40:36.0 +0200
@@ -1,3 +1,12 @@
+gnupg2 (2.2.27-2) unstable; urgency=medium
+
+  Starting with version 2.2.27-1, per-user configuration of the GnuPG
+  suite has completely moved to ~/.gnupg/gpg.conf, and ~/.gnupg/options
+  is no longer in use.  Please rename the file if necessary, or move
+  its contents to the new location.
+
+ -- Christoph Biedl   Thu, 22 Apr 2021 
20:37:45 +0200
+
 gnupg2 (2.2.17-1) unstable; urgency=medium
 
   Upstream GnuPG now defaults to not accepting third-party certifications


signature.asc
Description: PGP signature

Bug#987805: Clone #987805

[Jörg Frings-Fürst]

clone 987805 -1 
retitle -1 sane-utils: package doesn't purge cleanly (user / group)
retitle 987805 sane-utils: package doesn't purge cleanly (update-inetd)
quit


Hi,

I split this bug into 2 Parts (user / group) and (update-inetd).

CU
Jörg

New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



signature.asc
Description: This is a digitally signed message part

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Fri, 2021-04-30 at 21:20 +0530, Ritesh Raj Sarraf wrote:
> 
> How would you like to see this fixed Cyril ?
> 
> The easiest option, if d-i supports, would be to extend architecture
> list to: `linux-any`, keeping it in line with what the actual open-
> iscsi package supports.

Here's what I've done. And propose.

rrs@priyasi:~/.../open-iscsi (wip/ritesh/fix-armel)$ git diff
master..HEAD
diff --git a/debian/changelog b/debian/changelog
index acfa52e..8365844 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+open-iscsi (2.1.3-4) unstable; urgency=medium
+
+  * [98b0d39] Add check for architectures where open-iscsi-udeb is
built
+  * [bf3d0f5] Add armel to support architecture for d-i
+
+ -- Ritesh Raj Sarraf   Fri, 30 Apr 2021 22:07:27
+0530
+
 open-iscsi (2.1.3-3) unstable; urgency=medium
 
   * [47645a5] Make open-iscsi-udeb compatible with d-i.
diff --git a/debian/control b/debian/control
index a69ce2c..3df235f 100644
--- a/debian/control
+++ b/debian/control
@@ -139,7 +139,7 @@ Package: open-iscsi-udeb
 #   linux kernel udebs) must exist for these architectures - so
 #   check that before adding them to this list; the other
 #   scsi-(core|common|...)-modules are NOT sufficient!
-Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
ppc64el s390x
+Architecture: amd64 arm64 armel armhf i386 ia64 mips mipsel powerpc
ppc64 ppc64el s390x
 Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
diff --git a/debian/rules b/debian/rules
index 60211b8..17ef5d8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -101,4 +101,9 @@ override_dh_missing:
dh_missing --fail-missing
 
 override_dh_makeshlibs:
+ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 ia64
mips mipsel powerpc ppc64 ppc64el s390x))
dh_makeshlibs --add-udeb=open-iscsi-udeb
+else
+   dh_makeshlibs
+endif
+



I noticed that d-i seems to have gained support for armel too. So my
proposed changes introduce support for armel. And the conditional check
also ensures to call the correct dh_makeshlibs on the respective host
architecture.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#956192: Any progress or missing information?

[Helge Kreutzmann]

Hello Laura,
On Sun, Apr 11, 2021 at 12:36:38PM +0200, Laura Arjona Reina wrote:
> I have added an exception about manpages-l10n in a similar way than was
> already for manpages-fr-extra (thanks David Prévot for the hint):
> 
> https://salsa.debian.org/webmaster-team/webwml/-/commit/017f1d07c22c906dcb76ad48d7db75ff615b9b99
> 
> Closing the bug, feel free to reopen if you see something broken or not
> working as expected (I think the scripts run once a day, so we need to
> wait a bit to see the efects of the change made in the webwml repo).

> El 10/4/21 a las 19:18, Helge Kreutzmann escribió:
> > Dear webmasters,
> > one year ago I requested that manpages-l10n should be removed from
> > https://www.debian.org/international/l10n/po/de
> > 
> > as it does not make sense to track it. David Prevot reported that in
> > the past the (no longer existing) manpages-fr-extra had been removed
> > from being listed there as well.
> > 
> > Please remove it for the other languages as well (fr, es, mk, ..),
> > tracking it here really is useless and (speaking as part of upstream)
> > have good working relationship with the translators (as far as they
> > are still active).
> > 
> > If you require any further input from my side please let me know.

How long does this exception require to become effective? So fare,
there is no change visible.

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#987805: sane-utils: package doesn't purge cleanly

[Christoph Anton Mitterer]

On Fri, 2021-04-30 at 16:51 +0200, Jörg Frings-Fürst wrote:
> the problem at point 2 cannot be shown here. Because of the
> dependencies, sane-utils is always deleted before update-inetd.

Didn't seem to have been the case here, looking at my
/var/log/apt/term.log (all from one run):
Removing unrar-free (1:0.0.1+cvs20140707-4+b1) ...
Removing update-inetd (4.51) ...
Removing usbmuxd (1.1.1-2) ...
...
[snipsnap]
...
Purging configuration files for aspell-en (2018.04.16-0-1) ...
Purging configuration files for update-inetd (4.51) ...
Purging configuration files for rpm (4.16.1.2+dfsg1-0.6) ...




https://www.debian.org/doc/debian-policy/ch-relationships.html
seems to say:
The meaning of the five dependency fields is as follows:
Depends
...
Finally, the Depends field should be used if the depended-on package is
needed by the postrm script to fully clean up after the package
removal. There is no guarantee that package dependencies will be
available when postrm is run, but the depended-on package is more
likely to be available if the package declares a dependency
(particularly in the case of postrm remove). The postrm script must
gracefully skip actions that require a dependency if that dependency
isn’t available.


> 
> Can you please expand this bug from the system on which the error
> occurred using report-bug. This will give me information for further
> investigation.


What exactly do you mean with "expand"? :-)


Cheers,
Chris.

Bug#987803: geoclue-2.0: package doesn't purge cleanly

[Christoph Anton Mitterer]

On Fri, 2021-04-30 at 18:02 +0200, Chris Hofstaedtler wrote:
> > 1) The user/group geoclue aren't removed at all.
> 
> This is correct behaviour for Debian packages.

Is this anywhere in the policy? There seem to be quite a number of
packages which do clean up properly:

/var/lib/dpkg/info$ grep "deluser " *.*rm -l
davfs2.postrm
dnsmasq-base.postrm
libvirt-daemon-system.postrm
lightdm.postrm
logcheck.postrm
ntp.postrm
openssh-server.postrm
privoxy.postrm
pulseaudio.postrm
strongswan-starter.postrm


And what sense would it make to leave it behind?


Cheers,
Chris.

Bug#987803: geoclue-2.0: package doesn't purge cleanly

[Chris Hofstaedtler]

* Christoph Anton Mitterer  [210430 16:02]:
> On purging the package there are leftovers:
> 
> 1) The user/group geoclue aren't removed at all.

This is correct behaviour for Debian packages.

Chris

Bug#932087: dig/kdig alternatives

[Chris Hofstaedtler]

Hello,

please do not use alternatives for dig/kdig. These tools are
*debugging* tools, and while they are mostly compatible, they
diverge in certain ways, including various default settings.

kdig also does not print its version number or identifies itself as
kdig.

Its extremely important when debugging DNS problems or anything
else, that the tools one is using, are exactly the tools one expects
to be using, and not "transparently" something else.

Please reconsider.

Thanks,
Chris

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

The upload I prepped failed on some of the architectures.
https://buildd.debian.org/status/logs.php?pkg=open-iscsi=2.1.3-3

In d/control, there is:

```
Package: open-iscsi-udeb
# Note: the (virtual) udeb package scsi-modules (provided by different
#   linux kernel udebs) must exist for these architectures - so
#   check that before adding them to this list; the other
#   scsi-(core|common|...)-modules are NOT sufficient!
Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
ppc64el s390x
Section: debian-installer
Package-Type: udeb
```


The udeb package was introduced by Colin Watson from Ubuntu. I extended
the architecture list, based on the supported architectures by d-i. But
I really don't use or test this functionality of the package.


How would you like to see this fixed Cyril ?

The easiest option, if d-i supports, would be to extend architecture
list to: `linux-any`, keeping it in line with what the actual open-
iscsi package supports.





On Thu, 2021-04-29 at 13:36 +0530, Ritesh Raj Sarraf wrote:
> 
> Thank you. I find your reworded comment proper and have applied the
> same.
> 
> I will now work with the release team.
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

Control: tag -1 +moreinfo +help

On Fri, 2021-04-30 at 21:02 +0530, Ritesh Raj Sarraf wrote:
> Control: tag -1 -moreinfo
> 
> On Fri, 2021-04-30 at 20:33 +0530, Ritesh Raj Sarraf wrote:
> > On Thu, 2021-04-29 at 22:19 +0200, Paul Gevers wrote:
> > > > The interim workaround is to ship the library into the open-
> > > > iscsi-
> > > udeb
> > > > package itself.
> > > 
> > > This looks acceptable, but could you please add a binary debdiff to
> > > this
> > > report to show the effect of the changes?
> > 
> > I guess I used the tool in the right way.
> > 
> > rrs@priyasi:.../Result$ debdiff /var/tmp/Chrome-Downloads/open-
> > iscsi_2.1.3-2_amd64.deb open-iscsi_2.1.3-3_amd64.deb
> > File lists identical (after any substitutions)
> > 
> > Control files: lines which differ (wdiff format)
> > 
> > Version: [-2.1.3-2-] {+2.1.3-3+}
> > 
> > 
> > 
> > I will go ahead with the upload now and will untag this bug report of
> > `moreinfo`.
> > 
> 
> The package has been uploaded to Debian Unstable now.
> 

And it has failed to build on some of the architectures. And that is
because, we have:

```
Package: open-iscsi-udeb
# Note: the (virtual) udeb package scsi-modules (provided by different
#   linux kernel udebs) must exist for these architectures - so
#   check that before adding them to this list; the other
#   scsi-(core|common|...)-modules are NOT sufficient!
Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
ppc64el s390x
Section: debian-installer
Package-Type: udeb
```

Let me work with the d-i team and come with a follow-up fix/upload.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers

[Christoph Martin]

Am 30.04.21 um 14:32 schrieb Salvatore Bonaccorso:
> 
> is this problem still relevant?
> 

I think so. My upstream request was never really considered.
You still have the problem that a kernel-nfs server with only few memory
runs out of sessions with a lot of clients.

> Side note that we would anyway not apply a patch which would not have
> been accepted upstream, likely unless there are very valid reasons.
> 

Yes I also think so.

We changed to nfs-ganesha as a user level NFS server, which does not
have this restriction.

Christoph

Bug#982845: [Pkg-ayatana-devel] Bug#982845: Acknowledgement (Build tests are failed but ignored)

[Sebastien Bacher]

Hey Mike,

Great, thanks, that's helpful, I will check that next week on Ubuntu!

Cheers,
Sebastien

Le 30/04/2021 à 17:35, Mike Gabriel a écrit :
>
> I have just uploaded a libayatana-appindicator version that should fix
> this problem.
>
> I also filed a PR upstream for this:
> https://github.com/AyatanaIndicators/libayatana-appindicator/pull/19
>
> Greets,
> Mike 

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

Control: tag -1 -moreinfo

On Fri, 2021-04-30 at 20:33 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2021-04-29 at 22:19 +0200, Paul Gevers wrote:
> > > The interim workaround is to ship the library into the open-
> > > iscsi-
> > udeb
> > > package itself.
> > 
> > This looks acceptable, but could you please add a binary debdiff to
> > this
> > report to show the effect of the changes?
> 
> I guess I used the tool in the right way.
> 
> rrs@priyasi:.../Result$ debdiff /var/tmp/Chrome-Downloads/open-
> iscsi_2.1.3-2_amd64.deb open-iscsi_2.1.3-3_amd64.deb
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Version: [-2.1.3-2-] {+2.1.3-3+}
> 
> 
> 
> I will go ahead with the upload now and will untag this bug report of
> `moreinfo`.
> 

The package has been uploaded to Debian Unstable now.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#967047: plymouth-start.service: Unit configured to use KillMode=none

[Faustin Lammler]

Hi,
FYI, I hit this bug by trying to verify a systemd unit file.

| systemd-analyze verify docker.service
| /lib/systemd/system/plymouth-start.service:16: Unit configured to use 
KillMode=none. This is unsafe, as it disables systemd's process lifecycle 
management for the service. Please update your service to use a safer 
KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is 
deprecated and will eventually be removed.

Here is the MR:
https://salsa.debian.org/debian/plymouth/-/merge_requests/3

Cheers!

--
Faustin Lammler
GPG: F652 BCD1 1AA8 8975 F010 48A5 390A 2F27 832A 5C79


signature.asc
Description: PGP signature

Bug#932087: knot-host: Add to update-alternatives

[Jakub Ružička]

Hello,

thanks for handling the bind9 side of things!

I'm happy to update the knot source package with update-alternatives
functionality as soon as it's implemented in bind9 package which is a
necessary prerequisite to avoid package file conflicts if I understand
correctly.


Cheers,
Jakub

On Wed, 28 Apr 2021 00:15:39 +0200 Daniel Baumann wrote:
> tag 932087 patch
> thanks
>
> Hi,
>
> I've attached patches that we're using in our Debian derrivate for this.
> I've also send the required patches to a bugreport against src:bind9
> (will add a "block by" to this bug after having recieved the bugnumber).
>
> Regards,
> Daniel
>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987766: unblock: open-iscsi/2.1.3-2

[Ritesh Raj Sarraf]

On Thu, 2021-04-29 at 22:19 +0200, Paul Gevers wrote:
> > The interim workaround is to ship the library into the open-iscsi-
> udeb
> > package itself.
> 
> This looks acceptable, but could you please add a binary debdiff to
> this
> report to show the effect of the changes?

I guess I used the tool in the right way.

rrs@priyasi:.../Result$ debdiff /var/tmp/Chrome-Downloads/open-
iscsi_2.1.3-2_amd64.deb open-iscsi_2.1.3-3_amd64.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Version: [-2.1.3-2-] {+2.1.3-3+}



I will go ahead with the upload now and will untag this bug report of
`moreinfo`.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#987836: unblock: openjdk-11/11.0.11+9-1 and openjdk-17/17~19-1

[Matthias Klose]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock the openjdk-11 and openjdk-17 packages. For openjdk-11, it's the
quaterly security release, and for openjdk-17 it's the next snapshot made after
including the security fixes made for the openjdk-11 release.

openjdk-11 (11.0.11+9-1) unstable; urgency=high

  * OpenJDK 11.0.11+9 build (release).
  * Security fixes:
- JDK-8244473: Contextualize registration for JNDI.
- JDK-8244543: Enhanced handling of abstract classes.
- JDK-8259633: compiler/graalunit/CoreTest.java fails with NPE
  after JDK-8244543.
- JDK-8250568: Less ambiguous processing (CVE-2021-2161).
- JDK-8253799: Make lists of normal filenames.
- JDK-8261183: Follow on to Make lists of normal filenames.
- JDK-8249906: Enhance opening JARs (CVE-2021-2163).
- JDK-8258247: Couple of issues in fix for JDK-8249906.
- JDK-8259428: AlgorithmId.getEncodedParams() should return copy.
- JDK-8257001: Improve HTTP client support.


openjdk-17 (17~19-1) unstable; urgency=high

  * OpenJDK 17 snapshot, build 19.
- Fix JDK-8250568: Less ambiguous processing (CVE-2021-2161).
- Fix JDK-8249906: Enhance opening JARs (CVE-2021-2163).

Bug#987805: sane-utils: package doesn't purge cleanly

[Jörg Frings-Fürst]

tags 987805 + moreinfo
tags 987805 + unreproducible
quit



Hello Christoph,



thank you for spending your time helping to make Debian better with
this bug report.

the problem at point 2 cannot be shown here. Because of the
dependencies, sane-utils is always deleted before update-inetd.

Can you please expand this bug from the system on which the error
occurred using report-bug. This will give me information for further
investigation.

Thanks in advance

CU
Jörg

Am Freitag, dem 30.04.2021 um 03:08 +0200 schrieb Christoph Anton
Mitterer:
> Package: sane-utils
> Version: 1.0.31-4
> Severity: normal
> 
> 
> 
> Hi.
> 
> On purging the package there are leftovers:
> 
> 1) The saned user/group aren't removed.
> 
> 2) When update-inetd is also purged in the same run (which is not so
> unlikely,
> when it was pulled in by saned-utils):
> Purging configuration files for sane-utils (1.0.31-4) ...
> /var/lib/dpkg/info/sane-utils.postrm: 31: update-inetd: not found
> /var/lib/dpkg/info/sane-utils.postrm: 32: update-inetd: not found
> /var/lib/dpkg/info/sane-utils.postrm: 31: update-inetd: not found
> /var/lib/dpkg/info/sane-utils.postrm: 32: update-inetd: not found
> 
> Cheers,
> Chris.

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



signature.asc
Description: This is a digitally signed message part

Bug#987835: unblock: python2.7/2.7.18-7

[Matthias Klose]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python2.7. No code changes, just adding a breaks for
upgrades, see #987661 for the issue and the diff for the fix.

Bug#985870: [debian-mysql] Bug#985870: mariadb-server-10.5: unowned files after purge (policy 6.8, 10.8): /usr/share/mysql/debian-10.5.flag

[Faustin Lammler]

Hi Andreas!
Thanks for your report and I can confirm this with the latest 10.5
version (debian and upstream).

| podman run -it debian:sid bash -c "apt-get update &&\
|   apt-get install -y mariadb-server &&\
|   ls /usr/share/mysql/debian-*.flag &&\
|   apt-get autopurge -y --force mariadb-server"

@Otto, I have verified on 10.3 and my understanding is that there might be a
confusion between datadir and statedir.

For 10.3 we did not create the flag in the statedir whereas upstream
did:
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/buster/debian/mariadb-server-10.3.postinst#L96-114
https://github.com/MariaDB/server/blob/10.3/debian/mariadb-server-10.3.postinst#L135-L156

I am not sure if this statedir flag (/usr/share/mysql/debian-*.flag) is
used by any maintainer script, let me know if you want me to open a jira
issue and a PR upstream (I guess we should fix this upstream).

Faustin


signature.asc
Description: PGP signature

Bug#987834: unblock: fwlogwatch/1.4-3

[tony mancill]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package fwlogwatch

Dear Release Team,

[ Reason ]
I am requesting an unblock for an upload that addresses a grave [1] bug
that was opened during the freeze.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987315

[ Impact ]
If the unblock isn't granted, fwlogwatch should not ship with bullseye
because it hangs during install and requires the user to stop the
systemd unit and manually address the PID file issue .  I don't have a
sense of the impact of removal based on popcon, which 112.

https://qa.debian.org/popcon.php?package=fwlogwatch

[ Tests ]
I reproduced the issue with the 1.4-2 package.  I successful tested
package installation, daemon startup, manipulation with
systemctl, and package removal with 1.4-3.

The upload also addresses a trivial bug in the autopkgtest that was
preventing the tests from running at all.  The tests now show as "No
test results" on the PTS (https://tracker.debian.org/pkg/fwlogwatch),
but that is because the test itself is now marked as superficial.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969828

[ Risks ]
The fix to the name of the PID file is trivial.  The package is leaf.  I
am not familiar with alternatives.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Thank you for your work on Debian!

unblock fwlogwatch/1.4-3
diff -Nru fwlogwatch-1.4/debian/changelog fwlogwatch-1.4/debian/changelog
--- fwlogwatch-1.4/debian/changelog 2019-07-22 05:27:20.0 -0700
+++ fwlogwatch-1.4/debian/changelog 2021-04-23 21:10:36.0 -0700
@@ -1,3 +1,12 @@
+fwlogwatch (1.4-3) unstable; urgency=medium
+
+  * QA upload.
+  * Correct service PID file (Closes: #987315)
+  * Mark autopkgtest as superficial (Closes: #969828)
+  * Correct the path to the fwlogwatch command in the autopkgtest.
+
+ -- tony mancill   Fri, 23 Apr 2021 21:10:36 -0700
+
 fwlogwatch (1.4-2) unstable; urgency=medium
 
   * QA upload.
diff -Nru fwlogwatch-1.4/debian/fwlogwatch.service 
fwlogwatch-1.4/debian/fwlogwatch.service
--- fwlogwatch-1.4/debian/fwlogwatch.service2019-07-22 05:27:20.0 
-0700
+++ fwlogwatch-1.4/debian/fwlogwatch.service2021-04-23 21:10:36.0 
-0700
@@ -9,7 +9,7 @@
  'if [ "x${START_DAEMON}" != "xtrue" ]; then echo "aborted"; exit 1; fi; \
   exec /usr/sbin/fwlogwatch -c /etc/fwlogwatch/fwlogwatch.config -R ${PARAMS}'
 Type=forking
-PIDFile=/run/htpdate.pid
+PIDFile=/run/fwlogwatch.pid
 
 ### Security ###
 
diff -Nru fwlogwatch-1.4/debian/tests/control 
fwlogwatch-1.4/debian/tests/control
--- fwlogwatch-1.4/debian/tests/control 2019-07-22 05:27:20.0 -0700
+++ fwlogwatch-1.4/debian/tests/control 2021-04-23 21:10:36.0 -0700
@@ -1 +1,3 @@
-Test-Command: fwlogwatch -V | grep -q "Zlib support enabled"
+Test-Command: /usr/sbin/fwlogwatch -V | grep -q "Zlib support enabled"
+Depends: @
+Restrictions: superficial


signature.asc
Description: PGP signature

Bug#987800: sane-utils: split out saned from sane-utils?

[Jörg Frings-Fürst]

Hello Christoph,


thank you for spending your time helping to make Debian better with
this bug report.

I think this is not necessary; especially because the daemon is set to
deactivated during installation. 

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.


Am Donnerstag, dem 29.04.2021 um 23:48 +0200 schrieb Christoph Anton
Mitterer:
> Package: sane-utils
> Version: 1.0.31-4
> Severity: wishlist
> 
> 
> Hi.
> 
> Just an idea, ... it could make sense to split out saned from sane-
> utils.
> 
> That way people can install the -utils package without getting the
> daemon
> (which most people probably won't need anyway).
> 
> 
> Cheers,
> Chris.




signature.asc
Description: This is a digitally signed message part

Bug#980316: starting with clipanion

[Pirate Praveen]

On Mon, 18 Jan 2021 00:19:59 +0530 Pirate Praveen 
 wrote:

> clipanion needs @wessberg/rollup-plugin-ts as build dependency

clipanion 3 has moved to @rollup/plugin-typescript which is already 
packaged.


https://www.npmjs.com/package/clipanion?activeTab=dependencies

Bug#987620: Bug

[Daniel Wagenaar]

Looks spectacular. I'd be very happy for you to upload it.

Thanks!

- Daniel

On 4/29/21 1:50 AM, Barak A. Pearlmutter wrote:
>>> I'd be happy to sponsor it.
>> I would very much appreciate that
> Okay then!
>
> (CCing the WPNN bug, for posterity, and so others can see this is taken.)
>
> Took a quick look, and did a major updating of the debian/ packaging scripts.
>
> There were issues with passing flags through to the actual compiler,
> so I did some Rube Goldberg tricks to bypass the top-level Makefile
> and let debhelper do its tricks with qmake.
> Ultimately, the "right thing" would be to mess about with the
> "upstream" build scripts to make them more standard, like have the
> qmake stuff do the installation, have only one qmake invocation, yada
> yada.
>
> Anyway, I forked your github repo and pushed my changes there. Please
> check if it works with my scripts. If you're happy with everything, I
> can just upload it. Or if you'd rather, I can be more hands-off and
> sponsor someone else's uploads (e.g., yours) and let you do all the
> packaging stuff w/ my feedback etc. However as a PI myself, I know
> what I'd choose!
>
> Minor stuff:
>
> Not sure if it belongs in "science" because that's generally for
> things like data analysis software, numeric methods, machine learning
> libraries, etc.
> But what the heck. That gives it an automatic team maintenance, which is nice.
> And it can always be shifted.
>
> There are some compiler warnings, like using an old sort function
> instead of the new approved one. Someone should probably take a look
> at them sometime.
>
> I'm renamed the icon to just eln, since the longer one seems a bit
> silly: what if (no offense) you're hit by a bus?
>
> Cheers,
>
> --Barak.

Bug#987833: r-cran-openmx: FTBFS on mips due to a variable called 'mips'

[Yangfl]

Source: r-cran-openmx
Tags: patch
Severity: minor

Hi,

r-cran-openmx FTBFS on mips (after fixing #987755), since a variable
is called 'mips' and on mips 'mips' is expanded to '1'. Please
consider applying this patch, adding a suffix to the variable 'mips'.
diff --git a/src/ba81quad.cpp b/src/ba81quad.cpp
index 3df6ee0..6ebca7d 100644
--- a/src/ba81quad.cpp
+++ b/src/ba81quad.cpp
@@ -212,7 +212,7 @@ void ifaGroup::import(const List )
 
 	paramRows = -1;
 	int pmatCols=-1;
-	int mips = 1;
+	int mips_ = 1;
 	int dataRows = 0;
 	NumericVector Rmean;
 	NumericMatrix Rcov;
@@ -272,7 +272,7 @@ void ifaGroup::import(const List )
 		} else if (strEQ(key, "qpoints")) {
 			qpoints = as(slotValue);
 		} else if (strEQ(key, "minItemsPerScore")) {
-			mips = as(slotValue);
+			mips_ = as(slotValue);
 		} else {
 			// ignore
 		}
@@ -313,7 +313,7 @@ void ifaGroup::import(const List )
 
 	setLatentDistribution(mean, cov);
 
-	setMinItemsPerScore(mips);
+	setMinItemsPerScore(mips_);
 
 	if (numItems() != pmatCols) {
 		mxThrow("item matrix implies %d items but spec is length %d",
@@ -422,13 +422,13 @@ void ba81NormalQuad::layer::setupOutcomes(ifaGroup )
 void ba81NormalQuad::setupOutcomes(class ifaGroup )
 { layers[0].setupOutcomes(ig); }
 
-void ifaGroup::setMinItemsPerScore(int mips)
+void ifaGroup::setMinItemsPerScore(int mips_)
 {
 	if (numItems() && mips > numItems()) {
 		mxThrow("minItemsPerScore (=%d) cannot be larger than the number of items (=%d)",
-			 mips, numItems());
+			 mips_, numItems());
 	}
-	minItemsPerScore = mips;
+	minItemsPerScore = mips_;
 }
 
 void ifaGroup::buildRowMult()
diff --git a/src/ba81quad.h b/src/ba81quad.h
index 45cbe42..d99b58c 100644
--- a/src/ba81quad.h
+++ b/src/ba81quad.h
@@ -742,7 +742,7 @@ private:
 	int minItemsPerScore;
 	double weightSum;
 public:
-	void setMinItemsPerScore(int mips);
+	void setMinItemsPerScore(int mips_);
 	std::vector rowSkip; // whether to treat the row as NA
 
 	// workspace

Bug#985297: libreoffice-common: do not use dir_to_symlink for /usr/lib/libreoffice/share/registry

[Andreas Beckmann]

Followup-For: Bug #985297
Control: tag -1 patch

Hi Rene,

I've been experimenting a lot to fix this bug.
One problem is Breaks in one package being handled first (by
deconfiguratio) and subsequent occurrences of Conflicts in another
package will be ignored for deconfigured packages (and removal will not
happen).

We can fix most of the upgrade issues by propagating the Conflicts to
the package with the Breaks, s.t. deconfiguration does not happen but
removal does happen immediately. Unfortunately this does not work if
there are too many packages the would need to be removed together since
dpkg does not get the optimal ordering for doing that. These are mostly
upgrade paths with libreoffice-impress or libreoffice-report-builder
installed.

So in the end I resorted to not using
  dpkg-maintscript-helper dir_to_symlink
as I had initially suggested but fixing it up manually in the postinst.

I've running various buster->bullseye upgrade scenarios (with and
without recommends, direct distupgrade vs upgrade && dist-upgrade)
with the patched packages as upgrade targets. I've rerun all piuparts
tests that had libreoffice-common installed and haven't seen any more
problems with the patched packages.

The attached patch does only patch debian/control.in, please regenerate
debian/control as this caused a lot of noise (I did nocheck builds).
It also contains adding some weird symbols with symbol version GLIBCXX_3.4
that looks weird, because libreoffice should not provide symbols with
such a version. This could also be an artefact of how I did build the
packages. Please decide what should happen to them.

Andreas
diff -Nru libreoffice-7.0.4/debian/changelog libreoffice-7.0.4/debian/changelog
--- libreoffice-7.0.4/debian/changelog  2021-01-03 18:54:17.0 +0100
+++ libreoffice-7.0.4/debian/changelog  2021-04-07 09:42:18.0 +0200
@@ -1,3 +1,16 @@
+libreoffice (1:7.0.4-4) UNRELEASED; urgency=medium
+
+  * libreoffice-core: Copy some Conflicts from libreoffice-common for smoother
+upgrades from buster. Dpkg will otherwise ignore Conflicts that are
+encountered later against a package that is already deconfigured.
+  * libreoffice-common: Do not use dir_to_symlink for
+/usr/lib/libreoffice/share/registry, the Breaks/Conflicts cascade does not
+work reliable here to ensure all packages previously shipping files there
+are either removed or upgraded first, but not just deconfigured. Fix up
+the symlink in postinst instead.  (Closes: #985297)
+
+ -- Andreas Beckmann   Wed, 07 Apr 2021 09:42:18 +0200
+
 libreoffice (1:7.0.4-3) unstable; urgency=medium
 
   * debian/tests/control.in: *really* add libreoffice-writer dependency
diff -Nru libreoffice-7.0.4/debian/control.in 
libreoffice-7.0.4/debian/control.in
--- libreoffice-7.0.4/debian/control.in 2020-12-31 11:27:09.0 +0100
+++ libreoffice-7.0.4/debian/control.in 2021-04-07 09:42:18.0 +0200
@@ -236,6 +236,15 @@
 libreoffice-common (<< 1:5.4.1),
 libreoffice-avmedia-backend-gstreamer (<< ${binary:Version})
 Conflicts: libreoffice-filter-binfilter, libreoffice-avmedia-backend-vlc, 
libreoffice-mysql-connector (<< 1:6.2.0~), libreoffice-core-nogui
+# for bullseye, copied from libreoffice-common, see #985297
+ ,
+ libreoffice-base (<< 1:7.0.0~alpha~),
+ libreoffice-calc (<< 1:7.0.0~alpha~),
+ libreoffice-draw (<< 1:7.0.0~alpha~),
+ libreoffice-impress (<< 1:7.0.0~alpha~),
+ libreoffice-math (<< 1:7.0.0~alpha~),
+ libreoffice-report-builder (<< 1:7.0.0~alpha~),
+ libreoffice-writer (<< 1:7.0.0~alpha~),
 Replaces: libreoffice-pdfimport (<< 1:5.4~), libreoffice-common (<< 
1:6.3.0~rc1~), libreoffice-avmedia-backend-gstreamer, libreoffice-core-nogui
 Description: office productivity suite -- arch-dependent files
  LibreOffice is a full-featured office productivity suite that provides
diff -Nru libreoffice-7.0.4/debian/libreoffice-common.maintscript 
libreoffice-7.0.4/debian/libreoffice-common.maintscript
--- libreoffice-7.0.4/debian/libreoffice-common.maintscript 2020-12-31 
11:27:09.0 +0100
+++ libreoffice-7.0.4/debian/libreoffice-common.maintscript 2021-04-07 
09:42:18.0 +0200
@@ -2,4 +2,10 @@
 mv_conffile /etc/apparmor.d/usr.lib.libreofficeprogram.senddoc 
/etc/apparmor.d/usr.lib.libreoffice.program.senddoc 1:5.4.3-1
 mv_conffile /etc/apparmor.d/usr.lib.libreofficeprogram.soffice.bin 
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin 1:5.4.3-1
 mv_conffile /etc/apparmor.d/usr.lib.libreofficeprogram.xpdfimport 
/etc/apparmor.d/usr.lib.libreoffice.program.xpdfimport 1:5.4.3-1
-dir_to_symlink /usr/lib/libreoffice/share/registry /etc/libreoffice/registry 
1:7.0.2~rc1-1 
+
+# do this manually since dpkg-maintscript-helper dir_to_symlink
+# does not work reliably in this case because we cannot ensure that all
+# conflicting packages previously shipping files in
+# /usr/lib/libreoffice/share/registry are either upgraded or removed
+# but not just deconfigured, see #985297
+#dir_to_symlink 

Bug#987832: opendnssec: patch to build against mysql

[Mattia Rizzolo]

Source: opendnssec
Version: 1:2.1.7-1
Severity: minor

In Ubuntu this patch has been applied to allow building against a
default-libmysqlclient-dev that points against MySQL instead of MariaDB
as it's done in Debian.

diff -pruN 1:2.1.7-1/debian/patches/0016-mysql8_my_bool.patch 
1:2.1.7-1ubuntu1/debian/patches/0016-mysql8_my_bool.patch
--- 1:2.1.7-1/debian/patches/0016-mysql8_my_bool.patch  1970-01-01 
00:00:00.0 +
+++ 1:2.1.7-1ubuntu1/debian/patches/0016-mysql8_my_bool.patch   2020-02-14 
17:40:22.0 +
@@ -0,0 +1,17 @@
+Description: Reintroduce my_bool to fix build with MySQL 8
+Author: Andreas Hasenack 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1863026
+Forwarded: no
+Last-Update: 2020-02-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/enforcer/src/db/db_backend_mysql.c
 b/enforcer/src/db/db_backend_mysql.c
+@@ -33,6 +33,7 @@
+ #include "log.h"
+
+ #include 
++typedef bool my_bool;
+ #include 
+ #include 
+ #include 


Please consider applying this in Debian too, so that the package can be
built without extra changes in Ubuntu too.

Thank you in advance.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#987829: crazydiskinfo: FTBFS on mips due to mismatched struct member

[Yangfl]

Source: crazydiskinfo
Tags: patch
Severity: minor

Hi,

crazydiskinfo FTBFS on mips, because a struct `sigaction' is
initialized tag-less, while on mips the first member happens to be
different from that on other architectures.

Please consider applying this patch to fix this problem.
diff --git a/main.cpp b/main.cpp
index 7dcdf05..9172521 100644
--- a/main.cpp
+++ b/main.cpp
@@ -507,7 +507,8 @@ int main()
 	update();
 
 	{
-		struct sigaction s = {{actionWINCH}};
+		struct sigaction s = {0};
+		s.sa_handler = actionWINCH;
 		sigaction(SIGWINCH, , nullptr);
 	}
 

Bug#987828: unblock: openvswitch/2.15.0+ds1-3 (pre-approval)

[Thomas Goirand]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

In Experimental, We've added an openvswitch-source binary package, which
contains the sources of OpenVSwitch, that are needed in order to build
the OVN package that we're currently preparing.

I'd like to add this to Bullseye, to avoid backporting OpenVSwitch itself
when we will want to backport OVN to bullseye-backports.

Obviously, the change in the OpenVSwitch package itself is minimal, and
I cannot see why this would be a risk for anyone to upload it. But
it is clearly against the release team rules to add a binary package.
Which is why I'm asking for pre-approval.

What is the release team opinion? Should I upload openvswitch
2.15.0+ds1-3 to unstable with the new binary package?

Debdiff attached.

Cheers,

Thomas Goirand (zigo)
diff -Nru openvswitch-2.15.0+ds1/debian/changelog 
openvswitch-2.15.0+ds1/debian/changelog
--- openvswitch-2.15.0+ds1/debian/changelog 2021-02-20 21:58:03.0 
+0100
+++ openvswitch-2.15.0+ds1/debian/changelog 2021-03-01 22:15:45.0 
+0100
@@ -1,3 +1,10 @@
+openvswitch (2.15.0+ds1-3) experimental; urgency=medium
+
+  [ Amaury Séchet ]
+  * Add an openvswitch-source package, needed to build OVN.
+
+ -- Thomas Goirand   Mon, 01 Mar 2021 22:15:45 +0100
+
 openvswitch (2.15.0+ds1-2) unstable; urgency=medium
 
   * Mipsel64 and mipsel: blacklist more tests, as they are failing on these
diff -Nru openvswitch-2.15.0+ds1/debian/control 
openvswitch-2.15.0+ds1/debian/control
--- openvswitch-2.15.0+ds1/debian/control   2021-02-20 21:58:03.0 
+0100
+++ openvswitch-2.15.0+ds1/debian/control   2021-03-01 22:15:45.0 
+0100
@@ -163,6 +163,22 @@
  Open vSwitch switches and controllers, reducing the risk of
  man-in-the-middle attacks on the Open vSwitch network infrastructure.
 
+Package: openvswitch-source
+Architecture: all
+Depends:
+ ${misc:Depends},
+Description: Open vSwitch source code
+ Open vSwitch is a production quality, multilayer, software-based,
+ Ethernet virtual switch. It is designed to enable massive network
+ automation through programmatic extension, while still supporting
+ standard management interfaces and protocols (e.g. NetFlow, IPFIX,
+ sFlow, SPAN, RSPAN, CLI, LACP, 802.1ag). In addition, it is designed
+ to support distribution across multiple physical servers similar to
+ VMware's vNetwork distributed vswitch or Cisco's Nexus 1000V.
+ .
+ This package contains the full Open vSwitch source code to support
+ use with the Open Virtual Network (OVN) build.
+
 Package: openvswitch-switch
 Architecture: linux-any
 Depends:
diff -Nru openvswitch-2.15.0+ds1/debian/openvswitch-source.dirs 
openvswitch-2.15.0+ds1/debian/openvswitch-source.dirs
--- openvswitch-2.15.0+ds1/debian/openvswitch-source.dirs   1970-01-01 
01:00:00.0 +0100
+++ openvswitch-2.15.0+ds1/debian/openvswitch-source.dirs   2021-03-01 
22:15:45.0 +0100
@@ -0,0 +1 @@
+usr/src/openvswitch
diff -Nru openvswitch-2.15.0+ds1/debian/openvswitch-source.install 
openvswitch-2.15.0+ds1/debian/openvswitch-source.install
--- openvswitch-2.15.0+ds1/debian/openvswitch-source.install1970-01-01 
01:00:00.0 +0100
+++ openvswitch-2.15.0+ds1/debian/openvswitch-source.install2021-03-01 
22:15:45.0 +0100
@@ -0,0 +1 @@
+_debian/openvswitch.tar.gz /usr/src/openvswitch

Bug#987823: cinnamon: window decoration themes gone

[Christoph Anton Mitterer]

When manually setting /org/cinnamon/desktop/wm/preferences/theme to
"TraditionalOk" it works again... and the preview even shows up in the
Themes dialogue.. (but only as the current selected one,... I still
couldn't select it again).


Cheers,
Chris.

Bug#986907: dh-make-perl: use rt.cpan.org as default bugtracker for CPAN

[Andrius Merkys]

Hi,

On 2021-04-14 19:02, gregor herrmann wrote:
> On Wed, 14 Apr 2021 09:06:19 +0300, Andrius Merkys wrote:
> 
>> CPAN's default bugtracker is rt.cpan.org. Therefore, it would be nice to
>> have Bug-Database and Bug-Submit fields of debian/upstream/metadata
>> auto-filled in with appropriate default values for CPAN packages:
>>
>> Bug-Database: https://rt.cpan.org/Dist/Display.html?Name=$PKG
>> Bug-Submit: https://rt.cpan.org/Ticket/Create.html?Queue=$PKG
> 
> [$PKG -> $CPAN_Distribution]

Right, that's what I meant, thanks for correction.

> I'm not sure this makes sense. Here's my quick train of thought:
> 
> I know of 3 producers of debian/upstream/metadata: our own
> dh-make-perl and dpt-debian-pstream, plus lintian-brush (run manually
> or via the janitor). I think all of them do basically the same: Add
> Bug-* entries if this information is present in META.yml or
> META.json, plus some guesswork to add GitHub issues if there is no
> bugtracker information but a GutHub repo.
> 
> Then I know of one consumer of debian/upstream/metadata: dpt-forward,
> which already uses CPAN RT as a default value if it doesn't find a
> better info anywhere else (in META.* or debian/upstream/metadata).

UltimateDebianDatabase also seems to ingest debian/upstream/metadata to
its tables, but I haven't checked how they look there. Also I am not
aware of services using the UDD.

> I'm not opposed to adding "Bug-*: CPAN RT" to
> debian/upstream/metadata in both dpt-debian-upstream and dh-make-perl
> for cases where there is no explicit bugtracker in META.* and there
> is no upstream repo on GitHub; but the result at least for my use and
> the consumers I know would just be that dpt-forward does the same as
> it does now: use CPAN RT for forwarding bug reports/patches.
> 
> But it's of course possible that there are other consumers or other
> use cases where this would help.

I agree. Most likely this would not add much benefit.

Best,
Andrius

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Vincent Blut]

Le 2021-04-30 13:41, Salvatore Bonaccorso a écrit :
> Hi Vincent,
> 
> On Fri, Apr 30, 2021 at 12:43:22PM +0200, Vincent Blut wrote:
> > Le 2021-04-30 09:12, Bastian Germann a écrit :
> > > Am 29.04.21 um 20:13 schrieb Vincent Blut:
> > > > Running 'xrandr --verbose' from Xorg should give you the supported
> > > > HDCP Content Type. If that reports "HDCP Type1" then support for HDCP 
> > > > 2.2 is
> > > > enabled.
> > > 
> > > Works as expected. Enabling the two configs is sufficient.
> > 
> > Thanks for confirming.
> > 
> > Salvatore, how do you feel about enabling those kernel options for Bullseye?
> > Should I open a MR?
> 
> As it was verified to work and it adds important additional hardware
> support, then yes please.

Done.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/354

> I just find at this stage the part very important, we should try to
> enable additional HW support only if we have some verification that it
> adds value for the users, this is why I mentioned it last time.

Definitely agree!

> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987825: [Pkg-javascript-devel] Bug#987825: node-escope: unmaintained, replace it with its maintained fork eslint-scope

[Jonas Smedegaard]

Quoting Pirate Praveen (2021-04-30 14:16:45)
> Package: node-escope
> Severity: important
> Control: affects -1 node-eslint-plugin-eslint-plugin
> 
> node-escope upstream project is unmaintained and its only reverse 
> dependency node-eslint-plugin-eslint-plugin has updated its dependency 
> to a maintained fork of escope, ie, eslint-scope in its new major 
> release. So we should replace node-escope with eslint-scope, update 
> node-eslint-plugin-node-eslint-plugin to 3.x and remove node-escope.

Cood catch, Praveen!

node-eslint-plugin-eslint-plugin 2.3.0+~0.3.0-3 was just now released 
targeted Debian unstable, dropping the build-dependency on node-escope 
(by cherry-picking upstream change to move to eslint-escope).

When node-eslint-plugin-eslint-plugin 2.3.0+~0.3.0-3 reached Debian 
testing, node-escope should be possible to drop from Debian unstable.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#841044: Problem with gem network card

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Mon, Aug 27, 2018 at 12:14:58PM +0100, Mark Cave-Ayland wrote:
> On 27/08/18 10:39, Mathieu Malaterre wrote:
> 
> > Christian,
> > 
> > On Mon, Oct 17, 2016 at 9:32 AM Mathieu Malaterre  wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Oct 14, 2016 at 4:45 PM, Thadeu Lima de Souza Cascardo
> >>  wrote:
> >>> There is certainly a way to automate this, but my question on whether
> >>> that sequence would fix the problem was intended to more easily fix a
> >>> real bug in the driver.
> >>>
> >>> I can try to help fix the driver on my free time as a volunteer.
> >>> Christian, would you be willing to test patches to the driver? That
> >>> would require some back and forth between us and some patience of yours,
> >>> as I would be doing it on my spare time, considering I have family and
> >>> other projects I would like to attend to as well.
> >>>
> >>> I don't have a PPC Macbook of my own, but I used to fix Linux drivers on
> >>> PPC64 for a living not too long ago.
> >>
> >> That's a good news ! Feel free to use the bug report #841044 to send
> >> your patch (and/or updates).
> > 
> > Any update on the patch ?
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841044#30
> 
> FWIW QEMU now has sungem emulation which may help when trying to track
> down overflow errors such as this.

Is this bug still relevant/present or can the bug be closed by now?

Regards,
Salvatore

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupré]

On 2021-04-29 20:38:53, Nicholas D. Steeves wrote:
> Antoine Beaupré  writes:
>> On 2021-04-29 13:54:05, Nicholas D. Steeves wrote:
> [snip]
>>> These Emacs >= 27 changes also affect the point in emacs init where
>>> package-enable-at-startup can be set:
>>>
>>> If non-nil, packages are made available before reading the init file
>>> (but after reading the early init file).  This means that if you
>>> wish to set this variable, you must do so in the early init file.
>>>
>>> I think this bug is still valid and actionable even if removing
>>> package-initialize from the minimum reproducer, and/or after moving
>>> package-enable-at-startup to early-init.el makes the bug unreproducible.
>>> If nothing else, it seems like our src:emacs might need a NEWS entry on
>>> the topic, but that said, my suspicion is that lsp-mode could be more
>>> defensive.
>>
>> So what you're saying is that in Emacs >= 27, I don't need the
>> package-initialize anymore and that will fix my bug?
>>
>
> Yup, you don't need to manually call package-initialize anymore; also,
> please see the note about package-enable-at-startup, because that
> variable "must" now be set in the new early-init.el.  AFAICT These easy
> config changes are normal major version migration stuff, but I'm not
> sure if they'll be enough to solve your bug.  Definitely worth a shot
> though!

I still need to get to the office to confirm the fix, but this totally
makes sense. I have a very old Emacs configuration, which I've been
carrying for over two decades at this point. Cruft is bound to creep up
in there, and I'm actually surprised things still work in any meaningful
way. :)

I'm still kind of confused. What's the proper way to (say) setup package
repositories and then `use-package'?

In other words, what's the modern equivalent of this in my
`.emacs.d/init.el`?

(when (require 'package nil t)
  (setq-default
   load-prefer-newer t
   package-enable-at-startup nil)
  (when (< emacs-major-version 27)
(package-initialize))
  (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/;)
  ("melpa" . "https://melpa.org/packages/;)))
  ;; in elpa-use-package debian package since stretch
  (unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package)))

(eval-when-compile
  (require 'use-package)
  (setq-default
   use-package-always-defer nil
   use-package-always-ensure t))

Note that I added this `(when (< emacs-major-version 27)' blob to try to
workaround the bug. But now it seems that this packaging stuff might
belong to early-init.el? What if I want this config to still work in
Emacs 26?

Thanks for holding my hand through the new millenia. ;)

a.

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden

Bug#987827: unblock: node-opencv/7.0.0+git20200310.6c13234-1+b1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 987...@bugs.debian.org

Please unblock package node-opencv

[ Reason ]
node-opencv ReadImageAsync segfaults #987364

[ Impact ]
- Users will occasionally have segfaults using node-opencv.
- Build tests and autopkgtest sometimes fails on some architectures

[ Tests ]
Yes, autopkgtest fails (but not always).
Specifically examples/readimage.js fails when repeated several times on ppc64el.
Also I manually checked that:
- it fails ~ every five times before the patch
- it doesn't fail at all after the patch

[ Risks ]
Very low risk.
The patch copies a buffer and frees it afterwise.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock node-opencv/7.0.0+git20200310.6c13234-1+b1
diff -Nru node-opencv-7.0.0+git20200310.6c13234/debian/changelog 
node-opencv-7.0.0+git20200310.6c13234/debian/changelog
--- node-opencv-7.0.0+git20200310.6c13234/debian/changelog  2020-06-15 
14:58:13.0 +0200
+++ node-opencv-7.0.0+git20200310.6c13234/debian/changelog  2021-04-30 
14:18:17.0 +0200
@@ -1,3 +1,10 @@
+node-opencv (7.0.0+git20200310.6c13234-2) unstable; urgency=medium
+
+  * Fix OpenCV::ReadImageAsync segfault (Closes: #987364).
+Thanks to Jochen Sprickerhof.
+
+ -- Jérémy Lal   Fri, 30 Apr 2021 14:18:17 +0200
+
 node-opencv (7.0.0+git20200310.6c13234-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch 
node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch
--- node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch 
1970-01-01 01:00:00.0 +0100
+++ node-opencv-7.0.0+git20200310.6c13234/debian/patches/async_malloc.patch 
2021-04-30 14:06:38.0 +0200
@@ -0,0 +1,27 @@
+Description: avoid occasional crash in async call to opencv
+Author: Jochen Sprickerhof 
+Reviewed-By: Jérémy Lal 
+Last-Update: 2021-04-30
+Forwarded: https://github.com/peterbraden/node-opencv/pull/679
+--- a/src/OpenCV.cc
 b/src/OpenCV.cc
+@@ -37,6 +37,7 @@
+ cv::Mat mbuf(len, 1, CV_64FC1, buf);
+ outputmat = cv::imdecode(mbuf, flags);
+ success = 1;
++free(buf);
+   } catch(...){
+ success = 0;
+   }
+@@ -224,8 +225,10 @@
+ // async
+ uint8_t *buf = (uint8_t *) 
Buffer::Data(Nan::To(info[0]).ToLocalChecked());
+ unsigned len = 
Buffer::Length(Nan::To(info[0]).ToLocalChecked());
++uint8_t *buf_new = (uint8_t *)malloc(len);
++memcpy(buf_new, buf, len);
+ Nan::Callback *callback = new Nan::Callback(cb.As());
+-Nan::AsyncQueueWorker(new AsyncImDecodeWorker(callback, buf, len, 
flags));
++Nan::AsyncQueueWorker(new AsyncImDecodeWorker(callback, buf_new, len, 
flags));
+ return;
+   }
+   // WILL have returned by here unless exception
diff -Nru node-opencv-7.0.0+git20200310.6c13234/debian/patches/series 
node-opencv-7.0.0+git20200310.6c13234/debian/patches/series
--- node-opencv-7.0.0+git20200310.6c13234/debian/patches/series 2020-06-15 
14:58:13.0 +0200
+++ node-opencv-7.0.0+git20200310.6c13234/debian/patches/series 2021-04-30 
14:06:30.0 +0200
@@ -1 +1,2 @@
+async_malloc.patch
 0002_patch_unittest.patch

Bug#796882: hyperv-daemons: include debian specific versions of hv_get* scripts

[Salvatore Bonaccorso]

control: tags -1 + moreinfo

On Tue, Aug 25, 2015 at 02:27:46PM +0200, Christoph Martin wrote:
> Package: hyperv-daemons
> Version: 4.1.4-2~bpo8+1
> Severity: normal
> 
> hv_kvp_daemon gives the following errors:
> 
> hv_kvp_daemon[941]: sh: 1: hv_get_dns_info: not found
> hv_kvp_daemon[941]: sh: 1: hv_get_dhcp_info: not found
> hv_kvp_daemon[941]: sh: 1: hv_get_dns_info: not found
> hv_kvp_daemon[941]: sh: 1: hv_get_dhcp_info: not found
> 
> These scripts are missing from the package. 
> Debian should include there own disto specific versions of this scripts.
> 
> Examples are in the linux-tools source in the directory tools/hv/

This should have been resolved in 4.5.1-1, when we got own init and
systemd service units, is this correct?

Regards,
Salvatore

Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Tue, Aug 18, 2015 at 03:30:59PM +0200, Christoph Martin wrote:
> Package: src:linux
> Version: 3.16.7-ckt11-1+deb8u3~bpo70+1
> Severity: normal
> File: /boot/vmlinuz-3.16.0-0.bpo.4-amd64
> 
> The drc (duplicate request cache) for NFS 4.1 in the vanilla kernel
> has a fixed size only depending on the RAM of the machine.
> 
> For example, when setting up a vm which should only serve as a
> nfs referral server with 768 MB RAM it could only server about
> 20 clients. So it is roughly 32 clients per GB.
> 
> The problem is, that in nfssvc.c the size of drc is calculated with
> a shift of NFSD_DRC_SIZE_SHIFT bits from the RAM size.
> 
> I attach a patch for this which I also sent to linux-nfs.
> (See http://www.spinics.net/lists/linux-nfs/msg51791.html)
> 
> It implements a module variable to set the size on module load.
> 
> It hope that such a patch can make it into Debian soon.

is this problem still relevant?

Side note that we would anyway not apply a patch which would not have
been accepted upstream, likely unless there are very valid reasons.

Regards,
Salvatore

Bug#774896: Exynos4 CONFIG_HZ

[Salvatore Bonaccorso]

Hi,

On Mon, Jan 19, 2015 at 11:23:04AM +0100, Krzysztof Kozłowski wrote:
> 2015-01-18 17:57 GMT+01:00 Sten Spans :
> >
> > With the  improvements in upstream support for exynos4 devices
> > I've been looking into adding support odroid devices to Debian's
> > armmp kernel. The kernel config changes needed are quite minimal
> > as can be seen here:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774896
> >
> > Mostly enabling support and various modules.
> >
> > However as Ian Campbell notes, enabling ARCH_EXYNOS4 triggers
> > the following from arch/arm/Kconfig:
> > config HZ_FIXED
> > int
> > default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
> > ARCH_S5PV210 || ARCH_EXYNOS4
> > default AT91_TIMER_HZ if ARCH_AT91
> > default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
> > default 0
> >
> > This forces CONFIG_HZ=200 for the entire armmp kernel, which is
> > undesirable. The reason for this setting isn't very clear to either
> > me or Ian. I personally have verified that HZ=250 (the default for debian
> > armmp kernels) boots fine.
> >
> > Is there a particular reason for this setting?
> > Would a patch removing this requirement for ARCH_EXYNOS4 be accepted?
> 
> +Cc Kukjin Kim
> 
> I cannot find a valid reason for fixed 200 Hz, especially that other
> values (<100, 1000>) are working. Maybe Kukjin will share some light
> on this?

I'm not sure if this bugreport is still relevant, but in any case
upstream changed this in da6b21e97e39 ("ARM: Drop fixed 200 Hz timer
requirement from Samsung platforms").

In case the bugreport is not anymore relevant, let's close it.

Regards,
Salvatore

Bug#987826: dkms: recompiles the whole kernel

[Norbert Preining]

Package: dkms
Version: 2.8.4-4
Severity: normal
X-Debbugs-Cc: norb...@preining.info

Hi,

I usually build my own kernels from git, and then call make
modules_install and make install.

Debian's dkms seems to hook into this, and that worked quite well for
most modules (nvidia is an exception, it **never** works and needs to be
built automatically), but since a short time I see the following:

$ make install
sh ./arch/x86/boot/install.sh 5.12.0 arch/x86/boot/bzImage \
System.map "/boot"
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.12.0 
/boot/vmlinuz-5.12.0
run-parts: executing /etc/kernel/postinst.d/dkms 5.12.0 /boot/vmlinuz-5.12.0
dkms: running auto installation service for kernel 5.12.0:ACPI disabled in this 
kernel, not building module.
ACPI disabled in this kernel, not building module.
ACPI disabled in this kernel, not building module.
ACPI disabled in this kernel, not building module.
ACPI disabled in this kernel, not building module.
ACPI disabled in this kernel, not building module.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area.
make -j8 KERNELRELEASE=5.12.0 -C /lib/modules/5.12.0/build 
M=/var/lib/dkms/acpi-call/1.1.0/build.

and it rebuilds the **whole** kernel ... again and again.
I have built the kernel before completely, the very same minute.

This is definitely new and a very disturbing and painful behaviour, that
actually doesn't result in anything useful.

Best

Norbert

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.12.0 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dkms depends on:
ii  build-essential12.9
ii  clang-11 [c-compiler]  1:11.0.1-2
ii  clang-9 [c-compiler]   1:9.0.1-16
ii  coreutils  8.32-4+b1
ii  dctrl-tools2.24-3+b1
ii  dpkg-dev   1.20.9
ii  gcc [c-compiler]   4:10.2.1-1
ii  gcc-10 [c-compiler]10.2.1-6
ii  gcc-9 [c-compiler] 9.3.0-22
ii  kmod   28-1
ii  lsb-release11.1.0
ii  make   4.3-4.1
ii  patch  2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.25.3-1.1
pn  linux-headers-686-pae | linux-headers-amd64 | linux-headers-gen  
ii  sudo 1.9.5p2-3

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.2-1
ii  menu   2.1.48

-- no debconf information



-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.12.0 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dkms depends on:
ii  build-essential12.9
ii  clang-11 [c-compiler]  1:11.0.1-2
ii  clang-9 [c-compiler]   1:9.0.1-16
ii  coreutils  8.32-4+b1
ii  dctrl-tools2.24-3+b1
ii  dpkg-dev   1.20.9
ii  gcc [c-compiler]   4:10.2.1-1
ii  gcc-10 [c-compiler]10.2.1-6
ii  gcc-9 [c-compiler] 9.3.0-22
ii  kmod   28-1
ii  lsb-release11.1.0
ii  make   4.3-4.1
ii  patch  2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.25.3-1.1
pn  linux-headers-686-pae | linux-headers-amd64 | linux-headers-gen  
ii  sudo 1.9.5p2-3

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.2-1
ii  menu   2.1.48

-- no debconf information