Bug#965752: ogamesim: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Ying-Chun Liu (PaulLiu)]

Hi all,

I'm about to fix this bug. And NMU this package.
The following changes are made:

  * Change debhelper from 5 to 11. Update debian/rules. (Closes: #965752)
   - Clean files by debian/clean
 * Change source package to DebSrc3.0 with quilt.
   - Split diff.gz to quilt patches.
 * debian/control: Change priority from extra to optional.
 * debian/control: Don't depends on perl-modules. Depends on perl is 
enough.

 * debian/copyright: Change to dep5 machine-readable format.
 * Add autopkgtest


The NMU diff is attached. I'll upload it soon.

Yours,
Paul

diff -Nru ogamesim-20130107/csim/version.h ogamesim-20130107/csim/version.h
--- ogamesim-20130107/csim/version.h	2022-01-07 15:44:58.0 +0800
+++ ogamesim-20130107/csim/version.h	2008-08-31 22:06:08.0 +0800
@@ -17,6 +17,6 @@
 */
 #ifndef __VERSION__H__
 
-#define VERSION   "1.18"
+#define VERSION   "1.17"
 
 #endif
diff -Nru ogamesim-20130107/debian/changelog ogamesim-20130107/debian/changelog
--- ogamesim-20130107/debian/changelog	2022-01-07 15:44:58.0 +0800
+++ ogamesim-20130107/debian/changelog	2022-01-07 15:43:00.0 +0800
@@ -1,3 +1,17 @@
+ogamesim (20130107-3.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Change debhelper from 5 to 11. Update debian/rules. (Closes: #965752)
+- Clean files by debian/clean
+  * Change source package to DebSrc3.0 with quilt.
+- Split diff.gz to quilt patches.
+  * debian/control: Change priority from extra to optional.
+  * debian/control: Don't depends on perl-modules. Depends on perl is enough.
+  * debian/copyright: Change to dep5 machine-readable format.
+  * Add autopkgtest
+
+ -- Ying-Chun Liu (PaulLiu)   Fri, 07 Jan 2022 15:43:00 +0800
+
 ogamesim (20130107-3.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru ogamesim-20130107/debian/clean ogamesim-20130107/debian/clean
--- ogamesim-20130107/debian/clean	1970-01-01 08:00:00.0 +0800
+++ ogamesim-20130107/debian/clean	2022-01-07 14:52:24.0 +0800
@@ -0,0 +1,4 @@
+ogamesim
+index.cgi
+ogamesim.6
+csim/csim
diff -Nru ogamesim-20130107/debian/compat ogamesim-20130107/debian/compat
--- ogamesim-20130107/debian/compat	2022-01-07 15:44:58.0 +0800
+++ ogamesim-20130107/debian/compat	2022-01-07 14:19:54.0 +0800
@@ -1 +1 @@
-7
+11
diff -Nru ogamesim-20130107/debian/control ogamesim-20130107/debian/control
--- ogamesim-20130107/debian/control	2022-01-07 15:44:58.0 +0800
+++ ogamesim-20130107/debian/control	2022-01-07 15:05:32.0 +0800
@@ -1,9 +1,9 @@
 Source: ogamesim
 Section: games
-Priority: extra
+Priority: optional
 Maintainer: Dmitry E. Oboukhov 
 Standards-Version: 3.7.3
-Build-Depends: perl (>= 5.6), gettext (>= 0.15), debhelper (>= 5)
+Build-Depends: perl (>= 5.6), gettext (>= 0.15), debhelper (>= 11)
 Homepage: http://www.o-o-d.com/tool/sim
 
 Package: ogamesim
@@ -21,7 +21,7 @@
 Package: ogamesim-www
 Suggests: apache2
 Architecture: all
-Depends: perl, libsys-cpu-perl, libcgi-simple-perl, libhtml-template-perl, perl-modules, ogamesim
+Depends: perl, libsys-cpu-perl, libcgi-simple-perl, libhtml-template-perl, ogamesim, ${misc:Depends}
 Description: WWW GUI for ogamesim
  CGI frontend for the console battles simulator.
  Contains:
diff -Nru ogamesim-20130107/debian/copyright ogamesim-20130107/debian/copyright
--- ogamesim-20130107/debian/copyright	2022-01-07 15:44:58.0 +0800
+++ ogamesim-20130107/debian/copyright	2022-01-07 15:38:57.0 +0800
@@ -1,29 +1,30 @@
-This package was debianized by Dmitry E. Oboukhov  on
-Mon Dec  4 13:12:57 MSK 2006
-
-Upstream copyright:
-	Copyright (C) 2006,2007 Dmitry E. Oboukhov 
-
-It was downloaded from:
-	http://www.o-o-d.com/tool/sim/
-
-License:
-   This package is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2 of the License, or
-   (at your option) any later version.
-
-   This package is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   You should have received a copy of the GNU General Public License
-   along with this package; if not, write to the Free Software
-   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
-
-On debian systems, full text of GPLv2 license is alailable
-in /usr/share/common-licenses/GPL-2
-
-The Debian packaging is (C) 2006, Dmitry E. Oboukhov  and
-is licensed under the GPL, see `/usr/share/common-licenses/GPL'.
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: ogamesim
+Upstream-Contact: Dmitry E. Oboukhov 
+Source: http://www.o-o-d.com/tool/sim/
+
+Files: *
+Copyright: 2006-2007 Dmitry E. Oboukhov 
+License: GPL-2+
+
+Files: debian/*
+Copyright: 2006 Dmitry E. 

Bug#1003143: ITP: bitwarden-cli -- The Bitwarden command line vault.

[Michele Cane]

Package: wnpp
Followup-For: Bug #1003143
Owner: Michele Cane 
X-Debbugs-Cc: debian-de...@lists.debian.org

Hi,

Thanks for looking into this.

You might want to look at #956836, they already did some work on it or at list 
looked into the issue.

Cheers

Mike

Bug#1003264: mesa: Build-Dependency cycle between mesa and libglvnd

[Laurent Bigonville]

Source: mesa
Version: 21.3.3-1
Severity: important

Hello,

Looks like there is still a build-dependency loop between mesa and libglvnd

mesa build-depends on:
- libglvnd-dev:kfreebsd-amd64 (>= 1.3.2)
libglvnd-dev depends on:
- libglx-dev:kfreebsd-amd64 (>= 1.3.0-1)
libglx-dev depends on:
- libglx0:kfreebsd-amd64 (= 1.4.0-1)
libglx0 depends on missing:
- libglx-mesa0:kfreebsd-amd64

In #979976 you have reintroduced the libglvnd-core-dev package, but it
seems that mesa is still BD on libglvnd-dev instead

Could you please switch the build-dependency from libglvnd-dev to
libglvnd-core-dev?

Kind regards,
Laurent Bigonville


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#1003263: why does guake warn about a non-existing custom_command.json file ?

[shirish शिरीष]

Package: guake
Version: 3.8.1-1
Severity: normal

Dear Maintainer,

I get the following in the .xsession-errors.

Custom file does not exit: /home/shirish/.config/guake/custom_command.json

And have no idea why it is like that. Is it a bug or not ???

FWIW, I haven't made any file like that. Is such a file needed, if
yes, for what ???

The manpage says nothing about it and sadly there is no section 8 so
I'm at wits end.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages guake depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-3
ii  dbus-x11 [dbus-session-bus]   1.12.20-3
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-2
ii  gir1.2-glib-2.0   1.70.0-2
ii  gir1.2-gtk-3.03.24.31-1
ii  gir1.2-keybinder-3.0  0.3.2-1.1
ii  gir1.2-notify-0.7 0.7.9-3
ii  gir1.2-pango-1.0  1.48.10+ds1-1
ii  gir1.2-vte-2.91   0.66.2-1
ii  gir1.2-wnck-3.0   40.0-2
ii  libglib2.0-bin2.70.2-1
ii  libutempter0  1.2.1-2
ii  python3   3.9.7-1
ii  python3-cairo 1.20.1-3
ii  python3-dbus  1.2.18-3+b1
ii  python3-gi3.42.0-3
ii  python3-gi-cairo  3.42.0-3
ii  python3-pbr   5.6.0-2

guake recommends no packages.

Versions of packages guake suggests:
ii  numix-gtk-theme  2.6.7-6

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#1003195: enlightenment: E crashes after coming back from a different VTY

[Ross Vandegrift]

On Thu, Jan 06, 2022 at 12:32:44AM +0100, Robert Waldner wrote:
> F'rex, switching to VTY1 (text console) works as expected, but after
> switching back to Enlightenment on VTY7 E crashes.
> Same after switching back to VTY7 from VTY8 (where a different user runs
> XFCE4).

Switching to a different vty and back works fine for me, but I don't have
another desktop session running anywhere.  Does the issue still happen if you
only have one session running?

> Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red
> writing situation:

It looks like you're missing the debug symbols.  Please follow the instructions
at https://wiki.debian.org/HowToGetABacktrace and try again.

Ross

Bug#1003247: workaround / Re: Bug#1003247: mailman3-web: Mailman3 not working following distribution upgrade from Debian 10 to 11.

[Joost van Baal-Ilić]

On Thu, Jan 06, 2022 at 06:14:26PM -0500, Gordon Dickens wrote:
> Package: mailman3-web
> Version: 0+20200530-2
> Severity: important
> 
> Dear Maintainer,
> 
> I performed a distribution upgrade from Debian 10 Buster (which runs mailman
> 3.2.1) to Debian 11 Bullseye (which runs mailman 3.3.1) with the command
> "apt-get full-upgrade -y" and everything apparently worked properly except at
> the end of the upgrade when the following error dialog was generated by the
> mailman3-web and mailman3-full post-installation scripts:
> 
> Setting up mailman3-web (0+20200530-2) ...
> Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
> dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
> dbconfig-common: flushing administrative password
> sed: -e expression #2, char 77: unterminated `s' command
> dpkg: error processing package mailman3-web (--configure):
>  installed mailman3-web package post-installation script subprocess returned
>  error exit status 1
> dpkg: dependency problems prevent configuration of mailman3-full:
>  mailman3-full depends on mailman3-web; however:
>   Package mailman3-web is not configured yet.
> 
> dpkg: error processing package mailman3-full (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  mailman3-web
>  mailman3-full
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 

> 
> So, I am now stuck

> 
> Does anybody have any idea how to fix this?  I would very much appreciate 
> some suggestions.
> 

Not a fix, but a _very_ _dirty_ workaround:

 sudo mv /var/lib/dpkg/info/mailman3-web.postinst 
/var/lib/dpkg/info/mailman3-web.postinst.disabled

(Only do this if everything else failed.) After that, try the install again by
running

 sudo apt-get -f install

.  Your can now do dpkg/apt stuff again.  However, you'll have to manually
execute all the needed things /var/lib/dpkg/info/mailman3-web.postinst was
trying to achieve: have a look at that script.

HTH, Bye,

Joost

Bug#1002986: Re: Bug#1002986: libguestfs-tools: Depends on guestfs-tools that is not in the archive

[Johannes Schauer Marin Rodrigues]

Control: block 1003191 by -1
Control: affects -1 + mmdebstrap

On Wed, 05 Jan 2022 13:25:57 -0800 "Joseph Carter" 
 wrote:
> On Sun, 02 Jan 2022 23:28:32 +0100 Hilko Bengen  wrote:
> > * Laurent Bigonville:
> > 
> > > It looks like libguestfs-tools version 1:1.46.2-1 in depending on
> > > guestfs-tools that is not in the archive making the package uninstalable
> > >
> > > guestfs-tools is currently stuck in the new queue
> > 
> > Right. Let's  just wait. (Or do you know of a way to speed this up?)
> 
> Cold beverages of the FTP maintainer's choice?  Hopefully it'll be in the
> archive soon, but looking at https://ftp-master.debian.org/new.html there are
> packages that have been sitting in NEW for almost a year now. It might be a
> case of squeaky wheels—or that some of those packages having a hold-up for a
> particular reason. Probably a bit of both.

I pinged ftp master on IRC about this just now as this is making a new release
of my package mmdebstrap impossible (#1003191).

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1003262: ITP: python-docx-template -- Python DOCX template engine

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 999508 by -1

* Package name: python-docx-template
  Version : 0.15.1
  Upstream Author : Eric Lapouyade
* URL : https://github.com/elapouya/python-docx-template
* License : LGPL-2.1
  Programming Lang: Python
  Description : Python DOCX template engine

python-docx-template has been created because python-docx is powerful
for creating documents but not for modifying them.

The idea is to begin to create an example of the document one wants to
generate with any DOCX WYSIWYG editor. It can be as complex as one
wants: pictures, index tables, footer, header, variables. Then, as one
is still editing the document, one inserts jinja2-like tags directly in
the document. This becomes a DOCX template file.

This package is required by finalcif.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-docx-template

Bug#1003261: Debdiff for bullseye pu

[Scott Kitterman]

Also, I meant to put the d/changelog in the bug and forgot:

postfix (3.5.13-0+deb11u1) bullseye; urgency=medium

  [Scott Kitterman]

  * Update debian/watch to track v3.5 versions for stable updates
  * Refresh patches
  * Include compatibility_level in addition to postifx version when
determining default value for chroot in master.cf.  Closes: #995129
  * Fixup errors in postifx-add-* man pages.  Closes: #995031
  * Update main/master.cf.proto on upgrade if not modified.  Closes: #991513
  * Update d/p/70_postfix-check.diff to exclude makedefs.out from synlink
check.  Closes: #926331
  * Test that nothing is reported by postfix check in autopkgtest
  * Do not override user set default_transport in postinst.  Closes: #988538
  * Remove left-over ca-certificates.crt file from postfix chroot. 
Closes: #991609
  * Add information about keeping resolv.conf up to date in the chroot with
the resolvconf package.  Closes: #964762

  [Sergio Gelato]

  * Correct if-up.d to not error out if postfix can't send mail yet. 
Closes: #959864

  [Miriam España Acebal]

  * Removed LDFLAG -Bsymbolic-functions to fix issue where TLS is disabled
when private/tlmsgr socket is not found.  lp: #1885403

  [Paride Legovini]

  * d/postfix.postinst: tolerate search domain with a leading dot. 
Closes: #991950

  [Wietse Venema]

  * 3.5.7
- Bugfix (introduced: Postfix 3.4, already fixed in Postfix
  3.6): tlsproxy(8) was using the wrong DANE macro for
  connections with DANE trust anchors or with non-DANE trust
  anchors (WTF: Thorsten Habich found this bug in the use
  case that has nothing to do with DANE). This resulted in a
  global certificate verify function pointer race, between
  TLS handshakes that use TLS trust achors and handshakes
  that use PKI. No memory was corrupted in the course of all
  this.  Viktor Dukhovni. File: tlsproxy/tlsproxy.c.

- Cleanup: the posttls-finger '-X' option reported a false
  conflict with '-r'. File: posttls-finger/posttls-finger.c.

  * 3.5.8
- Bugfix (introduced: Postfix 2.0): smtp_sasl_mechanism_filter
  ignored table lookup errors, treating them as 'not found'.
  Found during Postfix 3.6 development. File: smtp/smtp_sasl_proto.c.

- Bugfix (introduced: Postfix 2.3): when deleting a recipient
  with a milter, delete the recipient from the duplicate
  filter, so that the recipient can be added back. Backported
  from Postfix 3.6. Files: global/been_here.[hc],
  cleanup/cleanup_milter.c.

- Bugfix (introduced: before Postfix alpha): the code that
  looks for Delivered-To: headers ignored headers longer than
  $line_length_limit. Backported from Postfix 3.6. File:
  global/delivered_hdr.c.

- Bugfix (introduced: Postfix 2.8): save a copy of the
  postscreen_dnsbl_reply_map lookup result. This has no effect
  when the recommended texthash: look table is used, but it
  may avoid stale data with other lookup tables. File:
  postscreen/postscreen_dnsbl.c.

- Bugfix (introduced: Postfix 2.2): after processing an
  XCCLIENT command, the smtps service was waiting for a TLS
  handshake. Found by Aki Tuomi. File: smtpd/smtpd.c.

- Bugfix (introduced: Postfix 2.3): static maps did not free
  their casefolding buffer. File: util/dict_static.c.

- Bugfix (introduced: Postfix 3.5): the Postfix SMTP client
  broke message headers longer than $line_length_limit, causing
  subsequent header content to become message body content.
  Reported by Andreas Weigel, fix by Viktor Dukhovni. File:
  smtp/smtp_proto.c.

  * 3.5.9
- Feature: when a Postfix program makes a DNS query that
  requests DNSSEC validation (usually for Postfix DANE support)
  but the DNS response is not DNSSEC validated, Postfix will
  send a DNS query configured with the "dnssec_probe" parameter
  to determine if DNSSEC support is available, and logs a
  warning if it is not. By default, the probe has type "ns"
  and domain name ".". The probe is sent once per process
  lifetime. Files: dns/dns.h, dns/dns_lookup.c, dns/dns_sec.c,
  test_dns_lookup.c, global/mail_params.[hc], mantools/postlink.

- The default "smtp_tls_dane_insecure_mx_policy = dane" was
   causing unnecessary dnssec_probe activity. The default is now
   "dane" when smtp_tls_security_level is "dane", otherwise it is
   "may". File: global/mail_params.h.

  * 3.5.10
- Missing null pointer checks (introduced: Postfix 3.4) after
  an internal I/O error during the smtp(8) to tlsproxy(8)
  handshake. Found by Coverity, reported by Jaroslav Skarvada.
  Based on fix by Viktor Dukhovni. File: tls/tls_proxy_client_scan.c.

- Null pointer bug (introduced: Postfix 3.0) and memory leak
  (introduced: Postfix 3.4) after an inline: table syntax
  error in main.cf or master.cf. Found by Coverity, reported
  by Jaroslav Skarvada. 

Bug#1003261: bullseye-pu: package postfix/3.5.6-1

[Scott Kitterman]

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

I've put together my usual postfix post-release update.  Because I'm
behind, it's rather larger than usual.  Also, a number of packaging bugs
that apply to bullseye have been recently fixed in Bookworm, so the low
risk changes there have been backported too.

The diff is rather large, so I don't include it in the original bug
report to increase the chances this makes it to the mailing list.

Also, as usual, I have this update ready to upload and running in
production locally.

Scott K

Bug#1003158: [pkg-apparmor] Bug#1003158: apparmor: tunables/home seems to have wrong order of variables

[Seth Arnold]

On Thu, Jan 06, 2022 at 08:38:32PM +0100, Christian Boltz wrote:
> Am Mittwoch, 5. Januar 2022, 23:09:01 CET schrieb Karsten Hilbert:
> > Unless I misunderstand apparmor profile logic it is not
> > purely cosmetic. It excludes "/home/*/" from @{HOME}.
> 
> That's the difference between a human parser (you) and apparmor_parser 
> ;-) - you think of the profile as "code" (where order matters) while 
> apparmor_parser (mostly) doesn't care about the order.
> 
> I'll try to explain how apparmor_parser works using pseudo-SQL:

Another way to look at this is through a quick test:

$ cat test_profile
@{A}=@{B} /a/
@{B}=/b/
@{A}+=/c/

profile p {
  @{A} r,
}
$ apparmor_parser -Qd < test_profile
- Debugging built structures -
Name:   p
Profile Mode:   Enforce
--- Entries ---
Mode:   r:r Name:   ({/b/,/a/,/c/})

$


Maybe a simple example will be more clear :)

Thanks


signature.asc
Description: PGP signature

Bug#1002850: journalctl -f for SD card in USB adapter and in PC Card.

[peter]

peter@joule:/home/peter$ cat USB/udevLog1
-- Journal begins at Fri 2021-12-24 18:36:08 PST. --
Jan 06 19:09:29 mebius systemd[362]: Queued start job for default target Main Us
er Target.
Jan 06 19:09:29 mebius systemd[362]: Created slice User Application Slice.
Jan 06 19:09:29 mebius systemd[362]: Reached target Paths.
Jan 06 19:09:29 mebius systemd[362]: Reached target Timers.
Jan 06 19:09:29 mebius systemd[362]: Starting D-Bus User Message Bus Socket.
Jan 06 19:09:29 mebius systemd[362]: Listening on D-Bus User Message Bus Socket.
Jan 06 19:09:29 mebius systemd[362]: Reached target Sockets.
Jan 06 19:09:29 mebius systemd[362]: Reached target Basic System.
Jan 06 19:09:29 mebius systemd[362]: Reached target Main User Target.
Jan 06 19:09:29 mebius systemd[362]: Startup finished in 1.619s.
peter@joule:/home/peter$

Also observed this on the screen when the SD was inserted in 
the USB adapter.

[  223.073688] usb usb1-port2: disabled by hub (EMI?), re-enabling...
[  223.741529] usb 1-2: device descriptor read/64, error -71
[  223.985548] usb 1-2: device descriptor read/64, error -71
[  224.357535] usb 1-2: device descriptor read/64, error -71
[  224.601534] usb 1-2: device descriptor read/64, error -71
[  225.277540] usb 1-2: device not accepting address 6, error -71
[  225.821547] usb 1-2: device not accepting address 7, error -71
[  225.821818] usb usb1-port2: unable to enumerate USB device



-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Vincent Lefevre]

Control: reassign -1 libglib2.0-0 2.70.2-1
Control: retitle -1 libglib2.0-0: the terminal for desktop files with 
Terminal=true should be configurable
Control: tags -1 upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/338
Control: affects firefox

On 2022-01-07 10:25:36 +0900, Mike Hommey wrote:
> On Fri, Jan 07, 2022 at 02:23:44AM +0100, Vincent Lefevre wrote:
> > On 2022-01-07 10:18:11 +0900, Mike Hommey wrote:
> > > Firefox starts whatever glib tells it is in the desktop file. If the
> > > command in the desktop file ends up running urxvt, it's not Firefox's
> > > fault. If the desktop file says "Terminal=true" and glib tells Firefox
> > > to run urxvt, it's not Firefox's fault.
> > 
> > OK, so the bug would be in libglib2.0-0 (which uses a hardcoded
> > list of terminals as said in the reddit post I've mentioned in
> > my other message)?
> 
> Apparently yes.

So reassigning.

Concerning the urxvt failure, this is due to the fact that firejail
blacklists Perl for security reasons and urxvt needs Perl modules.
As a workaround, firejail should also blacklist rxvt in this case,
so that glib won't see it and won't try to run it (so it will run
xterm instead). I've submitted a pull request for firejail:

  https://github.com/netblue30/firejail/pull/4831

and also reported a bug for Debian:

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1002567: libjson-schema-modern-perl

[Karen Etheridge]

Andrius Merkys wrote:
> On 2021-12-24 12:15, Damyan Ivanov wrote:
> > JSON::Schema::Modern aims to be a fully-compliant JSON Schema evaluator
and
> > validator, targeting the currently-latest Draft 2020-12
> > (https://json-schema.org/specification-links.html#2020-12).
>
> Thanks for an interesting ITP. I find it nontrivial to understand how
> JSON::Schema::Modern is different from JSON::Validator which is already
> in Debian. Maybe it is worth asking the upstream.

It probably would be :)  This distribution is fully specification-compliant,
including output formats, and supports up to the latest version of the json
schema specification, which is necessary for OpenAPI 3.1 support.

> > Currently the tests fail with AUTOMATED_TESTS=1 in the environment
(which
> > happens during autopkg-testing).
>
> I may look into this if I find some time.

This is because one of its dependencies, Test::JSON::Schema::Acceptance, was
being packaged with the incorrect data set -- the newer code was not
compatible with the older data.  I believe that
libtest-json-schema-acceptance-perl has now been properly repackaged, so you
may try again.

Why are you using AUTOMATED_TESTS though? See
https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.md#environment-variables-for-testing-contexts
for the proper usage of this environment variable.

cheers,
Karen Etheridge
et...@cpan.org
- the author of JSON::Schema::Modern

Bug#1003259: firejail should blacklist rxvt when Perl is blacklisted

[Vincent Lefevre]

Package: firejail
Version: 0.9.66-2
Severity: normal
Tags: upstream
Forwarded: https://github.com/netblue30/firejail/pull/4831

When Firefox needs to run an application with Terminal=true in its
.desktop file, this is done via glib, which uses a hardcoded list
of terminals .
See also Debian bug 1003206.

In particular, rxvt comes before xterm in this list:
  https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdesktopappinfo.c

But rxvt needs Perl modules, which are blacklisted with the firefox
profile, thus does not work. So we need to blacklist it in this case
so that an alternative terminal emulator (further in the list) is
tried by glib.

I've submitted a pull request upstream. The corresponding patch:
https://github.com/netblue30/firejail/pull/4831/commits/ed5c259fcc106b8b07f056f65e828c680fec9562

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 firejail depends on:
ii  libapparmor1  3.0.3-6
ii  libc6 2.33-1
ii  libselinux1   3.3-1+b1

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.66-2
ii  iproute2   5.15.0-1
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.1-1+b3
ii  xvfb   2:1.20.13-3

firejail suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003258: php-redis: Support php8.1

[Johnw]

Package: php-redis
Severity: wishlist
X-Debbugs-Cc: johnw.m...@gmail.com

Dear Maintainer,

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

Since debian sid updated the php to version 8.1.
Please update php-redis to support it, thanks.

   * What led up to the situation?
   * 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: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages php-redis depends on:
ii  libc62.33-1
pn  php-common   
pn  php-igbinary 
pn  phpapi-20190902  

php-redis recommends no packages.

Versions of packages php-redis suggests:
pn  redis-server  

Bug#988369: debsigs --verify not implemented

[Todd C. Miller]

I have implemented verify mode.  There is a merge request at
GitLab: https://gitlab.com/debsigs/debsigs/-/merge_requests/5

 - todd

Bug#1003257: screen: segfaults ("screen caught signal 11. (core dumped)])") when run with no arguments/-r

[наб]

Package: screen
Version: 4.8.0-6
Severity: important

Dear Maintainer,

I freshly installed screen. I don't think I have any pre-existing
configuration on this machine. I also don't think I have any weird
system config.

Please consider the following shell session:
-- >8 --
nabijaczleweli@tarta:~/uwu$ screen

[screen caught signal 11. (core dumped)]
nabijaczleweli@tarta:~/uwu$
-- >8 --

(Also, I have ulimit -c set to 0, so not only is there no coredump,
 there can't be one).

The same happens when I run screen -r, which I decided to do seeing as
/run/screen/S-nabijaczleweli/ had some sockets in it:
-- >8 --
srwx-- 1 nabijaczleweli users 0 Jan  7 02:38 100395.pts-0.tarta
srwx-- 1 nabijaczleweli users 0 Jan  7 02:40 184228.pts-0.tarta
srwx-- 1 nabijaczleweli users 0 Jan  7 02:40 184368.pts-0.tarta
srwx-- 1 nabijaczleweli users 0 Jan  7 02:40 187419.pts-0.tarta
srwx-- 1 nabijaczleweli users 0 Jan  7 02:40 188181.pts-0.tarta
srwx-- 1 nabijaczleweli users 0 Jan  7 02:41 190201.pts-0.tarta
srwx-- 1 nabijaczleweli users 0 Jan  7 02:44 308064.pts-0.tarta
srwx-- 1 nabijaczleweli users 0 Jan  7 02:38 97741.pts-0.tarta
-- >8 --

Attaching a strace -f screen (which indicates that it catches SIGABRT,
not SIGSEGV? wild) and the coredump (after raising ulimit -c).

Please advise? Am I holding it wrong? (How wrong indeed if it ends up
like this?)

Best,
наб

-- Package-specific info:
File Existence and Permissions
--

drwxr-xr-x 33 root root   1040 Jan  7 02:33 /run
lrwxrwxrwx  1 root root  4 Mar 16  2020 /var/run -> /run
-rwxr-xr-x  1 root root 482312 Feb 27  2021 /usr/bin/screen
-rw-r--r--  1 root root119 Jan  7 02:33 /etc/tmpfiles.d/screen-cleanup.conf
lrwxrwxrwx  1 root root  9 Jan  7 02:33 
/lib/systemd/system/screen-cleanup.service -> /dev/null
-rwxr-xr-x  1 root root   1222 Feb 18  2021 /etc/init.d/screen-cleanup
lrwxrwxrwx  1 root root 24 Jan  7 02:33 /etc/rcS.d/S01screen-cleanup -> 
../init.d/screen-cleanup

File contents
-

### /etc/tmpfiles.d/screen-cleanup.conf
__
# This file is generated by /var/lib/dpkg/info/screen.postinst upon package 
configuration
d /run/screen 1777 root utmp
__

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-10-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages screen depends on:
ii  libc6 2.31-13+deb11u2
ii  libcrypt1 1:4.4.18-4
ii  libpam0g  1.4.0-9+deb11u1
ii  libtinfo6 6.2+20201114-2
ii  libutempter0  1.2.1-2

screen recommends no packages.

Versions of packages screen suggests:
ii  iselect   1.4.0-4
ii  ncurses-term  6.2+20201114-2
ii  screenie  20120406-1.1

-- no debconf information


screen-core.zst
Description: application/zstd
498446 execve("/bin/screen", ["screen"], 0x7ffda8397838 /* 25 vars */) = 0
498446 brk(NULL)= 0x55a46b1e7000
498446 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
directory)
498446 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
498446 fstat(3, {st_mode=S_IFREG|0644, st_size=95401, ...}) = 0
498446 mmap(NULL, 95401, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f52d117
498446 close(3) = 0
498446 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libtinfo.so.6", 
O_RDONLY|O_CLOEXEC) = 3
498446 read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\351\0\0\0\0\0\0"..., 832) = 
832
498446 fstat(3, {st_mode=S_IFREG|0644, st_size=187792, ...}) = 0
498446 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f52d116e000
498446 mmap(NULL, 190880, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f52d113f000
498446 mmap(0x7f52d114d000, 57344, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f52d114d000
498446 mmap(0x7f52d115b000, 57344, PROT_READ, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7f52d115b000
498446 mmap(0x7f52d1169000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x29000) = 0x7f52d1169000
498446 close(3) = 0
498446 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libutempter.so.0", 
O_RDONLY|O_CLOEXEC) = 3
498446 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 
\21\0\0\0\0\0\0"..., 832) = 832
498446 fstat(3, {st_mode=S_IFREG|0644, st_size=14256, ...}) = 0
498446 mmap(NULL, 16416, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 

Bug#1003256: .part file created when modifying file on NAS device

[danc]

Package: unknown
Version: unknown

In debian stable I can modify files on the NAS with no problem.
When I change my repo to testing or unstable when I modify a file and 
attempt to save it, it just creates a .part file and doesn't save the 
original file.


Let me know if you need more information.

Thanks
Dan Cihon

Bug#1003255: (no subject)

[Peter Mueller]

Package: texlive-pstricks
Version: 2021.20211217-1
Let's construct mwe.tex containing
\documentclass{article} \usepackage{pstricks} \begin{document} test 
\end{document}
and run
latex mwe && dvipdf mwe
or
latex mwe && dvips mwe && ps2pdf mwe.ps
This prints
 WARNING: Transparency operations ignored - need to use 
-dALLOWPSTRANSPARENCY
on a tty. Of course, one can do as the message says and add the corresponding 
command-line option. Still, I feel that the transparency stuff shouldn't even 
be in the Postscript file unless it is really used. So could pstricks be a bit 
more economical and not issue the transparency-related commands by default (or, 
equivalently, issue them only if opacity and the like is really used in the 
user's LaTeX input)? Alternatively or in addition, could ghostscript be a 
little less fussy about transparency and make ALLOWPSTRANSPARENCY default?
Bug report: https://tex.stackexchange.com/questions/629314 
https://tex.stackexchange.com/questions/629314. The PStricks maintainers have 
been informed, too, just in case they don't have an update for this issue yet.
Thank you in advance,
Peter

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Vincent Lefevre]

On 2022-01-07 10:18:11 +0900, Mike Hommey wrote:
> Firefox starts whatever glib tells it is in the desktop file. If the
> command in the desktop file ends up running urxvt, it's not Firefox's
> fault. If the desktop file says "Terminal=true" and glib tells Firefox
> to run urxvt, it's not Firefox's fault.

OK, so the bug would be in libglib2.0-0 (which uses a hardcoded
list of terminals as said in the reddit post I've mentioned in
my other message)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Mike Hommey]

On Fri, Jan 07, 2022 at 02:23:44AM +0100, Vincent Lefevre wrote:
> On 2022-01-07 10:18:11 +0900, Mike Hommey wrote:
> > Firefox starts whatever glib tells it is in the desktop file. If the
> > command in the desktop file ends up running urxvt, it's not Firefox's
> > fault. If the desktop file says "Terminal=true" and glib tells Firefox
> > to run urxvt, it's not Firefox's fault.
> 
> OK, so the bug would be in libglib2.0-0 (which uses a hardcoded
> list of terminals as said in the reddit post I've mentioned in
> my other message)?

Apparently yes.

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Vincent Lefevre]

On 2022-01-07 02:04:01 +0100, Vincent Lefevre wrote:
> On 2022-01-07 09:17:22 +0900, Mike Hommey wrote:
> > Rephrasing: the main question is why your config/Emacs's desktop
> > file/Emacs's configuration/whatever wants to use urxvt, because
> > Firefox won't do that on its own.
> 
> There's no mention of rxvt in
> /usr/share/applications/emacs-term.desktop
> 
> Anyway, this is Firefox that starts the application. Unfortunately,
> http://kb.mozillazine.org/File_types_and_download_actions and
> https://firefox-source-docs.mozilla.org/uriloader/exthandler/index.html
> are silent on this subject.

https://www.reddit.com/r/linuxquestions/comments/jelish/change_the_default_terminal_emulator_for_all/
is about

  Change the default terminal emulator for all .desktop files with
  Terminal=true?

which is the case of the emacs-term.desktop file. There's an answer
saying:

  This really depends on what's interpreting the desktop entry file.
  Programs that use Glib, for instance, are unfortunately still stuck
  with a hard-coded list of terminal applications.

So this would really come from Firefox or a library it uses.
I can see that firefox depends on libglib2.0-0, but is it what
it uses to start applications?

Another answer mentions /etc/alternatives/x-terminal-emulator for
Debian-based systems, but here it is not used (it points to uxterm
as I've said).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Mike Hommey]

On Fri, Jan 07, 2022 at 02:04:01AM +0100, Vincent Lefevre wrote:
> On 2022-01-07 09:17:22 +0900, Mike Hommey wrote:
> > Rephrasing: the main question is why your config/Emacs's desktop
> > file/Emacs's configuration/whatever wants to use urxvt, because
> > Firefox won't do that on its own.
> 
> There's no mention of rxvt in
> /usr/share/applications/emacs-term.desktop
> 
> Anyway, this is Firefox that starts the application. Unfortunately,
> http://kb.mozillazine.org/File_types_and_download_actions and
> https://firefox-source-docs.mozilla.org/uriloader/exthandler/index.html
> are silent on this subject.

Firefox starts whatever glib tells it is in the desktop file. If the
command in the desktop file ends up running urxvt, it's not Firefox's
fault. If the desktop file says "Terminal=true" and glib tells Firefox
to run urxvt, it's not Firefox's fault.

Mike

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Vincent Lefevre]

On 2022-01-07 09:17:22 +0900, Mike Hommey wrote:
> Rephrasing: the main question is why your config/Emacs's desktop
> file/Emacs's configuration/whatever wants to use urxvt, because
> Firefox won't do that on its own.

There's no mention of rxvt in
/usr/share/applications/emacs-term.desktop

Anyway, this is Firefox that starts the application. Unfortunately,
http://kb.mozillazine.org/File_types_and_download_actions and
https://firefox-source-docs.mozilla.org/uriloader/exthandler/index.html
are silent on this subject.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1002600: firefox-esr: 91.4.1 unable to open any web (SSE2 again)

[NoSSE2]

Package: firefox-esr
Version: 91.4.1esr-1~deb11u1
Followup-For: Bug #1002600
X-Debbugs-Cc: karogyoker2+deb...@gmail.com

Dear Maintainer,

I have the same issue. I can't open any webpage, all crash instantly.
All of the reports show SIGILL / ILL_ILLOPN, here is one of them:
https://crash-
stats.mozilla.org/report/index/c402dee7-8941-48f1-a6d6-aa7390220107

I also have dmesg full of these lines:
[ 5061.277751] traps: Web Content[2013] trap invalid opcode ip:ad125c0d
sp:bfb40f5c error:0 in libxul.so[ac09a000+5844000]

It violates the i386 baseline by using SSE2 unconditionally, even if the host
CPU doesn't support it (tested on a downclocked Athlon XP).

I suggest that https://wiki.debian.org/SIMDEverywhere might be helpful in
developing a patch, if it isn't just a compiler flag fix.

If this issue/bug is unfixable, the package should depend on package
sse2-support (i386 only).

Workaround: use the epiphany-browser package (GNOME Web). That works without
SSE2.

cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm)
stepping: 0
cpu MHz : 1143.871
cache size  : 512 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch
vmmcall
bugs: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2
spec_store_bypass
bogomips: 2287.74
clflush size: 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts


-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Proxy Failover
Location: 
/home/user/.mozilla/firefox/59cnrgo2.default-esr/features/{846e0e2e-33ed-482e-a2cb-73452b541ea7}/proxy-failo...@mozilla.com.xpi
Status: enabled

Name: System theme theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr91.4.1esr-1~deb11u1 i386 Mozilla Firefox web browser 
- Extended Support Release (ESR)

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

Kernel: Linux 5.10.0-10-686-pae (SMP w/1 CPU thread)
Kernel taint flags: TAINT_WARN
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 firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  

Bug#1003252: AttributeError: install_layout

[Tomas Janousek]

Package: python3-setuptools
Version: 58.2.0-1
Severity: normal
X-Debbugs-CC: debian-pyt...@lists.debian.org

Since setuptools 60+ is out with SETUPTOOLS_USE_DISTUTILS defaulting to 
"local", pip install --editable in --system-site-packages venvs fails:

$ docker run --rm -it debian:sid
# apt update
# apt install git python3-setuptools python3-pip python3-venv
# cd /tmp
# git clone https://github.com/platformdirs/platformdirs
# cd platformdirs
# python3 -m venv --system-site-packages --without-pip .venv
# .venv/bin/python -m pip install -e .
Obtaining file:///tmp/platformdirs
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
Preparing wheel metadata ... done
Installing collected packages: platformdirs
  Running setup.py develop for platformdirs
ERROR: Command errored out with exit status 1:
 command: /tmp/platformdirs/.venv/bin/python -c 'import sys, 
setuptools, tokenize; sys.argv[0] = '"'"'/tmp/platformdirs/setup.py'"'"'; 
__file__='"'"'/tmp/platformdirs/setup.py'"'"';f=getattr(tokenize, 
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop 
--no-deps
 cwd: /tmp/platformdirs/
Complete output (30 lines):
running develop
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/platformdirs/setup.py", line 5, in 
setup()
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
153, in setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 148, in setup
dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 967, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 985, in run_command
cmd_obj.ensure_finalized()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 107, in ensure_finalized
self.finalize_options()
  File "/usr/lib/python3/dist-packages/setuptools/command/develop.py", 
line 52, in finalize_options
easy_install.finalize_options(self)
  File 
"/usr/lib/python3/dist-packages/setuptools/command/easy_install.py", line 293, 
in finalize_options
self.set_undefined_options(
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 287, in set_undefined_options
src_cmd_obj.ensure_finalized()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 107, in ensure_finalized
self.finalize_options()
  File 
"/usr/lib/python3/dist-packages/setuptools/command/install_lib.py", line 17, in 
finalize_options

self.set_undefined_options('install',('install_layout','install_layout'))
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 290, in set_undefined_options
setattr(self, dst_option, getattr(src_cmd_obj, src_option))
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 103, in __getattr__
raise AttributeError(attr)
AttributeError: install_layout

ERROR: Command errored out with exit status 1: 
/tmp/platformdirs/.venv/bin/python -c 'import sys, setuptools, tokenize; 
sys.argv[0] = '"'"'/tmp/platformdirs/setup.py'"'"'; 
__file__='"'"'/tmp/platformdirs/setup.py'"'"';f=getattr(tokenize, 
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop 
--no-deps Check the logs for full command output.

This happens even though setuptools 60 isn't in Debian yet, because pip 
downloads latest setuptools for pep517 installs that require setuptools 
in the build-system section of pyproject.yaml, but then fails to 
actually use that version fully (this is a bug in pip: 
https://github.com/pypa/pip/issues/6264).

I'll explain what's going on in detail further down, but first I'll 
present a simpler reproducer that illustrates why this might be a bug in 
Debian's setuptools packaging as well:

$ docker run --rm -it debian:sid
# apt update
# apt install git python3-setuptools python3-pip
# cd /tmp
# git clone https://github.com/platformdirs/platformdirs
# cd platformdirs
# SETUPTOOLS_USE_DISTUTILS=local python3 setup.py install
running install
Traceback (most recent call last):
  …
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 
103, in __getattr__
raise AttributeError(attr)
AttributeError: install_layout

Here we are explicitly using Debian's setuptools package, just telling it 
to use the 

Bug#1003251: uscan: mode=git + Files-Excluded is excessively slow

[Ben Hutchings]

Package: devscripts
Version: 2.21.7
Severity: normal

For the linux source package, debian/watch currently refers to
tarballs.  But there are no signed tarballs available for release
candidates.  To fix this, we could use mode=git, like so:

version=3
opts="mode=git, gitmode-shallow, pgpmode=gittag, uversionmangle=s|-rc|~rc|" \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 
refs/tags/v(.*) debian

There are also several files in the upstream source that we consider
non-free, so in any case the upstream source needs to be repacked.

The current behaviour of uscan in this configuration is:

1. Create a shallow, bare, git repository
2. Export an uncompressed tarball from git
3. Compress the first tarball with xz
4. Unpack the first compressed tarball
5. Delete the excluded files
6. Create a second compressed tarball

The size of the uncompressed source is over 1 GB, and it's being
compressed twice with xz, so this process takes a long time - nearly
20 minutes on my laptop.  Step 3 seems to be totally unnecessary in
this case, and I would like uscan to skip it if it is going to
repack the tarball.

Ben.

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBSIGN_KEYID=AC2B29BD34A6AFDDB3F68F35E7BFC8EC95861109
DEBUILD_DPKG_BUILDPACKAGE_OPTS='-uc -us'
DEBDIFF_CONTROLFILES=ALL

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 devscripts depends on:
ii  dpkg-dev  1.21.1
ii  fakeroot  1.26-1
ii  file  1:5.41-2
ii  gnupg 2.2.27-2
ii  gnupg22.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.33-1
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.59-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-6
ii  python3   3.9.8-1
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.3.13
ii  curl7.79.1-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2021.09.25
ii  dput1.1.0
ii  equivs  2.3.1
ii  libdistro-info-perl 1.1
ii  libdpkg-perl1.21.1
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-1
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.31-1
ii  liburi-perl 5.10-1
ii  licensecheck3.2.14-2
ii  lintian 2.114.0
ii  man-db  2.9.4-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.3.0+b1
ii  python3-debian  0.1.42
ii  python3-magic   2:0.4.24-2
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21.2-2+b1
ii  xz-utils5.2.5-2

Versions of packages devscripts suggests:
pn  adequate 
ii  at   3.1.23-1.1
ii  autopkgtest  5.19
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-2
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.5.2
ii  diffoscope   196
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  elpa-devscripts  40.5
ii  faketime 0.9.8-9
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1.1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
pn  libnet-smtps-perl
ii  libterm-size-perl0.211-1
ii  libtimedate-perl 2.3300-2
ii  libyaml-syck-perl1.34-1+b1
ii  mailutils [mailx]1:3.13-1
ii  mmdebstrap   0.8.1-1
pn  mozilla-devscripts   
ii  mutt 2.1.3-1
ii  

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Mike Hommey]

On Fri, Jan 07, 2022 at 12:43:55AM +0100, Vincent Lefevre wrote:
> On 2022-01-07 05:58:36 +0900, Mike Hommey wrote:
> > On Thu, Jan 06, 2022 at 10:39:17AM +0100, Vincent Lefevre wrote:
> > > If Firefox is started in a terminal, I can see:
> > > 
> > > Can't locate utf8.pm:   /usr/share/perl5/utf8.pm: Permission denied at 
> > > /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> > > BEGIN failed--compilation aborted at 
> > > /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> > > Compilation failed in require at -e line 1.
> > > BEGIN failed--compilation aborted at -e line 1.
> > > urxvt: unable to initialize perl-interpreter, continuing without.
> > 
> > Sounds like your terminal has a problem, not Firefox.
> 
> I don't know why urxvt is failing, but anyway, the main question
> is why Firefox wants to start urxvt, and not xterm (the terminal
> I normally use).

Rephrasing: the main question is why your config/Emacs's desktop
file/Emacs's configuration/whatever wants to use urxvt, because
Firefox won't do that on its own.

Mike

Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

[Henry Cejtin]

ssume that it isn't reproducible on AMD, right?
Or better, x86 (32 bit)?
One thing to try, under either of these, would be compiling stuff with
-codegen c
or, compiling the compiler with that.

The idea is that the HPPA stuff must use the C compiler back end.

On Thu, Jan 6, 2022 at 3:24 PM John David Anglin  wrote:
>
> Same issue with Linux overcommit turned off.  The machine is not running out 
> of memory and
> there is lots of swap (40G).
>
> Don't really know what's causing segfault.
>
> On 2022-01-06 3:27 p.m., Henry Cejtin wrote:
> > MLton understands about running out of memory, so it shouldn't just 
> > segfault.
> > If it isn't too hard, could you try it with Linux overcommit turned off?
> >
> > On Thu, Jan 6, 2022 at 1:57 PM John David Anglin  
> > wrote:
> >> Source: mlton
> >> Version: 20130715-3
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> Because of dependency problems mlton_20210117+dfsg-3 had to built
> >> manually on hppa.  However, it seems mlton_20210117+dfsg-3 cannot
> >> rebuild itself on hppa.
> >>
> >> See log:
> >> https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0
> >>
> >> It fails with a reproducible segmentation fault.  I noticed the compiler
> >> had allocated more than 2G at this point, so there was probably a memory
> >> allocation issue.  hppa is a 32-bit architecture.
> >>
> >> Regards,
> >> Dave Anglin
> >>
> >> -- System Information:
> >> Debian Release: bookworm/sid
> >>APT prefers buildd-unstable
> >>APT policy: (500, 'buildd-unstable'), (500, 'unstable')
> >> Architecture: hppa (parisc64)
> >>
> >> Kernel: Linux 5.16.0-rc8+ (SMP w/4 CPU threads)
> >> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> >> Shell: /bin/sh linked to /bin/dash
> >> Init: systemd (via /run/systemd/system)
> >>
>
>
> --
> John David Anglin  dave.ang...@bell.net
>

Bug#1003249: libqt5webenginecore5: i386 baseline violation

[NoSSE2]

Package: libqt5webenginecore5
Version: 5.15.2+dfsg-3
Severity: important
X-Debbugs-Cc: karogyoker2+deb...@gmail.com

Dear Maintainer,

I tried to start Konqueror on a fresh install of Debian by typing konqueror
into LXTerminal, it doesn't start, just crashes all the time.

It violates the i386 baseline by using SSE2 unconditionally, even if the host
CPU doesn't support it (tested on a downclocked Athlon XP).

I suggest that https://wiki.debian.org/SIMDEverywhere might be helpful in
developing a patch, if it isn't just a compiler flag fix.

If this issue/bug is unfixable, the package should depend on package
sse2-support (i386 only).

It crashes right after start and produces the below stack trace:
Application: Konqueror (konqueror), signal: Illegal instruction

[KCrash Handler]
#5  0x9cd81d4f in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#6  0x9cd83a2a in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#7  0x9cdd10a2 in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#8  0x9cd8bad4 in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#9  0x9cd8bb42 in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#10 0x9add9357 in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#11 0x9addb634 in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#12 0x9ad94447 in
QtWebEngineCore::ProfileAdapter::createDefaultProfileAdapter() () from
/lib/i386-linux-gnu/libQt5WebEngineCore.so.5
#13 0xa1a51f8b in QWebEngineProfile::defaultProfile() () from /lib/i386-linux-
gnu/libQt5WebEngineWidgets.so.5
#14 0xa1a9d7ed in WebEnginePart::WebEnginePart(QWidget*, QObject*, QByteArray
const&, QStringList const&) () from /lib/i386-linux-gnu/libkwebenginepart.so
#15 0xa1b3f7b1 in ?? () from /usr/lib/i386-linux-
gnu/qt5/plugins/kf5/parts/webenginepart.so
#16 0xb7e3896e in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#17 0xb7e23fa9 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#18 0xb7e13131 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#19 0xb7e18d62 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#20 0xb7e1d2e6 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#21 0xb7e584d7 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#22 0xb7e5a724 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#23 0xb7e6c5d0 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#24 0xb7e84268 in ?? () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#25 0xb7e86ea3 in kdemain () from /lib/i386-linux-gnu/libkdeinit5_konqueror.so
#26 0x00466087 in ?? ()
#27 0xb7c09e46 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#28 0x004660d1 in _start ()
[Inferior 1 (process 15864) detached]

Running with gdb konqueror gives the below result:
Thread 1 "konqueror" received signal SIGILL, Illegal instruction.
0x9ce37d4f in ?? () from /lib/i386-linux-gnu/libQt5WebEngineCore.so.5
(gdb) set disassembly-flavor intel
(gdb) x/i $eip
=> 0x9ce37d4f:  movq   QWORD PTR [ebp-0x4c],xmm0

cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm)
stepping: 0
cpu MHz : 1143.871
cache size  : 512 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch
vmmcall
bugs: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2
spec_store_bypass
bogomips: 2287.74
clflush size: 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts

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

Kernel: Linux 5.10.0-10-686-pae (SMP w/1 CPU thread)
Kernel taint flags: TAINT_WARN
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 libqt5webenginecore5 depends on:
ii  libasound21.2.4-1.1
ii  libavcodec58  7:4.3.3-0+deb11u1
ii  libavformat58 7:4.3.3-0+deb11u1
ii  libavutil56   7:4.3.3-0+deb11u1
ii  libc6 2.31-13+deb11u2
ii  libdbus-1-3   1.12.20-2
ii  libevent-2.1-72.1.12-stable-1
ii  libexpat1 2.2.10-2
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libharfbuzz0b 2.7.4-1
ii  libicu67 

Bug#1003248: E: "binary-with-bad-dynamic-table" and W: "elf-error In ELF header" issued for foreign-arch binaries

[Wookey]

Package: lintian
Version: 2.114.0
Severity: normal

I have a package (libopencsd) which has aarch64 elf binaries in some of its 
test-cases.
e.g 
https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-001/uname.bin/
https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-001/vdso.bin/

Lintian gives both an error and a warning about this file:
E: libopencsd source: binary-with-bad-dynamic-table 
[decoder/tests/snapshots/juno-uname-001/uname.bin]
W: libopencsd source: elf-error In ELF header: Reading 1728 bytes extends past 
end of file for section headers 
[decoder/tests/snapshots/juno-uname-001/uname.bin]

It also gives the warning about another file:
W: libopencsd source: elf-error In ELF header: Reading 896 bytes extends past 
end of file for section headers 
[decoder/tests/snapshots/juno-uname-001/vdso.bin]

nd then complains some more in a similar vein
W: libopencsd source: elf-error In ELF header: Section headers are not 
available! [decoder/tests/snapshots/juno-uname-001/uname.bin]
W: libopencsd source: elf-error In ELF header: Section headers are not 
available! [decoder/tests/snapshots/juno-uname-001/vdso.bin]
W: libopencsd source: elf-error In program headers: the dynamic segment offset 
+ size exceeds the size of the file 
[decoder/tests/snapshots/juno-uname-001/uname.bin]

For some reason I don't understand it does not complain about the same binaries 
in other test-cases:
https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-002/uname.bin/
https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/juno-uname-002/vdso.bin/
https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/test-file-mem-offsets/uname.bin/
https://sources.debian.org/src/libopencsd/1.1.1-2/decoder/tests/snapshots/test-file-mem-offsets/vdso.bin/

I presume that if binutils for the foreign arch was installed this
error would not appear.  I think that lintian should either install
the right tools for running this test on foreign-arch binaries, or it
should not try to check foregn-arch binaries.

There is a separate issue about whether these files count as
'source-is-missing' binaries, but that's independent of the above
issue, which seems to me to be a lintian bug.

--
Wookey

Bug#1002604: RFS: tapecalc/20211222-2 [ITA] [RC] -- full-screen tape editor that lets the user edit a calculation

[Bastian Germann]

Can you please explain what you try to do with the Salsa CI?
Why don't you just use the default pipelines?

Bug#1003247: mailman3-web: Mailman3 not working following distribution upgrade from Debian 10 to 11.

[Gordon Dickens]

Package: mailman3-web
Version: 0+20200530-2
Severity: important

Dear Maintainer,

I performed a distribution upgrade from Debian 10 Buster (which runs mailman 
3.2.1) to Debian 11 Bullseye (which runs mailman
3.3.1) with the command "apt-get full-upgrade -y" and everything apparently 
worked properly except at the end of the upgrade when
the following error dialog was generated by the mailman3-web and mailman3-full 
post-installation scripts:

Setting up mailman3-web (0+20200530-2) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
dbconfig-common: flushing administrative password
sed: -e expression #2, char 77: unterminated `s' command
dpkg: error processing package mailman3-web (--configure):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 1
dpkg: dependency problems prevent configuration of mailman3-full:
 mailman3-full depends on mailman3-web; however:
  Package mailman3-web is not configured yet.

dpkg: error processing package mailman3-full (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mailman3-web
 mailman3-full
E: Sub-process /usr/bin/dpkg returned an error code (1)

Now, every time that I execute "apt-get upgrade" then I continue to get the 
above error dialog.  Also, the command
"dpkg-reconfigure mailman3-web" generates this output:

/usr/sbin/dpkg-reconfigure: mailman3-web is broken or not fully installed

So, I am now stuck since apt-get is saying that mailman3-web is not configured 
yet, however, neither apt-get nor dpkg-reconfigure
will successfully configure mailman3-web.

Note the syntax error statement from the above dialog which may be the culprit: 
"sed: -e expression #2, char 77: unterminated `s' command"

Does anybody have any idea how to fix this?  I would very much appreciate some 
suggestions.

Thanks,

Gordon Dickens


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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-mysql 2.0.19
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  python3-django-hyperkitty  1.3.4-4
ii  python3-django-postorius   1.3.4-2+deb11u1
ii  python3-mysqldb1.4.4-2+b3
ii  python3-psycopg2   2.8.6-2
ii  python3-whoosh 2.7.4+git6-g9134ad92-5
ii  ucf3.0043
ii  uwsgi-core 2.0.19.1-7.1
ii  uwsgi-plugin-python3   2.0.19.1-7.1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.52-1~deb11u2

Versions of packages mailman3-web suggests:
ii  default-mysql-server1.0.7
ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.12-0+deb11u1

-- Configuration Files:
/etc/mailman3/apache.conf changed:
Alias /mailman3/favicon.ico 
/var/lib/mailman3/web/static/postorius/img/favicon.ico
Alias /mailman3/static  /var/lib/mailman3/web/static

Require all granted


ProxyPass /mailman3/favicon.ico !
ProxyPass /mailman3/static !
ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost



-- debconf information:
  mailman3-web/pgsql/changeconf: false
  mailman3-web/remote/host: localhost
  mailman3-web/dbconfig-remove: true
  mailman3-web/internal/skip-preseed: false
  mailman3-web/db/basepath: /var/lib/mailman3/web
  mailman3-web/upgrade-error: abort
* mailman3-web/database-type: mysql
  mailman3-web/pgsql/no-empty-passwords:
* mailman3-web/superuser-name: gordon
* mailman3-web/db/app-user: mailman3web@localhost
  mailman3-web/passwords-do-not-match:
* mailman3-web/db/dbname: mailman3web
  mailman3-web/missing-db-package-error: abort
* mailman3-web/superuser-mail: gor...@mailhub4u.com
  mailman3-web/install-error: abort
  mailman3-web/pgsql/method: TCP/IP
  mailman3-web/mysql/authplugin: default
  mailman3-web/nginx-choice:
  mailman3-web/dbconfig-upgrade: true
  mailman3-web/pgsql/admin-user: postgres
  mailman3-web/pgsql/authmethod-admin: ident
* mailman3-web/mysql/method: Unix socket
* mailman3-web/emailname: host2.mailhub4u.com
  mailman3-web/pgsql/authmethod-user: password
  mailman3-web/remote/port:
  mailman3-web/remove-error: abort
* mailman3-web/restart-webserver: true
  mailman3-web/pgsql/manualconf:
  mailman3-web/dbconfig-reinstall: false
* mailman3-web/dbconfig-install: true
  mailman3-web/purge: false
  mailman3-web/internal/reconfiguring: false
* mailman3-web/mysql/admin-user: debian-sys-maint
  

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Vincent Lefevre]

On 2022-01-07 05:58:36 +0900, Mike Hommey wrote:
> On Thu, Jan 06, 2022 at 10:39:17AM +0100, Vincent Lefevre wrote:
> > If Firefox is started in a terminal, I can see:
> > 
> > Can't locate utf8.pm:   /usr/share/perl5/utf8.pm: Permission denied at 
> > /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> > BEGIN failed--compilation aborted at 
> > /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> > Compilation failed in require at -e line 1.
> > BEGIN failed--compilation aborted at -e line 1.
> > urxvt: unable to initialize perl-interpreter, continuing without.
> 
> Sounds like your terminal has a problem, not Firefox.

I don't know why urxvt is failing, but anyway, the main question
is why Firefox wants to start urxvt, and not xterm (the terminal
I normally use).

This is even not what x-terminal-emulator points to:

lrwxrwxrwx 1 root root 15 2015-10-26 13:32:50 
/etc/alternatives/x-terminal-emulator -> /usr/bin/uxterm*

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003181: cython: sparc64 is not building cython ("Not For Us")

[Drew Parsons]

On 2022-01-06 23:00, John Paul Adrian Glaubitz wrote:

On 1/6/22 22:54, Drew Parsons wrote:

I will build the current version manually for now with the testsuite
disabled and
upload the package.


Thanks Adrian.  I guess disabling tests permanently for sparc64 is a 
reasonable

(if regrettable) work-around if they continue to cause trouble.


We could also ask the maintainer to disable the testsuite on sparc64.


Well yes, that's what I meant :)  Easy enough to do in-package.

Bug#993515: catch: FTBFS with glibc 2.34

[Aurelien Jarno]

On 2021-09-02 14:37, Graham Inggs wrote:
> Source: catch
> Version: 1.12.1-1.1
> Severity: important
> 
> Hi Maintainer
> 
> Catch will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and
> SIGSTKSZ no longer being defined.
> 
> This was fixed Catch2's upstream [1].  I'm not sure if this can be
> adapted for Catch(1).
> Another approach is to simply replace SIGSTKSZ with a constant, as
> done in Fedora [2].

Please note that glibc 2.34 is available in experimental for a few
weeks. It should ease testing the fix.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1000966: amdgpu: output to VR headset fails with "*ERROR* dc_stream_state is NULL for crtc '1'!"

[Claire]

This also occurs using linux-image-5.15.0-2-amd64 and 
linux-image-5.16.0-rc8-amd64.

Bug#1003080: RFS: lsb-release-minimal/0.2-2 [ITP] -- Linux Standard Base version reporting utility (minimal implementation)

[Bastian Germann]

Control: tags -1 moreinfo

On Mon, 3 Jan 2022 20:01:40 +0100 Gioele Barabucci  wrote:
Changes for the initial release (the previous versions have not been 
released):


lsb-release-minimal (0.2-2) UNRELEASED; urgency=medium

   * debian/control: Move Git repo to salsa.debian.org
   * debian/watch: Change watch URL to salsa.debian.org
   * debian/copyright: Align with dh_make template
   * debian/copyright: Update copyright year to 2022
   * debian/changelog: Fix previous releases

lsb-release-minimal (0.2-1) experimental; urgency=medium

   * New upstream release v0.2
   * debian/control: Add Homepage field
   * debian/control: Update Standards-Version (no changes)
   * debian/gbp: Use same branch settings for all commands
   * debian/watch: Fix filenamemangle

lsb-release-minimal (0.1-1) experimental; urgency=medium

   * Initial upstream release (Closes: #1002831)


Please do not target UNRELEASED with ITP uploads and only have -1 revision with 
one entry closing the ITP:

lsb-release-minimal (0.2-1) experimental; urgency=medium

  * Initial upstream release (Closes: #1002831)


When you are done, untag moreinfo from this bug.

Bug#1003223: buildd.debian.org: exFAT do no work on internal hard drives.

[Aurelien Jarno]

control: reassign -1 src:linux

On 2022-01-06 16:07, Mats Lundström wrote:
> Package: buildd.debian.org

exfat support is provided by the kernel and has nothing to do with
buildd.debian.org. Reassigning the bug there.

> Severity: important
> X-Debbugs-Cc: t...@digitronics.se
>
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> 
> I am trying to migrate from Windows to Linux due to security, performance and 
> hardware compatibility issues. Some of the software that I use, are available 
> both in 
> Linux and Windows, so I have been doing some performance tests. Fastest is 
> Linux (tried Lubuntu, Ubuntu and Debian and it don't matter which one), just 
> followed by
> Windows 7. Windows 10 is way behind, due to constant external communication 
> with unknown source (have seen this clearly at my work) and sometimes forced 
> reboots due
> to forced system updates (this can't be tured off in Windows 10 ...) The 
> latter is a problem, when running software 24/7 that can't resume properly at 
> reboot without
> manual interaction. If this happen when at work or during the night, the 
> computer will idle. Windows 7 (SP1) is in many ways better than Windows 10, 
> but have issues
> when trying to install it on newer systems. (Systems with i5/i7/i9 and 
> chipset Z490/Z590 blocks any Windows 7 installation ...) With 35.5 years of 
> [prof.] hardware
> and software experience, I am still convinced that Windows 7 is the best 
> Windows version, despite some would say that it lacks security. By own 
> experience, Windows
> 10 isn't actually any better though, but rather worse.
> 
> 
>* What exactly did you do (or not do) that was effective (or ineffective)?
> 
> I do stuff, including professional work related, that still are only possible 
> on Windows computers. Therefore I intend to create a dual boot system and 
> need a hard
> drive with data, that can be read properly by both Linux and Windows. A hard 
> drive that uses NTFS have issues in Linux and a hard drive that uses ext4 is 
> basically
> ignored in Windows (it detects all the partitions though). Using the hard 
> drive with exFAT via USB works, but have stability, mechanical and formost 
> performance
> issues - no go.
> 
> 
>* What was the outcome of this action?
> 
> A complete 'read only' status, that can not be changed what so ever, even 
> logged in as root. Owner of the drive is 'root' and can not be changed 
> either. Have tried
> to fix the problem with a number of HDD utilities, but none of them can do 
> much at all. (Installing a Debian based OS has not been easy, because of 
> reports of assumed
> PCIe [8086: - lost this specific address, unfortunally ...] and MMIO 
> errors with the i9/Z590 system. OS's like Windows, CentOS/Red Hat, OpenSUSE 
> do not detect
> this at all ... OpenSUSE have severe issues with Nvidia drivers ...) Files 
> can be copied to the system drive and edited there, but can only be copied 
> back as a
> duplicate copy. Soon the hard drive will be filled with a number of copies 
> ... (The fastest way to fix this, is to clean up in Windows ...) Have tried 
> to transfer
> the data to new hard drive, to exclude any issues with the hard drive itself, 
> but no difference.
> 
> 
>* What outcome did you expect instead?
> 
> A 'read/write' status. This is somewhat surprising that exFAT has not been 
> included earlier, as the standard has existed since 2006. A hard drive that 
> only can be
> used as 'read only' makes no sense.
> 
> 
> Regards
> 
> Mats Lundström

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1002072: RFS: vkd3d/1.2-6.1 [NMU] -- Direct3D 12 to Vulkan translation - shader compiler

[Bastian Germann]

On Tue, 21 Dec 2021 14:15:20 +0100 Maxime Lombard  wrote:

Changes since the last upload:

vkd3d (1.2-6.1) unstable; urgency=medium
.
* Non-maintainer upload.
* Disable tests since it fails with mesa-vulkan-drivers.
- Bug reported upstream : https://bugs.winehq.org/show_bug.cgi?id=52248
* Delete requirement of mesa-vulkan-drivers before version 21.


Please note that your request was closed. That was an automated event.
I would have closed it because the package is team maintained.
Please try to work with the team. NMU if they do not respond (not on the addressed bugs but on their mailing list/IRC) 
and document lack of response.

Bug#1003246: ruby-httpclient: Typo in package description

[Thomas Vincent]

Package: ruby-httpclient
Severity: minor

Dear Maintainer,

While reviewing the french translation of ruby-httpclient's package 
description, I noticed a typo in its english version.
Indeed, in "Negotiate/NTLM auth for WWW-Authenticate (requires net/htlm 
module)", I believe it should be "ntlm" instead of "htlm".

This typo probably comes from the upstream description, where is has been fixed 
some time ago: 
https://github.com/nahi/httpclient/commit/280ecfb4bbc24ead1b2b699195ac7a1c4b7a706d

Thanks for maintaining ruby-httpclient!

Best regards,
Thomas


-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-httpclient depends on:
ii  ca-certificates   20210119
ii  ruby  1:2.7+2
pn  ruby-http-cookie  

ruby-httpclient recommends no packages.

ruby-httpclient suggests no packages.

Bug#1003245: release-notes: sections in Upgrade guide could be ordered more usefully

[Peter van Dijk]

Package: release-notes
Severity: normal
X-Debbugs-Cc: pe...@7bits.nl

Dear Maintainer,

as I was upgrading a system from Debian 10 to Debian 11, I dutifully read 
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html

I ran into 4.2.7 (The security section) and 4.2.8 (The proposed-updates 
section). They contain relevant information that I was happy to receive. 
However, this information comes some time before the point that I am actually 
editing sources.list files.

My suggestion: put these two explanations early in 4.3 - either as extra 
sentences after "add sources for bullseye and typically to remove sources for 
buster." or as extra sections between what currently is 4.3 (Preparing APT 
source-list files) and 4.3.1 (Adding APT Internet sources).

Thank you.

Bug#1003244: openssh-client: ssh_config manpage has conflicting information about Debian-specific changes to defaults

[Peter van Dijk]

Package: openssh-client
Version: 1:8.4p1-5
Severity: normal
X-Debbugs-Cc: pe...@7bits.nl

Dear Maintainer,

   * What led up to the situation?

After upgrading to Debian 11, using ssh to connect to one of my machines took a 
very long time.
The time is spent in:

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

This happens twice and takes a total of around 100 seconds. The first few tries 
I figured my VM had
half-died because ssh just sat there.

After a while I figured out disabling GSSAPIAuthentication helped. But the 
manpage is confusing.

ssh_config(5) says:

 GSSAPIAuthentication
 Specifies whether user authentication based on GSSAPI is allowed.  
The default is no.

it also says:

 Note that the Debian openssh-client package sets several options as 
standard in
 /etc/ssh/ssh_config which are not the default in ssh(1):

   o   Include /etc/ssh/ssh_config.d/*.conf
   o   SendEnv LANG LC_*
   o   HashKnownHosts yes
   o   GSSAPIAuthentication yes

but I usually search manpages, not read them end to end. So, the bit about 
Debian defaults being different is very hard to miss. Perhaps the sections on 
those four options could grow a few words repeating the changes that Debian did.


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

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.20.9
ii  libc6 2.31-13+deb11u2
ii  libedit2  3.1-20191231-2+b1
ii  libfido2-11.6.0-2
ii  libgssapi-krb5-2  1.18.3-6+deb11u1
ii  libselinux1   3.1-3
ii  libssl1.1 1.1.1k-1+deb11u1
ii  passwd1:4.8.1-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.1-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- Configuration Files:
/etc/ssh/ssh_config changed:
Include /etc/ssh/ssh_config.d/*.conf
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication no


-- no debconf information

Bug#1003181: cython: sparc64 is not building cython ("Not For Us")

[John Paul Adrian Glaubitz]

On 1/6/22 22:54, Drew Parsons wrote:
>> I will build the current version manually for now with the testsuite
>> disabled and
>> upload the package.
> 
> Thanks Adrian.  I guess disabling tests permanently for sparc64 is a 
> reasonable
> (if regrettable) work-around if they continue to cause trouble.

We could also ask the maintainer to disable the testsuite on sparc64.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003181: cython: sparc64 is not building cython ("Not For Us")

[Drew Parsons]

On 2022-01-06 22:38, John Paul Adrian Glaubitz wrote:

Hello!

On 1/5/22 18:02, Drew Parsons wrote:
cython previously built on sparc64 for bullseye (stable) at version 
0.29.21-3


Now (for version 0.29.24-2), cython is marked "Not For Us" on sparc64
and is no longer building.


The package is currently blocked on sparc64 because the testsuite kept 
crashing
the host system and no solution was found yet. It seems that the 
testsuite will
put a lot of strain on the host system when the machine has many CPU 
cores which

is true for most sparc64 systems we use.

...

I will build the current version manually for now with the testsuite
disabled and
upload the package.



Thanks Adrian.  I guess disabling tests permanently for sparc64 is a 
reasonable (if regrettable) work-around if they continue to cause 
trouble.


Drew

Bug#1003242: Versions ...

[Peter Chubb]

I think the issue is that python3-django-hyperkitty 1.3.5-1 has this
change:
Pass the secret archiver key in a HTTP Authorization header
instead of a GET query parameter so it doesn’t appear in
logs. (CVE-2021-35058, Closes #387)

See also:
https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/WSUEPQL6PX52Y7XVWYSSGJJXC7E3F6FG/

So to upgrade to python3-django-hyperkitty 1.3.5-1 you must also
upgrade python3-mailman-hyperkitty to 1.2.0; version 1.1.10 should
conflict with python3-django-hyperkitty versions < 1.3.5
-- 
Dr Peter Chubbhttps://trustworthy.systems/
Trustworthy Systems GroupCSE, UNSW

Bug#1003243: wordpress: WordPress 5.8.3 Security Release

[Craig Small]

Package: wordpress
Version: 5.8.2+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

WordPress have released version 5.8.3 which fixes 4 security bugs.
https://wordpress.org/news/2022/01/wordpress-5-8-3-security-release/

 * An issue with stored XSS through post slugs.
   CVE-2022-21662 - Stored XSS through authenticated users
   
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-699q-3hj9-889w
   https://hackerone.com/reports/425342


 * An issue with Object injection in some multisite installations.
   CVE-2022-21663 - Authenticated Object Injection in Multisites
   
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-jmmq-m8p8-332h
   https://hackerone.com/reports/541469


 * A SQL injection vulnerability in WP_Query.
   CVE-2022-21661 - WordPress: SQL Injection through WP_Query
   
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-6676-cqfm-gw84
   https://hackerone.com/reports/1378209

 * A SQL injection vulnerability in WP_Meta_Query
   CVE-2022-21664 - SQL injection due to improper sanitization in WP_Meta_Query
   
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-jp3p-gw8h-6x86

Bug#1003181: cython: sparc64 is not building cython ("Not For Us")

[John Paul Adrian Glaubitz]

Hello!

On 1/5/22 18:02, Drew Parsons wrote:
> cython previously built on sparc64 for bullseye (stable) at version 0.29.21-3
> 
> Now (for version 0.29.24-2), cython is marked "Not For Us" on sparc64
> and is no longer building.

The package is currently blocked on sparc64 because the testsuite kept crashing
the host system and no solution was found yet. It seems that the testsuite will
put a lot of strain on the host system when the machine has many CPU cores which
is true for most sparc64 systems we use.

> python3.10 is still building for sparc64.  A lot of python packages
> need cython, it would be a shame not to let them be available any
> more.

I will build the current version manually for now with the testsuite disabled 
and
upload the package.

The sparc64 porterbox is currently offline but it will be replaced with a newer,
faster one within the next weeks. The new server has already been acquired. Then
we can have another look at the package and maybe figure out how to fix the 
testsuite
issue.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003242: python3-mailman-hyperkitty: Need a newer version to match mailman core

[Peter Chubb]

Package: python3-mailman-hyperkitty
Version: 1.1.0-10
Severity: important

Dear Maintainer,

Since a routine apt upgrade, hyperkitty has stopped archiving emails.
In the log I see:

  Jan 07 00:36:18 2022 (3203621) Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 154
, in _archive_message
url = self._send_message(mlist, msg)
  File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 210
, in _send_message
raise ValueError(result.text)
ValueError: Auth required
Authorization RequiredThe archiver key is now
 required to be sent over the Authorization HTTP header.
 You need to upgrade the mailman-hyperkitty package to
 1.2.0 or newer.



looks like there are inconsistent packages. 
-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-cloud-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 python3-mailman-hyperkitty depends on:
ii  debconf [debconf-2.0]   1.5.79
ii  mailman33.3.3-1
ii  python3 3.9.8-1
ii  python3-pkg-resources   59.6.0-1
ii  python3-requests2.25.1+dfsg-2
ii  python3-zope.interface  5.4.0-1+b1
ii  ucf 3.0043

Versions of packages python3-mailman-hyperkitty recommends:
ii  mailman3-web   0+20200530-2
ii  python3-django-hyperkitty  1.3.5-1

python3-mailman-hyperkitty suggests no packages.

-- no debconf information

Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes

[Aurelien Jarno]

On 2022-01-06 05:36, Rich wrote:
> On Thu, Jan 6, 2022 at 5:22 AM Aurelien Jarno  wrote:
> 
> > On 2022-01-06 03:36, Rich wrote:
> > > Hi Aurelien,
> > > It's a VM running in qemu on an amd64 Debian bullseye system, no KVM
> > > acceleration to be found here.
> >
> > Ok, that might be a QEMU issue then. Which CPU do you emulate with QEMU?
> >
> 
> I don't explicitly specify a -M or -cpu, so whatever it defaults to, which
> according to -M help seems to be "pseries" mapping to pseries-6.1 here.

Thanks. That allowed me to reproduce the issue locally. I tracked down
it was due to the emulation of a POWER9 CPU, things work fine with a
POWER8 CPU. I found that it has been fixed recently in the upstream 2.33
branch:

https://sourceware.org/git/?p=glibc.git;a=commit;h=c493f6a0e4dcd6fff22da0df9fb2e52ecf41

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

[John David Anglin]

Same issue with Linux overcommit turned off.  The machine is not running out of 
memory and
there is lots of swap (40G).

Don't really know what's causing segfault.

On 2022-01-06 3:27 p.m., Henry Cejtin wrote:

MLton understands about running out of memory, so it shouldn't just segfault.
If it isn't too hard, could you try it with Linux overcommit turned off?

On Thu, Jan 6, 2022 at 1:57 PM John David Anglin  wrote:

Source: mlton
Version: 20130715-3
Severity: normal

Dear Maintainer,

Because of dependency problems mlton_20210117+dfsg-3 had to built
manually on hppa.  However, it seems mlton_20210117+dfsg-3 cannot
rebuild itself on hppa.

See log:
https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0

It fails with a reproducible segmentation fault.  I noticed the compiler
had allocated more than 2G at this point, so there was probably a memory
allocation issue.  hppa is a 32-bit architecture.

Regards,
Dave Anglin

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

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




--
John David Anglin  dave.ang...@bell.net

Bug#1003241: RFS: gtkcrypto/1.0.0-1 [ITP] -- GTK+ application for encrypting files and computing hashes

[Guilherme Xavier]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gtkcrypto":

 * Package name: gtkcrypto
   Version : 1.0.0-1
   Upstream Author : Paolo Stivanin 
 * URL : https://github.com/paolostivanin/GTKCrypto
 * License : GPL-3+
 * Vcs : [fill in URL of packaging vcs]
   Section : misc

It builds those binary packages:

  gtkcrypto - GTK+ application for encrypting files and computing hashes

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

 https://mentors.debian.net/package/gtkcrypto/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gtkcrypto/gtkcrypto_1.0.0-1.dsc

Changes since the last upload:

gtkcrypto (1.0.0-1) unstable; urgency=medium

  * Initial release (Closes: #1003217)


I would like whoever can do the sponsor also create the VCS and give
me access permission.
My user on salsa is: gplnx

Regards,
--
  Guilherme de Paula Xavier Segundo

Bug#977607: auto detect rollup.config.js and rollup -c package.json#scripts#build

[Yadd]

Hi,

this thing is ready for a while but desactivated. For now, pkg-js-tools 
only detects Gruntfile.js but doesn't fail if grunt fails. Proposition:

 - autodetect all (rollup.config.js, Gruntfile.js, tsconfig.json,...)
 - fail if build fails. Then only packages with these files and without
   an "override_dh_auto_build" will fail, so just a few list and
   probably some bad package (such as libjs-angular-file-upload which
   was not really DFSG)

There are too many packages to reverse-build for my little computer then 
I propose to:

 * upload these change in experimental,
 * wait a few days for test
 * push pkg-js-tools to unstable
 * fix all FTBFS that will appear (probably just a few list, at least
   an empty "override_dh_auto_build" will fix the problem)

Cheers,
Yadd

Bug#1003206: firefox: opening an unsupported text/* file with Emacs silently fails

[Mike Hommey]

On Thu, Jan 06, 2022 at 10:39:17AM +0100, Vincent Lefevre wrote:
> Package: firefox
> Version: 95.0.1-1
> Severity: normal
> 
> Opening an unsupported text/* file with Emacs silently fails.
> For instance, on https://homepages.loria.fr/PZimmermann/CORE-MATH/
> the link "glibc" for acos / binary32
> 
>   https://homepages.loria.fr/PZimmermann/CORE-MATH/acosf-v1.patch
> 
> is served as text/x-diff (as seen with wget, since this is not clear
> with Firefox). Since text/x-diff is not supported, Firefox proposes
> to open it with
> 
>   Emacs (Terminal) (default)
> 
> but nothing happens, not even an error message.
> 
> If Firefox is started in a terminal, I can see:
> 
> Can't locate utf8.pm:   /usr/share/perl5/utf8.pm: Permission denied at 
> /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm line 463.
> BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/urxvt/urxvt.pm 
> line 463.
> Compilation failed in require at -e line 1.
> BEGIN failed--compilation aborted at -e line 1.
> urxvt: unable to initialize perl-interpreter, continuing without.

Sounds like your terminal has a problem, not Firefox.

Mike

Bug#1003240: Acknowledgement (mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa)

[John David Anglin]

Yes.  Aside from being misaligned, any address in page 0 will fault.

On 2022-01-06 3:34 p.m., Henry Cejtin wrote:

Does the line
 [161519.338536] do_page_fault() command='mlton-compile' type=15
address=0x0002 in mlton-compile[1+12c9000]
mean it is trying to fetch from address 2???

On Thu, Jan 6, 2022 at 2:18 PM John David Anglin  wrote:

Some additional info:
[161513.075587] mlton-compile(27627): unaligned access to 0x08011ef9 at 
ip=0x00b53d73
[161513.365382] mlton-compile(27627): unaligned access to 0x08011ef9 at 
ip=0x00b53d73
[161519.322624] handle_unaligned: 67 callbacks suppressed
[161519.322668] mlton-compile(27627): unaligned access to 0x080908c9 at 
ip=0x00dbc84f
[161519.323263] mlton-compile(27627): unaligned access to 0x080908ce at 
ip=0x00dbc84f
[161519.326435] mlton-compile(27627): unaligned access to 0x08011d11 at 
ip=0x00dc13fb
[161519.329577] mlton-compile(27627): unaligned access to 0x08011d11 at 
ip=0x00db98cb
[161519.331724] mlton-compile(27627): unaligned access to 0x08011d11 at 
ip=0x00db98f3

[161519.338536] do_page_fault() command='mlton-compile' type=15 
address=0x0002 in mlton-compile[1+12c9000]
  trap #15: Data TLB miss fault
[161519.341747] CPU: 0 PID: 27627 Comm: mlton-compile Not tainted 5.16.0-rc8+ #1
[161519.341770] Hardware name: 9000/800/rp3440

[161519.341792]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[161519.341802] PSW: 01101010 Not tainted
[161519.341818] r00-03  00ff0006be0f 00010e10 0809874c 
012efdf0
[161519.341839] r04-07   838ede14 08055634 
012efe04
[161519.341855] r08-11  012f0014 012f00a0 08011f13 
100dcf74
[161519.341873] r12-15  012f0010 012f007c 08011f13 
012f0088
[161519.341890] r16-19  012f00b0 012f0044 100dcf70 
8829
[161519.341907] r20-23   08044828 00dfd2a8 
0006
[161519.341924] r24-27   08055628 012efdf0 
012d9110
[161519.341941] r28-31  0002  f9af49c0 

[161519.341959] sr00-03  06189000   
06189000
[161519.341978] sr04-07  06189000 06189000 06189000 
06189000

[161519.342006]   VZOUICununcqcqcqcqcqcrmunTDVZOUI
[161519.342016] FPSR: 1000110011101101
[161519.342026] FPER1: 
[161519.342037] fr00-03  8c0ed000   

[161519.342053] fr04-07  3b9aca00 61d72b58 16c7bfa123237000 
0001020c49ba
[161519.342070] fr08-11  0001   

[161519.342087] fr12-15     

[161519.342103] fr16-19     

[161519.342118] fr20-23    00410011 
0104
[161519.342137] fr24-27  3f7fc07f01fc07f0 41020bd8 41af2180 

[161519.342157] fr28-31  2deb33a075f5d1c1 6b17d1f2508fe882 d898c296 


[161519.342191] IASQ: 06189000 06189000 IAOQ: 00dc0ea7 
00dc0eab
[161519.342207]  IIR: 0f801094ISR: 06189000  IOR: 0002
[161519.342221]  CPU:0   CR30: 559f0430 CR31: 
[161519.342236]  ORIG_R28: 
[161519.342246]  IAOQ[0]: 00dc0ea7
[161519.342257]  IAOQ[1]: 00dc0eab
[161519.342267]  RP(r2): 0809874c

dc0e90:   0c 80 10 9c ldw 0(r4),ret0
dc0e94:   e8 1f 0f 05 b,l dc061c 
<_GLOBAL_OFFSET_TABLE_@@Base-0x52f788>,r0
dc0e98:   d0 95 1b c1 extrw,u r4,30,31,r21

dc0e9c:   4b c2 3e 59 ldw -d4(sp),rp
dc0ea0:   08 4b 04 15 sub r11,rp,r21
dc0ea4:   0f 80 10 94 ldw 0(ret0),r20
dc0ea8:   0d 74 12 99 stw r20,-4(r11)
dc0eac:   0f 95 12 80 stw r21,0(ret0)
dc0eb0:   0d 79 10 9c ldw -4(r11),ret0
dc0eb4:   d3 94 1b ff extrw,u ret0,31,1,r20
dc0eb8:   86 80 3f d7 cmpib,=,n 0,r20,dc0ea8 
<_GLOBAL_OFFSET_TABLE_@@Base-0x52eefc>
dc0ebc:   0f 80 10 94 ldw 0(ret0),r20
dc0ec0:   e8 1f 0b cd b,l dc04ac 
<_GLOBAL_OFFSET_TABLE_@@Base-0x52f8f8>,r0
dc0ec4:   d3 94 1b c1 extrw,u ret0,30,31,r20

Fault occurs on load "ldw 0(ret0),r20" instruction.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net




--
John David Anglin  dave.ang...@bell.net

Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

[John David Anglin]

How do I do that?

On 2022-01-06 3:27 p.m., Henry Cejtin wrote:

MLton understands about running out of memory, so it shouldn't just segfault.
If it isn't too hard, could you try it with Linux overcommit turned off?

On Thu, Jan 6, 2022 at 1:57 PM John David Anglin  wrote:

Source: mlton
Version: 20130715-3
Severity: normal

Dear Maintainer,

Because of dependency problems mlton_20210117+dfsg-3 had to built
manually on hppa.  However, it seems mlton_20210117+dfsg-3 cannot
rebuild itself on hppa.

See log:
https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0

It fails with a reproducible segmentation fault.  I noticed the compiler
had allocated more than 2G at this point, so there was probably a memory
allocation issue.  hppa is a 32-bit architecture.

Regards,
Dave Anglin

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

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




--
John David Anglin  dave.ang...@bell.net

Bug#1003240: Acknowledgement (mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa)

[Henry Cejtin]

Does the line
[161519.338536] do_page_fault() command='mlton-compile' type=15
address=0x0002 in mlton-compile[1+12c9000]
mean it is trying to fetch from address 2???

On Thu, Jan 6, 2022 at 2:18 PM John David Anglin  wrote:
>
> Some additional info:
> [161513.075587] mlton-compile(27627): unaligned access to 0x08011ef9 
> at ip=0x00b53d73
> [161513.365382] mlton-compile(27627): unaligned access to 0x08011ef9 
> at ip=0x00b53d73
> [161519.322624] handle_unaligned: 67 callbacks suppressed
> [161519.322668] mlton-compile(27627): unaligned access to 0x080908c9 
> at ip=0x00dbc84f
> [161519.323263] mlton-compile(27627): unaligned access to 0x080908ce 
> at ip=0x00dbc84f
> [161519.326435] mlton-compile(27627): unaligned access to 0x08011d11 
> at ip=0x00dc13fb
> [161519.329577] mlton-compile(27627): unaligned access to 0x08011d11 
> at ip=0x00db98cb
> [161519.331724] mlton-compile(27627): unaligned access to 0x08011d11 
> at ip=0x00db98f3
>
> [161519.338536] do_page_fault() command='mlton-compile' type=15 
> address=0x0002 in mlton-compile[1+12c9000]
>  trap #15: Data TLB miss fault
> [161519.341747] CPU: 0 PID: 27627 Comm: mlton-compile Not tainted 5.16.0-rc8+ 
> #1
> [161519.341770] Hardware name: 9000/800/rp3440
>
> [161519.341792]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [161519.341802] PSW: 01101010 Not tainted
> [161519.341818] r00-03  00ff0006be0f 00010e10 0809874c 
> 012efdf0
> [161519.341839] r04-07   838ede14 08055634 
> 012efe04
> [161519.341855] r08-11  012f0014 012f00a0 08011f13 
> 100dcf74
> [161519.341873] r12-15  012f0010 012f007c 08011f13 
> 012f0088
> [161519.341890] r16-19  012f00b0 012f0044 100dcf70 
> 8829
> [161519.341907] r20-23   08044828 00dfd2a8 
> 0006
> [161519.341924] r24-27   08055628 012efdf0 
> 012d9110
> [161519.341941] r28-31  0002  f9af49c0 
> 
> [161519.341959] sr00-03  06189000   
> 06189000
> [161519.341978] sr04-07  06189000 06189000 06189000 
> 06189000
>
> [161519.342006]   VZOUICununcqcqcqcqcqcrmunTDVZOUI
> [161519.342016] FPSR: 1000110011101101
> [161519.342026] FPER1: 
> [161519.342037] fr00-03  8c0ed000   
> 
> [161519.342053] fr04-07  3b9aca00 61d72b58 16c7bfa123237000 
> 0001020c49ba
> [161519.342070] fr08-11  0001   
> 
> [161519.342087] fr12-15     
> 
> [161519.342103] fr16-19     
> 
> [161519.342118] fr20-23    00410011 
> 0104
> [161519.342137] fr24-27  3f7fc07f01fc07f0 41020bd8 41af2180 
> 
> [161519.342157] fr28-31  2deb33a075f5d1c1 6b17d1f2508fe882 d898c296 
> 
>
> [161519.342191] IASQ: 06189000 06189000 IAOQ: 
> 00dc0ea7 00dc0eab
> [161519.342207]  IIR: 0f801094ISR: 06189000  IOR: 0002
> [161519.342221]  CPU:0   CR30: 559f0430 CR31: 
> [161519.342236]  ORIG_R28: 
> [161519.342246]  IAOQ[0]: 00dc0ea7
> [161519.342257]  IAOQ[1]: 00dc0eab
> [161519.342267]  RP(r2): 0809874c
>
>dc0e90:   0c 80 10 9c ldw 0(r4),ret0
>dc0e94:   e8 1f 0f 05 b,l dc061c 
> <_GLOBAL_OFFSET_TABLE_@@Base-0x52f788>,r0
>dc0e98:   d0 95 1b c1 extrw,u r4,30,31,r21
>
>dc0e9c:   4b c2 3e 59 ldw -d4(sp),rp
>dc0ea0:   08 4b 04 15 sub r11,rp,r21
>dc0ea4:   0f 80 10 94 ldw 0(ret0),r20
>dc0ea8:   0d 74 12 99 stw r20,-4(r11)
>dc0eac:   0f 95 12 80 stw r21,0(ret0)
>dc0eb0:   0d 79 10 9c ldw -4(r11),ret0
>dc0eb4:   d3 94 1b ff extrw,u ret0,31,1,r20
>dc0eb8:   86 80 3f d7 cmpib,=,n 0,r20,dc0ea8 
> <_GLOBAL_OFFSET_TABLE_@@Base-0x52eefc>
>dc0ebc:   0f 80 10 94 ldw 0(ret0),r20
>dc0ec0:   e8 1f 0b cd b,l dc04ac 
> <_GLOBAL_OFFSET_TABLE_@@Base-0x52f8f8>,r0
>dc0ec4:   d3 94 1b c1 extrw,u ret0,30,31,r20
>
> Fault occurs on load "ldw 0(ret0),r20" instruction.
>
> Regards,
> Dave Anglin
>
> --
> John David Anglin  dave.ang...@bell.net
>

Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.

[Cameron White]

This issue has been frequently reported upstream (I'm the upstream Pinta
maintainer) and seemed to be a bug in some versions of Mono / gtksharp.
Updating to the latest stable Mono release was reported to avoid the
crashes.
This is also obsolete with the recently-released Pinta 2.0, which uses
dotnet-runtime-6.0

Cameron

Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

[Henry Cejtin]

MLton understands about running out of memory, so it shouldn't just segfault.
If it isn't too hard, could you try it with Linux overcommit turned off?

On Thu, Jan 6, 2022 at 1:57 PM John David Anglin  wrote:
>
> Source: mlton
> Version: 20130715-3
> Severity: normal
>
> Dear Maintainer,
>
> Because of dependency problems mlton_20210117+dfsg-3 had to built
> manually on hppa.  However, it seems mlton_20210117+dfsg-3 cannot
> rebuild itself on hppa.
>
> See log:
> https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0
>
> It fails with a reproducible segmentation fault.  I noticed the compiler
> had allocated more than 2G at this point, so there was probably a memory
> allocation issue.  hppa is a 32-bit architecture.
>
> Regards,
> Dave Anglin
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
> Architecture: hppa (parisc64)
>
> Kernel: Linux 5.16.0-rc8+ (SMP w/4 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>

Bug#989816: snapd: snap-store does not work properly

[dylanmeca]

Package: snapd
Version: 2.49-1+b5
Followup-For: Bug #989816
X-Debbugs-Cc: dylanmec...@gmail.com

Dear maintainer, good afternoon, I have a problem in snap-store, this all 
started when I installed snap, I had no problem installing snap. But when I 
installed snap-store with snap at the end of the installation and execute the 
command snap-store I got this before the store opened:

WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement

I don't know what that error was due to, but when the store was opened, the 
application icons were blue icons with a gear, and there were only 8 
applications in the store, if I used the search engine to find other programs, 
I would not find them, they were only the 8 applications and from there there 
were no more, since it took too long to find, that circle that is loading 
appeared.

This problem is only the snap-store since the rest if it works correctly.

I appreciate your help. Greetings.

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

Kernel: Linux 5.10.0-10-amd64 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_PE.UTF-8, LC_CTYPE=es_PE.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_PE:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  gnupg2.2.27-2
ii  libapparmor1 2.13.6-10
ii  libc62.31-13+deb11u2
ii  libcap2  1:2.44-1
ii  libseccomp2  2.5.1-1+deb11u1
ii  libudev1 247.3-6
ii  openssh-client   1:8.4p1-5
ii  squashfs-tools   1:4.4-2+deb11u2
ii  systemd  247.3-6
ii  udev 247.3-6

Versions of packages snapd recommends:
ii  gnupg  2.2.27-2

Versions of packages snapd suggests:
ii  kdialog  4:20.12.0-1

-- no debconf information

Bug#962208: libtrace3: diff for NMU version 3.0.22-0.1

[Adrian Bunk]

On Fri, Jan 07, 2022 at 08:05:19AM +1300, Matt Brown wrote:
> Please go ahead.
>...

Thanks, rescheduled for immediate upload.

> Cheers

cu
Adrian

Bug#999069: console-cyrillic: diff for NMU version 0.9-17.2

[Adrian Bunk]

On Thu, Jan 06, 2022 at 09:22:59PM +0200, Anton Zinoviev wrote:
> On Tue, Jan 04, 2022 at 09:19:29AM +0200, Adrian Bunk wrote:
> > 
> > I've prepared an NMU for console-cyrillic (versioned as 0.9-17.2) and 
> > uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it.
> 
> Thanks.

Thanks, rescheduled for immediate upload.

> Anton Zinoviev

cu
Adrian

Bug#1003240: Acknowledgement (mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa)

[John David Anglin]

Some additional info:
[161513.075587] mlton-compile(27627): unaligned access to 0x08011ef9 at 
ip=0x00b53d73
[161513.365382] mlton-compile(27627): unaligned access to 0x08011ef9 at 
ip=0x00b53d73
[161519.322624] handle_unaligned: 67 callbacks suppressed
[161519.322668] mlton-compile(27627): unaligned access to 0x080908c9 at 
ip=0x00dbc84f
[161519.323263] mlton-compile(27627): unaligned access to 0x080908ce at 
ip=0x00dbc84f
[161519.326435] mlton-compile(27627): unaligned access to 0x08011d11 at 
ip=0x00dc13fb
[161519.329577] mlton-compile(27627): unaligned access to 0x08011d11 at 
ip=0x00db98cb
[161519.331724] mlton-compile(27627): unaligned access to 0x08011d11 at 
ip=0x00db98f3

[161519.338536] do_page_fault() command='mlton-compile' type=15 
address=0x0002 in mlton-compile[1+12c9000]
    trap #15: Data TLB miss fault
[161519.341747] CPU: 0 PID: 27627 Comm: mlton-compile Not tainted 5.16.0-rc8+ #1
[161519.341770] Hardware name: 9000/800/rp3440

[161519.341792]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[161519.341802] PSW: 01101010 Not tainted
[161519.341818] r00-03  00ff0006be0f 00010e10 0809874c 
012efdf0
[161519.341839] r04-07   838ede14 08055634 
012efe04
[161519.341855] r08-11  012f0014 012f00a0 08011f13 
100dcf74
[161519.341873] r12-15  012f0010 012f007c 08011f13 
012f0088
[161519.341890] r16-19  012f00b0 012f0044 100dcf70 
8829
[161519.341907] r20-23   08044828 00dfd2a8 
0006
[161519.341924] r24-27   08055628 012efdf0 
012d9110
[161519.341941] r28-31  0002  f9af49c0 

[161519.341959] sr00-03  06189000   
06189000
[161519.341978] sr04-07  06189000 06189000 06189000 
06189000

[161519.342006]   VZOUICununcqcqcqcqcqcrmunTDVZOUI
[161519.342016] FPSR: 1000110011101101
[161519.342026] FPER1: 
[161519.342037] fr00-03  8c0ed000   

[161519.342053] fr04-07  3b9aca00 61d72b58 16c7bfa123237000 
0001020c49ba
[161519.342070] fr08-11  0001   

[161519.342087] fr12-15     

[161519.342103] fr16-19     

[161519.342118] fr20-23    00410011 
0104
[161519.342137] fr24-27  3f7fc07f01fc07f0 41020bd8 41af2180 

[161519.342157] fr28-31  2deb33a075f5d1c1 6b17d1f2508fe882 d898c296 


[161519.342191] IASQ: 06189000 06189000 IAOQ: 00dc0ea7 
00dc0eab
[161519.342207]  IIR: 0f801094    ISR: 06189000  IOR: 0002
[161519.342221]  CPU:    0   CR30: 559f0430 CR31: 
[161519.342236]  ORIG_R28: 
[161519.342246]  IAOQ[0]: 00dc0ea7
[161519.342257]  IAOQ[1]: 00dc0eab
[161519.342267]  RP(r2): 0809874c

  dc0e90:   0c 80 10 9c ldw 0(r4),ret0
  dc0e94:   e8 1f 0f 05 b,l dc061c 
<_GLOBAL_OFFSET_TABLE_@@Base-0x52f788>,r0
  dc0e98:   d0 95 1b c1 extrw,u r4,30,31,r21

  dc0e9c:   4b c2 3e 59 ldw -d4(sp),rp
  dc0ea0:   08 4b 04 15 sub r11,rp,r21
  dc0ea4:   0f 80 10 94 ldw 0(ret0),r20
  dc0ea8:   0d 74 12 99 stw r20,-4(r11)
  dc0eac:   0f 95 12 80 stw r21,0(ret0)
  dc0eb0:   0d 79 10 9c ldw -4(r11),ret0
  dc0eb4:   d3 94 1b ff extrw,u ret0,31,1,r20
  dc0eb8:   86 80 3f d7 cmpib,=,n 0,r20,dc0ea8 
<_GLOBAL_OFFSET_TABLE_@@Base-0x52eefc>
  dc0ebc:   0f 80 10 94 ldw 0(ret0),r20
  dc0ec0:   e8 1f 0b cd b,l dc04ac 
<_GLOBAL_OFFSET_TABLE_@@Base-0x52f8f8>,r0
  dc0ec4:   d3 94 1b c1 extrw,u ret0,30,31,r20

Fault occurs on load "ldw 0(ret0),r20" instruction.

Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#999069: console-cyrillic: diff for NMU version 0.9-17.2

[Anton Zinoviev]

On Tue, Jan 04, 2022 at 09:19:29AM +0200, Adrian Bunk wrote:
> 
> I've prepared an NMU for console-cyrillic (versioned as 0.9-17.2) and 
> uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it.

Thanks.

Anton Zinoviev

Bug#1003012: Accepted bash 5.1-6 (source) into unstable

[Salvatore Bonaccorso]

Source: bash
Source-Version: 5.1-6

On Thu, Jan 06, 2022 at 04:48:44PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Thu, 06 Jan 2022 17:16:52 +0100
> Source: bash
> Architecture: source
> Version: 5.1-6
> Distribution: unstable
> Urgency: medium
> Maintainer: Matthias Klose 
> Changed-By: Matthias Klose 
> Changes:
>  bash (5.1-6) unstable; urgency=medium
>  .
>* Apply upstream patches 013 - 016.

patch 014 is for the upstream issue
https://savannah.gnu.org/patch/?10035, so addressing #1003012.

Closing the bugreport.

Regards,
Salvatore

Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

[John David Anglin]

Source: mlton
Version: 20130715-3
Severity: normal

Dear Maintainer,

Because of dependency problems mlton_20210117+dfsg-3 had to built
manually on hppa.  However, it seems mlton_20210117+dfsg-3 cannot
rebuild itself on hppa.

See log:
https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0

It fails with a reproducible segmentation fault.  I noticed the compiler
had allocated more than 2G at this point, so there was probably a memory
allocation issue.  hppa is a 32-bit architecture.

Regards,
Dave Anglin

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

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

Bug#997841: thunderbird: ignores locale settings

[Carsten Schoenert]

Control: tags -1 pending

Hi Ángel, hello Михаил,

Am 06.01.22 um 20:07 schrieb Ángel:

This patch was changed on 30d1d481:

https://salsa.debian.org/mozilla-team/thunderbird/-/commit/30d1d481403f6fadd363da6796839582fa4750e0#533b8cf491d78f20026b4b74e666a86d89407ab8

On thunderbird 78 toolkit/xre/nsXREDirProvider.cpp had no
MOZ_BACKGROUNDTASKS blocks, and it wasn't an issue.
(note that looking just at the patch is slightly misleading, since it
shows a #ifdef and a #endif which are not paired)

Both patches apply to nsXREDirProvider::GetFilesInternal() but after
30d1d481 the LoadDirIntoArray(mXULAppDir, kAppendSysPrefDir...) appears
inside the MOZ_BACKGROUNDTASKS.
The patch by Михаил seems the right way to solve it, by moving that
line just above #ifdef MOZ_BACKGROUNDTASKS.

The patch itself is not consistent since, even if MOZ_BACKGROUNDTASKS
was defined, kAppendSysPrefDir is only used if MOZ_BACKGROUNDTASKS  but
declared always (I expect this would cause a compiler warning).


the analysis from both from you is correct, thanks for figuring out this!
I've compared the used patch with the one from firefox and they differ 
slightly.


https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/sid/debian/patches/debian-hacks/Add-another-preferences-directory-for-applications-p.patch

https://salsa.debian.org/mozilla-team/firefox/-/commit/286df5563f1c52e56c44918da01643add87fb3c6?view=inline

The wrong adjustment of patch was obviously happen while the the first 
pre version for TB 91 was merged in. As mostly only a small amount of 
people do using experimental to test newer package versions nobody 
detected this problem early.


I've adjusted the patch in question locally, but need to do some more 
testing before pushing to the tree.


--
Regards
Carsten

Bug#1003158: [pkg-apparmor] Bug#1003158: apparmor: tunables/home seems to have wrong order of variables

[Christian Boltz]

Hello,

Am Mittwoch, 5. Januar 2022, 23:09:01 CET schrieb Karsten Hilbert:
> Unless I misunderstand apparmor profile logic it is not
> purely cosmetic. It excludes "/home/*/" from @{HOME}.

That's the difference between a human parser (you) and apparmor_parser 
;-) - you think of the profile as "code" (where order matters) while 
apparmor_parser (mostly) doesn't care about the order.

I'll try to explain how apparmor_parser works using pseudo-SQL:


Step 1: read tunables/home

@{HOME}=@{HOMEDIRS}/*/ /root/

-> INSERT INTO variables VALUES ( '@{HOME}', '@{HOMEDIRS}/*/ /root/');

@{HOMEDIRS}=/home/

-> INSERT INTO variables VALUES ( '@{HOMEDIRS}', '/home/');

Now we have the two variables in the variables database.
Note that @{HOME} was stored "raw", without expanding the embedded 
variable. Therefore the order of the variable declaration (or INSERT 
commands) doesn't matter.


Step 2: if a rule uses one of the variables:

@{HOME}/foo r,

apparmor_parser: "that rule contains a variable! Let's look it up..."

-> SELECT FROM variables WHERE name='@{HOME}';
Result: @{HOMEDIRS}/*/ /root/

apparmor_parser: "oh, that contains another variable, let's look it up 
too..."
-> SELECT FROM variables WHERE name='@{HOMEDIRS}';
Result: /home/

apparmor_parser: "and now let me replace that variable in @{HOME}..."
Original: @{HOMEDIRS}/*/ /root/# replace @{HOMEDIRS} with /home/
Result: /home/*/ /root/

apparmor_parser: "Looks good. That variable has two items, split it and 
update the rule..." (which gives us two rules, one for each variable 
item)
Result: /home/*/foo r, /root/foo r,


Does that help to understand what's going on?


Regards,

Christian Boltz

PS: The above is simplified (for example, it doesn't have "SQL" for 
extending variables with "+="). Also, apparmor_parser doesn't use 
SQL or a database internally - but the actual data structure/storage
is just a technical detail you can ignore for now.
Also, inserting the variables into the rule will give you 
alternations (not multiple rules), but that's also just a technical 
detail.

One detail I didn't mention is that the replacement in step 2 is 
that slashes get de-duplicated so that you end up with /home/*/ 
instead of /home//*/ which you would get by blindly replacing the 
variable.

-- 
 darix: I need to go, let's continue tomorrow if you have 
time
 tomorrow i will be drunk or so
 darix: count on me for that state :-)
[from #opensuse-admin]


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

Bug#1003239: flameshot: the configuration contains an error

[Rock Storm]

Package: flameshot
Version: 11.0~rc1+ds1-2
Severity: normal
X-Debbugs-Cc: rockst...@gmx.com

Dear Maintainer,

After upgrading to version 11.0~rc1+ds1-2 straight from version
0.10.1+ds1-1, flameshot would not start throwing the following message:

flameshot: error: The configuration contains an error. Falling back to
default.


As suggested by @darxmurf [1], the following change in flameshot.ini
does the trick and flameshot starts normally.

-setSaveAsFileExtension=Portable Network Graphic file (PNG) (*.png)
+setSaveAsFileExtension=.png


This was already reported upstream [1], but thought I'd share here just
in case it rings any bells and/or helps other users.

[1]: https://github.com/flameshot-org/flameshot/issues/2232


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500,
'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages flameshot depends on:
ii  hicolor-icon-theme  0.17-2
ii  libc6   2.33-1
ii  libgcc-s1   11.2.0-13
ii  libqt5core5a    5.15.2+dfsg-14
ii  libqt5dbus5 5.15.2+dfsg-14
ii  libqt5gui5  5.15.2+dfsg-14
ii  libqt5network5  5.15.2+dfsg-14
ii  libqt5svg5  5.15.2-3
ii  libqt5widgets5  5.15.2+dfsg-14
ii  libstdc++6  11.2.0-13

Versions of packages flameshot recommends:
ii  grim    1.3.2+ds-1
ii  xdg-desktop-portal-gtk  1.12.0-1

Versions of packages flameshot suggests:
ii  ca-certificates  20211016
ii  openssl  1.1.1m-1

-- no debconf information

--
Rock Storm
Open PGP: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD

Bug#1003238: python3-astropy: circular dependencies

[Bill Allombert]

Package: python3-astropy
Version: 5.0-1
Severity: important

Hello Debian Astronomy Maintainers,

There is a circular dependency between python3-astropy, 
python3-pytest-arraydiff and python3-pytest-astropy:

python3-astropy :Depends: python3-pytest-astropy
python3-pytest-arraydiff:Depends: python3-astropy
python3-pytest-astropy  :Depends: python3-pytest-arraydiff

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1003193: Switch maintainer?

[Dirk Eddelbuettel]

On 6 January 2022 at 19:48, Adam Cécile wrote:
| On 1/5/22 10:39 PM, Dirk Eddelbuettel wrote:
| > Hi Adam,
| >
| > Would you be ok with me more formally adopting the package as maintainer?
| 
| Hello,
| 
| Absolutely no issue on my side. Who could be a better maintainer than 
| the upstream developer :-)

:-)

I do work mostly on the R bindings though (which I could / should / might)
package, not the C++ side.

Cool. So will proceed and try to sort things out. I only turned hdfs off as I
hoped it might help with unit test outcomes (it didn't) so I may turn that
back on.  I really want serialization in but need to wait for capnproto 0.8.0
to hit unstable / testing.  And I really want s3 support but that is more
complicated still.

Amicalement,  Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#997841: Info received (thunderbird: ignores locale settings)

[Ángel]

This patch was changed on 30d1d481:

https://salsa.debian.org/mozilla-team/thunderbird/-/commit/30d1d481403f6fadd363da6796839582fa4750e0#533b8cf491d78f20026b4b74e666a86d89407ab8

On thunderbird 78 toolkit/xre/nsXREDirProvider.cpp had no
MOZ_BACKGROUNDTASKS blocks, and it wasn't an issue.
(note that looking just at the patch is slightly misleading, since it
shows a #ifdef and a #endif which are not paired)

Both patches apply to nsXREDirProvider::GetFilesInternal() but after
30d1d481 the LoadDirIntoArray(mXULAppDir, kAppendSysPrefDir...) appears
inside the MOZ_BACKGROUNDTASKS.
The patch by Михаил seems the right way to solve it, by moving that
line just above #ifdef MOZ_BACKGROUNDTASKS.

The patch itself is not consistent since, even if MOZ_BACKGROUNDTASKS
was defined, kAppendSysPrefDir is only used if MOZ_BACKGROUNDTASKS  but
declared always (I expect this would cause a compiler warning).


Cheers

Bug#962208: libtrace3: diff for NMU version 3.0.22-0.1

[Matt Brown]

Please go ahead.

I haven't looked at your particular patches yet, but I've been trying to
make time to address these bugs without success over the last few weeks.

Thanks for your effort, I will do my best to follow-up with a further
tidy-up version, etc in due course.

Cheers


On Fri, Jan 7, 2022 at 5:22 AM Adrian Bunk  wrote:

> Control: tags 962208 + patch
> Control: tags 962208 + pending
> Control: tags 965694 + patch
> Control: tags 965694 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for libtrace3 (versioned as 3.0.22-0.1) and
> uploaded it to DELAYED/15. Please feel free to tell me if I should
> cancel it.
>
> cu
> Adrian
>


-- 
Matt Brown
m a...@debian.org
+64 20 4099 3329 www.mattb.net.nz

Bug#1003214: RFS: opencpn/5.6.0+dfsg0-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software

[Alec Leamas]

Hi Tobias,

On Thu, 06 Jan 2022 16:59:00 +0100 Tobias Frost  wrote:
> Control: tags -1 moreinfo
> 
> Hi Alec,

> if you dont remove it using Files-Excluded, you need to document libwxsvg's
> copyright in d/copyright...
>  


Indeed, good catch! I have uploaded a new build to mentors.

Cheers!
--alec

Bug#1003193: Switch maintainer?

[Adam Cécile]

On 1/5/22 10:39 PM, Dirk Eddelbuettel wrote:

Hi Adam,

Would you be ok with me more formally adopting the package as maintainer?


Hello,

Absolutely no issue on my side. Who could be a better maintainer than 
the upstream developer :-)


Regards, Adam.

Bug#1000662: Bug#995189: RFH: isc-dhcp

[Santiago R.R.]

On January 6, 2022 4:49:49 AM GMT-05:00, "Martin-Éric Racine" 
 wrote:
>Hello again,
>
>ke 24. marrask. 2021 klo 16.20 Santiago Ruano Rincón
>(santiag...@riseup.net) kirjoitti:
>> El 07/11/21 a las 13:54, Martin-Éric Racine escribió:
>> > ma 27. syysk. 2021 klo 21.44 Santiago Ruano Rincón
>> > (santiag...@riseup.net) kirjoitti:
>> > > El 27/09/21 a las 20:25, Martin-Éric Racine escribió:
>> > > > Package: wnpp
>> > > > Severity: normal
>> > > > X-Debbugs-Cc: debian-de...@lists.debian.org
>> > > > Control: affects -1 src:isc-dhcp
>> > > >
>> > > > -BEGIN PGP SIGNED MESSAGE-
>> > > > Hash: SHA256
>> > > >
>> > > > The ISC DHCP suite has a lenghty list of bug reports that have been 
>> > > > left unattended. Some bugs date back to DHCP 3 or even earlier.
>> > > >
>> > > > Additionally, recent upstream releases are still unpackaged. One 
>> > > > release came out well ahead of the Bullseye freeze, a bug report 
>> > > > requesting its packaging was filed, but it remains unanswered.
>> > > >
>> > > > Leaving a package with a priority Important in such utter state of 
>> > > > neglect is unacceptable.
>> > > >
>> > > > At this point, it has become clear that, at the very least, its 
>> > > > maintainers need help, hence why I filed this WNPP bug.
>> > >
>> > > Indeed. I am willing to spend some cycles to help maintaining it. I
>> > > requested access to the ISC DHCP packaging team in salsa ~a couple of
>> > > weeks ago, but I hasn't been answered yet (mgilbert is its only member).
>> > > It was on my ToDo list to ping the maintainers (in CC).
>> >
>> > Has any progress taken place on this?
>>
>> I've started doing some work at https://salsa.debian.org/santiago/isc-dhcp/
>>
>> I still didn't get any answer from current maintainers (keeping them in
>> CC), so I plan to retitle this bug as an ITS bug soon. Hopefully no
>> later than next Friday.
>
>Has the ITA taken place?
>

Not an ITA, but an ITS (CCed). I was unable close according to the ITS 
schedule, and I will have to resume the work after then end of my VAC 
(mid-January)

Cheers,

-- S

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
brevedad.

Bug#1003236: webcam Live! Cam Sync HD VF0770 unusable with linux 5.15.5 (working with at least 5.10)

[Mathieu Roy]

Package: src:linux
Version: 5.15.5-2
Severity: normal
Tags: upstream

Hello,

With any computer running 5.15.5, I cannot access the webcam Live! Cam 
Sync HD VF0770


The logs stops at
[  490.602056] usb 1-11: USB disconnect, device number 8
[  491.872365] usb 1-11: new high-speed USB device number 9 using xhci_hcd
[  492.114279] usb 1-11: New USB device found, idVendor=041e, 
idProduct=4095, bcdDevice=20.20
[  492.114285] usb 1-11: New USB device strings: Mfr=3, Product=1, 
SerialNumber=2

[  492.114289] usb 1-11: Product: Live! Cam Sync HD VF0770
[  492.114292] usb 1-11: Manufacturer:
and /dev/video* arent created, making the webcam unusable.



While,  with 5.10.9 kernel (and exact same hardware and installed software)

[  519.376025] usb 1-11: new high-speed USB device number 10 using xhci_hcd
[  519.617723] usb 1-11: New USB device found, idVendor=041e, 
idProduct=4095, bcdDevice=20.20
[  519.617730] usb 1-11: New USB device strings: Mfr=3, Product=1, 
SerialNumber=2

[  519.617734] usb 1-11: Product: Live! Cam Sync HD VF0770
[  519.617736] usb 1-11: Manufacturer: Creative Technology Ltd.
[  519.617739] usb 1-11: SerialNumber:
[  519.624350] uvcvideo: Found UVC 1.00 device Live! Cam Sync HD VF0770 
(041e:4095)
[  519.641876] input: Live! Cam Sync HD VF0770: Live! as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11:1.0/input/input35


# ls /dev/video*
/dev/video0  /dev/video1

# v4l2-ctl --list-devices
Live! Cam Sync HD VF0770: Live! (usb-:00:14.0-11):
    /dev/video0
    /dev/video1
    /dev/media0

and webcam works as expected

This webcam supported since 2.6.26
https://linux-hardware.org/?id=usb:041e-4095

I found at least one post that is likely related (1 month old, 5.15 
kernel, working with Ubuntu 20.04 running earlier kernels)

https://www.reddit.com/r/archlinux/comments/r9l32r/live_cam_sync_hd_usb_webcam_not_working/


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: Z390 GAMING SLI
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F10k
board_vendor: Gigabyte Technology Co., Ltd.
board_name: Z390 GAMING SLI-CF
board_version: Default string

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor 
Host Bridge/DRAM Registers [8086:3ec2] (rev 07)

    DeviceName: Onboard - Other
    Subsystem: Gigabyte Technology Co., Ltd 8th Gen Core Processor Host 
Bridge/DRAM Registers [1458:5000]
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
    Latency: 0
    IOMMU group: 0
    Capabilities: 
    Kernel driver in use: skl_uncore
    Kernel modules: ie31200_edac

00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor 
PCIe Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode])
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
    Latency: 0, Cache Line Size: 64 bytes
    Interrupt: pin A routed to IRQ 121
    IOMMU group: 1
    Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
    I/O behind bridge: 4000-4fff [size=4K]
    Memory behind bridge: 5200-550f [size=49M]
    Prefetchable memory behind bridge: 
4000-4fff [size=256M]
    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- 

    BridgeCtl: Parity- SERR+ NoISA- VGA+ VGA16+ MAbort- >Reset- FastB2B-
    PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
    Capabilities: 
    Kernel driver in use: pcieport

00:12.0 Signal processing controller [1180]: Intel Corporation Cannon 
Lake PCH Thermal Controller [8086:a379] (rev 10)

    DeviceName: Onboard - Other
    Subsystem: Gigabyte Technology Co., Ltd Cannon Lake PCH Thermal 
Controller [1458:]
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
    Latency: 0
    Interrupt: pin A routed to IRQ 16
    IOMMU group: 2
    Region 0: Memory at 5553d000 (64-bit, non-prefetchable) [size=4K]
    Capabilities: 
    Kernel driver in use: intel_pch_thermal
    Kernel modules: intel_pch_thermal

00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 
xHCI Host Controller [8086:a36d] (rev 10) (prog-if 30 [XHCI])

    DeviceName: Onboard - Other
    Subsystem: Gigabyte Technology Co., Ltd Cannon Lake PCH USB 3.1 
xHCI Host Controller [1458:5007]
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
    Latency: 0
    Interrupt: pin A routed to IRQ 132
  

Bug#1003090: RFS: ffcvt/1.7.5-1

[Tong Sun]

On Mon, Jan 3, 2022 at 3:45 PM Tong Sun wrote:
>
> On Mon, Jan 3, 2022 at 3:20 PM Tong Sun
>  wrote:
> >
> > Package: sponsorship-requests
> > Severity: normal
> >
> > Dear mentors,
> >
> > I updated my ffcvt to a newer version, and am now looking for a sponsor.
> >
> > Here is from the d/changelog
> >
> > ffcvt (1.7.5-1) unstable; urgency=medium
> >
> >   * New upstream version 1.7.5
> > - add --Speed for speeding up playback (v1.7.5)
> > - add a copy target type that can speed up operations (v1.7.4)
> > - add option -S,Seg -- split video into multiple segments (v1.7.3)
> > - add option -sel, subtitle encoding language (v1.7.2)
> > - add option -C which allows cutting multiple segments (v1.7.1)
> > - add wx type for weixin (v1.7.0)
> > - x264-mp3 type set ext to .mp4 (v1.6.2)
> >   * fix "source: out-of-date-standards-version" problem
> >   * fix "source: update-debian-copyright" problem
> >   * fix "source: prefer-uscan-symlink filenamemangle" problem
> >
> > Note
> >
> > 1) My GPG key expired a few days ago, and I've already submit the
> > update to keyring.debian.org, yet I understand it might take a while
> > to really get updated, so please
> >
> > go directly to
> > https://salsa.debian.org/go-team/packages/ffcvt/-/commits/master
> >
> > 2) Please disregard the .gitlab-ci.yml build failure as I'm not
> > supposed to touch it.
>
> Ops, please hold off reviewing it, as I've found out where the problem
> is -- ffcvt depends on the latest easygen to build yet I haven't
> upgraded easygen in Debian yet. and my expired GPG key is preventing
> me from fixing it promptly.
>
> Will update when the situation is fixed.
>
> Sorry & thanks
>
> > The build is fine, check out here --
> > https://github.com/suntong/ffcvt/runs/4687405723?check_suite_focus=true

