Bug#989242: please write your own logfile

[Harald Dunkel]

Package: logrotate
Version: 3.18.1-1
Severity: wishlist

Would you mind to enable logrotate logging for Bookworm by default?
logrotate appears to be excellent in logging. Its a shame that this
is not used. And since you have to wait 24h for the next run (unless
you enable hourly rotation) it is even more painful to have no log
when you need it.

This would be very helpful to catch unwanted config files in logrotate.d,
not caught by tabooext, for example.


--- /lib/systemd/system/logrotate.service   2020-08-21 15:02:38.0 
+0200
+++ /etc/systemd/system/logrotate.service   2021-05-30 06:48:42.743903674 
+0200
@@ -6,7 +6,7 @@

 [Service]
 Type=oneshot
-ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
+ExecStart=/usr/sbin/logrotate -l /var/log/logrotate.log /etc/logrotate.conf

 # performance options
 Nice=19


The cron script should be modified accordingly (not shown here).


Thanx in advance

Harri

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

And the same thing happened again today, with the ati card this time! I logged
in via ssh and, like with nvidia and nouveaum radeon was not found in lsmod. I
then checked lspci and the entire vga part was not there, as if a gpu was not
even connected!
What the fuck was on this update that fucked my only pcie-x slot that bad?
Since I get no replies and so far I have been troubleshooting it on my own, I
decided to move to arch by the end of the week, provided that one of the cards
still works.
Thanks for nothing, I will surely leave a bad review on distrowatch for the
rest of the people to see.

p.s. I had to borrow an fresh (yet old) nvidia card in order to make my system
boot again and right now I am using it with nouveau, which is godawful btw.

Bug#988983: unblock: golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4

[Shengjing Zhu]

Hi,

On Sat, May 22, 2021 at 10:21 PM Shengjing Zhu  wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: z...@debian.org
>
> Please unblock package golang-golang-x-net
>
> [ Reason ]
> Backport patch for CVE-2021-33194
> x/net/html: infinite loop in ParseFragment
>
> [ Impact ]
> It fixes security issues.
>
> [ Tests ]
> Upstream has added a unit test for the issue in the patch.
>
> [ Risks ]
> + Diff is small
> + Key package
>
> [ 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 ]
> Need rebuild packages which have built-using with old version of
> golang-golang-x-net
>
> unblock golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4

Ping?

-- 
Shengjing Zhu

Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)

[Daniel Serpell]

Package: src:linux
Version: 5.10.40-1
Followup-For: Bug #966218

Dear maintainer,

This bug is still present in current linux version (5.10.40-1).

This is the extract from kernel logs, shown in red with dmesg and journalctl:

[4.029767] Intel(R) Wireless WiFi driver for Linux
[4.031188] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[4.033427] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-QuZ-a0-hr-b0-59.ucode
[4.033437] iwlwifi :00:14.3: api flags index 2 larger than supported by 
driver
[4.033449] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 
65.3.35.22
[4.033702] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 
QuZ-a0-hr-b0-59.ucode op_mode iwlmvm
[4.033719] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[4.033726] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[4.035880] i915 :00:02.0: firmware: direct-loading firmware 
i915/kbl_dmc_ver1_04.bin
[4.036287] i915 :00:02.0: [drm] Finished loading DMC firmware 
i915/kbl_dmc_ver1_04.bin (v1.4)
[4.037965] uvcvideo: Found UVC 1.00 device HD WebCam (04f2:b5c5)


Regards,


-- System Information:
Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)

Bug#984581: RE: Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

[Paul Wise]

On Mon, 5 Apr 2021 06:04:49 + "Surla, Sai Kalyan" wrote:

> Is there any update on the issues.

I finally found time to work on the first issue (header detection)
where we had a workaround already and created proper patches (attached)
for the issue and sent them to the upstream maintainer.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From a4aa24ae5675b09385d0c88add48c3ab046e699d Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Sun, 30 May 2021 10:02:14 +0800
Subject: [PATCH 1/3] Add debugging for header detection

---
 src/readpst.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/readpst.c b/src/readpst.c
