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

[Camaleón]

Package: openldap
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# openldap po-debconf translation to Spanish
# Copyright 2006 Rudy Godoy 
# Copyright 2008 Steve Langasek 
# Copyright (C) 2009, 2010 Software in the Public Interest
# This file is distributed under the same license as the openldap package.
#
# Changes:
# - Initial translation
# Rudy Godoy , 2006
#
# - Reviewer
# Javier Fernandez-Sanguino
#
# - Updates
# Steve Langasek , 2008
# Francisco Javier Cuadrado , 2009, 2010
# Camaleón , 2014, 2020
#
# 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/coordinacion
# especialmente las notas 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: openldap 2.4.23-3exp1\n"
"Report-Msgid-Bugs-To: openl...@packages.debian.org\n"
"POT-Creation-Date: 2019-10-03 23:01+\n"
"PO-Revision-Date: 2020-04-14 07:14+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../slapd.templates:1001
msgid "Omit OpenLDAP server configuration?"
msgstr "¿Desea omitir la configuración del servidor OpenLDAP?"

#. Type: boolean
#. Description
#: ../slapd.templates:1001
msgid ""
"If you enable this option, no initial configuration or database will be "
"created for you."
msgstr ""
"No se creará la configuración ni la base de datos inicial si habilita esta "
"opción."

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "always"
msgstr "siempre"

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "when needed"
msgstr "cuando se necesite"

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "never"
msgstr "nunca"

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid "Dump databases to file on upgrade:"
msgstr "Volcar las bases de datos a un fichero al actualizar:"

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid ""
"Before upgrading to a new version of the OpenLDAP server, the data from your "
"LDAP directories can be dumped into plain text files in the standard LDAP "
"Data Interchange Format."
msgstr ""
"Antes de que actualice a una nueva versión del servidor OpenLDAP, se puede "
"volcar la información de sus directorios LDAP en ficheros de texto plano en "
"el formato estandarizado «LDAP Data Interchange Format» (formato de "
"intercambio de datos de LDAP)."

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid ""
"Selecting \"always\" will cause the databases to be dumped unconditionally "
"before an upgrade. Selecting \"when needed\" will only dump the database if "
"the new version is incompatible with the old database format and it needs to "
"be reimported. If you select \"never\", no dump will be done."
msgstr ""
"Si selecciona «siempre» se volcarán sus bases de datos de forma "
"incondicional antes de cada actualización. Si selecciona «cuando se "
"necesite» sólo se hará un volcado si la nueva versión es incompatible con el "
"formato de la base de datos antigua y la información se debe volver a "
"importar. Si selecciona «nunca» no se hará ningún volcado."

#. Type: string
#. Description
#: ../slapd.templates:3001
msgid "Directory to use for dumped databases:"
msgstr "Directorio donde volcar las bases de datos:"

#. Type: string
#. Description
#: ../slapd.templates:3001
msgid ""
"Please specify the directory where the LDAP databases will be exported. In "
"this directory, several LDIF files will be created which correspond to the "
"search bases located on the server. Make sure you have enough free space on "
"the partition where the directory is located. The first occurrence of the "
"string \"VERSION\" is replaced with the server version you are upgrading "
"from."
msgstr ""
"Especifique el directorio donde se exportarán las bases de datos de LDAP. En "
"éste se crearán diversos ficheros LDIF que corresponden a las bases de datos "
"ubicadas en el servidor. Asegúrese de que tiene suficiente espacio libre en "
"la partición donde se ubica el directorio. La primera ocurrencia de la "
"cadena «VERSION» se reemplaza con la versión del servidor desde la cual va a "
"actualizar."

#. Type: boolean
#. Description
#: ../slapd.templates:4001
msgid "Move old database?"
msgstr "¿Desea mover la base de datos anti

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

[Camaleón]

Package: bilibop
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# bilibop po-debconf translation to Spanish
# Copyright (C) 2013 Software in the Public Interest
# This file is distributed under the same license as the bilibop package.
# Changes:
# - Initial translation
# Camaleón , 2010, 2013.
# - Updates
# 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: bilibop 0.4.20\n"
"Report-Msgid-Bugs-To: bili...@packages.debian.org\n"
"POT-Creation-Date: 2020-02-08 18:15+\n"
"PO-Revision-Date: 2020-04-14 13:58+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid "Do you intend to install bilibop-rules on a Live System ?"
msgstr "¿Va a instalar bilibop-rules en un sistema «Live»?"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid ""
"Some bilibop-rules settings can be useful on non-volatile Operating Systems, "
"when running from a removable and writable media (USB sticks, external HDD "
"or SD cards); but they are currently useless or even harmful for LiveCD or "
"LiveUSB systems."
msgstr ""
"Algunos de los ajustes de bilibop-rules pueden resultar útiles en sistemas "
"operativos persistentes cuando se ejecutan desde un dispositivo removible y "
"grabable (llaves USB, discos duros externos o tarjetas SD) pero resultan "
"completamente inútiles o incluso perjudiciales en sistemas LiveCD o LiveUSB."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid ""
"If you choose this option, no other question will be asked; bilibop udev "
"rules will be applied but nothing else will be modified on your system. Note "
"that in that case, this package is overkill and you should probably replace "
"it by the lighter but as much as efficient bilibop-udev package."
msgstr ""
"Si elige esta opción no se le harán más preguntas, se aplicarán las reglas "
"udev de bilibop pero no se modificará nada más en su sistema. Tenga en "
"cuenta que en este caso este paquete resulta excesivo y probablemente "
"debería reemplazarlo por otro más ligero pero igual de eficiente como el "
"paquete bilibop-udev."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid "Do you want to use custom bilibop rules and build them now ?"
msgstr "¿Desea utilizar reglas bilibop personalizadas y construirlas ahora?"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid ""
"If tens of removable media are plugged on the computer your system boots "
"from, bilibop udev rules can significantly increase boot time. This can be "
"avoided by using custom udev rules, which are specific to the device your "
"system is installed on."
msgstr ""
"Si tiene conectados varios dispositivos removibles en el equipo desde donde "
"inicia el sistema, las reglas udev de bilibop pueden incrementar "
"significativamente el tiempo de inicio. Para evitar esto puede utilizar "
"reglas udev personalizadas que son específicas para el dispositivo donde se "
"encuentra instalado el sistema."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid ""
"That said, if this device can boot from different hardware port types (as "
"USB/Firewire, USB/eSATA, USB/MMC/SD, etc.), you should check the resulting "
"rules by booting your system on the alternative port type, and if necessary "
"by running 'dpkg-reconfigure bilibop-rules' again with proper options, or "
"even by editing '/etc/udev/rules.d/66-bilibop.rules'."
msgstr ""
"Dicho eso, si el dispositivo puede iniciarse desde distintos tipos de puerto "
"(como USB/Firewire, USB/eSATA, USB/MMC/SD, etc.) debería comprobar las "
"reglas generadas e iniciar el sistema desde uno de los tipos de puerto "
"alternativos y si fuera necesario, ejecutar «dpkg-reconfigure bilibop-rules» "
"de nuevo con las opciones adecuadas o incluso editar el archivo "
"«/etc/udev/rules.d/66-bilibop.rules»."

#. Type: select
#. Choices
#: ../bilibop-rules.templates:3001
msgid "keep existing custom rules"
msgstr "mantener las reglas personalizadas existentes"

#. Type: select
#. Choices
#: ../bi

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

[Camaleón]

Package: neutron
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# neutron po-debconf translation to Spanish
# Copyright (C) 2013 Software in the Public Interest
# This file is distributed under the same license as the neutron package.
# Changes:
# - Initial translation
# Camaleón , 2013, 2015.
# - Updates
# 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: neutron 2015.06.24\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2020-04-13 17:36+\n"
"PO-Revision-Date: 2020-04-14 14:21+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../neutron-common.templates.in:2001
msgid "Manage nova config through debconf?"
msgstr "¿Desea administrar la configuración de Nova a través de debconf?"

#. Type: boolean
#. Description
#: ../neutron-common.templates.in:2001
msgid ""
"Neutron service must contact Nova, and this is configured through the [nova] "
"section of the configuration. Specify if you wish to handle this "
"configuration through debconf."
msgstr ""
"El servicio Neutron debe contactar con Nova, y esto se configura desde la "
"sección «nova» de la configuración. Indique si quiere gestionar esta "
"configuración desde debconf."

#. Type: string
#. Description
#: ../neutron-common.templates.in:3001
msgid "Nova keystone auth URL:"
msgstr "Dirección URL de autenticación del keystone de Nova:"

#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#. Type: password
#. Description
#: ../neutron-common.templates.in:3001 ../neutron-common.templates.in:4001 
#: ../neutron-common.templates.in:5001 ../neutron-common.templates.in:6001 
#: ../neutron-common.templates.in:7001
msgid ""
"Neutron needs to be able to communicate with Nova through Keystone. "
"Therefore Neutron needs to know the Nova admin tenant name, username, "
"password and region."
msgstr ""
"Neutron necesita poder comunicarse con Nova a través de Keystone. Por lo "
"tanto, Neutron necesita saber el identificador del inquilino («tenant») "
"administrador de Nova, el nombre de usuario y la contraseña."

#. Type: string
#. Description
#: ../neutron-common.templates.in:3001
msgid "Please enter the URL of keystone auth_url for Nova."
msgstr ""
"Introduzca la dirección URL de autenticación del keystone (auth_url) de Nova."

#. Type: string
#. Description
#: ../neutron-common.templates.in:4001
msgid "Nova server region name:"
msgstr "Nombre de la región del servidor Nova:"

#. Type: string
#. Description
#: ../neutron-common.templates.in:4001
msgid "Please enter the region of the admin tenant for Nova."
msgstr "Introduzca la región del inquilino («tenant») administrador de Nova."

#. Type: string
#. Description
#: ../neutron-common.templates.in:5001
msgid "Nova admin tenant name:"
msgstr "Nombre del inquilino («tenant») administrador de Nova:"

#. Type: string
#. Description
#: ../neutron-common.templates.in:5001
msgid "Please enter the name of the admin tenant for Nova."
msgstr "Introduzca el nombre del inquilino («tenant») administrador de Nova."

#. Type: string
#. Description
#: ../neutron-common.templates.in:6001
msgid "Nova service username:"
msgstr "Nombre de usuario del servicio Nova:"

#. Type: string
#. Description
#: ../neutron-common.templates.in:6001
msgid "Please enter the username of the admin tenant for Nova."
msgstr ""
"Introduzca el nombre de usuario del inquilino («tenant») administrador de "
"Nova."

#. Type: password
#. Description
#: ../neutron-common.templates.in:7001
msgid "Nova administrator password:"
msgstr "Contraseña del administrador de Nova:"

#. Type: password
#. Description
#: ../neutron-common.templates.in:7001
msgid "Please enter the password of the admin tenat for Nova."
msgstr ""
"Introduzca la contraseña del inquilino («tenant») administrador de Nova."

#. Type: boolean
#. Description
#: ../neutron-metadata-agent.templates:2001
msgid "Manage Neutron metadata config through debconf?"
msgstr ""
"¿Desea administrar la configuración de los metadatos de Neutron a través de "
"debconf?"

#. Type: boolean
#. Descript

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

[Camaleón]

Package: nbd
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# nbd po-debconf translation to Spanish
# Copyright (C) 2010 Software in the Public Interest
# This file is distributed under the same license as the nbd package.
#
# Changes:
# - Initial translation
# Camaleón , 2010, 2015.
#
# - Updates
#
#
# 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: nbd\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2020-04-13 17:34+\n"
"PO-Revision-Date: 2020-04-14 13:55+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: error
#. Description
#: ../nbd-client.templates:2001
msgid "AUTO_GEN is set to \"n\" in /etc/nbd-client"
msgstr "AUTO_GEN está establecido a «n» en «/etc/nbd-client»"

#. Type: error
#. Description
#: ../nbd-client.templates:2001
msgid ""
"The /etc/nbd-client file contains a line that sets the AUTO_GEN variable to "
"\"n\". This indicates that you prefer that the nbd configuration is not "
"automatically generated."
msgstr ""
"El archivo «/etc/nbd-client» contiene una línea que establece la variable "
"AUTO_GEN a «n». Esto significa que prefiere que la configuración de nbd no "
"se genere automáticamente."

#. Type: error
#. Description
#: ../nbd-client.templates:2001
msgid ""
"Since nbd-client 1:3.14-1, the file /etc/nbd-client is no longer used for "
"boot-time configuration; instead, a file /etc/nbdtab is used, with a "
"different format. The debconf configuration options have been removed, and "
"this file is therefore never automatically generated, except that this "
"upgrade would have generated a /etc/nbdtab file from your /etc/nbd-client if "
"AUTO_GEN had not been set to \"n\". As such, you'll need to either disable "
"the AUTO_GEN line in /etc/nbd-client and call `dpkg-reconfigure nbd-client' "
"to allow the configuration to be migrated, or write the nbdtab file yourself "
"manually."
msgstr ""
"A partir de nbd-client 1:3.14-1, ya no se utiliza el archivo «/etc/nbd-"
"client» para la configuración en tiempo de arranque, sino que se utiliza el "
"archivo «/etc/nbdtab», que usa un formato distinto. Se han eliminado las "
"opciones de configuración de debconf y por lo tanto, este archivo nunca se "
"va a generar automáticamente, salvo que esta actualización hubiera generado "
"un archivo «/etc/nbdtab» desde «/etc/nbd-client» si AUTO_GEN no se hubiera "
"establecido a «n». Por lo tanto, tendrá que desactivar la línea AUTO_GEN en "
"«/etc/nbd-client» y ejecutar «dpkg-reconfigure nbd-client» para permitir que "
"se pueda migrar la configuración actual, o bien, editar el archivo nbdtab "
"manualmente."

#. Type: error
#. Description
#: ../nbd-client.templates:2001
msgid ""
"If you do not take either of those steps, your nbd-client boot-time "
"configuration will not be functional."
msgstr ""
"Si no sigue uno de estos pasos, la configuración en tiempo de arranque de "
"nbd-client no será funcional."

#. Type: note
#. Description
#: ../nbd-client.templates:3001
msgid "KILLALL is no longer supported"
msgstr "Ya no se admite KILLALL"

#. Type: note
#. Description
#: ../nbd-client.templates:3001
msgid ""
"You have a file /etc/nbd-client which does not set the shell variable "
"KILLALL to false. Since nbd-client 1:3.14-1, the boot sequence has been "
"changed to use /etc/nbdtab instead of /etc/nbd-client, and this mode of "
"operation no longer supports killing devices that are not specified in "
"nbdtab."
msgstr ""
"Tiene un archivo «/etc/nbd-client» que no establece la variable de la shell "
"KILLALL a «false». Desde nbd-client 1:3.14-1, se ha modificado la secuencia "
"de arranque para utilizar «/etc/nbdtab» en lugar de «/etc/nbd-client», y "
"este modo de operación ya no permite matar a los dispositivos que no se "
"encuentren definidos en nbdtab."

#. Type: note
#. Description
#: ../nbd-client.templates:3001
msgid ""
"Your configuration has been migrated to /etc/nbdtab and the /etc/nbd-client "
"file moved to /etc/nbd-client.old, but please note that you must bring down "
"any devices not specified in /etc/nbdtab manually from now on."
msgstr ""
"La configuración actual 

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

[Camaleón]

Package: kexec-tools
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# kexec-tools po-debconf translation to Spanish
# Copyright (C) 2010 Software in the Public Interest
# This file is distributed under the same license as the kexec-tools package.
#
# Changes:
# - Initial translation
# Camaleón , 2011
#
# - Updates
#
#
# 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: kexec-tools 2.0.2-3\n"
"Report-Msgid-Bugs-To: kexec-to...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-22 17:16-0600\n"
"PO-Revision-Date: 2020-04-14 08:56+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../kexec-tools.templates:2001
msgid "Should kexec-tools handle reboots (sysvinit only)?"
msgstr ""
"¿Debe kexec-tools gestionar los reinicios del sistema (solo para sysvinit)?"

#. Type: boolean
#. Description
#: ../kexec-tools.templates:2001
msgid ""
"If you choose this option, a system reboot will trigger a restart into a "
"kernel loaded by kexec instead of going through the full system boot loader "
"process."
msgstr ""
"Si selecciona esta opción, al reiniciar el sistema se realizará un reinicio "
"en un núcleo cargado por kexec en lugar de iniciar el proceso completo del "
"cargador de arranque del sistema."

#. Type: boolean
#. Description
#: ../kexec-tools.templates:3001
msgid "Read GRUB configuration file to load the kernel?"
msgstr "¿Leer el archivo de configuración de GRUB al cargar el kernel?"

#. Type: boolean
#. Description
#: ../kexec-tools.templates:3001
msgid ""
"If you choose this option, kexec will read the GRUB configuration file to "
"determine which kernel and options to load for kexec reboot, as opposed to "
"what is in /etc/default/kexec."
msgstr ""
"Si selecciona esta opción, kexec leerá el archivo de configuración de GRUB "
"para determinar el kernel y las opciones que se van a cargar al reiniciar "
"kexec, en lugar de obtener los valores desde el archivo «/etc/default/kexec»."

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

[Camaleón]