Hi,

The situation should have been fixed with the new upload of easygen.

However, the CI build is still failing in salsa. This is something
that I don't understand as it builds OK on github.

Sorry I've run out of ideas why it is happening like this, and am now
thinking to remove the build dependency of easygen, to fix this and to
make things easier...

Somebody help please.

Bug#1003235: RFS: xbrzscale/1.8+ds-1 [ITP] -- Intelligent graphics file upscaling tool

[Peter]

Package: sponsorship-requests
Severity: wishlist

Dear Mentors,

I am looking for a sponsor for my package "xbrzscale":

 * Package name    : xbrzscale
   Version : 1.8+ds-1
   Upstream Author : Przemysław Grzywacz 
 * URL : https://github.com/atheros/xbrzscale
 * License : GPL-3+, cc0-1.0
   Section : graphics

It builds those binary packages:
  xbrzscale - Intelligent graphics file upscaling tool

To access further information about this package, please visit the following 
URL:
  https://mentors.debian.net/package/xbrzscale/

Alternatively, one can download the package with dget using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/x/xbrzscale/xbrzscale_1.8+ds-1.dsc

Changes for the initial release:
 xbrzscale (1.8+ds-1) unstable; urgency=medium
 .
   * Initial release. Closes: #969652


xBRZ is a new generation high-quality image file upscaling filter.
It is better than simple filters and is expecially good at upscaling 
low-resolution pixel art
such as icons, glyphs, cartoons & game tiles, where there are areas of solid 
colour with sharp boundaries.
These are upscaled without introducing ragged or blurred edges.
xBRZ has been used to upscale graphics for Doom, Wesnoth & C-evo.