index 6d94f15..b5910e9 100644
--- a/src/readpst.c
+++ b/src/readpst.c
@@ -1591,6 +1591,8 @@ void write_normal_email(FILE* f_output, char f_name[], pst_item* item, int mode,
 DEBUG_ENT("write_normal_email");
 
 pst_convert_utf8_null(item, >email->header);
+DEBUG_INFO(("PST headers\n%s\n", *item->email->header.str));
+DEBUG_INFO(("Extra MIME headers\n%s\n", *extra_mime_headers));
 headers = valid_headers(item->email->header.str) ? item->email->header.str :
   valid_headers(*extra_mime_headers) ? *extra_mime_headers :
   NULL;
-- 
2.30.2

From bade93dcdb435bc7bec50cf4b54481731beea45c Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Sun, 30 May 2021 09:49:57 +0800
Subject: [PATCH 2/3] Also detect email headers wrapped with space instead of
 tab

Spaces are commonly used for email header wrapping.
---
 src/readpst.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/readpst.c b/src/readpst.c
index b5910e9..6663771 100644
--- a/src/readpst.c
+++ b/src/readpst.c
@@ -1275,8 +1275,10 @@ int  header_match(char *header, char*field) {
 if (strncasecmp(header, field, n) == 0) return 1;   // tag:{space}
 if ((field[n-1] == ' ') && (strncasecmp(header, field, n-1) == 0)) {
 char *crlftab = "\r\n\t";
+char *crlfspc = "\r\n ";
 DEBUG_INFO(("Possible wrapped header = %s\n", header));
 if (strncasecmp(header+n-1, crlftab, 3) == 0) return 1; // tag:{cr}{lf}{tab}
+if (strncasecmp(header+n-1, crlfspc, 3) == 0) return 1; // tag:{cr}{lf}{space}
 }
 return 0;
 }
-- 
2.30.2

From da5f159caa66db380b793f9062a36888c9b12467 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Sun, 30 May 2021 09:51:26 +0800
Subject: [PATCH 3/3] Detect reasonable email headers too

RFC 5322 specifies the syntax of email headers, most header fields are more
restricted though so use a restricted check in case the headers are bogus
parts of the body that happen to match RFC 5322.

Fixes: https://bugs.debian.org/984581
---
 src/readpst.c | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/src/readpst.c b/src/readpst.c
index 6663771..97ba127 100644
--- a/src/readpst.c
+++ b/src/readpst.c
@@ -1283,6 +1283,65 @@ int  header_match(char *header, char*field) {
 return 0;
 }
 
+// https://en.wikipedia.org/wiki/Email#Message_header
+// https://www.rfc-editor.org/rfc/rfc5322.html
+// https://www.iana.org/assignments/message-headers/message-headers.xhtml
+int  header_is_reasonable(char *header)
+{
+char *c;
+#define C *c
+
+// The header must not be NULL
+if (header) c = header;
+else return 0;
+
+// usually the header field name starts with upper-case: A-Z
+if (C >= 'A' && C <= 'Z') c++;
+else return 0;
+
+while(1) {
+// most header field names use a limited set of characters: - 0-9 A-Z a-z
+if (
+(C >= 'A' && C <= 'Z') ||
+(C >= 'a' && C <= 'z') ||
+(C >= '0' && C <= '9') ||
+(C == '-')
+   ) {
+c++;
+// the header field name is then terminated with a colon
+} else if (C == ':') {
+  c++;
+  goto parse_header_field_value;
+// other characters are an indicator of an invalid header
+} else {
+  return 0;
+}
+}
+
+parse_header_field_value:
+while(1) {
+// header field values are printable US-ASCII plus space/tab
+if (
+(C >= 33 && C <= 126) ||
+(C == ' ' || C == '\t')
+   ) {
+c++;
+// the header field value is then terminated with CRLF
+} else if (C == '\r' && *(c+1) == '\n') {
+c += 2;
+// the value could continue to the next line though
+if (C == ' ' || C == '\t') c++;
+else return 1;
+// other characters are an indicator of an invalid header
+} else {
+  return 0;
+}
+}
+
+#undef C
+
+}
+
 int  valid_headers(char *header)
 {
 // headers are sometimes really bogus - they seem to be fragments of the
@@ -1303,6 +1362,7 @@ int  valid_headers(char *header)
 if (header_match(header, "X-ASG-Debug-ID: "   )) return 1;
 if (header_match(header, "X-Barracuda-URL: "  )) return 1;
 if 

Bug#989240: lxqt-session automatically runs at system startup regardless of chosen desktop environment

[FPacifica]

Package: lxqt-session
Version: 0.16.0-1
Severity: normal

Dear Maintainer,

After a recent upgrade from Buster -> Bullseye I was experiencing issues
KDE Plasma: It took an extremely long time for the login process and
opening a new session to complete, and running sessions lacked window
controls because kwin_x11 was not running.  Eventually the Plasma
session would crash and freeze.

I noticed by checking running processes on the system that multiple
lxqt-* processes were running.  I eventually traced these to
/etc/xdg/autostart.  Not sure how or why all the lxqt-* entries were
there but I removed them.

However even after removing them lxqt-session was still automatically
starting after system boot, causing problems for KDE Plasma.

Eventually I just apt purged lxqt-session.

I have no insight into why this was happening but it was a fairly severe
issue that prevented me from using KDE.



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

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

Versions of packages lxqt-session depends on:
ii  libc6   2.31-12
ii  libkf5windowsystem5 5.78.0-2
ii  liblxqt00.16.0-1
ii  libqt5core5a5.15.2+dfsg-5
ii  libqt5dbus5 5.15.2+dfsg-5
ii  libqt5gui5  5.15.2+dfsg-5
ii  libqt5widgets5  5.15.2+dfsg-5
ii  libqt5x11extras55.15.2-2
ii  libqt5xdg3  3.6.0-1
ii  libstdc++6  10.2.1-6
ii  libudev1247.3-5
ii  libx11-62:1.7.1-1
ii  lxqt-qtplugin   0.16.0-1
ii  lxqt-theme-debian [lxqt-theme]  0.14.0.3
ii  lxqt-themes [lxqt-theme]0.16.0-1
ii  x11-xkb-utils   7.7+5

Versions of packages lxqt-session recommends:
ii  lxqt-config   0.16.1-1
ii  lxqt-notificationd0.16.0-1
ii  lxqt-policykit0.16.0-1
ii  lxqt-powermanagement  0.16.0-1
ii  lxqt-session-l10n 0.16.0-1
ii  lxqt-sudo 0.16.0-1
ii  pcmanfm-qt0.16.0-1
ii  qlipper   1:5.1.2-1+b1
ii  qps   2.2.0-1
ii  xscreensaver  5.45+dfsg1-1

lxqt-session suggests no packages.

-- no debconf information

Bug#989239: dash: support $'…' style quotes

[Christoph Anton Mitterer]

Package: dash
Version: 0.5.11+git20210120+802ebd4-1
Severity: wishlist


Hi.

It would be nice if dash could support $'…' style strings as bash does.

This also seem to be sooner or later going to be part of POSIX:
https://austingroupbugs.net/view.php?id=249#c599

Cheers,
Chris.

Bug#824417: gnome-terminal: Does not show up in menu(s) in LXDE. Last line of file /usr/share/applications/org.gnome.Terminal.desktop specifies "OnlyShowIn=GNOME; Unity; " Please add LXDE as well.

[Lisandro Damián Nicanor Pérez Meyer]

Hi! With my Qt/KDE maintainer hat here.

On Sun, 15 May 2016 11:59:47 -0700 Lubo Diakov  wrote:
> > LXDE is dead upstream (has been replaced by LXQt). So I'm not convinced
> > it makes sense to add this for LXDE now.

Actually today we had a user wanting to launch gnome-terminal from
Plasma and wasn't able due to this patch.

[snip]
> > I wonder if it would make sense to drop
> > debian/patches/01_onlyshowin.patch completely.
> >
> > This patch was added as other desktop environments usually install their
> > own preferred terminal, in case of lxde this is lxterminal.

But users should still be able to run the applications they want using
their desktop launcher. So that patch is indeed causing a bug.

> Yes, please. Having every program that is technically compatible show
> up without jumping through unneeded hoops. Anyone who installs 2 or
> more should be tech. savvy enough to know why he/she did it, i.e. the
> other one has a feature they need.
> >
> > Having multiple terminals in the menu could be confusing.
>
> Only to rank beginners, and that can be mitigated somewhat by clear
> concise explanations/titles in the menu and hints. E.g. if instead of
> calling itself "Terminal" as if there is only one (echoes of
> Highlander in my head) it would specify "gnome terminal, a terminal
> emulator for X11 implemented by gnome, with perhaps the upstream URL
> for FAQs, if needed"

I agree with this.

Bug#989238: gnome-terminal: .desktop entry for gnome-terminal OnlyShowIn=GNOME;Unity prevents app from being listed

[FPacifica]

Package: gnome-terminal
Version: 3.38.3-1
Severity: normal

Dear Maintainer,

The line:

OnlyShowIn=GNOME;Unity;

in /usr/share/applications/org.gnome.Terminal.desktop

prevents Gnome Terminal from being listed in KDE.

Solution was to copy /usr/share/applications/org.gnome.Terminal.desktop
to ~/.local/share/applications and remove the line.





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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  gnome-terminal-data   3.38.3-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-12
ii  libdconf1 0.38.0-2
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libpango-1.0-01.46.2-3
ii  libuuid1  2.36.1-7
ii  libvte-2.91-0 0.62.3-1
ii  libx11-6  2:1.7.1-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.46.2-1
pn  nautilus-extension-gnome-terminal  
pn  yelp   

gnome-terminal suggests no packages.

-- no debconf information

Bug#989235: p11-kit FTBFS on hurd-any

[Jeffrey Walton]

On Sat, May 29, 2021 at 5:00 PM Helmut Grohne  wrote:
> ...
> p11-kit fails to build from source on hurd-any. The immediate reason is
> an undefined macro SIZE_MAX in p11-kit/lists.c. It happens that this
> file fails to #include , which is generally required for
> SIZE_MAX. I'm attaching a patch for this.

There are different philosophies about SIZE_MAX. The one that wins on
Hurd is, SIZE_MAX is a vulnerability.

Also see https://lists.debian.org/debian-hurd/2021/04/msg00045.html.

Jeff

Bug#976070: issues fixed

[Sylvain Archenault]

Actually my issue seems different, i think it was this issue in
network-manager:
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/64.

This has been fixed in 1.8.14-1 currently in experimental.

Bug#987081: unblock: puppet-module-puppetlabs-haproxy/2.1.0-3

[Sebastian Ramacher]

Control: clone -1 -2
Control: reassign -2 puppet-module-puppetlabs-haproxy 2.1.0-2
Control: retitle -2 puppet-module-puppetlabs-haproxy: clean up 
update-alternatives handling
Control: severity -2 important
Control: tags -2 =

On 2021-05-28 23:49:40 +0200, Thomas Goirand wrote:
> Hi,
> 
> Sorry, I missed your reply. Thanks for the ping.
> 
> Sebastian must be right, but then that's a different issue than the one
> that I'm trying to fix. Maybe a bug (of IMO severity "important") should
> be filled against this package.

Done

Cheers

> Though then probably also against all
> other Puppet packages I maintain, which makes it a mass bug filling,
> which may not be appropriate. IMO it may be best to just fix this after
> the release.
> 
> Also, there's currently no other puppet-module-*-haproxy available in
> Debian right now, so even if Sebastian, this has no consequence.
> 
> Anyways, please still unblock this fix, which is IMO a way more annoying
> than just removing the alternatives on removal/disappear.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> On 5/27/21 9:26 PM, Paul Gevers wrote:
> > Hi Thomas,
> > 
> > Ping.
> > 
> > Paul
> > Note: without reply, we'll close the bug without action
> > 
> > On 20-04-2021 11:03, Sebastian Ramacher wrote:
> >> Control: tags -1 moreinfo
> >>
> >> On 2021-04-17 12:02:44 +0200, Thomas Goirand wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: unblock
> >>>
> >>> Please unblock package puppet-module-puppetlabs-haproxy
> >>>
> >>> This fixes a minor issue in the prerm when removing
> >>> alternatives (ie: wrong path when removing the alternative).
> >>
> >> Why is update-alternatives run on upgrade and deconfigure in prerm? From
> >> update-alternatives' manpage:
> >>
> >> update-alternatives is usually called from the following Debian package
> >> maintainer scripts, postinst (configure) to install the alternative and
> >> from prerm and postrm (remove) to remove the alternative. Note: in most
> >> (if not all) cases no other maintainer script actions should call
> >> update-alternatives, in particular neither of upgrade nor disappear, as
> >> any other such action can lose the manual state of an alternative, or
> >> make the alternative temporarily flip-flop, or completely switch when
> >> several of them have the same priority.
> >>
> >>
> >> Cheers
> >>
> >>
> >>>
> >>> (very) small debdiff attached.
> >>>
> >>> Please unblock puppet-module-puppetlabs-haproxy/2.1.0-3.
> >>>
> >>> Cheers,
> >>>
> >>> Thomas Goirand (zigo)
> >>
> >>> diff -Nru puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog 
> >>> puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog
> >>> --- puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog   
> >>> 2020-03-24 
> > 11:21:33.0 +0100
> >>> +++ puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog   
> >>> 2021-04-17 
> > 11:58:30.0 +0200
> >>> @@ -1,3 +1,9 @@
> >>> +puppet-module-puppetlabs-haproxy (2.1.0-3) unstable; urgency=medium
> >>> +
> >>> +  * Fix update-alternatives --remove in prerm.
> >>> +
> >>> + -- Thomas Goirand   Sat, 17 Apr 2021 11:58:30 +0200
> >>> +
> >>>  puppet-module-puppetlabs-haproxy (2.1.0-2) unstable; urgency=medium
> >>>  
> >>>[ Ondřej Nový ]
> >>> diff -Nru 
> >>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
> >>>  
> >>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
> >>> --- 
> >>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
> >>>   2020-03-24 11:21:33.0 +0100
> >>> +++ 
> >>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
> >>>   2021-04-17 11:58:30.0 +0200
> >>> @@ -3,7 +3,7 @@
> >>>  set -e
> >>>  
> >>>  if [ "${1}" = "remove" ] || [ "${1}" = "upgrade" ] || [ "${1}" = 
> > "deconfigure" ] ; then
> >>> - update-alternatives --remove puppet-module-haproxy 
> >>> /usr/share/puppet/modules.available/puppet-module-puppetlabs-haproxy
> >>> + update-alternatives --remove puppet-module-haproxy 
> >>> /usr/share/puppet/modules.available/puppetlabs-haproxy
> >>>  fi
> >>>  
> >>>  #DEBHELPER#
> >>
> >>
> > 
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988578: unblock: dmidecode/3.3-2

[Sebastian Ramacher]

Control: tags -1 d-i

On 2021-05-27 10:33:51 +0200, Jörg Frings-Fürst wrote:
> tags 988578 - moreinfo
> thanks
> 
> Hello Sebastian,
> 
> dmidecode is now in unstable.

Cyril, can you please (n)ack for d-i? Final debdiff is below:

diff -Nru dmidecode-3.3/debian/changelog dmidecode-3.3/debian/changelog
--- dmidecode-3.3/debian/changelog  2020-10-17 10:31:23.0 +0200
+++ dmidecode-3.3/debian/changelog  2021-05-17 18:53:43.0 +0200
@@ -1,3 +1,14 @@
+dmidecode (3.3-2) unstable; urgency=medium
+
+  * Add upstream recommended patches (Closes: #987033):
+- New debian/patches/0145-Fix_condition_error_in_ascii_filter.patch.
+- New debian/patches/0150-Fix_crash.patch.
+  * Declare compliance with Debian Policy 4.5.1 (No changes needed).
+  * debian/copyright:
+- Add year 2021 to myself.
+
+ -- Jörg Frings-Fürst   Mon, 17 May 2021 18:53:43 +0200
+
 dmidecode (3.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru dmidecode-3.3/debian/control dmidecode-3.3/debian/control
--- dmidecode-3.3/debian/control2020-10-17 09:58:18.0 +0200
+++ dmidecode-3.3/debian/control2021-05-07 08:54:34.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Jörg Frings-Fürst 
 Build-Depends: debhelper-compat (= 13)
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Vcs-Git: git://jff.email/opt/git/dmidecode.git
 Vcs-Browser: https://jff.email/cgit/dmidecode.git/
diff -Nru dmidecode-3.3/debian/copyright dmidecode-3.3/debian/copyright
--- dmidecode-3.3/debian/copyright  2020-10-17 10:14:51.0 +0200
+++ dmidecode-3.3/debian/copyright  2021-05-07 08:56:16.0 +0200
@@ -13,7 +13,7 @@
 Files: debian/*
 Copyright: 2003-2007 Petter Reinholdtsen 
2011-2012 Daniel Baumann 
-   2014-2020 Jörg Frings-Fürst 
+   2014-2021 Jörg Frings-Fürst 
 License: GPL-2+
 
 License: GPL-2+
diff -Nru 
dmidecode-3.3/debian/patches/0145-Fix_condition_error_in_ascii_filter.patch 
dmidecode-3.3/debian/patches/0145-Fix_condition_error_in_ascii_filter.patch
--- dmidecode-3.3/debian/patches/0145-Fix_condition_error_in_ascii_filter.patch 
1970-01-01 01:00:00.0 +0100
+++ dmidecode-3.3/debian/patches/0145-Fix_condition_error_in_ascii_filter.patch 
2021-05-07 08:41:39.0 +0200
@@ -0,0 +1,18 @@
+Description: Fix the condition error in ascii_filter
+Origin: upstream, 
http://git.savannah.gnu.org/cgit/dmidecode.git/commit/?id=1117390ccd9cea139638db6f460bb6de70e28f94
+Last-Update: 2021-05-07
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: trunk/dmidecode.c
+===
+--- trunk.orig/dmidecode.c
 trunk/dmidecode.c
+@@ -116,7 +116,7 @@ static void ascii_filter(char *bp, size_
+   size_t i;
+ 
+   for (i = 0; i < len; i++)
+-  if (bp[i] < 32 || bp[i] == 127)
++  if (bp[i] < 32 || bp[i] >= 127)
+   bp[i] = '.';
+ }
+ 
diff -Nru dmidecode-3.3/debian/patches/0150-Fix_crash.patch 
dmidecode-3.3/debian/patches/0150-Fix_crash.patch
--- dmidecode-3.3/debian/patches/0150-Fix_crash.patch   1970-01-01 
01:00:00.0 +0100
+++ dmidecode-3.3/debian/patches/0150-Fix_crash.patch   2021-05-07 
08:44:07.0 +0200
@@ -0,0 +1,21 @@
+Description: Fix crash with -u option
+Origin: upstream, 
http://git.savannah.gnu.org/cgit/dmidecode.git/commit/?id=11e134e54d15e67a64c39a623f492a28df922517
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987033
+Last-Update: 2021-05-07
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: trunk/dmidecode.c
+===
+--- trunk.orig/dmidecode.c
 trunk/dmidecode.c
+@@ -248,9 +248,9 @@ static void dmi_dump(const struct dmi_he
+   {
+   int j, l = strlen(s) + 1;
+ 
+-  off = 0;
+   for (row = 0; row < ((l - 1) >> 4) + 1; row++)
+   {
++  off = 0;
+   for (j = 0; j < 16 && j < l - (row << 
4); j++)
+   off += sprintf(raw_data + off,
+  j ? " %02X" : "%02X",
diff -Nru dmidecode-3.3/debian/patches/series 
dmidecode-3.3/debian/patches/series
--- dmidecode-3.3/debian/patches/series 2020-10-17 09:39:24.0 +0200
+++ dmidecode-3.3/debian/patches/series 2021-05-17 18:49:01.0 +0200
@@ -1,3 +1,5 @@
+0145-Fix_condition_error_in_ascii_filter.patch
+0150-Fix_crash.patch
 0100-ansi-c.patch
 0001-hurd.patch
 #0005-build.patch


Cheers

> 
> CU
> Jörg
> 
> 
> Am Mittwoch, dem 19.05.2021 um 20:28 +0200 schrieb Sebastian Ramacher:
> > Control: tags -1 moreinfo confirmed
> > 
> > On 2021-05-17 19:04:20 +0200, Jörg Frings-Fürst wrote:
> > > Control: tags 

Bug#969954: giblib1: error saving screenshot scrot

[Adrian Bunk]

Control: retitile -1 giblib1 should give better error message when target 
directory does not exist
Control: severity -1 minor

On Wed, Sep 09, 2020 at 11:15:42AM +0200, Nicola wrote:
> Package: giblib1
> Version: 1.2.4-12
> Severity: important
> 
> Dear Maintainer,
> 
> scrot can't save screenshot
> 
> nicola@lenovo:~$ scrot -c ~/screenshot/test.png
> giblib error: Saving to file /home/nicola/screenshot/test.png failed
>...

I can reproduce this when the target directory ~/screenshot does not 
exist, and "mkdir ~/screenshot" fixes it.

The error message could print "No such file or directory" to make it clearer.

cu
Adrian

Bug#988618: Acknowledgement (unblock: kodi-pvr-iptvsimple/7.6.5+ds1-1)

[Sebastian Ramacher]

On 2021-05-18 08:34:01 +, Vasyl Gello wrote:
> Useful fixes and improvements in this version:
> 
> * Fix parsing of tvg-rec M3U tags
> * Fix crash if remote XMLTV data is compressed with XZ
> * Allow sub-channels

The new version also introduces some new features and is not a targeted
bug fix release. Please cherry pick the fixes if you deem them
important.

Cheers

> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989222: [Pkg-phototools-devel] Bug#989222: Bug#989222: darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files

[Adrian Bunk]

On Sat, May 29, 2021 at 07:45:04PM +0200, Jonas Smedegaard wrote:
>...
> Seems to me that upstream talked about dropping that SSE code causing an 
> acceptable 20% slowdown of that routine.
>...

Upstream says the SSE code was 20% slower, so this improves performance.

>  - Jonas

cu
Adrian

Bug#989236: crossgrader: crashes with "Could not mark python3-apt:amd64 for install, fixing manually."

[Adam Borowski]

Package: crossgrader
Version: 0.0.3+nmu2
Severity: important

Hi!
While trying to crossgrade a system, I got the following crash:

Could not mark python3-apt:amd64 for install, fixing manually.
Traceback (most recent call last):
  File "/usr/bin/crossgrader", line 33, in 
sys.exit(load_entry_point('debian-crossgrader==0.0.3', 'console_scripts', 
'crossgrader')())
  File "/usr/lib/python3/dist-packages/debian_crossgrader/__main__.py", line 
262, in main
first_stage(args)
  File "/usr/lib/python3/dist-packages/debian_crossgrader/__main__.py", line 
60, in first_stage
crossgrader.cache_package_debs(pkg_packages)
  File "/usr/lib/python3/dist-packages/debian_crossgrader/crossgrader.py", line 
581, in cache_package_debs
assert target.marked_install, \
AssertionError: python3-apt:amd64 not marked as install despite no auto_inst

As python3-apt is a dependency of crossgrader itself, I can't remove it to
let crossgrader continue.

Before the crash, the output so far was:

# crossgrader amd64
Installing initramfs binary architecture check hook...
arch check hook already installed.
Hook installation failed.
Hit http://apt-stg.angband.pl:3142/debian bullseye InRelease
 
Hit http://apt-stg.angband.pl:3142/debian bullseye-updates InRelease
 
Hit http://angband.pl/debian sid InRelease  
 
Hit http://apt-stg.angband.pl:3142/security.debian.org bullseye-security 
InRelease   
Hit http://deb.debian.org/debian bullseye-backports InRelease   
 
Fetched 0 B in 0s (0 B/s)   
 
48 targets found.
apt-utils:amd64
apt:amd64
base-files:amd64
base-passwd:amd64
bash:amd64
bsdutils:amd64
coreutils:amd64
cpio:amd64
cron:amd64
dash:amd64
debianutils:amd64
diffutils:amd64
dpkg:amd64
e2fsprogs:amd64
findutils:amd64
gcc-10-base:amd64
gpgv:amd64
grep:amd64
gzip:amd64
hostname:amd64
init:amd64
iproute2:amd64
iputils-ping:amd64
klibc-utils:amd64
kmod:amd64
less:amd64
libc-bin:amd64
libpam-modules-bin:amd64
libpam-modules:amd64
libreadline8:amd64
login:amd64
logrotate:amd64
mawk:amd64
mount:amd64
ncurses-bin:amd64
passwd:amd64
perl-base:amd64
procps:amd64
python3-apt:amd64
python3:amd64
rsyslog:amd64
screen:amd64
sed:amd64
sudo:amd64
sysvinit-utils:amd64
tar:amd64
udev:amd64
util-linux:amd64
Do you want to continue [y/N]? y


Meow!
-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (400, 'testing')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages crossgrader depends on:
ii  arch-test  0.17-1
ii  dpkg-dev   1.20.9
ii  initramfs-tools0.140
ii  python33.9.2-3
ii  python3-appdirs1.4.4-1
ii  python3-apt2.2.0
ii  python3-pkg-resources  52.0.0-3

crossgrader recommends no packages.

Versions of packages crossgrader suggests:
pn  qemu-user-static  

-- no debconf information

Bug#981083: protobuf: support build profiles

[Helmut Grohne]

Control: tags -1 - moreinfo

Hi GCS,

On Sat, May 29, 2021 at 05:32:59PM +0200, László Böszörményi (GCS) wrote:
>  Might you have some time to check if I correctly forward ported your
> patch [1] to the new protobuf release?

Sure.

* Given that you depend on dh-sequence-python3 now, I think you can drop
  the dh-python dependency.

* The dh-sequence-python3 dependency also means
  that you can drop --with python3, which simplifies your d/rules.

* The conditional CXX assignment can be replaced with:
  include /usr/share/dpkg/buildtools.mk

* dh_auto_configure -- --host=... seems suboptimal to me as more flags
  depend on the architecture. I recommend using this variant:
  dpkg-architecture -f -a$(DEB_BUILD_ARCH) -c dh_auto_configure

* There is now is an alternative to profile conditionals. Instead of
  ifneq (,$(filter someprofile,$(DEB_BUILD_PROFILES)))
  you may write:
  ifneq (,$(filter somepackage,$(shell dh_listpackages)))
  The latter makes the steps conditional to the relevant binary
  packages, which can be inhibited by either build profiles or by doing
  an arch-only/indep-only build. Neither is inherently wrong. I'm just
  giving an alternative.

All of the items above are nitpicks. None undermines the usability of
the implementation. Use the ones that make sense to you and ignore the
others.

Helmut

Bug#989235: p11-kit FTBFS on hurd-any

[Helmut Grohne]

Source: p11-kit
Version: 0.23.22-1
User: helm...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian-h...@lists.debian.org

p11-kit fails to build from source on hurd-any. The immediate reason is
an undefined macro SIZE_MAX in p11-kit/lists.c. It happens that this
file fails to #include , which is generally required for
SIZE_MAX. I'm attaching a patch for this.

Unfortunately, this does not entirely fix p11-kit. Beyond this issue,
one runs into this #error at:
https://sources.debian.org/src/p11-kit/0.23.22-1/common/unix-peer.c/#L133

It seems like all the possible implementations using one of SO_PEERCRED,
getpeereid(), getpeerucred(), or  are unavailable on hurd.
I'm unsure how to proceed here and have Cced the hurd porters for help.

Do note that p11-kit is required for building essential. As such, not
supporting hurd here practically kills hurd ports. If someone happens to
find a fix or workaround, please notify me.

Helmut
--- a/p11-kit/lists.c
+++ b/p11-kit/lists.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Bug#989234: apt-show-versions: shows abandoned apt lists

[Adam Borowski]

Package: apt-show-versions
Version: 0.22.12
Severity: normal

Hi!
If the machine had an apt source removed for whatever reason (dist-upgraded
from a past Debian release, a foreign architecture removed, etc), apt leaves
the obsolete lists in /var/apt/lists/.  While I find purpose of that
behaviour questionable, it's how things currently are, and even if this
changes in the future, you may expect cruft from past apt versions.

apt-show-version shouldn't read those files.

With other bugs related to reading apt lists, perhaps you might want to
run "apt-cache dumpavail" instead of reading them manually?


Meow!
-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (400, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages apt-show-versions depends on:
ii  apt  2.2.3
ii  libapt-pkg-perl  0.1.39
ii  perl [libstorable-perl]  5.32.1-4

apt-show-versions recommends no packages.

apt-show-versions suggests no packages.

-- no debconf information

Bug#989233: malloc(): smallbin double linked list corrupted

[Allan Wind]

Package: newsboat
Version: 2.13-1+deb10u1
Severity: normal

Dear Maintainer,

I am getting this error once in a while:

"malloc(): smallbin double linked list corrupted"

and the program exists and leaves the terminal in a modified 
state.  echo disabled, I think.  Sorry, I did not think of

running stty to figure out what.

I have not been able to reproduce the issue.  This looks 
potentially interesting:


https://github.com/newsboat/newsboat/blob/master/CHANGELOG.md#2221---2021-01-10

2.22

...

Memory corruption while rendering an article with JavaScript that 
contains HTML (#1300) (Alexander Batischev)



/Allan

-- System Information:
Debian Release: 10.9
 APT prefers stable-updates
 APT policy: (990, 'stable-updates'), (990, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages newsboat depends on:
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4+deb10u2
ii  libgcc-s1 [libgcc1]  10.1.0-1
ii  libgcc1  1:8.3.0-6
ii  libjson-c3   0.12.1+ds-2+deb10u1
ii  libncursesw6 6.1+20181013-2+deb10u2
ii  libsqlite3-0 3.27.2-3+deb10u1
ii  libstdc++6   10.1.0-1
ii  libstfl0 0.22-1.3+b10
ii  libtinfo66.1+20181013-2+deb10u2
ii  libxml2  2.9.4+dfsg1-7+deb10u1

Versions of packages newsboat recommends:
ii  sensible-utils  0.0.12

newsboat suggests no packages.

-- no debconf information

--
Allan Wind
Yaxto - Runs Your Business

Bug#989229: grub-install: warning: Cannot read EFI Boot* variables.

[Joseph Maher]

Package: grub2-common
Version: 2.04-17
Severity: grave
Justification: renders package unusable


grub seems unhappy on my laptop (testing=bullseye, acer spin 1), currently 
grub-install doesn't work, and so the various grub packages aren't 
installable / upgradable


Not sure what the severity should be, or which package I should file a bug 
against, but I've appended some typical output below that may or may not 
be useful:


Yours

Joseph


# grub-install --target=x86_64-efi
Installing for x86_64-efi platform.
grub-install: warning: Cannot read EFI Boot* variables.
grub-install: warning: efivarfs_get_variable: read failed: Interrupted system 
call.
grub-install: warning: efi_get_variable: ops->get_variable failed: Interrupted 
system call.
grub-install: error: failed to register the EFI boot entry: Interrupted system 
call.


# grub-install --target=x86_64-efi --debug

This output is very verbose, but I've left a copy here:

https://www.maher.org.uk/~joseph/20210529-grub-install.log



# efibootmgr 
Skipping unreadable variable "Boot": Interrupted system call

Skipping unreadable variable "Boot0001": Interrupted system call
Skipping unreadable variable "Boot0002": Interrupted system call
Skipping unreadable variable "Boot0003": Interrupted system call
Skipping unreadable variable "Boot0005": Interrupted system call
Skipping unreadable variable "Boot0008": Interrupted system call
Skipping unreadable variable "Boot000B": Interrupted system call
Skipping unreadable variable "Boot000E": Interrupted system call
Skipping unreadable variable "Boot0011": Interrupted system call
Skipping unreadable variable "Boot0014": Interrupted system call
Skipping unreadable variable "Boot0017": Interrupted system call
Skipping unreadable variable "Boot2001": Interrupted system call
Skipping unreadable variable "Boot2002": Interrupted system call
Skipping unreadable variable "Boot2003": Interrupted system call
show_order(): Interrupted system call


# efivar -l
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
8be4df61-93ca-11d2-aa0d-00e098032b8c-dbxDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-dbDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-KEKDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-PKDefault
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0017
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0014
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0011
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000E
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000B
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0008
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0005
89cb0e8d-393c-4830-bfff-65d9147e8c3b-AUPS
89cb0e8d-393c-4830-bfff-65d9147e8c3b-ACUB
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications
a9b5f8d2-cb6d-42c2-bc01-b5ffaae4335e-PBRDevicePath
d719b2cb-3d3a-4596-a3bc-dad00e67656f-db
8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK
8be4df61-93ca-11d2-aa0d-00e098032b8c-PK
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002
eaec226f-c9a3-477a-a826-ddc716cdc0e3-OfflineUniqueIDEKPubCRC
eaec226f-c9a3-477a-a826-ddc716cdc0e3-OfflineUniqueIDEKPub
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001
89cb0e8d-393c-4830-bfff-65d9147e8c3b-WBSN
89cb0e8d-393c-4830-bfff-65d9147e8c3b-WBMN
59d1c24f-50f1-401a-b101-f33e0daed443-TargetHddDevPath
a04a27f4-df00-4d42-b552-39511302113d-BootType
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
bf661981-1bce-42fc-abc4-716d8531aac5-WIFICTL
89cb0e8d-393c-4830-bfff-65d9147e8c3b-ASSN
0d9a1427-e02a-437d-926b-aa521fd722ba-PciLanInfo
04b37fe8-f6ae-480b-bdd5-37d98c5e89aa-VarErrorFlag
89cb0e8d-393c-4830-bfff-65d9147e8c3b-AEBT
0a4cd120-ea2d-4aef-a4b0-b0c08cbbdbbe-BootDevice
59d1c24f-50f1-401a-b101-f33e0daed443-PhysicalBootOrder
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot2003
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot2002
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot2001
59d1c24f-50f1-401a-b101-f33e0daed443-EMMC_DTR
89cb0e8d-393c-4830-bfff-65d9147e8c3b-SMAC
89cb0e8d-393c-4830-bfff-65d9147e8c3b-SMAB
89cb0e8d-393c-4830-bfff-65d9147e8c3b-SMAA
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout
89cb0e8d-393c-4830-bfff-65d9147e8c3b-A01LastSataPortPresent
89cb0e8d-393c-4830-bfff-65d9147e8c3b-ABRV
a04a27f4-df00-4d42-b552-39511302113d-Custom
59d1c24f-50f1-401a-b101-f33e0daed443-CustomPlatformLang
89cb0e8d-393c-4830-bfff-65d9147e8c3b-ACFB
59d1c24f-50f1-401a-b101-f33e0daed443-AdministerSecureBoot
89cb0e8d-393c-4830-bfff-65d9147e8c3b-ASTM
aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54-Tcg2PhysicalPresence
aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54-Tcg2PhysicalPresenceFlags
e20939be-32d4-41be-a150-897f85d49829-MemoryOverwriteRequestControl
89cb0e8d-393c-4830-bfff-65d9147e8c3b-AFBD
89cb0e8d-393c-4830-bfff-65d9147e8c3b-AACV
382af2bb--abcd-aaee-cce099338877-SecureFlashInfo
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
8be4df61-93ca-11d2-aa0d-0

Bug#988494: RFS: ircii/20190117-1+deb10u1 [QA] [RC] -- Internet Relay Chat client

[Håvard Flaget Aasen]

Control: tags -1 -moreinfo

Hi Tobias,

Thanks for the review.

> 
> The package looks fine; however, you need to say 
> "Closes: #986214" (the "#" is missing).
> Would be cool if you could update the package accordingly.
> Possibly a good idea to send the updated debdiff also to the pu-buster bug.

I updated the package yesterday, and sent a new debdiff to the buster-pu
bug.

> 
> (After release-team says "OK", it can be uploaded…)
> 
> (I'm tagging it more info to get it from the list of actionable RFS;
> please remove the tag once the release team gives green light.)

The buster-pu bug was approved earlier today.


Håvard
> 
> Cheers,
> -- 
> tobi
> 
> >   ircii - Internet Relay Chat client
> > 
> > To access further information about this package, please visit the
> > following URL:
> > 
> >   https://mentors.debian.net/package/ircii/
> > 
> > Alternatively, one can download the package with dget using this command:
> > 
> >   dget -x
> >
> https://mentors.debian.net/debian/pool/main/i/ircii/ircii_20190117-1+deb10u1.dsc
> > 
> > Changes since the last upload:
> > 
> >  ircii (20190117-1+deb10u1) buster; urgency=medium
> >  .
> >    * QA upload.
> >    * Fix CVE-2021-29376: allows remote attackers to cause a denial of
> >  service (segmentation fault and client crash, disconnecting
> >  the victim from an IRC server) via a crafted CTCP UTC message.
> >  Closes: 986214
> > 
> > 
> > I've sent a "buster-pu" mail, which is located here [0]
> > 
> > 
> > Regards,
> > Håvard
> > 
> > 
> > [0] https://bugs.debian.org/#988492
> > 
> > 
> 
> 
> 

Bug#987545: libpam-u2f: libpam_u2f does not require pin regardless of key definition

[Salvatore Bonaccorso]

Hi nicoo,

Unless mistaken this relates to CVE-2021-31924, and affects only the
bulleye and unstable version. Can you include the fix and ask the
release team for an unblock?

https://www.yubico.com/support/security-advisories/ysa-2021-03

Regards,
Salvatore

Bug#988724: firefox: Firefox 88 unusable on intel gpu

[Kamil Jońca]

Mike Hommey  writes:

> On Mon, May 24, 2021 at 08:51:43AM +0200, Kamil Jońca wrote:
>> 
>> 
>> Mike Hommey  writes:
>> >
>> > Can you also provide about:support content for that working firefox 88?
>
> Can you go to about:config, set gfx.webrender.software to true, then
> restore your Xorg configuration and try again?
>
> Mike

With this configuration, firefox was usable. No noticable difference in
responsivnes in my short test. Although youtbe clip generated about 150%
CPU on my Intel(R) Core(TM) i7-8665U

KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Bug#989232: mtx: manpages suggest /proc/scsi/scsi, it's long obsolete

[James Youngman]

Package: mtx
Version: 1.3.12-12
Severity: normal
Tags: patch upstream

The manpages refer to use of /proc/scsi/scsi for troubleshooting and
seem to predate the ubiqity of udev.  The attached patch brings the
documentation a bit more up-to-date.

-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages mtx depends on:
ii  libc6  2.28-10

mtx recommends no packages.

mtx suggests no packages.

-- no debconf information
>From ae077698ef87324631f6e0586e95153a58862167 Mon Sep 17 00:00:00 2001
From: James Youngman 
Date: Sat, 29 May 2021 19:30:26 +0100
Subject: [PATCH] Update Linux device node naming and troubleshooting.

1. Suggest "lscsi" instead of "cat /proc/scsi/scsi" for Linux, because
   the latter has been a legacy feature since about 2011.
2. Update Linux device file naming to match usual names with
   udev.
3. Mention some more modern tape hardware on which the tools have been
   tested.
---
 mtx/FAQ  |  79 -
 mtx/loaderinfo.1 |  36 ---
 mtx/mtx.1| 112 +++
 mtx/scsieject.1  |  51 ++---
 mtx/scsitape.1   |  67 +---
 mtx/tapeinfo.1   |  29 ++--
 6 files changed, 183 insertions(+), 191 deletions(-)

diff --git a/mtx/FAQ b/mtx/FAQ
index 186242f..c7d60ae 100644
--- a/mtx/FAQ
+++ b/mtx/FAQ
@@ -1,6 +1,6 @@
 Frequently Asked Questions List, v 1.0.1
 
-Index: 
+Index:
   I. Compiling
   II. Finding the correct device
   III. Operational Issues
@@ -9,68 +9,70 @@ Part I: Compiling.
 
 Q: Where is the Makefile in the tarball?
 A: MTX now uses GNU Autoconf to generate the Makefile. Type "./configure"
-   while in the extracted mtx directory. 
+   while in the extracted mtx directory.
 
 Q: Typing 'make' gives me a bunch of errors in the Makefile. Why can't
you provide a Makefile that works?
-A: Note that you need the GNU 'make'. The BSD 'make' won't work, and 
+A: Note that you need the GNU 'make'. The BSD 'make' won't work, and
   Solaris 'make' probably won't work either. If you want a better
   configuration and makefile system, write one, then EMAIL me the results --
-  mtx is Open Source software and needs your code contributions to grow. 
+  mtx is Open Source software and needs your code contributions to grow.
 
 Q: How do I compile for operating systems other than Linux?
 A: MTX no longer needs you to edit the Makefile to compile for operating
-   systems other than Linux. Just type ./configure and go with it. 
+   systems other than Linux. Just type ./configure and go with it.
 
 Q: How do I port it to OS's other than the supported ones?
 A: Create a new scsi_ module using one of the existing modules as an
example (scsi_freebsd.c might be a good model). Decide what symbol
you want #ifdef'ed in order to include that scsi_ module. Edit
mtxl.c to #include your scsi_ module. Edit the Makefile to add the
-   new target, including the -D needed to #include your new scsi_ module. 
+   new target, including the -D needed to #include your new scsi_ module.
 
 *
-Part II: Finding the correct device. 
+Part II: Finding the correct device.
 
 Q: Why does this command not work??
 [root@Scotty mtxl-1.4.8]# ./mtx -f /dev/st0 inquiry
In /var/log/messages I see:
-  st0: Write not multiple of tape block size. 
+  st0: Write not multiple of tape block size.
 A: Note that mtx 1.2 and above use the SCSI GENERIC interface on Linux,
   FreeBSD, and Solaris (at least). They do NOT use the tape device node.
 
-Q: When I do 'mtx -f /dev/sga inquiry' it shows 
+Q: When I do 'mtx -f /dev/sga inquiry' it shows
   Product Type: Tape Drive
-  Vendor Id: HP   
-  Product ID: C1553A 
+  Vendor Id: HP
+  Product ID: C1553A
But when I do a 'mtx -f /dev/sga status' it fails. Why?!
 A: You're trying to send a robotics command to a tape drive. You need
to send robotics commands to robotics devices, not to tape drives. Look in
-  /proc/scsi/scsi (Linux) or camcontrol (FreeBSD) to find out what the
+  lsscsi -gc (Linux) or camcontrol (FreeBSD) to find out what the
   robotics device is. It will be reported as a 'Medium Changer', not a
   'Sequential Access' or 'Tape Drive'.
 
 Q: When I do 'cat /proc/scsi/scsi' it shows only one device, the tape device!
 A: You are using a DAT autochanger that has one SCSI ID but two LUN's, LUN 0
and LUN 1. You need to compile a new kernel with  SCAN SCSI LUNS enabled
-   or add 

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

I never thought I would say that, but radeon's capabilities are inferior even
to nvidia's legacy driver.
It has been a few hours now and I am still struggling to get vaapi working on
mpv and mplayer. 2d acceleration is bad, so bad that I can see the scrollbar on
ALL webpages "struggle" to keep up with the rest of the page when I scroll with
the wheel.

And on top of the above, 5.10.40 messed up the cpu temperature sensor readings
I get on my conky, so now I have nothing to look at. What a mess!

Bug#989061: Update protobuf to new upstream 3.15.5 or later

[Pirate Praveen]

On Sat, May 29, 2021 at 5:28 pm, László Böszörményi (GCS) 
 wrote:

Control: tags -1 + moreinfo pending

On Mon, May 24, 2021 at 10:57 PM Pirate Praveen
 wrote:

 Please update protobuf to 3.15.5 or later. I'd be happy to help with
 the update if required.
 Yup, please test it [1] and let me know if it works correctly or not 
for you.




Thanks, I have built it here 
https://people.debian.org/~praveen/devel/pool/main/p/protobuf/


ruby-pg-query now builds fine with this version. I still need some more 
dependencies updated/packaged before I can actually test gitlab. Even 
then due to #966653 the debian package of grpc/protobuf is unusable for 
me for some time and as a work around I have been using the binaries 
provided via rubygems.org But I will test again once I have the new 
version of gitlab.



Regards,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/protobuf_3.17.1-1.dsc

Bug#989089: [Pkg-tigervnc-devel] Bug#989089: tigervnc-standalone-server: when a vncserver instance is invoked, mate-panel starts grabbing memory

[Ola Lundqvist]

Hi

Now I understand better. What I do not understand is why you have filed the
bug on vnc when it is the mate-panel that hogs the memory.
For this to be a vnc bug I think we need some proof that this is VNC
specific and this does not happen when starting a normal X session.

Vnc starts a desktop environment and mate-panel is a component of the Mate
desktop environment.

Or am I completely wrong?

// Ola

On Sat, 29 May 2021 at 08:58, deltagam...@gmx.net 
wrote:

> The relevant machine has 8 GB RAM, 2 GB RAM is fix reserved for oracle DB
> 18c xe.
>
> As you can see here
>
> [user__at__machine:pts/4 ~/.vnc]$ date && free -tm
> Fr 30. Apr 16:09:49 CEST 2021
>   totalusedfree  shared  buff/cache
> available
> Mem:   79782761 89112784325
> 3636
>
> 3.6 GB available memory before starting vncserver on 30. April  ...
>
> ===  after some days  ==
> [user__at__machine:pts/4 ~/.vnc]$ date && sudo pmap 8903 | head -10
> Do 6. Mai 13:21:39 CEST 2021
> [sudo] Passwort für user:
> 8903:   mate-panel
> 55ec1bd26000128K r mate-panel
> 55ec1bd46000324K r-x-- mate-panel
> 55ec1bd97000140K r mate-panel
> 55ec1bdba000 16K r mate-panel
> 55ec1bdbe000  4K rw--- mate-panel
> 55ec1cb34000 1698228K rw---   [ anon ]
> 7f9e9000   1416K rw---   [ anon ]
> 7f9e90162000  64120K -   [ anon ]
> 7f9e9400   1448K rw---   [ anon ]
> [user__at__machine:pts/4 ~/.vnc]$
> [user__at__machine:pts/4 ~/.vnc]$ date && free -tm
>
> After 6 days, on 6 May mate-panel has grabbed more than 1698228K  ==> 1.69
> GB,
> the available memory sunk to 2 GB , the difference is approx. the 1.6 GB
> that mate-panel has grabbed.
>
>
> [user__at__machine:pts/4 ~/.vnc]$ date && free -tm
> Do 6. Mai 13:24:07 CEST 2021
>   totalusedfree  shared  buff/cache
> available
> Mem:   79784357 54112683079
> 2049
> Swap:  664925544095
> Total:1462869124636
> [user__at__machine:pts/4 ~/.vnc]$
>
> After killing the vncserver now, on 6. May, the mate-panel process
> disappeared also ( it seems there is a strong interaction between
> tigervnc-standalone-server and mate-panel ) , the new available memory is
> also again around 3.6 GB
> which indicates again that mate-panel has grabbed the difference between
> the 2 "avaibale memory" states, namely 3.6GB and 2.0GB
>
>
> On a reference machine, same Debian buster, same 8 GB RAM, but DB not
> installed yet, the mate-panel has stable about 35 MB memory , after a week
> with a running vncserver:
>
> =  reference machine with running vncserver AND connected client for 
> a week ==
>
> user__at__refmachine:~/.vnc$ sudo pmap 19726 |head -10
> 19726:   mate-panel
> 558100ac1000128K r mate-panel
> 558100ae1000324K r-x-- mate-panel
> 558100b32000140K r mate-panel
> 558100b55000 16K r mate-panel
> 558100b59000  4K rw--- mate-panel
> 55810215e000  35224K rw---   [ anon ]
> 7fcc3000132K rw---   [ anon ]
> 7fcc30021000  65404K -   [ anon ]
> 7fcc3400132K rw---   [ anon ]
> user__at__refmachine:~/.vnc$
>
>
> I think the relevant address, process, is the first  [ anon ]  entry in the 
> pmap listing of the mate-panel.
>
> It is about 35 MB at ref-machine,
>
> and started with about 13 MB  { 5620203f9000  13064K rw---   [ anon ] }  
> on the production machine
> to 266 MB { 5620203f9000 266824K rw---   [ anon ] } 1 day later  on the 
> production machine
> up to 1.69 GB {  55ec1cb34000 1698228K rw---   [ anon ] } after 1 week on 
> the production machine, where I killed/stopped the vncserver.
>
> I let the mate-panel reach also between 2.5 GB and 3 GB before I killed the 
> vncserver, the mate-panel process disappeared also,
> and the freed memroy  corresponded to the memory mate-panel has grabbed.
>
> The displayed lines are all protocolled in the 2 attached files.
>
> Hope this clarifies the case.
>
> Greets
>
>
>
>
> Am 26.05.2021 um 08:27 schrieb Ola Lundqvist:
>
> Hi
>
> When you are referring to "grabbing memory" how much are you expecting
> mate-panel to use?
> Is it much more than what the mate-panel use to use in other X servers?
> I can see that mate-panel use some 70 to 100 MB memory but since I have no
> knowledge about this software I cannot tell whether that is a lot of not.
>
> Cheers
>
> // Ola
>
> On Tue, 25 May 2021 at 18:19, deltagam...@gmx.net 
> wrote:
>
>> forgot to attach some files
>>
>>
>>
>> ___
>> Pkg-tigervnc-devel mailing list
>> pkg-tigervnc-de...@alioth-lists.debian.net
>>
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>>
>
>
> --
>  - Ola Lundqvist ---
> /  o...@debian.org 

Bug#987936: libstorj: fails to build from the source

[Philip Wyett]

On Mon, 2021-05-17 at 12:45 +0200, Andrej Shadura wrote:
> Hi Phil and Josue,
> 
> On 15/05/2021 06:05, Philip Wyett wrote:
> > Attached is a (NMU) debdiff that fixes the issue. Cherry picked patch from 
> > Fedora[1].
> > 
> > This RC bug can be handled however wished by the maintainer. Just one less 
> > to fix. :-)
> > 
> > [1] Original patch by: Gwyn Ciesla 
> 
> It would appear Nettle 3.7.2+ ships its own implementation of
> pbkdf2_hmac_sha512, which causes the conflict during the build. I think
> the best way is to change to patch to use #ifndef and not just comment
> it out, so it can still be built against an older Nettle (e.g. for
> backports).
> 
> I’ve pushed the changes to the Git repo and will upload this to DELAYED/0.
> 

Hi Andrej,

This fix is now in unstable, but to make it into testing/bullseye it requires 
an 'unblock' request
filing.

We are close to auto removal on June 1st, which I think we would all like to 
avoid.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#989231: libegl-dev: Updated version in backports breaks libegl1-mesa-dev reverse dependencies

[Marcel Partap]

Package: libegl-dev
Version: 1.3.2-1
Severity: normal
X-Debbugs-Cc: mpar...@gmx.net

Recently, libglvnd packages 1.3.2 was pushed to backports.. libegl-dev says it
'replaces' libegl1-mesa-dev, but it doesn't 'provide' it.. so packages in
stable that are dependent on that break when updating.
Probably changing the 'replaces' to 'provides' is enough to unbreak?

Bug#989222: [Pkg-phototools-devel] Bug#989222: Bug#989222: darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files

[Jonas Smedegaard]

Quoting David Bremner (2021-05-29 18:58:16)
> Jonas Smedegaard  writes:
> > Quoting David Bremner (2021-05-29 14:32:09)
> >> Jonas Smedegaard  writes:
> >> > Upstream tracked and has solved this issue at 
> >> > https://github.com/darktable-org/darktable/issues/8951
> >> >
> >> > At upstream issue tracking is mentioned that the file they used 
> >> > as proof was arguably broken.
> >> >
> >> 
> >> Upstream suggests that fix is not easily backportable,
> >
> > Oh, wauw - then apparently I did something hard without even knowing 
> > it: I grabbed and applied the patch and it seems to work just fine: 
> > https://source.puri.sm/pureos/packages/darktable/-/commit/19eb57c7bffdca0575f1d526656ca4614f05a33c
> >
> > Where do upstream say that?  Perhaps they mean backporting further 
> > back than nearest point release, 3.4.1?
> >
> 
> They mentioned there was a substantial amount of code deletion.

Seems to me that upstream code changes consist of a) fixing the bug 
(involving edits to 7 lines) and b) dropping hand-optimized parallel 
implementation for SSE-capable platforms lots and lot of lines dropped), 
where b) is all ifdef'ed by __SSE__.

Seems to me that upstream talked about dropping that SSE code causing an 
acceptable 20% slowdown of that routine.

I still don't see anywhere that upstream express concern over 
backportability of the bugfix.  If you meant to say that the _size_ of 
upstream changes implied it not being easily backportable, then please 
consider look closer and see if you can agree with me that essentially 
it is a 7 lines change + a massive removal of an optimization deemed no 
longer beneficial to maintain upstream.


> Also, there were 4 commits in that PR; maybe some are harder to 
> backport than others.

Seems to me that the 4 patches in the PR are equivalent to git commit 
2ff4fc58e442cec46042c0be4ac84352196b in upstream master branch, 
which is what I chery-picked and tested.


Thanks for taking time to look at this,

 - 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#989222: [Pkg-phototools-devel] Bug#989222: Bug#989222: darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files

[David Bremner]

Jonas Smedegaard  writes:

> Quoting David Bremner (2021-05-29 14:32:09)
>> Jonas Smedegaard  writes:
>> 
>> >
>> > Upstream tracked and has solved this issue at
>> > https://github.com/darktable-org/darktable/issues/8951
>> >
>> > At upstream issue tracking is mentioned that the file they used as 
>> > proof was arguably broken.
>> >
>> 
>> Upstream suggests that fix is not easily backportable,
>
> Oh, wauw - then apparently I did something hard without even knowing it: 
> I grabbed and applied the patch and it seems to work just fine: 
> https://source.puri.sm/pureos/packages/darktable/-/commit/19eb57c7bffdca0575f1d526656ca4614f05a33c
>
> Where do upstream say that?  Perhaps they mean backporting further back 
> than nearest point release, 3.4.1?
>

They mentioned there was a substantial amount of code deletion. Also,
there were 4 commits in that PR; maybe some are harder to backport than
others.

Bug#989230: nemo: Files size copy is buggy

[Nicolas Patrois]

Package: nemo
Version: 4.8.6-1
Severity: normal
Tags: upstream

Dear Maintainer,

The screenshot shows the issue.
I’m just copying a bunch of files onto an USB key.
Of course, I’m not copying 1.4 Eo of data and I won’t wait ten years until it
finishes.

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.7.0-1-686-pae (SMP w/3 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nemo depends on:
ii  cinnamon-desktop-data  4.8.1-2
ii  desktop-file-utils 0.26-1
ii  gsettings-desktop-schemas  3.38.0-2
ii  gvfs   1.46.2-1
ii  libatk1.0-02.36.0-2
ii  libc6  2.31-12
ii  libcairo-gobject2  1.16.0-5
ii  libcairo2  1.16.0-5
ii  libcinnamon-desktop4   4.8.1-2
ii  libexempi8 2.5.2-1
ii  libexif12  0.6.22-3
ii  libgail-3-03.24.24-4
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libglib2.0-0   2.66.8-1
ii  libglib2.0-data2.66.8-1
ii  libgtk-3-0 3.24.24-4
ii  libnemo-extension1 4.8.6-1
ii  libnotify4 0.7.9-3
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libselinux13.1-3
ii  libx11-6   2:1.7.1-1
ii  libxapp1   2.0.7-1
ii  libxml22.9.10+dfsg-6.7
ii  nemo-data  4.8.6-1
ii  shared-mime-info   2.0-1

Versions of packages nemo recommends:
ii  cinnamon-l10n4.8.3-1
ii  gvfs-backends1.46.2-1
ii  gvfs-fuse1.46.2-1
ii  librsvg2-common  2.50.3+dfsg-1
ii  nemo-fileroller  4.8.0-1

Versions of packages nemo suggests:
pn  eog   
ii  evince [pdf-viewer]   3.38.2-1
ii  gv [pdf-viewer]   1:3.7.4-2
ii  mpg321 [mp3-decoder]  0.3.2-3.1
ii  mupdf [pdf-viewer]1.17.0+ds1-1.3
ii  okular [pdf-viewer]   4:20.12.3-1
ii  vlc [mp3-decoder] 1:3.0.14-dmo1
ii  xdg-user-dirs 0.17-2
ii  xpdf [pdf-viewer] 3.04+git20210103-3

Bug#988492: buster-pu: package ircii/20190117-1

[Tobias Frost]

On Sat, 29 May 2021 15:11:30 +0100 "Adam D. Barratt" 
wrote:
> Please go ahead.
> 

Thanks, Adam.

I've just sponsored the uploaded for Håvard.

-- 
Cheers,
tobi

Bug#989132: buster-pu: package wml/2.12.2~ds1-3~deb10u1

[Cyril Brulebois]

Adam D. Barratt  (2021-05-29):
> On Wed, 2021-05-26 at 13:10 +0200, Cyril Brulebois wrote:
> > The wml package in buster contains a regression from stretch that
> > leads to various Unicode-related fun. It can trigger Unicode validity
> > issues in Chinese, which was seen and worked around for the build of
> > the Debian website; but it can also misrender various languages, if a
> > non-ASCII character happens to be the last one on a line in the WML
> > source.
> > That includes the rather frequent word “à” in French (affecting
> > hundreds of pages on the Debian website), or “υ” as the last letter
> > of the last word (seen in Greek). This was also reported for Russian.
> 
> Please go ahead; thanks.

Thanks, package uploaded.

Axel, buster branch & debian/2.12.2_ds1-3_deb10u1 tag pushed to wml.git.


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


signature.asc
Description: PGP signature

Bug#985791: buster-pu: package nmap/7.70+dfsg1-6+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-03-23 at 17:48 +, Samuel Henrique wrote:
> Please refer to the recent unblock request for bullseye for the same
> reason: #985680
> https://bugs.debian.org/985680
> 
> I updated the nmap-mac-prefixes file as per user request (#953986).
> 
> This is a file which contains a list of OUI entries (OUI + name) and
> it's used by nmap to help identify vendors based on MAC addresses.
> 
> The file is constantly updated by upstream but our packages use the
> old
> version, the change is to update the file based on the latest
> release,
> 7.91.
> 

Note that this request didn't make it to debian-release, presumably due
to the size of the diff; apologies for the delay.

Please go ahead.

Regards,

Adam

Bug#988977: buster-pu: package libbusiness-us-usps-webtools-perl/1.122-1+deb10u1

[Yadd]

Le 29/05/2021 à 16:04, Adam D. Barratt a écrit :
> Control: tags -1 + confirmed
> 
> On Sat, 2021-05-22 at 12:26 +0200, Yadd wrote:
>> [ Reason ]
>> USPS is sending notices that HTTP access will be turned off shortly,
>> in favor of HTTPS.
>>
>> Given that is a web service that will break in the wild, in addition
>> to a regular update for unstable, we should update buster (and
>> stretch) via stable-updates (and oldstable-updates).
> 
> Ideally there'll have been a point release before June 24th; admittedly
> that still needs organising.
> 
> Note that stretch-updates stopped being supported when stretch moved to
> LTS; indeed, it doesn't make much sense given that there are no point
> releases for LTS for such updates to be released in advance of.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Hi,

done for Buster. I pushed also a Stretch update, then if someone want to
get it, it is ready ;-)

Thanks!
Yadd

Bug#989226: unblock: isc-dhcp/4.4.1-2.3

[Cyril Brulebois]

Salvatore Bonaccorso  (2021-05-29):
> Nothing particularly, but it needs a d-i review as well from Cyril.

No objections, thanks.

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


signature.asc
Description: PGP signature

Bug#981083: protobuf: support build profiles

[GCS]

Control: tags -1 + moreinfo pending

Hi Helmut,

On Tue, Jan 26, 2021 at 7:21 AM Helmut Grohne  wrote:
> protobuf participates in dependency loops relevant to architecture
> bootstrap. I noticed that protobuf's Build-Depends are well organized.
> Thank you! There is not much room for trimming them, but using build
> profiles one can cut certain cycles. The most useful profile likely is
> nocheck. Beyond that, I'm proposing profiles nopython and noruby. Please
> consider applying the attached patch. Note that #981014 needs to before
> you can ship the nopython and noruby profiles.
 Might you have some time to check if I correctly forward ported your
patch [1] to the new protobuf release?

Thanks anyway,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/protobuf_3.17.1-1.dsc

Bug#989061: Update protobuf to new upstream 3.15.5 or later

[GCS]

Control: tags -1 + moreinfo pending

On Mon, May 24, 2021 at 10:57 PM Pirate Praveen
 wrote:
> Please update protobuf to 3.15.5 or later. I'd be happy to help with
> the update if required.
 Yup, please test it [1] and let me know if it works correctly or not for you.

Regards,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/protobuf_3.17.1-1.dsc

Bug#989224: [Pkg-puppet-devel] Bug#989224: puppet: Cron Provider breaks on crontab with certain environment variables (easy DOS for a user)

[Stig Sandbeck Mathisen]

Joerg Jaspert  writes:

> Upstream does not care, see
> https://tickets.puppetlabs.com/browse/PUP-10998

>From the upstream comment, it looks a bit more like "Upstream has not
understood your comment, has yet to see the issue from your perspective
or thought through the security implications of the bug".

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#989228: curl: CVE-2021-22898: TELNET stack contents disclosure

[Salvatore Bonaccorso]

Source: curl
Version: 7.74.0-1.2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.64.0-4+deb10u2
Control: found -1 7.64.0-4+deb10u1
Control: found -1 7.64.0-4

Hi,

The following vulnerability was published for curl.

CVE-2021-22898[0]:
| TELNET stack contents disclosure

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-22898
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22898
[1] https://curl.se/docs/CVE-2021-22898.html

Regards,
Salvatore

Bug#731852:

[brianjesse]

Witaj, Uprzejmie informujemy, że ten e-mail, który dotarł do Twojej
skrzynki pocztowej, nie jest błędem, ale został specjalnie do Ciebie
skierowany. Mam propozycję (7,500.000,00 $) pozostawioną przez mojego
zmarłego klienta inżyniera Carlosa, który nosi to samo nazwisko, który
kiedyś pracował i mieszkał tutaj w Lome Togo. Mój zmarły klient i rodzina
uczestniczyli w wypadku samochodowym, który zabrał ich życie . Skontaktuję
się z tobą jako najbliższym krewnym zmarłego, abyś mógł otrzymać środki na
roszczenia. Po szybkiej odpowiedzi poinformuję cię o sposobach wykonania
tego przymierza, skontaktuj się ze mną w tej sprawie (brianjess...@gmail.com
)

Bug#989095: nginx: diff for NMU version 1.18.0-6.1

[Salvatore Bonaccorso]

Control: tags 989095 + patch
Control: tags 989095 + pending


Dear maintainer,

I've prepared an NMU for nginx (versioned as 1.18.0-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru nginx-1.18.0/debian/changelog nginx-1.18.0/debian/changelog
--- nginx-1.18.0/debian/changelog	2020-08-19 15:27:02.0 +0200
+++ nginx-1.18.0/debian/changelog	2021-05-29 16:21:37.0 +0200
@@ -1,3 +1,11 @@
+nginx (1.18.0-6.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Resolver: fixed off-by-one write in ngx_resolver_copy() (CVE-2021-23017)
+(Closes: #989095)
+
+ -- Salvatore Bonaccorso   Sat, 29 May 2021 16:21:37 +0200
+
 nginx (1.18.0-6) unstable; urgency=medium
 
   * Fix GCC-10 compatibility (Closes: #957605).
diff -Nru nginx-1.18.0/debian/patches/Resolver-fixed-off-by-one-write-in-ngx_resolver_copy.patch nginx-1.18.0/debian/patches/Resolver-fixed-off-by-one-write-in-ngx_resolver_copy.patch
--- nginx-1.18.0/debian/patches/Resolver-fixed-off-by-one-write-in-ngx_resolver_copy.patch	1970-01-01 01:00:00.0 +0100
+++ nginx-1.18.0/debian/patches/Resolver-fixed-off-by-one-write-in-ngx_resolver_copy.patch	2021-05-29 16:21:37.0 +0200
@@ -0,0 +1,39 @@
+From: Maxim Dounin 
+Date: Tue, 25 May 2021 15:17:36 +0300
+Subject: Resolver: fixed off-by-one write in ngx_resolver_copy().
+Origin: https://github.com/nginx/nginx/commit/7199ebc203f74fd9e44595474de6bdc41740c5cf
+Bug-Debian: https://bugs.debian.org/989095
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-23017
+
+Reported by Luis Merino, Markus Vervier, Eric Sesterhenn, X41 D-Sec GmbH.
+---
+ src/core/ngx_resolver.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/core/ngx_resolver.c b/src/core/ngx_resolver.c
+index 793907010278..63b26193df4f 100644
+--- a/src/core/ngx_resolver.c
 b/src/core/ngx_resolver.c
+@@ -4008,15 +4008,15 @@ done:
+ n = *src++;
+ 
+ } else {
++if (dst != name->data) {
++*dst++ = '.';
++}
++
+ ngx_strlow(dst, src, n);
+ dst += n;
+ src += n;
+ 
+ n = *src++;
+-
+-if (n != 0) {
+-*dst++ = '.';
+-}
+ }
+ 
+ if (n == 0) {
+-- 
+2.31.1
+
diff -Nru nginx-1.18.0/debian/patches/series nginx-1.18.0/debian/patches/series
--- nginx-1.18.0/debian/patches/series	2020-08-19 15:11:02.0 +0200
+++ nginx-1.18.0/debian/patches/series	2021-05-29 16:21:37.0 +0200
@@ -1,3 +1,4 @@
 0002-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
 0003-define_gnu_source-on-other-glibc-based-platforms.patch
 CVE-2019-20372.patch
+Resolver-fixed-off-by-one-write-in-ngx_resolver_copy.patch

Bug#989227: kdenlive: feature missing "motion tracker"

[ybx332]

Package: kdenlive
Version: 20.12.3-1
Severity: normal
X-Debbugs-Cc: ybx...@gmail.com

Dear Maintainer,

 The upstream released the motion tracker function since version 20.08. But now
even under 20.12.3, I still can't find the function motion tracker.


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

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

Versions of packages kdenlive depends on:
ii  ffmpeg 7:4.3.2-0+deb11u1
ii  gstreamer1.0-plugins-bad   1.18.4-3
ii  kded5  5.78.0-2
ii  kdenlive-data  20.12.3-1
ii  kinit  5.78.0-2
ii  kio5.78.0-4
ii  libc6  2.31-12
ii  libkf5archive5 5.78.0-2
ii  libkf5bookmarks5   5.78.0-2
ii  libkf5completion5  5.78.0-3
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5crash5   5.78.0-3
ii  libkf5dbusaddons5  5.78.0-2
ii  libkf5declarative5 5.78.0-2
ii  libkf5filemetadata35.78.0-2
ii  libkf5guiaddons5   5.78.0-3
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5itemviews5   5.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kiocore5 5.78.0-4
ii  libkf5kiofilewidgets5  5.78.0-4
ii  libkf5kiogui5  5.78.0-4
ii  libkf5kiowidgets5  5.78.0-4
ii  libkf5newstuff55.78.0-4
ii  libkf5notifications5   5.78.0-2
ii  libkf5notifyconfig55.78.0-2
ii  libkf5purpose-bin  5.78.0-2
ii  libkf5purpose5 5.78.0-2
ii  libkf5service-bin  5.78.0-2
ii  libkf5service5 5.78.0-2
ii  libkf5solid5   5.78.0-2
ii  libkf5textwidgets5 5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  libmlt++3  6.24.0-1
ii  libmlt66.24.0-1
ii  libqt5concurrent5  5.15.2+dfsg-5
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5dbus55.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-5
ii  libqt5qml5 5.15.2+dfsg-5
ii  libqt5quick5   5.15.2+dfsg-5
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5quickwidgets55.15.2+dfsg-5
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libqt5xml5 5.15.2+dfsg-5
ii  librttr-core0.9.6  0.9.6+dfsg1-4
ii  libstdc++6 10.2.1-6
ii  melt   6.24.0-1
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtqml-models2   5.15.2+dfsg-5
ii  qml-module-qtquick-controls5.15.2-2
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.2-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-5
ii  qml-module-qtquick-window2 5.15.2+dfsg-5
ii  qml-module-qtquick25.15.2+dfsg-5

Versions of packages kdenlive recommends:
ii  breeze 4:5.20.5-3
ii  dvdauthor  0.7.2-1+b3
ii  dvgrab 3.5+git20160707.1.e46042e-1+b1
ii  frei0r-plugins 1.7.0-1
ii  genisoimage9:1.1.11-3.2
ii  oxygen-icon-theme  5:5.78.0-2
ii  recordmydesktop0.3.8.1+svn602-1.1
ii  swh-plugins0.4.17-2

Versions of packages kdenlive suggests:
ii  khelpcenter  4:20.12.0-1
ii  vlc  3.0.12-3

Bug#989202: keepassxc saves config in ~/.cache

[Arnaud bourree]

Hello,

I'm a KeepassXC user on Debian 11.
My keepassxc version is 2.6.2+dfgs.1-1 as referenced here.

Yes, there is a configuration file located at ~/.cache/keepassxc/
keepassxc.ini
But there is also a configuration file located at ~/.config/keepassxc/
keepassxc.ini
When you diff them you can see that configuration in .cache are last
temporary config like last open databases.

IMO, there is no bug there

Regards,

Arnaud

On Fri, 28 May 2021 13:21:55 +0200 Elrond <
elrond+bugs.debian@samba-tng.org> wrote:
> Package: keepassxc
> Version: 2.6.2+dfsg.1-1
> Severity: important
>
> Hi,
>
> (Version in reality: 2.6.2+dfsg.1-1~bpo10+1)
>
> keepassxc 2.6.2 saves a lot of its config in
> ~/.cache/keepassxc/keepassxc.ini
>
> This is not good!
> ~/.cache is for cache files and not for config files.
> This folder is allowed to be cleaned. It is usally ignored
> in backups, etc.
>
> Some setups even clean ~/.cache regularly to remove "old
> unneeded stuff". This will remove the config. And in fact,
> keepassxc afterwards has forgotten nearly everything.
>
> Reasons for severity important (I personally would put it
> grave, but I can't justify it clearly enough):
>
> 1. This is against the XDG Base Directory Specification.
> One should put config files in ~/.config (or possibly
> ~/.local/share), but NOT ~/.cache.
>
> 2. This has the potential for data loss (well,
> configuration loss)
>
>
> Obviously, if this only affects the bpo version, then
> downgrade the severity and highly consider fixing the bpo
> version.
>
>
> Thanks in advance
>
>
> Elrond
>
>

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Version: linux-image-5.10.0-7-amd64
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

Impending rant, because I think it is indeed a hardware failure that was caused
from the kernel upgrade.

I successfully downgraded linux-compiler-gcc-10-x86 and linux-kbuild-5.10 to
their 5.10.28 versions from testing.
As usual, it failed to boot properly after shutdown. I then decided to
completely remove nvidia legacy 340 and give nouveau a chance, although I hate
it and the room temperature was high already, so the risk of frying the card
was also high. Nothing changed, blank screen from boot to poweroff (via ssh).

Out of curiosity, I ran lsmod on both nouveau and nvidia (while it was already
installed). And none of them showed up in lsmod! Moreover, lightdm was not
running at all and I cound not even switch to a tty (not that I could when the
problem first started).
Then I got mad and went for a walk to calm down. I came back a few hours later
and I also borrowed an ati 6450 from a friend to try.

I pressed the power button and the system booted up as usual, using nouveau for
the very first time (maybe second) ever. I ran poweroff, it shut down, I
pressed the power button again and the same thing happened. Blank screen,
nothing on lsmod etc.
Then I replaced it with my friend's ati so as to be able to come back and write
all this text here.

I have no way to test the gpu (e.g. no spare pc), however, if it is a hw
failure, it will be the second time debian destroys one for me. First time was
on summer of 2011, when debian decided to remove fglrx from the repo and force
me to use radeon for my 3850 after the upgrade to a new kernel. Back then,
radeon was so limited in capabilities that it could not do powersaving. Long
story short, my 3850 gave up the ghost ~1 month later, after running in  max
clock speed for a month.

Sadly for me, history has probably repeated itself today, and I don't know why.
What was changed in that damn update that f-ed up my gpu so badly?
This gives me one more reason to leave debian after 13,5 years and move to
arch. I had taken the decision to go there if nouveau becomes my only way to
make my old gpu work in debian, now I have one more.

Bug#986001: buster-pu: package glib2.0/2.58.3-2+deb10u3

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sat, 2021-03-27 at 17:21 +, Simon McVittie wrote:
> Backport security fixes from testing/unstable. The security team say
> they do not intend to issue a DSA for these.
> 
> [ Impact ]
> * CVE-2021-28153: symlink attack allowing an attacker to create an
> empty
>   regular file in a location of their choice when a malicious archive
> is
>   unpacked with file-roller
> * CVE-2021-27219: integer overflow that can cause at least a crash
> (DoS),
>   and maybe code execution, in a setuid program from policykit-1
> * CVE-2021-27218: another integer overflow, not known to be
> exploitable
> * various other integer overflows fixed at the same time as CVE-2021-
> 27219,
>   which are not known to be exploitable
> 
> Please see 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984969#26 if
> more information is required.
> 
> [ Tests ]
> I'm trying the proposed version with normal use on a GNOME laptop and
> some servers. The autopkgtests are fairly extensive, and still pass,
> including new coverage for CVE-2021-28153. The proof-of-concept
> exploits for CVE-2021-27219 and CVE-2021-28153 also now fail.

Apologies for letting this fall through the cracks for a while.

As glib2.0 produces a udeb, this will need a KiBi-ack, so CCing and
tagging appropriately.

Regards,

Adam

Bug#986898: buster-pu: package yubikey-manager/2.1.0-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-04-13 at 12:45 -0400, Taowa wrote:
> This update aims to fix #986865 by adding a dependency on
> python3-pkg-resources.
> 
> [ Impact ]
> A user who installs yubikey-manager will be unable to use it without
> python3-pkg-resources. This will easily go unnoticed should they have
> reportbug installed, but is present on a machine without it.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#987246: buster-pu: package tnef/1.4.12-1.2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-04-20 at 11:21 +, Thorsten Alteholz wrote:
> The attached debdiff for tnef fixes CVE-2019-18849 in Buster.
> 

+tnef (1.4.12-1.2+deb10u1) buster-security; urgency=high

The distribution should just be "buster" for a pu upload, pleae.

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#989226: unblock: isc-dhcp/4.4.1-2.3

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,k...@debian.org

Hi Release team,

Please unblock package isc-dhcp

[ Reason ]
Update to adress CVE-2021-25217, tracked as #989157.

[ Impact ]
CVE remains open for bullseye.

[ Tests ]
None specifically to the vulnerability. The autopkgtests passes (only
systemd one seems flaky a bit, once retried it worked).

[ Risks ]
It includes the upstream provided patch which is overviewable and
targetted in the parsin code.

[ 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 ]
Nothing particularly, but it needs a d-i review as well from Cyril.

unblock isc-dhcp/4.4.1-2.3

Regards,
Salvatore
diff -Nru isc-dhcp-4.4.1/debian/changelog isc-dhcp-4.4.1/debian/changelog
--- isc-dhcp-4.4.1/debian/changelog 2020-08-06 04:08:47.0 +0200
+++ isc-dhcp-4.4.1/debian/changelog 2021-05-27 06:59:48.0 +0200
@@ -1,3 +1,12 @@
+isc-dhcp (4.4.1-2.3) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * A buffer overrun in lease file parsing code can be used to exploit a
+common vulnerability shared by dhcpd and dhclient (CVE-2021-25217)
+(Closes: #989157)
+
+ -- Salvatore Bonaccorso   Thu, 27 May 2021 06:59:48 +0200
+
 isc-dhcp (4.4.1-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch 
isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch
--- isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch1970-01-01 
01:00:00.0 +0100
+++ isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch2021-05-27 
06:59:48.0 +0200
@@ -0,0 +1,29 @@
+Description: A buffer overrun in lease file parsing code can be used to 
exploit a common vulnerability shared by dhcpd and dhclient
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/989157
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-25217
+Forwarded: not-needed
+Author: Salvatore Bonaccorso 
+Last-Update: 2021-05-26
+
+diff --git a/common/parse.c b/common/parse.c
+index 386a6321..fc7b39c6 100644
+--- a/common/parse.c
 b/common/parse.c
+@@ -5556,13 +5556,14 @@ int parse_X (cfile, buf, max)
+   skip_to_semi (cfile);
+   return 0;
+   }
+-  convert_num (cfile,  [len], val, 16, 8);
+-  if (len++ > max) {
++  if (len >= max) {
+   parse_warn (cfile,
+   "hexadecimal constant too long.");
+   skip_to_semi (cfile);
+   return 0;
+   }
++  convert_num (cfile,  [len], val, 16, 8);
++  len++;
+   token = peek_token (, (unsigned *)0, cfile);
+   if (token == COLON)
+   token = next_token (,
diff -Nru isc-dhcp-4.4.1/debian/patches/series 
isc-dhcp-4.4.1/debian/patches/series
--- isc-dhcp-4.4.1/debian/patches/series2020-08-06 04:08:47.0 
+0200
+++ isc-dhcp-4.4.1/debian/patches/series2021-05-27 06:59:48.0 
+0200
@@ -17,3 +17,5 @@
 
 configure.patch
 Fixed_gcc_10_compilation_issues.patch
+
+4.4.2.CVE-2021-25217.patch

Bug#987726: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.143-1~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-04-28 at 17:50 +0200, Andreas Beckmann wrote:
> let's fix CVE-2021-1076 by updating the non-free
> nvidia-graphics-drivers-legacy-390xx in buster to a new upstream
> release.
> 
> This a rebuild of the package in sid, thus it also contains the
> additional packaging change: the creation of the missing
> libnvidia-ml.so symlink

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#987725: buster-pu: package nvidia-graphics-drivers/418.197.02-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-04-28 at 17:43 +0200, Andreas Beckmann wrote:
> let's fix CVE-2021-1076 by updating the non-free nvidia-graphics-
> drivers
> in buster to a new upstream release.
> This driver version is in sid and bullseye available as
> src:nvidia-graphics-drivers-tesla-418
> 
> There is an additional packaging change: the creation of the missing
> libnvidia-ml.so symlink.

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#988255: Acknowledgement (buster-pu: package mariadb-10.3 10.3.29-0+deb10u1)

[Adam D. Barratt]

Control: tags -1 + confirmed

[Note that this mail didn't make it to debian-release, presumably
because of the diffs, even though they were compressed]

On Mon, 2021-05-10 at 08:43 -0700, Otto Kekäläinen wrote:
> Changelog:
> 
> mariadb-10.3 (1:10.3.29-0+deb10u1) buster; urgency=medium
> 
>   [ Otto Kekäläinen ]
>   * SECURITY UPDATE: New upstream version 10.3.29. Includes fixes for
> the
> following security vulnerabilities:
> - CVE-2021-2154
> - CVE-2021-2166
>   * Previous release 10.3.28 included fixes for:
> - CVE-2021-27928
>   * Remove patch regarding a test now removed by upstream (MDEV-
> 22653).
>   * Remove obsolete sql file removed by upstream (MDEV-24586).
>   * Update symbols to include new one from MariaDB Client 3.1.13
>   * Innotop: Add support for MariaDB 10.3 (Closes: #941986)
>   * Upstream release includes fix for MDEV-24194: "Invalid syntax
> errors on
> syntax WHERE `field` IS NULL = 0" (Closes: #977383)
> 
>   [ Daniel Black ]
>   * Add caching_sha2_password.so (Closes: #962597)
> 
> As this is a stable update, there are a couple of important bug fixes
> included which are very safe, and make features work for users that
> currently are completely broken in Buster.
> 

Please go ahead.

Regards,

Adam

Bug#988453: buster-pu: package rust-rustyline/3.0.0-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-05-13 at 11:13 +0100, plugwash wrote:
> rust-rustyline fails to build in buster due to a change of behaviour
> in rustc,
> this has been fixed in bullseye/sid for some time and I was able to
> locate
> the upstream commit that fixes the failure by bisecting and then
> apply it to
> the package from buster.
> 

Please go ahead.

Regards,

Adam

Bug#989006: [RFS] [preapproval] Bug#989006: unblock: vtk-dicom/0.8.12-3

[Étienne Mollier]

Control: tags -1 - moreinfo
Control: retitle -1 unblock: vtk-dicom/0.8.12-4

Hi Sebastian,

Sebastian Ramacher, on 2021-05-28:
> ACK, please remove the moreinfo tag once the new version is available in
> unstable.

The new version has been uploaded and accepted into unstable,
and built on most release architectures.

Thank you for your time!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#988936: buster-pu: package mqtt-client/1.14-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-05-22 at 00:03 +0530, Abhijith PA wrote:
> I would like to update mqtt-client in buster for fixing CVE-2019-
> 0222. 
> 

Please go ahead.

Regards,

Adam

Bug#988492: buster-pu: package ircii/20190117-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-05-28 at 19:52 +, Håvard Flaget Aasen wrote:
> Hi,
> 
> The package was reviewed on the mentors site. I forgot a '#' when I
> closed the bug, that is now fixed.
> 
> Updated the debdiff
> 

Please go ahead.

Regards,

Adam

Bug#988977: buster-pu: package libbusiness-us-usps-webtools-perl/1.122-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-05-22 at 12:26 +0200, Yadd wrote:
> [ Reason ]
> USPS is sending notices that HTTP access will be turned off shortly,
> in favor of HTTPS.
> 
> Given that is a web service that will break in the wild, in addition
> to a regular update for unstable, we should update buster (and
> stretch) via stable-updates (and oldstable-updates).

Ideally there'll have been a point release before June 24th; admittedly
that still needs organising.

Note that stretch-updates stopped being supported when stretch moved to
LTS; indeed, it doesn't make much sense given that there are no point
releases for LTS for such updates to be released in advance of.

Please go ahead.

Regards,

Adam

Bug#988974: buster-pu: package fig2dev/1:3.2.7a-5+deb10u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-05-22 at 11:47 +0200, Roland Rosenfeld wrote:
> I prepared an update for fig2dev 1:3.2.7a-5+deb10u3 to deb10u4, which
> in the first time fixes CVE-2021-3561 (the security team doesn't
> intend to create a DSA but redirected me here).
> 
> Additionally it fixes four other buffer overflows, that are all fixed
> upstream and I backported the fixes.
> 

I'm assuming that "fixed upstream" here implies that the fixes are also
in unstable? If so, please go ahead.

Regards,

Adam

Bug#989129: buster-pu: package node-ws/1.1.0+ds1.e6ddaae4-5+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-05-26 at 12:45 +0200, Yadd wrote:
> Here is the missing debdiff

Please go ahead.

Regards,

Adam

Bug#989132: buster-pu: package wml/2.12.2~ds1-3~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-05-26 at 13:10 +0200, Cyril Brulebois wrote:
> The wml package in buster contains a regression from stretch that
> leads to various Unicode-related fun. It can trigger Unicode validity
> issues in Chinese, which was seen and worked around for the build of
> the Debian website; but it can also misrender various languages, if a
> non-ASCII character happens to be the last one on a line in the WML
> source.
> That includes the rather frequent word “à” in French (affecting
> hundreds of pages on the Debian website), or “υ” as the last letter
> of the last word (seen in Greek). This was also reported for Russian.
> 

Please go ahead; thanks.

Regards,

Adam

Bug#989148: tpm2-tools: CVE-2021-3565

[Bastian Germann]

On Wed, 26 May 2021 22:05:35 +0200 Salvatore Bonaccorso  
wrote:

CVE-2021-3565[0]:
| during tpm2_import command invocation a fixed AES wrapping key is
| used

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-3565
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3565
[1] https://github.com/tpm2-software/tpm2-tools/issues/2738
[2] 
https://github.com/tpm2-software/tpm2-tools/commit/c069e4f179d5e6653a84fb236816c375dca82515

Please adjust the affected versions in the BTS as needed.


The buster version 3.1.3-2 does not contain the tpm2_import tool, so the CVE is not applicable to 
buster. Please correct that in the security tracker.

Bug#989222: [Pkg-phototools-devel] Bug#989222: darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files

[Jonas Smedegaard]

Quoting David Bremner (2021-05-29 14:32:09)
> Jonas Smedegaard  writes:
> 
> >
> > Upstream tracked and has solved this issue at
> > https://github.com/darktable-org/darktable/issues/8951
> >
> > At upstream issue tracking is mentioned that the file they used as 
> > proof was arguably broken.
> >
> 
> Upstream suggests that fix is not easily backportable,

Oh, wauw - then apparently I did something hard without even knowing it: 
I grabbed and applied the patch and it seems to work just fine: 
https://source.puri.sm/pureos/packages/darktable/-/commit/19eb57c7bffdca0575f1d526656ca4614f05a33c

Where do upstream say that?  Perhaps they mean backporting further back 
than nearest point release, 3.4.1?


> so the fix likely have to wait until the release of darktable 3.6.  If 
> you think its a big issue in practice (I can't judge, I don't use 
> DNG), maybe the release team would consider 3.6 for a bullseye point 
> release (likely to a huge diff).

The application megapixels targeted Debian bullseye outputs DNG.

I think it would be helpful that darktable in bullseye could either 
process such DNG files or if not then at least _not_ process them - not 
crash and continue crashing thereafter because the crashing files would 
"pollute" cashed data of darktable.


Kind regards,

 - 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#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Samuel Henrique]

Control: severity -1 grave
Control: tags -1 moreinfo

Hello Jan,

That's a great catch!
I'm bumping the severity as this "makes the package in question
unusable or mostly so".

I believe you accidentally pasted the same link twice when talking
about two different functions.

Could you submit your tests so we can confirm any fix applied (if we do so)?
I would like to use your tests with git-bisect to make sure this
regression wasn't caused by one of our patches.

It's possible that this bug also affects rsakeyfind, so I would
appreciate it if you could run your test against that package as well
(I assume it must be easy since they are so similar).

Thanks for your contributions,

-- 
Samuel Henrique 

Bug#989222: [Pkg-phototools-devel] Bug#989222: darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files

[David Bremner]

Jonas Smedegaard  writes:

>
> Upstream tracked and has solved this issue at
> https://github.com/darktable-org/darktable/issues/8951
>
> At upstream issue tracking is mentioned that the file they used as proof
> was arguably broken.
>

Upstream suggests that fix is not easily backportable, so the fix likely
have to wait until the release of darktable 3.6.  If you think its a big
issue in practice (I can't judge, I don't use DNG), maybe the release
team would consider 3.6 for a bullseye point release (likely to a huge
diff).

Bug#989161: [pre-approval] unblock: cups/2.3.3op2-3+deb11u1

[Didier 'OdyX' Raboud]

Control: tags -1 -moreinfo

Le vendredi, 28 mai 2021, 23.21:56 h CEST Sebastian Ramacher a écrit :
> On 2021-05-27 09:03:49 +0200, Didier 'OdyX' Raboud wrote:
> > unblock cups/2.3.3op2-3+deb11u1
> 
> ACK, please remove the moreinfo tag once the new version is available in
> unstable.

Got the "Accepted cups 2.3.3op2-3+deb11u1 (source) into unstable" email, 
removing the tag.

Thanks for your work!

-- 
OdyX

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

Bug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Mon, Jun 03, 2019 at 09:22:06PM +0200, Philipp Marek wrote:
> Package: src:linux
> Version: 4.19.37-3
> Severity: normal
> 
> Sequence of events:
> 
>  1. Notebook is rebooted properly, used for work for some hours
>  2. Notebook lid was closed, STR works as usual
>  3. Notebook opened; some work; lid close, STR works
>  4. Notebook was opened; NFS4 from remote machine mounted
>  5. Files copied around
>  6. NFS server stopped (data only temporarily shared)
>  7. NFS unmounted via "umount dir/", returns immediately to shell
>  7. I remember that I stopped the server already, "umount dir/ -f &"
>  9. Closing the lid
>  6. About half an hour later I take the notebook from my bag and see that 
> it's still running
> 10. I see the messages about NFS
> 11. I start NFS again for a clean umount - but it's not mounted any more, 
> so there's nothing to umount
> 12. Manual "acpitool -s" (twice) doesn't work (19:34:26)
> 13. I stop the NFS server again
> 14. Closing the lid still doesn't work
> 15. I start NFS again
> 16. At 20:00 an "at" job stops the NFS server again
> 17. MUCH LATER one of the backgrounded "acpitool -s" seems to work, 
> notebook gets suspended while I'm working with it
> 18. Something's still thinking that NFS is mounted
> 
> 
> Here's some log data, shortened/annotated:
> 
>   16:24:14  2. PM: suspend entry (deep)
>   16:24:14 PM: Syncing filesystems ... done.
>   16:49:34  3. PM: suspend exit
>   17:13:53  "  PM: suspend entry (deep)
>   18:23:36  "  PM: Syncing filesystems ... done.
>   18:23:36  4. PM: suspend exit
>   18:41:39  9. PM: suspend entry (deep)
>   18:43:31 PM: Syncing filesystems ...
>   18:45:12 10. INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   18:47:13 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   18:49:14 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   18:51:14 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   18:53:15 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   18:55:16 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   18:57:17 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   18:59:18 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   19:01:19 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   19:03:19 INFO: task systemd-sleep:3057 blocked for more than 120 
> seconds.
>   19:32:34 11. nfs: server rpi3 OK
>   19:34:26 12. PM: suspend entry (deep)
>   19:34:26 PM: suspend exit
>   19:34:30 PM: suspend entry (deep)
>   19:34:30 PM: suspend exit
>   19:37:09 14. PM: suspend entry (deep)
>   19:37:09 PM: suspend exit
>   19:40:27 15. nfs: server rpi3 OK
>   20:52:49 17. done.
>   20:52:49 Freezing user space processes ... (elapsed 0.029 seconds) 
> done. 
>   
>   20:52:49 18. PM: suspend exit 
>   20:55:33 nfs: server rpi3 not responding, timed out
> 
> 
> I know this is not that easy to understand; still, I hope it's 
> reproducible.
> 
> Thank you!

Can you still reproduce your issue with a recent kernel?

Regards,
Salvatore

Bug#989225: unblock: nim/1.4.6+really1.4.2-2

[Federico Ceratto]

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

Please unblock package nim to fix #987272

[ Reason ]
The package currently in Bullseye (1.4.2-1) is affected by:
CVE-2021-21372 CVE-2021-21373 CVE-2021-21374 CVE-2021-29495

[ Impact ]
The vulnerabilities would not be addressed

[ Tests ]
Run the default unit test suite and manual tests

[ Risks ]
Low. The security fixes has been backported from upstream
releases using small quilt patches.

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

[ Other info ]
N/A

unblock nim/1.4.6+really1.4.2-2
diff -Nru nim-1.4.2/debian/changelog nim-1.4.6+really1.4.2/debian/changelog
--- nim-1.4.2/debian/changelog  2020-12-02 13:39:46.0 +
+++ nim-1.4.6+really1.4.2/debian/changelog  2021-05-13 14:09:37.0 
+0100
@@ -1,3 +1,17 @@
+nim (1.4.6+really1.4.2-2) unstable; urgency=medium
+
+  * Rebuild
+
+ -- Federico Ceratto   Thu, 13 May 2021 14:09:37 +0100
+
+nim (1.4.6+really1.4.2-1) unstable; urgency=medium
+
+  * Upload 1.4.2 as 1.4.6+really1.4.2-1 (Closes: #987279)
+  * Security update for CVE-2021-21372 CVE-2021-21373
+CVE-2021-21374 CVE-2021-29495 (Closes: #87272)
+
+ -- Federico Ceratto   Fri, 07 May 2021 21:42:48 +0100
+
 nim (1.4.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru nim-1.4.2/debian/patches/check-ssl-certs.patch 
nim-1.4.6+really1.4.2/debian/patches/check-ssl-certs.patch
--- nim-1.4.2/debian/patches/check-ssl-certs.patch  1970-01-01 
01:00:00.0 +0100
+++ nim-1.4.6+really1.4.2/debian/patches/check-ssl-certs.patch  2021-05-13 
14:09:37.0 +0100
@@ -0,0 +1,42 @@
+Subject: CVE-2021-29495 Check SSL certs by default; fix cert load error 
handling
+Origin: vendor
+Bug: 
https://github.com/nim-lang/security/security/advisories/GHSA-9vqv-2jj9-7mqr
+Forwarded: not-needed
+
+--- a/lib/pure/httpclient.nim
 b/lib/pure/httpclient.nim
+@@ -321,7 +321,7 @@
+   result = defaultSslContext
+   when defined(ssl):
+ if result == nil:
+-  defaultSslContext = newContext(verifyMode = CVerifyNone)
++  defaultSslContext = newContext(verifyMode = CVerifyPeer)
+   result = defaultSslContext
+   doAssert result != nil, "failure to initialize the SSL context"
+ 
+--- a/lib/pure/net.nim
 b/lib/pure/net.nim
+@@ -626,11 +626,12 @@
+ discard newCTX.SSLCTXSetMode(SSL_MODE_AUTO_RETRY)
+ newCTX.loadCertificates(certFile, keyFile)
+ 
+-when not defined(nimDisableCertificateValidation) and not 
defined(windows):
++const VerifySuccess = 1 # SSL_CTX_load_verify_locations returns 1 on 
success.
++when not defined(nimDisableCertificateValidation):
+   if verifyMode != CVerifyNone:
+ # Use the caDir and caFile parameters if set
+ if caDir != "" or caFile != "":
+-  if newCTX.SSL_CTX_load_verify_locations(caFile, caDir) != 0:
++  if newCTX.SSL_CTX_load_verify_locations(caFile, caDir) != 
VerifySuccess:
+ raise newException(IOError, "Failed to load SSL/TLS CA 
certificate(s).")
+ 
+ else:
+@@ -638,7 +639,7 @@
+   # the SSL_CERT_FILE and SSL_CERT_DIR env vars
+   var found = false
+   for fn in scanSSLCertificates():
+-if newCTX.SSL_CTX_load_verify_locations(fn, "") == 0:
++if newCTX.SSL_CTX_load_verify_locations(fn, nil) == VerifySuccess:
+   found = true
+   break
+   if not found:
diff -Nru nim-1.4.2/debian/patches/fix-nimble-cert-validation-2021-21374.patch 
nim-1.4.6+really1.4.2/debian/patches/fix-nimble-cert-validation-2021-21374.patch
--- nim-1.4.2/debian/patches/fix-nimble-cert-validation-2021-21374.patch
1970-01-01 01:00:00.0 +0100
+++ 
nim-1.4.6+really1.4.2/debian/patches/fix-nimble-cert-validation-2021-21374.patch
2021-05-13 14:09:37.0 +0100
@@ -0,0 +1,68 @@
+Subject: Fix CVE-2021-21374 Nimble SSL certificate checking
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987272
+Bug: 
https://github.com/nim-lang/security/security/advisories/GHSA-c2wm-v66h-xhxx
+Forwarded: not-needed
+
+--- a/dist/nimble/src/nimblepkg/packageinfo.nim
 b/dist/nimble/src/nimblepkg/packageinfo.nim
+@@ -4,6 +4,7 @@
+ # Stdlib imports
+ import system except TResult
+ import hashes, json, strutils, os, sets, tables, httpclient
++from net import SSLError
+ 
+ # Local imports
+ import version, tools, common, options, cli, config
+@@ -199,8 +200,12 @@
+ priority = LowPriority)
+ 
+   try:
+-let client = newHttpClient(proxy = proxy)
++let ctx = newSSLContext()
++let client = newHttpClient(proxy = proxy, sslContext = ctx)
+ client.downloadFile(url, tempPath)
++  except SslError:
++let message = "Failed to verify the SSL certificate for " & url
++raiseNimbleError(message, "")
+

Bug#928706: Debian Stretch cannot be installed on QNAP TS-121 (Kirkwood Marvell 6282 CPU w/ 1GB RAM)

[Salvatore Bonaccorso]

Hi Martin, Uwe, Luca,

On Wed, Jul 31, 2019 at 04:46:51PM +0200, Martin Michlmayr wrote:
> * Uwe Kleine-König  [2019-07-29 14:10]:
> > > Unfortunately there's no planned fix yet.  Upstream kernel folks
> > > suggested something but that leads to other problems.
> > 
> > You have a link?
> 
> It's best to download the debian-arm mbox and search for "external
> abort on linefetch" since the thread was over several months (or
> years, in fact, starting in July 2017).
> 
> Basically, the suggestion was to use VMSPLIT_3G_OPT=y but several
> people reported that while this fixes the original issue, networking
> doesn't work anymore.
> 
> Relevant links:
> 
> https://lists.debian.org/debian-arm/2018/06/msg3.html
> https://lists.debian.org/debian-arm/2019/04/msg00031.html
> 
> Let me email Andrew again.

Was this issue adressed with a recent kernel?

Regards,
Salvtore

Bug#927710: ath10k locks to regulatory domain US on ACPI platforms

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sun, Apr 21, 2019 at 09:48:17PM +0200, Rene 'Renne' Bartsch, B.Sc. 
Informatics wrote:
> Package: linux-image
> Version: 4.19.28-2
> 
> The ath10k 802.11 driver reads the country code for the radio regulatory 
> domain from the ACPI table.
> If it can't get a valid value it locks to US regulatory domain which is wrong 
> for most countries.
> This makes Atheros devices in master mode unusable on ACPI devices in most 
> countries.
> 
> Sven Gottschall suggested on ath10k mailing-list to return -EOPNOTSUPP in 
> function
> ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd) in file 
> drivers/net/wireless/ath/ath10k/mac.c to solve this.
> 
> 
> static int ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd)
> {
> return -EOPNOTSUPP;
> }

Was there a conclusion upstream?

Regards,
Salvatore

Bug#927401: linux-image-4.9.0-8-amd64: fails to recognize properly every time the same sound device

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Fri, Apr 19, 2019 at 04:08:11AM +0200, Julien-Benjamin wrote:
> Package: src:linux
> Version: 4.9.144-3.1
> Severity: normal
> 
> Dear Maintainer,
> 
> I am using a HiFimeDIY UAE23 USB DAC (ESS Sabre ES9023+Savitech SA9023) as 
> the default sound output. 
> 
> This device is using the driver "snd-usb-audio".
> 
> When I boot the system, it may or may not recognize the device properly, 
> leading to have no sound anymore played on this output.
> 
> I set the device as default sink, using `pacmd set-default-sink 0`, where the 
> pulseaudio index 0 is the USB DAC.
> 
> But when the machine boots with the device being in a bad state, the device 
> name, vendor id and model id values change (while the id vendor id does not). 
> 
> Unplugging and plugging it back solves the issue, because the device name, 
> vendor id and model id values change back to proper ones.
> 
> I could provide a lot of outputs messages, but I tried to provide only the 
> most relevant ones, let me know if you need more details.
> 
> Here is what `udevadm info` gives for both cases:
> 
> - Bad state:
> -
> $ udevadm info -p 
> /devices/pci:00/:00:14.0/usb3/3-3/3-3:1.1/sound/card2
> P: /devices/pci:00/:00:14.0/usb3/3-3/3-3:1.1/sound/card2
> E: DEVPATH=/devices/pci:00/:00:14.0/usb3/3-3/3-3:1.1/sound/card2
> E: ID_BUS=usb
> E: ID_FOR_SEAT=sound-pci-_00_14_0-usb-0_3_1_1
> E: ID_ID=usb-SAVITECH_Bravo-X_USB_Audio-01
> E: ID_MODEL=Bravo-X_USB_Audio
> E: ID_MODEL_ENC=Bravo-X\x20USB\x20Audio
> E: ID_MODEL_ID=9023
> E: ID_PATH=pci-:00:14.0-usb-0:3:1.1
> E: ID_PATH_TAG=pci-_00_14_0-usb-0_3_1_1
> E: ID_REVISION=0001
> E: ID_SERIAL=SAVITECH_Bravo-X_USB_Audio
> E: ID_TYPE=audio
> E: ID_USB_DRIVER=snd-usb-audio
> E: ID_USB_INTERFACES=:03:010100:010200:
> E: ID_USB_INTERFACE_NUM=01
> E: ID_VENDOR=SAVITECH
> E: ID_VENDOR_ENC=SAVITECH
> E: ID_VENDOR_ID=262a
> E: SOUND_INITIALIZED=1
> E: SUBSYSTEM=sound
> E: SYSTEMD_WANTS=sound.target
> E: TAGS=:seat:systemd:
> E: USEC_INITIALIZED=5402460
> 
> -
> 
> - Good state:
> -
> $ udevadm info -p 
> /devices/pci:00/:00:14.0/usb3/3-3/3-3:1.1/sound/card2
> P: /devices/pci:00/:00:14.0/usb3/3-3/3-3:1.1/sound/card2
> E: DEVPATH=/devices/pci:00/:00:14.0/usb3/3-3/3-3:1.1/sound/card2
> E: ID_BUS=usb
> E: ID_FOR_SEAT=sound-pci-_00_14_0-usb-0_3_1_1
> E: ID_ID=usb-HiFimeDIY_Audio_SA9023_USB_Audio-01
> E: ID_MODEL=SA9023_USB_Audio
> E: ID_MODEL_ENC=SA9023\x20USB\x20Audio
> E: ID_MODEL_ID=10e0
> E: ID_PATH=pci-:00:14.0-usb-0:3:1.1
> E: ID_PATH_TAG=pci-_00_14_0-usb-0_3_1_1
> E: ID_REVISION=0001
> E: ID_SERIAL=HiFimeDIY_Audio_SA9023_USB_Audio
> E: ID_TYPE=audio
> E: ID_USB_DRIVER=snd-usb-audio
> E: ID_USB_INTERFACES=:03:010100:010200:
> E: ID_USB_INTERFACE_NUM=01
> E: ID_VENDOR=HiFimeDIY_Audio
> E: ID_VENDOR_ENC=HiFimeDIY\x20Audio
> E: ID_VENDOR_ID=262a
> E: SOUND_INITIALIZED=1
> E: SUBSYSTEM=sound
> E: SYSTEMD_WANTS=sound.target
> E: TAGS=:seat:systemd:
> E: USEC_INITIALIZED=5429778
> -
> 
> Hope I have been clear enough, do not hesitate to ask be go further into 
> details if needed.

Can you still reproduce your issue with a current kernel from the
used series?

Regards,
Salvatore

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Alois,

On Fri, May 31, 2019 at 09:24:03PM +0200, Romain Perier wrote:
> On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote:
> > On 3/26/19 9:03 PM, Romain Perier wrote:
> > > On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:
> > >> On 3/18/19 7:46 PM, Romain Perier wrote:
> > >>> On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:
> >  On 3/18/19 12:20 PM, Romain Perier wrote:
> > > Hello,
> > >
> > > On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> > >> Source: linux
> > >> Severity: normal
> > >>
> > >> Dear Maintainer,
> > >>
> > >>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 
> > >> 10
> > >> (testing).
> > >>    After the upgrade, the touchpad and the trackpoint was not usable
> > >> anymore.
> > >>
> > >>
> > >>    This already has some bug report here,
> > >>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> > >>
> > >>    As a workaround, one can run the command,
> > >>    sudo sh -c 'echo -n "elantech">
> > >> /sys/bus/serio/devices/serio1/protocol'
> > >>    in order to use the touchpad. However, on a GUI Interface and 
> > >> without
> > >>    an external mouse, it's impossible to apply this workaround
> > >>   (switching to the terminal -F1, login, and run the 
> > >> command
> > >> above might work)
> > >>
> > >>    I expect to be able to use the touchpad just out of the box, not 
> > >> needing
> > >>    to run the above workaround
> > >>
> > > Could you :
> > >
> > > - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) 
> > > and confirm or
> > >   not is the problem still exists ?
> >  Dear Romain
> > 
> > 
> >  I upgraded the kernel and rebooted:
> > 
> >  schloegl@debian10:~$ uname -a
> >  Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
> >  x86_64 GNU/Linux
> > 
> > 
> >  With this kernel the trackpoint is working, the trackpad is still not
> >  usable.
> > 
> >  (This improves the situation because now at least one pointer device is
> >  available).
> > 
> > 
> > >>> Good, we did some progress :)
> > >>>
> > > - According to the bug on launchpad and to the fix pushed upstream, 
> > > the
> > >   fix seems to be an hardware quirks, could you give me the output of 
> > > the
> > >   following command :
> > >   $ /sys/bus/serio/devices/serio1/firmware_id
> >  root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
> >  PNP: LEN2036 PNP0f13
> > 
> > >>> Could you test the patch attached to this reply ?
> > >>> (if you don't know how to do this, I can provide support)
> > >>>
> > >>> Regards,
> > >>> Romain
> > >>
> > >>
> > >> I tried to followed these instructions:
> > >>
> > >> https://kernel-team.pages.debian.net/kernel-handbook/ch-comm
> > >>
> > >> 4.5. Building a custom kernel from Debian kernel source
> > >>
> > >> Specifically using the patched the sources,
> > >>
> > >> *scripts/config --disable MODULE_SIG*
> > >> **scripts/config --disable DEBUG_INFO**
> > >> ||*|make clean|* ||*|make deb-pkg
> > >>
> > >> |*
> > >>
> > >> and ended up with a kernel that does not boot (missing HD audio 
> > >> firmware),
> > >>
> > >>
> > >> Which procedure do you recommend to build and install a modified kernel ?
> > >>
> > >>
> > > Hi,
> > >
> > > Section 4.2 from
> > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
> > > , until test-patches should work. For the test-patches script, use the 
> > > flavour and a
> > > featureset as argument, when you invoke it, like this :
> > >
> > > # debian/bin/test-patches -f amd64 -s none 
> > > /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch
> > >
> > > This will apply the patch on the fly, configure the kernel for amd64
> > > and build a version with a special changelog entry and a special suffix
> > > version dedicated to the test version you generate.
> > >
> > >
> > > In case of troubles, I can provide another way, from git with few
> > > commands.
> > >
> > >
> > > Hope this helps,
> > > Regards,
> > > Romain
> > 
> > 
> > Dear Romain,
> > 
> > 
> > your instructions to build the kernel worked fine, when trying to
> > install the kernel,
> > 
> >    sudo dpkg -i linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb 
> > linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb
> > 
> > I run into problem, getting this warning. 
> > 
> > 
> >  │ You are running a kernel (version 4.19.0-5-amd64) and attempting to
> > remove the same
> > version.
> >    
> > │
> >  │  
> >  

Bug#848945: #848945 Empty rpool leaves ZFS systems unbootable

[Etienne Dechamps]

By the way, for those who don't like patching packaged files, here's a
workaround for manually overriding the root= parameter from
/etc/default/grub:

GRUB_FS=manual
GRUB_DISABLE_LINUX_UUID=true
GRUB_DEVICE=ZFS=yourpoolname/path/to/your/root/dataset

Bug#923988: /boot/vmlinuz-4.19.0-2-arm64: dmidecode causes kernel panic (puma-rk3399)

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Thu, Mar 07, 2019 at 04:29:14PM -0800, Vagrant Cascadian wrote:
> Package: src:linux
> Version: 4.19.16-1
> Severity: normal
> File: /boot/vmlinuz-4.19.0-2-arm64
> X-Debbugs-Cc: klaus.go...@theobroma-systems.com
> 
> When running dmidecode as root on puma-rk3399, it consistantly causes a
> kernel panic.
> 
> Other similar rockchip rk3399 boards do not seem to have this
> problem. All older (maybe 4.16-4.18) and newer (v4.20) kernels I've
> tried seem to be affected.

Is this something you can still reproduce with current kernel?

Regards,
Salvatore

Bug#988686: pre-approval: spamassassin/3.4.6-1

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-05-17 13:48:52 -0700, Noah Meyerhans wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> We briefly discussed spamassassin 3.4.6-1 as a new upstream release for
> bullseye in #987022.  To quote the original request:
> 
> > If it was completely up to me, I'd want 3.4.6-1 released with bullseye.
> > It will be better supported by upstream and contains all the relevant
> > bug fixes.  IMO it's less likely to introduce any new regressions than a
> > 3.4.5-pre1-4 with relevant changes pulled back from upstream's svn.
> > However, it's late in the freeze and I fully understand the policy wrt
> > to new upstream releases.
> 
> At the time, we decided to go with 3.4.5~pre4-4, and consider 3.4.6-1
> afterward.  At this point, 3.4.5-pre1-4 is in bullseye, and it has an
> RC bug related to service management under sysvinit (or is sysvinit
> not RC, by definition?), so an another is needed.  The fix involves
> deleting some code from postinst that was always intended to go away
> before bullseye, and is part of a transition to a sane approach to
> spamd service management.
> 
> 3.4.5~pre4-5 is prepared as a minimal fix to 3.4.1~pre4-4.
> 
> As I stated previously, I'd much prefer to support 3.4.6-1 for the
> course of bullseye's lifetime.  So my preference would be to upload
> 3.4.6-1 to unstable and get it into bullseye.  3.4.5~pre1-4
> incorporates quite a few changes (13) from 3.4.6 in the form of debian
> patches adapted from cherry-picked upstream commits, so we'd get to
> drop all of those.  Most of the rest of the changes in the debdiff are
> related to the rulesets, which are updated nightly upstream and
> commonly refreshed on a similar schedule on deployed systems via the
> sa-update facility, or release administrivia and housekeeping (svn
> branch management, updating the Apache logo, updating version strings,
> spelling corrections, etc).
> 
> The 3.4.6-1 debdiff is at
> https://people.debian.org/~noahm/spamassassin_3.4.6-1.debdiff

Assuming that the upload happens soon, please go ahead with 3.4.6-1
together with the fix for #947086. Please remove the moreinfo tag once
the new version is available in unstable.

Cheers

> 
> The 3.4.5~pre1-5 debdiff is at
> https://people.debian.org/~noahm/spamassassin_3.4.5~pre1-5.debdiff
> 
> I haven't uploaded either to unstable yet.
> 
> Thanks
> noah
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#848945: #848945 Empty rpool leaves ZFS systems unbootable

[Etienne Dechamps]

Control: found -1 2.04-18

I just hit this bug. It rendered my system unbootable because my root
ZFS pool has the new zstd compression feature enabled, and it looks
like grub-probe choked on that.

There are two things that I found highly frustrating here:

- While my root (/) is on ZFS, my /boot is not, precisely to try to
avoid issues like these. In this setup GRUB doesn't need to be able to
read the zpool - all that matters is the name of the pool, which can
be trivially determined without the need for any kind of subtle
low-level probing. It seems like as long as the
bootloader/kernel/initrd itself is not stored on ZFS, GRUB should Just
Work regardless of the low-level zpool details (such as zpool
features). That is not presently the case because /etc/grub.d/10_linux
insists on using grub-probe and grub-probe insists on using its own
custom low-level ZFS read code just to figure out the name of the
zpool. That's just... silly.

- The error handling here is appalling. In my case update-grub
(grub-mkconfig) *did not even display a single error message*. The
"unknown filesystem" error from grub-probe is being swallowed somehow,
and /etc/grub.d/10_linux doesn't check that the returned `rpool` looks
valid. update-grub will happily generate an obviously garbage,
unbootable config with a syntactically invalid root=ZFS= kernel
parameter and everything will look fine at first... until you try to
reboot! At the very least an error message should be displayed;
ideally update-grub should refuse to generate a new config altogether,
to avoid replacing a working config with a broken one.

By the way, here are steps to reproduce to make grub-probe choke on a
ZFS pool with zstd enabled:

# dd if=/dev/zero of=/tmp/pool bs=1 count=1 seek=$((128*1024*1024))
# zpool create testpool /tmp/pool
# zfs set compression=zstd testpool
# /usr/sbin/grub-probe --device /tmp/pool --target=fs_label
/usr/sbin/grub-probe: error: unknown filesystem.

If the "zfs set compression" step is omitted, grub-probe works. Tested
with zfs 2.0.3-8.

Bug#989224: puppet: Cron Provider breaks on crontab with certain environment variables (easy DOS for a user)

[Joerg Jaspert]

Source: puppet
Severity: important

Dear Maintainer,

puppets cron provider contains a bug that allows any local user to 
easily turn off the puppet service.


A crontab that contains an environment variable with a - breaks puppet. 
Change - to _ and it works.
Yes, POSIX does not allow that, sure, but users can be stupid, software 
should deal with it.


Test:
Create a crontab like

MAILTO=t...@example.com
CONSOLE-LOG=/var/log/file

*/15 * * * * /bin/bash -c "echo test"

And puppet goes boom, it couldn't parse the line, followed by a stack 
trace and out it is.

Now change the - to _ and voila, puppet does not go boom.

I personally had this on puppet6, but had a DSA member try on their 
machines, the bug exists on puppet5 buster and bullseye too.


Upstream does not care, see 
https://tickets.puppetlabs.com/browse/PUP-10998 if you want, but I think 
it would be nice if we do not ship such a bug in Debian.


--
bye, Joerg

Bug#986709: rsnapshot: not suitable for stable release

[Gionatan Danti]

Hi all,
for what it is worth, I am against removing rsnapshot from Debian. While 
it is not actively developed anymore, it is stable software and as far I 
know it has no know vulnerabilities (being a wrapper around rsync).


borg (or duplicity) is not an equivalent solution, and I really like to 
continue using rsnapshot as-is on Debian (and other distro).


Thanks.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8

Bug#977767: opendmarc: CVE-2020-12272

[Moritz Muehlenhoff]

On Sat, May 29, 2021 at 10:43:21AM +0200, David Bürgin wrote:
> > This appears to have been fixed in
> > https://github.com/trusteddomainproject/OpenDMARC/commit/f3a9a9d4edfaa05102292727d021683f58aa4b6e,
> > could we get that in Bullseye?
> 
> This isn’t the only commit for CVE-2020-12272.

Thanks, can you please provide the additional commits needed that so we can 
update
the Debian Security Tracker?

> I have been preparing OpenDMARC 1.4.1.1 for bookworm in Salsa. I’m also
> preparing patches for all open CVEs for bullseye. Unless Scott wants to
> push this forward faster, I expect the patches to be in the first
> security update or so.

Better let's push these to bullseye before it gets released, then. Security
fixes are perfectly fine during the current freeze still.

Cheers,
Moritz

Bug#989217: Enable and ship Java bindings via libturbojpeg-java (patch)

[Mike Gabriel]

Hi Daniel,

big thanks for the contribution.

On  Sa 29 Mai 2021 02:15:32 CEST, Daniel Leidert wrote:


Source: libjpeg-turbo
Version: 1:2.0.6-4
Severity: wishlist
Tags: patch
I was recently asked to repackage libjpeg-turbo to ship the Java bindings
required by Cantaloupe. It is fairly easy and others might benefit from this
too. Attached is the patch I applied. Please note that I downgraded
debhelper-compat because it was necessary to rebuild for Buster.

https://salsa.debian.org/dleidert/libjpeg-turbo/-/tree/buster

Regards, Daniel


It is now on my list for bullseye+1 (aka the bookwork (Debian 12)  
release cycle).


If this will be stalling for too long, feel free to send a gentle  
reminder after the Debian 11 release.


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



pgpUWV8zKAjQM.pgp
Description: Digitale PGP-Signatur

Bug#989223: vim: unavailable URL in README.Debian

[Reiner Herrmann]

Source: vim
Version: 2:8.2.2434-3

Dear maintainer,

README.Debian contains a link to 
http://pkg-vim.alioth.debian.org/vim-policy.html/
which is no longer available (does not resolve).
Please update it with its new location.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#982761: torbrowser-launcher: I can't start Tor Browser

[Roger Shimizu]

control: tags -1 +moreinfo +unreproducible

On Sun, Feb 14, 2021 at 9:51 AM Debian Live user  wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.3-3~bpo10+1
> Severity: important
>
> Dear Maintainer,
>
> I can't start Tor Browser. After clicking the icon, nothing happens.
> I am using Debian Live. I installed it with torbrowser-launcher from 
> backports.
> For me it looks like it is problem with AppArmor. Here are logs from dmesg. 
> http://paste.debian.net/hidden/d4c44566/

Thanks for your report!
I checked the log above, but I never see such apparmor errors and
cannot reproduce locally.
So please kindly provide more information.

Maybe you can remove local cache of tbb and try again?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#989222: darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files

[Jonas Smedegaard]

Package: darktable
Version: 3.4.1-3
Severity: important
Tags: upstream patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Loading some DNG files causes darktable to crash after 30 seconds,
seemingly tied to generating thunbnail for the image.
Every start of darktable after that crash will crash similarly, until
~/.config/darktable is removed.

Upstream tracked and has solved this issue at
https://github.com/darktable-org/darktable/issues/8951

At upstream issue tracking is mentioned that the file they used as proof
was arguably broken.

I experienced the issue (confirmed to be the same: Applying upstream
patch makes the program not crash and instead generate a thumbnail in
roughly same time: 30 seconds) with DNG files generated by megapixels
in the Librem 5 phone, and one of the phone developer told me that those
DNG files comply with the specification.  I can provide samples if
needed.

Kind regards,

 - Jonas



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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.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 darktable depends on:
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libcolord-gtk1   0.1.26-2
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3
ii  libcurl3-gnutls  7.74.0-1.2
ii  libexiv2-27  0.27.3-3
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgomp1 10.2.1-6
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.36+hg16481-1
ii  libgtk-3-0   3.24.24-4
ii  libilmbase25 2.5.4-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjson-glib-1.0-0   1.6.2-1
ii  liblcms2-2   2.12~rc1-2
ii  liblensfun1  0.3.2-6
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libopenexr25 2.5.4-2
ii  libopenjp2-7 2.4.0-3
ii  libosmgpsmap-1.0-1   1.2.0-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpugixml1v51.11.4-1
ii  librsvg2-2   2.50.3+dfsg-1
ii  libsecret-1-00.20.4-2
ii  libsoup2.4-1 2.72.0-2
ii  libsqlite3-0 3.34.1-3
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1
ii  libwebp6 0.6.1-2+b1
ii  libx11-6 2:1.7.1-1
ii  libxml2  2.9.10+dfsg-6.7
ii  libxrandr2   2:1.5.1-1
ii  zlib1g   1:1.2.11.dfsg-2

darktable recommends no packages.

darktable suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmCyEJMACgkQLHwxRsGg
ASHtvw//b+TcJeGc7Ef4o+DqUhBl4pkJ5IsjG3cZq3KgEEN0tkACWgYrnr/b2wlh
I4nIQeFjjVpO5m/YjhxyIZlMtDCfESxK7/7zbJVtJyNESkZLbnjzDXX7J5pvXuc1
9GvMrIM5LMdqDzzJDELzKSKc0va9q1PeDvfJ5FyGysiVll8pLjRer5QE5rHlAKUA
XdYwMKHki9j0lguFmcQJX/o0Yzr+YgDuNUo3eYHfv7BsocVFIoy7WxTChQnveAqV
Q7iyMiyqipTCp/8rg59cG0GmQLivkQM9Wy3BhaTYMZGPIwD4jHf90nQXTZB9xeg4
f6nrXYyG9hsTHp7SvT4g3UxKTrXW4akNOwVFwKgyiOK+V8JConOW/0QyDAw85kcf
YrAiTvOdSyH3EeShU3No5niWbLChVXLtEEey84j9wFBSfgFB0m6wUbZnn9ZKWopQ
sfKqXwzMvixCKA/mJC3xeJf/PSg54AvyNZlIm1bdSyIK7X2szym8SoQ0mqjMr0Mh
lYNs11HT2BAeHZKATx18iHK3GMM7ircPZt8FG6FwGeYr3R+QQNwKYHEdQMDyG1Oh
maVB+HmgqXq/YYx9lZEYU+IjI7OwJjoFpnN3k5+/RKCOz1LYnlE24IuU5KnyL6h0
RqMHCXXVyVOuM9o29LAiv1DUj8OLXb2dkgwpPZW8bYprYhQGicg=
=hTfl
-END PGP SIGNATURE-

Bug#923272: linux: 50 s delay during boot [m68k, atari, ARAnyM]

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Mon, Feb 25, 2019 at 05:20:49PM +, Thorsten Glaser wrote:
> Package: src:linux
> Version: 4.19.20-1
> Severity: normal
> 
> linux-image-4.19.0-3-m68k takes massively longer to boot
> than linux-image-4.1.0-2-m68k did (on an ARAnyM VM Atari
> using NatFeat network/disc/…):
[...]

Is this still valid bug for a recent kernel version? If so can you
bring the issue upstream (feel free to keep the bug into the loop).

Regards,
Salvatore

Bug#922274: thinkpad_acpi: Error probing battery 2 (Lenovo Thinkpad Yoga 11e)

[Salvatore Bonaccorso]

Source: linux
Source-Version: 5.9.15-1

fixed 922274 4.19.171-1
thanks

On Thu, Feb 14, 2019 at 02:56:36AM +0100, Daniel Leidert wrote:
> Package: src:linux
> Version: 4.19.20-1
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Since some time I get these error messages during startup (however, the system
> starts without any issue):
> 
> [   31.210320] ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as 
> error
> [   31.210325] thinkpad_acpi: Error probing battery 2
> [   31.210462] battery: error in extension, unloading: ThinkPad Battery 
> Extension
> [   31.210468] battery: extension unregistered: ThinkPad Battery Extension
> [   31.210545] battery: ACPI: Battery Slot [BAT1] (battery present)
> 
> Searching for this issue I found these resources:
> 
> https://patchwork.kernel.org/patch/10552407/
> https://bbs.archlinux.org/viewtopic.php?id=238170
> 
> I haven't checked, if the suggested patch has already been accepted into
> the kernel. If yes, my model is probably missing. So maybe this information
> helps, to fix the kernel to fix the issue on my system too:
> 
> [   29.593658] thinkpad_acpi: ThinkPad ACPI Extras v0.26
> [   29.593661] thinkpad_acpi: http://ibm-acpi.sf.net/
> [   29.593663] thinkpad_acpi: ThinkPad BIOS N15ET75W (1.35), EC unknown
> [   29.593664] thinkpad_acpi: Lenovo ThinkPad Yoga 11e, model 20DA001CUK
> [   29.625754] thinkpad_acpi: radio switch found; radios are enabled
> [   29.629774] thinkpad_acpi: Tablet mode switch found (type: GMMS), 
> currently in laptop mode
> [   29.630080] thinkpad_acpi: This ThinkPad has standard ACPI backlight 
> brightness control, supported by the ACPI video driver
> [   29.630082] thinkpad_acpi: Disabling thinkpad-acpi brightness events by 
> default...
> [   29.640950] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is 
> unblocked
> [   29.641331] thinkpad_acpi: Standard ACPI backlight interface available, 
> not loading native one
> [   29.641473] thinkpad_acpi: Console audio control enabled, mode: monitor 
> (read only)
> [   29.680689] input: ThinkPad Extra Buttons as 
> /devices/platform/thinkpad_acpi/input/input10
> [   31.210325] thinkpad_acpi: Error probing battery 2
> 
> If I can provide useful input to fix the situation, please let me know.

This should be fixed with c986a7024916 ("platform/x86: thinkpad_acpi:
Add BAT1 is primary battery quirk for Thinkpad Yoga 11e 4th gen")
which landed in 5.10-c6, backproted to 5.9.15 and as well 4.19.164.

(Closing the bug, but can you confirm this is true and thest with a
recent kernel, and if the bug closure was false, plese reopen)?

Regards,
Salvatore

Bug#988997: [Pkg-privacy-maintainers] Bug#988997: Signature verification failed, key expired

[Roger Shimizu]

control: severity -1 wishlist

On Sun, May 23, 2021 at 3:57 AM Mikko Viinamäki
 wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.2-14~bpo9+1

Thanks for your report!

Just FYI.
For stretch, I uploaded 0.3.3-3~bpo9+1 long time ago, and it's still
in the policy NEW queue [1].
So not much I can do as pkg maintainer.

[1] https://ftp-master.debian.org/backports-new.html

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#921223: linux-image-4.9.0-8-amd64: Booting from hibernated state sometimes hangs

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sun, Feb 03, 2019 at 11:29:08AM +0100, Timothy Hobbs wrote:
> Package: src:linux
> 
> Version: 4.9.130-2
> Severity: important
> 
> Dear Maintainer,
> 
> When hibernated after using the command $ sudo systemctl hibernate
> Sometimes (about 1 in 10 boots) the computer hangs with a black
> screen. It appears that USB devices do not initialize (mouse does
> not light up). Today, the screen showed a kernel oops. I neglected
> to check if the mouse had lit up, but did take a photo of the
> screen. You can see a photo of the oops here:
> 
> http://timothy.hobbs.cz/kernel-oops-1-2019-home-tower.jpg
> 
> After rebooting from hung state, hibernated session is lost.
> 
> The computer runs fine other than this hibernation restore problem.
> Restoring from suspend does not work as the graphics card behaves
> strangely upon restoring. There are also occasional graphics glitches
> but only when using certain 3D OpenGL applications.

Assuming you are still unsing stretch on that host: Can you still
reproduce the issue with a recent 4.9.y kernel? if you switched to
buster and up, are you still able to reproduce the issue with a recent
kernel instead?

if it is not anymore reproducible, we can go ahead and close the bug
otherwise.

Regards,
Salvatore

Bug#920177: linux-image-4.19.0-2-rt-amd64-unsigned: BUG while removing the sunrpc module

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Tue, Jan 22, 2019 at 12:20:38PM +0100, Laurent Bonnaud wrote:
> Subject: linux-image-4.19.0-2-rt-amd64-unsigned: BUG
> Package: src:linux
> Version: 4.19.16-1
> Severity: normal
> 
> 
> Dear Maintainer,
> 
> I was trying to remove the sunrpc module from the kernel and got the 
> following BUG and backtrace.
> 
> Note that the kernel is tainted because of this previous error that is 
> unrelated:
> 
> [1.514708] button: module verification failed: signature and/or required 
> key missing - tainting kernel
> 
> [  204.858131] RPC: Unregistered named UNIX socket transport module.
> [  204.858134] RPC: Unregistered udp transport module.
> [  204.858136] RPC: Unregistered tcp transport module.
> [  204.858137] RPC: Unregistered tcp NFSv4.1 backchannel transport module.
> [  204.859248] 
> =
> [  204.859251] BUG rpc_inode_cache (Tainted: GE): Objects 
> remaining in rpc_inode_cache on __kmem_cache_shutdown()   
>   
> [  204.859251] 
> -
> 
> [  204.859252] Disabling lock debugging due to kernel taint
> [  204.859255] INFO: Slab 0x006c197c objects=18 used=13 
> fp=0xa584567e flags=0x17fffc08100
> [  204.859259] CPU: 0 PID: 3633 Comm: rmmod Tainted: GB   E 
> 4.19.0-2-rt-amd64 #1 Debian 4.19.16-1
> [  204.859260] Hardware name: Dell Inc. OptiPlex 7010/0KRC95, BIOS A29 
> 06/28/2018
> [  204.859261] Call Trace:
> [  204.859269]  dump_stack+0x5c/0x80
> [  204.859273]  slab_err+0xb0/0xd4
> [  204.859277]  ? cpumask_next+0x16/0x20
> [  204.859279]  ? flush_all+0x66/0x100
> [  204.859282]  __kmem_cache_shutdown.cold.103+0x1c/0x26
> [  204.859287]  shutdown_cache+0x15/0x1c0
> [  204.859290]  kmem_cache_destroy+0x216/0x240
> [  204.859316]  unregister_rpc_pipefs+0x16/0x30 [sunrpc]
> [  204.859334]  cleanup_sunrpc+0x1e/0x39 [sunrpc]
> [  204.859337]  __x64_sys_delete_module+0x190/0x2c0
> [  204.859341]  do_syscall_64+0x53/0x100
> [  204.859346]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  204.859349] RIP: 0033:0x7f43fb8a00f7
> [  204.859351] Code: 73 01 c3 48 8b 0d 99 0d 0c 00 f7 d8 64 89 01 48 83 c8 ff 
> c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 
> 01 f0 ff ff 73 01 c3 48 8b 0d 69 0d 0c 00 f7 d8 64 89 01 48
> [  204.859354] RSP: 002b:7ffc4236d208 EFLAGS: 0206 ORIG_RAX: 
> 00b0
> [  204.859356] RAX: ffda RBX: 55a14f7eb220 RCX: 
> 7f43fb8a00f7
> [  204.859357] RDX: 000a RSI: 0800 RDI: 
> 55a14f7eb288
> [  204.859358] RBP:  R08: 7ffc4236c181 R09: 
> 
> [  204.859359] R10: 7f43fb911ae0 R11: 0206 R12: 
> 7ffc4236d430
> [  204.859360] R13: 7ffc4236ec4b R14: 55a14f7ea010 R15: 
> 55a14f7eb220
> [  204.859363] kmem_cache_destroy rpc_inode_cache: Slab cache still has 
> objects
> [  204.859621] CPU: 0 PID: 3633 Comm: rmmod Tainted: GB   E 
> 4.19.0-2-rt-amd64 #1 Debian 4.19.16-1
> [  204.859622] Hardware name: Dell Inc. OptiPlex 7010/0KRC95, BIOS A29 
> 06/28/2018
> [  204.859623] Call Trace:
> [  204.859626]  dump_stack+0x5c/0x80
> [  204.859629]  kmem_cache_destroy+0x233/0x240
> [  204.859647]  unregister_rpc_pipefs+0x16/0x30 [sunrpc]
> [  204.859664]  cleanup_sunrpc+0x1e/0x39 [sunrpc]
> [  204.859666]  __x64_sys_delete_module+0x190/0x2c0
> [  204.859670]  do_syscall_64+0x53/0x100
> [  204.859673]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  204.859675] RIP: 0033:0x7f43fb8a00f7
> [  204.859677] Code: 73 01 c3 48 8b 0d 99 0d 0c 00 f7 d8 64 89 01 48 83 c8 ff 
> c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 
> 01 f0 ff ff 73 01 c3 48 8b 0d 69 0d 0c 00 f7 d8 64 89 01 48
> [  204.859678] RSP: 002b:7ffc4236d208 EFLAGS: 0206 ORIG_RAX: 
> 00b0
> [  204.859679] RAX: ffda RBX: 55a14f7eb220 RCX: 
> 7f43fb8a00f7
> [  204.859680] RDX: 000a RSI: 0800 RDI: 
> 55a14f7eb288
> [  204.859681] RBP:  R08: 7ffc4236c181 R09: 
> 
> [  204.859682] R10: 7f43fb911ae0 R11: 0206 R12: 
> 7ffc4236d430
> [  204.859683] R13: 7ffc4236ec4b R14: 55a14f7ea010 R15: 
> 55a14f7eb220

This was not while trying to force unload and sunrpc was really not
anymore in use?

Recently there was a fix for f1442d6349a2 ("sunrpc: fix refcount leak for rpc 
auth modules")
https://lore.kernel.org/linux-nfs/3f1b347f-b809-478f-a1e9-0be98e22b...@oracle.com/T/#t

That fix from 5.12-rc4 went into 4.19.183 (not yet available for
buster, but working on) and 5.10.26.

Can you reproduce the issue using 5.10.40-1 from unstable?

Regards,
Salvatore

Bug#919350: hyperv-daemons: hv_get_dhcp_info, hv_get_dns_info not found

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Tue, Jan 15, 2019 at 11:02:36AM +0300, Сергей Олегович wrote:
> Package: hyperv-daemons
> Version: 4.9.130-2
> 
> Hello. I'm using Hyper-V for Virtual Machine and install Debian.
> Installed hyperv-daemons and i see in syslog very much message:
> Jan 15 08:07:59 gateway hv_kvp_daemon[1056]: sh: 1: hv_get_dhcp_info: not
> found
> Jan 15 08:07:59 gateway hv_kvp_daemon[1056]: sh: 1: hv_get_dns_info: not
> found
> 
> # systemctl status hyperv-daemons.hv-kvp-daemon
> hyperv-daemons.hv-vss-daemon hyperv-daemons.hv-fcopy-daemon
> ● hyperv-daemons.hv-kvp-daemon.service - Hyper-V key-value pair (KVP) daemon
>Loaded: loaded
> (/lib/systemd/system/hyperv-daemons.hv-kvp-daemon.service; enabled; vendor
> preset: enabled)
>Active: active (running) since Mon 2019-01-14 09:17:04 MSK; 1 day 1h ago
>  Main PID: 542 (hv_kvp_daemon)
> Tasks: 1 (limit: 9830)
>CGroup: /system.slice/hyperv-daemons.hv-kvp-daemon.service
>└─542 /usr/sbin/hv_kvp_daemon -n
> 
> Jan 15 10:58:49 gw hv_kvp_daemon[542]: sh: 1: hv_get_dns_info: not found
> Jan 15 10:58:49 gw hv_kvp_daemon[542]: sh: 1: hv_get_dhcp_info: not found
> ...
> 
> ● hyperv-daemons.hv-vss-daemon.service - Hyper-V volume shadow copy service
> (VSS) daemon
>Loaded: loaded
> (/lib/systemd/system/hyperv-daemons.hv-vss-daemon.service; enabled; vendor
> preset: enabled)
>Active: active (running) since Mon 2019-01-14 09:17:03 MSK; 1 day 1h ago
>  Main PID: 509 (hv_vss_daemon)
> Tasks: 1 (limit: 9830)
>CGroup: /system.slice/hyperv-daemons.hv-vss-daemon.service
>└─509 /usr/sbin/hv_vss_daemon -n
> 
> Jan 15 09:49:04 gw hv_vss_daemon[509]: Hyper-V VSS: VSS: op=CHECK HOT BACKUP
> ...
> 
> ● hyperv-daemons.hv-fcopy-daemon.service - Hyper-V file copy service
> (FCOPY) daemon
>Loaded: loaded
> (/lib/systemd/system/hyperv-daemons.hv-fcopy-daemon.service; enabled;
> vendor preset: enabled)
>Active: inactive (dead)
> Condition: start condition failed at Mon 2019-01-14 09:17:04 MSK; 1 day 1h
> ago
>└─ ConditionPathExists=/dev/vmbus/hv_fcopy was not met

This issue reminds me of #796882. Is this issue still really
reproducible with recent versions. The services provided in the
packages were as well renamed a while back.

This was in 5.8.3-1~exp1.

Regards,
Salvatore

Bug#918042: WoL does not work on r8169 (regression since 4.18)

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Wed, Jan 02, 2019 at 07:02:42PM +0100, Marc Haber wrote:
> Package: src:linux
> Version: 4.20-1~exp1
> Severity: normal
> 
> Hi,
> 
> I frequently send my desktop PC to sleep (suspend-to-ram) and wake it up
> from remote when I need to access it. To do so, I use a script on a
> banana pi which ends up calling etherwake 54:04:a6:82:21:00. This
> has worked reliably up to the last 4.18 release, including the Debian
> kernel linux-image-4.18.0-3-amd64 version 4.18.20-2.
> 
> In 4.19, this ceased to work and has remained that way up to the kernel
> I am reporting this issue on, linux-image-4.20.0-trunk-amd64 version
> 4.20-1~exp1. I have observed this behavior also on my "own", locally
> built kernels of various 4.19 releases and also 4.20. Sorry, I didn't
> try any Debian 4.19 kernels, I decided to pursue this issue further
> after the regression was also present in 4.20.
> 
> I am prepared to try kernel patches or follow other hints in debugging
> this. I acknowledge that this is most probably an upstream issue, but I
> don't have enough kernel foo to investigate this on an upstream level
> (and frankly, I am afraid of doing a bisect between 4.18 and 4.19).
> 
> Any hints will be appreciated.

Marc, ist this still something you can reproduce with a recent kernel?

Regards,
Salvatore

Bug#977767: opendmarc: CVE-2020-12272

[David Bürgin]

This appears to have been fixed in
https://github.com/trusteddomainproject/OpenDMARC/commit/f3a9a9d4edfaa05102292727d021683f58aa4b6e,
could we get that in Bullseye?


This isn’t the only commit for CVE-2020-12272.

I have been preparing OpenDMARC 1.4.1.1 for bookworm in Salsa. I’m also
preparing patches for all open CVEs for bullseye. Unless Scott wants to
push this forward faster, I expect the patches to be in the first
security update or so.

Bug#989220: Output of gdb; please reclassify its severity.

[Zuluaga, Juan P]

Bug seems related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887978, 
except that the message is a bit different

cannot load settings: Resource temporarily unavailable
malloc(): invalid size (unsorted)
Aborted

instead of

cannot load settings: Resource temporarily unavailable
  malloc(): memory corruption
  Aborted

Output of gdb follows:
(gdb) run
Starting program: /usr/bin/solvespace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
cannot load settings: Resource temporarily unavailable
[New Thread 0xaf702b40 (LWP 20199)]
malloc(): invalid size (unsorted)

Thread 1 "solvespace" received signal SIGABRT, Aborted.
0xb7fd4d61 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fd4d61 in __kernel_vsyscall ()
#1  0xb6c23382 in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb6c0d2b6 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0xb6c64d2c in ?? () from /lib/i386-linux-gnu/libc.so.6
#4  0xb6c6baed in ?? () from /lib/i386-linux-gnu/libc.so.6
#5  0xb6c6e80b in ?? () from /lib/i386-linux-gnu/libc.so.6
#6  0xb6c70c34 in calloc () from /lib/i386-linux-gnu/libc.so.6
#7  0xb312b867 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#8  0xb2ec0ea9 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#9  0xb3445465 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#10 0xb3442e0f in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#11 0xb339fea7 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#12 0xb329843e in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#13 0xb3297e57 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#14 0xb334477f in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
#15 0x004df59f in SolveSpace::ssglLineWidth (width=) at 
./src/glhelper.cpp:97
#16 0x004b2dc1 in SolveSpace::Entity::Draw (this=0xbd8b20, drawAsHidden=false)
at ./src/drawentity.cpp:117
#17 0x004b2ece in SolveSpace::Entity::DrawAll (drawAsHidden=false) at 
./src/drawentity.cpp:103
#18 0x0049d4d5 in SolveSpace::GraphicsWindow::Paint (this=) at 
./src/draw.cpp:724
#19 0x0048470e in SolveSpace::GraphicsWidget::on_gl_draw (this=0xb4a180) at 
./src/gtk/gtkmain.cpp:524
#20 0x00486f4f in SolveSpace::GlWidget::on_draw (cr=..., this=0xb4a180) at 
./src/gtk/gtkmain.cpp:334
#21 SolveSpace::GlWidget::on_expose_event (this=) at 
./src/gtk/gtkmain.cpp:350
#22 0xb7c8f579 in Gtk::Widget_Class::expose_event_callback(_GtkWidget*, 
_GdkEventExpose*) ()
   from /lib/i386-linux-gnu/libgtkmm-2.4.so.1
#23 0xb76396e7 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#24 0xb7274128 in g_closure_invoke () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#25 0xb72873ed in ?? () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#26 0xb7290961 in g_signal_emit_valist () from 
/lib/i386-linux-gnu/libgobject-2.0.so.0
#27 0xb7291425 in g_signal_emit () from /lib/i386-linux-gnu/libgobject-2.0.so.0
#28 0xb775b4d4 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#29 0xb7637b71 in gtk_main_do_event () from 
/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#30 0xb74400ca in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#31 0xb7440077 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#32 0xb7470f0c in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#33 0xb743c6d4 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#34 0xb743d052 in gdk_window_process_all_updates () from 
/lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#35 0xb75b8cc3 in ?? () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#36 0xb741a8c5 in ?? () from /lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#37 0xb68a2e65 in g_main_context_dispatch () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
#38 0xb68a3269 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#39 0xb68a3609 in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#40 0xb7636675 in gtk_main () from /lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#41 0xb7c1ec8e in Gtk::Main::run(Gtk::Window&) () from 
/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#42 0x004624bf in main (argc=, argv=)
at /usr/include/c++/8/bits/unique_ptr.h:342
(gdb) quit

---
Please reclassify the severity of bug: it prevents me to use the program 
itself, but as far as I can see, it does not affect other parts of the system.

Bug#989220: solvespace: crashes when starting on Debian stable.

[Juan Zuluaga]

Package: solvespace
Version: 2.3+repack1-3+b1
Severity: normal
Tags: a11y

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
 Starting the program from gui menu produced a flash on screen but
 nothing else. Then I started the program from command line, and error
 message appeared.  Starting program as 
 > solvespace --help
 starts showing some graphs, but when I try to interact, program
 crashes.

* What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-16-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages solvespace depends on:
ii  libatkmm-1.6-1v52.28.0-2
ii  libc6   2.28-10
ii  libcairomm-1.0-1v5  1.12.2-4
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.1.0-1
ii  libglew2.1  2.1.0-4
ii  libglib2.0-02.58.3-2+deb10u2
ii  libglibmm-2.4-1v5   2.58.0-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libgtk2.0-0 2.24.32-3
ii  libgtkmm-2.4-1v51:2.24.5-4
ii  libjson-c3  0.12.1+ds-2+deb10u1
ii  libpangomm-1.4-1v5  2.42.0-2
ii  libpng16-16 1.6.36-6
ii  libsigc++-2.0-0v5   2.10.1-2
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

solvespace recommends no packages.

solvespace suggests no packages.

-- no debconf information

Bug#989221: lvm2: Missing kernel modules for Cache LVs and RAID1 LVs with DM integrity in initrd

[Jakob Meng]

Package: lvm2
Version: 2.03.11-2.1
Severity: normal
Tags: patch

To activate Cache LVs or RAID1 LVs with DM integrity on system
boot it is required to add additional kernel modules to the
initial ramdisk. If those modules are not present during boot,
LVs will not be activated and LVM's initrd scripts indicate
this in syslog with messages such as:

  lvm[***]:   pvscan[***] VG *** skip autoactivation.

Please find the attached patch which adds those missing modules
to the initrd. Instead of adding a dozen of modules precautionary
maybe it should be documented somewhere that modules have to
be added to /etc/initramfs-tools/modules in case of strange
autoactivation issues? Or maybe I am missing something and it is
documented already?

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 lvm2 depends on:
ii  dmeventd  2:1.02.175-2.1
ii  dmsetup   2:1.02.175-2.1
ii  init-system-helpers   1.60
ii  libaio1   0.3.112-9
ii  libblkid1 2.36.1-7
ii  libc6 2.31-12
ii  libdevmapper-event1.02.1  2:1.02.175-2.1
ii  libedit2  3.1-20191231-2+b1
ii  libselinux1   3.1-3
ii  libsystemd0   247.3-5
ii  libudev1  247.3-5
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.9.0-1

lvm2 suggests no packages.

-- no debconf information
>From 1f1a595dcee4a421ac2aba38bd6de9fdb33ec151 Mon Sep 17 00:00:00 2001
From: Jakob Meng 
Date: Sat, 29 May 2021 09:05:01 +0200
Subject: [PATCH] Added modules for Cache and DM integrity LVs to initrd

To activate Cache LVs and RAID1 LVs with DM integrity on system boot it
is required to add additional kernel modules to the initial ramdisk. If
those modules are not present during boot, LVs will not be activated and
LVM's initrd scripts indicate this in syslog with messages such as:
 lvm[***]:   pvscan[***] VG *** skip autoactivation.
---
 debian/initramfs-tools/lvm2/hooks/lvm2 | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/debian/initramfs-tools/lvm2/hooks/lvm2 
b/debian/initramfs-tools/lvm2/hooks/lvm2
index 6c186dc5a..4eef98faf 100755
--- a/debian/initramfs-tools/lvm2/hooks/lvm2
+++ b/debian/initramfs-tools/lvm2/hooks/lvm2
@@ -33,6 +33,21 @@ copy_exec /sbin/dmsetup
 copy_exec /sbin/lvm
 ln -s lvm ${DESTDIR}/sbin/vgchange
 
-for x in dm_mod dm_snapshot dm_mirror dm_raid raid0 raid1 raid10 raid456; do
+for x in \
+   dm_bio_prison \
+   dm_bufio \
+   dm_cache \
+   dm_cache_smq \
+   dm_integrity \
+   dm_persistent_data \
+   dm_mirror \
+   dm_mod \
+   dm_raid \
+   dm_snapshot \
+   raid0 \
+   raid1 \
+   raid10 \
+   raid456 \
+   ; do
manual_add_modules ${x}
 done
-- 
2.20.1

Bug#579616: RFA: nss-updatedb -- Cache name service directories in DB format

[Guido Günther]

Hi,
On Sat, May 29, 2021 at 12:38:29AM -0300, Fabio A. De Muzio Tobich wrote:
> On Thu, 29 Apr 2010 07:04:21 +0200 Guido =?iso-8859-1?Q?G=FCnther?=
>  wrote:
> > Package: wnpp
> > Severity: normal
> > 
> > I request an adopter for the nss-updatedb package.
> > 
> > The package description is:
> >  This package contains a script, nss_updatedb, which can be
> >  used to maintain local caches of user and group directories.
> >  These can then be used by the DB Name Service Switch module
> >  (libnss-db) to provide name service when the system is offline.
> >  .
> >  These tools are designed to work with libpam-ldap and libnss-ldap.
> > 
> > I'm not using it anymore.
> > Cheers,
> >  -- Guido
> > 
> > 
> > 
> 
> Hi Guido,
> 
> I still use this package quite regularly and I'm interested in adopting it.
> It's been a while since you opened this RFA, would be ok if I go ahead with
> the adoption process?

Sure, go ahead!
Thanks,
 -- Guido

> 
> Regards,
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
> ⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
> ⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
> ⠈⠳⣄
> 





signature.asc
Description: PGP signature

Bug#912411: Cgroup memory subsystem memory leak

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Wed, Oct 31, 2018 at 05:21:39PM +0800, 段熊春 wrote:
> Package: linux-image-4.9.0-0.bpo.7-amd64
> Version: 4.9.110-3+deb9u2~deb8u1
> 
> Package: systemd
> Version: 230-7~bpo8+2
> 
> hi guys：
> We suspect that we may have found a memory leak bug in cgroup memory 
> subsystem, with 1GBytes/Hour leak speed for a special case.
> This bug could be reproduced 100% on the mainstream kernel version 4.19.   
> (Tried on Debian's latest kernel 4.14 and 4.9, the same result.)
> 
> This is what we have observed (Debian 9 Stretch, with mainstream kernel 
> version 4.19, kconfig attached) and how to reprocude:
> System with Cgroup enabled. A demo service which simulates an "ill" behavior: 
> program broken, and exit immediately after just startup:
> 
> service code
> #include "stdio.h"
> #include "stdlib.h"
> int main()
> {
>  void * p = malloc(10240);
>  return 1;
> }
> Compile the above code and put the binary as /usr/bin/test 
> systemd service
> [Service]
> ExecStart=/usr/bin/test
> Restart=always
> RestartSec=2s
> MemoryLimit=1G
> StartLimitInterval=0
> [Install]
> WantedBy=default.target
> Enable and start the above service with the tool systemctl.
> 
> Some additional information：
> With strace attach to systemd before start the service: systemd will mkdir 
> under /sys/fs/cgroup/memory for that service(/usr/bin/test). After the 
> service stops, rmdir will remove the correspond entry under 
> /sys/fs/cgrou/memory
> With kprobe hook to cgroup_mkdir and cgroup_rmdir: the number of call 
> cgroup_mkdir and cgroup_rmdir are equally.
> With kprobe hook to (1)mem_cgroup_css_alloc (2)mem_cgroup_css_free 
> (3)mem_cgroup_css_released (4)mem_cgroup_css_offline:
> the invoke number of mem_cgroup_css_alloc and mem_cgroup_css_offline are 
> equally  (Assume the number is A)
> the invoke number of alloc mem_cgroup_css_free and mem_cgroup_css_released 
> are equally (Assume the number is B)
> A > B
> With jprobe: we have collected some addresses of memcg. With the crash tool, 
> inspect the living kernel: the member named refcnt's flag in the memcg->css 
> is change to __PERCPU_REF_ATOMIC_DEAD. memcg->css->refcnt->count  keeps 
> the same value as memcg->memory->count.  After 24 hours, we observed the data 
> structure is still in use, and the value of the two count both are 1.
> we wrote a kmod to put a memcg which counter is 1, nothing happen except this 
> struct has been free
> We suspect the issue maybe caused by incorrect call to  try_charge and 
> cancel_charge. Anyway, just guess.
> Following is some inspection code we used as described above:
[...]

Can you still reproduce this issue with a recent kernel from unstable
or buster-backports? What about mainline? if so can you please report
this upstream instead, and keep us downstream in the loop?

Regards,
Salvatore

Bug#989089: Fwd: [Pkg-tigervnc-devel] Bug#989089: tigervnc-standalone-server: when a vncserver instance is invoked, mate-panel starts grabbing memory

[deltagam...@gmx.net]

 Weitergeleitete Nachricht 
Betreff:Re: [Pkg-tigervnc-devel] Bug#989089:
tigervnc-standalone-server: when a vncserver instance is invoked,
mate-panel starts grabbing memory
Datum:  Sat, 29 May 2021 08:52:56 +0200
Von:deltagam...@gmx.net 
An: Ola Lundqvist 



The relevant machine has 8 GB RAM, 2 GB RAM is fix reserved for oracle
DB 18c xe.

As you can see here

[user__at__machine:pts/4 ~/.vnc]$ date && free -tm
Fr 30. Apr 16:09:49 CEST 2021
  total    used    free  shared  buff/cache  
available
Mem:   7978    2761 891    1278   
4325    3636

3.6 GB available memory before starting vncserver on 30. April  ...

===  after some days  ==
[user__at__machine:pts/4 ~/.vnc]$ date && sudo pmap 8903 | head -10
Do 6. Mai 13:21:39 CEST 2021
[sudo] Passwort für user:
8903:   mate-panel
55ec1bd26000    128K r mate-panel
55ec1bd46000    324K r-x-- mate-panel
55ec1bd97000    140K r mate-panel
55ec1bdba000 16K r mate-panel
55ec1bdbe000  4K rw--- mate-panel
55ec1cb34000 1698228K rw---   [ anon ]
7f9e9000   1416K rw---   [ anon ]
7f9e90162000  64120K -   [ anon ]
7f9e9400   1448K rw---   [ anon ]
[user__at__machine:pts/4 ~/.vnc]$
[user__at__machine:pts/4 ~/.vnc]$ date && free -tm

After 6 days, on 6 May mate-panel has grabbed more than 1698228K  ==>
1.69 GB,
the available memory sunk to 2 GB , the difference is approx. the 1.6 GB
that mate-panel has grabbed.


[user__at__machine:pts/4 ~/.vnc]$ date && free -tm
Do 6. Mai 13:24:07 CEST 2021
  total    used    free  shared  buff/cache  
available
Mem:   7978    4357 541    1268   
3079    2049
Swap:  6649    2554    4095
Total:    14628    6912    4636
[user__at__machine:pts/4 ~/.vnc]$

After killing the vncserver now, on 6. May, the mate-panel process
disappeared also ( it seems there is a strong interaction between
tigervnc-standalone-server and mate-panel ) , the new available memory
is also again around 3.6 GB
which indicates again that mate-panel has grabbed the difference between
the 2 "avaibale memory" states, namely 3.6GB and 2.0GB


On a reference machine, same Debian buster, same 8 GB RAM, but DB not
installed yet, the mate-panel has stable about 35 MB memory , after a
week with a running vncserver:

=  reference machine with running vncserver AND connected client for a 
week ==

user__at__refmachine:~/.vnc$ sudo pmap 19726 |head -10
19726:   mate-panel
558100ac1000128K r mate-panel
558100ae1000324K r-x-- mate-panel
558100b32000140K r mate-panel
558100b55000 16K r mate-panel
558100b59000  4K rw--- mate-panel
55810215e000  35224K rw---   [ anon ]
7fcc3000132K rw---   [ anon ]
7fcc30021000  65404K -   [ anon ]
7fcc3400132K rw---   [ anon ]
user__at__refmachine:~/.vnc$


I think the relevant address, process, is the first  [ anon ]  entry in the 
pmap listing of the mate-panel.

It is about 35 MB at ref-machine,

and started with about 13 MB  { 5620203f9000  13064K rw---   [ anon ] }  on 
the production machine
to 266 MB { 5620203f9000 266824K rw---   [ anon ] } 1 day later  on the 
production machine
up to 1.69 GB {  55ec1cb34000 1698228K rw---   [ anon ] } after 1 week on 
the production machine, where I killed/stopped the vncserver.

I let the mate-panel reach also between 2.5 GB and 3 GB before I killed the 
vncserver, the mate-panel process disappeared also,
and the freed memroy  corresponded to the memory mate-panel has grabbed.

The displayed lines are all protocolled in the 2 attached files.

Hope this clarifies the case.

Greets




Am 26.05.2021 um 08:27 schrieb Ola Lundqvist:
> Hi
>
> When you are referring to "grabbing memory" how much are you expecting
> mate-panel to use?
> Is it much more than what the mate-panel use to use in other X servers?
> I can see that mate-panel use some 70 to 100 MB memory but since I
> have no knowledge about this software I cannot tell whether that is a
> lot of not.
>
> Cheers
>
> // Ola
>
> On Tue, 25 May 2021 at 18:19, deltagam...@gmx.net
>   > wrote:
>
> forgot to attach some files
>
>
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> 
> 
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>
>
>
> --
>  - Ola Lundqvist ---
> /  o...@debian.org                    
>  o...@inguza.com                   \
> |  http://inguza.com/                 +46 (0)70-332 1551       |
>  

Bug#987388: Crash of amdgpu on Debian 11 Bullseye

[Simon Iremonger (debian)]

Dear all on this bug,


I would like to briefly point out these crashes are showing kernel
errors, the kernel / amdgpu modesetting seems to be a very significant
part of the problem if I am not mistaken, this bug being against
the X-server component.

I would say, from the deb-10 / MX19.4 side of things with a GCN1.1
series amdgpu card,  updated 5.10 kernels (i.e. backports of deb11
bullseye kernels) have incrementally improved problems with crashing,
resuming from sleep, and so-on. With 5.10.0-7 I seem to be able to
reliably unpower and repower monitors and manage to keep X working
without crash and just xrandr fix up monitor layout.  Similar applies
to sleep/resume situation!.

I know the kernel amdgpu modesetting driver is a huge part of that work.

In short, I would highly recommend trying different kernels on your
deb11 testing machines and see how that affects your situation, and
in any case report which kernels are in use in the crash scenario.


Debian11 bullseye currently has 5.10.0-6 and I understand the 5.10.0-7
packages are to hit bullseye soon (through hard freeze).

5.10.0-7 is in sid and can be manually downloaded, or installed via
*temporary* adding sid to sources.list and then removing from sources
(or pinning to avoid all packages going to sid).

https://packages.debian.org/search?keywords=linux-image-5.10.0-7-amd64


Also, I would note, testing the older linux-image-4.19.0-16  may be
worthwhile, I get impression this (buster) kernel should nonetheless
'work' with bullseye and may assist with the 'it used to work' scenario.


Hope that helps,

--Simon