date:20210411

Bug#967537: [Debian-zh-dev] Bug#967537: forward this bug to upstream

2021-04-11 Thread LI Daobing

0.8.0 released.

On Fri, Jan 22, 2021 at 12:27 PM xiao sheng wen  wrote:
>
> Forward this bug to the upstream:
>
> https://github.com/iptux-src/iptux/issues/307
>
> --
> 肖盛文 xiao sheng wen Faris Xiao
> 微信(wechat)：atzlinux
> 《铜豌豆 Linux》https://www.atzlinux.com
> 基于 Debian 的 Linux 中文 桌面 操作系统
> Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
> GnuPG Public Key: 0x00186602339240CB
>
> ___
> Chinese-developers mailing list
> chinese-develop...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/chinese-developers



-- 
Best Regards
LI Daobing

Bug#986782: ITP: libchemistry-isotope-perl -- table of the isotopes exact mass data

2021-04-11 Thread Andrius Merkys

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libchemistry-isotope-perl
  Version : 0.11
  Upstream Author : Ivan Tubert-Brohman 
* URL : https://metacpan.org/release/Chemistry-Isotope
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : table of the isotopes exact mass data
 Chemistry::Isotope contains the exact mass data from the table of the
 isotopes. It has an exportable function, isotope_mass, which returns
the mass
 of an atom in mass units given its mass number (A) and atomic number
(Z); and
 a function isotope_abundance which returns a table with the natural
abundance
 of the isotopes given an element symbol.
 .
 The table of the masses includes 2931 nuclides and is taken from
 http://ie.lbl.gov/txt/awm95.txt (G. Audi and A.H. Wapstra, Nucl. Phys.
A595,
 409, 1995)
 .
 The table of natural abundances includes 288 nuclides and is taken from the
 Commission on Atomic Weights and Isotopic Abundances report for the
 International Union of Pure and Applied Chemistry in Isotopic
Compositions of
 the Elements 1989, Pure and Applied Chemistry, 1998, 70, 217.
 http://www.iupac.org/publications/pac/1998/pdf/7001x0217.pdf

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libchemistry-isotope-perl

Bug#986764: libncurses-dev: coinstalling fails on /usr/bin/ncurses6-config for release arch vs {avr32,hppa,ia64}

2021-04-11 Thread Helmut Grohne

Hi Sven,

On Sun, Apr 11, 2021 at 08:51:24PM +0200, Sven Joachim wrote:
> That is a result of me complaining about these flags when they were
> introduced, see
> https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00037.html.

That seems quite wise in retrospect. :)

> > So actually fixing this would be possible by fixing the generated
> > /usr/bin/ncurses6-config to not contain them. The filtering can either
> > happen inside the configure script or applied post build in a
> > Debian-specific fixup.
> 
> Another option might be to patch misc/ncurses-config.in and remove
> @LDFLAGS@ there.

That depends on the purpose of @LDFLAGS@ there. It would very likely
work on Debian, but I am unsure whether it would break elsewhere. So
maybe doing so is not acceptable upstream. I suppose that you do want to
minimize the difference to upstream.

On the Debian side, I do agree here as @LDFLAGS@ only contain the
dpkg-buildflags, which we do not want to forward. So patching it locally
sounds like a sane plan B to me.

If @LDFLAGS@ has a purpose for other distributions, I guess the best
trade-off is filtering it during configure.

Helmut

Bug#815164: Alerte par e-mail

2021-04-11 Thread alerte

Nous avons remarqué sur notre serveur de messagerie que votre compte de 
messagerie ac-rennes.fr vient d'être piraté par un utilisateur inconnu, 
veuillez cliquer ICI maintenant pour sécuriser rapidement votre messagerie et 
éviter de perdre votre compte

Cordialement
E-mail de l'équipe

Bug#986781: ITP: gemmi -- library for structural biology

2021-04-11 Thread Andrius Merkys

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: gemmi
  Version : 0.4.5
  Upstream Author : Marcin Wojdyr 
* URL : https://project-gemmi.github.io
* License : MPL-2.0 or LGPL-2.0
  Programming Lang: C, Python
  Description : library for structural biology

Gemmi is a library, accompanied by a set of programs, developed
primarily for use in macromolecular crystallography (MX). For working with:

macromolecular models (content of PDB, PDBx/mmCIF and mmJSON files),
refinement restraints (CIF files),
reflection data (MTZ and mmCIF formats),
data on a 3D grid (electron density maps, masks, MRC/CCP4 format)
crystallographic symmetry.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/gemmi

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

2021-04-11 Thread Josh Triplett

On Mon, Apr 12, 2021 at 07:00:31AM +0200, Vincent Bernat wrote:
>  ❦ 11 avril 2021 18:44 -07, Josh Triplett:
> 
> >> > Whether you have an initramfs or not is orthogonal to DHCP
> >> > configuration. The kernel's built-in DHCP configuration works even if
> >> > you're not using a network filesystem as the root filesystem.
> >> 
> >> The initramfs is supposed to take responsibility for handling all of
> >> the legacy boot parameters.  Moving this to initramfs-tools and merging
> >> it with the existing bug there.
> >
> > That wouldn't actually solve the issue as reported. I was hoping
> > specifically for the in-kernel support.
> >
> > I'd like to use this on a cloud instance that uses ext4 on NVMe, and
> > thus doesn't currently need an initramfs.
> 
> I think your concern is around making VM boot fast. I don't want to put
> words in your mouth, but if I am correct, this may help your argument.

That's true, yes. I'm currently booting cloud instances in a fraction of
a second, and this will help with that.

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

2021-04-11 Thread Vincent Bernat

 ❦ 11 avril 2021 18:44 -07, Josh Triplett:

>> > Whether you have an initramfs or not is orthogonal to DHCP
>> > configuration. The kernel's built-in DHCP configuration works even if
>> > you're not using a network filesystem as the root filesystem.
>> 
>> The initramfs is supposed to take responsibility for handling all of
>> the legacy boot parameters.  Moving this to initramfs-tools and merging
>> it with the existing bug there.
>
> That wouldn't actually solve the issue as reported. I was hoping
> specifically for the in-kernel support.
>
> I'd like to use this on a cloud instance that uses ext4 on NVMe, and
> thus doesn't currently need an initramfs.

I think your concern is around making VM boot fast. I don't want to put
words in your mouth, but if I am correct, this may help your argument.
-- 
Water, taken in moderation cannot hurt anybody.
-- Mark Twain

Bug#986777: RFS: ink/0.5.3-2 [QA] -- tool for checking the ink level of your local printer

2021-04-11 Thread Hugo Torres de Lima

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ink
   Version : 0.5.3-2
   Upstream Author : Markus Heinz 
 * URL : http://ink.sourceforge.net/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/ink
   Section : admin

It builds those binary packages:

  ink - tool for checking the ink level of your local printer

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/i/ink/ink_0.5.3-2.dsc

Changes since the last upload:

 ink (0.5.3-2) experimental; urgency=medium
 .
   * QA upload.
   * debian/control:
   - Bumped DH level format to 13.
   - Bumped Standards-Version to 4.5.1.
   * debian/copyright:
   - Added Upstream-Contact.
   - Updated license order.
   - Updated upstream and packaging copyright years.
   * debian/ink.lintian-overrides: Added for false positive about
   spelling-error-in-binary.
   * debian/rules:
   - Removed comments.
   - Updated DEB_LDFLAGS_MAINT_APPEND and added DEB_CFLAGS_MAINT_APPEND
 variable to improve the GCC hardening.
   * debian/salsa-ci.yml: Added to provide CI tests for Salsa.
   * debian/tests/control: Created for basic CI testing.
   * debian/upstream/metadata: Created.
   * debian/watch:
   - Bumped to version 4.
   - Updated the source address.

Regards,
-- 
  Hugo Torres de Lima

Bug#986780: unblock: email-reminder/0.8.1-3

2021-04-11 Thread Francois Marier

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

Please unblock package email-reminder

[ Reason ]
The .desktop file is not installed (bug #986744).

[ Impact ]
A non-technical user likely won't be able to start the application at
all.

[ Tests ]
Manual test: open gnome-shell and ensure it's displayed in the list of
applications.

[ Risks ]
Minimal: one-line change which only affects the .desktop file.

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

unblock email-reminder/0.8.1-3
diff -Nru email-reminder-0.8.1/debian/changelog email-reminder-0.8.1/debian/changelog
--- email-reminder-0.8.1/debian/changelog	2021-01-18 22:01:41.0 -0800
+++ email-reminder-0.8.1/debian/changelog	2021-04-10 19:26:37.0 -0700
@@ -1,3 +1,9 @@
+email-reminder (0.8.1-3) unstable; urgency=medium
+
+  * Add missing .desktop file (closes: #986744).
+
+ -- Francois Marier   Sat, 10 Apr 2021 19:26:37 -0700
+
 email-reminder (0.8.1-2) unstable; urgency=medium
 
   * Bump Standards-Version up to 4.5.1.
diff -Nru email-reminder-0.8.1/debian/install email-reminder-0.8.1/debian/install
--- email-reminder-0.8.1/debian/install	1969-12-31 16:00:00.0 -0800
+++ email-reminder-0.8.1/debian/install	2021-04-10 19:26:37.0 -0700
@@ -0,0 +1 @@
+email-reminder.desktop  usr/share/applications

Bug#986779: preinst script misses dependency on dpkg-dev

2021-04-11 Thread Daniel Leidert

Package: fwupd
Version: 1.2.13-3+deb10u2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The preinst script uses `dpkg-vendor` which is provided by dpkg-dev. But there
is no (pre-)dependency on this package. Thus the preinst script throws an
error:

Preparing to unpack .../04-fwupd_1.2.13-3+deb10u2_amd64.deb ...
/var/lib/dpkg/tmp.ci/preinst: 13: /var/lib/dpkg/tmp.ci/preinst: dpkg-vendor: 
not found

Regards, Daniel



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

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

Versions of packages fwupd depends on:
ii  libc6  2.31-11
ii  libcurl3-gnutls7.74.0-1.2
ii  libefiboot137-6
ii  libelf10.183-3
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-3
ii  libfwupdplugin11.5.7-3
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-3
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-30
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-3
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.20-2
pn  fwupd-signed   
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-1

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmBzxucACgkQS80FZ8KW
0F2kcg//VqaaEPlz0mZ+PgszRPwBnjGV8CY561BNSV37Q8tF+KPnKgAN8BAUUIqm
/ONl0sh17uhGKGUi9o/35LmEyGqUCHUcNZ1/RcYxRSzOpplQEAYIHHqZLk9nU/6A
30PBbKj8h0oBW/y7+54iNKoPB3ME6A1wbkE8PR/bRoUcerIQ4WsYL0S1mihQINh1
kXTCsRh5BbTrON8dHcuFIuHXrgzNaW0gVBWxewKnS1cl591dMJOIljlRqo93612W
6dVJ/WPRSZH1xncz5TDRmxqgO0anFzR8RnIT+u7Rvgz7fOrGOg0ME55jMSa03JJz
kqp1RHGEM2ZryfLolEs/Bu6eKfkgBSRH5kRXnRwDp2N+2K04e6fx++9W/R75Se/Q
61vUl7rHOFL3S2z0g1+jfAUE+P1fmRwlHKfK3Bn47eBd3KjlQZEy68tt1WNIvabK
s56zzwwyFJO+Dfd5a7iJCy9Re7MXOWN/DSVjLtaMvsXjKmEM8TOFuRHGdiaYkHan
ROqUfzuwP62zyrD1kt51zNaFuLIJqWrMk80J3rgx6iPkUF4dK8i3qENZ6ivvD+YA
kGcCQ4iME+HU6CjJ8VyNuK7Ykg2d1aNakY7fRuJT32oHPBDhcC4bcOfbEC3+09vX
KgOmA/UWs1q47wut4+yXUfvhFV+/7NIdvGYjF1RnDg/PL2wyE3Y=
=n2ol
-END PGP SIGNATURE-

Bug#986778: ITP: gcc-sh-elf -- GNU C compiler for embedded SuperH devices

2021-04-11 Thread John Scott

Package: wnpp
Severity: wishlist
Owner: John Scott 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-electronics-de...@alioth-lists.debian.net
Control: block -1 by 912271 980889

* Package name    : gcc-sh-elf
  Upstream Author : GNU Project
* URL : https://gcc.gnu.org
* License : GPL
  Programming Lang: C, C++
  Description : GNU C compiler for embedded SuperH devices

This native package will provide a build of gcc as a cross-compiler for
bare-metal SuperH devices as well as a build of Newlib to serve as the
ISO C standard library.

My primary motivation is to make possible building carl9170, the libre
wireless firmware for Atheros AR9170 USB wireless adapters, but it may
be useful for other applications as well. I plan to maintain this
within the Electronics Team.



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

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

2021-04-11 Thread Josh Triplett

On Sun, Apr 11, 2021 at 10:45:27PM +0200, Ben Hutchings wrote:
> Control: reassign -1 initramfs-tools
> Control: tag -1 - wontfix
> Control: forcemerge 789067 -1
> 
> On Sat, 2021-04-10 at 15:36 -0700, Josh Triplett wrote:
> > On Sat, Apr 10, 2021 at 11:23:53PM +0200, Bastian Blank wrote:
> > > On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> > > > For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> > > > minimal network configuration. Enabling this option will do nothing
> > > > unless the kernel command line includes ip=dhcp.
> > > 
> > > We don't support initramfs-less boot.
> > 
> > Whether you have an initramfs or not is orthogonal to DHCP
> > configuration. The kernel's built-in DHCP configuration works even if
> > you're not using a network filesystem as the root filesystem.
> 
> The initramfs is supposed to take responsibility for handling all of
> the legacy boot parameters.  Moving this to initramfs-tools and merging
> it with the existing bug there.

That wouldn't actually solve the issue as reported. I was hoping
specifically for the in-kernel support.

I'd like to use this on a cloud instance that uses ext4 on NVMe, and
thus doesn't currently need an initramfs.

Bug#986727: pexpect: flaky and superficial? autopkgtest

2021-04-11 Thread Jochen Sprickerhof


Hi,

I looked into this bug but was not able to reproduce it locally.
But it looks like that the autopkgtests only rerun the unit tests with 
the local source code and don't test the installed package at all. I was 
able to run the tests successfully without having the package installed.
As those tests are run during the package build already, I would propose 
to remove the autopkgtests.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#958499: eclipse: fails to launch

2021-04-11 Thread Emmanuel Bourg

Control: tags -1 + wontfix
Control: done -1

Eclipse is no longer in Debian

Bug#986776: [INTL:es] Spanish translation of the debconf template python-certbot

2021-04-11 Thread jathan

Package: python-certbot
Severity: wishlist


Hi,

please find attached the Spanish debconf translation of python-certbot.

Regards,
Jathan

-- 
A permissive license would only be more "free" than a license like the
GPL, when a society that allows slavery be considered more free than
a society that does not.
https://www.gnu.org/licenses/agpl-3.0.en.html



# python-certbot po-debconf translation to Spanish.
# Copyright (C) 2021 Software in the Public Interest
# This file is distributed under the same license as the python-certbot package.
#
# Changes:
# - Initial translation
# Jonathan Bustillos , 2021.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentaciÃ³n de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducciÃ³n al espaÃ±ol, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducciÃ³n de Debian al espaÃ±ol
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducciÃ³n en
# http://www.debian.org/intl/spanish/notas
#
# - La guÃa de traducciÃ³n de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: python-certbot\n"
"Report-Msgid-Bugs-To: python-cert...@packages.debian.org\n"
"POT-Creation-Date: 2020-06-21 21:24-0400\n"
"PO-Revision-Date: 2021-04-03 14:32-0600\n"
"Last-Translator: Jonathan Bustillos \n"
"Language-Team: Debian Spanish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: boolean
#. Description
#: ../certbot.templates:1001
msgid "You have unexpired certs; do you still want to purge?"
msgstr "Tiene certificados no caducados; Â¿AÃºn asÃ desea purgarlos?"

#. Type: boolean
#. Description
#: ../certbot.templates:1001
msgid ""
"The certbot configuration directory /etc/letsencrypt still contains "
"unexpired certificates that may be live on your system.  If you choose this "
"option, the purge will continue and delete those certificates, potentially "
"breaking services which depend on them."
msgstr ""
"El directorio de configuraciÃ³n de certbot /etc/letsencrypt todavÃa contiene "
"certificados no caducados que pueden estar activos en su sistema.  Si elige "
"esta opciÃ³n, la purga continuarÃ¡ y borrarÃ¡ esos certificados, pudiendo "
"romper los servicios que dependen de ellos."

#. Type: boolean
#. Description
#: ../certbot.templates:1001
msgid ""
"If you have already installed different certificates in your services, or "
"you have confirmed you don't have any services depending on these "
"certificates, you should choose this option.  To cancel and manually delete "
"the /etc/letsencrypt directory, you should refuse this option."
msgstr ""
"Si ya ha instalado diferentes certificados en sus servicios, o ha confirmado "
"que no tiene ningÃºn servicio que dependa de estos certificados, debe elegir "
"esta opciÃ³n.  Para cancelar y eliminar manualmente el directorio /etc/"
"letsencrypt, debe rechazar esta opciÃ³n."


signature.asc
Description: OpenPGP digital signature

Bug#986775: [INTL:es] Spanish translation of the debconf template postgresql-13

2021-04-11 Thread jathan

Package: postgresql-13
Severity: wishlist


Hi,

please find attached the Spanish debconf translation of postgresql-13.

Regards,
Jathan

-- 
A permissive license would only be more "free" than a license like the
GPL, when a society that allows slavery be considered more free than
a society that does not.
https://www.gnu.org/licenses/agpl-3.0.en.html


# postgresql-13 po-debconf translation to Spanish.
# Copyright (C) 2021 Software in the Public Interest
# This file is distributed under the same license as the postgresql-13 package.
#
# Changes:
# - Initial translation
# Jonathan Bustillos , 2021.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentaciÃ³n de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducciÃ³n al espaÃ±ol, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducciÃ³n de Debian al espaÃ±ol
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducciÃ³n en
# http://www.debian.org/intl/spanish/notas
#
# - La guÃa de traducciÃ³n de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-03-31 18:37+\n"
"PO-Revision-Date: 2021-04-03 14:25-0600\n"
"Last-Translator: Jonathan Bustillos \n"
"Language-Team: Debian Spanish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: boolean
#. Description
#: ../postgresql-13.templates:1001
msgid "Remove PostgreSQL directories when package is purged?"
msgstr "Â¿Eliminar los directorios de PostgreSQL cuando se purga el paquete?"

#. Type: boolean
#. Description
#: ../postgresql-13.templates:1001
msgid ""
"Removing the PostgreSQL server package will leave existing database clusters "
"intact, i.e. their configuration, data, and log directories will not be "
"removed. On purging the package, the directories can optionally be removed."
msgstr ""
"La eliminaciÃ³n del paquete del servidor PostgreSQL dejarÃ¡ intactos los "
"clusters de bases de datos existentes, es decir, no se eliminarÃ¡n sus "
"directorios de configuraciÃ³n, datos y registro. Al purgar el paquete, los "
"directorios pueden ser eliminados opcionalmente."


signature.asc
Description: OpenPGP digital signature

Bug#986774: [INTL:es] Spanish translation of the debconf template munin

2021-04-11 Thread jathan

Package: munin
Severity: wishlist


Hi,

please find attached the Spanish debconf translation of munin.

Regards,
Jathan

-- 
A permissive license would only be more "free" than a license like the
GPL, when a society that allows slavery be considered more free than
a society that does not.
https://www.gnu.org/licenses/agpl-3.0.en.html

# munin po-debconf translation to Spanish.
# Copyright (C) 2021 Software in the Public Interest
# This file is distributed under the same license as the munin package.
#
# Changes:
# - Initial translation
# Jonathan Bustillos , 2021.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentaciÃ³n de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducciÃ³n al espaÃ±ol, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducciÃ³n de Debian al espaÃ±ol
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducciÃ³n en
# http://www.debian.org/intl/spanish/notas
#
# - La guÃa de traducciÃ³n de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: munin\n"
"Report-Msgid-Bugs-To: mu...@packages.debian.org\n"
"POT-Creation-Date: 2019-08-04 17:40+0200\n"
"PO-Revision-Date: 2021-04-03 14:16-0600\n"
"Last-Translator: Jonathan Bustillos \n"
"Language-Team: Debian Spanish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: boolean
#. Description
#: ../munin.templates:1001
msgid "Remove all RRD database files?"
msgstr "Â¿Eliminar todos los archivos de la base de datos RRD?"

#. Type: boolean
#. Description
#: ../munin.templates:1001
msgid ""
"The /var/lib/munin directory which contains the RRD files with the data "
"accumulated by munin is about to be removed."
msgstr ""
"El directorio /var/lib/munin que contiene los archivos RRD con los datos "
"acumulados por munin estÃ¡ a punto de ser eliminado."

#. Type: boolean
#. Description
#: ../munin.templates:1001
msgid ""
"If you want to install munin later again or if you want to use the content "
"of the RRD files for other purposes, the data should be kept."
msgstr ""
"Si desea volver a instalar munin mÃ¡s adelante o si desea utilizar el "
"contenido de los archivos RRD para otros fines, los datos deben conservarse."


signature.asc
Description: OpenPGP digital signature

Bug#986773: [INTL:es] Spanish translation of the debconf template libvirt

2021-04-11 Thread jathan

Package: libvirt
Severity: wishlist


Hi,

please find attached the Spanish debconf translation of libvirt.

Regards,
Jathan

-- 
A permissive license would only be more "free" than a license like the
GPL, when a society that allows slavery be considered more free than
a society that does not.
https://www.gnu.org/licenses/agpl-3.0.en.html
# libvirt po-debconf translation to Spanish.
# Copyright (C) 2021 Software in the Public Interest
# This file is distributed under the same license as the libvirt package.
#
# Changes:
# - Initial translation
# Jonathan Bustillos , 2021.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentaciÃ³n de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducciÃ³n al espaÃ±ol, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducciÃ³n de Debian al espaÃ±ol
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducciÃ³n en
# http://www.debian.org/intl/spanish/notas
#
# - La guÃa de traducciÃ³n de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: libvirt\n"
"Report-Msgid-Bugs-To: libv...@packages.debian.org\n"
"POT-Creation-Date: 2016-12-22 14:20+0100\n"
"PO-Revision-Date: 2021-04-03 13:42-0600\n"
"Last-Translator: Jonathan Bustillos \n"
"Language-Team: Debian Spanish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid "Continue with incorrect libvirt-qemu user/group ID(s)?"
msgstr "Â¿Continuar con ID(s) de usuario/grupo incorrectos de libvirt-qemu?"

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" The user/group ID (uid/gid) allocated for libvirt-qemu (64055)\n"
" seems to be taken by another user/group, thus it is not possible\n"
" to create the user/group with this numeric ID."
msgstr ""
" El ID de usuario/grupo (uid/gid) asignado para libvirt-qemu (64055) \n"
" parece estar ocupado por otro usuario/grupo, por lo que no es posible\n"
" crear el usuario/grupo con este ID numÃ©rico."

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" The migration of guests with disk image files shared over NFS\n"
" requires a static libvirt-qemu user and group ID (uid and gid)\n"
" between the source and destination host systems."
msgstr ""
" La migraciÃ³n de huÃ©spedes con archivos de imagen de disco compartidos a "
"travÃ©s de NFS\n"
" requiere una identificaciÃ³n estÃ¡tica de usuario y grupo (uid y gid) de "
"libvirt-qemu\n"
" entre los sistemas anfitriones de origen y destino."

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" If guest migration over NFS is not required, you can continue\n"
" the installation."
msgstr ""
" Si la migraciÃ³n de huÃ©sped a travÃ©s de NFS no es necesaria, puede "
"continuar\n"
" la instalaciÃ³n."

#. Type: boolean
#. Description
#: ../libvirt-daemon-system.templates:1001
msgid ""
" In order to resolve this problem, do not continue the installation,\n"
" release the 64055 uid/gid (which might involve permission changes),\n"
" then install this package again."
msgstr ""
" Para resolver este problema, no continÃºe la instalaciÃ³n,\n"
" libere el uid/gid 64055 (lo que podrÃa implicar cambios en los permisos),\n"
" y vuelva a instalar este paquete."


signature.asc
Description: OpenPGP digital signature

Bug#986772: [patch] debian-cd: Include eatmydata deb for udeb to use offline

2021-04-11 Thread Petter Reinholdtsen



Package: debian-cd
Version: 3.1.33
Tags: patch

A proposal is floating on debian-boot@ to speed up the installation
significatly using the eatmydata-udeb.  This only work with network
installations, but it would be great if it worked with offline
installations too.

See thread starting on
https://lists.debian.org/debian-boot/2021/03/msg00121.html > for
the history so far.

The eatmydatat udeb has been in included on the Debian Edu images for a
while now, the deb is small, and is not activated by default with this
change, so the impact for the default installation is very small.

diff --git a/tasks/bullseye/forcd1 b/tasks/bullseye/forcd1
index 37733845..904ee658 100644
--- a/tasks/bullseye/forcd1
+++ b/tasks/bullseye/forcd1
@@ -23,3 +23,6 @@ pppconfig
 /* #861288 - make it easier for users to report installation problems */
 reportbug
 
+/* ensure eatmydata-udeb can speed up offline installs too */
+eatmydata
+libeatmydata1

-- 
Happy hacking
Petter Reinholdtsen

Bug#986770: shapetools: FTBFS with glibc 2.32

2021-04-11 Thread Logan Rosen

Package: shapetools
Version: 1.4pl6-14
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

shapetools currently FTBFS against glibc 2.32, which is used in the
development release of Ubuntu (and should be in Debian soon).

This is because it uses sys_errlist instead of strerror(), which is also
supported in earlier versions of glibc.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use strerror() instead of sys_errlist to fix FTBFS with glibc 2.32.

Thanks for considering the patch.

Logan
diff -u shapetools-1.4pl6/src/atfs/aferror.c 
shapetools-1.4pl6/src/atfs/aferror.c
--- shapetools-1.4pl6/src/atfs/aferror.c
+++ shapetools-1.4pl6/src/atfs/aferror.c
@@ -272,7 +272,7 @@
 
   switch (af_errno) {
   case AF_ESYSERR:
-sprintf (errMsg, "%s: %s", string, sys_errlist[errno]);
+sprintf (errMsg, "%s: %s", string, strerror(errno));
 break;
   case AF_EMISC:
 sprintf (errMsg, "%s: %s", string, diagstr);
diff -u shapetools-1.4pl6/src/atfs/atfsrepair.c 
shapetools-1.4pl6/src/atfs/atfsrepair.c
--- shapetools-1.4pl6/src/atfs/atfsrepair.c
+++ shapetools-1.4pl6/src/atfs/atfsrepair.c
@@ -495,7 +495,7 @@
 lockInfo.l_pid = (pid_t)0;
 if (fcntl (fileno(inFile), F_GETLK, ) == -1) {
   fprintf (stderr, "->   Error:\tCannot get lock info for %s -- fcntl 
failed (%s)!\n",
-  arFilename, sys_errlist[errno]);
+  arFilename, strerror(errno));
   fclose (inFile);
   cleanup ();
 }
@@ -525,7 +525,7 @@
 lockInfo.l_pid = (pid_t)0;
 if (fcntl (fileno(inFile), F_SETLK, ) == -1) {
   fprintf (stderr, "->   Error:\tCannot unlock %s -- fcntl failed (%s)!\n",
-  arFilename, sys_errlist[errno]);
+  arFilename, strerror(errno));
   fclose (inFile);
   cleanup ();
 }
@@ -1437,7 +1437,7 @@
if (modeConfirmed) {
  if (chmod (attrArPath, atfsIbuf.st_mode) == -1)
fprintf (stderr, "Error:\tCannot change protection of '%s': 
%s\n",
-attrArPath, sys_errlist[errno]);
+attrArPath, strerror(errno));
}
  }
  if (atfsIbuf.st_gid != subIbuf.st_gid) {
@@ -1454,7 +1454,7 @@
  if (chown (attrArPath, atfsIbuf.st_uid, atfsIbuf.st_gid) == -1)
if (chown (attrArPath, geteuid(), atfsIbuf.st_gid) == -1) {
  fprintf (stderr, "Error:\tCannot change Owner/Group of '%s': 
%s\n",
-  attrArPath, sys_errlist[errno]);
+  attrArPath, strerror(errno));
}
  }
}
diff -u shapetools-1.4pl6/src/atfs/cacheadm.c 
shapetools-1.4pl6/src/atfs/cacheadm.c
--- shapetools-1.4pl6/src/atfs/cacheadm.c
+++ shapetools-1.4pl6/src/atfs/cacheadm.c
@@ -132,7 +132,7 @@
retCode += setCacheSize (argv[i+optind]);
   }
   else {
-   fprintf (stderr, "  Error -- %s: %s\n", argv[i+optind], 
sys_errlist[errno]);
+   fprintf (stderr, "  Error -- %s: %s\n", argv[i+optind], 
strerror(errno));
   }
 }
   }