xbrzscale is very easy to use, having no options. It just takes one parameter, 
the upscaling factor (2-6).

An example upscale attached. Try viewing zooming the original with your favorite graphics file viewer and compare with 
the upscaled version to see the difference.



Regards,
Peter Blackman

Bug#1002850: udev fails to create a symlink for a SDHC card connected to a Sharp Mebius laptop.

[Michael Biebl]

On 06.01.22 18:09, pe...@easthope.ca wrote:

From: Michael Biebl 
Date: Tue, 4 Jan 2022 19:12:04 +0100

Can you please provide the udev debug log from your mebius laptop?


Certainly.  From your message 27 I should first up the log-priority.

udevadm control --log-priority=debug

Then the udev daemon will report into /var/log/syslog.  Records will
be interspersed with other syslog records. I've checked udev.man and
udevadm.man.  No mention of a parameter specifying a log file.  Can
udev log to a dedicated file?  That will be easier to comprehend than
the full syslog.

Thanks,   ... P.



udevadm control --log-priority=debug
journalctl -f

(and udevadm control --log-priority=info to set it back to sane levels)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003233: numpy: Please move the BD needed to build the -doc package to Build-Depends-Indep

[Laurent Bigonville]

Source: numpy
Version: 1:1.21.5-1
Severity: normal
Tags: patch