Package: openstack-pkg-tools
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# openstack-pkg-tools po-debconf translation to Spanish
# Copyright (C) 2010 Software in the Public Interest
# This file is distributed under the same license as the kexec-tools package.
#
# Changes:
# - Initial translation
# Camaleón , 2011
#
# - Updates
#
#
# 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: glance 2012.1-3\n"
"Report-Msgid-Bugs-To: openstack-pkg-to...@packages.debian.org\n"
"POT-Creation-Date: 2019-10-10 18:44+0200\n"
"PO-Revision-Date: 2020-04-14 10:07+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-db.templates:1001
msgid "Set up a database for this package?"
msgstr "¿Desea configurar una base de datos para este paquete?"

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-db.templates:1001
msgid ""
"No database has been set up for this package. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"No se ha configurado ninguna base de datos para este paquete. Antes de "
"continuar debe asegurarse de que dispone de los siguientes datos:"

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-db.templates:1001
msgid ""
" * the type of database that you want to use - generally the MySQL backend\n"
"   (which is compatible with MariaDB) is a good choice, and other\n"
"   implementations like PostgreSQL or SQLite are often problematic with\n"
"   OpenStack (this depends on the service);\n"
" * the database server hostname (that server must allow TCP connections "
"from\n"
"   this machine);\n"
" * a username and password to access the database."
msgstr ""
" * el tipo de base de datos que quiere utilizar; generalmente, el soporte "
"MySQL (que es compatible con MariaDB) es una buena elección, si bien otras "
"opciones como PostgreSQL o SQLite suelen dar problemas con OpenStack, aunque "
"depende del servicio;\n"
" * el nombre del equipo del servidor de la base de datos (el servidor debe "
"permitir conexiones TCP desde este equipo).\n"
" * el nombre de usuario y la contraseña para acceder a la base de datos."

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-db.templates:1001
msgid ""
"Note that if you plan on using a remote database server, you must first "
"configure dbconfig-common to do so (using dpkg-reconfigure dbconfig-common), "
"and the remote database server needs to be configured with adequate "
"credentials."
msgstr ""
"Tenga en cuenta que si tiene pensado utilizar un servidor de base de datos "
"remoto, primero debe configurar «dbconfig-common» para hacerlo (usando «dpkg-"
"reconfigure dbconfig-common»), y necesita configurar el servidor de base de "
"datos remoto con las credenciales adecuadas."

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-db.templates:1001
msgid ""
"If some of these requirements are missing, do not choose this option. Run "
"with regular SQLite support instead."
msgstr ""
"Si no dispone de alguno de estos datos, no elija esta opción. En su lugar, "
"ejecútelo con el soporte habitual de SQLite."

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-db.templates:1001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow\"."
msgstr ""
"Podrá cambiar esta configuración más adelante ejecutando «dpkg-reconfigure -"
"plow»."

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-ksat.templates:1001
msgid "Manage keystone_authtoken with debconf?"
msgstr "¿Desea administrar «keystone_authtoken» con debconf?"

#. Type: boolean
#. Description
#: ../openstack-pkg-tools.configure-ksat.templates:1001
msgid ""
"Every OpenStack service must contact Keystone, and this is configured "
"through the [keystone_authtoken] section of the configuration. Specify if "
"you wish to handle this configuration through debconf."
msgstr ""
"Cada servicio de OpenStack debe contactar con Keystone, y esto se configura "
"desde la sección «keystone_authtoken» de la confi

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

[Camaleón]

Package: apt-listchanges
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# apt-listchanges po-debconf translation to Spanish
# Copyright (C) 2010 Software in the Public Interest
# This file is distributed under the same license as the apt-listdifferences 
package.
#
# Changes:
# - Initial translation
# Camaleón , 2013
#
# - Updates
#
#
# 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: apt-listchanges 2.39\n"
"Report-Msgid-Bugs-To: apt-listchan...@packages.debian.org\n"
"POT-Creation-Date: 2017-11-12 23:48+0100\n"
"PO-Revision-Date: 2020-04-15 14:19+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#: ../templates:2001
msgid "pager"
msgstr "paginador"

#. Type: select
#. Choices
#: ../templates:2001
msgid "browser"
msgstr "navegador"

#. Type: select
#. Choices
#: ../templates:2001
msgid "xterm-pager"
msgstr "paginador-xterm"

#. Type: select
#. Choices
#: ../templates:2001
msgid "xterm-browser"
msgstr "navegador-xterm"

#. Type: select
#. Choices
#: ../templates:2001
msgid "gtk"
msgstr "gtk"

#. Type: select
#. Choices
#. Type: select
#. Choices
#: ../templates:2001 ../templates:4001
msgid "text"
msgstr "texto"

#. Type: select
#. Choices
#: ../templates:2001
msgid "mail"
msgstr "correo"

#. Type: select
#. Choices
#: ../templates:2001
msgid "none"
msgstr "ninguno"

#. Type: select
#. Description
#: ../templates:2002
msgid "Method to be used to display changes:"
msgstr "Método a usar para la visualización de los cambios:"

#. Type: select
#. Description
#: ../templates:2002
msgid ""
"Changes in packages can be displayed in various ways by apt-listchanges:"
msgstr ""
"apt-listchanges puede mostrar los cambios en los paquetes de varias formas:"

#. Type: select
#. Description
#: ../templates:2002
msgid ""
" pager: display changes one page at a time;\n"
" browser  : display HTML-formatted changes using a web browser;\n"
" xterm-pager  : like pager, but in an xterm in the background;\n"
" xterm-browser: like browser, but in an xterm in the background;\n"
" gtk  : display changes in a GTK window;\n"
" text : print changes to the terminal (without pausing);\n"
" mail : only send changes via e-mail;\n"
" none : do not run automatically from APT."
msgstr ""
" paginador   : mostrar los cambios en una página de cada vez,\n"
" navegador   : mostrar los cambios en formato HTML con un navegador,\n"
" paginador-xterm : como paginador, pero en una xterm en segundo plano,\n"
" navegador-xterm : como navegador, pero en una xterm en segundo plano,\n"
" gtk : mostrar los cambios en una ventana GTK,\n"
" texto   : escribir los cambios en la terminal (sin pausas),\n"
" correo  : enviar los cambios sólo por correo,\n"
" ninguno : no ejecutar automáticamente desde APT."

#. Type: select
#. Description
#: ../templates:2002
msgid ""
"This setting can be overridden at execution time. By default, all the "
"options except for 'none' will also send copies by mail."
msgstr ""
"Esta configuración puede cambiarse en tiempo de ejecución. Por defecto todos "
"los métodos excepto «ninguno» enviarán una copia por correo."

#. Type: string
#. Description
#: ../templates:3001
msgid "E-mail address(es) which will receive changes:"
msgstr "Dirección(es) de correo que recibirán los cambios:"

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Optionally, apt-listchanges can e-mail a copy of displayed changes to a "
"specified address."
msgstr ""
"Opcionalmente, apt-listchanges puede enviar una copia de los cambios "
"mostrados a una dirección de correo."

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Multiple addresses may be specified, delimited by commas. Leaving this field "
"empty disables mail notifications."
msgstr ""
"Se pueden especificar múltiples direcciones, separadas por comas. Dejando "
"este campo en blanco deshabilitará las notificaciones por correo."

#. Type: select
#. Choices
#: ../templates:4001
msgid "html"
msgstr "html"

#. Type: select
#. Description
#: ../templates:40

Bug#958876: gnome-shell-extensions: extensions requiring more space only display centre part

[Axel Stammler]

Package: gnome-shell-extensions
Version: 3.30.1-1
Severity: important

Dear Maintainer,

many extensions cannot be used because their output is severly curtailed as 
their width is
reduced to a minimum, cutting off the left and right-hand parts, e.g.:

- Command output
- Ping Indicator
- System-monitor
- Eye

The following extensions are able to have a wider display, i.e. they may 
contain the code
that is needed:

- Open Weather
- Places status indicator
- Removable drive menu
- Clock

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

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

Versions of packages gnome-shell-extensions depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-atk-1.0   2.30.0-2
ii  gir1.2-clutter-1.0   1.26.2+dfsg-10
ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gmenu-3.0 3.31.4-3
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-pango-1.0 1.42.4-7~deb10u1
ii  gnome-session-bin3.30.1-2
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell  3.30.2-11~deb10u1
ii  gvfs 1.38.1-5

Versions of packages gnome-shell-extensions recommends:
ii  gnome-tweaks  3.30.2-1

gnome-shell-extensions suggests no packages.

-- debconf-show failed

Bug#958865: mplayer: theora playback broken: vf_get_image: Assertion `h == -1 || h >= vf->h' failed.

[Stuart Longland]

On 26/4/20 4:03 pm, Jonas Smedegaard wrote:
> MPlayer is no longer developed and largely replaced by mpv.
> 
> I can suggest to try use mpv instead. If you dislike the minimal builtin 
> user interface, then try one of the frontends gnome-mpv or smplayer.
> 
> I can play the above video just fine with mpv, but your problem might be 
> related to other parts of your system (graphics driver, X11 or Wayland 
> setup, etc.).

Right, wasn't aware of mplayer's demise… my use case was to play a
full-screen video without sound as the screen saver… so I have the
following:

stuartl@vk4msl-nb:~$ cat .screensavers/playrandom.sh
#!/bin/bash

if [ -n "$1" ]; then
XSCREENSAVER_WINDOW=$1
fi

exec /usr/bin/mplayer -nosound -fs -really-quiet\
${XSCREENSAVER_WINDOW+-wid} \
$XSCREENSAVER_WINDOW\
-nolirc -nostop-xscreensaver\
-shuffle\
/home/stuartl/.screensavers/*.{mkv,mpeg,mp4}\
/home/stuartl/.screensavers/*/*.{mkv,mpeg,mp4}
stuartl@vk4msl-nb:~$ grep -C 3 playrandom.sh .xscreensaver
textURL:http://planet.debian.org/rss20.xml

programs:
  \
"Random video"
/home/stuartl/.screensavers/playrandom.sh \
  $XSCREENSAVER_WINDOW
\n\
-   maze -root
\n\
- GL:   superquadrics -root
\n\

This works well, with MPEG4 files, it crashes and burns with Ogg/Theora.

I'll have to see if mpv can pull off the same trick as mplayer.

Bug#958865: mplayer: theora playback broken: vf_get_image: Assertion `h == -1 || h >= vf->h' failed.

[Stuart Longland]

On 26/4/20 5:22 pm, Stuart Longland wrote:
> I'll have to see if mpv can pull off the same trick as mplayer.

Turns out it can:

stuartl@vk4msl-nb:~$ cat .screensavers/playrandom.sh
#!/bin/bash

if [ -n "$1" ]; then
XSCREENSAVER_WINDOW=$1
fi

exec /usr/bin/mpv --no-audio --fs --really-quiet\
${XSCREENSAVER_WINDOW+--wid}\
$XSCREENSAVER_WINDOW\
--no-stop-screensaver   \
--shuffle   \
/home/stuartl/.screensavers/*.ogv   \
/home/stuartl/.screensavers/*/*.ogv

and my Ogg/Theora videos play with it… so okay, time to `apt-get purge
mplayer`.

Bug#958877: gnome-shell-extensions: It should be possible to add some extensions to the top bar several times

[Axel Stammler]

Package: gnome-shell-extensions
Version: 3.30.1-1
Severity: minor

Dear Maintainer,

some extensions should be allowed to run and appear in several instances, e.g.:

- Command output
- Iconping for gnome
- Ping indicator

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

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

Versions of packages gnome-shell-extensions depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-atk-1.0   2.30.0-2
ii  gir1.2-clutter-1.0   1.26.2+dfsg-10
ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gmenu-3.0 3.31.4-3
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-pango-1.0 1.42.4-7~deb10u1
ii  gnome-session-bin3.30.1-2
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell  3.30.2-11~deb10u1
ii  gvfs 1.38.1-5

Versions of packages gnome-shell-extensions recommends:
ii  gnome-tweaks  3.30.2-1

gnome-shell-extensions suggests no packages.

-- debconf-show failed

Bug#958878: RM: plasma-mediacenter -- ROM; unmaintained upstream

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove plasma-mediacenter, as it was declared unmaintained
upstream after few years of basically no development.

Thanks,
-- 
Pino

Bug#958879: mplayer: wrong homepage

[Jonas Smedegaard]

Source: mplayer
Version: 2:1.3.0-8
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Homepage is listed as https://www.mplayerhq.hu/ but that site apparently
does not exist.

This site exists and seem correct: https://mplayerhq.hu/

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6lP1gACgkQLHwxRsGg
ASFCnRAAleeIJ3UT8wA23bsreO+O+qezE7eDWnvq3c18k5tb1DR5+1f2uVkiE+Fe
7e1BlzeVIpg6KLeoKUmgx+Sdy5kfTKqyGnz/zqV8RTHyHZv7K0WZ2zdN0Vv2LRNj
WK62RyHBAZJbxje+7Sg1RdRtYZMlS/a0nY0SvFjg+K9acQzwddSslpbyzFs6uCn6
9AvNuRHethS+I/dSrcLiUSwpne95kbTmntK6LyL3tO+ep5fDU6vpXXWVWEDPNUWf
S8alFHJpbJpqvTmtsGUuFl1NyJFlx/PARjH45hBcJ5ldD2gsikpOa3AAslWopTNT
LMzivbyrJmAqndYgyr7QdeOHQMOdleH3E2UjYVA8jzLLpWlMfjzcbBg/RxJuIFgA
u67gNA3lop/wiy24rFTfa8tGOEFBxwtT0659lhBbIwduhPKiBp2kug7N/XGl+FRJ
x3e7TXSFR5nRQloF84KTviu5/IV7OXWi2OxAv5B5NebY0hnWvIxoPxhBLmcq6vdZ
XLq2yd+2BiQ147RoLzkewB8yeI7ZvtYyJvtLPsc1P22zZY5LWZFHbIUwWsngFMuk
ovPexPWgkSPG+RRJKHOqv7phkCgfum3rCOoqvhCAg1UDhUiXrSiGzjkx3Xgt3Aec
H7labuzUTkJksWqjoe50IxKjqD91PgU2rM5Th1dQTDo8XXnuTUI=
=9w9M
-END PGP SIGNATURE-

Bug#958880: mplayer: package neglected

[Jonas Smedegaard]

Source: mplayer
Version: 2:1.3.0-8
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

MPlayer upstream saw no new release for 3 years between 2016 and 2019
and MPlayer in Debian did not yet upgrade to latest release since a year,
which means effectively MPlayer in Debian is 4 years old.

MPlayer is already arguably surpassed by MPV for its playout features,
and ffmpeg arguably surpasses its mencoder transcoding features.
Possibly some users have a specific desire to use MPlayer, but at least
some of our users keep using MPlayer simply because they are unaware of
the existence of MPV, and when pointed out they agree it works better
for them.

Let's not do our users a disservice by shipping an inferior media player.

Please lower or close this bugreport *only* if a) you have compared with
new releases of mpv and ffmpeg that mplayer/mencoder really is still
needed in Debian *AND* your plan to _maintain_ MPlayer in Debian for the
long term (not if you want to help fix a single bug).

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6lRS4ACgkQLHwxRsGg
ASGmRw//VDB3AcKdXO96RJmfM8hKMFHLFQNE1RkXlLnJ8QBqCBpfVLS54UK0079J
gVPp7/aDnXm1M8Esp1ir+dVNvurPyLvsMFQMBDoXVLJgQOXG+o+x4MKVOKsPfh6s
WnTFeegwV0QJIBJ28E/cDvVB2zNW43ZZGJHIRAkobic1oqG5WD+rWBJtgrndW+0b
G7lmN62gWcnePtY5sXFwgzgB9CHVjp3Bkbyk3WVkclrnIcnRFFa5xMJT7441umGf
9tvXwSzVDO4xrHN6SjeSUN/4/k8oNpG47s2x5x7tJ/yTt0DQa3uIMBC2avZuaF+9
ttcmdTjKF8/gs5CLa9tqKUM2sHqknbWC+Q1UTZZuXqAKvdCXdW8ymRYcFSS/HqYU
AmGxkYjWQqXGBHikBbNO8uvtkkqcPwmSNXWlce5XsI6v4jdUUMQ8I2M7f5uwLey2
zWm50ampIgd5QvJmR6nWJ3zCOMQOnzaajRxGE606xSMhnlZ6J0SAe79q40hyO05J
iVvzlyvW4amBaG7As+YeJbp80twRpMGln+SQcAZ8Y+VicBRyaPithAFvUyfgbdLP
LGtEa6tPh0O6/uQICdYxS89hV457TM3QZhbTIcWRbRZhJg9DTWEJXzOKqW8jUgxo
YdNdySDPq/cye8Oxu39w2pTWKbKIP3vijVmq8d/T6tGw78hO/NE=
=SuT/
-END PGP SIGNATURE-

Bug#922211: change required package

[navaneeth]

As mentioned above, libgdk-pixbuf2.0-bin is required for nautilus to
generate thumbnails. Nautilus' requirement for libgdk-pixbuf2.0 should
be updated to libgdk-pixbuf2.0-bin.

Bug#958410: lintian: please warn about about duplicated debhelper build-deps

[Mattia Rizzolo]

On Tue, Apr 21, 2020 at 11:49:09PM +0100, Chris Lamb wrote:
> >  Build-Depends: autoconf-archive,
> > -   debhelper (>= 11),
> > +   debhelper (>= 12),
> > +   debhelper-compat (= 12),
> > libbz2-dev,
> > libtar-dev,
> 
> Interesting, I would have thought debhelper would FTBFS this with:
> 
> dh: warning: Please specify the debhelper compat level exactly once.
> dh: warning:  * debian/compat requests compat 12.
> dh: warning:  * debian/control requests compat 12 via "debhelper-compat 
> (= 12)"
> dh: warning: 
> dh: warning: Hint: If you just added a build-dependency on 
> debhelper-compat, then please remember to remove debian/compat
> dh: warning: 
> dh: error: debhelper compat level specified both in debian/compat and via 
> build-dependency on debhelper-compat

That only happens if you ship d/compat AND have debhelper-compat in the
build-deps.  It is not related to having debhelper in the build-deps.

If fact, there are documented use cases where you *need* have have both
debhelper and debhelper-compat (an example, if you rely on the udeb
auto-detection from dh_makeshlibs 12.3, you need "debhelper-compat (=
12)" AND "debhelper (>= 12.3)" (or just d-copat=13 now…)).

> Alternatively, if the build-profile means that the *debhelper-compat*
> dependency is ignored and there is no debian/compat, would it not mean
> that it would FTBFS with a "no debian/compat file"?

The "extra restrictions (build profiles, etc)" I was referring to is
related to the "debhelper" build-dep, not "debhelper-compat", sorry for
not being precise.
However now, thinking again, I can't think of a good reason to have a
version of debhelper <= of that of debhelper-compat even with a build
profile, I'm not sure what I was thinking about. :3

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#958881: debian-installer: ext4 with no journal is misinterpreted as ext2

[Alan Chandler]

Package: debian-installer
Severity: normal
Tags: d-i

Dear Maintainer,

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

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

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

After a corrupted nvme drive which included my root filesystem as btrfs which
wouldn't repair, I had to re-install (I was on Buster, but have taken the
opportunity to upgrade to Bulleye).