diff -u shapetools-1.4pl6/src/shape/parser.h 
shapetools-1.4pl6/src/shape/parser.h
--- shapetools-1.4pl6/src/shape/parser.h
+++ shapetools-1.4pl6/src/shape/parser.h
@@ -39,5 +39,5 @@
 extern char *sys_errlist[] ;   /* ... these strings by myself */
 #endif
-#define fatal_perror(string)fatal(sys_errlist[errno], string)
+#define fatal_perror(string)fatal(strerror(errno), string)
 
 
diff -u shapetools-1.4pl6/src/vc/rcs2atfs/utils.c 
shapetools-1.4pl6/src/vc/rcs2atfs/utils.c
--- shapetools-1.4pl6/src/vc/rcs2atfs/utils.c
+++ shapetools-1.4pl6/src/vc/rcs2atfs/utils.c
@@ -387,16 +387,16 @@
switch (errno) {
  case EACCES:
if (! recursive) {
-   error(sys_errlist[errno], fname) ;
+   error(strerror(errno), fname) ;
}
return f_error ;
  case EFAULT:
-   fatal(sys_errlist[errno], MUSTNOT) ;
+   fatal(strerror(errno), MUSTNOT) ;
  case ENOENT:
/* can be RCS working file without busy version */
return f_plain ;
  default:
-   error(sys_errlist[errno], fname) ;
+   error(strerror(errno), fname) ;
}
 }
 