Hello,

There are a lot of build dependencies that are marked with the !nodoc
profile

Shouldn't all of these be moved to Build-Depends-Indep instead?

That should reduce the package pulled by the buildd (and also make the
package easier to bootstrap on new ports)

Kind regards,
Laurent Bigonville


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
commit 88e9936f0efa0aeebec879b4e622b7e5becb9906
Author: Laurent Bigonville 
Date:   Thu Jan 6 18:55:48 2022 +0100

debian/control: Move all the BD marked wity !nodoc to BDI

diff --git a/debian/control b/debian/control
index e9acc64e..5ad36d83 100644
--- a/debian/control
+++ b/debian/control
@@ -10,26 +10,26 @@ Build-Depends: cython3 (>= 0.29.24),
gfortran,
libblas-dev [!arm !m68k],
liblapack-dev [!arm !m68k],
-   python-imageio-doc ,
-   python-matplotlib-doc ,
-   python-pandas-doc ,
-   python-scipy-doc ,
-   python-skimage-doc ,
python3-all-dev,
-   python3-doc ,
python3-hypothesis (>= 5.19.1) ,
-   python3-ipython ,
-   python3-matplotlib ,
-   python3-numpydoc ,
-   python3-pydata-sphinx-theme (>= 0.7.1) ,
python3-pytest ,
python3-scipy ,
-   python3-scipy ,
python3-setuptools,
-   python3-sphinx (>= 2) ,
python3-tz ,
-   texlive-latex-base ,
-   texlive-latex-extra ,
+Build-Depends-Indep: python-imageio-doc ,
+ python-matplotlib-doc ,
+ python-pandas-doc ,
+ python-scipy-doc ,
+ python-skimage-doc ,
+ python3-doc ,
+ python3-ipython ,
+ python3-matplotlib ,
+ python3-numpydoc ,
+ python3-pydata-sphinx-theme (>= 0.7.1) ,
+ python3-scipy ,
+ python3-sphinx (>= 2) ,
+ texlive-latex-base ,
+ texlive-latex-extra ,
 Standards-Version: 4.6.0.1
 Vcs-Git: https://salsa.debian.org/python-team/packages/numpy.git
 Vcs-Browser: https://salsa.debian.org/python-team/packages/numpy