This drive contains a partition which I had formatted as ext4 with no journal
(it is the data directory for a docker install of sql server, so was set that
way as btrds cow settings not appropriate for a database), although I had
forgotten it was ext4 with no journal, and could afford to recreate from
scratch.

So during installation it is reported by partman as ext2, but just failed to
mount.  I assumed it was corrupted as was the rest of the ssd, so I told the
installer to reformat it.

I have a virtual box machine on another SSD, and that too was reported as ext2
but failed to mount.  This drive is more important (it contains a windows 10
installation maintained over a large number of years) and so I just told the
installer to forget it.

Now I have a working system and come to mount it, I had incorrectly added it to
/etc/fstab as ext2 and it was failing to mount.  However a manual mount without
specifying the file system type (sudo mount /dev/sdb1 /home/alan/vbox ) made it
work

But now I could examine the failure message and realise its an ext4 without
journal and that is why its not mounting /etc/fstab.




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

Kernel: Linux 5.5.0-2-amd64 (SMP w/12 CPU cores)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#956694: purify: FTBFS with spdlog 1.5.0

[Ole Streicher]

Control: affects -1 src:purify

This now also affects the "purify" package, which is supposed to be
rebuilt during the auto-casacore transition.

Bug#958882: hplip: plugins remain unconfigured after installation

[Matthias Brennwald]

Package: hplip
Version: 3.20.3+dfsg0-2
Severity: normal

Dear Maintainer,

After installing hplip, (some?) plugins remain unconfigured. For instance,
using the built-in scanner of my printer does not work without configuration of
the corresponding plugin. I had to execute the following to make the scanner /
plugin work correctly:

sudo /usr/bin/hp-plugin



-- Package-specific info:
Saving output in log file: /home/mbrennwa/hp-check.log

HP Linux Imaging and Printing System (ver. 3.20.3)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before  
compiling the HPLIP supplied tarball (.tar.gz or .run) to determine 
if the proper dependencies are installed to successfully compile
HPLIP.  
2. Run-time check mode (-r or --run): Use this mode to determine if 
a distro supplied package (.deb, .rpm, etc) or an already built 
HPLIP supplied tarball has the proper dependencies installed to 
successfully run.   
3. Both compile- and run-time check mode (-b or --both) (Default):  
This mode will check both of the above cases (both compile- and 
run-time dependencies). 

Check types:
a. EXTERNALDEP - External Dependencies  
b. GENERALDEP - General Dependencies (required both at compile and  
run time)   
c. COMPILEDEP - Compile time Dependencies   
d. [All are run-time checks]
PYEXT SCANCONF QUEUES PERMISSION

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

warning: debian-testing version is not supported. Using debian-10.2 versions 
dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 5.5.0-1-amd64 #1 SMP Debian 5.5.13-2 (2020-03-30) GNU/Linux
 Host: espresso
 Proc: 5.5.0-1-amd64 #1 SMP Debian 5.5.13-2 (2020-03-30) GNU/Linux
 Distribution: debian testing
 Bitness: 64 bit


---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.20.3
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian 
distro  testing version 

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.20.3

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=no
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=no
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.20.3
restricted-build=no
ui-toolkit=qt5
qt3=no
qt4=no
qt5=yes
policy-kit=yes
lite-build=no
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
apparmor_build=no
class-driver=no


Current contents of '/var/lib/hp/hplip.state' file:
[plugin]
installed = 1
eula = 1
version = 3.20.3



Current contents of '~/.hplip/hplip.conf' file:
[installation]
date_time = 04/26/20 10:49:05
version = 3.20.3


 


-
| External Dependencies |
-

 error: cups  CUPS - Common Unix Printing System
   REQUIRED1.1 -   INCOMPAT   'CUPS may not be 
installed or not running'
 gs   GhostScript - PostScript and PDF language interpreter and 
previewer REQUIRED7.059.52OK -
 error: xsane xsane - Graphical scanner frontend for SANE   
   OPTIONAL0.9 -   MISSING'xsane needs to 
be installed'
 scanimagescanimage - Shell scanning program
   OPTIONAL1.0 1.0.27  OK -
 error: dbus  DBus - Message bus system 
   REQUIRED-   1.12.16 MISSING'DBUS may not be 
installed or not running'
 policykit 

Bug#958884: keepassxc: KeePassXC prevent KDE shutdown when "Minimize instead of app exit" option is enabled

[Olivier]

Package: keepassxc
Version: 2.4.3+dfsg.1-1+b1
Severity: normal
Tags: upstream

Dear Maintainer,

issue occur with KDE desktop. When I request a reboot or shutdown computer, a
pop-up appear who tell that KeePassXC has block action.

According to https://github.com/keepassxreboot/keepassxc/issues/2692 , this is
a known issue, look like fixed into 2.5.2:


However, after 2.5.2 came out, I decided to check if this issue was fixed in
the official version, and I can no longer replicate it. I don't know what
changed, whether KeePassXC, Qt, systemd or something else, but the problem I
had doesn't happen anymore.


There is a workaround : Disable "Minimize instead of app exit" option. In this
case, KeePassXC does not prevent KDE shutdown.

Recommandation : Upgrade to current upstream version (today, this 2.5.4).

Thanks for your support !

Best regards,
 Olivier




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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages keepassxc depends on:
ii  libargon2-10~20171227-0.2
ii  libc6  2.30-4
ii  libgcrypt201.8.5-5
ii  libqrencode4   4.0.2-2
ii  libqt5concurrent5  5.12.5+dfsg-10
ii  libqt5core5a   5.12.5+dfsg-10
ii  libqt5dbus55.12.5+dfsg-10
ii  libqt5gui5 5.12.5+dfsg-10
ii  libqt5network5 5.12.5+dfsg-10
ii  libqt5svg5 5.12.5-2
ii  libqt5widgets5 5.12.5+dfsg-10
ii  libqt5x11extras5   5.12.5-1
ii  libsodium231.0.18-1
ii  libstdc++6 10-20200418-1
ii  libx11-6   2:1.6.9-2
ii  libxi6 2:1.7.9-1
ii  libxtst6   2:1.2.3-1
ii  libykpers-1-1  1.20.0-2
ii  libzxcvbn0 2.4+dfsg-2
ii  zlib1g 1:1.2.11.dfsg-2

keepassxc recommends no packages.

keepassxc suggests no packages.

-- no debconf information

Bug#958883: unattended-upgrades: consumes 100% cpu over a long period (more then half an hour) doing nothing

[Maurizio Di Pietro]

Package: unattended-upgrades
Version: 2.3
Severity: important

Dear Maintainer,

after latest system upgrade , i noticed this behavior.
In the bugtracker i noticed there was a similar behavior described in

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

but it had been fixed. Maybe a regression.

Thanks


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

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.8.2-3
ii  python3-apt2.1.1
ii  python3-dbus   1.2.16-2
ii  python3-distro-info0.23
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-29
ii  cron [cron-daemon]  3.0pl1-136
ii  systemd-sysv245.5-1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1+b1
ii  exim4-daemon-light [mail-transport-agent]  4.93-14
ii  needrestart3.5-1
ii  powermgmt-base 1.36
ii  python3-gi 3.36.0-3

-- debconf information:
  unattended-upgrades/enable_auto_updates: true
  unattended-upgrades/origins_pattern: 
"origin=Debian,codename=${distro_codename},label=Debian-Security";

Bug#958243: Use system libinih-dev

[Andreas Metzler]

Control: tags -1 moreinfo

On 2020-04-20 Yangfl  wrote:
> Source: gnutls28
> Severity: wishlist

> Hi,

> As libinih-dev is now available, please consider linking against
> system library instead of bundled ini.c.


Hello,

Afaict libinih/upstream does not provide a shared library, the Debian
package is patched to build one. However inih does not seem to be
designed as a shared library. It is build-time configured by setting
#defines. The inih Debian patch changes/extends this:

--- a/ini.h
+++ b/ini.h
 /* Maximum line length for any line in INI file (stack or heap). Note that
this must be 3 more than the longest line (due to '\r', '\n', and '\0'). */
 #ifndef INI_MAX_LINE
 #define INI_MAX_LINE 200
 #endif
+extern int ini_max_line;
--- a/ini.c
+++ b/ini.c
+int ini_max_line = INI_MAX_LINE;
[...]

Afaict when linking /statically/ the old '#define INI_MAX_LINE 666' in
config.h would continue to work even with the patched version but would
be ignored if linking dynamically. Gnutls would need to set the global
variable 'ini_max_line = 666' instead. (Isn't this going to break when gnutls
sets 'ini_max_line = 666' and another program using both gnutls and inih
sets/wants 'ini_max_line = 50' instead?)

So linking gnutls against libinih-dev dynamically would require source
changes which are not upstreamable because inih/shared is a Debian fork.

cu Andreas

Bug#958853: anki: Upstream new version

[Julian Gilbey]

On Sat, Apr 25, 2020 at 10:15:55PM +0200, Alberto Fuentes wrote:
> Package: anki
> Version: 2.1.15+dfsg-1
> Severity: wishlist
> 
> Upstream version is 2.1.22. Almost 9 months of fixes :)
> 
> Cheers!

Hi Alberto,

Since the latest version in Debian, upstream have started using Rust
as part of the Anki package.  They are also now building Anki using
their own Rust program (called maturin).  This is making packaging the
newer releases for Debian significantly challenging, as it require
liaising with the Rust team and learning a whole new packaging
environment.  Rust has lots of little modules ("crates"), each of
which is packaged separately, and the version dependencies are pretty
horrendous.  I spent a day a couple of weeks ago trying to figure it
all out, and learnt lots.  But it's probably most of a week's work to
get the whole thing to work, and I haven't yet had the time to do
this.

If you're able to help, it would be hugely appreciated!

Best wishes,

   Julian

Bug#958885: RFS: xine-lib-1.2/1.2.10-1 [QA] -- xine media player library

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xine-lib-1.2"

 * Package name: xine-lib-1.2
   Version : 1.2.10-1
   Upstream Author :
 * URL : http://xine-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/xine-lib-1.2
   Section : libs

It builds those binary packages:

  libxine2   - xine media player library – metapackage
   libxine2-all-plugins - xine video/media player library ‒ metapackage
for all plugins
   libxine2-bin - xine video/media player library – binary files
   libxine2-console - libaa/libcaca/framebuffer/directfb related plugins
for libxine2
   libxine2-dev - xine video player library – development packages
   libxine2-doc - xine video player library – documentation files
   libxine2-ffmpeg - MPEG-related plugins for libxine2
   libxine2-gnome - GNOME-related plugins for libxine2
   libxine2-misc-plugins - Input, audio output and post plugins for libxine2
   libxine2-plugins - xine video/media player library ‒ metapackage for
commonly-used p
   libxine2-vdr - VDR-related plugins for libxine2
   libxine2-x - X desktop video output plugins for libxine2

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

  https://mentors.debian.net/package/xine-lib-1.2

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

  dget -x
https://mentors.debian.net/debian/pool/main/x/xine-lib-1.2/xine-lib-1.2_1.2.10-1.dsc