only in patch2:
unchanged:
--- shapetools-1.4pl6.orig/src/vc/rcs2atfs/main.c
+++ shapetools-1.4pl6/src/vc/rcs2atfs/main.c
@@ -98,12 +98,12 @@
 if (use_pipe) {
/* open pipe to Bourne Shell */
if ((out = popen(BOURNE_SHELL, "w")) == NULL) {
-   fatal(POPEN_SHELL, sys_errlist[errno]) ;
+   fatal(POPEN_SHELL, strerror(errno)) ;
}
 } else {
/* open output file for script */
if ((out = fopen(shellscript, "w")) == NULL) {
-   fatal(sys_errlist[errno], shellscript) ;
+   fatal(strerror(errno), shellscript) ;
}
/* insert some header into shell script (#!/bin/sh etc.) */
fprintf(out,

Bug#986409: unblock: azure-cosmos-python/3.1.1-4

2021-04-11 Thread Luca Boccassi

On Sun, 2021-04-11 at 14:29 +0200, Ivo De Decker wrote:
> Hi,
> 
> On Tue, Apr 06, 2021 at 09:21:10PM +0100, Luca Boccassi wrote:
> > > Changes to the debhelper compat are no longer appropriate at this
> > > point
> > > in the freeze. Please revert that. Once the new version is
> > > available in
> > > unstable, please remove the moreinfo tag.
> > 
> > Thanks for the review - I would rather not change this again. The
> > package is trivial, and thus this version bump is trivial too, and
> > has
> > no discernible effect bar silencing Lintian.
> 
> See the last entry at
> https://release.debian.org/bullseye/FAQ.html

"Changing the debhelper compat version changes the resulting packages,
sometimes in complicated or unintended ways. Carefully checking the
details of these changes is too much work when processing an unblock
request."

As mentioned, it's identical before/after. The only difference you can
see is that a generated comment in a script doesn't end with a colon
anymore:

$ diffoscope python3-azure-cosmos_3.1.1-3_all.deb 
python3-azure-cosmos_3.1.1-4_all.deb
--- python3-azure-cosmos_3.1.1-3_all.deb
+++ python3-azure-cosmos_3.1.1-4_all.deb
├── file list
│ @@ -1,3 +1,3 @@
│ --rw-r--r--   0004 2020-03-07 10:58:01.00 
debian-binary
│ --rw-r--r--   000 2328 2020-03-07 10:58:01.00 
control.tar.xz
│ --rw-r--r--   00051572 2020-03-07 10:58:01.00 
data.tar.xz
│ +-rw-r--r--   0004 2021-03-12 12:02:24.00 
debian-binary
│ +-rw-r--r--   000 2324 2021-03-12 12:02:24.00 
control.tar.xz
│ +-rw-r--r--   00051812 2021-03-12 12:02:24.00 
data.tar.xz
├── control.tar.xz
│ ├── control.tar
│ │ ├── file list
│ │ │ @@ -1,5 +1,5 @@
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2020-03-07 
10:58:01.00 ./
│ │ │ --rw-r--r--   0 root (0) root (0)  464 2020-03-07 
10:58:01.00 ./control
│ │ │ --rw-r--r--   0 root (0) root (0) 4868 2020-03-07 
10:58:01.00 ./md5sums
│ │ │ --rwxr-xr-x   0 root (0) root (0)  266 2020-03-07 
10:58:01.00 ./postinst
│ │ │ --rwxr-xr-x   0 root (0) root (0)  415 2020-03-07 
10:58:01.00 ./prerm
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-03-12 
12:02:24.00 ./
│ │ │ +-rw-r--r--   0 root (0) root (0)  443 2021-03-12 
12:02:24.00 ./control
│ │ │ +-rw-r--r--   0 root (0) root (0) 4868 2021-03-12 
12:02:24.00 ./md5sums
│ │ │ +-rwxr-xr-x   0 root (0) root (0)  265 2021-03-12 
12:02:24.00 ./postinst
│ │ │ +-rwxr-xr-x   0 root (0) root (0)  414 2021-03-12 
12:02:24.00 ./prerm
│ │ ├── ./control
│ │ │ @@ -1,12 +1,12 @@
│ │ │  Package: python3-azure-cosmos
│ │ │  Source: azure-cosmos-python
│ │ │ -Version: 3.1.1-3
│ │ │ +Version: 3.1.1-4
│ │ │  Architecture: all
│ │ │ -Maintainer: Debian Python Modules Team 

│ │ │ +Maintainer: Debian Python Team 
│ │ │  Installed-Size: 383
│ │ │  Depends: python3-requests, python3-six (>= 1.6), python3:any
│ │ │  Section: python
│ │ │  Priority: optional
│ │ │  Homepage: https://github.com/Azure/azure-cosmos-python
│ │ │  Description: Azure DocumentDB Python SDK
│ │ │   This package provides the Python 3 modules for the Azure DocumentDB API.
│ │ ├── ./md5sums
│ │ │ ├── ./md5sums
│ │ │ │┄ Files differ
│ │ ├── ./postinst
│ │ │ @@ -1,11 +1,11 @@
│ │ │  #!/bin/sh
│ │ │  set -e
│ │ │  
│ │ │ -# Automatically added by dh_python3:
│ │ │ +# Automatically added by dh_python3
│ │ │  if which py3compile >/dev/null 2>&1; then
│ │ │   py3compile -p python3-azure-cosmos 
│ │ │  fi
│ │ │  if which pypy3compile >/dev/null 2>&1; then
│ │ │   pypy3compile -p python3-azure-cosmos  || true
│ │ │  fi
│ │ ├── ./prerm
│ │ │ @@ -1,11 +1,11 @@
│ │ │  #!/bin/sh
│ │ │  set -e
│ │ │  
│ │ │ -# Automatically added by dh_python3:
│ │ │ +# Automatically added by dh_python3
│ │ │  if which py3clean >/dev/null 2>&1; then
│ │ │   py3clean -p python3-azure-cosmos 
│ │ │  else
│ │ │   dpkg -L python3-azure-cosmos | perl -ne 
's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach 
glob($_)'
│ │ │   find /usr/lib/python3/dist-packages/ -type d -name __pycache__ -empty 
-print0 | xargs --null --no-run-if-empty rmdir
│ │ │  fi
├── data.tar.xz
│ ├── data.tar
│ │ ├── file list
│ │ │ @@ -1,25 +1,25 @@
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2020-03-07 
10:58:01.00 ./
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2020-03-07 
10:58:01.00 ./usr/
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2020-03-07 
10:58:01.00 ./usr/lib/
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2020-03-07 
10:58:01.00 ./usr/lib/python3/
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2020-03-07 
10:58:01.00

Bug#986622: [Pkg-clamav-devel] Bug#986622: fixes

2021-04-11 Thread Sebastian Andrzej Siewior

On 2021-04-10 15:10:36 [+0200], Matus UHLAR - fantomas wrote:
> Hello,
Hi,

> I just wanted to note that clamav 0.103.2 fixes[1] all issues currently open
> at security tracker[2]
> 
> CVE-2021-1252
> CVE-2021-1404
> CVE-2021-1405

Everyone wondering, yes I am aware but not as fast as I would like to.
My plan is to get 103.2 into Buster after I spent the day today to look
what should be backported and what not.

Sebastian

Bug#986769: wireshark: Dropdown menus invisible in Sway

2021-04-11 Thread Pelle

Package: wireshark
Version: 3.4.4-1
Severity: normal

Dear Maintainer,

Wireshark's dropdown menus are invisible in Sway (the Wayland compositor). The
invisible dropdown menu entries can't be clicked but they can still be
activated via keyboard. The dropdown menus in other QT-based apps (VLC, Krita,
…) work fine in Sway.

A workaround is to run `ssh -X localhost wireshark` in Sway, or to run
Wireshark inside Weston.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_CRAP
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 wireshark depends on:
ii  wireshark-qt  3.4.4-1

wireshark recommends no packages.

wireshark suggests no packages.

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

2021-04-11 Thread Ben Hutchings

Control: reassign -1 initramfs-tools
Control: tag -1 - wontfix
Control: forcemerge 789067 -1

On Sat, 2021-04-10 at 15:36 -0700, Josh Triplett wrote:
> On Sat, Apr 10, 2021 at 11:23:53PM +0200, Bastian Blank wrote:
> > On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> > > For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> > > minimal network configuration. Enabling this option will do nothing
> > > unless the kernel command line includes ip=dhcp.
> > 
> > We don't support initramfs-less boot.
> 
> Whether you have an initramfs or not is orthogonal to DHCP
> configuration. The kernel's built-in DHCP configuration works even if
> you're not using a network filesystem as the root filesystem.

The initramfs is supposed to take responsibility for handling all of
the legacy boot parameters.  Moving this to initramfs-tools and merging
it with the existing bug there.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


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

Bug#986768: snakemake: autopkgtest regression: Missing input files for rule remote_ancient

2021-04-11 Thread Paul Gevers

Source: snakemake
Version: 5.24.1-1
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer,

Your package has an autopkgtest, great! However, the last couple of days
it started to fail [1]. Looking at the error, it seems a remote file has
disappeared. Can you investigate and fix the situation? Additionally, if
your test needs internet, it must set the needs-internet restriction.

Paul

[1] https://ci.debian.net/packages/s/snakemake/

https://ci.debian.net/data/autopkgtest/testing/amd64/s/snakemake/11609476/log.gz

- Captured stderr call
-
Building DAG of jobs...
Full Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/__init__.py",
line 643, in snakemake
success = workflow.execute(
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/workflow.py",
line 672, in execute
dag.init()
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 177, in init
job = self.update(self.file2jobs(file), file=file, progress=progress)
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 753, in update
raise exceptions[0]
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 711, in update
self.update_(
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 848, in update_
raise MissingInputException(job.rule, missing_input)
snakemake.exceptions.MissingInputException: Missing input files for rule
remote_ancient:
github.com/snakemake/snakemake/raw/master/tests/test_remote_http/expected-results/landsat-data.txt

MissingInputException in line 38 of /tmp/snakemake-s4m7gneh/Snakefile:
Missing input files for rule remote_ancient:
github.com/snakemake/snakemake/raw/master/tests/test_remote_http/expected-results/landsat-data.txt
unlocking
removed all locks
-- Captured log call
---
WARNING  snakemake.logging:logging.py:373 Building DAG of jobs...
DEBUGsnakemake.logging:logging.py:379 Full Traceback (most recent
call last):
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/__init__.py",
line 643, in snakemake
success = workflow.execute(
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/workflow.py",
line 672, in execute
dag.init()
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 177, in init
job = self.update(self.file2jobs(file), file=file, progress=progress)
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 753, in update
raise exceptions[0]
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 711, in update
self.update_(
  File
"/tmp/autopkgtest-lxc.q0choluk/downtmp/build.FZs/src/snakemake/dag.py",
line 848, in update_
raise MissingInputException(job.rule, missing_input)
snakemake.exceptions.MissingInputException: Missing input files for rule
remote_ancient:
github.com/snakemake/snakemake/raw/master/tests/test_remote_http/expected-results/landsat-data.txt

ERRORsnakemake.logging:logging.py:377 MissingInputException in line
38 of /tmp/snakemake-s4m7gneh/Snakefile:
Missing input files for rule remote_ancient:
github.com/snakemake/snakemake/raw/master/tests/test_remote_http/expected-results/landsat-data.txt




OpenPGP_signature
Description: OpenPGP digital signature

Bug#986031: ogmrip crashes on startup with "malloc(): unsorted double linked list corrupted"

2021-04-11 Thread Bernhard Übelacker


Dear Maintainer,
I tried to have a look and the segfault is really a result of the
previous g_param_spec_is_valid_name failures.

It looks like g_param_spec_is_valid_name got tightened lately to
not accept names with dashes anymore.

The following malloc corruption seems to originate in the backtrace below.
There the value pointer neither gets initialised, nor written to,
therefore the free fails.

Attached patch would replace thes "/" by "-" in the parameters
which get accepted by glib2.0.

I assume because of this issue this package is not usable at all,
therefore should be the severity increased?

Kind regards,
Bernhard


export MALLOC_CHECK_=3
(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f11eae17537 in __GI_abort () at abort.c:79
#2  0x7f11eae70768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f11eaf7ee2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f11eae77a5a in malloc_printerr (str=str@entry=0x7f11eaf7d05a "free(): 
invalid pointer") at malloc.c:5347
#4  0x7f11eae79ca6 in free_check (mem=0x55a02d91b8f0, caller=) at hooks.c:255
#5  0x55a02cd9ac41 in ogmrip_profiles_check_profile (section=0x55a02daae930 
"/apps/ogmrip/profiles/default-avi", error=error@entry=0x0) at 
ogmrip-profiles.c:155
#6  0x55a02cd9c7bf in ogmrip_profiles_dialog_add_profiles 
(dialog=dialog@entry=0x55a02d9d4410, reload=reload@entry=0) at 
ogmrip-profiles-dialog.c:157
#7  0x55a02cd9d0e5 in ogmrip_profiles_dialog_init (dialog=0x55a02d9d4410) 
at ogmrip-profiles-dialog.c:733
#8  0x7f11eb11b391 in g_type_create_instance (type=) at 
../../../gobject/gtype.c:1868
#9  0x7f11eb101615 in g_object_new_internal 
(class=class@entry=0x55a02d92f430, params=params@entry=0x0, 
n_params=n_params@entry=0) at ../../../gobject/gobject.c:1939
#10 0x7f11eb102b1d in g_object_new_with_properties 
(object_type=94146449298656, n_properties=0, names=names@entry=0x0, 
values=values@entry=0x0) at ../../../gobject/gobject.c:2107
#11 0x7f11eb1035f1 in g_object_new (object_type=, 
first_property_name=first_property_name@entry=0x0) at ../../../gobject/gobject.c:1779
#12 0x55a02cd9d149 in ogmrip_profiles_dialog_new () at 
ogmrip-profiles-dialog.c:741
#13 0x55a02cd8a21d in ogmrip_main_profiles_dialog_construct 
(data=0x55a02d8a1b20) at ogmrip-main.c:1751
#14 main (argc=, argv=) at ogmrip-main.c:3215
Bug-Debian: https://bugs.debian.org/986031
Last-Update: 2021-04-11

--- ogmrip-1.0.1.orig/libogmrip-gtk/ogmrip-gconf-settings.c
+++ ogmrip-1.0.1/libogmrip-gtk/ogmrip-gconf-settings.c
@@ -63,10 +63,10 @@ my_gconf_concat_dir_and_key (const gchar
 
   strcpy (retval, dir);
 
-  if (dir[dirlen-1] == '/')
+  if (dir[dirlen-1] == '-')
   {
 /* dir ends in slash, strip key slash if needed */
-if (*key == '/')
+if (*key == '-')
   ++key;
 
 strcpy (retval + dirlen, key);
@@ -76,9 +76,9 @@ my_gconf_concat_dir_and_key (const gchar
 /* Dir doesn't end in slash, add slash if key lacks one. */
 gchar* dest = retval + dirlen;
 
-if (*key != '/')
+if (*key != '-')
 {
-  *dest = '/';
+  *dest = '-';
   ++dest;
 }
   
--- ogmrip-1.0.1.orig/libogmrip-gtk/ogmrip-lavc-options.c
+++ ogmrip-1.0.1/libogmrip-gtk/ogmrip-lavc-options.c
@@ -39,25 +39,25 @@
 #define OGMRIP_IS_LAVC_DIALOG(obj)   (G_TYPE_CHECK_INSTANCE_TYPE ((obj), 
OGMRIP_TYPE_LAVC_DIALOG))
 #define OGMRIP_IS_LAVC_DIALOG_CLASS(obj) (G_TYPE_CHECK_CLASS_TYPE ((klass), 
OGMRIP_TYPE_LAVC_DIALOG))
 
-#define OGMRIP_LAVC_KEY_CMP OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_CMP
-#define OGMRIP_LAVC_KEY_PRECMP  OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_PRECMP
-#define OGMRIP_LAVC_KEY_SUBCMP  OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_SUBCMP
-#define OGMRIP_LAVC_KEY_DIA OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_DIA
-#define OGMRIP_LAVC_KEY_PREDIA  OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_PREDIA
-#define OGMRIP_LAVC_KEY_KEYINT  OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_KEYINT
-#define OGMRIP_LAVC_KEY_BUF_SIZEOGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_BUF_SIZE
-#define OGMRIP_LAVC_KEY_MIN_RATEOGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_MIN_RATE
-#define OGMRIP_LAVC_KEY_MAX_RATEOGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_MAX_RATE
-#define OGMRIP_LAVC_KEY_STRICT  OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_STRICT
-#define OGMRIP_LAVC_KEY_DC  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_DC
-#define OGMRIP_LAVC_KEY_MBD OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_MBD
-#define OGMRIP_LAVC_KEY_QNS OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_QNS
-#define OGMRIP_LAVC_KEY_VB_STRATEGY OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_VB_STRATEGY
-#define OGMRIP_LAVC_KEY_LAST_PRED   OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_LAST_PRED
-#define OGMRIP_LAVC_KEY_PREME   OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_PREME
-#define OGMRIP_LAVC_KEY_VQCOMP  OGMRIP_LAVC_SECTION "/" 
OGMRIP_LAVC_PROP_VQCOMP
-#define

Bug#986716: installation-guide: Preseeding passwd/root-password-crypted with "!" doesn't work as described

2021-04-11 Thread Samuel Thibault

Control: reassigne -1 user-setup

Hello,

David Mandelberg, le ven. 09 avril 2021 23:06:06 -0400, a ecrit:
> https://www.debian.org/releases/bullseye/amd64/apbs04.en.html section
> B.4.5 talks about using "!" in passwd/root-password-crypted:
> > The passwd/root-password-crypted and passwd/user-password-crypted
> > variables can also be preseeded with "!" as their value. In that case,
> > the corresponding account is disabled. This may be convenient for the
> > root account, provided of course that an alternative method is set up
> > to allow administrative activities or root login (for instance by
> > using SSH key authentication or sudo).
> 
> When I tried that, it didn't seem to have any effect. From looking at
> what I think is the relevant code[0], it looks like a value of "!" in
> passwd/root-password-crypted is explicitly ignored.

It seems to me that it is actually a regression in the user-setup
package. "!" was really meant to mean empty password (thus disabled) and
it seems that the fix for #400766 broke it.

Samuel

Bug#985853: debian-installer: Whitespace before a commented line in preseed file causes line to be parsed

2021-04-11 Thread Samuel Thibault

Control: tags -1 + pending

Hello,

Holger Wansing, le sam. 10 avril 2021 12:32:57 +0200, a ecrit:
> Charles Curley  wrote (Thu, 25 Mar 2021 
> 12:06:32 -0600):
> > On Thu, 25 Mar 2021 10:49:06 -0400
> > lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> > 
> > > Well none of the examples ever have spaces before # for comments.
> > > The documentation page you linked to doesn't even mention comments at
> > > all. I would agree that perhaps it should.  I have certainly
> > > encountered file types before where comments had to have # at the
> > > start of the line.
> > 
> > May I suggest inserting the following as the last bullet point item at
> > the top of "B.3. Creating a preconfiguration file" the following:
> > 
> > A comment consist of a line which *starts* with a sharp character ("#")
> > and extends the length of that line.
> > 
> > https://www.debian.org/releases/stable/i386/apbs03.en.html
> > 
> > The emphasis on the word "starts" should probably be italics, or, in
> > HTML, .
> 
> Re-assigning to installation-guide

Commited, thanks!

Samuel

Bug#986767: installation-reports: Bullseye installation on Lamobo-R1

2021-04-11 Thread Andrey Jr. Melnikov

Package: installation-reports
Severity: important
Tags: d-i
X-Debbugs-Cc: temnota...@gmail.com

Boot method: SD card
Image version: unstable daily build
Date: 20210411

Machine: Lamobo R1
Partitions: 
Disk /dev/mmcblk0: 14.46 GiB, 15523119104 bytes, 30318592 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x15fd02d0

Device BootStart  End  Sectors  Size Id Type
/dev/mmcblk0p1 *2048   999423   997376  487M 83 Linux
/dev/mmcblk0p2999424 28332031 27332608   13G 83 Linux
/dev/mmcblk0p3  28332032 30316543  1984512  969M 82 Linux swap / Solaris

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

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

Comments/Problems:

Installer can't properly bring up BCM53125 with DSA - missing DSA module 
tag_brcm. Also, no USB is detected.

After replacing kernel modules in installer initrd.gz from 
linux-image-5.10.0-5-armmp_5.10.26-1_armhf.deb 
DSA properly detect and configure Broadcom BCM53125 switch, but unable to use 
it. Installer 
try enable individual interface (wan) and disable all other, but for DSA master 
interface (eth0) MUST be enabled before wan interface and stay up.

After connect USB network card - installer is able to detects network and 
complete the installation. 


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210409-00:04:58"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux lamobo-r1 5.10.0-5-armmp #1 SMP Debian 5.10.26-1 (2021-03-27) 
armv7l GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-5-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: AX88x72A [0b95:772a]
usb-list:Level 01 Parent 01 Port 00  Class ff(vend.) Subclass ff Protocol 00
usb-list:Manufacturer: ASIX Elec. Corp.
usb-list:Interface 00: Class ff(vend.) Subclass ff Protocol 00 Driver asix
usb-list: 
usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-5-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 02: 802.11n WLAN Adapter [0bda:8178]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Realtek
usb-list:Interface 00: Class ff(vend.) Subclass ff Protocol ff Driver 
rtl8192cu
usb-list: 
usb-list: Bus 03 Device 01: MUSB HDRC host driver [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 5.10.0-5-armmp musb-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-5-armmp ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: dm_mod114688  0
lsmod: md_mod147456  0
lsmod: xfs  1236992  0
lsmod: jfs   180224  0
lsmod: btrfs1339392  0
lsmod: blake2b_generic36864  0
lsmod: xor16384  1 btrfs
lsmod: xor_neon   16384  1 xor
lsmod: raid6_pq  106496  1 btrfs
lsmod: libcrc32c  16384  2 btrfs,xfs
lsmod: fuse  122880  0
lsmod: vfat   24576  0
lsmod: fat69632  1 vfat
lsmod: ext4  729088  2
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2  114688  1 ext4
lsmod: crc32c_generic 16384  4
lsmod: usb_storage57344  0
lsmod: rtl8192cu  69632  0
lsmod: rtl_usb20480  1 rtl8192cu
lsmod: rtl8192c_common40960  1 r

Bug#960154: lintian.d.o: please provide a stable, parsable output

2021-04-11 Thread Felix Lechner

Control: retitle -1 Feed UDD with just-in-time packaging hints from Lintian

Hi,

On Sat, May 9, 2020 at 5:33 PM Mattia Rizzolo  wrote:
>
> have lintian decide on a nice machine-parsable (text!) format
> then udd will adapt its importer.

As you know, both of these already happened several months ago. I have
not commented here because I am still chewing on a related, but much
harder problem:

Lintian will soon cease to run blindly across the archive and instead
produce packaging hints on demand, as uploads are received by the
archive. There is no batch process anymore that will produce files for
the entire archive the way you expect. Instead, Lintian's new website
https://lintian.debian.*net* offers a JSON interface [1] to get up to
date information similar to DAKweb. [2] The Node.js maintainers
already use it.

Retitling to better reflect the problem at hand. Ideas are welcome.

Kind regards
Felix Lechner

[1] https://lintian.debian.net/query
[2] https://ftp-team.pages.debian.net/dak/epydoc/dakweb-module.html

Bug#986754: unblock: please unblock gcc-9-cross and gcc-9-cross-ports

2021-04-11 Thread Paul Gevers

Hi

On 11-04-2021 14:38, Matthias Klose wrote:
> please unblock gcc-9-cross and gcc-9-cross-ports, no-change rebuilds using the
> gcc-9 version as found in bullseye.

unblocked.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#581960: tex4ht: wrong charset in htlatex output

2021-04-11 Thread Hilmar Preuße


Am 17.05.2010 um 13:54 teilte jsb...@mimuw.edu.pl mit:

Dear Janusz,

Yes, we have long response times. Sorry for this!


Package: tex4ht
Version: 20090611-1+b2
Severity: normal
File: /usr/bin/htlatex

Please have a look at the attached example.

This is a regression, it work correctly several years ago...


I got a response from upstream. They said:

Yes, the encoding should be "utf-8" as he requires "uni-html4" option. 
Note that this happens only with old scripts like htlatex, as make4ht 
uses utf-8 by default.


Anyway, I've updated the sources to better support the `uni-html4` 
option. The other option, that worked always is to use the 
"charset=utf-8" option:


--
htlatex minimal_example_squeeze.tex "xhtml,charset=utf-8" " -utf8 -cunihtf"


Upstream anyway recommends to use make4ht, like this: make4ht -u 
minimal_example_squeeze.tex


Does that solve your issue?

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#986592: closed by Debian FTP Masters (reply to u...@debian.org (Aaron M. Ucko)) (Bug#986592: fixed in kaptive 0.7.3-2)

2021-04-11 Thread Paul Gevers

Control: reopen -1

On 10-04-2021 00:21, Debian Bug Tracking System wrote:
> which was filed against the kaptive package:
> 
> #986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current 
> thread

I scheduled 20 runs of kleborate in unstable on arm64 [1]. Most of them
failed.

Paul

[1] https://ci.debian.net/packages/k/kleborate/unstable/arm64/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986764: libncurses-dev: coinstalling fails on /usr/bin/ncurses6-config for release arch vs {avr32,hppa,ia64}

2021-04-11 Thread Sven Joachim

Am 11.04.2021 um 19:48 schrieb Helmut Grohne:

> Package: libncurses-dev
> Version: 6.2+20201114-2
> File: /usr/bin/ncurses6-config
> User: helm...@debian.org
> Usertags: rebootstrap
>
> Coinstalling libncurses-dev has another issue besides #720033. There is
> another file conflict on /usr/bin/ncurses6-config. It results from
> embedding LDFLAGS. For all release architectures, those are set up as
> -Wl,-z,relro and due to hardening also -Wl,-z,now. Some architectures
> such as avr32, hppa and ia64 do not implement them and thus the LDFLAGS
> differ. Since they get embedded in /usr/bin/ncurses6-config, we get a
> file conflict.
>
> Looking closer, these flags are actively filtered in ncurses6-config
> such that they do not pose any behavioural difference.

That is a result of me complaining about these flags when they were
introduced, see
https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00037.html.

> So actually fixing this would be possible by fixing the generated
> /usr/bin/ncurses6-config to not contain them. The filtering can either
> happen inside the configure script or applied post build in a
> Debian-specific fixup.

Another option might be to patch misc/ncurses-config.in and remove
@LDFLAGS@ there.

Cheers,
   Sven

Bug#986764: libncurses-dev: coinstalling fails on /usr/bin/ncurses6-config for release arch vs {avr32,hppa,ia64}

2021-04-11 Thread Thomas Dickey

On Sun, Apr 11, 2021 at 07:48:06PM +0200, Helmut Grohne wrote:
> Package: libncurses-dev
> Version: 6.2+20201114-2
> File: /usr/bin/ncurses6-config
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> Coinstalling libncurses-dev has another issue besides #720033. There is
> another file conflict on /usr/bin/ncurses6-config. It results from
> embedding LDFLAGS. For all release architectures, those are set up as
> -Wl,-z,relro and due to hardening also -Wl,-z,now. Some architectures
> such as avr32, hppa and ia64 do not implement them and thus the LDFLAGS
> differ. Since they get embedded in /usr/bin/ncurses6-config, we get a
> file conflict.

yes... it would be nice if the cross-compiling packages would install
using a tool-prefix for these special cases (as the cross-compiling
tools do themselves).

Actually I do that for myself.  Here's what I have (Debian 10) in /usr/bin:

/usr/bin/i686-w64-mingw32-ncursesw6-config   <-- mine
/usr/bin/ncurses5-config
/usr/bin/ncurses6-config
/usr/bin/ncursestw6dev-config<-- mine
/usr/bin/ncursesw5-config
/usr/bin/ncursesw6-config
/usr/bin/ncursesw6dev-config <-- mine
/usr/bin/x86_64-w64-mingw32-ncursesw6-config <-- mine

(I'm able to build my test-packages for ncurses-examples with those pc files)
 
> Looking closer, these flags are actively filtered in ncurses6-config
> such that they do not pose any behavioural difference. So actually
> fixing this would be possible by fixing the generated
> /usr/bin/ncurses6-config to not contain them. The filtering can either
> happen inside the configure script or applied post build in a
> Debian-specific fixup.
> 
> In any case, I think that embedding the buildflags like this is a bad
> idea and worth reporting. They've always been architecture-dependent and
> it is not entirely unlikely that it'll hunt us at a later time for a
> release architecture.
> 
> Helmut
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#986766: unblock: openbox/3.6.1-9+deb11u1

2021-04-11 Thread Mateusz Łukasik


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

Please unblock package openbox

[ Reason ]
This changes fixed infinite loop when openbox is running with > 2 screens

[ Impact ]
Same as above.

[ Tests ]
No tests affected.

[ Risks ]
Zero risks. Patch fixed multi monitor configuration.


diff -Nru openbox-3.6.1/debian/changelog openbox-3.6.1/debian/changelog
--- openbox-3.6.1/debian/changelog  2020-03-17 18:22:37.0 +0100
+++ openbox-3.6.1/debian/changelog  2021-03-18 22:11:13.0 +0100
@@ -1,3 +1,11 @@
+openbox (3.6.1-9+deb11u1) unstable; urgency=medium
+
+  [ dann frazier ]
+  * When running with > 2 screens, avoid calling XQueryPointer() in an
+infinite loop. (Closes: #983882)
+
+ -- Mateusz Łukasik   Thu, 18 Mar 2021 22:11:13 +0100
+
 openbox (3.6.1-9) unstable; urgency=medium
 
   * Switch to python3. (Closes: #887122 #886716) (LP: #1816473)
diff -Nru 
openbox-3.6.1/debian/patches/Fix-collision-between-iterator-and-throw-away-argume.patch
 
openbox-3.6.1/debian/patches/Fix-collision-between-iterator-and-throw-away-argume.patch
--- 
openbox-3.6.1/debian/patches/Fix-collision-between-iterator-and-throw-away-argume.patch
 1970-01-01 01:00:00.0 +0100
+++ 
openbox-3.6.1/debian/patches/Fix-collision-between-iterator-and-throw-away-argume.patch
 2021-03-18 22:10:53.0 +0100
@@ -0,0 +1,38 @@
+From: Alex Goins 
+Date: Thu, 18 Feb 2021 21:25:22 -0600
+Subject: [PATCH] Fix collision between iterator and throw-away argument to
+ XQueryPointer()
+
+Without this, Openbox is unstable on any setup with more than 2 X screens, as
+the collision can make the loop infinitely call XQueryPointer() on X screen 1.
+
+Bug-Debian: https://bugs.debian.org/983882
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1917516
+Origin: 
https://github.com/AlexGoinsNV/openbox-multiXscreen-bugfix/commit/2635c87d160aa5f6f9e91e290678e99111788d57
+Last-Updated: 2021-03-02
+
+Index: openbox-debian/openbox/screen.c
+===
+--- openbox-debian.orig/openbox/screen.c
 openbox-debian/openbox/screen.c
+@@ -1908,16 +1908,16 @@ guint screen_monitor_pointer()
+ gboolean screen_pointer_pos(gint *x, gint *y)
+ {
+ Window w;
+-gint i;
++gint i, scrnindex;
+ guint u;
+ gboolean ret;
+ 
+ ret = !!XQueryPointer(obt_display, obt_root(ob_screen),
+   , , x, y, , , );
+ if (!ret) {
+-for (i = 0; i < ScreenCount(obt_display); ++i)
+-if (i != ob_screen)
+-if (XQueryPointer(obt_display, obt_root(i),
++for (scrnindex = 0; scrnindex < ScreenCount(obt_display); ++scrnindex)
++if (scrnindex != ob_screen)
++if (XQueryPointer(obt_display, obt_root(scrnindex),
+   , , x, y, , , ))
+ break;
+ }
diff -Nru openbox-3.6.1/debian/patches/series 
openbox-3.6.1/debian/patches/series
--- openbox-3.6.1/debian/patches/series 2020-03-15 17:26:18.0 +0100
+++ openbox-3.6.1/debian/patches/series 2021-03-18 22:11:00.0 +0100
@@ -22,3 +22,4 @@
 887908.patch
 917204_undecorated_maximized_no_border.patch
 python3.patch
+Fix-collision-between-iterator-and-throw-away-argume.patch

Bug#969171: Again, not even looked at the real problem.

2021-04-11 Thread Eric Valette




I think it is not a bug of the package. But it is definitely not severity 
grave as Akonadi is perfectly usable here in exact the same version 
(usable to the extent Akonadi works reliable, but that is an upstream 
issue). So downgrading severity to normal.


When only akonadi-backend-sqlite is installed as you can see in 
installed packages I find normal that the default config file is changed 
to use sqlite by default as I would expect that removing 
akonadi-backend-mysql would remove the mysql backend if it was used with 
a warning.


But apparently, you are more interested in having the package without 
bug than working to simplify your user's life.



-- eric

Bug#986765: AMD SEV guest crash after "Loading initial ramdisk ..."

2021-04-11 Thread Ján Máté

Package: qemu-system-x86
Version: 1:5.2+dfsg-9

When I try to boot an AMD SEV enabled guest OS it crashes immediately after the 
"Loading initial ramdisk ..." message (the result is infinite reboot loop). 
Here is my libvirt XML which works fine without the 
"..." XML element (which enables the AMD 
SEV):


  test
  4dea22b3-1d52-d8f3-2516-782e98ab3fa0
  ab826c0a-a349-4470-bbb9-d2b6ee23e8c3
  Test Server
  8388608
  8388608
  
9437184
  
  

  






  
  4
  1
  
hvm

/var/lib/libvirt/qemu/nvram/test_VARS.fd



  
  






  
  
  



  
  



  
  

  
  destroy
  restart
  coredump-restart
  restart
  
/usr/bin/kvm

  
  
  
  
  
  


  
  
  
  


  
  
  
  
  


  
  


  
  


  


  
  
  
  


  
  
  
  


  
  
  
  


  
  
  
  


  
  
  
  


  
  
  
  


  
  
  
  


  
  


  
  
  
  
  

  
  
  
  


  

  


  


  
  


  


  


  


  
  



  /dev/random
  
  

  
  
47
1
0x0033
  


kvm command line arguments (from the XML above):
/usr/bin/kvm -name guest=test,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-12-test/master-key.aes
 -blockdev 
{"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE_4M.ms.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}
 -blockdev 
{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}
 -blockdev 
{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/test_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}
 -blockdev 
{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}
 -machine 
pc-q35-5.2,accel=kvm,usb=off,smm=on,dump-guest-core=off,kernel_irqchip=on,memory-encryption=sev0,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,memory-backend=pc.ram
 -cpu 
host,migratable=off,topoext=on,kvmclock=on,kvm-pv-unhalt=on,kvm-hint-dedicated=on,kvm-poll-control=on,host-cache-info=on,l3-cache=off
 -global driver=cfi.pflash01,property=secure,value=on -m 8192 -object 
memory-backend-memfd,id=pc.ram,hugetlb=yes,hugetlbsize=2097152,share=yes,prealloc=yes,size=8589934592
 -overcommit mem-lock=on -smp 4,sockets=1,dies=1,cores=2,threads=2 -object 
iothread,id=iothread1 -uuid 4dea22b3-1d52-d8f3-2516-782e98ab3fa0 -device 
vmgenid,guid=ab826c0a-a349-4470-bbb9-d2b6ee23e8c3,id=vmgenid0 -no-user-config 
-nodefaults -device sga -chardev socket,id=charmonitor,fd=33,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot 
menu=on,splash-time=5000,strict=on -device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1
 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6 
-device qemu-xhci,id=usb,bus=pci.2,addr=0x0 -device 
virtio-serial-pci,id=virtio-serial0,iommu_platform=on,bus=pci.6,addr=0x0 
-blockdev 
{"driver":"file","filename":"/home/data/debian.iso","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}
 -blockdev 
{"node-name":"libvirt-3-format","read-only":true,"driver":"raw","file":"libvirt-3-storage"}
 -device ide-cd,bus=ide.0,drive=libvirt-3-format,id=sata0-0-0,bootindex=2 
-blockdev 
{"driver":"host_device","filename":"/dev/vg_storage/lv_test-swap","aio":"native","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}
 -blockdev 
{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}
 -device 
virtio-blk-pci-non-transitional,iothread=iothread1,iommu_platform=on,bus=pci.3,addr=0x0,drive=libvirt-2-format,id=virtio-disk0,write-cache=on
 -blockdev 
{"driver":"host_device","filename":"/dev/vg_storage/lv_test-root","aio":"native","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}
 -blockdev

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

2021-04-11 Thread Ivo De Decker


Hi Simon,

There is a theoretical and a practical aspect to this issue. From a 
theoretical point of view, the dependency relations should not be 
stricter than necessary, to allow partial upgrades and to avoid 
complicating migration to testing of library transitions.


On 4/11/21 12:37 PM, Simon McVittie wrote:

A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
have an elegant way to handle this automatically at build time to make sure
the dependencies are correct, without having to add them manually.


Should libpoppler102 get a Breaks: libpoppler-glib8 (<< 20.08.0-1~), where
that version was the first one to have the libpoppler102 SONAME? That
would ensure that the bad partial upgrade you describe can't happen,
because if a dependent package uses libpoppler102 ABI directly, and
also uses libpoppler indirectly via libpoppler-glib8, then it's the
same libpoppler.


The issue only happens if the same package depends on both libpoppler 
and libpoppler-glib, so forcing libpoppler and libpoppler-glib to be 
upgraded at the same time, is more strict than is theoretically needed. 
Also, I wonder if this would still allow the reverse issue to happen:


If an old inkscape is linked against the old libpoppler-glib8 and 
libpoppler95, installing libpoppler102 would force libpoppler-glib8 to 
be upgraded, and the old inkscape would link against the old libpoppler 
and the new libpoppler-glib, causing the same issue (I didn't test if 
this happens in practice).



Or, would this work?

* in src:poppler libpoppler-glib8.symbols.in, bump the version on every
   symbol to at least 20.08.0-1~ (the version that had the most recent
   SONAME bump) and upload to unstable


This would cause every package that links against libpoppler-glib8, but 
not (directly) against libpoppler to depend on the newer version of 
libpoppler-glib8, even if that's not necessary. In practice, this would 
severely reduce the usefulness of using the symbols file. And make 
partial upgrades (for users) and smooth updates (for library transitions 
to testing) much harder.



* binNMU the dependent packages elpa-pdf-tools-server, gambas3-gb-poppler
   and inkscape

That way, the binNMU'd versions of the dependent packages would have:

 Depends: libpoppler-glib8 (>= 20.08.0-1~), libpoppler102 (>= x)

and the bad partial upgrade you describe could not happen, because the
dependent package (inkscape in your example) would pull in the new
libpoppler-glib8 in addition to the new libpoppler102.


It would create the desired dependency, but I'm not sure if this is 
better than just manually adding it to the 2 remaining packages we are 
aware of (especially at this stage of the freeze).



For completeness, maybe it would make sense to give libpoppler-cpp0v5 and
libpoppler-qt5-1 the same treatment as libpoppler-glib8 (whatever that is),
since they could suffer from the same bug if an application calls into
libpoppler both directly and via libpoppler-cpp0v5 or libpoppler-qt5-1 -
although I don't know whether that happens in practice.


Well, I suspect there are actually quite a lot of these issue a our 
packages, but that many of them are not usually detected. Doing partial 
upgrades might result in binaries being (transitively) linked to 
different (incompatible) version of the same library. Even when that 
happens, it's not always immediately obvious. In the inkscape example, 
the issue only shows up when you try to open a pdf, not when you just 
start the program. So the fact that the programs runs successfully in 
some cases, doesn't guarantee that the issue isn't present.


This issue reminds me of https://bugs.debian.org/962320, which is 
somewhat similar, because multiple versions of the same boost library 
are linked into the same binary. In that case, this was detected because 
some of the packages weren't rebuilt yet, but I suspect it might be 
possible to trigger a similar issue by doing a partial upgrade of a 
package that (transitively) pulls in a number of boost libraries.


This brings me to the practical aspect of this issue: we try to support 
partial upgrades, and generate the correct dependency relation to make 
sure that unsupported combinations of packages can't be installed at the 
same time. However, we currently don't have a way to generate these 
dependencies when multiple interdependent libraries are involved. I'm 
unsure how we could handle this in general, but it certainly would be 
nice to have a way to do so. For now, though (and especially for 
bullseye), I think we should accept that we aren't going to solve this 
issue in general. The best we can do, is to try to fix obvious cases 
where we are aware of the issue. In other cases, we'll probably need to 
advise our users to do a full upgrade instead of a partial one.


Cheers,

Ivo

Bug#986764: libncurses-dev: coinstalling fails on /usr/bin/ncurses6-config for release arch vs {avr32,hppa,ia64}

2021-04-11 Thread Helmut Grohne

Package: libncurses-dev
Version: 6.2+20201114-2
File: /usr/bin/ncurses6-config
User: helm...@debian.org
Usertags: rebootstrap

Coinstalling libncurses-dev has another issue besides #720033. There is
another file conflict on /usr/bin/ncurses6-config. It results from
embedding LDFLAGS. For all release architectures, those are set up as
-Wl,-z,relro and due to hardening also -Wl,-z,now. Some architectures
such as avr32, hppa and ia64 do not implement them and thus the LDFLAGS
differ. Since they get embedded in /usr/bin/ncurses6-config, we get a
file conflict.

Looking closer, these flags are actively filtered in ncurses6-config
such that they do not pose any behavioural difference. So actually
fixing this would be possible by fixing the generated
/usr/bin/ncurses6-config to not contain them. The filtering can either
happen inside the configure script or applied post build in a
Debian-specific fixup.

In any case, I think that embedding the buildflags like this is a bad
idea and worth reporting. They've always been architecture-dependent and
it is not entirely unlikely that it'll hunt us at a later time for a
release architecture.

Helmut

Bug#986763: libfm-qt8: Terminal applications are not openend with the default terminal

2021-04-11 Thread Sébastien Dailly

Package: libfm-qt8
Version: 0.16.0-3
Severity: normal
X-Debbugs-Cc: 2021bohha...@dailly.me

Dear Maintainer,

I'm using the debian vershion of libfm-qt (libfm-qt8_0.16.0-3) and I have the
same issue than [https://github.com/lxqt/libfm-qt/issues/309] when I'm opening
a file with a terminal application inside pcmanfm-qt, it uses the glib backend
instead of the default terminal.

here is an extract from the `strace pcmanfm-qt` when I try to open a text/plain
document :

```
access("/usr/bin/gnome-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/bin/gnome-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/games/gnome-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/bin/mate-terminal", X_OK)  = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/bin/mate-terminal", X_OK)  = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/games/mate-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/bin/xfce4-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/bin/xfce4-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/games/xfce4-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/bin/nxterm", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/bin/nxterm", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/games/nxterm", X_OK)   = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/bin/color-xterm", X_OK)= -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/bin/color-xterm", X_OK)= -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/games/color-xterm", X_OK)  = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/local/bin/rxvt", X_OK) = -1 ENOENT (Aucun fichier ou dossier
de ce type)
access("/usr/bin/rxvt", X_OK)   = 0
```

The terminal list is taken from the glib library, so it seems that the issue
above is not completely corrected. rxvt is used here because it is the first
application installed in the list, but if install xfce4-terminal, this
applicaton is used instead.

The xdg-association is a standard vim configuration (untouched from the default
debian configuration)

$ xdg-mime query default text/plain
vim.desktop


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

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

Versions of packages libfm-qt8 depends on:
ii  libc6 2.31-9
ii  libexif12 0.6.21-5.1+deb10u5
ii  libglib2.0-0  2.64.4-1
ii  libglib2.0-bin2.64.4-1
ii  libmenu-cache31.1.0-1
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-3
ii  libqt5gui55.15.2+dfsg-3
ii  libqt5widgets55.15.2+dfsg-3
ii  libqt5x11extras5  5.14.2-2
ii  libstdc++610.2.1-6
ii  libxcb1   1.13.1-2
ii  shared-mime-info  1.10-1

Versions of packages libfm-qt8 recommends:
ii  libfm-qt-l10n  0.14.1-9

libfm-qt8 suggests no packages.

Bug#968257: no finding; requesting more submitter details per release-notes: UpgradingToBuster: apt doesn't report how much space

2021-04-11 Thread Paul Gevers

Hi Federico,

Thanks for your feedback, much appreciation for your (promised) work on
the release notes.

On 11-04-2021 18:46, Federico Grau wrote:
> Alternately, I recommend this bug be closed as not applicable to current
> Debian.

This bug is already marked as "buster", so it's not applicable to the
current testing. However, if we find issues with the buster release that
warrant a notes in the notes, we still update the release notes. If
nothing happens, i.e. the submitter and nobody else provide more info,
this bug can be closed once buster goes EOL.

Paul

OpenPGP_signature
Description: OpenPGP digital signature

Bug#986762: firefox-esr: mishandles combining characters in textarea

2021-04-11 Thread Thorsten Glaser

Package: firefox-esr
Version: 78.9.0esr-1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de

籠⃠ is misrendered in s (one after another, the second
glyph is not composed on top of the first one as UCS requires),
but it is handled right-ish in input fields, etc.


-- Package-specific info:

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

Name: Autoplay Settings for YouTube
Location: ${PROFILE_EXTENSIONS}/{14e605a0-6fdd-43e9-891a-29f6e481db24}.xpi
Status: enabled

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

Name: Classic Theme Restorer
Location: ${PROFILE_EXTENSIONS}/classicthemeresto...@arist2noia4dev.xpi
Status: app-disabled

Name: Clear Search 2
Location: ${PROFILE_EXTENSIONS}/clearsear...@extension-id.invalid.xpi
Status: app-disabled

Name: Crowdbar
Location: ${PROFILE_EXTENSIONS}/jid1-xgbyhwcvipe...@jetpack.xpi
Status: enabled

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

Name: Dark Reader
Location: ${PROFILE_EXTENSIONS}/ad...@darkreader.org.xpi
Status: enabled

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

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 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: HTTPS Everywhere
Location: /usr/share/webext/https-everywhere
Package: webext-https-everywhere
Status: user-disabled

Name: Image Max URL
Location: ${PROFILE_EXTENSIONS}/max...@qsniyg.xpi
Status: enabled

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

Name: Never-Consent
Location: ${PROFILE_EXTENSIONS}/{816c90e6-757f-4453-a84f-362ff989f3e2}.xpi
Status: enabled

Name: Offline QR Code Generator
Location: ${PROFILE_EXTENSIONS}/offline-qr-c...@rugk.github.io.xpi
Status: enabled

Name: Old Image Style
Location: ${PROFILE_EXTENSIONS}/{dfac41f2-b87d-4759-8825-a8bfd4cce744}.xpi
Status: enabled

Name: SoundFixer
Location: ${PROFILE_EXTENSIONS}/soundfi...@unrelenting.technology.xpi
Status: enabled

Name: Tampermonkey
Location: ${PROFILE_EXTENSIONS}/fire...@tampermonkey.net.xpi
Status: enabled

Name: Twitter View Original Images
Location: ${PROFILE_EXTENSIONS}/{0e05c778-ab7d-45a5-98d0-ed365ac4653b}.xpi
Status: user-disabled

Name: User-Agent Switcher and Manager
Location: ${PROFILE_EXTENSIONS}/{a6c4a591-f1b2-4f03-b3ff-767e5bedf4e7}.xpi
Status: enabled

Name: Wayback Machine
Location: ${PROFILE_EXTENSIONS}/wayback_mach...@mozilla.org.xpi
Status: enabled

Name: Web Compat
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

Name: YouTube Ad Auto-skipper
Location: ${PROFILE_EXTENSIONS}/{bd6b8f4a-b0c3-4d61-a0f8-5539d3df3959}.xpi
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox-esr 78.9.0esr-1  amd64Mozilla Firefox web 
browser - Extended Support Release (ESR)
ii  webext-https-everywhere 2021.1.27-1  all  Extension to force the 
use of HTTPS on many sites

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

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-11
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  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0

Bug#986761: openssh fails to start when using ListenAddress and systemd-network

2021-04-11 Thread Daniel Baumann

Package: openssh
Severity: normal
Version: 1:8.4p1-5

Hi,

on systems with multiple interfaces, we tend to use 'ListenAddress' in
sshd_config to ensure that openssh only runs on the local management
interface.

now, with vanilla bullseye systems using ifupdown this works.

once switching to systemd-networkd, this fails. openssh logs the 'cannot
bind to address' error because the (statically configured) IP on the
interface is not up yet.

I guess systemd-networkd reports "network.target" to early that it
completed its stuff (when it has not).

once I remove the ListenAddress, everything works again as usual.

Regards,
Daniel

Bug#985292: materia-gtk-theme: unhandled symlink to directory conversion: /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets

2021-04-11 Thread Leandro Cunha

Hi,

On Sat, Apr 3, 2021 at 5:14 PM Andreas Beckmann  wrote:

> On 03/04/2021 07.43, Leandro Cunha wrote:
> > Can you test the version I pushed for Salsa and confirm that the problem
> > has been fixed?
> >
> > [1] https://salsa.debian.org/leandrocunha/materia-gtk-theme
>
> There is no releated change in git, only a changelog entry (I would have
> expected a .maintscript file to be added).
> But there is a revert of debian/rules to an older version (and from
> short debhelper 13 to something much older), which is probably unwanted
> and inappropriate at this point of the release cycle.
>
>
> Andreas
>

I made an update to the repository in Salsa based on the log made available.
Please confirm the correction with a log and this test that was done didn't
find
documentation of it to reproduce here. Thanks.

[1] https://salsa.debian.org/leandrocunha/materia-gtk-theme

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#968257: no finding; requesting more submitter details per release-notes: UpgradingToBuster: apt doesn't report how much space

2021-04-11 Thread Federico Grau

I had a chance to run through the upgrade process from Debian 10 'buster' to
Debian 11/testing 'bullseye' on a test VM this weekend.  My findings were
different, and `apt' produced equivalent space usage estimates to `apt-get'.  

Could the bug submitter provide more details per this issue, possibly with a
script log or console excerpt with the 5x sample commands.  
Alternately, I recommend this bug be closed as not applicable to current
Debian.

# suggested 5x console commands from bug submitter
a) apt -o APT::Get::Trivial-Only=true full-upgrade
b) apt-get -o APT::Get::Trivial-Only=true full-upgrade
c) cat /etc/debian_version 
d) hostnamectl 
e) dpkg -l apt

regards,
donfede



#
# console review of a Debian 10 to Debian 11 upgrade, with valid apt space 
estimates

root@saltdev12:~# apt -o APT::Get::Trivial-Only=true full-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
  ant-contrib bsdmainutils cpp-8 dns-root-data dnsmasq-base enchant
...
The following packages will be upgraded:
...
  xterm xxd xz-utils zenity zenity-common zip zlib1g
1211 upgraded, 174 newly installed, 17 to remove and 0 not upgraded.
Need to get 1,026 MB of archives.
After this operation, 1,168 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.
root@saltdev12:~# 
root@saltdev12:~# apt-get -o APT::Get::Trivial-Only=true full-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
  ant-contrib bsdmainutils cpp-8 dns-root-data dnsmasq-base enchant
...
  xterm xxd xz-utils zenity zenity-common zip zlib1g
1211 upgraded, 174 newly installed, 17 to remove and 0 not upgraded.
Need to get 1,026 MB of archives.
After this operation, 1,168 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.
root@saltdev12:~# 
root@saltdev12:~# cat /etc/debian_version 
10.9
root@saltdev12:~# hostnamectl 
   Static hostname: saltdev12
 Icon name: computer-vm
   Chassis: vm
Machine ID: 7dbeb15ee7f3422880510406f4f3e69f
   Boot ID: 200e18ca7f004054827ced4cc0902a1b
Virtualization: kvm
  Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-16-amd64
  Architecture: x86-64
root@saltdev12:~# 
root@saltdev12:~# which apt
/usr/bin/apt
root@saltdev12:~# which apt-get
/usr/bin/apt-get
root@saltdev12:~# dpkg -S /usr/bin/apt
apt: /usr/bin/apt
root@saltdev12:~# dpkg -S /usr/bin/apt-get
apt: /usr/bin/apt-get
root@saltdev12:~# dpkg -l apt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  apt1.8.2.2  amd64commandline package manager
root@saltdev12:~# 




signature.asc
Description: PGP signature

Bug#986760: unblock: seahorse/3.38.0.1-2

2021-04-11 Thread Simon McVittie

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

Please unblock package seahorse.

[ Reason ]
Fix key import dialog to wait for the key to be imported, rather than
cancelling the action before it starts.
(#931558, Severity: important in my opinion)

[ Impact ]
If not fixed, GNOME users cannot import GPG keys via a GUI and must use
the command-line.

[ Tests ]
Manual test:
- Obtained a public key that was not in my keyring and attempted to
  import it with 3.38.0.1-1, confirmed failure (dialog closes immediately,
  new key not present when asking the gpg CLI).
- Upgraded to 3.38.0.1-2, re-imported the key, confirmed success (a
  spinner appears in the Import button for a while before the dialog
  closes, new key is visible to the gpg CLI afterwards).

[ Risks ]
Minimal risk. It's a targeted fix to a UI element that previously
didn't work at all, so even a partial or imperfect solution would be
an improvement.

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

[ Other info ]
If this cannot migrate in time for Debian 11.0, then I think a stable
update in 11.1 would be appropriate.

unblock seahorse/3.38.0.1-2
diffstat for seahorse-3.38.0.1 seahorse-3.38.0.1

 changelog|9 
 gbp.conf |2 -
 patches/ImportDialog-Fix-import-dialog.patch |   29 +++
 patches/series   |2 -
 4 files changed, 40 insertions(+), 2 deletions(-)

diff -Nru seahorse-3.38.0.1/debian/changelog seahorse-3.38.0.1/debian/changelog
--- seahorse-3.38.0.1/debian/changelog	2020-12-12 08:56:34.0 +
+++ seahorse-3.38.0.1/debian/changelog	2021-04-11 17:28:09.0 +0100
@@ -1,3 +1,12 @@
+seahorse (3.38.0.1-2) unstable; urgency=medium
+
+  * Team upload
+  * d/p/ImportDialog-Fix-import-dialog.patch:
+Apply patch from upstream to fix GPG key import (Closes: #931558)
+  * d/gbp.conf: Switch branch to debian/bullseye
+
+ -- Simon McVittie   Sun, 11 Apr 2021 17:28:09 +0100
+
 seahorse (3.38.0.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru seahorse-3.38.0.1/debian/gbp.conf seahorse-3.38.0.1/debian/gbp.conf
--- seahorse-3.38.0.1/debian/gbp.conf	2020-12-12 08:56:34.0 +
+++ seahorse-3.38.0.1/debian/gbp.conf	2021-04-11 17:28:09.0 +0100
@@ -1,6 +1,6 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
+debian-branch = debian/bullseye
 upstream-branch = upstream/latest
 
 [buildpackage]
diff -Nru seahorse-3.38.0.1/debian/patches/ImportDialog-Fix-import-dialog.patch seahorse-3.38.0.1/debian/patches/ImportDialog-Fix-import-dialog.patch
--- seahorse-3.38.0.1/debian/patches/ImportDialog-Fix-import-dialog.patch	1970-01-01 01:00:00.0 +0100
+++ seahorse-3.38.0.1/debian/patches/ImportDialog-Fix-import-dialog.patch	2021-04-11 17:28:09.0 +0100
@@ -0,0 +1,29 @@
+From: Jeremias Ortega 
+Date: Mon, 9 Nov 2020 22:39:01 -0600
+Subject: ImportDialog: Fix import dialog
+
+The import dialog fails to import files without showing any warning.
+The dialog closes before it finishes the import process and cancels it.
+
+This is solved by making the import button not return a response directly.
+
+Bug: https://gitlab.gnome.org/GNOME/seahorse/-/issues/236
+Bug-Debian: https://bugs.debian.org/931558
+Origin: upstream, 40~alpha, commit:6cc0fe7381a4c9536123bf877b3e055774b2f0a9
+---
+ src/import-dialog.vala | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/import-dialog.vala b/src/import-dialog.vala
+index 983b7e4..650aaa2 100644
+--- a/src/import-dialog.vala
 b/src/import-dialog.vala
+@@ -41,7 +41,7 @@ public class Seahorse.ImportDialog : Gtk.Dialog {
+ this.import.get_style_context().add_class("suggested-action");
+ this.import.importing.connect(() => this.viewer.clear_error());
+ this.import.imported.connect(on_import_button_imported);
+-add_action_widget(this.import, Gtk.ResponseType.OK);
++((Gtk.HeaderBar) get_header_bar()).pack_end(this.import);
+ 
+ this.viewer = new Gcr.ViewerWidget();
+ this.viewer.added.connect((v, r, parsed) => this.import.add_parsed(parsed));
diff -Nru seahorse-3.38.0.1/debian/patches/series seahorse-3.38.0.1/debian/patches/series
--- seahorse-3.38.0.1/debian/patches/series	2020-12-12 08:56:34.0 +
+++ seahorse-3.38.0.1/debian/patches/series	2021-04-11 17:28:09.0 +0100
@@ -1 +1 @@
-
+ImportDialog-Fix-import-dialog.patch

Bug#986759: libpam-otpw: pam_otpw.so is installed in /lib/security/, but should be in /lib/x86_64-linux-gnu/security/

2021-04-11 Thread Andreas B. Mundt

Package: libpam-otpw
Version: 1.5-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: a...@debian.org

Dear Maintainer,

after trying to set up libpam-otpw on bullseye, it did not work 
and the line:

  PAM unable to dlopen(pam_otpw.so): 
/lib/x86_64-linux-gnu/security/pam_otpw.so: 
cannot open shared object file: No such file or directory

showed up in the journal.

Copying pam_otpw.so from /lib/security/pam_otpw.so to 
/lib/x86_64-linux-gnu/security/
fixed the problem.  It looks like pam_otpw.so is installed in an
outdated location.

Thanks and best regards,

  Andi

Bug#960593: hplip: Requires login as root instead of as user

2021-04-11 Thread Brendon Higgins

On Mon, 22 Mar 2021 17:01:06 +0200 Teemu Ikonen  wrote:
> Note that this bug can be mitigated by adding the two lines below to 
> ~/.hplip/hplip.conf:
> 
> -*-
> [authentication]
> su_sudo=sudo
> -*-

Good tip, thanks for that. Evidently it only works on a per-user basis - i.e., 
adding those lines to /etc/hp/hplip.conf does nothing - which isn't perfect, 
but this is something.

For me, hplip insists on going through the plugin install process after each 
time apt installs an updated package, so this will make that recurring 
annoyance that much more tolerable.

Best,
Brendon

Bug#986758: unblock: systemd/247.3-4

2021-04-11 Thread Luca Boccassi

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org

Please unblock package systemd

As requested by Michael, opening unblock ticket. Debdiff attached. Two
high-impact patches are backported from upstream and should be included
in Bullseye.

* Backport patch to fix assert with invalid LoadCredentials=
  Regression introduced in v247, fixed in v249, see:
  https://github.com/systemd/systemd/issues/19178
  (Closes: #986302)

* network: Delay addition of IPv6 Proxy NDP addresses.
  Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
  networkd adds them". (Closes: #985510)

The first patch fixes a crash when a malformed option is set in any
unit.

unblock systemd/247.3-4

-- 
Kind regards,
Luca Boccassi
diff -Nru systemd-247.3/debian/changelog systemd-247.3/debian/changelog
--- systemd-247.3/debian/changelog	2021-03-11 17:09:35.0 +
+++ systemd-247.3/debian/changelog	2021-04-11 15:06:46.0 +0100
@@ -1,3 +1,18 @@
+systemd (247.3-4) unstable; urgency=medium
+
+  [ Luca Boccassi ]
+  * Backport patch to fix assert with invalid LoadCredentials=
+Regression introduced in v247, fixed in v249, see:
+https://github.com/systemd/systemd/issues/19178
+(Closes: #986302)
+
+  [ Michael Biebl ]
+  * network: Delay addition of IPv6 Proxy NDP addresses.
+Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
+networkd adds them". (Closes: #985510)
+
+ -- Michael Biebl   Sun, 11 Apr 2021 16:06:46 +0200
+
 systemd (247.3-3) unstable; urgency=medium
 
   * pkg-config: make prefix overridable again (Closes: #984763)
diff -Nru systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch
--- systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch	2021-03-11 17:09:35.0 +
+++ systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch	2021-04-11 15:06:46.0 +0100
@@ -16,7 +16,7 @@
  3 files changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
-index 4964249..2d48783 100644
+index 5b66fb1..df5669a 100644
 --- a/src/core/load-fragment.c
 +++ b/src/core/load-fragment.c
 @@ -372,6 +372,7 @@ static int patch_var_run(
diff -Nru systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
--- systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch	1970-01-01 01:00:00.0 +0100
+++ systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch	2021-04-11 15:06:46.0 +0100
@@ -0,0 +1,34 @@
+From: Luca Boccassi 
+Date: Thu, 1 Apr 2021 22:18:29 +0100
+Subject: LoadCredentials: do not assert on invalid syntax
+
+LoadCredentials=foo causes an assertion to be triggered, as we
+are not checking that the rvalue's right hand side part is non-empty
+before using it in unit_full_printf.
+
+Fixes #19178
+
+# printf [Service]nLoadCredential=passwd.hashed-password.rootn > hello.service
+# systemd-analyze verify ./hello.service
+...
+Assertion 'format' failed at src/core/unit-printf.c:232, function unit_full_printf(). Aborting.
+Aborted (core dumped)
+
+(cherry picked from commit f7a6f1226e800f7695c2073675523062ea697aa4)
+---
+ src/core/load-fragment.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
+index 4964249..5b66fb1 100644
+--- a/src/core/load-fragment.c
 b/src/core/load-fragment.c
+@@ -4569,7 +4569,7 @@ int config_parse_load_credential(
+ r = extract_first_word(, , ":", EXTRACT_DONT_COALESCE_SEPARATORS);
+ if (r == -ENOMEM)
+ return log_oom();
+-if (r <= 0) {
++if (r <= 0 || isempty(p)) {
+ log_syntax(unit, LOG_WARNING, filename, line, r, "Invalid syntax, ignoring: %s", rvalue);
+ return 0;
+ }
diff -Nru systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch
--- systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch	1970-01-01 01:00:00.0 +0100
+++ systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch	2021-04-11 15:06:46.0 +0100
@@ -0,0 +1,86 @@
+From: "Kevin P. Fleming" 
+Date: Sat, 6 Feb 2021 10:58:43 -0500
+Subject: network: Delay addition of IPv6 Proxy NDP addresses
+
+Setting of IPv6 Proxy NDP addresses must be done at the same
+time as static addresses, static routes, and other link attributes
+that must be configured when the link is up. Doing this ensures
+that they are reconfigured on the link if the link goes down

Bug#985989: nextcloud-desktop: segmentation fault when trying to open settings

2021-04-11 Thread Bernhard Übelacker


Hello till,
I tried to reproduce this inside a minimal VM,
but the crash did not show for me.

Maybe you could provide some more details, e.g.
by installing systemd-coredump and inspecting the
journal after a crash happened and adding the lines
of the crash time to this bug.
Please see more details in [1].

Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace

Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2

2021-04-11 Thread Nicholas D Steeves

Attention LXC Team: Does a functioning /sys always exist in an LXC
container, or is it absent/disabled in some configurations?

Hi Arnaud,

Reply follows inline.

Arnaud Rebillout  writes:

> Package: debootstrap
> Version: 1.0.123
> Severity: normal
> Tags: patch
> User: de...@kali.org
> Usertags: origin-kali
>
> Dear Maintainer,
>
> The code that is meant to detect if debootstrap is running from within a
> docker container is broken with cgroup v2. Talking about this particular
> function and line in the file `functions`:
>

I agree that Bullseye should have working LXC with cgroups v2, since (as
far as I know) we have new enough packages from upstream to support
it :-)  Thank you for your interest and motivation to fix this!

> detect_container () {
> [...]
> elif grep -qs '[[:space:]]/docker/.*/sys/fs/cgroup' 
> /proc/1/mountinfo; then
> CONTAINER="docker"
>
> This code only works for cgroup v1.
>
> After some research, and also after looking into the code of
> systemd-detect-virt, it seems that the right way to detect a docker
> container these days is to check for the file '/.dockerenv'.
>
> Hence I'm proposing this patch:
> https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/52
>

I'm not sure that systemd-detect-virt and your patch are
forward-compatible in light of

Originally, ".dockerenv" was for transmitting the environment
variables of the container across the container boundary -- I would
not recommend relying on its existence either (IIRC, that code
you've linked to is the only reason it still exists).  There's
likely something incriminatory inside /sys/fs/cgroup, but I haven't
checked recently.
https://github.com/moby/moby/issues/18355#issuecomment-220484748

This makes it sounds like ".dockerenv" may be deprecated and later
removed.  It seems reasonable to contact Debian's systemd maintainer[s]
about this probable future issue, because if checking for ".dockerenv"
is robust enough for Bullseye's systemd, then it might be robust enough
for debootstrap.  That said, I still wonder if this method could pose a
problem when using debootstrap, lxc, and docker from future
bullseye-backports, if ".dockerenv" support is removed sometime during
Bullseye's life-cycle.

Cgroup v2 is also mounted at /sys/fs/cgroup, so I wonder if the original
check should be rewritten to check for something under this path instead
of mountinfo?  Also, using this /sys/fs/cgroup method, I'm not sure if
it's better debootstrap style to express the OR logical operator in the
regex or a shell "||" (ie: seems to be needed because the tree under
/sys/fs/cgroup is different between v1 and v2).

Thanks again!
Regards,
Nicholas

signature.asc
Description: PGP signature

Bug#429060: seahorse-agent crashes when making a new ssh connection

2021-04-11 Thread Simon McVittie

Control: notforwarded -1
Control: tags -1 = moreinfo

On Fri, 15 Jun 2007 at 18:48:50 +0200, Stefan Schoenleitner wrote:
> I'm on unstable and after upgrading seahorse, the seahorse-agent crashes if a
> new ssh connection is made.
...
> A more detailed report can be found here:
> http://bugzilla.gnome.org/show_bug.cgi?id=447931

On Tue, 10 Jul 2007 at 23:36:21 +0100, Mark Brown wrote:
> I appear to be seeing this bug reproduced on every login.  During the
> login seahorse-agent will generally prompt me for the passphrase for my
> SSH key and then segfault with what appears to be a very similar
> backtrace.  This behaviour appeared within the past week.

Does this still happen? The upstream bug was closed as not having enough
information to investigate further.

The backtrace in the upstream bug didn't have debug symbols and involves a
call into libgnomeui, which doesn't exist in Debian any more, so I suspect
the code has changed a lot in the 13 years since the bug was reported and
this crash might well no longer exist.

smcv

Bug#818649: power.d scripts are not run at all

2021-04-11 Thread Demi

I'm not sure why this only hit me after upgrading to bullseye, but it
did.

For now, I've fixed it by adding two custom rules to udev (perhaps
dump them into 10_pm-utils-local.rules):

  ACTION=="change", SUBSYSTEM=="power_supply", ATTR{type}=="Mains",\
ATTR{online}=="1", RUN+="/usr/sbin/pm-powersave false"
  ACTION=="change", SUBSYSTEM=="power_supply", ATTR{type}=="Mains",\
ATTR{online}=="0", RUN+="/usr/sbin/pm-powersave true"

It clearly would be great if this could somehow be added to the
package, though of course I have no idea how this would interact with
upower or systemd.

It does co-operate nicely with tlp (wearing their upstream down do
allow custom hook scripts would be an attractive alternative, though).

Bug#944982: open-infrastructure-compute-tools: Script accesses internal dpkg database

2021-04-11 Thread Daniel Baumann

retitle 944982 uses dpkg file paths to check for packages
tag 944982 pending
thanks

fixed upstream, uploading after further tests in the next couple of days.

Regards,
Daniel

Bug#986622: ClamAV 0.103.2 security patch release

2021-04-11 Thread Damian Lukowski


> CVE-2021-1252 :
> Fix for Excel XLM parser infinite loop. Affects 0.103.0 and 0.103.1 only.

Debian's security tracker claims that stretch and buster are vulnerable. According to the clamav announcement and CVE they 
shouldn't be.


> CVE-2021-1405 :
> Fix for mail parser NULL-dereference crash. Affects 0.103.1 and prior.

The clamav announcement and CVE are inconsistent whether 0.102 is affected.

Bug#983114: libapparmor1: After upgrade is the system not bootable. Init is complaining about incorrect apparmor version.

2021-04-11 Thread Ďoďo

ok, so I did remove stretch update from the sources.
Then apt update, upgrade, reboot and crash again during the boot.

On Sun, Apr 11, 2021 at 3:32 PM Ďoďo  wrote:

> Hi, yes, I do agree the problem is in libc dependencies. Yes, I am using
> testing and I just did allow the apt to upgrade all the
> recommended packages. It resulted in not booting system.
>
> But after reading your email 2-3 times and then triple checking my
> apt.sources I noticed something there. This is my cleaned apt source:
> deb http://ftp.de.debian.org/debian/ stable main non-free contrib
> deb http://ftp.de.debian.org/debian/ testing main non-free contrib
> deb http://security.debian.org/debian-security stable/updates main
> contrib non-free
> deb http://ftp.de.debian.org/debian/ stretch-updates main contrib non-free
>
> Is it possible that the forgotten stretch-updates is the trouble maker?
> Otherwise I do not understand your comment about "running testing on
> stretch system".
> Thanks for your reply and sorry for very likely incorrect bug report
>
> Jozef
>
>
> On Fri, Apr 2, 2021 at 11:31 AM intrigeri  wrote:
>
>> Control: tag -1 + moreinfo
>>
>> Hi,
>>
>> Ivanecky Jozef (2021-02-19):
>> > Package: libapparmor1
>> > Version: 2.13.6-9
>>
>> > Debian Release: 9.8
>> >   APT prefers oldstable-updates
>> >   APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500,
>> 'stable')
>>
>> > Versions of packages libapparmor1 depends on:
>> > ii  libc6  2.31-9
>>
>> It looks like you've upgraded key packages (libapparmor1, libc6) to
>> the version from testing/sid on a Stretch system. Is this correct?
>>
>> This kind of setup is unsupported and I'm afraid there's little chance
>> it'll work. I suspect the problem here is about the libc6 upgrade,
>> rather than about AppArmor, by the way.
>>
>

Bug#986314: RFS: gsimplecal/2.1-2 [QA] -- lightweight GUI calendar application

2021-04-11 Thread Giovani Ferreira

Control: owner -1 !
Control: tags -1 + moreinfo

Hi Hugo,

On Tue, 06 Apr 2021 12:30:05 + Hugo Torres
 wrote:
> 
> Necessary for the creation of the Debian repository in Salsa.
> 
> I created the repository in my account to make the migration:
> https://salsa.debian.org/f9kill/gsimplecal
> 

I can create gsimplecal repo in the debian namespace after updating and
uploading.

Some things I'd like you to fix before the upload:

-d/docs: Missing a break line at the end of the file, please add this.

-d/rules: You don't need to specify '--with autoreconf' on d/rules
because it is default since the DH 10.

-d/tests/control: The autopkgtest is running a trivial command that does
not provide significant test coverage. Mark the trivial test with
"Restrictions: superficial"

Thanks,

-- 
Giovani Ferreira
0x78494EF72375A66C



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986746: systemd: Symbols are missing when building systemd by Clang

2021-04-11 Thread Michael Biebl

Fwiw, this problem is not specific to systemd. Other packages FTBFS with 
lld as well, e.g. network-manager. It appears to be the same issue.




--- debian/libnm0.symbols (libnm0_1.30.0-1_amd64)
+++ dpkg-gensymbolsbURsJa   2021-04-11 13:46:43.525365613 +
@@ -1,32 +1,32 @@
 libnm.so.0 libnm0 #MINVER#
 * Build-Depends-Package: libnm-dev
- libnm_1_0_0@libnm_1_0_0 1.0.0
- libnm_1_0_4@libnm_1_0_4 1.0.4
- libnm_1_0_6@libnm_1_0_6 1.0.6
- libnm_1_10_0@libnm_1_10_0 1.9.90
- libnm_1_10_14@libnm_1_10_14 1.14.4
- libnm_1_10_2@libnm_1_10_2 1.10.2
- libnm_1_12_0@libnm_1_12_0 1.11.3
- libnm_1_12_2@libnm_1_12_2 1.12.2
- libnm_1_14_0@libnm_1_14_0 1.13.90
- libnm_1_14_8@libnm_1_14_8 1.19.90
- libnm_1_16_0@libnm_1_16_0 1.16.0
- libnm_1_18_0@libnm_1_18_0 1.18.0
- libnm_1_20_0@libnm_1_20_0 1.19.90
- libnm_1_20_6@libnm_1_20_6 1.20.6
- libnm_1_22_0@libnm_1_22_0 1.22.0
- libnm_1_22_2@libnm_1_22_2 1.22.2
- libnm_1_22_8@libnm_1_22_8 1.22.8
- libnm_1_24_0@libnm_1_24_0 1.23.90
- libnm_1_26_0@libnm_1_26_0 1.25.90
- libnm_1_26_4@libnm_1_26_4 1.27.90
- libnm_1_28_0@libnm_1_28_0 1.27.90
- libnm_1_2_0@libnm_1_2_0 1.1.90
- libnm_1_2_4@libnm_1_2_4 1.2.4
- libnm_1_30_0@libnm_1_30_0 1.29.90
- libnm_1_4_0@libnm_1_4_0 1.4.0
- libnm_1_6_0@libnm_1_6_0 1.5.90
- libnm_1_8_0@libnm_1_8_0 1.8.0
+#MISSING: 1.30.0-1# libnm_1_0_0@libnm_1_0_0 1.0.0
+#MISSING: 1.30.0-1# libnm_1_0_4@libnm_1_0_4 1.0.4
+#MISSING: 1.30.0-1# libnm_1_0_6@libnm_1_0_6 1.0.6
+#MISSING: 1.30.0-1# libnm_1_10_0@libnm_1_10_0 1.9.90
+#MISSING: 1.30.0-1# libnm_1_10_14@libnm_1_10_14 1.14.4
+#MISSING: 1.30.0-1# libnm_1_10_2@libnm_1_10_2 1.10.2
+#MISSING: 1.30.0-1# libnm_1_12_0@libnm_1_12_0 1.11.3
+#MISSING: 1.30.0-1# libnm_1_12_2@libnm_1_12_2 1.12.2
+#MISSING: 1.30.0-1# libnm_1_14_0@libnm_1_14_0 1.13.90
+#MISSING: 1.30.0-1# libnm_1_14_8@libnm_1_14_8 1.19.90
+#MISSING: 1.30.0-1# libnm_1_16_0@libnm_1_16_0 1.16.0
+#MISSING: 1.30.0-1# libnm_1_18_0@libnm_1_18_0 1.18.0
+#MISSING: 1.30.0-1# libnm_1_20_0@libnm_1_20_0 1.19.90
+#MISSING: 1.30.0-1# libnm_1_20_6@libnm_1_20_6 1.20.6
+#MISSING: 1.30.0-1# libnm_1_22_0@libnm_1_22_0 1.22.0
+#MISSING: 1.30.0-1# libnm_1_22_2@libnm_1_22_2 1.22.2
+#MISSING: 1.30.0-1# libnm_1_22_8@libnm_1_22_8 1.22.8
+#MISSING: 1.30.0-1# libnm_1_24_0@libnm_1_24_0 1.23.90
+#MISSING: 1.30.0-1# libnm_1_26_0@libnm_1_26_0 1.25.90
+#MISSING: 1.30.0-1# libnm_1_26_4@libnm_1_26_4 1.27.90
+#MISSING: 1.30.0-1# libnm_1_28_0@libnm_1_28_0 1.27.90
+#MISSING: 1.30.0-1# libnm_1_2_0@libnm_1_2_0 1.1.90
+#MISSING: 1.30.0-1# libnm_1_2_4@libnm_1_2_4 1.2.4
+#MISSING: 1.30.0-1# libnm_1_30_0@libnm_1_30_0 1.29.90
+#MISSING: 1.30.0-1# libnm_1_4_0@libnm_1_4_0 1.4.0
+#MISSING: 1.30.0-1# libnm_1_6_0@libnm_1_6_0 1.5.90
+#MISSING: 1.30.0-1# libnm_1_8_0@libnm_1_8_0 1.8.0
  nm_802_11_ap_flags_get_type@libnm_1_0_0 1.0.0
  nm_802_11_ap_security_flags_get_type@libnm_1_0_0 1.0.0
  nm_802_11_mode_get_type@libnm_1_0_0 1.0.0
dh_makeshlibs: error: failing due to earlier errors
make[1]: *** [debian/rules:69: override_dh_makeshlibs] Error 1
make[1]: Leaving directory '/network-manager-1.30.0'
make: *** [debian/rules:10: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983114: libapparmor1: After upgrade is the system not bootable. Init is complaining about incorrect apparmor version.

2021-04-11 Thread Ďoďo

Hi, yes, I do agree the problem is in libc dependencies. Yes, I am using
testing and I just did allow the apt to upgrade all the
recommended packages. It resulted in not booting system.

But after reading your email 2-3 times and then triple checking my
apt.sources I noticed something there. This is my cleaned apt source:
deb http://ftp.de.debian.org/debian/ stable main non-free contrib
deb http://ftp.de.debian.org/debian/ testing main non-free contrib
deb http://security.debian.org/debian-security stable/updates main contrib
non-free
deb http://ftp.de.debian.org/debian/ stretch-updates main contrib non-free

Is it possible that the forgotten stretch-updates is the trouble maker?
Otherwise I do not understand your comment about "running testing on
stretch system".
Thanks for your reply and sorry for very likely incorrect bug report

Jozef

On Fri, Apr 2, 2021 at 11:31 AM intrigeri  wrote:

> Control: tag -1 + moreinfo
>
> Hi,
>
> Ivanecky Jozef (2021-02-19):
> > Package: libapparmor1
> > Version: 2.13.6-9
>
> > Debian Release: 9.8
> >   APT prefers oldstable-updates
> >   APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500,
> 'stable')
>
> > Versions of packages libapparmor1 depends on:
> > ii  libc6  2.31-9
>
> It looks like you've upgraded key packages (libapparmor1, libc6) to
> the version from testing/sid on a Stretch system. Is this correct?
>
> This kind of setup is unsupported and I'm afraid there's little chance
> it'll work. I suspect the problem here is about the libc6 upgrade,
> rather than about AppArmor, by the way.
>

Bug#986746: systemd: Symbols are missing when building systemd by Clang

2021-04-11 Thread Michael Biebl


Control: reassign -1 lld-11
Am 11.04.21 um 14:21 schrieb Michael Biebl:

Hello,

I was surprised reading this bug report, givent that the systemd 
upstream CI runs Clang builds with different Clang versions.


I rebuilt both the buster and sid/bullseye systemd package in a 
corresponding build chroot with clang/llvm-dev with no source changes.


sid built successfully and passed all tests,
buster built successfully as well but had one failing test 
(test-strip-tab-ansi). Rebuilding with "nocheck" was successful.


Ok, the missing part was that you not only used clang but also the llvm 
based linker.

So lld is the real culprit here, thus reassigning.
I could reproduce the issue on sid with lld-11, so reassigning to that 
package.


Excerpt from the build log

dh_makeshlibs -plibudev1 --add-udeb=libudev1-udeb -- -c0
dpkg-gensymbols: warning: some symbols or patterns disappeared in the 
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libudev1/DEBIAN/symbols doesn't match 
completely debian/libudev1.symbols

--- debian/libudev1.symbols (libudev1_247.3-3_amd64)
+++ dpkg-gensymbolsDoJqNd   2021-04-11 13:02:31.114254096 +
@@ -1,11 +1,11 @@
 libudev.so.1 libudev1 #MINVER#
 * Build-Depends-Package: libudev-dev
- LIBUDEV_183@LIBUDEV_183 183
- LIBUDEV_189@LIBUDEV_189 189
- LIBUDEV_196@LIBUDEV_196 196
- LIBUDEV_199@LIBUDEV_199 199
- LIBUDEV_215@LIBUDEV_215 215
- LIBUDEV_247@LIBUDEV_247 247
+#MISSING: 247.3-3# LIBUDEV_183@LIBUDEV_183 183
+#MISSING: 247.3-3# LIBUDEV_189@LIBUDEV_189 189
+#MISSING: 247.3-3# LIBUDEV_196@LIBUDEV_196 196
+#MISSING: 247.3-3# LIBUDEV_199@LIBUDEV_199 199
+#MISSING: 247.3-3# LIBUDEV_215@LIBUDEV_215 215
+#MISSING: 247.3-3# LIBUDEV_247@LIBUDEV_247 247
  udev_device_get_action@LIBUDEV_183 183
  udev_device_get_current_tags_list_entry@LIBUDEV_247 247
  udev_device_get_devlinks_list_entry@LIBUDEV_183 183
dh_makeshlibs -psystemd -Xlibsystemd-shared -- -c0
dh_makeshlibs --remaining-packages -- -c0
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: 
see diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the 
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libsystemd0/DEBIAN/symbols doesn't 
match completely debian/libsystemd0.symbols

--- debian/libsystemd0.symbols (libsystemd0_247.3-3_amd64)
+++ dpkg-gensymbolsuYW0SJ   2021-04-11 13:02:34.350300727 +
@@ -1,33 +1,35 @@
 libsystemd.so.0 libsystemd0 #MINVER#
 * Build-Depends-Package: libsystemd-dev
- LIBSYSTEMD_209@LIBSYSTEMD_209 0
- LIBSYSTEMD_211@LIBSYSTEMD_211 211
- LIBSYSTEMD_213@LIBSYSTEMD_213 213
- LIBSYSTEMD_214@LIBSYSTEMD_214 214
- LIBSYSTEMD_216@LIBSYSTEMD_216 217
- LIBSYSTEMD_217@LIBSYSTEMD_217 217
- LIBSYSTEMD_219@LIBSYSTEMD_219 219
- LIBSYSTEMD_220@LIBSYSTEMD_220 220
- LIBSYSTEMD_221@LIBSYSTEMD_221 221
- LIBSYSTEMD_222@LIBSYSTEMD_222 222
- LIBSYSTEMD_226@LIBSYSTEMD_226 226
- LIBSYSTEMD_227@LIBSYSTEMD_227 227
- LIBSYSTEMD_229@LIBSYSTEMD_229 229
- LIBSYSTEMD_230@LIBSYSTEMD_230 230
- LIBSYSTEMD_231@LIBSYSTEMD_231 231
- LIBSYSTEMD_232@LIBSYSTEMD_232 232
- LIBSYSTEMD_233@LIBSYSTEMD_233 233
- LIBSYSTEMD_234@LIBSYSTEMD_234 234
- LIBSYSTEMD_236@LIBSYSTEMD_236 236
- LIBSYSTEMD_237@LIBSYSTEMD_237 237
- LIBSYSTEMD_238@LIBSYSTEMD_238 238
- LIBSYSTEMD_239@LIBSYSTEMD_239 239
- LIBSYSTEMD_240@LIBSYSTEMD_240 240
- LIBSYSTEMD_241@LIBSYSTEMD_241 241
- LIBSYSTEMD_243@LIBSYSTEMD_243 243
- LIBSYSTEMD_245@LIBSYSTEMD_245 245
- LIBSYSTEMD_246@LIBSYSTEMD_246 246
- LIBSYSTEMD_247@LIBSYSTEMD_247 247
+#MISSING: 247.3-3# LIBSYSTEMD_209@LIBSYSTEMD_209 0
+#MISSING: 247.3-3# LIBSYSTEMD_211@LIBSYSTEMD_211 211
+#MISSING: 247.3-3# LIBSYSTEMD_213@LIBSYSTEMD_213 213
+#MISSING: 247.3-3# LIBSYSTEMD_214@LIBSYSTEMD_214 214
+#MISSING: 247.3-3# LIBSYSTEMD_216@LIBSYSTEMD_216 217
+#MISSING: 247.3-3# LIBSYSTEMD_217@LIBSYSTEMD_217 217
+#MISSING: 247.3-3# LIBSYSTEMD_219@LIBSYSTEMD_219 219
+#MISSING: 247.3-3# LIBSYSTEMD_220@LIBSYSTEMD_220 220
+#MISSING: 247.3-3# LIBSYSTEMD_221@LIBSYSTEMD_221 221
+#MISSING: 247.3-3# LIBSYSTEMD_222@LIBSYSTEMD_222 222
+#MISSING: 247.3-3# LIBSYSTEMD_226@LIBSYSTEMD_226 226
+#MISSING: 247.3-3# LIBSYSTEMD_227@LIBSYSTEMD_227 227
+#MISSING: 247.3-3# LIBSYSTEMD_229@LIBSYSTEMD_229 229
+#MISSING: 247.3-3# LIBSYSTEMD_230@LIBSYSTEMD_230 230
+#MISSING: 247.3-3# LIBSYSTEMD_231@LIBSYSTEMD_231 231
+#MISSING: 247.3-3# LIBSYSTEMD_232@LIBSYSTEMD_232 232
+#MISSING: 247.3-3# LIBSYSTEMD_233@LIBSYSTEMD_233 233
+#MISSING: 247.3-3# LIBSYSTEMD_234@LIBSYSTEMD_234 234
+#MISSING: 247.3-3# LIBSYSTEMD_236@LIBSYSTEMD_236 236
+#MISSING: 247.3-3# LIBSYSTEMD_237@LIBSYSTEMD_237 237
+#MISSING: 247.3-3# LIBSYSTEMD_238@LIBSYSTEMD_238 238
+#MISSING: 247.3-3# LIBSYSTEMD_239@LIBSYSTEMD_239 239
+#MISSING: 247.3-3# LIBSYSTEMD_240@LIBSYSTEMD_240 240
+#MISSING: 247.3-3# LIBSYSTEMD_241@LIBSYSTEMD_241 241
+#MISSING: 247.3-3# LIBSYSTEMD_243@LIBSYSTEMD_243 243
+#MISSING: 247.3-3# LIBSYSTEMD_245@LIBSYSTEMD_245 245
+#MISSING: 247.3-3# LIBSYSTEMD_246@LIBSYSTEMD_246 246
+#MISSING: 247.3-3#

Bug#986757: partman-auto-lvm: Allow reuse of existing PVs / VGs / LVs when using expert_recipe

2021-04-11 Thread bauen1

Source: partman-auto-lvm
Version: 84
Severity: wishlist
X-Debbugs-Cc: j24...@gmail.com

Dear Maintainer,

Please allow the use of existing Physical / Logical Volumes and Volume Groups 
when using expert_recipe similar to normal partitions.

This allows the preseeding of installations where an existing LVM Volume 
contains Data that should be kept intact, e.g. for multi boot setups, or a 
seperate /, /var, /home on LVM where only / should be erased.
Currently this is not possible, as auto-lvm wipes any existing PVs, VGs, LVs 
unconditionally, even if the expert_recipe results in them being recreated in 
the exact same way immediately.

This was already requested / asked a few times:

https://lists.debian.org/debian-boot/2015/05/msg00339.html

https://lists.debian.org/debian-boot/2013/08/msg00275.html

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy

Bug#986756: unblock: please unblock python3-defaults

2021-04-11 Thread Matthias Klose

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

please unblock python3-defaults/3.9.2-3.

  * Ship index.html to unbreak links in python-policy.html. Closes: #985313.
  * Don't ship html policy links in the python3.9 doc directory.
Closes: #984961.

There are no code changes, the package is a dependency package.

Fixing a dangling symlink, and making the html policy links work, however the
latter is already worked around at
https://www.debian.org/doc/packaging-manuals/python-policy/

Bug#986755: unblock: please unblock what-is-python

2021-04-11 Thread Matthias Klose

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

please unblock what-is-python.

  * Update package descriptions for the Debian 11 (bullseye) release.
  * Bump package versions and provides.
  * Provide pdb symlinks in the -dev packages.
  * Also provide symlinks to the manual pages for all packages.

There are no code changes, the package is a dependency package.

The python-is-python3 and python-dev-is-python3 are now provided in version
3.9.x, instead of 3.8.x to match what is shipped with bullseye.

Bug#977468: smuxi is marked for autoremoval from testing

2021-04-11 Thread Mirco Bauer

On Wed, Mar 17, 2021 at 4:13 AM Moritz Mühlenhoff  wrote:

> > Having identified the offending code the fix is a one line change on the
> > other hand. I plan to upload a fixed version of log4net in the coming
> days.
>
> What's the status of that upload? Patch is at
>
> https://github.com/apache/logging-log4net/commit/d0b4b0157d4af36b23c24a23739c47925c3bd8d7

After some struggles with my pbuilder setup I have pushed the backported
fix for CVE-2018-1285 to salsa [0].

Since I don't have access to my PGP key during the pandemic, I am looking
for a sponsor for the upload of HEAD [1].
The source package builds from HEAD as 1.2.10+dfsg-8 and is ready for a
build with gbp and upload.

 [0]:
https://salsa.debian.org/dotnet-team/log4net/-/commit/3f6f2fa7927ceb8c7dd72e4f8cf4194ad3779bc6
 [1]:
https://salsa.debian.org/dotnet-team/log4net/-/commit/a1a1620bb68b815713e7408824be04825e544c27

Best regards,

Mirco Bauer

Security Architect  mirco.ba...@bitgamelabs.com https://bgl.hk/
FOSS Hacker mee...@meebey.net  https://www.meebey.net/
Debian Developermee...@debian.org  http://www.debian.org/
GNOME Foundation Member mmmba...@gnome.org http://www.gnome.org/
.NET Foundation Advisory Council Memberhttp://www.dotnetfoundation.org/
PGP-Key ID  0x7127E5ABEEF946C8 https://meebey.net/pubkey.asc

Bug#986754: unblock: please unblock gcc-9-cross and gcc-9-cross-ports

2021-04-11 Thread Matthias Klose

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

please unblock gcc-9-cross and gcc-9-cross-ports, no-change rebuilds using the
gcc-9 version as found in bullseye.

Bug#986753: unblock: cross-toolchain-base-ports

2021-04-11 Thread Matthias Klose

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

please unblock cross-toolchain-base-ports/45, same rationale as given for
cross-toolchain-base in #985363

Bug#986752: unblock: petsc/3.14.5+dfsg1-3

2021-04-11 Thread Drew Parsons

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

Please unblock package petsc

[ Reason ]

petsc 3.14.5+dfsg1-2 has a packaging bug #985659. (potential dangling
symlinks in docs).

petsc 3.14.6 has just been released, and is a final bugfix release for 3.14
before the petsc 3.15 series.

This releases fixes #985659 (a trivial update to Depends),
and cherry-picks four specific patches from 3.14.6 which may be
anticipated to affect bullseye 3.14.5 users.

The specific bug fixes cherry-picked from PETSc 3.14.6 are pulled from
the separate upstream Pull Releases and applies as separate patches in
debian/patches. 

- PR3681_scalapack_block_size.diff

  sets block size of transposed ScalAPACK matrices
  
  source: PR3681  https://gitlab.com/petsc/petsc/-/merge_requests/3681
  3.14.6 commit 59172f18

- PR3686_DMPlex_missing_PetscSFSetUp.diff

  adds PetscSFSetUp() to DM plexcreate.c
  
  source: PR3686  https://gitlab.com/petsc/petsc/-/merge_requests/3686
  3.14.6 commit 07a779fe

- PR3722_umfpack_ordering.diff

  use default umfpack ordering since much faster than PETSc ordering
  
  source: PR3722  https://gitlab.com/petsc/petsc/-/merge_requests/3722
  3.14.6 commit 07a4507b

- PR3728_DM_anchor_initialize.diff

  initialize variable in DM anchor calculation
  
  source: PR3728  https://gitlab.com/petsc/petsc/-/merge_requests/3728
  3.14.6 commit 326b8f31


[ Impact ]

Bug#985659 affects general policy of providing packages without
dangling links.
 
The bugs fixed by the PRs from 3.14.6 can be expected to badly affects
users accessing those functionalities, with data blocks not correctly
initialized (PR3681, PR3686, PR3728).

PR3722 is a trivial patch that significantly improves performance when
using the umfpack solver (which is often used to solve linear systems).

[ Tests ]

petsc/3.14.5+dfsg1-3 debci tests are passing.

debci tests for client packages (dolfin, deal.ii) are also
passing against petsc/3.14.5+dfsg1-3, as are petsc4py, slepc

[ Risks ]

#985659 is fixed simply by adding "Depends: sphinx-common" to
petsc3.14-doc 

Each patch is a one line change only, or in the case of
PR3681_scalapack_block_size.diff, reducing code complexity by
reducing 4 lines to 1 line (in 3 locations)

For that reason the risk of the patches is low.

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

[ Other info ]

PETSc 3.15.0 is now released. I expect 3.14.6 to be the final bugfix
release in the petsc 3.14 series.  The debian release here pulls the
crucial fixes from 3.14.6, making the 3.14.5 version in bullseye as
robust as the final upstream bugfix release.

unblock petsc/3.14.5+dfsg1-3
diff -Nru petsc-3.14.5+dfsg1/debian/changelog 
petsc-3.14.5+dfsg1/debian/changelog
--- petsc-3.14.5+dfsg1/debian/changelog 2021-03-10 12:21:59.0 +0100
+++ petsc-3.14.5+dfsg1/debian/changelog 2021-04-09 13:28:02.0 +0200
@@ -1,3 +1,21 @@
+petsc (3.14.5+dfsg1-3) unstable; urgency=medium
+
+  * petsc3.14-doc Depends: sphinx-common.
+Required since upstream tarball provides pregenerated docs, so
+dh_sphinxdoc does not automatically add sphinx-common.
+Closes: #985659.
+  * cherry-pick specific bug fixes from PETSc 3.14.6
+- PR3681_scalapack_block_size.diff, sets block size of transposed
+  ScalAPACK matrices
+- PR3686_DMPlex_missing_PetscSFSetUp.diff, adds PetscSFSetUp()
+  to DM plexcreate.c
+- PR3722_umfpack_ordering.diff, use default umfpack ordering
+  since much faster than PETSc ordering
+- PR3728_DM_anchor_initialize.diff, initialize variable in DM
+  anchor calculation
+
+ -- Drew Parsons   Fri, 09 Apr 2021 13:28:02 +0200
+
 petsc (3.14.5+dfsg1-2) unstable; urgency=medium
 
   * upload new bugfix release to unstable
diff -Nru petsc-3.14.5+dfsg1/debian/control petsc-3.14.5+dfsg1/debian/control
--- petsc-3.14.5+dfsg1/debian/control   2021-03-10 12:21:59.0 +0100
+++ petsc-3.14.5+dfsg1/debian/control   2021-04-09 13:28:02.0 +0200
@@ -198,7 +198,7 @@
 Architecture: all
 Multi-Arch: foreign
 Section: doc
-Depends: ${misc:Depends}, ${sphinxdoc:Depends}
+Depends: sphinx-common, ${misc:Depends}, ${sphinxdoc:Depends}
 Suggests: libpetsc-real3.14-dev (= ${binary:Version}), illuminator-doc
 Description: Documentation and examples for PETSc
  PETSc is the "Portable Extensible Toolkit for Scientific
diff -Nru petsc-3.14.5+dfsg1/debian/patches/PR3681_scalapack_block_size.diff 
petsc-3.14.5+dfsg1/debian/patches/PR3681_scalapack_block_size.diff
--- petsc-3.14.5+dfsg1/debian/patches/PR3681_scalapack_block_size.diff  
1970-01-01 01:00:00.0 +0100
+++ petsc-3.14.5+dfsg1/debian/patches/PR3681_scalapack_block_size.diff  
2021-04-09 13:28:02.0 +0200
@@ -0,0 +1,45 @@
+diff --git a/src/mat/impls/scalapack/matscalapack.c 
b/src/mat/impls/scalapack/matscalapack.c

Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

2021-04-11 Thread Chris Hofstaedtler

Hello Václav, Marc,

* Václav Doležal  [210410 19:15]:
> > Thanks for your followup. The original submitter sent this info in
> > message #27:
> > 
> > 
> ># lsblk --version
> >lsblk from util-linux 2.35.1
> Yes, I noticed. But the bug is in libblkid, lsblk just displays info passed 
> by 
> udev.
> 
> Log in msg#37 (http://data.plan9.de/blkidbug.txt) starts with
> 
> 5575: libblkid: INIT: library version: 2.33.1 [09-Jan-2019]
> 
> so I think only util-linux package was upgraded.

Ah indeed, thanks for pointing this out.

Marc, could you try again with a fully-upgraded system?

> Otherwise, I think that the log matches the behaviour of libblkid prior to 
> cdb9140967.

Thanks,
Chris

Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked

2021-04-11 Thread Michael Biebl

On Mon, 24 Feb 2020 17:38:53 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?=
 wrote:
> Package: user-setup
> Version: 1.83
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> 
> Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
> the systemd-sulogin-shell binary run by rescue.service and
> emergency.service now adds the --force flag for the sulogin call
> when SYSTEMD_SULOGIN_FORCE is set to 1 in the environment.
> 
>
https://github.com/systemd/systemd/commit/33eb44fe4a8d7971b5614bc4c2d90f8d91cce66c
> explains that the expectation is that distributions should now
> put service override files to set this environment variable.
> 
> Thus user-setup should create the appropriate configuration file when
> the root account is not configured. Maybe this should be controlled
> by some low priority debconf question as the password-less login through
> the rescue boot entry can be seen as a security issue by some.
> 

There is https://salsa.debian.org/ah/user-setup/commits/wip/rootpassword
thanks to Andreas.

I'd suggest that people caring about that issue submit this as proper MR.

Regards,
Michael


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

Bug#986751: ITP: python-apispec -- pluggable API specification generator

2021-04-11 Thread Jelmer Vernooij

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-de...@lists.debian.org, de...@kali.org

* Package name: python-apispec
  Version : 3.3.1
* URL : https://github.com/marshmallow-code/apispec
* License : MIT
  Programming Lang: Python
  Description : pluggable API specification generator

 This package contains a pluggable API specification generator. It currently
supports the OpenAPI Specification (f.k.a. the Swagger specification).  The
features are:
  - Supports the OpenAPI Specification (versions 2 and 3)
  - Framework-agnostic
  - Built-in support for marshmallow
  - Utilities for parsing docstrings

(this is already packaged in kali at 
https://gitlab.com/kalilinux/packages/apispec, I will base the package on 
theirs)

Bug#986750: ITP: python-webargs -- Python library for parsing and validating HTTP request arguments

2021-04-11 Thread Jelmer Vernooij

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-de...@lists.debian.org, de...@kali.org

* Package name: python-webargs
  Version : 7.0.1
* URL : https://github.com/sloria/webargs
* License : MIT
  Programming Lang: Python
  Description : Python library for parsing and validating HTTP request 
arguments

 This package contains a Python library for parsing and validating HTTP request 
 arguments, with built-in support for popular web frameworks, including Flask,  
Django, Bottle, Tornado, Pyramid, webapp2, Falcon, and aiohttp.

(Already packaged in Kali, I will be basing this on their packaging -
https://gitlab.com/kalilinux/packages/python-webargs)

Bug#986749: apt-cacher-ng: acng still stops working with APOLL ADD failing and Bad file descriptor

2021-04-11 Thread Christian Meyer

Package: apt-cacher-ng
Version: 3.6.3-1
Severity: important
X-Debbugs-Cc: c2h...@web.de

Dear Maintainer,

even after the recent acng updates I still see apt-cacher-ng (3.6.3-1 amd64) 
stop working.
Apt throws a bunch of errors like:

E: Fehlschlag beim Holen von 
http://deb.debian.org/debian/dists/bullseye/main/Contents-all Fehler beim Lesen 
vom Server: Verbindung wurde durch den Se
rver auf der anderen Seite geschlossen. [IP: 127.0.0.1 3142]
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden 
ignoriert oder alte an ihrer Stelle benutzt.
...

W: Das Depot »http://127.0.0.1:3142/deb.debian.org/debian bullseye Release« 
enthält keine Release-Datei.
E: Fehlschlag beim Holen von 
http://127.0.0.1:3142/deb.debian.org/debian/dists/bullseye/main/binary-i386/Packages
 503  Service Unavailable [IP: 127.0.
0.1 3142]
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden 
ignoriert oder alte an ihrer Stelle benutzt.
E: Paket adduser kann nicht gefunden werden.
E: Paket apt kann nicht gefunden werden.
...

...
Get:99 http://deb.debian.org/debian bullseye/main amd64 krb5-user amd64 
1.18.3-4 [151 kB]
Get:100 http://deb.debian.org/debian bullseye/main amd64 ldap-utils amd64 
2.4.57+dfsg-2 [206 kB]
Get:101 http://deb.debian.org/debian bullseye/main amd64 
linux-image-5.10.0-5-amd64 amd64 5.10.26-1 [53.4 MB]
Err:101 http://deb.debian.org/debian bullseye/main amd64 
linux-image-5.10.0-5-amd64 amd64 5.10.26-1
  Undetermined Error [IP: 127.0.0.1 3142]
Err:102 http://deb.debian.org/debian bullseye/main amd64 linux-image-amd64 
amd64 5.10.26-1
  Could not connect to 127.0.0.1:3142 (127.0.0.1). - connect (111: Connection 
refused) [IP: 127.0.0.1 3142]
Err:103 http://deb.debian.org/debian bullseye/main amd64 whois amd64 5.5.8
  Unable to connect to 127.0.0.1:3142: [IP: 127.0.0.1 3142]


Since systemctl often tells me something about "Epoll ADD" failing:
# systemctl status apt-cacher-ng.service
apt-cacher-ng[646]: [warn] Epoll ADD(1) on fd 14 failed. Old events were 0; 
read change was 1 (add); write change was 0 (none); close change was 0 (none): 
Bad file descriptor

my workaround is to automatically restart the service by a cronjob (and after 
that /usr/lib/apt-cacher-ng/expire-caller.pl) when this line is seen.



More information:

Yes, my internet connection is very slow (around 8000 kbit/s) and that's my 
reason to run acng).

# less /var/log/apt-cacher-ng/apt-cacher.err.1
Beside of tons of "Bad file descriptor" messages:
Fri Apr  9 11:13:05 
2021|debrep/pool/main/f/ffmpeg/libavutil56_4.3.2-0+deb11u1_amd64.deb storage 
error [HTTP/1.1 503 Bad file descriptor], last errno: Bad file descriptor
Fri Apr  9 11:13:06 
2021|debrep/pool/main/c/codec2/libcodec2-0.9_0.9.2-4_amd64.deb storage error 
[HTTP/1.1 503 Bad file descriptor], last errno: Bad file descriptor
Fri Apr  9 11:13:17 
2021|debrep/pool/main/p/pulseaudio/libpulsedsp_14.2-2_amd64.deb storage error 
[HTTP/1.1 503 Bad file descriptor], last errno: Bad file descriptor

I only see a few different ones:
Fri Apr  9 10:57:49 2021|Failed to move stale item 
debrep/dists/bullseye/main/i18n/Translation-de.bz2 out of the way: No such file 
or directory
Fri Apr  9 10:59:29 2021|Failed to move stale item 
debrep/dists/bullseye/main/i18n/Translation-en.bz2 out of the way: No such file 
or directory
Fri Apr  9 11:05:10 
2021|debrep/pool/main/f/fonts-liberation/fonts-liberation_1.07.4-11_all.deb 
storage error [HTTP/1.1 503 Broken pipe], last errno: Broken pipe
Fri Apr  9 11:06:56 
2021|debrep/pool/main/l/lm-sensors/libsensors5_3.6.0-7_i386.deb storage error 
[HTTP/1.1 503 Connection reset by peer], last errno: Connection reset by peer
Fri Apr  9 11:12:51 
2021|debrep/pool/main/libr/libreoffice/libreoffice-base-drivers_7.0.4-3_amd64.deb
 storage error [HTTP/1.1 503 Broken pipe], last errno: Broken pipe


# journalctl
only shows something like:
Apr 03 00:34:03 121-My apt-cacher-ng[2900630]: [warn] fcntl(15, F_SETFL): Bad 
file descriptor
...
Apr 09 11:12:44 121-My apt-cacher-ng[2900630]: [warn] Epoll ADD(1) on fd 75 
failed. Old events were 0; read change was 1 (add); write change was 0 (n>
Apr 09 11:12:53 121-My apt-cacher-ng[2900630]: [warn] Epoll ADD(1) on fd 75 
failed. Old events were 0; read change was 1 (add); write change was 0 (n>
Apr 09 11:12:53 121-My apt-cacher-ng[2900630]: [warn] Epoll ADD(1) on fd 73 
failed. Old events were 0; read change was 1 (add); write change was 0 

Christian Meyer



-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf

Bug#986665: $HOME not writable when using schroot

2021-04-11 Thread Simon McVittie

Control: severity -1 normal
Control: retitle -1 autopkgtest-virt-schroot: cannot guarantee that $HOME is 
writable
Control: found -1 2.0.0

I'm sure autopkgtest could do better to try to arrange things "normally",
and I'd be happy to review an implementation if you have one in mind,
but I don't think we can treat this as RC when autopkgtest-virt-schroot
has (as far as I can tell) always worked like this since its introduction
in 2011.

On Fri, 09 Apr 2021 at 13:24:54 +0200, Laurent Bigonville wrote:
> Le 9/04/21 à 11:09, Simon McVittie a écrit :
> > If you are using profile=default (which is the default if left unspecified),
> > /etc/schroot/default/fstab usually bind-mounts the real /home.
> > 
> > If you are using profile=sbuild, /etc/schroot/sbuild/fstab usually does
> > not, making it unsuitable for autopkgtest-virt-schroot.
> 
> I'm indeed using the "sbuild" profile, but I don't think that anybody would
> want to have their real home bind mounted in the chroot and mixed with the
> one from the tests

Sure, but this is not really under autopkgtest's control. You've chosen to
use a particular schroot profile which has a particular meaning, and
autopkgtest-virt-schroot is doing its best to run tests in that environment.

The responsibility for making autopkgtest implement the spec is shared
between autopkgtest itself, the virt backend (in this case -virt-schroot),
and virt-backend-specific configuration: autopkgtest can't really guarantee
that an arbitrary chroot/container/VM implements everything it needs,
because you might have given it a chroot that is missing important things
or isn't even Debian-based.

> Shouldn't HOME be pointing a temporary directory like for AUTOPKGTEST_TMP ?

That would be following the letter of the spec, but not really the spirit,
IMO. Some packages look at a user's "official" home directory (according to
getent passwd) instead of looking at $HOME, and those packages ought to be
testable too.

Setting $HOME to a temporary directory owned by the running user might be
the next best thing, and I'd be happy to review an implementation of that.

If we're root, then it might be possible to `install -d` the "official"
home directory if it doesn't already exist, and optionally mount a tmpfs
onto it? But I'm not sure whether mounting an extra tmpfs would break
schroot session teardown, and we definitely wouldn't want to do this if
autopkgtest-virt-schroot is (mis)configured to run tests as a user whose
home directory is something like /nonexistent!

If mounting an extra tmpfs doesn't break schroot teardown, then perhaps
it would be possible to mount a tmpfs on /home (if it exists), then
`install -d` the "official" home directory if it happens to be below /home,
which in practice it usually will be?

Or maybe autopkgtest could install an /etc/schroot/setup.d/ hook to set
up the desired situation during schroot setup and undo it during teardown
if asked to do so (somehow) by autopkgtest-virt-schroot?

> > I would recommend using autopkgtest-virt-lxc or autopkgtest-virt-qemu:
> > those are considerably better-tested in practice than -schroot.
> 
> I should maybe look at that, but my schroot setup is usually enough for me

Given that schroot is orphaned in Debian, had its most recent upstream
release 6 years ago and is mostly only used by Debian, I'd be reluctant
to put a lot of time or work into relying on schroot, for anything where
Debian doesn't already rely on it.

For porterboxes and official buildds, we're stuck with it for now (until
someone implements first-class-citizen support for doing those things with
for example Docker, podman or systemd-nspawn, which I'm sure will happen
eventually), and for systems that aim to emulate official buildds as
closely as possible (like my "vectis"), we're also stuck with it for now;
but for things like autopkgtest that are not already particularly tied to
schroot, I think we need to be looking for an exit strategy onto a real
container manager, more than trying to turn schroot into one.

smcv

Bug#966707: debhelper: dh not keeping command log results in package rebuild

2021-04-11 Thread Niels Thykier

On Fri, 16 Oct 2020 17:57:26 +0200 Alex  wrote:
> Hi,
> 
> Samuel is not alone in this issue. As I frequently rebuild packages with
> small changes, I fully recognise the reported problem occurring since
> compat 10. I would very welcome a solution to get the behaviour of
> compat<10 back as waiting half an hour per build, just to find an error
> in some final step is not fun...
> 

As I said, I understand the issue and can definitely see why you would
like a change in dh.
  For now, there is a work around.  In its raw format, it is not very
pretty but someone could clean it up and provide a short-hand for it.

> On Sat, 12 Sep 2020 18:09:57 +0200 Samuel Thibault
>  wrote:
> > DH_REBUILD=dh_auto_build dpkg-buildpackage -B -nc
> > or
> > DH_REBUILD=dh_auto_configure dpkg-buildpackage -B -nc
> 
> Or using a command-line parameter to specify the step at which dh should
> restart:
> 
> dpkg-buildpackage -B --no-pre-clean=dh_auto_build
> 
> Or if reusing --no-pre-clean is a no-go:
> 
> dpkg-buildpackage -B --continue=dh_auto_build
> 
> --
> mvg,
> 
> Alex Hermann
> 
> 

Looks like as good a starting point as any, but it would require support
in dpkg (which has a separate set of maintainers).  Feel free to suggest
it to them, but be advised that that the dpkg maintainers almost
certainly will want a general solution (i.e. one that is not tied to
debhelper).

If dpkg-buildpackage provides an interface that debhelper can rely on
and easily use, then that I happy to consider adding support for that
interface in debhelper.  That said, I am not planning to drive the
discussion/design - "someone else" will have to volunteer to take that role.

~Niels

Bug#986748: syslog-ng: stucks on writev(), mostly around nightly rotate and cause _everything_ to stuck until killed

2021-04-11 Thread Peter Gervai

Package: syslog-ng
Version: 3.28.1-2
Severity: important
Tags: upstream

I sincerely apologise since this is not a good bugreport, so if you really
feel like completely clueless you can close it, but the problem will
probably presist.

The environments use SysV init (none of the systems are systemd-infected).
(It is possible that it have happened on a systemd-infected server, too,
but I am not sure now as it was many weeks before and back then I was not
aware about the cause of the problem.)

What happens: 

* usually around 03:26 (cron.daily / logrotate) syslog-ng gets stuck on a
writev() call, which is supposed to write the actual incoming log line into
a physical file on the system. strace shows that syslog-ng gets signals 
(like HUP or TERM), handles them and ignores them and go back to writev().

* during this time the syslog service blocks (after a while). 

* this in turn blocks everything using syslog service, and I mean everything.
Notable mentions are dhcp server, vpn server, various cron services. (Blocking
cron may also mean system load goes sky high due to many cron spawns running at 
once.)

* the disk is not full. 

* HUP, TERM and normal signals get ignored. ILL or KILL kills the daemon and the
system starts working again as syslog-ng gets respawned.

Log rotation is done using 'invoke-rc.d syslog-ng reload' which uses 
`start-stop-daemon` to send SIGNAL1 (SIGHUP) then uses 
`syslog-ng-ctl stats` to see when the daemon reports back, which never happens:
the call gets stuck as well.
[I would guess SIGHUP handler runs amok.]

This seems to happen in 3.19.1-5 and 3.28.1-2 as well, but only on the fraction
of the servers, but there it is recurring around weekly. Nothing relevant is in
dmesg or elsewhere. :-(


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

Kernel: Linux 5.8.6 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages syslog-ng depends on:
ii  syslog-ng-core 3.28.1-2+b1
ii  syslog-ng-mod-mongodb  3.28.1-2+b1
ii  syslog-ng-mod-sql  3.28.1-2+b1

Versions of packages syslog-ng recommends:
pn  syslog-ng-mod-add-contextual-data  
pn  syslog-ng-mod-amqp 
pn  syslog-ng-mod-examples 
pn  syslog-ng-mod-extra
pn  syslog-ng-mod-geoip2   
pn  syslog-ng-mod-getent   
pn  syslog-ng-mod-graphite 
pn  syslog-ng-mod-http 
pn  syslog-ng-mod-map-value-pairs  
pn  syslog-ng-mod-python   
pn  syslog-ng-mod-rdkafka  
pn  syslog-ng-mod-redis
pn  syslog-ng-mod-riemann  
pn  syslog-ng-mod-slog 
pn  syslog-ng-mod-smtp 
pn  syslog-ng-mod-snmp 
pn  syslog-ng-mod-stardate 
pn  syslog-ng-mod-stomp
pn  syslog-ng-mod-xml-parser   

syslog-ng suggests no packages.

-- no debconf information

Bug#956192: Any progress or missing information?

2021-04-11 Thread Laura Arjona Reina

Hi
I have added an exception about manpages-l10n in a similar way than was
already for manpages-fr-extra (thanks David Prévot for the hint):

https://salsa.debian.org/webmaster-team/webwml/-/commit/017f1d07c22c906dcb76ad48d7db75ff615b9b99

Closing the bug, feel free to reopen if you see something broken or not
working as expected (I think the scripts run once a day, so we need to
wait a bit to see the efects of the change made in the webwml repo).

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

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

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#956192: Any progress or missing information?

2021-04-11 Thread Helge Kreutzmann

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

Thank you very much for you now very swift response!

In case some (unexpected) problem arises, I'll let you know.

Greetings

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


signature.asc
Description: PGP signature

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

2021-04-11 Thread Simon McVittie

Control: retitle -1 inkscape, etc. crashing with mismatched libpoppler102 and 
libpoppler-glib8

On Sat, 10 Apr 2021 at 22:13:13 +0200, Ivo De Decker wrote:
> Install inkscape on a buster system. The pdf David attached can be opened
> without issue. Upgrade only inkscape to bullseye (letting apt pull in the
> dependencies, which include libpoppler102 but not the newer libpoppler-glib8).
> When opening the pdf inkscape closes with an error, and the kernel reports:
> inkscape[9032]: segfault at 9 ip 7fad9e3e1d3e sp 7fff5127ae30 error 4 
> in libpoppler-glib.so.8.10.0[7fad9e3c4000+27000]
> 
> Installing the new libpoppler-glib8 fixes the issue.
> 
> A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
> well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
> have an elegant way to handle this automatically at build time to make sure
> the dependencies are correct, without having to add them manually.

Should libpoppler102 get a Breaks: libpoppler-glib8 (<< 20.08.0-1~), where
that version was the first one to have the libpoppler102 SONAME? That
would ensure that the bad partial upgrade you describe can't happen,
because if a dependent package uses libpoppler102 ABI directly, and
also uses libpoppler indirectly via libpoppler-glib8, then it's the
same libpoppler.

Or, would this work?

* in src:poppler libpoppler-glib8.symbols.in, bump the version on every
  symbol to at least 20.08.0-1~ (the version that had the most recent
  SONAME bump) and upload to unstable
* binNMU the dependent packages elpa-pdf-tools-server, gambas3-gb-poppler
  and inkscape

That way, the binNMU'd versions of the dependent packages would have:

Depends: libpoppler-glib8 (>= 20.08.0-1~), libpoppler102 (>= x)

and the bad partial upgrade you describe could not happen, because the
dependent package (inkscape in your example) would pull in the new
libpoppler-glib8 in addition to the new libpoppler102.

For completeness, maybe it would make sense to give libpoppler-cpp0v5 and
libpoppler-qt5-1 the same treatment as libpoppler-glib8 (whatever that is),
since they could suffer from the same bug if an application calls into
libpoppler both directly and via libpoppler-cpp0v5 or libpoppler-qt5-1 -
although I don't know whether that happens in practice.

smcv

Bug#986747: unblock: bouncy/0.6.20071104-8

2021-04-11 Thread Reiner Herrmann

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

Please unblock package bouncy

[ Reason ]
A missing dependency on a python3 module prevented the program from starting.

[ Impact ]
Without python3-future installed, bouncy does not start and the user
would need to install the missing dependency manually.

[ Tests ]
I tested running the program with and without the new dependency
and can confirm that it does not start without it, and starts/runs
successfully with it.

[ Risks ]
Low risk, no code changes, only new runtime dependency.

unblock bouncy/0.6.20071104-8
diff -Nru bouncy-0.6.20071104/debian/changelog 
bouncy-0.6.20071104/debian/changelog
--- bouncy-0.6.20071104/debian/changelog2019-09-15 18:17:45.0 
+0200
+++ bouncy-0.6.20071104/debian/changelog2021-04-10 15:55:51.0 
+0200
@@ -1,3 +1,12 @@
+bouncy (0.6.20071104-8) unstable; urgency=medium
+
+  * Team upload.
+  * Add dependency on python3-future.
+Thanks to Jérôme Bouat for the report, Hans Joachim Desserud for the fix.
+(Closes: #986577) (LP: #1922504)
+
+ -- Reiner Herrmann   Sat, 10 Apr 2021 15:55:51 +0200
+
 bouncy (0.6.20071104-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru bouncy-0.6.20071104/debian/control bouncy-0.6.20071104/debian/control
--- bouncy-0.6.20071104/debian/control  2019-09-15 18:17:45.0 +0200
+++ bouncy-0.6.20071104/debian/control  2021-04-10 15:55:51.0 +0200
@@ -21,6 +21,7 @@
 Architecture: all
 Depends:
  fonts-dejavu-core,
+ python3-future,
  python3-opengl,
  python3-pygame,
  ${misc:Depends},

Bug#977367: debsources: search results point to not existing sources?

2021-04-11 Thread Michael Stapelberg

Thanks for looping me in.

We introduced unpacking tarballs in https://github.com/Debian/dcs/issues/80
(from 2017!),
but apparently didn’t think it through far enough regarding sources.d.o :)

Would adding support for unpacking tarballs be something you would consider
in debsources?
I know that tarballs *technically are the source*, but humans clearly find
the contents of these tarballs more interesting.

Otherwise, we could handle these with our own /show handler by checking if
the source is present in debsources first,
but that obviously involves one additional request per /show handler, so
it’s not exactly cheap.

On Mon, Apr 5, 2021 at 8:23 PM Matthieu Caneill  wrote:

> Control: usertag -1 debsources
> Control: merge 761077 -1
>
> Hi Tomas,
>
> On Mon, Dec 14, 2020 at 02:13:49PM +0100, Tomas Pospisek wrote:
> > Go to
> https://codesearch.debian.net/search?q=Client+sent+an+HTTP+request+to+an+HTTPS+server
> > select first link
> https://codesearch.debian.net/show?file=gcc-10_10.2.1-1%2Fgcc-10.2.0%2Flibgo%2Fgo%2Fnet%2Fhttp%2Fserver.go=1798
> > get a 404 with a list of 12 alternative source files of different
> > versions of gcc-XX/XX.Y.Z-W/gcc-XX.V.U/libgo/go/net/http/server.go
> > each returning a 404.
> >
> > I have now clicked through quite a few links to source files, but
> > have yet to find one that won't return a 404...?
> >
> > Maybe the search index would need to be purged of source files that
> > have disappeared (been updated) or something?
>
> Thank you very much for the detailed bug report, and apologies for the
> delay in getting back to you.
>
> After further inspection, it turns out the tarball containing the
> source for gcc-10 contains embedded tarballs. See
> http://deb.debian.org/debian/pool/main/g/gcc-10/gcc-10_10.2.1.orig.tar.xz
> and https://sources.debian.org/src/gcc-10/10.2.0-3/
>
> Debsources unpacked the first tarball, and the embedded ones are
> technically the "source" of gcc-10. The path you obtained from
> codesearch.debian.net points to a file inside the tarball inside the
> tarball; this is unfortunately not supported by sources.d.o.
>
> I didn't know codesearch supported this feature. CCing Michael, in
> case you have an idea on how not to point to sources.d.o for code
> results originating from unpacked archives. :)
>
> Cheers,
> --
> Matthieu
>


-- 
Best regards,
Michael

Bug#960489: logrotate: error: gzip: stdin: file size changed while zipping

2021-04-11 Thread Ian Campbell

Package: mosquitto
Version: 1.5.7-1+deb10u1
Followup-For: Bug #960489

Dear Maintainer,

I'm also seeing this message, nearly every night I think.

I'm running stable (Buster) but I've picked up the change to use invoke-rc.d
instead of killall from #940229 but that hasn't helped, I think this means I'm
effectively using the same logrotate config as testing/unstable.

My guess is that the "postrotate" hook is not being called until after the
compression, so mosquitto.log.1 is still the live logfile at that point. This
seems a bit odd too me as I can't find any option to run a script between the
rotate and compress which seems like the sort of thing many daemons would need.

Looking at the logrotate man page I think the right answer is to use the
"delaycompress" option:

> Postpone compression of the previous log file to the next rotation cycle.
> This only has effect when used in combination with compress.  It can be
> used when some program cannot be told to close its logfile and thus might
> continue writing to the previous log file for some time.

IOW do not compress mosquitto.log.1 but instead defer until it becomes
mosquitto.log.2 tomorrow. I've deployed this locally but I won't know until a
few days time if it has worked.

HTH,
Ian.

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

Kernel: Linux 4.19.0-16-marvell
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages mosquitto depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libssl1.1   1.1.1d-0+deb10u6
ii  libsystemd0 241-7~deb10u7
ii  libuuid12.33.1-0.1
ii  libwebsockets8  2.0.3-3
ii  libwrap07.6.q-28
ii  lsb-base10.2019051400

mosquitto recommends no packages.

Versions of packages mosquitto suggests:
ii  apparmor  2.13.2-10

-- Configuration Files:
/etc/logrotate.d/mosquitto changed:
/var/log/mosquitto/mosquitto.log {
rotate 7
daily
compress
delaycompress
size 100k
nocreate
missingok
postrotate
if invoke-rc.d mosquitto status > /dev/null 2>&1; then \
invoke-rc.d mosquitto reload > /dev/null 2>&1; \
fi;
endscript
}


-- no debconf information

Bug#986746: systemd: Symbols are missing when building systemd by Clang

2021-04-11 Thread Shawn Chang

Package: systemd
Version: 241-7~deb10u7
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Reproducible steps:

# cat /etc/dpkg/buildflags.conf 
APPEND CFLAGS -O -fPIE  
APPEND CXXFLAGS -O -fPIE 
APPEND LDFLAGS -pie -fuse-ld=lld

# Add below to debian/rules
export CC=clang
export CXX=clang++

3 test cases will failed, you can ignore them by:
  1) Edit debian/rules, comment a few lines:

ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS)))
#   echo "01234567890123456789012345678901" > build-deb/machine-id
# some tests hang under fakeroot, so disable fakeroot
#   env -u LD_PRELOAD 
SYSTEMD_MACHINE_ID_PATH=$(CURDIR)/build-deb/machine-id meson test -C build-deb 
$(TEST_TIMEOUT_MULTIPLIER) || ( \
#
env -u LD_PRELOAD  meson test -C build-deb $(TEST_TIMEOUT_MULTIPLIER) 
|| ( \

  2) Drop two 
patches(0001-util-lib-static-array-argument-sizes-are-apparently-.patch and 
test-bus-track.patch) into debian/patches:

diff --git a/src/basic/string-util.c b/src/basic/string-util.c
index 7c487fb9a3..9586b3940e 100644
--- a/src/basic/string-util.c
+++ b/src/basic/string-util.c
@@ -725,10 +725,17 @@ char *strreplace(const char *text, const char 
*old_string, const char *new_strin
 return ret;
 }

-static void advance_offsets(ssize_t diff, size_t offsets[static 2], size_t 
shift[static 2], size_t size) {
+static void advance_offsets(
+ssize_t diff,
+size_t offsets[2], /* note: we can't use [static 2] here, 
since this may be NULL */
+size_t shift[static 2],
+size_t size) {
+
 if (!offsets)
 return;

+assert(shift);
+
 if ((size_t) diff < offsets[0])
 shift[0] += size;
 if ((size_t) diff < offsets[1])
@@ -844,8 +851,7 @@ char *strip_tab_ansi(char **ibuf, size_t *_isz, size_t 
highlight[2]) {

 fclose(f);

-free(*ibuf);
-*ibuf = obuf;
+free_and_replace(*ibuf, obuf);

 if (_isz)
 *_isz = osz;
@@ -855,7 +861,7 @@ char *strip_tab_ansi(char **ibuf, size_t *_isz, size_t 
highlight[2]) {
 highlight[1] += shift[1];
 }

-return obuf;
+return *ibuf;
 }

 char *strextend_with_separator(char **x, const char *separator, ...) {

diff --git a/src/libsystemd/sd-bus/test-bus-track.c 
b/src/libsystemd/sd-bus/test-bus-track.c
index 68a0010368..57af185d46 100644
--- a/src/libsystemd/sd-bus/test-bus-track.c
+++ b/src/libsystemd/sd-bus/test-bus-track.c
@@ -49,6 +49,7 @@ int main(int argc, char *argv[]) {
 const char *unique;
 int r;

+   return 0;
 test_setup_logging(LOG_INFO);

 r = sd_event_default();

  3) Add those two patch files's name into debian/patches/series

Begin to build the package:
# dpkg-buildpackage -rfakeroot -us -uc



make[1]: Entering directory '/opt/debian10/build/tmp/systemd-241'
dh_missing --sourcedir debian/install/deb --fail-missing
make[1]: Leaving directory '/opt/debian10/build/tmp/systemd-241'
   dh_strip -O--buildsystem=meson
   debian/rules override_dh_makeshlibs
make[1]: Entering directory '/opt/debian10/build/tmp/systemd-241'
sed 's/SHARED_LIB_VERSION/241/' debian/shlibs.local.in > debian/shlibs.local
dh_makeshlibs -plibudev1 --add-udeb=libudev1-udeb -- -c4
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libudev1/DEBIAN/symbols doesn't match 
completely debian/libudev1.symbols
--- debian/libudev1.symbols (libudev1_241-7~deb10u7_amd64)
+++ dpkg-gensymbolshwl7L5   2021-04-11 14:15:58.815007345 +0800
@@ -1,10 +1,10 @@
 libudev.so.1 libudev1 #MINVER#
 * Build-Depends-Package: libudev-dev
- LIBUDEV_183@LIBUDEV_183 183
- LIBUDEV_189@LIBUDEV_189 189
- LIBUDEV_196@LIBUDEV_196 196
- LIBUDEV_199@LIBUDEV_199 199
- LIBUDEV_215@LIBUDEV_215 215
+#MISSING: 241-7~deb10u7# LIBUDEV_183@LIBUDEV_183 183
+#MISSING: 241-7~deb10u7# LIBUDEV_189@LIBUDEV_189 189
+#MISSING: 241-7~deb10u7# LIBUDEV_196@LIBUDEV_196 196
+#MISSING: 241-7~deb10u7# LIBUDEV_199@LIBUDEV_199 199
+#MISSING: 241-7~deb10u7# LIBUDEV_215@LIBUDEV_215 215
  udev_device_get_action@LIBUDEV_183 183
  udev_device_get_devlinks_list_entry@LIBUDEV_183 183
  udev_device_get_devnode@LIBUDEV_183 183
dh_makeshlibs: failing due to earlier errors
make[1]: *** [debian/rules:295: override_dh_makeshlibs] Error 1
make[1]: Leaving directory '/opt/debian10/build/tmp/systemd-241'
make: *** [debian/rules:311: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


-- Package-specific info:

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Locale:

83 matches

Mail list logo