Bug#1002850: udev fails to create a symlink for a SDHC card connected to a Sharp Mebius laptop.

[peter]

From: Michael Biebl 
Date: Tue, 4 Jan 2022 19:12:04 +0100
> Can you please provide the udev debug log from your mebius laptop?

Certainly.  From your message 27 I should first up the log-priority.

udevadm control --log-priority=debug

Then the udev daemon will report into /var/log/syslog.  Records will 
be interspersed with other syslog records. I've checked udev.man and 
udevadm.man.  No mention of a parameter specifying a log file.  Can 
udev log to a dedicated file?  That will be easier to comprehend than 
the full syslog.

Thanks,   ... P.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

Bug#1003232: dependency fix for backports

[Simon Richter]

Package: kicad
Version: 6.0.0-0~bpo11+1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I had to apply this patch to fix the dependencies for backported packages;
otherwise the main kicad package would depend on a later version of itself
(because the Upstream-Version generated by dpkg-makeshlibs is greater than
the backport version).

The fix is to apply the -X arguments for the internal libraries during
makeshlibs, not during shlibdeps; this also means that libraries used by
the private libraries are pulled in correctly (so this fix should go into
the proper 6.0.0 release packages, not just into backports).

   Simon

- -- System Information:
Debian Release: 10.11
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kicad depends on:
iu  kicad6.0.0-0~bpo11+1
ii  libc62.31-13+deb11u2
ii  libcairo21.16.0-4+deb10u1
ii  libcurl4 7.64.0-4+deb10u2
ii  libgcc-s110.2.1-6
ii  libgl1   1.1.0-1
ii  libglew2.1   2.1.0-4
ii  libglib2.0-0 2.66.8-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1+b3
ii  libgtk-3-0   3.24.5-1
ii  libngspice0  30.2-1
ii  libocct-data-exchange-7.57.5.1+dfsg1-2
ii  libocct-foundation-7.5   7.5.1+dfsg1-2
ii  libocct-modeling-algorithms-7.5  7.5.1+dfsg1-2
ii  libocct-modeling-data-7.57.5.1+dfsg1-2
ii  libocct-ocaf-7.5 7.5.1+dfsg1-2
ii  libpixman-1-00.36.0-1
ii  libpython3.9 3.9.2-1
ii  libstdc++6   10.2.1-6
ii  libwxbase3.0-0v5 3.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-2
ii  python3  3.9.2-3
ii  python3-wxgtk4.0 4.0.7+dfsg-10
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages kicad recommends:
ii  kicad-demos  5.1.9+dfsg1-1
ii  kicad-libraries  5.1.9+dfsg1-1
ii  xsltproc 1.1.32-2.2~deb10u1