Changes since the last upload:

   * QA upload.
   [ Ondřej Nový ]
   * d/watch: Use https protocol
 .
   [ Håvard Flaget Aasen ]
   * New upstream version
   * Add 0001-Fix-ftbfs-with-gcc-10.patch closes: #957982
   * Update Standards-Version to 4.5.0
   * Change to debhelper-compat
   * Remove override_dh_installchangelogs
   * Add Build-Depends-Field to *.symbols file
   * Update symbols in *.symbols file
   * Update path to mime.types in d/not-installed
   * debian/*.install
 - Update after joining 3 video plugins
 - Add libpng decoder
 - Add OpenGL, EGL and Wayland support

The distribution is set to unstable, I'm not sure if it should go into
experimental first.

Regards,
Håvard

Bug#958886: xca: OID LN differs warning popups at startup

[Sander van Grieken]

Package: xca
Version: 2.2.1-1
Severity: normal

XCA shipped oids.txt mismatches against openssl defined OIDs, causing two
popups to appear at application startup.

Warnings are also output on console:

   0.00 Warning: OID:  "1.3.6.1.4.1.311.20.2.3" LN differs:  "Microsoft
Universal Principal Name"   Microsoft User Principal Name
   2.02 Warning: OID:  "1.3.6.1.4.1.311.20.2.2" LN differs:  "Microsoft
Smartcardlogin"   Microsoft Smartcard Login




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

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

Versions of packages xca depends on:
ii  libc6  2.30-4
ii  libgcc-s1  10-20200418-1
ii  libltdl7   2.4.6-14
ii  libqt5core5a   5.12.5+dfsg-10
ii  libqt5gui5 5.12.5+dfsg-10
ii  libqt5sql5 5.12.5+dfsg-10
ii  libqt5sql5-sqlite  5.12.5+dfsg-10
ii  libqt5widgets5 5.12.5+dfsg-10
ii  libssl1.1  1.1.1g-1
ii  libstdc++6 10-20200418-1

Versions of packages xca recommends:
ii  libqt5sql5-mysql   5.12.5+dfsg-10
pn  libqt5sql5-postgresql  

xca suggests no packages.

-- no debconf information

Bug#958663: libghc-hs-bibutils-dev: FTBFS with new libbibutils7 (library transition)

[Pierre Gruet]

Control: severity 958663 serious

Hi,

The transition of libbibutils6 to libbibutils7 has begun as the new library
is now in unstable.

The package can now be updated with the new upstream or the patch enclosed
to my initial message

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958663#5


Bye,
Pierre

Bug#958887: buster-pu: package purple-discord/0.9.2019.02.07.git.e5d9627-1

[Paul Wise]

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

A change to the Discord service causes crashes in purple-discord. There
is a workaround for this issue in unstable that I would like to have in Debian 
buster. I have uploaded the package to Debian buster just now and I attach the 
debdiff for review.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
diff -Nru purple-discord-0.9.2019.02.07.git.e5d9627/debian/changelog purple-discord-0.9.2019.02.07.git.e5d9627/debian/changelog
--- purple-discord-0.9.2019.02.07.git.e5d9627/debian/changelog	2019-02-09 10:54:10.0 +0800
+++ purple-discord-0.9.2019.02.07.git.e5d9627/debian/changelog	2020-04-26 17:47:55.0 +0800
@@ -1,3 +1,9 @@
+purple-discord (0.9.2019.02.07.git.e5d9627-1+deb10u1) buster; urgency=medium
+
+  * Backport workaround for crashes in ssl_nss_read (Closes: #955635)
+
+ -- Paul Wise   Sun, 26 Apr 2020 17:47:55 +0800
+
 purple-discord (0.9.2019.02.07.git.e5d9627-1) unstable; urgency=medium
 
   * New upstream snapshot
diff -Nru purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/series purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/series
--- purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/series	1970-01-01 08:00:00.0 +0800
+++ purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/series	2020-04-26 17:47:55.0 +0800
@@ -0,0 +1 @@
+workaround-ssl_nss_read-crashes.patch
diff -Nru purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/workaround-ssl_nss_read-crashes.patch purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/workaround-ssl_nss_read-crashes.patch
--- purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/workaround-ssl_nss_read-crashes.patch	1970-01-01 08:00:00.0 +0800
+++ purple-discord-0.9.2019.02.07.git.e5d9627/debian/patches/workaround-ssl_nss_read-crashes.patch	2020-04-26 17:47:55.0 +0800
@@ -0,0 +1,18 @@
+Description: Wrap all purple_ssl_read's to prevent segfaults elsewhere
+Origin: https://github.com/EionRobb/purple-discord/compare/4e71974...db7dc79.diff
+Bug: https://github.com/EionRobb/purple-discord/issues/288
+Bug-Debian: https://bugs.debian.org/955635
+Author: Eion Robb 
+Applied-Upstream: yes
+--- a/libdiscord.c
 b/libdiscord.c
+@@ -50,6 +50,9 @@
+ 
+ #include "markdown.h"
+ 
++// Prevent segfault in libpurple ssl plugins
++#define purple_ssl_read(a, b, c)  ((a) && (a)->private_data ? purple_ssl_read((a), (b), (c)) : 0)
++
+ #define DISCORD_PLUGIN_ID "prpl-eionrobb-discord"
+ #ifndef DISCORD_PLUGIN_VERSION
+ #define DISCORD_PLUGIN_VERSION "0.1"


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

Bug#958889: ITP: gnome-passwordsafe -- A password manager for GNOME

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 

* Package name: gnome-passwordsafe
  Version : 3.99.2
  Upstream Author : Falk Alexander Seidl , Uta Lemke
* URL : https://gitlab.gnome.org/World/PasswordSafe
* License : GPL
  Programming Lang: Python
  Description : A password manager for GNOME

Password Safe is a password manager which makes use of the KeePass v.4 format.
It integrates perfectly with the GNOME desktop and provides an easy and 
uncluttered interface for the management of password databases.

Bug#958888: ITP: pytorch -- Tensors and Dynamic neural networks in Python with strong GPU acceleration

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: pytorch
* URL : https://github.com/pytorch/pytorch
* License : BSD-3
  Programming Lang: C++, python
  Description : Tensors and Dynamic neural networks in Python with strong 
GPU acceleration

One of the top-2 deep learning frameworks

I've uploaded all the necessary build dependencies to the NEW queue.
Now I'm waiting for the upstream to merge my pull requests.

will be maintained under Debian Deep Learning Team

Bug#958891: ITP: pytorch-text -- Data loaders and abstractions for text and NLP

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: pytorch-text
* URL : https://github.com/pytorch/text
* License : bsd-3
  Programming Lang: py
  Description : Data loaders and abstractions for text and NLP

allows users to better manipulate textual data using pytorch

debian deep learning team

Bug#958890: ITP: pytorch-audio -- Data manipulation and transformation for audio signal processing, powered by PyTorch

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: pytorch-audio
* URL : https://github.com/pytorch/audio
* License : bsd-2
  Programming Lang: py
  Description : Data manipulation and transformation for audio signal 
processing, powered by PyTorch

enables user to manipulate audio data using pytorch
debian deep learning team

Bug#958883: unattended-upgrades: consumes 100% cpu over a long period (more then half an hour) doing nothing

[Bálint Réczey]

Control: block -1 by 711128
Control: tags -1 confirmed moreinfo

Hi Maurizio,

Maurizio Di Pietro  ezt írta (időpont: 2020. ápr.
26., V, 10:57):
>
> Package: unattended-upgrades
> Version: 2.3
> Severity: important
>
> Dear Maintainer,
>
> after latest system upgrade , i noticed this behavior.
> In the bugtracker i noticed there was a similar behavior described in
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899366
>
> but it had been fixed. Maybe a regression.

Unattended-upgrades 1.18 attempted to fully rely on APT's resolver for
upgrades, but unfortunately APT's resolver can't always find the
solution.
Unattended-upgrades thus tries to work around APT's resolver's failure
and falls back to adjusting package dependencies which can take long
if there are many upgradable/broken packages and this situation can
occur frequently in unstable.

Please attach the output of unattended-upgrades -d -v to see if u-u
spends its time in adjusting packages to help APT's resolver.

Thanks,
Balint

> Thanks
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages unattended-upgrades depends on:
> ii  debconf [debconf-2.0]  1.5.74
> ii  lsb-base   11.1.0
> ii  lsb-release11.1.0
> ii  python33.8.2-3
> ii  python3-apt2.1.1
> ii  python3-dbus   1.2.16-2
> ii  python3-distro-info0.23
> ii  ucf3.0038+nmu1
> ii  xz-utils   5.2.4-1+b1
>
> Versions of packages unattended-upgrades recommends:
> ii  anacron 2.3-29
> ii  cron [cron-daemon]  3.0pl1-136
> ii  systemd-sysv245.5-1
>
> Versions of packages unattended-upgrades suggests:
> ii  bsd-mailx  8.1.2-0.20180807cvs-1+b1
> ii  exim4-daemon-light [mail-transport-agent]  4.93-14
> ii  needrestart3.5-1
> ii  powermgmt-base 1.36
> ii  python3-gi 3.36.0-3
>
> -- debconf information:
>   unattended-upgrades/enable_auto_updates: true
>   unattended-upgrades/origins_pattern: 
> "origin=Debian,codename=${distro_codename},label=Debian-Security";
>

Bug#958892: ITP: pytorch-vision -- Datasets, Transforms and Models specific to Computer Vision

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: pytorch-vision
* URL : https://github.com/pytorch/vision
* License : BSD-3
  Programming Lang: C++,py
  Description : Datasets, Transforms and Models specific to Computer Vision

a very important extra module for pytorch users
debian deep learning team

Bug#958893: ITP: pytorch-ignite -- High-level library to help with training neural networks in PyTorch

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: pytorch-ignite
* URL : https://github.com/pytorch/ignite
* License : BSD-3
  Programming Lang: py
  Description : High-level library to help with training neural networks in 
PyTorch

make pytorch even easier to use
debian deep learning team

Bug#948333: buster-pu: package frr/6.0.2-2

[Thomas Goirand]

On 4/25/20 9:05 PM, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, 2020-01-07 at 14:05 +0100, Thomas Goirand wrote:
>> On 1/7/20 2:01 PM, Thomas Goirand wrote:
>>> As per the issue described here:
>>> https://github.com/FRRouting/frr/issues/3251
>>>
>>> extended next hop capability does not work in Debian Buster.
>>> As a consequence, we aren't able to advertize for an IP
>>> address on our local loopback through the IPv6 link local,
>>> which is how we would like to do BGP to the host.
>>>
>>> Note that this issue is from version 5.0.1 up to version
>>> 7.2 (which is in Sid), so I took the time to cherry-pick the
>>> fix from upstream. I have attached the resulting debdiff, and
>>> opened the bug against the frr package itself.
> [...]
>> FYI, frr bug number is:
>> https://bugs.debian.org/cgi-bin/948332
> 
> Apologies for the delay in getting back to you.
> 
> The description above, and the metadata on the referenced bug report,
> suggest that the issue still affects the package in unstable. Is that
> correct?
> 
> Regards,
> 
> Adam

It's not correct. The version in unstable, 7.2.1, contains the upstream
fix for this problem.

Cheers,

Thomas Goirand (zigo)

Bug#948322: mirror submission for web04.infania.net

[Mattias Björlin]

Hey

 

I have changed the address to ftpmirror1.infania.net
like
http://ftpmirror1.infania.net/debian/project/trace/ftpmirror1.infania.net

But i cant add that address either

/Mattias

 

On Mon, 20 Apr 2020 16:45:38 +0200 Julien Cristau 
wrote: 
> Control: tag -1 moreinfo 
> 
> On Tue, Jan 07, 2020 at 10:55:14AM +, FTP Admins wrote: 
> > Trace Url:

http://web04.infania.net/debian/project/trace/web04.infania.net 
> 
> Hi, 
> 
> the above URL (which we use to monitor Debian mirrors) does not exist. 
> If you wish your mirror to be listed under that name in the mirror list, 
> you may need to set MIRRORNAME in the ftpsync config, to have the trace 
> file named accordingly. 
> 
> Cheers, 
> Julien 
> 
> 

Bug#958876: gnome-shell-extensions: extensions requiring more space only display centre part

[Simon McVittie]

On Sun, 26 Apr 2020 at 09:26:21 +0200, Axel Stammler wrote:
> many extensions cannot be used because their output is severly curtailed as 
> their width is
> reduced to a minimum, cutting off the left and right-hand parts, e.g.:
> 
> - Command output
> - Ping Indicator
> - System-monitor
> - Eye

The gnome-shell-extensions package contains a specific collection of
extensions that are released together with GNOME, and is not a generic
place to report bugs in unrelated extensions. None of those extensions
seem to be part of gnome-shell-extensions, so please report this as a
bug in the extensions that have the issue instead.

Some extensions are available as individual packages in Debian, for
example gnome-shell-extension-system-monitor. The other extensions you
named only seem to be available outside Debian.

If you installed them as Debian packages, please report bugs in those
Debian packages. If you installed them from extensions.gnome.org using
chrome-gnome-shell, please report the bugs to the extensions' upstream
developers, specifying the version of GNOME Shell you are using (which
is 3.30.2).

The extensions in the gnome-shell-extensions package are:

- Applications menu
- Auto-move windows
- Removable drive menu
- Horizontal workspaces
- Launch new instance
- Native window placement
- Places status indicator (places menu)
- Screenshot window sizer
- User themes
- Window list
- Window navigator
- Workspace indicator

Bugs in those extensions are appropriate to report against the
gnome-shell-extensions package.

Thanks,
smcv

Bug#958894: grub-efi-amd64-bin: Secure Boot forbids loading module from .../multiboot.mod

[Fabian Greffrath]

Package: grub-efi-amd64-bin
Version: 2.04-7
Severity: important

Hi,

GRUB currently fails to load the Invaders game from the grub-invaders
package, Instead, it shows an error message stating

Fehler: Secure Boot forbids loading module from
(hd0,gpt5)/boot/grub/x86_64-efi/multiboot.mod

If multoboot is forbidden with Secure Boot enabled, grub-invaders is
most likely not the only "kernel" that GRUB will be unable to Boot.

Cheers,

 - Fabian


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
7403c6c5-930a-4efe-bf43-130f005cf9a5
else
  search --no-floppy --fs-uuid --set=root 7403c6c5-930a-4efe-bf43-130f005cf9a5
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=de_DE
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
7403c6c5-930a-4efe-bf43-130f005cf9a5
else
  search --no-floppy --fs-uuid --set=root 7403c6c5-930a-4efe-bf43-130f005cf9a5
fi
insmod png
if background_image 
/usr/share/desktop-base/futureprototype-theme/grub/grub-16x9.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-7403c6c5-930a-4efe-bf43-130f005cf9a5' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 
--hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  
7403c6c5-930a-4efe-bf43-130f005cf9a5
else
  search --no-floppy --fs-uuid --set=root 
7403c6c5-930a-4efe-bf43-130f005cf9a5
fi
echo'Loading Linux 5.5.0-1-amd64 ...'
linux   /boot/vmlinuz-5.5.0-1-amd64 
root=UUID=7403c6c5-930a-4efe-bf43-130f005cf9a5 ro  quiet splash
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-5.5.0-1-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-7403c6c5-930a-4efe-bf43-130f005cf9a5' {
menuentry 'Debian GNU/Linux, with Linux 5.5.0-1-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-5.5.0-1-amd64-advanced-7403c6c5-930a-4efe-bf43-130f005cf9a5' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
  

Bug#958895: libevhtp-dev: libtool arguments failure

[Alexandre Rossi]

Package: libevhtp-dev
Version: 1.2.18-1
Severity: important

Dear Maintainer,

My build fails with:

/bin/bash ../libtool  --tag=CC   --mode=link gcc 
-DPKGDATADIR=\"/usr/share/seafile\" -DPACKAGE_DATA_DIR=\""/usr/share/seafile"\" 
-DSEAFILE_SERVER -DFULL_FEATURE -I../include -I../lib -I../lib -I../common 
-pthread -I/build/ccnet-server-mgBlKx/ccnet-server-7.1.3/debian/tmp/usr/include 
-I/usr/include/searpc -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread 
-I/usr/include/searpc -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/evhtp -Wall -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -o seaf-server seaf-server.o 
web-accesstoken-mgr.o seafile-session.o zip-download-mgr.o index-blocks-mgr.o 
share-mgr.o passwd-mgr.o quota-mgr.o repo-op.o repo-perm.o size-sched.o 
virtual-repo.o copy-mgr.o http-server.o upload-file.o access-file.o pack-dir.o 
fileserver-config.o seaf-db.o branch-mgr.o fs-mgr.o config-mgr.o repo-mgr.o 
commit-mgr.o log.o object-list.o rpc-service.o vc-common.o seaf-utils.o 
obj-store.o obj-backend-fs.o seafile-crypt.o diff-simple.o mq-mgr.o block-mgr.o 
block-backend.o block-backend-fs.o merge-new.o block-tx-utils.o 
-L/build/ccnet-server-mgBlKx/ccnet-server-7.1.3/debian/tmp/usr/lib/x86_64-linux-gnu
 -lccnet -lsearpc -lgio-2.0 -lgobject-2.0 -lglib-2.0 -ljansson -levent -luuid 
-lgobject-2.0 -lglib-2.0 ../lib/libseafile_common.la -lonig -lglib-2.0 
-lgobject-2.0 -lglib-2.0 -lssl -lcrypto  -luuid -lsqlite3 -levent -L -levhtp 
../common/cdc/libcdc.la -lsearpc -lgio-2.0 -lgobject-2.0 -lglib-2.0 -ljansson 
-ljansson  -lz -larchive -L/usr/lib/x86_64-linux-gnu/ -lmariadb -lsqlite3
libtool:   error: require no space between '-L' and '-levhtp'

It appears that $libdir is empty:

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/evhtp.pc
prefix=/usr
libdir=
includedir=/evhtp

Name: libevhtp
Description: A more flexible replacement for libevent's httpd API
Version: 1.2.18
Libs: -L${libdir} -levhtp
Libs.private: 
/usr/lib/x86_64-linux-gnu/libevent.so;/usr/lib/x86_64-linux-gnu/libevent_openssl.so;/usr/lib/x86_64-linux-gnu/libevent_core.so;/usr/lib/x86_64-linux-gnu/libevent_extra.so;/usr/lib/x86_64-linux-gnu/libevent_pthreads.so;/usr/lib/x86_64-linux-gnu/libevent_extra.so;OpenSSL::SSL;OpenSSL::Crypto;Threads::Threads;/usr/lib/x86_64-linux-gnu/libonig.so
Cflags: -I${includedir}

which would explain the problem. In buster, libdir=/usr/lib .

Thanks,

Alex


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libevhtp-dev depends on:
ii  libevhtp01.2.18-1
ii  libonig-dev  6.9.5-1

libevhtp-dev recommends no packages.

Versions of packages libevhtp-dev suggests:
pn  libevhtp-doc  

-- no debconf information

Bug#958896: b4: new upstream version v0.4.0 available

[Salvatore Bonaccorso]

Source: b4
Severity: wishlist

Hi Héctor,

There is a new b4 upstream version (v0.4.0) released which contains
several bugfixes and new subcommands.

Regards,
Salvatore

Bug#958894: grub-efi-amd64-bin: Secure Boot forbids loading module from .../multiboot.mod

[Steve McIntyre]

Hi Fabian,

On Sun, Apr 26, 2020 at 01:37:33PM +0200, Fabian Greffrath wrote:
>Package: grub-efi-amd64-bin
>Version: 2.04-7
>Severity: important
>
>Hi,
>
>GRUB currently fails to load the Invaders game from the grub-invaders
>package, Instead, it shows an error message stating
>
>Fehler: Secure Boot forbids loading module from
>(hd0,gpt5)/boot/grub/x86_64-efi/multiboot.mod
>
>If multoboot is forbidden with Secure Boot enabled, grub-invaders is
>most likely not the only "kernel" that GRUB will be unable to Boot.

If you want to use grub-invaders or some of the other more esoteric
grub features, then you'll have to disable Secure Boot. Have you tried
that?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#958897: ITP: mobile-datovka -- Czech Data Boxes client

[David Heidelberg]

Package: wnpp
Severity: wishlist
Owner: David Heidelberg 

* Package name: mobile-datovka
  Version : 1.9.1
  Upstream Author : Karel Slaný 
* URL : https://www.datovka.cz/cs/pages/mobilni-datovka.html
* License : GPL-3.0-or-later, CC0-1.0
  Programming Lang: C++
  Description : A free graphical user interface for data boxes

Datovka is a multiplatform mobile application for accessing data boxes.
A data box is an electronic storage site in Czech Republic. It is intended
for delivery of official documents and for communication with public
authority bodies.

I'm looking for sponsor, preferably someone from Mobile team (since it's
mobile application).

Bug#958895: libevhtp-dev: libtool arguments failure

[Vincent Bernat]

Control: forwarded -1 https://github.com/criticalstack/libevhtp/pull/143
Control: block -1 by 958467

<#secure method=pgpmime mode=sign>
 ❦ 26 avril 2020 13:45 +02, Alexandre Rossi:

> It appears that $libdir is empty:
>
> $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/evhtp.pc
> prefix=/usr
> libdir=
> includedir=/evhtp

There is proposed patch upstream:
. Not merged yet.
Unfortunately, I cannot upload a fix yet as libonig-dev dropped
onigposix.h header. It's
.
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#903115: msttcorefonts: Debian package source repository links are all 404 not found

[Thijs Kinkhorst]

Hi Laurence,

Thanks for the feedback.

On Fri, July 6, 2018 12:47, Laurence Alexander Hurst wrote:
>* What led up to the situation?
> I've been asked to install this on a business system, so was trying to
> find licence terms for the fonts to see if I can, legally, before
> proceeding.  The copyright files says to see READ_ME!.gz but that does not
> appear to be in the package or the source tarball, so I was trying to go
> upstream but the upstream sources are all 404.

The file is installed on your system after installation indeed. As you
might have noticed, the package is rather special in that it needs to
download de fonts and then extract the .exe's they're contained in, for
license reasons.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Looked in sources for file referred to in 'copyright' file.  It did not
> exist, so tried to go upstream and discovered upstream 404s.
>
>* What was the outcome of this action?
> 404 not found

I don't think there's an URL in the package I could update.

However, the project's URL still exists here:
http://corefonts.sourceforge.net/


Kind regards,
Thijs

Bug#958898: keepalived: Using keepalived on Debian 10 with SMTP notifications enabled results in a segfault

[William Edwards]

Package: keepalived
Version: 2.0.10-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Some machines running Debian 9 have been upgraded to Debian 10. After upgrading 
to Debian 10, Keepalived would segfault on startup.

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

I have found the problem to be 'resolved' when removing the `smtp_server` 
directive.

After debugging, I found a commit fixing this (GitHub commit: fccdeba) merged 
into Keepalived version 2.0.11.

Keepalived 2.0.11 is not available in the repos yet, while Keepalived is now 
'broken' for many users with quite a standard setup.

I think it would be wise to backport this commit into the currently available 
Keepalived package for Debian 10.

Bug#958894: grub-efi-amd64-bin: Secure Boot forbids loading module from .../multiboot.mod

[Fabian Greffrath]

Hi Steve,

Am Sonntag, den 26.04.2020, 13:01 +0100 schrieb Steve McIntyre:
> If you want to use grub-invaders or some of the other more esoteric
> grub features, then you'll have to disable Secure Boot. Have you
> tried that?

no, I haven't. I am glad that secure boot works at it does on my
computer, to be honest.

 - Fabian



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

Bug#958899: dbab: /etc/init.d/dbab stop does not stop

[Kevin Ryde]

Package: dbab
Version: 1.3.3-1
Severity: normal
File: /lib/init/dbab-init-d-script

Under the standard "init", attempting to stop dbab with

/etc/init.d/dbab stop

silently fails to stop the running dbab-svr process.


In /lib/init/dbab-init-d-script, I suspect

start-stop-daemon --stop ... --exec /usr/sbin/dbab-svr

is no good for a perl script like dbab-svr since the process name is
"perl" rather than /usr/sbin/dbab-svr so the --exec does not match.
I got some joy from removing the --exec bit and letting it stop by the
pidfile, but better double check that.

As to silently failing, I think --quiet should be omitted so at least
when start-stop-daemon doesn't stop for some reason it says so.


-- System Information:
Debian Release: bullseye/sid
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dbab depends on:
ii  curl  7.67.0-2
ii  dnsmasq   2.80-1.1
ii  dnsutils  1:9.11.5.P4+dfsg-5.1+b1
ii  perl  5.30.0-9

Bug#953881: Bug#954866: Bug#953881: transition: ruby2.7 only

[James McCoy]

On Thu, Apr 23, 2020 at 02:09:35PM +0200, Paul Gevers wrote:
> I
> suggest you apply the same fix you already did here [2] and stop
> building the python package for now if that works.

Done and uploaded, however that now makes mercurial FTBFS, as I had
notified them earlier this month (#956007).  I've now raised that bug to
serious.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#958900: dbab: dnsmasq configs left behind on purge

[Kevin Ryde]

Package: dbab
Version: 1.3.3-1
Severity: normal

After purging dbab, there are dnsmasq.d files left behind, causing its
blocking to still take effect,

/etc/dnsmasq.d/dbab-map.adblock.conf
/etc/dnsmasq.d/dbab-map.trashsites.conf

I see the postrm has

/etc/dnsmasq.d/dbab.*

which I take it would have to be dbab-map.*


-- System Information:
Debian Release: bullseye/sid
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dbab depends on:
ii  curl  7.67.0-2
ii  dnsmasq   2.80-1.1
ii  dnsutils  1:9.11.5.P4+dfsg-5.1+b1
ii  perl  5.30.0-9

Bug#958780: take ownership

[Paolo Greppi]

owner 958780 Paolo Greppi 

Bug#958902: rainloop: Enabling PGP support in admin does not work

[Marc POULHIÈS]

Package: rainloop
Version: 1.12.1-2
Severity: normal

Dear Maintainer,

I've tried to enable OpenPGP from the admin panel (simply enabled the checkbox).
Then, from my regular user page, I can :
 - import keys
 - generate a keypair

Both of these do not work as it seems that the corresponding library is missing.
The result is that the button in the form won't do anything (not even an error 
is displayed).

Opening firefox' console gives the following error:

Error: rainloop/v/1.12.1/static/js/min/openpgp.min.js app.min.js:8:25403

Indeed, when looking at local files, I only have:
/usr/share/rainloop/static/js/min/admin.min.js
/usr/share/rainloop/static/js/min/app.min.js
/usr/share/rainloop/static/js/min/boot.min.js
/usr/share/rainloop/static/js/min/libs.min.js

It looks like the library is missing from the package (or maybe it should be 
provided by another package ? Could not find it), and the include path is not 
correct (it looks like the paths that are used in the upstream software, with 
'/v/VERSION/').

I've seen that this package is currently removed from buster but hope it will 
be back soon :)
Thanks,
Marc
-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages rainloop depends on:
ii  ckeditor4.11.1+dfsg-1
ii  nginx   1.14.2-2+deb10u1
ii  nginx-full [nginx]  1.14.2-2+deb10u1
ii  php-curl2:7.3+69
ii  php-fpm 2:7.3+69
ii  php-nrk-predis  1.0.0-1
ii  php-pclzip  2.8.2-4
ii  php-seclib  1.0.14-1
ii  php-xml 2:7.3+69
ii  php7.3-curl [php-curl]  7.3.14-1~deb10u1
ii  php7.3-fpm [php-fpm]7.3.14-1~deb10u1
ii  php7.3-json [php-json]  7.3.14-1~deb10u1
ii  php7.3-xml [php-xml]7.3.14-1~deb10u1

rainloop recommends no packages.

Versions of packages rainloop suggests:
pn  php5-sqlite | php5-mysql | php5-pgsql  

-- Configuration Files:
/etc/rainloop/application.ini changed [not included]
/etc/rainloop/rainloop.nginx.conf changed [not included]

-- no debconf information

Bug#958700: pocl: nested(?) dlopen fails

[Rebecca N. Palmer]

Control: retitle -1 pocl: nested(?) dlopen fails
Control: reassign -1 libpocl2 1.5-2
Control: affects -1 src:libgpuarray python3-pyopencl

ocl-icd-libopencl1 dlopen()s ICDs (at 
https://sources.debian.org/src/ocl-icd/2.2.12-4/ocl_icd_loader.c/#L184). 
 With pocl 1.5, this dlopen() fails in some conditions (returns a NULL 
pointer).  dlerror says the problem is "undefined symbol: clRetainEvent".


After such a failure, libopencl1 ignores that ICD but keeps looking for 
others.  If there aren't any (i.e. pocl is the only ICD installed), it 
returns a "no platforms found" error, hence the above test failures.


This is a regression: it does not happen with pocl from testing (1.4).

These fail:
- pygpu (libgpuarray Python interface) - import 
pygpu.gpuarray;pygpu.gpuarray.init('opencl0:0')

- libgpuarray C interface - program 2 below
- pyopencl - import pyopencl;pyopencl.get_platforms()

These succeed:
- direct C++ calls, including clRetainEvent - program 1 below
- clinfo
- beignet-dev's tester - /usr/lib/x86_64-linux-gnu/beignet/utest_run

These failures are all cases where the code trying to dlopen() pocl was 
itself dlopen()ed: Python dlopen()s C extensions (such as pyopencl and 
pygpu) on import, and libgpuarray dlopen()s libopencl.


$ gdb --args python3 -c "import pyopencl;pyopencl.get_platforms()"
[standard notice]
Reading symbols from python3...
(No debugging symbols found in python3)
(gdb) break _load_icd
Function "_load_icd" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_load_icd) pending.
(gdb) run
Starting program: /usr/bin/python3 -c import\ 
pyopencl\;pyopencl.get_platforms\(\)

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, _load_icd (lib_path=0xe1cbc0 "libpocl.so.2.5.0", num_icds=0)
at ocl_icd_loader.c:237
237 ocl_icd_loader.c: No such file or directory.
(gdb) break dlopen
Breakpoint 2 at 0x77dd22a0: file dlopen.c, line 75.
(gdb) c
Continuing.

Breakpoint 2, __dlopen (file=file@entry=0xe1cbc0 "libpocl.so.2.5.0",
mode=mode@entry=1) at dlopen.c:75
75  dlopen.c: No such file or directory.
(gdb) finish
Run till exit from #0  __dlopen (file=file@entry=0xe1cbc0 
"libpocl.so.2.5.0",

mode=mode@entry=1) at dlopen.c:75
0x777d97eb in _load_icd (lib_path=0xe1cbc0 "libpocl.so.2.5.0",
num_icds=0) at ocl_icd_loader.c:237
237 ocl_icd_loader.c: No such file or directory.
Value returned is $1 = (void *) 0x0
(gdb) print dlerror()
$2 = 0xd9c600 "/usr/lib/x86_64-linux-gnu/libpocl.so.2.5.0: undefined 
symbol: clRetainEvent"

(gdb) quit

Test program 1 - compile with -lOpenCL
#include 
#include 
int main(){
cl_uint num_platforms;
cl_int err;
err=clGetPlatformIDs(0,NULL,&num_platforms);
std::printf("%i %i",err,num_platforms);
cl_int status;
cl_device_id device;
clGetDeviceIDs(NULL,CL_DEVICE_TYPE_ALL,1,&device,NULL);
char device_name[101];
device_name[100]=0;
clGetDeviceInfo(device,CL_DEVICE_NAME,100,device_name,NULL);
cl_context ctx = clCreateContext(NULL, 1, &device, NULL, NULL, &status);
cl_event event1 = clCreateUserEvent(ctx,NULL);
std::printf("\n%i\n",clRetainEvent(event1));
}

Test program 2 - compile with -lgpuarray
#include 
#include 
int main(){
gpucontext_props *p;
gpucontext *p2 = NULL;
int err;
gpucontext_props_new(&p);
gpucontext_props_alloc_cache(p,0,0x10);
err = gpucontext_props_opencl_dev(p,0,0);
std::printf("%i %p",err,p);
err=gpucontext_init(&p2,"opencl",p);
std::printf("%i %p",err,p2);
}

Bug#958901: qreator does not start properly

[Rainer Dorsch]

Package: qreator
Version: 16.06.1-3.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I installed qreator on my system (with a KDE desktop).

I started qreator but did not see any response or window popping up:


rd@h370:~/Downloads$ qreator -w
/usr/share/qreator/qreator_lib/Builder.py:21: PyGIWarning: Gtk was imported 
without specifying a version first. Use gi.require_version('Gtk', '3.0') before 
import to ensure that the right version gets loaded.
  from gi.repository import GObject, Gtk # pylint: disable=E0611
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:18: PyGIWarning: 
GtkChamplain was imported without specifying a version first. Use 
gi.require_version('GtkChamplain', '0.12') before import to ensure that the 
right version gets loaded.
  from gi.repository import Gtk, GtkChamplain, Clutter, Champlain
/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:20: PyGIWarning: 
GtkClutter was imported without specifying a version first. Use 
gi.require_version('GtkClutter', '1.0') before import to ensure that the right 
version gets loaded.
  from gi.repository import GtkClutter
/usr/share/qreator/qreator/qrcodes/QRCodeWifiGtk.py:20: PyGIWarning: NM was 
imported without specifying a version first. Use gi.require_version('NM', 
'1.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, GLib, GdkPixbuf, NM
No handlers could be found for logger "qreator_lib"

I would have expected to see something similar to the windows shown here 
https://wiki.ubuntuusers.de/Qreator/


-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (105, 
'proposed-updates'), (105, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qreator depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  geoclue-2.0  2.5.2-1
ii  gir1.2-champlain-0.120.12.16-3
ii  gir1.2-clutter-1.0   1.26.2+dfsg-10
ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gtkchamplain-0.12 0.12.16-3
ii  gir1.2-gtkclutter-1.01.8.4-4
ii  gir1.2-nm-1.01.14.6-2+deb10u1
ii  python   2.7.16-1
ii  python-cairo 1.16.2-1+b1
ii  python-dbus  1.2.8-3
ii  python-gi3.30.4-1
ii  python-gi-cairo  3.30.4-1
ii  python-pil   5.4.1-2+deb10u1
ii  python-qrencode  1.2-4+b2
ii  python-requests  2.21.0-1
ii  python-vobject   0.9.6.1-0.1
ii  python-xdg   0.25-5

qreator recommends no packages.

qreator suggests no packages.

-- no debconf information

Bug#958903: mutt: Broken file name in attachment if file name has cyrillic symbols (file name charset is UTF-8)

[Andrey Stankevich]

Package: mutt
Version: 1.10.1-2.1
Severity: normal

Dear Maintainer,

I attached file to outgoing mail in mutt.
File name has cyrillic symbols.
Number of cyrillic symbols in file name is bigger than approximately forty 
symbols.

In this case attached file has broken name in attachment in mutt (the file name 
is truncated to approximately forty symbols).
So recipient's MUA receive broken file name in attachment.
For example google mail named that attachment file as "noname".

It is expected nontruncated file name in attachment or warning message in case 
of file name truncating or warning message in status line should be in this 
case.


-- Package-specific info:
Mutt 1.10.1 (2018-07-13)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.19.0-8-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-7' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-7) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20190525095611.wDDr64yqq1.db.mutt/mutt-1.10.1=.
 -fstack-protector-strong -Wformat -Werror=format-security' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20190525095611.wDDr64yqq1.db.mutt/mutt-1.10.1=.
 -fstack-protector-strong -Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  +USE_SIDEBAR  +USE_COMPRESSED  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Julien Cristau]

On Fri, Feb 07, 2020 at 05:21:21PM -0500, Antoine Beaupré wrote:
> [sorry for the dupe, hit send by mistake :(]
> 
> On 2019-11-24 12:13:20, Antoine Beaupré wrote:
> > On 2019-11-23 18:34:25, Julien Cristau wrote:
> >> I'm a bit uneasy about a blanket "include all", to be honest.  It's
> >> probably harmless since it's all coming straight out of debootstrap, but
> >> I'd have been happier with something like "include security.*" if that's
> >> what we expect to see.
> >
> > What kind of problems would you expect with including too many ACLs?
> 
> I'm still curious to hear what kind of problems you expect here. I've
> been running this patch in production for months now and would really
> like to see this land in buster (and hopefully stretch next).
> 
I don't know, that's kind of the point.  For changes in stable I tend to
err on the side of "if there's no demonstrated need for a change then it
shouldn't be done".  Things like "because why not" tend to be red flags.

Cheers,
Julien

Bug#958904: linux-image-4.19.0-8-rpi: Please set CONFIG_RTC_DRV_DS1307=m

[Reco]

Package: src:linux
Version: 4.19.98-1
Severity: wishlist

Dear Maintainer,

Raspberry Pi Model 1B I'm running this installation from does not have built-in 
RTC clock.
DS1307-based RTCs are very popular addon for Raspberry Pi, and I happen to have 
one.
The support of this particular chip is disabled in Debian kernels, so please 
consider building it as a module

Sincerely yours, Reco


-- Package-specific info:
** Version:
Linux version 4.19.0-8-rpi (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-6)) #1 Debian 4.19.98-1 (2020-01-26)

** Command line:
bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 
dma.dmachans=0x7f35 bcm2708.boardrev=0x10 bcm2708.serial=0x631eea77 
bcm2708.uart_clock=4800 bcm2708.disk_led_gpio=47 
bcm2708.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:1E:EA:77 
vc_mem.mem_base=0x1ec0 vc_mem.mem_size=0x2000  console=tty0 
console=ttyAMA0,115200 root=/dev/pi/root rw elevator=deadline fsck.repair=yes 
net.ifnames=0 cma=64M rootwait

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Hardware: BCM2835
Revision: 
Device Tree model: Raspberry Pi Model B Plus Rev 1.2

** Loaded modules:
cfg80211
rfkill
8021q
garp
stp
mrp
llc
ip6t_REJECT
nf_reject_ipv6
xt_mac
nft_counter
ipt_REJECT
nf_reject_ipv4
xt_hashlimit
xt_tcpudp
xt_conntrack
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
xt_comment
nft_compat
nf_tables
nfnetlink
nls_ascii
nls_cp437
vfat
fat
vc4
smsc95xx
snd_soc_core
usbnet
mii
snd_pcm_dmaengine
snd_pcm
snd_timer
snd
raspberrypi_hwmon
soundcore
cec
vchiq(C)
bcm2835_rng
rng_core
leds_gpio
zram
zsmalloc
auth_rpcgss
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
dm_mod

** PCI devices:
not available

** USB devices:
not available


-- System Information:
Debian Release: 10.3
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: armel (armv6l)

Kernel: Linux 4.19.0-8-rpi
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-4.19.0-8-rpi depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-8-rpi recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-4.19.0-8-rpi suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-8-rpi is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120190114-2
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#946779: buster-pu: package logrotate/3.14.0-4

[Julien Cristau]

Control: tag -1 moreinfo

On Sun, Dec 15, 2019 at 08:12:19PM +0100, Christian Göttsche wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> With version 3.14.0 [1] logrotate split the configuration for btmp and
> wtmp into separate configuration files.
> There are bug reports regarding this issue: 945932, 928516, 922045.
> 
> Package version 3.14.0-4+deb10u1 adds a NEWS entry about this change.
> 
> The packaging can be found at [2].
> An upload can be found at [3].
> 
I would suggest documenting this in the buster release notes instead of
updating the package just for the NEWS entry.

Cheers,
Julien

Bug#958905: Multiple versions of libocct cannot be installed

[Yuri D'Elia]

Package: opencascade
Version: 7.3.3+dfsg1-2
Severity: minor

My understanding is that when choosing to include the version in the
package name of a library, is that so that we can allow for multiple
versions of the library to coexist on the same system.

However all libocct-* 7.4 libs break 7.3, which defeats the point
of major-minor version in the package name itself.

Would it be possible to avoid the Breaks or there's some underlying
issue?

Bug#958490: buster-pu: package fuse3/3.4.1-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + d-i

On Sat, 2020-04-25 at 19:17 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2020-04-22 at 22:56 +0200, László Böszörményi wrote:
> > There are two RC bugs fixed in fuse3 for Bullseye but not yet for
> > Buster.
> > First one[1] is caused by a leftover in postinst - udev has rules
> > now
> > to handle such things in its 50-udev-default.rules and
> > 99-systemd.rules files.
> > Then it shouldn't explicitly remove fuse.conf [2] as it should be
> > done
> > by dpkg and fuse might still need it.
> > Last but not least there's a small memory leak fix[3] due to
> > free()-ing the stuct pointer of *mo but not its content with
> > destroy_mount_opts().
> > 
> 
> Please go ahead.

I missed (again) that the package generates a udeb. I don't think d-i
actually uses it, but it should have a KiBi-ack for completeness. (A
statement that fuse is OK to update in general would also work if
that's easier.)

Regards,

Adam

Bug#958108: Please build and install bindings for gi introspection

[Philipp Kern]

On 18.04.20 16:25, Pietro Battiston wrote:
> Package: libinfinity-0.7-0
> Version: 0.7.1-1
> Severity: wishlist
> Tags: patch
> 
> The libinfinity software includes the gi introspection code, but it is
> currently disabled in the debian package.
> 
> According to my tests, enabling it would only require replacing
> 
> --enable-gtk-doc
> 
> 
> with
> 
> --enable-gtk-doc \
> --enable-introspection
> 
> within debian/rules, and adding
> 
> usr/lib/@DEB_HOST_MULTIARCH@/girepository-1.0/*
> 
> after
> 
> usr/lib/@DEB_HOST_MULTIARCH@/libinfinoted-plugin-manager-*.so.*
> 
> within debian/libinfinity-0.7.0.install.

Did you actually manage to build it successfully? There's currently a
FTBFS bug due to glib (#935614) that I was able to bisect on the
upstream Github report but where I am at a loss on how to fix.

Kind regards
Philipp Kern

Bug#958489: buster-pu: package fuse/2.9.9-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + d-i

On Sat, 2020-04-25 at 19:16 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2020-04-22 at 22:56 +0200, László Böszörményi wrote:
> > There are two RC bugs fixed in fuse for Bullseye but not yet for
> > Buster.
> > First one[1] and its variant[2] are caused by a leftover in
> > postinst
> > -
> > udev has rules now to handle such things in its 50-udev-
> > default.rules
> > and 99-systemd.rules files.
> > Then it shouldn't explicitly remove fuse.conf [3] as it should be
> > done
> > by dpkg and fuse3 might still need it.
> > 
> 
> Please go ahead.
> 

Similarly to fuse3, this wants a KiBi-ack for completeness.

Regards,

Adam

Bug#948375: buster-pu: package ceph/12.2.12+dfsg-1

[Julien Cristau]

Control: tag -1 moreinfo

Hi Bernd,

On Tue, Jan 07, 2020 at 11:37:45PM +0100, Bernd Zeimetz wrote:
> I have a bit complicated idea for a buster-pu: ceph.
> Buster shipped with 12.2.11 and last April upstream released 12.2.12 as
> bugfix release. As usual with ceph, the diff is *huge*, but it is a
> bugfix-only release. So here are a few facts:
> 
> - upstream changes: https://ceph.io/releases/v12-2-12-luminous-released/
>   
> - proposed diff:
>   
> https://salsa.debian.org/ceph-team/ceph/compare/luminous%2Funstable...debian%2Fbuster
> 
That's kind of unreadable.  We like to have the proposed diff directly
in the p-u bug, along with a description of the changes, what they fix,
what the risks are.  Pointers to more information elsewhere are not bad,
but they don't replace information that should be in the bug.  In this
case the upstream changelog doesn't really provide much context on which
if any of the fixed issues are serious enough for us to want the update
in stable.

> - I've basically imported the changes the Ubuntu people have done in
>   Ubuntu together with 12.2.12. So I assume this should work well, I did
>   not yet test it properly as I want to wait for a reply from you. I'll
>   prepare a backport of 14.2.x as soon as it migrates to testing anyway.
> 
A reply from us tends to not be forthcoming before the proposed changes
have been tested, so there's a bit of a chicken and egg issue.

> - The issue with ceph is that upstream doesn't do QA for 32bit and our
>   selection of unusual architectures. I don't know if it builds on all
>   buildds without trying...
> 
There should be porterboxes available for all our release architectures.

Cheers,
Julien

Bug#948333: buster-pu: package frr/6.0.2-2

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Sun, 2020-04-26 at 13:11 +0200, Thomas Goirand wrote:
> On 4/25/20 9:05 PM, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Tue, 2020-01-07 at 14:05 +0100, Thomas Goirand wrote:
> > > On 1/7/20 2:01 PM, Thomas Goirand wrote:
> > > > As per the issue described here:
> > > > https://github.com/FRRouting/frr/issues/3251
> > > > 
> > > > extended next hop capability does not work in Debian Buster.
> > > > As a consequence, we aren't able to advertize for an IP
> > > > address on our local loopback through the IPv6 link local,
> > > > which is how we would like to do BGP to the host.
> > > > 
> > > > Note that this issue is from version 5.0.1 up to version
> > > > 7.2 (which is in Sid), so I took the time to cherry-pick the
> > > > fix from upstream. I have attached the resulting debdiff, and
> > > > opened the bug against the frr package itself.
> > [...]
> > > FYI, frr bug number is:
> > > https://bugs.debian.org/cgi-bin/948332
> > 
> > Apologies for the delay in getting back to you.
> > 
> > The description above, and the metadata on the referenced bug
> > report, suggest that the issue still affects the package in
> > unstable. Is that correct?
[...]
> It's not correct. The version in unstable, 7.2.1, contains the
> upstream fix for this problem.

Then https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948332 should
have a fixed version which indicates that.

Please feel free to go ahead, but please do fix the metadata.

Regards,

Adam

Bug#958906: ITP: pytyon-diagrams -- Diagrams lets you draw the cloud system architecture in Python code.

[TANIGUCHI Takaki]

Package: wnpp
Severity: wishlist
Owner: TANIGUCHI Takaki 

* Package name: pytyon-diagrams
  Version : 0.9.0
  Upstream Author : Copyright: 2020 MinJae Kwon 
* URL : https://diagrams.mingrammer.com/
* License : MIT
  Programming Lang: Python
  Description : Diagrams lets you draw the cloud system architecture in 
Python code.

 Diagrams lets you draw the cloud system architecture in Python code.
 It was born for prototyping a new system architecture design without
 any design tools. You can also describe or visualize the existing
 system architecture as well. Diagrams currently supports six major
 providers: AWS, Azure, GCP, Kubernetes, Alibaba Cloud and Oracle
 Cloud. It now also supports On-Premise nodes.

Bug#956219: Error out when DISPLAY is unset

[Alberto Garcia]

On Sat, Apr 25, 2020 at 10:17:47AM +0200, Laurent Bigonville wrote:
> I'm reopening this as yelp still FTBFS with 2.28.2 with the same
> error, was the patch cherry-picked?

It was, but the problem seems to be different this time (a null
pointer):

process:35799): Gtk-CRITICAL **: 13:40:20.270: gtk_icon_theme_get_for_screen: 
assertion 'GDK_IS_SCREEN (screen)' failed

** (process:35799): WARNING **: 13:40:20.271: Unable to connect to dbus: Cannot 
autolaunch D-Bus without X11 $DISPLAY
Unable to init server: Could not connect: Connection refused
Segmentation fault

Thread 1 "libyelp-scan" received signal SIGSEGV, Segmentation fault.
0x7335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at 
./src/renderer-backend-egl.c:54
54  backend->base.interface->destroy(backend->base.interface_data);
(gdb) bt
#0  0x7335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at 
./src/renderer-backend-egl.c:54
#1  0x763bc8bb in 
WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() ()
at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:66
#2  0x763bc8d9 in 
WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() ()
at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:67
#3  0x77c59e27 in __run_exit_handlers
(status=0, listp=0x77dd8718 <__exit_funcs>, 
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
at exit.c:108
#4  0x77c59fda in __GI_exit (status=) at exit.c:139
#5  0x77c42e12 in __libc_start_main (main=
0x6480 , argc=1, argv=0x7fffdd78, init=, 
fini=, rtld_fini=, stack_end=0x7fffdd68) at 
../csu/libc-start.c:342
#6  0x7b7a in _start () at libyelp-scan.c:1025

This looks like the WPE backend (which WebKitGTK uses), but from the
backtrace I can't quite tell yet where exactly the root of the problem
is. We'll investigate it and make sure that yelp builds after we have
fixed it.

Thanks for the report and sorry for the annoyance !

Berto

Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2

[Adam D. Barratt]

On Wed, 2020-04-22 at 05:21 +, Mo Zhou wrote:
> The whole fix involes two parts: a part goes to src:zfs-linux and the
> other goes to src:spl-linux. Now that the updated src:spl-linux is
> already uploaded, and I'm now asking for the permission to upload the
> updated src:zfs-linux. Which includes two upstream commits fixing
> potential deadlock issues.

What happens if a user tries using the current spl-dkms with the newer
zfs-dkms, or vice versa?

Regards,

Adam

Bug#953647: buster-pu: package proftpd-dfsg/1.3.6-4+deb10u5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-03-11 at 19:19 +0100, Hilmar Preusse wrote:
> the package fixes two critical issues, which impacts the usability of
> the
> mod_sftp proftp module. There are situations, where users can't
> connect to
> an proftp server using sftp in case the client is recent enough.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#958780: do we really want to do this ?

[Paolo Greppi]

My understanding is that node-gulp-babel v8 should be used with babel7.
Same goes for node-babel-loader, you need v8 for babel7, but we only have 
node-babel-loader 7 in Debian.

If we want babel6 to co-exist with babel7, then we don't want to just update 
node-gulp-babel and node-babel-loader to v8.
We want to keep node-gulp-babel and node-babel-loader at v7 for compatibility 
with babel6, and upload new node-gulp-babel8 and node-babel-loader8 for babel7.

Back to the topic of this bug, do we really want to upgrade the yarn build 
system from babel6 to babel7 ?
Here is some indication that upstream is not interested: 
https://github.com/yarnpkg/yarn/pull/6322
But I have raised the issue anyway: https://github.com/yarnpkg/yarn/issues/8083

Paolo

Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1

[Julien Cristau]

On Sun, Feb 16, 2020 at 04:27:11PM +, Ben Hutchings wrote:
> This was discussed on IRC with Julien Cristau, but unfortunately I
> didn't save a log.  The main points that came up were:
> 
> * Executables built for the O32 FP64 ABI require this kernel config
>   change and older kernel versions will refuse to load them.  So the
>   kernel needs to be upgraded before installing any binaries built
>   for the new FP ABI.
> 
> * Normally the support for an additional ABI would be included in
>   release N.0 and used in N+1.  Since this was not present in 10.0, it
>   would be possible for users to start upgrading to bullseye while
>   still running a kernel that does not support O32 FP64.  We need to
>   prevent them getting a broken system.
> 
> * Julien proposed that libc6 would have a preinst check on the kernel
>   when it is changed to use the new FP ABI.  Presumably all binaries
>   built for the new FP ABI should also have a versioned dependency on
>   at least this version of libc6.
> 
> So I don't see any reason not to update the kernel configuration
> already, as it will remain compatible with the O32 FPXX binaries in
> buster.  Only the user-space changes in unstable (libc6 and toolchain)
> need to be carefully coordinated.
> 
Here's the irc log for the record:

< bwh> jcristau: While you are here, could you have a quick look at #949259?
< jcristau> that's kind of awkward
< jcristau> maybe it's ok because it's only mips, but...
< bwh> but what?
< jcristau> well i'd normally expect bullseye to run on buster r0
< jcristau> what's the failure mode if the kernel doesn't support O32_FP64?
< bwh> syq_: Can you answer?
< bwh> jcristau: It looks to me like exec will fail for programs built for the 
new FP ABI
< jcristau> so they'll need to get a dependency on a new libc with a preinst 
check?
< bwh> jcristau: That seems like a reasonable approach
< bwh> that + prominent notice in the release notes
< syq_> jcristau: it will complain that not support such binary
< syq_> jcristau: if kernel doesn't enable FP64

I think you can go ahead provided that:
- enabling this support in the kernel doesn't break previously-supported
  userspace
- Aurélien as glibc maintainer is OK with this plan

Thanks,
Julien

Bug#955277: buster-pu: package mini-buildd/1.0.36

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-03-29 at 09:42 +0200, Stephan Suerken wrote:
> mini-buildd currently has
> 
> stable 1.0.x branch   bugfix+maintenance only   uploads to unstable
> (python 2)
> master branch development   uploads to
> experimental (python 3)
> 
> The development (py 3) variant is not yet ready for an upload to
> unstable for weeks/month.
> 
> In the past, I was quite happy to do "mini-buildd stable" uploads to
> unstable, and then do occasional backports from testing. Thus people
> could just find/install bugfix releases via Debian (through
> backports).
> 
> With python 2 getting removed from Debian, I can no longer go the
> 'bpo-way'. Although it is somewhat documented that there is a 3rd
> party PPA available, people usually don't find it (or don't want to
> use it).
> 
> I.e., I would love to do be able to do bugfix releases via Debian
> again, and afaics proposed-updates is now the option I have.
> 
> The most annoying issue long fixed after 1.0.36 is this
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951641
> 
> Candidates for proposed-updates imho:
> 
> 1.0.37: Some fixes especially for buster, but did not quite make it;
> fix for #951641.
> 1.0.41: What's currently in unstable.
> 

We'd need to see diffs for a proposed upload before OKing anything
here.

> 1.0.44: Most recent stable: 
> https://salsa.debian.org/debian/mini-buildd/-/tree/1.0.x

This, however, definitely doesn't work - you can't upload packages to
stable that are are newer than what's in unstable, not least because by
definition that means the bugfixes haven't been applied and tested
there.

> As a side question: Would it still work/be ok to upload (python 2)
> 1.0.44 to unstable, just for the sake that people are aware of this
> new version?

The SRMs have no control or say over what packages you upload to
unstable. However, doing so isn't going to help with either of the RC
bugs that the package currently has there. (I'm aware that they don't
apply to stable.)

Regards,

Adam

Bug#950488: buster-pu: package kronosnet/1.8-2

[Adam D. Barratt]

Control: tags -1 + moreinfo

Apologies for not replying sooner.

On Sun, 2020-02-02 at 14:47 +0100, Ferenc Wágner wrote:
> I'v got a bold request: please let me update Kronosnet in buster from
> 1.8-2 to 1.13-something to fix #946222.  During the buster freeze
> period, upstream released 1.9 and 1.10, but those didn't bring
> important
> fixes, so I didn't request freeze exceptions for them.  However, when
> Proxmox VE 6.0 got released (based on Debian buster), their users
> reported lots of intertwined bugs, and the developers iterated
> through
> 1.11, 1.12 and 1.13 in quick succession to fix them, see the linked
> https://forum.proxmox.com/threads/pve-5-4-11-corosync-3-x-major-issues.56124.

Do upstream have a stable or LTS tree? I see that unstable currently
contains 1.15, so 1.X is presumably not it.

Usually when considering a larger update, we'd be looking for
information such as:

- What sort of changes get included in upstream releases? Are they just
bug fixes, or are there new features included, or other changes?

- What sort of testing do the new releases get? Is the testing
automated?

- What sort of regressions are reported against new releases? How
quickly are they resolved?

Regards,

Adam

Bug#947172: npm 5.8.0+ds6-4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 947172 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: npm
Version: 5.8.0+ds6-4+deb10u1

Explanation: fix arbitrary path access [CVE-2019-16775, CVE-2019-16776, 
CVE-2019-16777]

Bug#958887: purple-discord 0.9.2019.02.07.git.e5d9627-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 958887 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: purple-discord
Version: 0.9.2019.02.07.git.e5d9627-1+deb10u1

Explanation: fix crashes in ssl_nss_read

Bug#950332: buster-pu: package wireless-regdb/2019.06.03-1~deb10u1

[Julien Cristau]

On Fri, Jan 31, 2020 at 02:26:18PM +0100, Ben Hutchings wrote:
> I failed to update wireless-regdb for some time, as it needed some
> significant work to prepare for the regulatory database being directly
> loaded by the kernel (instead of by crda).  This was introduced in
> Linux 4.15, but is currently disabled in all Debian suites.  It will
> be enabled starting with 5.5.
> 
> The version now in unstable has:
> 
> 1. regulatory.bin: loadable by crda, trusted by Debian crda
> 2. regulatory.db-debian, regulatory.db.p7s-debian:
>loadable by kernel, trusted by future Debian kernels
> 3. regulatory.db-upstream, regulatory.db.p7s-upstream:
>loadable by kernel, trusted by upstream and future Debian kernels
> 4. regulatory.db, regulatory.db.p7s: alternative links for either
>(2) or (3)
> 
> So this should be backward-compatible with all supported Debian
> releases, with one exception:
> 
> On a system that has a recent kernel and (3) from elsewhere, *and*
> also a currently unused wireless-regdb package, upgrading
> wireless-regdb will effectively replace (3) with (2), which is not
> trusted by their kernel.  They will need to run update-alternatives to
> fix this (this is documented in README.Debian).
> 
Is this something that can be detected from e.g. maintainer scripts, to
show some kind of hint to the affected user?

> The update for (1) definitely should be delivered to all suites, but
> I'm undecided whether the other files should be included.  Please
> advise what I should do.
> 
I guess our options for stable are:
a. ship 1/2/3/4 in a point release
b. ship an update for 1 in a point release, ship 1/2/3/4 in backports

For option b, can we reasonably have the backports kernel Break old
wireless-regdb, to nudge apt into updating that to the backport too?  Or
is that more likely to get wireless-regdb removed than anything else?

Cheers,
Julien

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

On 2020-04-26 15:45:02, Julien Cristau wrote:
> On Fri, Feb 07, 2020 at 05:21:21PM -0500, Antoine Beaupré wrote:
>> [sorry for the dupe, hit send by mistake :(]
>> 
>> On 2019-11-24 12:13:20, Antoine Beaupré wrote:
>> > On 2019-11-23 18:34:25, Julien Cristau wrote:
>> >> I'm a bit uneasy about a blanket "include all", to be honest.  It's
>> >> probably harmless since it's all coming straight out of debootstrap, but
>> >> I'd have been happier with something like "include security.*" if that's
>> >> what we expect to see.
>> >
>> > What kind of problems would you expect with including too many ACLs?
>> 
>> I'm still curious to hear what kind of problems you expect here. I've
>> been running this patch in production for months now and would really
>> like to see this land in buster (and hopefully stretch next).
>> 
> I don't know, that's kind of the point.  For changes in stable I tend to
> err on the side of "if there's no demonstrated need for a change then it
> shouldn't be done".  Things like "because why not" tend to be red flags.

I don't know what to say here. I'm not familiar with the security.* flag
you are refering to, and I do not know whether it will fix my bug. I
also do not know if there are other similar bugs lurking that we just
haven't found yet, exactly about this.

It seems to me we should have the most faithful archive and recovery
when we do a snapshot. This is what this patch does.

You bring up the concern of "include all" yet you also explicitely say
that it's "probably harmless". So I'm truly confused as to why we're
still blocking on this. I understand we want to be conservative in
stable, but this is not like I'm introducing a 1000-line long patch
here.

I would argue that restricting the number of extended attributes is
*more* likely to create bugs than the opposite.

I will also mention that this has landed in buster ages ago, and no ill
effects were found there.

A.

-- 
Use for yourself little but give to others much.
   - Albert Einstein

Bug#953155: buster-pu: package bind9/1:9.11.5.P4+dfsg+1-1

[Julien Cristau]

Control: tag -1 moreinfo

On Thu, Mar 05, 2020 at 11:40:44AM +0100, Ondřej Surý wrote:
> Hi,
> 
> recently, there was a bug #952946 filled against BIND 9 (and other packages)
> about license problem with OASIS PKCS#11 (pkcs11.h) that has incompatible
> license.  Upstream has already fixed that in the next upstream release to be 
> due
> in March and the question here is whether we want to do the dfsg to dfsg+1 
> bump
> just because of the pkcs11.h header in both buster and stretch.
> 
Can you provide more details as to exactly what the license problem is
and what the change would look like?

Cheers,
Julien

Bug#944099: CVE-2019-14433 / OSSA-2019-003: buster-pu: package nova/2:18.1.0-6 -> 18.1.0-6+deb10u1

[Julien Cristau]

On Sun, Nov 24, 2019 at 10:06:51AM +0100, Thomas Goirand wrote:
> On 11/23/19 6:09 PM, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > On Mon, Nov 04, 2019 at 11:53:52AM +0100, Thomas Goirand wrote:
> >> We would like to update Nova in Buster for 2 reasons. First, there's
> >> OSSA-2019-003 / CVE-2019-14433 which we would like to fix. Second,
> >> in non-interactive mode, upgrading Nova can lead to some configuration
> >> changes, which is an RC bug.
> >>
> > This doesn't sound like it should require new debconf templates.  What's
> > the logic there?  Why does upgrading touch the configuration at all?
> > 
> > Cheers,
> > Julien
> 
> Same as for Heat for which I just replied.
> 
> In the postinst, after consuming the password prompt in the .config
> script, the password is forgotten using db_unregister. The only way to
> avoid this is to have this other screen prompting for not handling this
> through debconf, which is always the default.
> 
This still doesn't make sense to me.

Cheers,
Julien

Bug#958908: ITP: bgpq4 -- automatic BGP filter generator using IRR routing data

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: bgpq4
  Version : 0.0.6
  Upstream Author : Job Snijders
* URL : https://github.com/bgp/bgpq4
* License : BSD 2-clause
  Programming Lang: C
  Description : automatic BGP filter generator using IRR routing data

bgpq4 eases BGP filter maintenance by automatically generating prefix
lists, (extended) access lists, policy statement terms and AS-path lists
using RADB data. It features IPv6 prefix-/access-list support,
aggregation of generated filters and output compatible with Cisco,
Juniper, Mikrotik, Nokia, OpenBGPD and BIRD.

It is a fork of bgpq3.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl6lpMkSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5Bw8P/007Ol3MXLxs2b68J0nxz0wLsqw4q+Cb
WMEdff8Hw2isNQuBkaZmOIcR19v7SjuLH1cYi/GgJEtBtTvxSrU/j85/+OHz5wY8
VwAhM8I7qBigwlyvH2GoWq119RyEAcDP+mH+0dekwiG5Rq60m9TuTpaKjx1fkkP2
Q5Zxz+GIxf2XXYOMoDF9ekJIS1H0gh6zqniQS5PV5zmkk7Yc5wI+0ar8QmuiAGMa
8ihn+o0NpANRCOmaRhFpTb/I0CoCX1pw0lpuPTeIQreKddyEKrFLRGjAnOOHQy/r
FarNfDd7ql0RZcU+MSND/KIxy5zSyrY3KdGDi9FunZ6fIGegSMRRWADUtX8waqwF
LmgaGeNZ06va2AvUUp6uBd7qAmHi0I1QzLRY2zDIKkPckOhbqAkB1NYYU9jUjcgc
pyLzy0cyxV4oKawjLB2kuN8tgzJCQRVLiEjze9sFO8tIB3Zb+of6yZiHI9GbI3gD
QUPii0rqZkzwegxbUHXm0l3VbnYC4xqHGhW1SjlZTGnE/Q7uTNBl8UIIbwe8YbpK
DrRJGuLnwZwhYQb0FutfPyEbaLFs7vV7VxhNZ8xGfoK8emDRQuJbyq0aPpBtZGiA
UUycJgn31Itjp6ZBzt4mekD2OOlIBqyrr7lWfjwdiv2TYKrrd71cJ7XvE/Ggo3gT
XHpzescaJu/S
=4Oxg
-END PGP SIGNATURE-

Bug#958907: debian/copyright missing text for "Python-2" license

[Ben Hutchings]

Package: ansible
Version: 2.9.6+dfsg-1
Severity: important

debian/copyright has:

Files: lib/ansible/module_utils/compat/*
   lib/ansible/utils/unsafe_proxy.py
   licenses/PSF-license.txt
Copyright: 2007, Google Inc
   Licensed to PSF under a Contributor Agreement
License: Python-2

and then at the end:

License: Python-2
Comment: Add the corresponding license text here

Ben.

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

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

Versions of packages ansible depends on:
ii  openssh-client1:8.2p1-4
ii  python3   3.8.2-3
ii  python3-crypto2.6.1-13.1+b1
ii  python3-cryptography  2.8-4
ii  python3-distutils 3.8.2-2
ii  python3-dnspython 1.16.0-2
ii  python3-httplib2  0.14.0-3
ii  python3-jinja22.10.1-2
ii  python3-netaddr   0.7.19-4
ii  python3-paramiko  2.6.0-2
ii  python3-yaml  5.3.1-2

Versions of packages ansible recommends:
ii  python3-argcomplete  1.8.1-1.3
ii  python3-jmespath 0.9.5-1
ii  python3-kerberos 1.1.14-3.1+b1
ii  python3-libcloud 2.8.0-1
ii  python3-selinux  3.0-1+b3
ii  python3-winrm0.3.0-2
ii  python3-xmltodict0.12.0-2

Versions of packages ansible suggests:
ii  cowsay   3.03+dfsg2-7
pn  sshpass  

-- no debconf information

Bug#949921: buster-pu: package uim_1.8.8-4+deb10u3

[Adam D. Barratt]

On Thu, 2020-01-30 at 19:24 +0900, Takatsugu Nokubi wrote:
> 2020年1月30日(木) 10:21 Takatsugu Nokubi :
> > > > This fix is not necessary in unstable, because libuim-data is
> > > > removed
> > > > on unstable.
> > > 
> > > It was incorrect. I'll update unstable for this issue.
> > 
> > I uploaded unstable.
> 
> Sorry, it was incorrect, the first message (no need to fix) is
> correct.
> 

Are you sure? libuim-data certainly still seems to be in unstable:

libuim-data | 1:1.8.8-6.1| unstable | all
uim| 1:1.8.8-6.1| unstable   | source,
amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

Regards,

Adam

Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Julien Cristau]

Control: tag -1 confirmed

On Sun, Mar 04, 2018 at 11:08:00AM +0100, Carsten Leonhardt wrote:
> Control: tags -1 - moreinfo
> 
> "Adam D. Barratt"  writes:
> 
> > -   --oknodo --exec $DAEMON --chuid $BUSER:$BGROUP -- -c $CONFIG
> > +   --oknodo --exec $DAEMON -- -g $BUSER -g $BGROUP -c $CONFIG
> >
> > The first of those "-g" is presumably supposed to be "-u". I realise
> > this may seem a small point, but it does make me wonder how it wasn't
> > caught in testing.
> 
> Thank you for your work and for catching this. A new version of the
> patch is attached.
> 
Sorry for the delay, please go ahead.

Cheers,
Julien

Bug#940222:

[Christoph Biedl]

Paolo Benvenuto wrote...

> on the server:
> 
> $ file -i myfile.avi
> myfile.avi: image/x-tga; charset=binary
> 
> $ file --version
> file-5.35
> magic file from /etc/magic:/usr/share/misc/magic
> 
> 
> on the ubuntu bionic pc:
> 
> $ file -i myfile.avi
> myfile.avi: video/mpeg; charset=binary
> 
> $ file --version
> file-5.32
> magic file from /etc/magic:/usr/share/misc/magic

At first, sorry for the long delay. That was not intended, but sometimes
live happens.

About your report, checking my collections I could not find a way to
reproduce the issue, and upstream made a lot of changes related to that
detection.

So could you please provide a hex dump of the first 256 bytes - that
should be enough to analyse what has happened. If possible, can you
also re-check on Ubuntu focal and Debian sid?

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#958780: [Pkg-javascript-devel] Bug#958780: do we really want to do this ?

[Pirate Praveen]

On Sun, Apr 26, 2020 at 4:33 pm, Paolo Greppi  
wrote:
My understanding is that node-gulp-babel v8 should be used with 
babel7.
Same goes for node-babel-loader, you need v8 for babel7, but we only 
have node-babel-loader 7 in Debian.


If we want babel6 to co-exist with babel7, then we don't want to just 
update node-gulp-babel and node-babel-loader to v8.
We want to keep node-gulp-babel and node-babel-loader at v7 for 
compatibility with babel6, and upload new node-gulp-babel8 and 
node-babel-loader8 for babel7.


My suggestion,

1. node-rollup-plugin-babel: Plan A, update all packages build 
depending on node-rollup-plugin-babel to build with babel 7 (psl.js 
updated already and seems pretty straight forward). Plan B, embed 
rollup-plugin-babel 4 in node-babel7 if plan A becomes too difficult.
2. node-gulp-babel: Plan A, update all packages build depending on 
node-gulp-babel to babel 7. Plan B: embed gulp-babel 8 in node-babel 7 
as it seems a simple module unlike rollup-plugin-babel.
3. babel-loader: This is not a blocker as node-babel7 build depends on 
node-rollup-plugin-babel and node-gulp-babel only.


Lets use https://wiki.debian.org/Javascript/Nodejs/Transitions/Babel7 
to track the status.


Back to the topic of this bug, do we really want to upgrade the yarn 
build system from babel6 to babel7 ?
Here is some indication that upstream is not interested: 
https://github.com/yarnpkg/yarn/pull/6322
But I have raised the issue anyway: 
https://github.com/yarnpkg/yarn/issues/8083


Ideally we should have only one version of babel in bullseye and we 
should try to get rid of babel 6 by bullseye freeze. Even if upstream 
is not interested, we will have to maintain the patch.

Bug#958108: Please build and install bindings for gi introspection

[Pietro Battiston]

Il giorno dom, 26/04/2020 alle 15.46 +0200, Philipp Kern ha scritto:
> [...]
> Did you actually manage to build it successfully? There's currently a
> FTBFS bug due to glib (#935614) that I was able to bisect on the
> upstream Github report but where I am at a loss on how to fix.

Sorry, I should have mentioned that I did my experiment under buster.

Pietro

Bug#950332: buster-pu: package wireless-regdb/2019.06.03-1~deb10u1

[Ben Hutchings]

On Sun, 2020-04-26 at 16:48 +0200, Julien Cristau wrote:
> On Fri, Jan 31, 2020 at 02:26:18PM +0100, Ben Hutchings wrote:
> > I failed to update wireless-regdb for some time, as it needed some
> > significant work to prepare for the regulatory database being directly
> > loaded by the kernel (instead of by crda).  This was introduced in
> > Linux 4.15, but is currently disabled in all Debian suites.  It will
> > be enabled starting with 5.5.
> > 
> > The version now in unstable has:
> > 
> > 1. regulatory.bin: loadable by crda, trusted by Debian crda
> > 2. regulatory.db-debian, regulatory.db.p7s-debian:
> >loadable by kernel, trusted by future Debian kernels
> > 3. regulatory.db-upstream, regulatory.db.p7s-upstream:
> >loadable by kernel, trusted by upstream and future Debian kernels
> > 4. regulatory.db, regulatory.db.p7s: alternative links for either
> >(2) or (3)
> > 
> > So this should be backward-compatible with all supported Debian
> > releases, with one exception:
> > 
> > On a system that has a recent kernel and (3) from elsewhere, *and*
> > also a currently unused wireless-regdb package, upgrading
> > wireless-regdb will effectively replace (3) with (2), which is not
> > trusted by their kernel.  They will need to run update-alternatives to
> > fix this (this is documented in README.Debian).

I didn't actually test this, but I have now.  In fact, update-
alternatives will *not* replace /lib/firmware/regulatory.db but will
issue warnings.  Package installation still succeeds.

> Is this something that can be detected from e.g. maintainer scripts, to
> show some kind of hint to the affected user?

I think that the current upgrade behaviour is safe.  However I should
probably implement replacement with the "upstream" alternative in case
regulatory.db is already present.

> > The update for (1) definitely should be delivered to all suites, but
> > I'm undecided whether the other files should be included.  Please
> > advise what I should do.
> > 
> I guess our options for stable are:
> a. ship 1/2/3/4 in a point release
> b. ship an update for 1 in a point release, ship 1/2/3/4 in backports
> 
> For option b, can we reasonably have the backports kernel Break old
> wireless-regdb,

It already does, in the version that's in backports-NEW.

> to nudge apt into updating that to the backport too?  Or
> is that more likely to get wireless-regdb removed than anything else?

I don't know.  I have updated wireless-regdb in buster-backports, so
the recommended "apt install -t buster-backports linux-image-amd64"
will work.  But upgrades might not.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.




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

Bug#892932: stretch-pu: package websockify/0.8.0+dfsg1-7+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Wed, Mar 14, 2018 at 06:48:51PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
>   * Add runtime depends on python{3,}-pkg-resources (Closes: #879224).

Please go ahead.

Cheers,
Julien

Bug#891657: stretch-pu: package swt-gtk/3.8.2-3+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Tue, Feb 27, 2018 at 08:47:39PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
>* libswt-webkit-gtk-3-jni: Add the missing dependency
>  on libwebkitgtk-1.0-0. (Closes: #879170)

Go ahead.

Cheers,
Julien

Bug#893006: stretch-pu: package boost1.62/1.62.0+dfsg-4+deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Wed, Apr 04, 2018 at 10:25:30PM +0200, Philipp Huebner wrote:
> Hi,
> 
> Am 02.04.2018 um 12:57 schrieb Julien Cristau:
> > On Thu, Mar 15, 2018 at 14:51:10 +0100, Philipp Huebner wrote:
> >> I would like to fix #883987 in boost1.62 for Stretch.
> >> The changes are basically the same as what is currently in testing and I 
> >> got the
> >> maintainer's go-ahead in
> >> http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2018-March/004184.html
> >>
> > What made these partial specializations not be necessary anymore?  That
> > seems like critical missing information if we are to make a decision
> > here, to know if/what we might be breaking instead.
> 
> my guess is that only upstream can really answer that.
> 
> My work colleague confirmed that we're basically using the same code as
> in the example at the upstream bug tracker and it fails when using gcc-6
> on Stretch:
> https://svn.boost.org/trac10/ticket/12534
> 
> 
> Best wishes,
> -- 
>  .''`.   Philipp Huebner 
> : :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
> `. `'`
>   `-
> 

Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2

[Mo Zhou]

On Sun, Apr 26, 2020 at 03:25:22PM +0100, Adam D. Barratt wrote:
> On Wed, 2020-04-22 at 05:21 +, Mo Zhou wrote:
> > The whole fix involes two parts: a part goes to src:zfs-linux and the
> > other goes to src:spl-linux. Now that the updated src:spl-linux is
> > already uploaded, and I'm now asking for the permission to upload the
> > updated src:zfs-linux. Which includes two upstream commits fixing
> > potential deadlock issues.
> 
> What happens if a user tries using the current spl-dkms with the newer
> zfs-dkms, or vice versa?

I forgot to add Depends: spl-dkms (>= 0.7.12-2+deb10u1, s-p-u) into the
debdiff of zfs-linux.

Actually zfs-linux (= 0.7.12-2+deb10u1, buster) have no problem to build
atop spl-linux (= 0.7.12-2, buster) or (= 0.7.12-2+deb10u1, s-p-u);
while zfs-linux (= 0.7.12-2+deb10u2, s-p-u) will FTBFS atop spl-linux (= 
0.7.12-2, buster)

In that sense we'd better deal with spl-linux and zfs-linux synchronously.
 
> Regards,
> 
> Adam

Bug#893439: stretch-pu: package gnucash/1:2.6.15-1+deb9u1

[Julien Cristau]

Control: reassign -1 pu: libdbi/0.9.0-4+deb9u2
Control: tag -1 confirmed

On Fri, Nov 09, 2018 at 07:29:32AM +0100, László Böszörményi wrote:
> On Sat, Oct 6, 2018 at 7:07 PM Adam D. Barratt  
> wrote:
> >
> > László: ping?
> >
> > On Mon, 2018-04-02 at 15:20 +0200, Julien Cristau wrote:
> > > On Mon, Apr  2, 2018 at 14:51:54 +0300, Adrian Bunk wrote:
> > > > On Mon, Apr 02, 2018 at 01:05:39PM +0200, Julien Cristau wrote:
> > > > > On Sun, Mar 18, 2018 at 22:07:25 +0200, Adrian Bunk wrote:
> > [...]
> > > > > libdbi 0.9.0-4+deb9u1 broke gnucash tests, runtime issues
> > > > > > with this backend were so far not reported but are not
> > > > > > unlikely.
> > [...]
> > > So the other option here would be to revert the libdbi change.  As
> > > far as I can tell from #880896 it wasn't prompted by a specific
> > > problem, so a revert there might be the safest course of action and
> > > sidesteps the gnucash issue.  László, any thoughts?
>  Indeed, that change is better reverted. I've proposed a patch on
> #884119 [1]. Can I upload it to Stretch or should file a separate PU
> proposal?
> 
Please go ahead and upload to stretch.  Repurposing this bug for the
libdbi update.

Cheers,
Julien

Bug#881687: dpkg-cross: skip ld.so.1 in /usr/$(multiarch)/lib for mips n32 and 64

[Helmut Grohne]

Control: tags -1 - moreinfo + patch

Hi Wookey and YunQiang,

On Thu, Nov 30, 2017 at 10:10:25PM +0800, YunQiang Su wrote:
> Wooky, this patch should work for the dpkg-cross package in repo.
> 
> @James:
> >YunQiang, you still haven't told me why we need to do any of these
> >dpkg-cross changes (I'm referring to #881687 as well as this bug). What
> >exactly was the problem that lead you to submitting #881687? I can't see
> >the bug you are trying to solve.
> 
> libc6_mips64el contains a file `/usr/lib/mips64el-linux-gnuabi64/ld.so.1'
> libc6-mips32_mips64el contains a file `/lib/ld.so.1'
> 
> when process with dpkg-cross:
> libc6-mips64el-cross will contains /usr/mips64el-linux-gnuabi64/lib/ld.so.1,
>and
> libc6-mips32-mips64el-cross also contains
> /usr/mips64el-linux-gnuabi64/lib/ld.so.1.
> 
> So my patch is to solve this file conflicts by obeying the old mips layout,
> ld.so.1 for N64 to lib64/
> ld.so.1 for N32 to lib32/
> ld.so.1 for O32 still in lib/
> 
> In fact for gcc-multilib/mips64, I also put all o32 files in libo32/
> and with ld.so.1 still in lib/
> This is a tradeoff between Debian's layout and old mips layout.
> 
> x86 doesn't have this problem due to it uses different ld.so file name
> for x64/x32/i386.

Thank you for his detailed explanation. I agree with the analysis. I
added the moreinfo tag to an earlier version of this patch, but my
concern has since been resolved in the updated patch. Therefore, I am
replacing the moreinfo tag with the patch tag.

I've also noticed that sparc64 is affected in the very same way as it
uses ld-linux.so.2 for both sparc (32bit) and sparc64. Therefore, I've
sent another patch for gcc-10 to add the relevant lib64 path in the -l
flag for dh_shlibdeps and I've updated your patch to also cover sparc64.
The attached patch therefore is a slight adaption of YunQiang Su's work.
Please consider applying it.

Helmut
--- /usr/bin/dpkg-cross	2017-07-24 23:47:10.0 +0800
+++ dpkg-cross	2017-11-30 21:55:14.612364968 +0800
@@ -631,6 +631,15 @@
 			return 0;
 		}
 		while () {
+			if ($multiarch =~ m/mips(isa)?64.*-linux.*-gnuabi64.*/) {
+s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
+			} elsif ($multiarch =~ m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {
+s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
+			} elsif ($multiarch =~ m/^mips(isa32)?.*-linux.*-gnu.*/) {
+s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
+			} elsif ($multiarchtriplet eq "sparc64-linux-gnu") {
+s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
+			}
 			s:(^|[^-\w/])(/usr)?/lib/$multiarch:$1$crosslib/:g;
 			unless ($multiarch) {
 s:(^|[^-\w/])(/usr)?/lib32/:$1$crosslib32/:g;
@@ -1018,7 +1025,12 @@
 
 		# Skip links that are going to point to themselves
 		next if ($lv eq $_);
-
+		
+		# skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
+ 		# their ld.so.1 should be in lib32 and lib64.
+		next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~ m:lib/ld\.so\.1$:);
+		next if ($multiarchtriplet eq "sparc64-linux-gnu" && $_ =~ m:lib/ld-linux\.so\.2$:);
+		
 		# skip links to private modules and plugins that are not
 		# useful or packaged in the -cross package, basically anything
 		# in a directory beneath /usr/lib/. See #499292

Bug#958909: gcc-10: fails to build sparc64 cross compiler with multilib

[Helmut Grohne]

Source: gcc-10
Version: 10-20200411-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block 881687 by -1
Control: affects -1 + src:gcc-9

In #881687, YunQiang Su sent a patch that disentangles multilibs in
dpkg-cross for mipsen. The problem is that after dpkg-cross, the
relevant ld.so paths end up conflicting and some need to be discarded.
This issue also happens to affect sparc64 as both 32bit sparc and
sparc64 use ld-linux.so.2. In order to make the patch from #881687 work
for sparc64, support from gcc-N (also affects gcc-9 at least) is needed.
Like it does for mipsen, it needs to pass the relevant -l flag to
dh_shlibdeps. Please consider applying the attached patch to implement
that. The bug log in #881687 is a little confusing, but the last mail
from YunQiang Su should clear most confusion.

Helmut
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -2245,6 +2245,8 @@
 	  $(with_build_sysroot)/$(usr_lib64)) \
 	$(if $(findstring mipsn32,$(DEB_TARGET_ARCH)), \
 	  $(with_build_sysroot)/$(usr_libn32)) \