Versions of packages kicad suggests:
pn  extra-xdg-menus 
pn  kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-doc-es | kicad-  
ii  kicad-packages3d5.1.7-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmHXK64PHHNqckBkZWJp
YW4ub3JnAAoJEH69OHuwmQgRIxQH/iWCcIE72J0cusE4OiIOanK+TVl2EekKKEQp
LphLZ+hlF0gtCGyJzuz4IUSPnkzT1ZPuCYTttQhyu4lI85EQAWff8aub+t+G5Ogy
dq90wMtALsTR5AZO00pZQ+kKZD4oBC3PFRrdw9MIlA3LDpP9fNqXo7hGmGR8CWnf
u1AYfMVyK/oBlRWVsoO1yn/kfkFqeDqVQmJHjqmJX1hNeqyrjVlN/hj4vB1cHfgt
qZjrzxGQ/YGIX+frRKN5jo7suZQ8F3yCKGiZd6ILMMudH8YEZgN3nR6cX+hOl/j8
ZFOaWpLSEqONjD7Ujp6tHOHk5pfiiB85ViIWGgL1UDxs22V8mlI=
=QA2s
-END PGP SIGNATURE-
--- kicad-6.0.0/debian/rules2021-12-27 20:41:19.0 +0100
+++ kicad-6.0.0/debian/rules2021-12-27 21:08:37.0 +0100
@@ -151,9 +151,10 @@
# strip unneeded symbols from the kicad specific libraries in 
/usr/lib/kicad/
strip --strip-unneeded --remove-section=.comment 
$(CURDIR)/debian/kicad/usr/lib/kicad/_*.kiface
 
-override_dh_shlibdeps:
-   dh_shlibdeps -a -l $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH) \
+override_dh_makeshlibs:
+   dh_makeshlibs -a \
-Xlibkicad_3dsg \
-Xlibs3d_plugin_idf \
+   -Xlibs3d_plugin_oce \
-Xlibs3d_plugin_vrml \
-X_pcbnew.$(DEB_HOST_MULTIARCH)

Bug#1003225: on resume, tries to openat() mountpoint of remote nfs mounts that are not yet available, thus delaying network configuration

[Michael Biebl]

On 06.01.22 17:26, Andras Korn wrote:

Package: systemd-timesyncd
Version: 249.7-1
Severity: normal
Tags: upstream

Hi,

I noticed that it took a while for the network to become available after my
laptop wakes up from suspend.

I traced the problem to systemd-timesyncd.

I use dhcpcd5, which ships /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf, which
contains the line "systemctl try-restart systemd-timesyncd.service || :".


That file is not shipped by systemd. Why does it restart timesyncd?
Why does it so blockingly? Why does it restart timesyncd when the 
network is still down?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003231: O: mz -- versatile packet creation and network traffic generation tool

[Tobias Frost]

Package: wnpp

The current maintainer of mz, Cristian Greco ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: mz
Binary: mz
Version: 0.40-1.1
Maintainer: Cristian Greco 
Build-Depends: debhelper (>= 7.3.0), cmake, libnet1-dev, libpcap0.8-dev, 
libcli-dev
Architecture: any
Standards-Version: 3.9.0
Format: 3.0 (quilt)
Files:
 5130a49602189c3168ce3d41b1eef3b0 1929 mz_0.40-1.1.dsc
 d3d959c92cbf3d81224f5b2f8409e9d8 232756 mz_0.40.orig.tar.gz
 38672260665354856124af6705a2b7ed 4048 mz_0.40-1.1.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=collab-maint/mz.git
Vcs-Git: git://git.debian.org/git/collab-maint/mz.git
Checksums-Sha256:
 0c94e6c880d817a6b6e8df12900667ed6ac6e7c5b8ec381b1ba84cbed3cf9818 1929 
mz_0.40-1.1.dsc
 378eb74a0447646764dd6fa2ca5290d1681bf407c8d2990f25978d6ccc61c96a 232756 
mz_0.40.orig.tar.gz
 c4a69eb7b468378aa2faf79e3a3502f52497c81908b7b32df1018c4f2a55d02e 4048 
mz_0.40-1.1.debian.tar.xz
Homepage: http://www.perihel.at/sec/mz/
Package-List: 
 mz deb net optional arch=any
Directory: pool/main/m/mz
Priority: source
Section: net

Package: mz
Source: mz (0.40-1.1)
Version: 0.40-1.1+b2
Installed-Size: 484
Maintainer: Cristian Greco 
Architecture: amd64
Depends: libc6 (>= 2.14), libcli1.10 (>= 1.9.1), libnet1 (>= 1.1.2.1), 
libpcap0.8 (>= 0.9.8)
Suggests: python-matplotlib
Description-en: versatile packet creation and network traffic generation tool
 mausezahn (mz) is a fast traffic generator written in C which allows you to
 send nearly every possible and impossible packet. It is mainly used to test
 VoIP or multicast networks but also for security audits to check whether
 your systems are hardened enough for specific attacks.
 Mausezahn can be used for example:
 .
  * as traffic generator (e.g. to stress multicast networks);
  * to precisely measure jitter (delay variations) between two hosts
(e.g. for VoIP-SLA verification);
  * as didactical tool during a datacom lecture or for lab exercises;
  * for penetration testing of firewalls and IDS;
  * for DoS attacks on networks (for audit purposes of course);
  * to find bugs in network software or appliances;
  * for reconnaissance attacks using ping sweeps and port scans;
  * to test network behaviour under strange circumstances (stress test,
malformed packets, ...).
Description-md5: 8e7134e5630c00bc3204b8c55b70e2ee
Homepage: http://www.perihel.at/sec/mz/
Tag: implemented-in::c, interface::commandline, protocol::ip, role::program,
 scope::utility, use::learning, use::measuring,
 works-with::network-traffic
Section: net
Priority: optional
Filename: pool/main/m/mz/mz_0.40-1.1+b2_amd64.deb
Size: 145748
MD5sum: 43b668a355120902a64a499ab7e13bb5
SHA256: 58ffaba2940d9b898855979fa6645f7a7449fe181e65257894370b3162f34917

Package: mz
Source: mz (0.40-1.1)
Version: 0.40-1.1+b1
Installed-Size: 484
Maintainer: Cristian Greco 
Architecture: amd64
Depends: libc6 (>= 2.14), libcli1.9 (>= 1.9.1), libnet1 (>= 1.1.2.1), 
libpcap0.8 (>= 0.9.8)
Suggests: python-matplotlib
Description-en: versatile packet creation and network traffic generation tool
 mausezahn (mz) is a fast traffic generator written in C which allows you to
 send nearly every possible and impossible packet. It is mainly used to test
 VoIP or multicast networks but also for security audits to check whether
 your systems are hardened enough for specific attacks.
 Mausezahn can be used for example:
 .
  * as traffic generator (e.g. to stress multicast networks);
  * to precisely measure jitter (delay variations) between two hosts
(e.g. for VoIP-SLA verification);
  * as didactical tool during a datacom lecture or for lab exercises;
  * for penetration testing of firewalls and IDS;
  * for DoS attacks on networks (for audit purposes of course);
  * to find bugs in network software or appliances;
  * for reconnaissance attacks using ping sweeps and port scans;
  * to test network behaviour under strange circumstances (stress test,
malformed packets, ...).
Description-md5: 8e7134e5630c00bc3204b8c55b70e2ee
Homepage: http://www.perihel.at/sec/mz/
Tag: implemented-in::c, interface::commandline, protocol::ip, role::program,
 scope::utility, use::learning, use::measuring,
 works-with::network-traffic
Section: net
Priority: optional
Filename: pool/main/m/mz/mz_0.40-1.1+b1_amd64.deb
Size: 145388
MD5sum: 090624fe82956248047e897cd47dcf79
SHA256: e4db846da881c52538950bafa422d789fbded6538ae487c66a5019e762049364

Bug#1003229: Updating the deluge Uploaders list

[Tobias Frost]