+	$(if $(filter sparc64,$(DEB_TARGET_ARCH)), \
+	  $(with_build_sysroot)/$(usr_lib64)) \
 	$(if $(filter yes,$(biarchsf) $(biarchhf)), \
 	  $(with_build_sysroot)/usr/$(call mlib_to_march,$(2))/lib) \
 	$(if $(filter yes, $(with_common_libs)),, \

Bug#898006: stretch-pu: package pcl/1.8.0+dfsg1-3

[Julien Cristau]

Control: tag -1 confirmed

On Sat, May 05, 2018 at 06:38:25PM +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> in #894656 I was asked to add libvtk6-qt-dev as a dependency to
> libpcl-dev in stretch. I would like to do this, except for armel and
> armhf which fails due to OpenGLES, cf. #835292.
> 
> The resulting debdiff is attached.
> 
Please go ahead.

Cheers,
Julien

Bug#829646: Merge request for implementation of Files-ExcludeIgnored stanza

[Reinhard Tartler]

Hi,

I took the liberty to implement this feature. Please take a look at
https://salsa.debian.org/debian/devscripts/-/merge_requests/189 and feel
free to improve it as you see fit.

The merge request includes a testcase that demonstrates the
functionality of the feature. Let me know if you have any questions.

-- 
regards,
Reinhard

Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host

[Sven Geuer]

Package: debci
Version: 2.11
Severity: normal

Dear Maintainer,

I intended to set up an armhf lxc container by running

debci setup -a armhf

as root on my amd64 system. The installation process terminated with

[...]
Timed out waiting for container to boot
lxc-stop: autopkgtest-unstable-armhf.new: tools/lxc_stop.c: main: 191
autopkgtest-unstable-armhf.new is not running
lxc-destroy: autopkgtest-unstable-armhf.new: tools/lxc_destroy.c: main: 271
Destroyed container autopkgtest-unstable-armhf.new


In /var/log/syslog I encountered these lines probably of relevance

Apr 26 17:16:25 e580sg kernel: [14086.041927] audit: type=1400
audit(1587914185.032:51): apparmor="STATUS" operation="profile_load"
profile="/usr/bin/lxc-start" name="lxc-autopkgtest-unstable-armhf.new_" pid=88028 comm="apparmor_parser"
Apr 26 17:16:25 e580sg NetworkManager[686]:   [1587914185.0606] manager:
(vethSB9884): new Veth device (/org/freedesktop/NetworkManager/Devices/22)
Apr 26 17:16:25 e580sg kernel: [14086.064571] br0: port 2(vethS5LJSK) entered
blocking state
Apr 26 17:16:25 e580sg kernel: [14086.064573] br0: port 2(vethS5LJSK) entered
disabled state
Apr 26 17:16:25 e580sg kernel: [14086.064617] device vethS5LJSK entered
promiscuous mode
Apr 26 17:16:25 e580sg kernel: [14086.064692] br0: port 2(vethS5LJSK) entered
blocking state
Apr 26 17:16:25 e580sg kernel: [14086.064693] br0: port 2(vethS5LJSK) entered
forwarding state
Apr 26 17:16:25 e580sg kernel: [14086.066265] br0: port 2(vethS5LJSK) entered
disabled state
Apr 26 17:16:25 e580sg systemd-udevd[88029]: ethtool: autonegotiation is unset
or enabled, the speed and duplex are not writable.
Apr 26 17:16:25 e580sg NetworkManager[686]:   [1587914185.0618] manager:
(vethS5LJSK): new Veth device (/org/freedesktop/NetworkManager/Devices/23)
Apr 26 17:16:25 e580sg systemd-udevd[88029]: Using default interface naming
scheme 'v245'.
Apr 26 17:16:25 e580sg systemd-udevd[88029]: Could not set Alias=, MACAddress=
or MTU= on vethSB9884: No such device
Apr 26 17:16:25 e580sg systemd-udevd[88029]: vethSB9884: Could not apply link
config, ignoring: No such device
Apr 26 17:16:25 e580sg systemd-udevd[88030]: ethtool: autonegotiation is unset
or enabled, the speed and duplex are not writable.
Apr 26 17:16:25 e580sg systemd-udevd[88030]: Using default interface naming
scheme 'v245'.
Apr 26 17:16:25 e580sg kernel: [14086.092692] eth0: renamed from vethSB9884
Apr 26 17:16:25 e580sg gnome-shell[2393]: Removing a network device that was
not added
Apr 26 17:16:25 e580sg NetworkManager[686]:   [1587914185.1205] device
(vethS5LJSK): carrier: link connected
Apr 26 17:16:25 e580sg NetworkManager[686]:   [1587914185.1209] device
(br0): carrier: link connected
Apr 26 17:16:25 e580sg kernel: [14086.124443] IPv6: ADDRCONF(NETDEV_CHANGE):
eth0: link becomes ready
Apr 26 17:16:25 e580sg kernel: [14086.124480] IPv6: ADDRCONF(NETDEV_CHANGE):
vethS5LJSK: link becomes ready
Apr 26 17:16:25 e580sg kernel: [14086.124553] br0: port 2(vethS5LJSK) entered
blocking state
Apr 26 17:16:25 e580sg kernel: [14086.124555] br0: port 2(vethS5LJSK) entered
forwarding state
Apr 26 17:16:25 e580sg kernel: [14086.152175] audit: type=1400
audit(1587914185.144:52): apparmor="DENIED" operation="mount" info="failed
flags match" error=-13 profile="/usr/bin/lxc-start" name="/proc/sys/kerne
l/random/boot_id" pid=88031 comm="lxc-start" srcname="/dev/.lxc-boot-id"
flags="rw, bind"
Apr 26 17:16:25 e580sg kernel: [14086.154374] Not activating Mandatory Access
Control as /sbin/tomoyo-init does not exist.
Apr 26 17:16:25 e580sg kernel: [14086.248964] br0: port 2(vethS5LJSK) entered
disabled state
Apr 26 17:16:25 e580sg kernel: [14086.250781] device vethS5LJSK left
promiscuous mode
Apr 26 17:16:25 e580sg kernel: [14086.250785] br0: port 2(vethS5LJSK) entered
disabled state
Apr 26 17:16:25 e580sg NetworkManager[686]:   [1587914185.2731] device
(vethS5LJSK): released from master device br0
Apr 26 17:16:25 e580sg gnome-shell[2393]: Removing a network device that was
not added
Apr 26 17:16:25 e580sg kernel: [14086.394930] audit: type=1400
audit(1587914185.384:53): apparmor="STATUS" operation="profile_remove"
profile="/usr/bin/lxc-start" name="lxc-autopkgtest-unstable-
armhf.new_" pid=88076 comm="apparmor_parser"

These are the installed qemu packages

$ LANG=C dpkg -l 'qemu-*' | grep -v '^un'
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 VersionArchitecture Description
+++--==--==
ii  qemu-efi-aarch64 0.0~20200229-2 all  UEFI firmware for
64-bit ARM virtual machines
ii  qemu-efi-arm 0.0~20200229-2 all  UEFI firmware for
32-bit ARM virtual machines
ii  qemu-kvm 1:4.2-6amd64QEMU Full
virtualization 

Bug#921319: stretch-pu: package iptables-persistent/1.0.4+nmu2

[Julien Cristau]

Control: tag -1 confirmed

On Tue, Feb 05, 2019 at 12:56:50PM +0800, gustavo panizzo wrote:
> hello
> 
> On Mon, Feb 04, 2019 at 05:05:25PM +0100, Bastian Blank wrote:
> > On Mon, Feb 04, 2019 at 10:55:26PM +0800, gustavo panizzo wrote:
> > > On Mon, Feb 04, 2019 at 09:59:06AM +, Adam D. Barratt wrote:
> > > > Control: tags -1 + moreinfo
> > > >
> > > > On 2019-02-04 08:11, gustavo panizzo wrote:
> > > > > I'd like to fix the bug #921186 in stable, only adding a dependency to
> > > > > iptables-persistent the bug can be closed
> > > >
> > > > The metadata for that bug suggests that the bug also affects the package
> > > > in unstable, and is not yet fixed there - is that correct? If so, please
> > > > fix the bug in unstable first; if not, please fix the metadata.
> > > I've fixed the metadata, thanks
> > 
> > The bug is fixed differently in unstable?
> > 
> 
> After thinking on how I solved this issue in unstable (#794037,
> #720110) I came up with another solution, similar to what's done in
> unstable
> 
> Initially I didn't want to modify the scripts but the initial fix (add
> kmod to deps) won't solve #720110 for the reporter, I think the current
> proposed fix is better and the risk of regressions is low
> 
> debdiff attached
> 
Looks OK, but:

> diff -Nru iptables-persistent-1.0.4+nmu2/debian/changelog 
> iptables-persistent-1.0.4+nmu3/debian/changelog
> --- iptables-persistent-1.0.4+nmu2/debian/changelog   2017-03-18 
> 21:11:49.0 +0800
> +++ iptables-persistent-1.0.4+nmu3/debian/changelog   2019-02-03 
> 19:18:27.0 +0800
> @@ -1,3 +1,10 @@
> +iptables-persistent (1.0.4+nmu3) stable; urgency=medium

Please make that "1.0.4+nmu2+deb9u1" and "stretch".

Cheers,
Julien

> +
> +  * Non-maintainer upload
> +  * Catch errors in calls to modprobe, thanks Hugo, Closes (#921186)
> +
> + -- gustavo panizzo   Sun, 03 Feb 2019 19:18:27 +0800
> +
>  iptables-persistent (1.0.4+nmu2) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -Nru iptables-persistent-1.0.4+nmu2/plugins/15-ip4tables 
> iptables-persistent-1.0.4+nmu3/plugins/15-ip4tables
> --- iptables-persistent-1.0.4+nmu2/plugins/15-ip4tables   2017-03-18 
> 21:11:49.0 +0800
> +++ iptables-persistent-1.0.4+nmu3/plugins/15-ip4tables   2019-02-03 
> 19:18:27.0 +0800
> @@ -31,7 +31,7 @@
>  {
>   #save IPv4 rules
>   #need at least iptable_filter loaded:
> - /sbin/modprobe -q iptable_filter
> + /sbin/modprobe -q iptable_filter || true
>   if [ ! -f /proc/net/ip_tables_names ]; then
>   echo "Warning: skipping IPv4 (no modules loaded)"
>   elif [ -x /sbin/iptables-save ]; then
> diff -Nru iptables-persistent-1.0.4+nmu2/plugins/25-ip6tables 
> iptables-persistent-1.0.4+nmu3/plugins/25-ip6tables
> --- iptables-persistent-1.0.4+nmu2/plugins/25-ip6tables   2017-03-18 
> 21:11:49.0 +0800
> +++ iptables-persistent-1.0.4+nmu3/plugins/25-ip6tables   2019-02-03 
> 19:18:27.0 +0800
> @@ -31,7 +31,7 @@
>  {
>   #save IPv6 rules
>   #need at least ip6table_filter loaded:
> - /sbin/modprobe -q ip6table_filter
> + /sbin/modprobe -q ip6table_filter || true
>   if [ ! -f /proc/net/ip6_tables_names ]; then
>   log_action_cont_msg "Warning: skipping IPv6 (no modules loaded)"
>   elif [ -x /sbin/ip6tables-save ]; then

Bug#947142: buster-pu: package python-oslo.utils/3.36.4-2 CVE-2019-3866

[Thomas Goirand]

On 4/25/20 9:45 PM, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> Apologies for the delay.
> 
> On Sat, 2019-12-21 at 22:13 +0100, Thomas Goirand wrote:
>> I'd like to update python-oslo.utils in Buster to address CVE-2019-
>> 3866.
>> It wasn't possible to apply directly the patch available here:
>>
>> https://review.opendev.org/692972
>>
>> and I found too dangerous to skip the commits right before it, which
>> are related to this patch. So I just merged upstream branch
>> stable/rocky into the Debian package. However, looking closer to all
>> patches, either they are all related to the official patch, or are
>> cosmetic from the Debian perspective (ie: .gitreview, or upstream CI
>> related).
>>
>> Please find, attached to this bug, the debdiff for the udpate.
>>
> 
> +python-oslo.utils (3.36.4+2019.11.15.git.c49a426b66-1+deb10u1) buster;
> urgency=medium
> 
> I'd prefer -0+deb10u1 there, as there was (I presume) never a -1 upload
> to Debian.
> 
> With that change, please go ahead.
> 
> Regards,
> 
> Adam

Hi,

Checking upstream, since my proposal to update this package, version
3.36.5 has been released, incorporating the change. The only difference
between 3.36.4+2019.11.15.git.c49a426b66 and 3.36.5 is added release
notes, which aren't even packaged in the binary. So I took the liberty
to upgrade to that instead, which is IMO cleaner, and doesn't change
anything regarding Debian.

The resulting package is uploaded to buster with 3.36.5-0+deb10u1 as
version number.

Cheers,

Thomas Goirand (zigo)

Bug#912956: ttf-mscorefonts-installer: Should use https URLs

[Christoph Anton Mitterer]

Hey.

Why would it be best to use HTTPS?

TLS alone, with its broken CA ecosystem, doesn't give any real
security... and the downloaded files have their hash sums already
verified (which is the real thing that gives security and trust here)
by the downloader.

The only thing one gets is an additional dependency on CA certificates
and problems like when certs would expire.


Cheers,
Chris-

Bug#948333: buster-pu: package frr/6.0.2-2

[Thomas Goirand]

On 4/26/20 4:06 PM, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sun, 2020-04-26 at 13:11 +0200, Thomas Goirand wrote:
>> On 4/25/20 9:05 PM, Adam D. Barratt wrote:
>>> Control: tags -1 + moreinfo
>>>
>>> On Tue, 2020-01-07 at 14:05 +0100, Thomas Goirand wrote:
 On 1/7/20 2:01 PM, Thomas Goirand wrote:
> As per the issue described here:
> https://github.com/FRRouting/frr/issues/3251
>
> extended next hop capability does not work in Debian Buster.
> As a consequence, we aren't able to advertize for an IP
> address on our local loopback through the IPv6 link local,
> which is how we would like to do BGP to the host.
>
> Note that this issue is from version 5.0.1 up to version
> 7.2 (which is in Sid), so I took the time to cherry-pick the
> fix from upstream. I have attached the resulting debdiff, and
> opened the bug against the frr package itself.
>>> [...]
 FYI, frr bug number is:
 https://bugs.debian.org/cgi-bin/948332
>>>
>>> Apologies for the delay in getting back to you.
>>>
>>> The description above, and the metadata on the referenced bug
>>> report, suggest that the issue still affects the package in
>>> unstable. Is that correct?
> [...]
>> It's not correct. The version in unstable, 7.2.1, contains the
>> upstream fix for this problem.
> 
> Then https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948332 should
> have a fixed version which indicates that.
> 
> Please feel free to go ahead, but please do fix the metadata.
> 
> Regards,
> 
> Adam

Thanks. Uploaded. BTS metadata updated.

Cheers,

Thomas Goirand (zigo)

Bug#958911: ITP: python-xstatic-dagre -- Graph layout for JavaScript XStatic support

[Michal Arbet]

Package: wnpp
Severity: wishlist
Owner: Michal Arbet 

* Package name: python-xstatic-dagre
  Version : 0.6.4.0
  Upstream Author : Chris Pettitt
* URL : https://github.com/dagrejs/dagre
* License : MIT
  Programming Lang: Python
  Description : Graph layout for JavaScript XStatic support

XStatic is a packaging standard to package external (often 3rd party) static
 files as a Python package, so they are easily usable on all operating
systems,
 with any package management system or even without one.
 .
 Many Python projects need to use some specific data files, like javascript,
 css, java applets, images, etc. Sometimes these files belong to YOUR
project
 (then you may want to package them separately, but you could also just put
 them into your main package). But in many other cases, those files are
 maintained by someone else (like jQuery javascript library or even much
bigger
 js libraries or applications) and you definitely do not really want to
merge
 them into your project. So, you want to have static file packages, but you
 don’t want to get lots of stuff you do not want. Thus, stuff required by
 XStatic file packages (especially the main, toplevel XStatic package)
tries to
 obey to be a MINIMAL, no-fat thing. XStatic doesn't "sell" any web
framework
 or other stuff you don't want. Maybe there will be optional XStatic
extensions
 for all sorts of stuff, but they won't be required if you just want the
files.
 .
 By having static files in packages, it is also easier to build virtual
envs,
 support linux/bsd/... distribution package maintainers and even windows
 installs using the same mechanism.
 .
 This package providesGraph layout for JavaScript support.