Source: deluge
Version: 2.0.3-3.1 1.3.15-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Cristian Greco  has retired, so can't work on
the deluge package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1003228: Updating the poco Uploaders list

[Tobias Frost]

Source: poco
Version: 1.10.0-6+deb11u1 1.9.0-5 1.11.0-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Cristian Greco  has retired, so can't work on
the poco package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1003230: O: icecream -- lightweight stream download utility

[Tobias Frost]

Package: wnpp

The current maintainer of icecream, Cristian Greco ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: icecream
Binary: icecream
Version: 1.3-4.1
Maintainer: Cristian Greco 
Build-Depends: debhelper (>= 7.0.50)
Architecture: all
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 7a6048601fc129069701aeb2c7fc1426 1824 icecream_1.3-4.1.dsc
 8524960a142fb936537ada1cce57a94f 17976 icecream_1.3.orig.tar.gz
 7c26d6744e5cc14f08876ae66e671448 3448 icecream_1.3-4.1.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=collab-maint/icecream.git
Vcs-Git: git://git.debian.org/git/collab-maint/icecream.git
Checksums-Sha256:
 73fcdd665499b203e0a4b9ba1b07da1c0b39409c1766dcd33b3531e06baf6373 1824 
icecream_1.3-4.1.dsc
 2d687cc81990ff703ecfe595fefd8dfd1ce187b50fbd974e60d6234124e6e9ff 17976 
icecream_1.3.orig.tar.gz
 1811edc5da09cf318dddb2db89f46ddcfbdffbf9df32ca0bc357268c778d7154 3448 
icecream_1.3-4.1.debian.tar.xz
Homepage: http://icecream.sourceforge.net
Package-List: 
 icecream deb net optional arch=all
Directory: pool/main/i/icecream
Priority: source
Section: net

Package: icecream
Binary: icecream
Version: 1.3-4
Maintainer: Cristian Greco 
Build-Depends: debhelper (>= 7.0.50)
Architecture: all
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 df07890c528968bef1bfe8b65008acca 1795 icecream_1.3-4.dsc
 8524960a142fb936537ada1cce57a94f 17976 icecream_1.3.orig.tar.gz
 b972982b0c45cb8a460ef67666de21d8 3536 icecream_1.3-4.debian.tar.gz
Dm-Upload-Allowed: yes
Vcs-Browser: http://git.debian.org/?p=collab-maint/icecream.git
Vcs-Git: git://git.debian.org/git/collab-maint/icecream.git
Checksums-Sha256:
 37105c740b5a8250086e6d04f4df48f0cdd691cda6d4d8eb356e462647af3be1 1795 
icecream_1.3-4.dsc
 2d687cc81990ff703ecfe595fefd8dfd1ce187b50fbd974e60d6234124e6e9ff 17976 
icecream_1.3.orig.tar.gz
 98c64c463bdc10b6da86ee17a1105d3b2bf93ac273181e0bbdd4f38bcb8eaba5 3536 
icecream_1.3-4.debian.tar.gz
Homepage: http://icecream.sourceforge.net
Directory: pool/main/i/icecream
Priority: source
Section: net

Bug#1003227: ITS: wmnet

[Andreas Metzler]

Package: wmnet
Version: 1.06-1.2
Severity: important
X-Debbugs-Cc: wma...@packages.debian.org, m...@qa.debian.org

Hello,

I intend to salvage wmnet, maintaining it under the Debian Window Maker
Team umbrella.

The last maintainer upload was in 2012, followed by a unacknowledged NMU
in Oct 2021. The package has already been dropped from testing due to a
FTFBS (#965880 - which I have fixed by a NMU today).

cu Andreas


signature.asc
Description: PGP signature

Bug#1003226: mdadm: typo in manual page mdadm(8)

[Martin Schwarz]

Package: mdadm
Version: 4.2~rc2-7
Severity: minor

Dear Maintainer,

there's a minor spelling mistake in the mdadm(8) manpage (file
/usr/share/man/man8/mdadm.8.gz):

The line "can be found it" should probably read "can be found in"
instead.

Thanks!

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

Bug#1002709: webext-ublock-origin-firefox: ublock-origin makes firefox-esr 91 consumes 100% of a CPU core

[Markus Koschany]

Control: affects 986027 webext-ublock-origin-firefox

Am Donnerstag, dem 06.01.2022 um 16:20 + schrieb Amr Ibrahim:
> Am Freitag, dem 31.12.2021 um 20:53 +0100 schrieb Markus Koschany:
> 
> > If you install version 1.40.2+dfsg-1 from unstable, does this resolve
> > your problem? I have noticed similar issues with Firefox on websites
> > which make heavy use of Javascript but I don't experience them with
> > Chromium.
> 
> Unfortunately no, 1.40.2+dfsg-1 from unstable does not fix the problem.
> However, the same version from Firefox Add-ons is fine, no 100% CPU.
> 
> I also found this Debian bug report against firefox:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986027
> 
> And this upstream Firefox bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1706594

Thanks for your analysis. It seems this issue is fixed in Firefox 95 but the
fix has not been backported to Firefox ESR yet. Let's wait for an update.

Regards,

Markus



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

Bug#1003225: on resume, tries to openat() mountpoint of remote nfs mounts that are not yet available, thus delaying network configuration

[Andras Korn]

Package: systemd-timesyncd
Version: 249.7-1
Severity: normal
Tags: upstream

Hi,

I noticed that it took a while for the network to become available after my
laptop wakes up from suspend.

I traced the problem to systemd-timesyncd.

I use dhcpcd5, which ships /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf, which
contains the line "systemctl try-restart systemd-timesyncd.service || :".

During this try-restart operation, a timesyncd process is started and hangs
for several seconds in D state for each nfs mountpoint that is unreachable.
(I'm attaching an strace log; the nfs server also exports
nfs-mountpoint-2/subdir to this client separately, so technically that's
nfs-mountpoint-3.)

dhcpcd5 doesn't continue setting up the network before the hook script
returns, but without the network, the hook script takes a long time to
finish.

I don't see why timesyncd has to try to openat() a directory on every
mountpoint. I assume this is due to some generic code it pulls in from maybe
libsystemd; if it can't be avoided, perhaps timesyncd should be started in a
restricted mount namespace that doesn't contain anything but the (local)
mountpoints it absolutely needs to function. (This would be desirable anyway
from a security perspective.) I'm not sure if this can also be done for
try-restart, though.

András

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.15-pf8-luna (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
 Good documentation is not written to satisfy a quota specified in cubic feet.
read(3, "REDACTED"..., 1024) = 1024 <0.20>
read(3, "REDACTED"..., 1024) = 1024 <0.22>
read(3, "REDACTED", 1024) = 18 <0.06>
read(3, "REDACTED", 1024) = 0 <0.06>
openat(AT_FDCWD, "/run/systemd/unit-root/run/credentials", 
O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 
4 <0.18>
mount(NULL, "/proc/self/fd/4", NULL, 
MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_REMOUNT|MS_BIND, NULL) = 0 <0.11>
close(4) = 0 <0.08>
lseek(3, 0, SEEK_SET) = 0 <0.06>
read(3, "REDACTED"..., 1024) = 1024 <0.29>
lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.08>
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 <0.06>
readlink("/proc/self", "63713", 4095)   = 5 <0.06>
lstat("/proc/63713", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/63713/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 
<0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.23>
read(3, "REDACTED"..., 1024) = 1024 <0.25>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.18>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.13>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED", 1024) = 18 <0.05>
read(3, "REDACTED", 1024) = 0 <0.05>
lseek(3, 0, SEEK_SET) = 0 <0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.18>
lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 <0.05>
readlink("/proc/self", "63713", 4095)   = 5 <0.06>
lstat("/proc/63713", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/63713/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 
<0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.20>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.13>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.11>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED", 1024) = 18 <0.05>
read(3, "REDACTED", 1024) = 0 <0.05>
openat(AT_FDCWD, "/run/systemd/unit-root/run/systemd/incoming", 
O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 
4 <0.08>
mount(NULL, "/proc/self/fd/4", NULL, 
MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_REMOUNT|MS_BIND, NULL) 

Bug#962208: libtrace3: diff for NMU version 3.0.22-0.1

[Adrian Bunk]

Control: tags 962208 + patch
Control: tags 962208 + pending
Control: tags 965694 + patch
Control: tags 965694 + pending

Dear maintainer,

I've prepared an NMU for libtrace3 (versioned as 3.0.22-0.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru libtrace3-3.0.21/configure libtrace3-3.0.22/configure
--- libtrace3-3.0.21/configure	2014-09-09 00:55:29.0 +0300
+++ libtrace3-3.0.22/configure	2015-02-10 06:56:58.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for libtrace 3.0.21.
+# Generated by GNU Autoconf 2.69 for libtrace 3.0.22.
 #
 # Report bugs to .
 #
@@ -590,8 +590,8 @@
 # Identity of this package.
 PACKAGE_NAME='libtrace'
 PACKAGE_TARNAME='libtrace'
-PACKAGE_VERSION='3.0.21'
-PACKAGE_STRING='libtrace 3.0.21'
+PACKAGE_VERSION='3.0.22'
+PACKAGE_STRING='libtrace 3.0.22'
 PACKAGE_BUGREPORT='cont...@wand.net.nz'
 PACKAGE_URL=''
 
@@ -1394,7 +1394,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures libtrace 3.0.21 to adapt to many kinds of systems.
+\`configure' configures libtrace 3.0.22 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1464,7 +1464,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of libtrace 3.0.21:";;
+ short | recursive ) echo "Configuration of libtrace 3.0.22:";;
esac
   cat <<\_ACEOF
 
@@ -1582,7 +1582,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-libtrace configure 3.0.21
+libtrace configure 3.0.22
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2503,7 +2503,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by libtrace $as_me 3.0.21, which was
+It was created by libtrace $as_me 3.0.22, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -2854,7 +2854,7 @@
 
 LIBTRACE_MAJOR=3
 LIBTRACE_MID=0
-LIBTRACE_MINOR=21
+LIBTRACE_MINOR=22
 
 # OpenSolaris hides libraries like libncurses in /usr/gnu/lib, which is not
 # searched by default - add it to LDFLAGS so we at least have a chance of
@@ -3332,7 +3332,7 @@
 
 # Define the identity of the package.
  PACKAGE='libtrace'
- VERSION='3.0.21'
+ VERSION='3.0.22'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -17942,6 +17942,9 @@
 
 if test "$ac_cv_search_dlopen" != "none required"; then
 	LIBPKTDUMP_LIBS="$LIBPKTDUMP_LIBS $ac_cv_search_dlopen"
+	if test "$dpdk_found" = 1; then
+		LIBTRACE_LIBS="$LIBTRACE_LIBS -Wl,$ac_cv_search_dlopen"
+	fi
 fi
 
 if test "$have_pthread" = 1; then
@@ -19255,7 +19258,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by libtrace $as_me 3.0.21, which was
+This file was extended by libtrace $as_me 3.0.22, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -19321,7 +19324,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-libtrace config.status 3.0.21
+libtrace config.status 3.0.22
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru libtrace3-3.0.21/configure.in libtrace3-3.0.22/configure.in
--- libtrace3-3.0.21/configure.in	2014-09-09 00:55:18.0 +0300
+++ libtrace3-3.0.22/configure.in	2015-02-10 06:56:03.0 +0200
@@ -3,11 +3,11 @@
 # Now you only need to update the version number in two places - below,
 # and in the README
 
-AC_INIT([libtrace],[3.0.21],[cont...@wand.net.nz],[libtrace])
+AC_INIT([libtrace],[3.0.22],[cont...@wand.net.nz],[libtrace])
 
 LIBTRACE_MAJOR=3
 LIBTRACE_MID=0
-LIBTRACE_MINOR=21
+LIBTRACE_MINOR=22
 
 # OpenSolaris hides libraries like libncurses in /usr/gnu/lib, which is not
 # searched by default - add it to LDFLAGS so we at least have a chance of 
@@ -417,6 +417,9 @@
 
 if test "$ac_cv_search_dlopen" != "none required"; then 
 	LIBPKTDUMP_LIBS="$LIBPKTDUMP_LIBS $ac_cv_search_dlopen"
+	if test "$dpdk_found" = 1; then
+		LIBTRACE_LIBS="$LIBTRACE_LIBS -Wl,$ac_cv_search_dlopen"
+	fi
 fi
 
 if test "$have_pthread" = 1; then
diff -Nru libtrace3-3.0.21/debian/changelog libtrace3-3.0.22/debian/changelog
--- libtrace3-3.0.21/debian/changelog	2014-10-24 02:51:45.0 +0300
+++ libtrace3-3.0.22/debian/changelog	2022-01-06 18:13:17.0 +0200
@@ -1,3 +1,12 @@
+libtrace3 (3.0.22-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * Backport upstream fix for FTBFS with glibc 2.31. (Closes: #962208)
+  * debian/compat: 5 -> 7. (Closes: 

Bug#1002709: webext-ublock-origin-firefox: ublock-origin makes firefox-esr 91 consumes 100% of a CPU core

[Amr Ibrahim]

Am Freitag, dem 31.12.2021 um 20:53 +0100 schrieb Markus Koschany:

> If you install version 1.40.2+dfsg-1 from unstable, does this resolve
> your problem? I have noticed similar issues with Firefox on websites
> which make heavy use of Javascript but I don't experience them with
> Chromium.

Unfortunately no, 1.40.2+dfsg-1 from unstable does not fix the problem.
However, the same version from Firefox Add-ons is fine, no 100% CPU.

I also found this Debian bug report against firefox:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986027

And this upstream Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1706594

Bug#1003107: "failed to find ref" when following gbp guide

[Guido Günther]

Hi,
On Tue, Jan 04, 2022 at 09:42:10AM +0100, Marc Haber wrote:
> Package: git-buildpackage
> Version: 0.9.25
> Severity: minor
> 
> Hi,
> 
> I am not sure whether this is a software bug or a bug in the
> documentation. I am therefore trying to file this against the guide
> "Building Debian Packages using git-buildpackage" 0.9.25 as published on
> honk.sigxcpu.org/projects/git-buildpackage/manual-html
> 
> Thanks for writing that guide, it is the most comprehensive information
> about gbp that I have ever seen, and it is easy to understand and gives
> a lot of information even to a DD who has been using gbp for many years.
> 
> I followed the chapter "When Upstream uses git / no upstream tarballs"
> with the extension that Upstream also does not do release tags. I
> therefore created my own "release tag", upstream/v0_20211218.
> 
> In this environment, gbp buildpackage --git-export=WC complain that the
> tarball could not be verified:
> 
> [97/7578]mh@drop:~/packages/oas/oas (debian/sid % u+1) $ gbp buildpackage 
> --git-export=WC --git-verbose
> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: /bin/true [] []
> gbp:debug: ['git', 'symbolic-ref', 'HEAD']
> gbp:debug: ['git', 'show-ref', 'refs/heads/debian/sid']
> gbp:debug: ['git', 'add', '-f', '/home/mh/packages/oas/oas']
> gbp:debug: ['git', 'write-tree']
> gbp:debug: ['git', 'ls-tree', '098f3cea3a2b52e88a49956dab2cac53ed0496bd']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/changelog']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/remotes/origin/pristine-tar']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: ['git', 'show', '--pretty=medium', 
> '098f3cea3a2b52e88a49956dab2cac53ed0496bd:debian/source/format']
> gbp:debug: Looking for orig tarballs 'oas_0~20211218-1~1.orig.tar.gz' at 
> '../tarballs'
> gbp:info: All Orig tarballs 'oas_0~20211218-1~1.orig.tar.gz' found at 
> '../tarballs'
> gbp:debug: pristine-tar [] ['--help']
> gbp:debug: pristine-tar [] ['verify', 
> '/home/mh/packages/oas/build-area/oas_0~20211218-1~1.orig.tar.gz']
> gbp:error: Pristine-tar couldn't verify "oas_0~20211218-1~1.orig.tar.gz": 
> pristine-tar: no pristine-tar branch found, use "pristine-tar commit" first
> [98/7579]mh@drop:~/packages/oas/oas (debian/sid % u+1) $

You have pristine-tar enabledx. You can export a tarball without it
adding `--git-no-pristine-tar`. Pristine-tar is not enabled by default.

> and the recommended call to pristine-tar fails as well:
> 
> $ pristine-tar --verbose commit ../tarballs/oas_0~20211218-1~1.orig.tar.gz
> pristine-tar: failed to find ref using: git show-ref upstream

What did you call the branch with the usptream sources?

try:

   gbp pristine-tar commit ../tarballs/oas_0~20211218-1~1.orig.tar.gz

if your upstream tag format is set up correctly it should do the right
thing.

> And in fact, the documented way of cloning the upstream repo as upstream
> and then adding debian/sid does not create an upstream branch.
> 
> What is the intended way to proceed from here?
> 
> Is this:
> 
> (1) a bug in the Guide, omitting to create the upstream branch?

I'd assume the upstream branch is there but can't tell for sure without
seeing the repo layout.

> (2) a bug in the Guide, omitting the configuration so that gbp knows
> there is no upstream branch?

There's no indication above that gbp doesn't find the upstream branch or
did I miss that? It seems `pristine-tar` doesn't find it.

> (3) a bug in gbp, not properly handling the "upstream branch missing"
> situation?

It works as expected:

>From your log:

> gbp:info: All Orig tarballs 'oas_0~20211218-1~1.orig.tar.gz' found at 
> '../tarballs'

^^ so it finds the tarball there

> gbp:debug: pristine-tar [] ['verify', 
> 

Bug#986027: Please backport the fix to firefox-esr 91

[Amr Ibrahim]

I'm also affected by this bug in firefox-esr 91. Please backport the
fixes.

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

Bug#975931: libllvm11: libgpuarray autopkgtest using pocl on armhf triggers segfault

[Drew Parsons]

Source: pocl
Version: 1.8-2
Followup-For: Bug #975931

pyopencl passes tests now on several arches with pocl 1.8-2 (llvm 11)
from experimental, though armhf still fails.

You reported that pocl 1.8 supports llvm 13.  Can we try that now, and
upload to unstable?  Would also fix Bug#1001317.

Bug#1003214: RFS: opencpn/5.6.0+dfsg0-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software

[Tobias Frost]

Control: tags -1 moreinfo

Hi Alec,


On Thu, 6 Jan 2022 12:27:51 +0100 Alec Leamas  wrote:
(...)

> * Don't strip libwxsvg in d/copyright, repack sources with bundled
>   library in place. Use dfsg0 to make it precede dfsg1 in bullseye.

if you dont remove it using Files-Excluded, you need to document libwxsvg's
copyright in d/copyright...
 
> Regards,
> -- 
>    Alec Leamas
> 

-- 
tobi 

Bug#1002868: firefox-esr: Extensions thread/process consuming 100% CPU (single thread) indefinitely

[Amr Ibrahim]

On Thu, 30 Dec 2021 11:54:33 + Bruno Gravato 
wrote:

> I'm using the following extensions, installed from the debian
packages:
> - webext-privacy-badger
> - webext-ublock-origin-firefox
> - webext-keepassxc-browser

I'm also affected by this bug. I reported a bug against ublock-origin
because I suspect it's the culprit.

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

Did you try ublock-origin from Firefox Add-ons and remove the Debian
package webext-ublock-origin-firefox? I don't experience the 100% CPU
after doing that.