Bug#987517: dipy: attempts to access network resources during build

2021-04-25 Thread Étienne Mollier
Source: dipy
Version: 1.3.0-2
Severity: serious
Justification: Policy 4.9

Dear Fellow Maintainers,

While working on #987453 affecting python3-dipy-lib, I noticed
that the build time test suite behaved differently depending
whether I had network access, or was working in an insulated
virtual machine environment.  I'm under the strong impression
the test suite fetches resources over the Internet.

I forced the proxy to non-configured address http://0.0.0.0 as a
quick & dirty way to disable the network access, and also tested
in offline virtual machine to validate my observations.

When online, the build shows these progress bars, example:


/<>/.pybuild/cpython3_3.9_dipy/build/dipy/viz/__init__.py:31: 
UserWarning: You do not have FURY installed. Some visualization functions might 
not work for you. For installation instructions, please visit: https://fury.gl/
  warnings.warn(

  0%|  | 0/1 [00:00>/.pybuild/cpython3_3.9_dipy/build/dipy/viz/__init__.py:31: 
UserWarning: You do not have FURY installed. Some visualization functions might 
not work for you. For installation instructions, please visit: https://fury.gl/
  warnings.warn(

Set numpy print options to "legacy" for new versions of numpy. ... ok
ERROR

These tests should probably be skipped if the point is to test
availability of resources; or just disable network access with
http_proxy altogether, since the outcome of build-time testing
is not checked anyway.

Kind Regards,
Étienne.


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

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

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


signature.asc
Description: PGP signature


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

2021-04-25 Thread Camaleón
Package: opendnssec
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 
# opendnssec po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the opendnssec package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: opendnssec\n"
"Report-Msgid-Bugs-To: opendns...@packages.debian.org\n"
"POT-Creation-Date: 2019-02-18 21:17+0100\n"
"PO-Revision-Date: 2021-04-14 16:49+0200\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: note
#. Description
#: ../opendnssec-common.templates:1001
msgid "OpenDNSSEC 2.0.0 database and tools migration"
msgstr "Migración de base de datos y herramientas de OpenDNSSEC 2.0.0"

#. Type: note
#. Description
#: ../opendnssec-common.templates:1001
msgid ""
"There are two steps in the database migration.  If you are running "
"OpenDNSSEC 1.4.6 from Debian stable, you need to apply the SQL statements "
"from /usr/share/opendnssec/migrate_1_4_8.{mysql,sqlite3} against your "
"existing database."
msgstr ""
"La migración de la base de datos comprende dos fases. Si está ejecutando "
"OpenDNSSEC 1.4.6 en la versión estable de Debian, tendrá que aplicar las "
"sentencias SQL que se encuentran en «/usr/share/opendnssec/migrate_1_4_8."
"{mysql,sqlite3}» contra la base de datos existente."

#. Type: note
#. Description
#: ../opendnssec-common.templates:1001
msgid ""
"The enforcer does require a full migration, as the internal database has "
"been completely revised.  See the upstream documentation in the /usr/share/"
"opendnssec/1.4-2.0_db_convert/README.md for a description."
msgstr ""
"El ejecutor («enforcer») necesita una migración completa, ya que la base "
"de datos interna ha sido completamente revisada. Consulte la documentación "
"previa disponible en «/usr/share/opendnssec/1.4-2.0_db_convert/README.md» "
"para una descripción detallada."

#. Type: note
#. Description
#: ../opendnssec-common.templates:1001
msgid ""
"You should also review the documentation on the OpenDNSSEC site.  This can "
"be updated in between releases to provide more help.  Especially if you have "
"tooling around OpenDNSSEC you should be aware that some command line "
"utilities have changed.  A fair amount of backward compatibility has been "
"respected, but changes are present."
msgstr ""
"También debería consultar la documentación de la página de OpenDNSSEC ya que "
"ha podido ser actualizada entre las versiones para ofrecer un mejor soporte. "
"En particular, si ha desarrollado herramientas en torno a OpenDNSSEC, tenga "
"en cuenta que han cambiado algunas utilidades en línea de órdenes. Se ha "
"respetado una cantidad considerable de compatibilidad con versiones 
anteriores, "
"pero hay modificaciones."

#. Type: note
#. Description
#: ../opendnssec-common.templates:2001
msgid "Manual OpenDNSSEC configuration required"
msgstr "Se requiere una configuración manual de OpenDNSSEC"

#. Type: note
#. Description
#: ../opendnssec-common.templates:2001
msgid ""
"OpenDNSSEC requires manual configuration before the signer and enforcer "
"daemons can be started."
msgstr ""
"OpenDNSSEC requiere una configuración manual antes de poder iniciar los "
"demonios de firma («signer») y ejecución («enforcer»)."

#. Type: note
#. Description
#: ../opendnssec-common.templates:2001
msgid ""
"One of these configuration steps consists of installing and configuring a "
"Hardware Security Module (HSM) that will handle the cryptographic key "
"operations. Most people will want to use the software HSM implementation "
"provided by the recommended softhsm2 package, but other options are possible."
msgstr ""
"Una de las fases de configuración consiste en instalar y configurar el módulo "
"de seguridad de hardware («Hardware Security Module - HSM») que gestionará "
"las operaciones de clave criptográfica. La mayoría de los usuarios querrán "
"utilizar la implementación del programa HSM que proporciona el paquete "
"recomendado softhsm2, pero existen otras alternativas." 

#. Type: note
#. Description
#: ../opendnssec-common.templates:2001
msgid ""
"The file /etc/opendnssec/prevent-startup is created during fresh "
"installations and prevents the daemons from being automatically started. You "
"should remove this file and start the daemons once you have configured "
"OpenDNSSEC."
msgstr ""
"El archivo «/etc/opendnssec/prevent-startup» se crea en las nuevas "
"instalaciones y evita que los demonios se inicien automáticamente. Debería "
"eliminar este archivo e iniciar los demonios una vez que haya configurado "
"OpenDNSSEC."


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

2021-04-25 Thread Camaleón
Package: usrmerge
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 
# usrmerge po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the usrmerge package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: usrmerge\n"
"Report-Msgid-Bugs-To: usrme...@packages.debian.org\n"
"POT-Creation-Date: 2016-02-12 03:06+0100\n"
"PO-Revision-Date: 2021-04-14 08:41+0200\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: title
#. Description
#: ../usrmerge.templates:1001
msgid "Automatic conversion to merged /usr"
msgstr "Conversión automática a /usr combinado"

#. Type: boolean
#. Description
#: ../usrmerge.templates:2001
msgid ""
"Do you want to convert this system to the merged /usr directories scheme?"
msgstr ""
"¿Desea configurar este sistema para usar el esquema de directorios "
"combinados /usr?"

#. Type: boolean
#. Description
#: ../usrmerge.templates:2001
msgid ""
"The usrmerge package will automatically convert the system to the merged /"
"usr directory scheme, in which the /{bin,sbin,lib}/ directories are "
"symlinked to their counterparts in /usr/."
msgstr ""
"El paquete usrmerge ajustará automáticamente el sistema para utilizar "
"un esquema de directorios combinados /usr, en el que los directorios "
"/{bin,sbin,lib}/ están enlazados simbólicamente con sus homólogos en /usr/."

#. Type: boolean
#. Description
#: ../usrmerge.templates:2001
msgid ""
"There is no automatic method to restore the precedent configuration, so "
"there is no going back once the conversion has been started."
msgstr ""
"No existe un método automático para restablecer la configuración anterior, "
"por lo que una vez iniciado el proceso de conversión, no podrá revertirlo."


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

2021-04-25 Thread Camaleón
Package: kdump-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 
# makedumpfile po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the makedumpfile package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: makedumpfile\n"
"Report-Msgid-Bugs-To: makedumpf...@packages.debian.org\n"
"POT-Creation-Date: 2016-06-10 12:46+0200\n"
"PO-Revision-Date: 2021-04-14 09:16+0200\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
#: ../kdump-tools.templates:1001
msgid "Should kdump-tools be enabled by default?"
msgstr "¿Debería activarse kdump-tools de manera predeterminada?"

#. Type: boolean
#. Description
#: ../kdump-tools.templates:1001
msgid ""
"If you choose this option, the kdump-tools mechanism will be enabled. A "
"reboot is still required in order to enable the crashkernel kernel parameter."
msgstr ""
"Si elije esta opción, se activará el mecanismo kdump-tools. Aún tiene que "
"reiniciar el equipo para activar el parámetro crashkernel del kernel."


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

2021-04-25 Thread Camaleón
Package: buildbot
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 
# buildbot po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the buildbot package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: buildbot\n"
"Report-Msgid-Bugs-To: build...@packages.debian.org\n"
"POT-Creation-Date: 2019-01-08 11:33+0100\n"
"PO-Revision-Date: 2021-04-14 09:25+0200\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
#: ../buildbot.templates:1001
msgid "Upgrade buildbot master instances when installing new versions?"
msgstr "¿Desea actualizar las instancias maestras de buildbot al instalar 
nuevas versiones?"

#. Type: boolean
#. Description
#: ../buildbot.templates:1001
msgid ""
"Stop, run ``buildbot upgrade-master'' and restart all buildbot master "
"instances when installing new versions."
msgstr ""
"Detener, ejecutar «buildbot upgrade-master» y reiniciar todas las "
"instancias maestras de buildmaster cuando se instalen nuevas versiones."

#. Type: boolean
#. Description
#: ../buildbot.templates:1001
msgid ""
"Please note that the ``buildbot upgrade-master'' operation is potentially "
"destructive and it is irreversible. It is not possible to \"downgrade\" an "
"upgraded master instance. For these reasons, some users may want to do "
"backups before doing it manually."
msgstr ""
"Por favor, tenga en cuenta que la operación «buildbot upgrade-master» "
"es potencialmente destructiva e irreversible. No se puede revertir la "
"actualización de una instancia maestra. Por ese motivo, es posible "
"que algunos usuarios quieran realizar una copia de seguridad antes de "
"ejecutarlo manualmente."

#. Type: boolean
#. Description
#: ../buildbot.templates:1001
msgid ""
"However, this operation is mandatory and buildbot will fail to restart a "
"master instance if it has not been performed. See buildbot(7) for more "
"details."
msgstr ""
"Sin embargo, es una operación necesaria y buildbot no podrá reiniciar una "
"instancia maestra si no se ha ejecutado esta operación. Consulte buildbot(7) "
"para más detalles."


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

2021-04-25 Thread Camaleón
Package: x2gobroker
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 
# x2gobroker po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the x2gobroker package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: x2gobroker\n"
"Report-Msgid-Bugs-To: x2gobro...@packages.debian.org\n"
"POT-Creation-Date: 2019-02-03 11:44+0100\n"
"PO-Revision-Date: 2021-04-14 15:32+0200\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
#: ../x2gobroker-ssh.templates:2001
msgid "Create group for X2Go Broker SSH access now?"
msgstr "¿Desea crear un grupo para el acceso SSH al broker de X2Go?"

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:2001
msgid ""
"In X2Go Session Broker, SSH-based broker access is controlled via the broker "
"users' membership in a dedicated group (default: x2gobroker-users)."
msgstr ""
"En X2Go Session Broker, el acceso al broker basado en SSH se controla a través 
"
"de la pertenencia de los usuarios del broker a un grupo dedicado 
(predeterminado: "
"x2gobroker-users)."

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:2001
msgid ""
"If this group is not created now, you will be asked to assign this privilege "
"to an existing group instead."
msgstr ""
"Si no crea este grupo ahora, en su lugar se le pedirá que asigne este "
"privilegio a un grupo existente."

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:3001
msgid "Use an already existing group for X2Go Session Broker SSH access?"
msgstr "¿Desea utilizar un grupo existente para el acceso SSH de X2Go Session?"
"Broker?"

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:3001
msgid ""
"If there already exists a group (e.g. in an LDAP database) that you would "
"like to use for controlling X2Go Session Broker SSH access with, then you "
"can specify this group name with the next step."
msgstr ""
"Si ya existe un grupo que desea utilizar para controlar el acceso SSH a "
"X2Go Session Broker (p. ej., en una base de datos LDAP), puede indicar "
"el nombre de este grupo en el siguiente apartado."

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:4001
msgid "Set up X2Go Session Broker SSH access later?"
msgstr "¿Desea configurar el acceso SSH a X2Go Session Broker en otro momento?"

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:4001
msgid ""
"Without an existing group for X2Go Session Broker SSH access, the SSH broker "
"will not be usable by users. You have to set up things later, either "
"manually or via this configuration helper."
msgstr ""
"Si no existe un grupo para el acceso SSH a X2Go Session Broker, los usuarios "
"no podrán usar el broker SSH. Tendrá que configurarlo más adelante, bien "
"manualmente o a través de este asistente de configuración."
""

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:4001
msgid ""
"A manual setup is only recommended, if you really know what have to do for "
"this."
msgstr ""
"Solo se recomienda realizar una configuración manual si realmente sabe lo "
"que tiene que hacer."

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:4001
msgid "Alternatively, the setup questions can be asked once more..."
msgstr "Alternativamente, se le pueden hacer las preguntas de configuración "
"una vez más..."

#. Type: string
#. Description
#: ../x2gobroker-ssh.templates:5001
msgid "X2Go Session Broker SSH access group:"
msgstr "Grupo para el acceso SSH de X2Go Session Broker:"

#. Type: string
#. Description
#: ../x2gobroker-ssh.templates:5001
msgid ""
"Please specify the group name for users with full X2Go Session Broker access "
"via SSH now."
msgstr ""
"Por favor, indique el nombre del grupo de los usuarios con derechos de acceso "
"a X2Go Session Broker a través de SSH."

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:6001
msgid ""
"Delete the group that was formerly used for X2Go Session Broker SSH access?"
msgstr ""
"¿Desea eliminar el grupo utilizado anteriormente para el acceso SSH a X2Go "
"Session Broker?"

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:6001
msgid "The group for X2Go Session Broker SSH access has been modified."
msgstr "Se ha modificado el grupo para el acceso SSH a X2Go Session Broker."

#. Type: boolean
#. Description
#: ../x2gobroker-ssh.templates:6001
msgid ""
"Please specify whether the old group should be deleted from your system. If "
"unsure, keep the formerly used group and manually investigate later."
msgstr ""
"Por favor, indique si debe eliminarse el grupo antiguo de su sistema. Si no "
"está seguro, conserve el grupo anterior e investigue después."

#. Type: note
#. Description
#: ../x2gobroker-ssh

Bug#754193: linux-image-3.2.0-4-amd64: reboot(2) called from a PID namespace shuts down a host

2021-04-25 Thread Salvatore Bonaccorso
Hi,

On Tue, Jul 08, 2014 at 05:30:48PM +0100, Ben Hutchings wrote:
> On Tue, 2014-07-08 at 16:33 +0200, Łukasz Stelmach wrote:
> > Package: src:linux
> > Version: 3.2.60-1+deb7u1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > tl;dr: init in a container (PID namespace) can call reboot(2) and
> > shutdown the host machine.
> 
> Yes, and you need real user namespaces (as introduced in Linux 3.7) to
> prevent this.
> 
> > Please refer to [1] for a detailed description of symptoms.
> > 
> > After some investigation and thanks to help received from systemd
> > developers I can tell the problems can be solved by applying [2] to the
> > kernel. The patch is relatively old, it has been released only three
> > months after 3.2.0 so I hope applying it wouldn't be a problem.
> [...]
> 
> This change seems to make containers work better, but it does not
> improve security.  I'm not sure whether this is sufficient justification
> for a stable update.  Please can you ask the stable release team
> (debian-rele...@lists.debian.org) to consider this.

I'm still inclinded to close this bug now, would you agree?

Regards,
Salvatore



Bug#987523: O: jugglinglab -- Application for creating and animating juggling patterns

2021-04-25 Thread David Rabel
Package: wnpp
Severity: normal

For more information see RFA (open for about two years):

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

Yours
  David


-- 
⚑ libertⒶd ⚑



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987524: O: vim-lastplace -- Vim script to reopen files at your last edit position

2021-04-25 Thread David Rabel
Package: wnpp
Severity: normal


For more information see RFA (open for about two years):


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

Yours
  David


-- 
⚑ libertⒶd ⚑



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987525: binutils64: Missing Built-Using for binutils

2021-04-25 Thread Adrian Bunk
Source: binutils64
Version: 1+c3
Severity: serious

binutils64 needs a Built-Using for binutils:
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using



Bug#987526: binutils64 FTBFS: Failed to apply patches

2021-04-25 Thread Adrian Bunk
Source: binutils64
Version: 1+c3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/binutils64.html

...
cd binutils-2.35.2 ;\
  for i in `ls /build/1st/binutils64-1+c3/debian/patches/binutils/*.patch 
2>/dev/null`; do \
patch -p1 < $i; \
  done;
patching file debian/binutils-multiarch.postrm.in
patching file debian/binutils-multiarch.preinst.in
patching file debian/binutils64.postrm.in
patching file debian/binutils64.preinst.in
patching file debian/control.host64.in
patching file debian/control.in
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file debian/control.in.rej
patching file debian/rules
Hunk #4 succeeded at 357 (offset 10 lines).
Hunk #5 succeeded at 409 (offset 10 lines).
Hunk #6 succeeded at 605 (offset 11 lines).
Hunk #7 succeeded at 626 (offset 11 lines).
Hunk #8 succeeded at 644 (offset 11 lines).
Hunk #9 succeeded at 1006 (offset 16 lines).
Hunk #10 succeeded at 1079 (offset 16 lines).
Hunk #11 succeeded at 1113 (offset 16 lines).
Hunk #12 succeeded at 1438 (offset 20 lines).
Hunk #13 succeeded at 1688 (offset 20 lines).
Hunk #14 succeeded at 1764 (offset 20 lines).
Hunk #15 succeeded at 1922 (offset 20 lines).
Hunk #16 succeeded at 2000 with fuzz 1 (offset 20 lines).
Hunk #17 succeeded at 2038 (offset 19 lines).
make: *** [debian/rules:57: stamp-dir/prepare] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2



Bug#985947: CVE-2021-28543

2021-04-25 Thread Moritz Muehlenhoff
On Sun, Apr 25, 2021 at 08:14:02AM +0200, Salvatore Bonaccorso wrote:
> Hi Tobi,
> 
> On Sat, Apr 24, 2021 at 10:33:36PM +0200, Tobias Frost wrote:
> > Package: varnish-modules
> > Followup-For: Bug #985947
> > Control: tags -1 unreproducible
> > Control: close -1
> > 
> > According to https://varnish-cache.org/security/VSV6.html the only 
> > affected
> > version is 0.17.0:
> 
> This btw, is often not enought to determine something is not affected.
> There are upstream which explicitly list only in their advisories, the
> currently affected and supported versions, other do deeper
> investigation and list the full range. Thus such a statement needs to
> be taken always with a grain of salt.

Indeed, that's why we typically file bugs regardless unless some package
is obviously not affected.

> > Therefore, closing the bug. If you disagree, please reopen.
> 
> Looking at the code indeed, it looks to me that the respective code
> around checking the b variable is not present, I guess the issue was
> introducing while switching to strands, around commit
> b4d5927a2fbba31b1213225138f8432572414a24, wich indeed would be in
> 0.17.0 only onwards (for the varnish-modules).
> 
> So I'm inclined to follow you and marking this really as not-affected
> for us.
> 
> Moritz, do you agree?

Agreed.

Cheers,
Moritz



Bug#987527: clonezilla: Fails to install on bullseye

2021-04-25 Thread Matthias Gies
Package: clonezilla
Version: 3.35.2-2
Severity: important
X-Debbugs-Cc: matthiasg...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Simply tried to install clonezilla via apt on a working bullseye system.

   * What was the outcome of this action?
Error on install:
clonezilla (3.35.2-2) wird eingerichtet ...
ln: die symbolische Verknüpfung '/opt/' konnte nicht angelegt werden: Datei 
oder Verzeichnis nicht gefunden
dpkg: Fehler beim Bearbeiten des Paketes clonezilla (--configure):
 »installiertes clonezilla-Skript des Paketes post-installation«-Unterprozess 
gab den Fehlerwert 1 zurück
Trigger für man-db (2.9.4-2) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 clonezilla
E: Sub-process /usr/bin/dpkg returned an error code (1)

   * What outcome did you expect instead?
Clean install.


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

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

Versions of packages clonezilla depends on:
ii  bc  1.07.1-2+b2
ii  dialog  1.3-20201126-1
pn  drbl
ii  e2fsprogs   1.46.2-1
ii  fdisk   2.36.1-7
ii  file1:5.39-3
ii  gdisk   1.0.6-1.1
ii  pigz2.6-1
ii  util-linux  2.36.1-7

Versions of packages clonezilla recommends:
pn  partclone  
pn  partimage  

Versions of packages clonezilla suggests:
ii  cifs-utils  2:6.11-1
ii  openssh-client  1:8.4p1-5
ii  sshfs   3.7.1+repack-1
pn  udpcast 


Bug#987528: ghdl-gcc: Missing Built-Using for gcc

2021-04-25 Thread Adrian Bunk
Package: ghdl-gcc
Version: 0.35+git20181129+dfsg-3
Severity: serious

ghdl-gcc needs a Built-Using for gcc:
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using



Bug#987488: unblock: irssi/20210314-1

2021-04-25 Thread Graham Inggs
Control: retitle -1 unblock: ircii/20210314-1
Contro: tags -1 + moreinfo

Hi Jan

On Sat, 24 Apr 2021 at 16:21, Jan Wagner  wrote:
> [ Risks ]
> While the diffstat looks huge, a significant part is removed code.

This debdiff is unreviewable.  Please provide a filtered debdiff along
with the command used to filter it.

++ Bump Debhelper-compat to 13.

Bumping the debehlper compat level is not accepted at this stage of
the release [1].
Please revert this change.

> unblock irssi/20210314-1

I'm assuming this is a typo and you meant ircii/20210314-1 here.

Regards
Graham


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



Bug#987529: buster-pu: package exactimage/1.0.2-1+deb10u1

2021-04-25 Thread Sven Eckelmann
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
X-Debbugs-CC: Moritz Mühlenhoff 
X-Debbugs-CC: Adrian Bunk 
Usertags: pu

[ Reason ]
The upload of openexr 2.2.1-4.1+deb10u1 to Debian Buster broke the build for 
pre-C++-11 packages which include the openexr headers. The build breaks with 
things like:

In file included from /usr/include/c++/8/cstdint:35,
 from /usr/include/OpenEXR/ImfFrameBuffer.h:55,
 from /usr/include/OpenEXR/ImfInputFile.h:47,
 from codecs/openexr.cc:24:
/usr/include/c++/8/bits/c++0x_warning.h:32:2: error: #error This file 
requires compiler and library support for the ISO C++ 2011 standard. This 
support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support \
  ^

The build system changes to switch from -std=gnu++98 to GCC-default from 
exactimage 1.0.2-8 was added to the Debian buster package to fix the FTBFS on 
buster.

[ Impact ]
Package fails to build under Debian Buster 10.6 (and newer)

[ Tests ]
The build was tested to verify that it actually builds now. Only minor tests 
were performed on the binaries to make sure that they don't immediately crash.

[ Risks ]
None known at the moment

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in stable
  [*] the issue is verified as fixed in unstable

[ Other info ]
See http://bugs.debian.org/968829 bug which was just recently re-opened for 
the regression in Debian Buster.

I have not yet uploaded the change to stable but will do this after I get an 
approval for the attached change.

Kind regards,
Svendiff -Nru exactimage-1.0.2/debian/changelog exactimage-1.0.2/debian/changelog
--- exactimage-1.0.2/debian/changelog	2019-02-03 17:49:58.0 +0100
+++ exactimage-1.0.2/debian/changelog	2021-04-25 07:57:10.0 +0200
@@ -1,3 +1,16 @@
+exactimage (1.0.2-1+deb10u1) buster; urgency=medium
+
+  * debian/rules:
+- Add -fpermissive to fix FTBFS due to missing C++11 "constexp"
+  * debian/patches:
+- Add adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch,
+  added-fpermissive-where-currently-necessary.patch,
+  if-we-can-not-easily-use-the-input-module-name-for-C-FLAS.patch,
+  Updated-per-file-C-FLAGS-to-likely-final-delimiter.patch,
+  Fix build with C++11 and OpenEXR 2.5.x (Closes: #968829)
+
+ -- Sven Eckelmann   Sun, 25 Apr 2021 07:57:10 +0200
+
 exactimage (1.0.2-1) unstable; urgency=medium
 
   * New Upstream Version
diff -Nru exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch
--- exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch	1970-01-01 01:00:00.0 +0100
+++ exactimage-1.0.2/debian/patches/adapt-for-nicer-per-file-_C-FLAGS-per-source-input-name.patch	2021-04-25 07:57:10.0 +0200
@@ -0,0 +1,38 @@
+From: rene 
+Date: Sun, 29 Sep 2019 19:42:13 +
+Subject: * adapt for nicer per file _C*FLAGS per source input name
+
+Bug-Debian: https://bugs.debian.org/968580
+Origin: upstream, https://svn.exactcode.de/exact-image/trunk@2349 cfa9e8bd-72fe-0310-85ed-f28a7036cb6a
+---
+ api/Makefile   | 2 +-
+ frontends/Makefile | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/api/Makefile b/api/Makefile
+index 243a27a..1240ab1 100644
+--- a/api/Makefile
 b/api/Makefile
+@@ -9,7 +9,7 @@ CPPFLAGS += $(BARDECODEINCS)
+ LDFLAGS += $(BARDECODELIBS)
+ endif
+ 
+-objdir/api/api.o_CXXFLAGS := -fpermissive
++$(X_MODULE)/api.cc_CXXFLAGS := -fpermissive
+ 
+ # we have an own install
+ _X_BUILD_IMPLICIT := $(_X_BUILD_IMPLICIT)
+diff --git a/frontends/Makefile b/frontends/Makefile
+index 875be16..3ebea5a 100644
+--- a/frontends/Makefile
 b/frontends/Makefile
+@@ -15,7 +15,7 @@ DEPS = $(image_BINARY) $(codecs_BINARY) $(bardecode_BINARY) $(X_OUTARCH)/utility
+ CPPFLAGS += -I utility
+ #LDFLAGS += -lGL -lGLU -lglut -L/usr/X11/lib64
+ 
+-objdir/frontends/bardecode.o_CXXFLAGS := -fpermissive
+-objdir/frontends/econvert.o_CXXFLAGS := -fpermissive
++$(X_MODULE)/bardecode.cc_CXXFLAGS := -fpermissive
++$(X_MODULE)/econvert.cc_CXXFLAGS := -fpermissive
+ 
+ include build/bottom.make
diff -Nru exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch
--- exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch	1970-01-01 01:00:00.0 +0100
+++ exactimage-1.0.2/debian/patches/added-fpermissive-where-currently-necessary.patch	2021-04-25 07:57:10.0 +0200
@@ -0,0 +1,48 @@
+From: rene 
+Date: Sun, 29 Sep 2019 19:22:47 +
+Subject: * added -fpermiss

Bug#987530: node-end-of-stream FTBFS in buster

2021-04-25 Thread Adrian Bunk
Source: node-end-of-stream
Version: 1.4.1-1
Severity: serious
Tags: ftbfs
Control: close -1 1.4.4-1

https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/node-end-of-stream.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/node-end-of-stream-1.4.1'
node test.js
assert.js:339
throw err;
^

AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert(expected === 0)

at Timeout._onTimeout (/build/node-end-of-stream-1.4.1/test.js:84:2)
at ontimeout (timers.js:436:11)
at tryOnTimeout (timers.js:300:5)
at listOnTimeout (timers.js:263:5)
at Timer.processTimers (timers.js:223:10)
make[1]: *** [debian/rules:12: override_dh_auto_test] Error 1



The FTBFS started when nodejs 10.19.0~dfsg1-1 entered buster.



Bug#987531: buster-pu: package opendmarc/1.3.2-6+deb10u2

2021-04-25 Thread Utkarsh Gupta
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
User: debian-rele...@lists.debian.org
Usertags: bsp-2021-04-at-salzburg
X-Debbugs-Cc: t...@security.debian.org
Tags: buster
Severity: normal

Hello,

src:opendmarc has been affected by CVE-2020-12460, which is fixed in
sid, bullseye, and stretch. Therefore, I'd like for it to be fixed in
buster as well. And hence this pu update.

The debdiff is duly attached. Let me know if you need any more information. TIA!


- u


opendmarc-buster.debdiff
Description: Binary data


Bug#987532: libatomic-queue builds with -march=native

2021-04-25 Thread Adrian Bunk
Source: libatomic-queue
Version: 0.0+git20201108.d9d66b6-1
Severity: serious

libatomic-queue builds with -march=native, which makes the
code run only on machines compatible with whatever buildd
happened to build the package.

Additionally the package builds with -mtune=native,
which makes it not reproducible and adds a regression
risk due to different compilation on different buildds.



Bug#711054: closed by j...@debian.org (Closing this bug)

2021-04-25 Thread Tomas Pospisek

Danke für die Triage Moritz!
*t

On Sat, 24 Apr 2021, Debian Bug Tracking System wrote:


This is an automatic notification regarding your Bug report
which was filed against the src:linux package:

#711054: synaptics touchpad becomes unusable under load

It has been closed by j...@debian.org.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact j...@debian.org by
replying to this email.


--
711054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711054
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems





Bug#987517: clarification on bandwidth metrics

2021-04-25 Thread Étienne Mollier
Just for the record, as my example output might be misleading,
bandwidth from the hardcopy are improperly computed by the data
fetcher.  At a later stage of the test suite, I record a dataset
which takes a lot more space, and where download rate are more
representative of the reality:

  0%|  | 0/5578 [00:00
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature


Bug#987534: soundtouch builds with -march=native and NEON on armhf

2021-04-25 Thread Adrian Bunk
Source: soundtouch
Version: 2.2+ds1-1
Severity: serious

soundtouch builds with -march=native, which makes the
code run only on machines compatible with whatever buildd
happened to build the package.

NEON is not part of the armhf baseline.



Bug#987441: debian-installer: D-I must get ready for Bullseye

2021-04-25 Thread Cyril Brulebois
Holger Wansing  (2021-04-24):
> Maybe add 
> #987449: [rc-1 graphical d-i] graphical installer hangs at language chooser 
> step for several languages
> here?

Sure, thanks.

Feel free to “nominate”/mention any other bug reports that seem worth
considering. I've seen you went through a number of installation
reports, and I'm pretty sure you have a better overview of the current
state of things than I do.

Also: Thanks for all your hard work in general. It's been very nice to
see you've handled so many things on a regular basis, it's taken a lot
of the load off from me.


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


signature.asc
Description: PGP signature


Bug#929799: --download-current-version and --download-version does not work with uscan when using multiple tarballs

2021-04-25 Thread Yadd
Control: tags -1 + moreinfo

Hi,

I'm unable to reproduce this issue, with and without ctype=nodejs



Bug#987332: aprx automatically starts up with really bad default config

2021-04-25 Thread Evgeni Golov
Hi,

On Thu, Apr 22, 2021 at 12:19:57AM +0300, Heikki Hannikainen wrote:
> - Have it not start up by default after installation, before it is configured

This should be doable by the following patch:
diff -Nru aprx-2.9.0+dfsg/debian/rules aprx-2.9.0+dfsg/debian/rules
--- aprx-2.9.0+dfsg/debian/rules2018-09-27 03:20:51.0 +
+++ aprx-2.9.0+dfsg/debian/rules2021-04-25 08:47:13.0 +
@@ -31,10 +31,13 @@
rm -vf ./test ./aprx-complex.conf Makefile

 override_dh_installinit:
-   dh_installinit --restart-after-upgrade
+   dh_installinit --restart-after-upgrade --no-enable

 override_dh_installdirs:
dh_installdirs
$(MAKE) DESTDIR=$(CURDIR)/debian/aprx logrotate.aprx install
cp logrotate.aprx debian/aprx.logrotate
install -m 644 apparmor.aprx 
$(CURDIR)/debian/aprx/etc/apparmor.d/sbin.aprx
+
+override_dh_installsystemd:
+   dh_installsystemd --no-enable


> - Remove N0CALL-1 from the default configuration (comment the line out) so
> that it will refuse to start up before configured with the callsign of the
> user

Is N0CALL-1 part of the default config aprx ships upstream?

> - Ensure that the instances which have already been started up like this
> will shut down again when upgraded to the next version

Not sure this is easily doable after the fact now, but we at least can
prevent new clients from poping up.



Bug#987535: ggcov FTBFS: 1/21 tests passed

2021-04-25 Thread Adrian Bunk
Source: ggcov
Version: 0.10-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/ggcov.html

...
(cd test && ./runtest)
Running tests
hostname: "ionos5-amd64"
date: "20220526T043014"
uname -s: "Linux"
uname -m: "x86_64"
uname -r: "5.10.0-0.bpo.5-amd64"
head -1 /etc/os-release: "PRETTY_NAME="Debian GNU/Linux bullseye/sid""
CC: "g++"
which g++: "/usr/bin/g++"
g++ --version: "g++ (Debian 10.2.1-6) 10.2.1 20210110"
CXX: "g++"
which g++: "/usr/bin/g++"
g++ --version: "g++ (Debian 10.2.1-6) 10.2.1 20210110"
ERROR: (test000) testrunner failed, see log
ERROR: (test001) no output files from tggcov
ERROR: (test002) no output files from tggcov
ERROR: (test004) no output files from tggcov
ERROR: (test005.1) no output files from tggcov
ERROR: (test006) no output files from tggcov
ERROR: (test007) no output files from tggcov
ERROR: (test008.0) no output files from tggcov
ERROR: (test009) no output files from tggcov
ERROR: (test010) no output files from tggcov
ERROR: (test011.1) no output files from tggcov
ERROR: (test013) no output files from tggcov
ERROR: (test014) no output files from tggcov
ERROR: (test015.a001) no output files from tggcov
ERROR: (test016.1) no output files from tggcov
PASS: (test021) unit test for libpopt / fakepopt.c
ERROR: (test026) no output files from tggcov
ERROR: (test029) no output files from tggcov
ERROR: (test030) no output files from tggcov
ERROR: (test033) no output files from tggcov
ERROR: (test034) no output files from tggcov
Total: 1/21 tests passed
make[1]: *** [debian/rules:35: override_dh_auto_test] Error 1



Bug#987491: installation-reports: Successful install AMD A6 - nonfree AMD Radeon firmware needed

2021-04-25 Thread Geert Stappers

Moin moin,

On Sun, Apr 25, 2021 at 10:31:00AM +0200, Holger Wansing wrote:
> Hi,
> 
> "Andrew M.A. Cater"  wrote (Sat, 24 Apr 2021 15:26:00 
> +):
> > Initial boot:   [O ]
> > Detect network card:[O ]
> > Configure network:  [O ]
> > Detect media:   [O ]
> > Load installer modules: [O ]
> > Clock/timezone setup:   [O ]
> > User/password setup:[O ]
> > Detect hard drives: [O ]
> > Partition hard drives:  [O ]
> > Install base system:[O ]
> > Install tasks:  [O ]
> > Install boot loader:[O ]
> > Overall install:[O ]
> > 
> > Comments/Problems:
> > 
> > Requires non-free Radeon drivers for r600 - firmware-amd-graphics
> 
> please be more specific:
> What happened, when no firmware is installed?
> Did the system work so far (graphical UI is visible and usable)?
> Or was it suffering from problems like "black screen" or "garbled screen" as 
> other users reported?
> 

I think this installation report  now waits for one of these options

 * Reporter reports "It is okay, consider 'Requires non-free' as comment"
 * Reporter provides information which special install care
   the special hardware needs. Info that will help others.
 * Closed due "Time out"



Groeten
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature


Bug#985617: glibc: flaky autopkgtest on most architectures

2021-04-25 Thread Simon McVittie
On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote:
> On 25-04-2021 01:55, Aurelien Jarno wrote:
> > It appears that all the failures are related to containers. I have been
> > able to reproduce the issue with a bullseye kernel, which defaults to
> > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners
> > still use a buster kernel (at least in the case of this build log).
> 
> That's correct, all workers run stable except s390x.
> 
> > Could it be that kernel.unprivileged_userns_clone is enabled on some of
> > the runners?
>
> If I want to make our workers equal, I guess
> changing them all to the default sounds sane, right? Do you know if the
> default is different for buster and bullseye?

The default was kernel.unprivileged_userns_clone=0 in buster kernels and
was switched to kernel.unprivileged_userns_clone=1 in bullseye kernels.

References:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446
https://salsa.debian.org/kernel-team/linux/-/commit/a381917851e762684ebe28e04c5ae0d8be7f42c7

If you want a quick way to get consistent behaviour, installing the
bubblewrap package from bullseye (but not buster-backports!) installs
a sysctl.d fragment to set kernel.unprivileged_userns_clone=1 even on
older kernels.

smcv



Bug#987536: imv FTBFS without internet access

2021-04-25 Thread Adrian Bunk
Source: imv
Version: 4.2.0-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/imv.html

...
[99/104] /usr/bin/a2x --no-xmllint --doctype manpage --format manpage 
--destination-dir /build/imv-4.2.0/obj-x86_64-linux-gnu ../doc/imv.5.txt
FAILED: imv.5 
/usr/bin/a2x --no-xmllint --doctype manpage --format manpage --destination-dir 
/build/imv-4.2.0/obj-x86_64-linux-gnu ../doc/imv.5.txt
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/build/imv-4.2.0/obj-x86_64-linux-gnu/imv.5.xml" returned non-zero exit status 
5

[100/104] /usr/bin/a2x --no-xmllint --doctype manpage --format manpage 
--destination-dir /build/imv-4.2.0/obj-x86_64-linux-gnu ../doc/imv-msg.1.txt
FAILED: imv-msg.1 
/usr/bin/a2x --no-xmllint --doctype manpage --format manpage --destination-dir 
/build/imv-4.2.0/obj-x86_64-linux-gnu ../doc/imv-msg.1.txt
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/build/imv-4.2.0/obj-x86_64-linux-gnu/imv-msg.1.xml" returned non-zero exit 
status 5

[101/104] /usr/bin/a2x --no-xmllint --doctype manpage --format manpage 
--destination-dir /build/imv-4.2.0/obj-x86_64-linux-gnu ../doc/imv.1.txt
FAILED: imv.1 
/usr/bin/a2x --no-xmllint --doctype manpage --format manpage --destination-dir 
/build/imv-4.2.0/obj-x86_64-linux-gnu ../doc/imv.1.txt
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/build/imv-4.2.0/obj-x86_64-linux-gnu/imv.1.xml" returned non-zero exit status 
5
...
make: *** [debian/rules:7: binary] Error 25


The Ubuntu patch seems to contain a fix/workaround.



Bug#987537: RM: scrollz -- RoQA unmaintained, dead upstream, has security issues

2021-04-25 Thread Tobias Frost
Package: scrollz
Severity: serious

user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-04-AT-Salzburg
thank you

Dear maintainers,

according to my research, scrollz is a fork of ircii, also in Debian.  However,
scrollz last update was 2016 while icrii is still frequently releasing new
versions.

Additionally, even if there was a new upstream version in 2016, it was never
packaged for Debian. This lets me believe that the package is no longer
maintained in Debian.

Due to the fact that the scrollz has an open security issue, is not maintained
upstream and Debian, having a very low popcon value and ircii being available,
I think it is probably best to remove the package from Debian at this point.

If there is no answer to this bug within 3 months, I will reassign this bug to
ftp.debian.org for the actual removal.

If you disagree, just close the bug, but it would be great if the package could
be fixed into back into an releasble state.

If you agree, please reassign the bug to ftp.debian.org.

Thanks,
tobi



Bug#987493: unblock: gutenprint/5.3.3-5

2021-04-25 Thread Graham Inggs
Control: retitle -1 [pre-approval] unblock: gutenprint/5.3.3-5
Control: tags -1 + moreinfo + confirmed

Hi Didier

On Sat, 24 Apr 2021 at 17:48, Didier 'OdyX' Raboud  wrote:
> This is a pre-approval request for package package gutenprint.

Please go ahead and upload, and remove the moreinfo tag once the new
version is available in unstable.

Regards
Graham



Bug#985617: glibc: flaky autopkgtest on most architectures

2021-04-25 Thread Simon McVittie
On Sun, 25 Apr 2021 at 10:14:51 +0100, Simon McVittie wrote:
> On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote:
> > On 25-04-2021 01:55, Aurelien Jarno wrote:
> > > It appears that all the failures are related to containers. I have been
> > > able to reproduce the issue with a bullseye kernel, which defaults to
> > > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners
> > > still use a buster kernel (at least in the case of this build log).

Looking at support/test-container.c, it seems that these tests will
automatically be skipped (FAIL_UNSUPPORTED) on a kernel that restricts
userns creation (like buster), and will be run (and perhaps fail)
on a kernel that does not (like bullseye). So it is not necessarily
a *regression* that they fail - they might just never have been tried
before we started using bullseye kernels.

The brute-force approach to making the autopkgtest not be flaky would be
to make these tests FAIL_UNSUPPORTED unconditionally, which will result
in the same coverage we would have had on buster kernels. Obviously it
would be better if they could be made to pass, but some reliable testing
is better than none.

These tests seem to be failing here (support/test-container.c:1095):

  execvp (new_child_proc[0], new_child_proc);

  /* Or don't run the child?  */
  FAIL_EXIT1 ("Unable to exec %s\n", new_child_proc[0]);

It would be useful if this printed strerror(errno) at least, so that we
can see whether it's ENOENT or EACCES or something else.

Perhaps the test support code is not copying/mounting everything that needs
to be copied/mounted into the container's filesystem? More debug logging in
support/test-container.c would probably be helpful here - perhaps even
running 'find . -ls' in the new_root_path before chrooting into it?

smcv



Bug#987441: debian-installer: D-I must get ready for Bullseye

2021-04-25 Thread Michael Biebl
Hi kibi

On Fri, 23 Apr 2021 22:57:40 +0200 Cyril Brulebois  wrote:

>  - broken rescue mode

Is this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952450 or
something else?
I.e. do you consider #952450 a blocker for d-i?

Regards,
Michael


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


Bug#986215: scrollz: CVE-2021-29376

2021-04-25 Thread Tobias Frost
Source: scrollz
Followup-For: Bug #986215

(As scrollz seems to be dead upstream / unmaintained, I'm not going to fix 
this, as the
risk is quite big to break stuff, but I want to document my triaging)

Looking at the diff for the ircii version 20210314 that fixes this CVE,
(ircii bug is #986214), the relevant changes seems to be that below.
(Of course, sources have diverged a bit, so the patch only can serve
as inspiration.)

--- /home/tobi/workspace/deb/bsp/scrollz/ircii-20190117/source/ctcp.c
+++ /home/tobi/workspace/deb/bsp/scrollz/ircii-20210314/source/ctcp.c
@@ -33,7 +33,7 @@
  */
 
 #include "irc.h"
-IRCII_RCSID("@(#)$eterna: ctcp.c,v 1.107 2017/11/02 00:41:42 mrg Exp $");
+IRCII_RCSID("@(#)$eterna: ctcp.c,v 1.110 2021/03/14 18:22:31 mrg Exp $");
 
 #include 
 
@@ -342,6 +342,7 @@
"%s :Use CLIENTINFO  to get more specific 
information",
buffer);
new_free(&buffer);
+   sl_free(sl, 0);
}
return NULL;
 }
@@ -536,12 +537,23 @@
 {
time_t  tm;
u_char  *date = NULL;
+   char*curtime;
 
if (!args || !*args)
return NULL;
tm = my_atol(args);
-   malloc_strcpy(&date, UP(ctime(&tm)));
-   date[my_strlen(date)-1] = '\0';
+   curtime = ctime(&tm);
+   if (curtime)
+   {
+   u_char *s = my_index(curtime, '\n');
+   if (s)
+   *s = '\0';
+
+   malloc_strcpy(&date, UP(curtime));
+   }
+   else
+   /* if we can't find a time, just return the number */
+   malloc_strcpy(&date, args);
return date;
 }
 
@@ -807,9 +819,10 @@
if (do_hook(CTCP_REPLY_LIST, "%s %s %s %s", from, to, cmd,
args) && !(flags & CTCP_NOREPLY))
{
+   u_char  buf[20];
+
if (!my_strcmp(cmd, "PING"))
{
-   u_char  buf[20];
time_t  timediff,
currenttime;
 



Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

2021-04-25 Thread Cyril Brulebois
Holger Wansing  (2021-04-25):
> Chris Hofstaedtler  wrote (Sat, 24 Apr 2021 23:45:13 +0200):
> > Hello,
> > 
> > * Holger Wansing  [210424 21:42]:
> > > While trying to debug another problem yesterday, I found that the RC1 
> > > graphical
> > > installer fails to go forward, when selecting one of these languages:
> > >   - Kannada
> > >   - Marathi
> > >   - Persian
> > >   - Sinhala
> > 
> > I spent a few hours today on this issue, but did not get very far.
> > Not totally unexpected if you know nothing about the installer.
> > 
> > I have, however, a perf top output to share. I believe this more or
> > less means the font rendering (pango, fontconfig) is stuck somehow?

Only quickly looked at pango1.0, freetype, fontconfig, those have last
changed in 2020, so before alpha3.

> That might support my wild guess, that "Drop fontconfig tweaks"
> changings could be related.
> https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f

Given the question below, I suppose you could revert this change
manually and restart the installer (after all, it's about a symlink and
a line in a config file).

> However, I don't get it, why recent dailies are not affected, while
> RC1 (and alpha3) is ???
> 
> (That might be the reason, why this issue slipped through our
> attention until now...)
> 
> Are there differences during build for the "release builds" (alpha,
> rc) compared to the dailies?

You can check debian/rules for USE_UDEBS_FROM:
 - releases fetch their udebs from testing;
 - dailies fetch their udebs from unstable (to shorten the feedback
   loop, and to inform our decision to let some packages migrate or not
   when a freeze — udebs or otherwise — is in effect)

You can switch to/from UNRELEASED in the first line of the changelog to
get the desired results. Or you can set the variable yourself if you run
something like this:

make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=unstable


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


signature.asc
Description: PGP signature


Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use error

2021-04-25 Thread Bernd Zeimetz
Hi,

do you have a example url for me? Maybe a public ntrip caster with auth, that
shows the bug?

Thanks,

Bernd

On Fri, 2021-04-23 at 13:30 +, Aiden Morrison wrote:
> Package: gpsd
> Version: 3.22 (revision 3.22)
> Error text: gpsd:ERROR not authorized for Ntrip stream
> caster.address.extension/mountpoint
>  
> Reproduction: provide an ntrip stream address per the documentation of gpsd
> at (https://gpsd.gitlab.io/gpsd/gpsd.html) in the form
> "ntrip://username:passw...@address.of.caster:port/mountpoint" and note that
> gpsd will throw the above error.
>  
> If the configuration string is intentionally malformed to include a "/"
> after the mountpoint name, this error is not thrown, however the
> corrections are not sent to the attached GNSS receiver:
>  
> cgps reports string
> {"class":"DEVICE","path":"ntrip://user:p...@address.of.caster:port/mountpoi
> nt/","activated":0} showing the malformed mountpoint identifier
>  
> I can connect to the same ntrip server
> using https://github.com/nunojpg/ntripclient as well as two commercial
> software packages, so the error appears to be in how gpsd is interpreting
> the connection string.
>  
> If credentials would be helpful in reproducing this bug I can be contacted
> ataiden.morri...@sintef.no
>  
>  

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#987538: buster-pu: package node-end-of-stream/1.4.1-1+deb10u1

2021-04-25 Thread Yadd
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org

[ Reason ]
node-end-of-stream test is RC-buggy. This little patch workaround this
bug which seems not related to node-end-of-stream itself

[ Impact ]
No impact, just fix test

[ Tests ]
No change except one ignored failure

[ Risks ]
No risks

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Test wanted 8 successful checks. The patch requires only 7, so allows
one failure (function not launched probably due to a nodejs change)

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index e08c7c7..4c026c2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-end-of-stream (1.4.1-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Workaround test bug (Closes: #987530)
+
+ -- Yadd   Sun, 25 Apr 2021 11:56:20 +0200
+
 node-end-of-stream (1.4.1-1) unstable; urgency=medium
 
   * New upstream version
diff --git a/debian/patches/01-fix-test.patch b/debian/patches/01-fix-test.patch
new file mode 100644
index 000..38a917e
--- /dev/null
+++ b/debian/patches/01-fix-test.patch
@@ -0,0 +1,22 @@
+Description: decrease min successful test to allow one error
+ Test wanted 8 (all) checks to be successful. It seems that nodejs changes
+ breaks last test (lines 67 to 81): eos(socket,...) isn't launched.
+ .
+ This bug seems not linked to end-of-stream itself but related to nodejs "net"
+ use in this test. So this patch is just a workaround, not a real fix.
+Author: Yadd 
+Bug-Debian: https://bugs.debian.org/987530
+Forwarded: not-needed
+Last-Update: 2021-04-25
+
+--- a/test.js
 b/test.js
+@@ -1,7 +1,7 @@
+ var assert = require('assert');
+ var eos = require('./index');
+ 
+-var expected = 8;
++var expected = 7;
+ var fs = require('fs');
+ var cp = require('child_process');
+ var net = require('net');
diff --git a/debian/patches/series b/debian/patches/series
index 6a9cea4..a9118e6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 00-fix_test.diff
+01-fix-test.patch


Bug#987441: debian-installer: D-I must get ready for Bullseye

2021-04-25 Thread Cyril Brulebois
Hallo Michael,

Michael Biebl  (2021-04-25):
> On Fri, 23 Apr 2021 22:57:40 +0200 Cyril Brulebois  wrote:
> 
> >  - broken rescue mode
> 
> Is this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952450 or
> something else?

No, I hadn't the bug report handy when I wrote the quick text, but it's
been added a few minutes later:

Fix blocked by […] 987377: rescue-mode: when in graphical mode, locks up 
one prompt before the shell, […]

so that's about the rescue mode of the installer, rather than about
rescue.target.

> I.e. do you consider #952450 a blocker for d-i?

I did see this when I was searching for /rescue/ (to get the right
number for the bug mentioned above), but it didn't feel like a bug
report that's been filed 1+ year ago at normal severity could be a
blocker for the release (especially since there was apparently no
follow-up after your suggestion).

For the avoidance of doubt, I didn't dive into rescue.target at all,
so I have no actual opinion regarding that particular issue besides
the initial metadata-based assessment above.


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


signature.asc
Description: PGP signature


Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

2021-04-25 Thread Holger Wansing
Hi,

Cyril Brulebois  wrote (Sun, 25 Apr 2021 11:53:22 +0200):
> Given the question below, I suppose you could revert this change
> manually and restart the installer (after all, it's about a symlink and
> a line in a config file).

Sure. I did that already.
But this does not gain any value, because building an image myself now without
doing any changings leads to a working d-i (on i386, if arch matters) !!!

I don't need to do anything to get a working d-i, just build myself.

But why does the RC1 fail then?

Holger



> > However, I don't get it, why recent dailies are not affected, while
> > RC1 (and alpha3) is ???
> > 
> > (That might be the reason, why this issue slipped through our
> > attention until now...)
> > 
> > Are there differences during build for the "release builds" (alpha,
> > rc) compared to the dailies?
> 
> You can check debian/rules for USE_UDEBS_FROM:
>  - releases fetch their udebs from testing;
>  - dailies fetch their udebs from unstable (to shorten the feedback
>loop, and to inform our decision to let some packages migrate or not
>when a freeze — udebs or otherwise — is in effect)
> 
> You can switch to/from UNRELEASED in the first line of the changelog to
> get the desired results. Or you can set the variable yourself if you run
> something like this:
> 
> make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=unstable
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Bug#987491: installation-reports: Successful install AMD A6 - nonfree AMD Radeon firmware needed

2021-04-25 Thread Cyril Brulebois
For context: Andrew is testing various hardware and reporting back,
but some part of it ended up on IRC instead of in bug reports.

Geert Stappers  (2021-04-25):
> On Sun, Apr 25, 2021 at 10:31:00AM +0200, Holger Wansing wrote:
> > Hi,
> > 
> > "Andrew M.A. Cater"  wrote (Sat, 24 Apr 2021 15:26:00 
> > +):
> > > Initial boot:   [O ]
> > > Detect network card:[O ]
> > > Configure network:  [O ]
> > > Detect media:   [O ]
> > > Load installer modules: [O ]
> > > Clock/timezone setup:   [O ]
> > > User/password setup:[O ]
> > > Detect hard drives: [O ]
> > > Partition hard drives:  [O ]
> > > Install base system:[O ]
> > > Install tasks:  [O ]
> > > Install boot loader:[O ]
> > > Overall install:[O ]
> > > 
> > > Comments/Problems:
> > > 
> > > Requires non-free Radeon drivers for r600 - firmware-amd-graphics
> > 
> > please be more specific:
> > What happened, when no firmware is installed?
> > Did the system work so far (graphical UI is visible and usable)?
> > Or was it suffering from problems like "black screen" or "garbled screen" 
> > as 
> > other users reported?

More info would definitely be helpful indeed.

> I think this installation report  now waits for one of these options
> 
>  * Reporter reports "It is okay, consider 'Requires non-free' as comment"
>  * Reporter provides information which special install care
>the special hardware needs. Info that will help others.
>  * Closed due "Time out"

Please don't close right away, thanks.


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


signature.asc
Description: PGP signature


Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

2021-04-25 Thread Cyril Brulebois
Holger Wansing  (2021-04-25):
> Cyril Brulebois  wrote (Sun, 25 Apr 2021 11:53:22 +0200):
> > Given the question below, I suppose you could revert this change
> > manually and restart the installer (after all, it's about a symlink and
> > a line in a config file).
> 
> Sure. I did that already.
> But this does not gain any value, because building an image myself now without
> doing any changings leads to a working d-i (on i386, if arch matters) !!!

I understood that part. :)

> I don't need to do anything to get a working d-i, just build myself.
> 
> But why does the RC1 fail then?

I meant that you could modify a released image (Alpha 3 or RC 1),
early after you have booted it; this way you would see whether
reverting the change manually would change anything.


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


signature.asc
Description: PGP signature


Bug#987514: virtualbox-ext-pack: fails to install: checksum of downloaded file does not match

2021-04-25 Thread Gianfranco Costamagna
control: tags -1 unreproducible
control: close -1

On Sun, 25 Apr 2021 02:40:37 +0200 Andreas Beckmann  wrote:
> Package: virtualbox-ext-pack
> Version: 6.1.20-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
> From the attached log (scroll to the bottom...):
> 
>   Setting up virtualbox-ext-pack (6.1.20-1) ...
>   virtualbox-ext-pack: downloading: 
> https://download.virtualbox.org/virtualbox/6.1.20/Oracle_VM_VirtualBox_Extension_Pack-6.1.20.vbox-extpack
>   The file will be downloaded into /usr/share/virtualbox-ext-pack
>   Hash mismatch Oracle_VM_VirtualBox_Extension_Pack-6.1.20.vbox-extpack: 
> expected 15bdee9c0385ddd4cdbbe0e446c0180ad4ae21554ddd52f8b44783aebd4aeef4, 
> removing the file.
>   dpkg: error processing package virtualbox-ext-pack (--configure):
>installed virtualbox-ext-pack package post-installation script subprocess 
> returned error exit status 1
>   Processing triggers for libc-bin (2.31-11) ...
>   Errors were encountered while processing:
>virtualbox-ext-pack
> 

Hello, please analyze on your system if you have a broken or corrupted 
download. The hash is correct, and works for me...
Maybe you have some proxy on your system? Did the download get corrupted?

Gianfranco



Bug#987491: Fwd: Missing firmware not declared / kernel modules not included in initrd

2021-04-25 Thread Geert Stappers


Updating the issue with "previously missing information"

- Forwarded message from "Andrew M.A. Cater" -

Date: Sun, 25 Apr 2021 10:13:59 +
From: "Andrew M.A. Cater" 
To: debian-b...@lists.debian.org
Subject: Re: [AMD/ATI graphics] Missing firmware not declared / kernel modules 
not included in initrd

On Sun, Apr 25, 2021 at 10:26:42AM +0200, Holger Wansing wrote:
> Hi,
> 
> Holger Wansing  wrote (Sun, 25 Apr 2021 10:08:32 +0200):
> > >I don't understand:
> > >does this mean that the issue that you reported in
> > >https://lists.debian.org/debian-boot/2020/12/msg00026.html can be
> > >considered fixed? And that the situation improved between buster and
> > >bullseye?
> > 
> > For this (old) hardware: yes, seems so.
> > 
> > However, we have several user reports, that not installed firmware leads to 
> > problems 
> > like black or garbled screen.
> 
> To be more clear:
> 
> The main point of my report at
> https://lists.debian.org/debian-boot/2020/12/msg00026.html ist:
> the installer is - per design - unable to detect, that the hardware needs
> firmware to be installed.
> 
> And this situation did not change!
> 
> The bullseye installation yesterday did not install the firmware package.
> 
> What seems to have changed is:
> GNOME seems to work (at least on this hardware !!!), even without the 
> firmware 
> installed.
> 
> (Also: Look at the other reports I quoted in my mail above for more user 
> cases.)
> 
> 
> Holger
> 

Adding to this, if I may. 

I've got two machines which both turn out to need firmware-amd-graphics
rather than the more modern firmware-amdgpu.

Installing with Bullsye RC1 netinst for amd64 but NOT the unofficial firmware 
version. debian-bullseye-DI-rc1-amd64-netinst.iso 

Even on an expert text mode install.the installer does not prompt for the 
firmware-amd-graphics package to be installed - it does complain about 
Realtek ethernet drivers and a Ralink WiFi card suggesting that you install 
the firmware for these. Booting the install medium does show, in passing,
in text that you need Radeon firmware R600 for modesetting.

If you _do not_ install the firmware, then on these two machines at least
there is a fallback mode to 800x600x16 so graphics remains (just) usable.
GNOME and Wayland work but it's not really practicable.

AT that point, you can install firmware-amd-graphics and it just works.
The meta-package which does this is firmware-linux-nonfree which also includes 
amd64-microcode

Once the firmwre is installed, these machines will drive a 2k monitor

This is explicitly NOT amdgpu which is where people are reporting black 
screens and no output whatsoever, I think.

Hope this helps,

Andy C.
> 
> 
> -- 
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
> 


- End forwarded message -


Those who feel more comformatable to close this issue than me,
should close this issue.


Groeten
Geert Stappers
-- 
Silence is hard to parse



Bug#985617: glibc: flaky autopkgtest on most architectures

2021-04-25 Thread Aurelien Jarno
On 2021-04-25 10:39, Simon McVittie wrote:
> On Sun, 25 Apr 2021 at 10:14:51 +0100, Simon McVittie wrote:
> > On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote:
> > > On 25-04-2021 01:55, Aurelien Jarno wrote:
> > > > It appears that all the failures are related to containers. I have been
> > > > able to reproduce the issue with a bullseye kernel, which defaults to
> > > > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners
> > > > still use a buster kernel (at least in the case of this build log).
> 
> Looking at support/test-container.c, it seems that these tests will
> automatically be skipped (FAIL_UNSUPPORTED) on a kernel that restricts
> userns creation (like buster), and will be run (and perhaps fail)
> on a kernel that does not (like bullseye). So it is not necessarily
> a *regression* that they fail - they might just never have been tried
> before we started using bullseye kernels.
> 
> The brute-force approach to making the autopkgtest not be flaky would be
> to make these tests FAIL_UNSUPPORTED unconditionally, which will result
> in the same coverage we would have had on buster kernels. Obviously it
> would be better if they could be made to pass, but some reliable testing
> is better than none.
> 
> These tests seem to be failing here (support/test-container.c:1095):
> 
>   execvp (new_child_proc[0], new_child_proc);
> 
>   /* Or don't run the child?  */
>   FAIL_EXIT1 ("Unable to exec %s\n", new_child_proc[0]);
> 
> It would be useful if this printed strerror(errno) at least, so that we
> can see whether it's ENOENT or EACCES or something else.
> 
> Perhaps the test support code is not copying/mounting everything that needs
> to be copied/mounted into the container's filesystem? More debug logging in
> support/test-container.c would probably be helpful here - perhaps even
> running 'find . -ls' in the new_root_path before chrooting into it?

Yes, this is exactly the problem. This is due to patch
any/local-rtlddir-cross.diff, which remove a snippet of code installing
the ld.so symlink. Instead this is done in an ugly way in the
debian/rules.d/build.mk. Both can be dropped to make things working
fine. However I am not sure what are the consequences on cross builds,
which anyway also use the same code from build.mk. I am currently
investigating.

Aurelien

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



Bug#987539: RM: mozplugger -- RoQA; unmaintained, broken

2021-04-25 Thread Reiner Herrmann
Package: ftp.debian.org
Severity: normal

Hi,

please remove mozplugger from the archive.
It is orphaned since 2013 and has seen no update since then.
It has an RC bug since 2018, as it is not working with new browsers.
Modern browsers already provide its functionality out of the box
(embedded viewing of PDFs, videos etc.).

Kind regards,
  Reiner



Bug#987493: unblock: gutenprint/5.3.3-5

2021-04-25 Thread Didier 'OdyX' Raboud
Control: tags -1 -moreinfo

Le dimanche, 25 avril 2021, 11.37:23 h CEST Graham Inggs a écrit :
> On Sat, 24 Apr 2021 at 17:48, Didier 'OdyX' Raboud  wrote:
> > This is a pre-approval request for package package gutenprint.
> 
> Please go ahead and upload, and remove the moreinfo tag once the new
> version is available in unstable.

Hello Graham,

Thanks for your prompt ack and your work as release team member!

Uploaded, and built already for most archs.

-- 
OdyX

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


Bug#987540: zsh: $((inf)) not handled correctly in tr_TR.utf8 locale

2021-04-25 Thread Vincent Lefevre
Package: zsh
Version: 5.8-6
Severity: normal

In zsh, $((inf)) should be regarded as infinity, not as the inf
variable. This does not work with tr_TR.utf8, probably because
"I" and "i" are not the same letter in Turkish.

$ zsh -fc 'export LC_ALL=tr_TR.utf8; echo $((Inf)) $((inf))'
Inf 0

This may be a Debian specific bug (upstream cannot reproduce it).

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----===
ii  curl 7.74.0-1.2   amd64command line tool for 
transferring data with URL syntax
ii  mercurial-common 5.6.1-2  all  easy-to-use, scalable 
distributed version control system (common files)
ii  meson0.56.2-1 all  high-productivity build system
ii  ninja-build  1.10.1-1 amd64small build system closest in 
spirit to Make
ii  pass 1.7.3-2  all  lightweight directory-based 
password manager
ii  pulseaudio   14.2-2   amd64PulseAudio sound server
ii  qpdf 10.1.0-1 amd64tools for transforming and 
inspecting PDF files
ii  systemd  247.3-5  amd64system and service manager
ii  udev 247.3-5  amd64/dev/ and hotplug management 
daemon
ii  vlc-bin  3.0.12-3 amd64binaries from VLC
ii  youtube-dl   2021.02.10-1 all  downloader of videos from 
YouTube and other sites

The following files were modified:

/etc/systemd/system.conf
/etc/systemd/journald.conf
/etc/systemd/logind.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  libc6   2.31-11
ii  libcap2 1:2.44-1
ii  libtinfo6   6.2+20201114-2
ii  zsh-common  5.8-6

Versions of packages zsh recommends:
ii  libgdbm6  1.19-2
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13

Versions of packages zsh suggests:
ii  zsh-doc  5.8-6

-- no debconf information

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



Bug#987541: ukopp: consider packaging upstream maintained successor

2021-04-25 Thread Ricardo Mones
Source: ukopp
Severity: wishlist
Tags: upstream

Dear future maintainer,

Considering adopting¹ ukopp? That's good, but note it has been
discontinued upstream under this name. Instead, please consider
packaging the sucessor of this program, named Backwild².

Thanks in advance for your contribution to Debian!


¹ https://bugs.debian.org/987092
² https://kornelix.net/backwild/backwild.html

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

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


Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use error

2021-04-25 Thread Aiden Morrison
Hi Bernd,

I can get this to manifest with ntrip://SNTu0:pa...@caster.dyndns.org:2101/NOT

The same caster/mountpoint are working with each of the Ublox u-center 
software, the BKG Ntrip Client (https://igs.bkg.bund.de/ntrip/bnc) and the 
previously mentioned ntripclient code on github.
BKG Ntrip Client - BNC
BKG Ntrip Client (BNC) The BKG Ntrip Client (BNC) is an Open Source 
multi-stream client program designed for a variety of real-time GNSS 
applications.
igs.bkg.bund.de
Please let me know if further information is helpful.

-Aiden

From: Bernd Zeimetz 
Sent: 25 April 2021 11:52
To: Aiden Morrison ; 987...@bugs.debian.org 
<987...@bugs.debian.org>
Subject: Re: Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use 
error

Hi,

do you have a example url for me? Maybe a public ntrip caster with auth, that
shows the bug?

Thanks,

Bernd

On Fri, 2021-04-23 at 13:30 +, Aiden Morrison wrote:
> Package: gpsd
> Version: 3.22 (revision 3.22)
> Error text: gpsd:ERROR not authorized for Ntrip stream
> caster.address.extension/mountpoint
>
> Reproduction: provide an ntrip stream address per the documentation of gpsd
> at 
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgpsd.gitlab.io%2Fgpsd%2Fgpsd.html&data=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J6W2QinFv7DlRv3%2BTzKDFRPcTbgLEbJ5yYUqTznZaiI%3D&reserved=0)
>  in the form
> "ntrip://username:passw...@address.of.caster:port/mountpoint" and note that
> gpsd will throw the above error.
>
> If the configuration string is intentionally malformed to include a "/"
> after the mountpoint name, this error is not thrown, however the
> corrections are not sent to the attached GNSS receiver:
>
> cgps reports string
> {"class":"DEVICE","path":"ntrip://user:p...@address.of.caster:port/mountpoi
> nt/","activated":0} showing the malformed mountpoint identifier
>
> I can connect to the same ntrip server
> using 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnunojpg%2Fntripclient&data=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QjyVo3xXClMT1wKpQrYttB5LK37JIt%2FRBMR%2F44PGwNw%3D&reserved=0
>  as well as two commercial
> software packages, so the error appears to be in how gpsd is interpreting
> the connection string.
>
> If credentials would be helpful in reproducing this bug I can be contacted
> ataiden.morri...@sintef.no
>
>

--
 Bernd ZeimetzDebian GNU/Linux Developer
 
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbzed.de%2F&data=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IaEVrk9tpjWMp1mlAq558pAgcrP5NAQGZiSKOHTZ0RI%3D&reserved=0

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.debian.org%2F&data=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OouRIFVC7%2BLsb9sefaUFFYPnbQ5%2FXosMRjGOTmllhtI%3D&reserved=0
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F




Bug#987535: ggcov FTBFS: 1/21 tests passed

2021-04-25 Thread Chris Hofstaedtler
* Adrian Bunk  [210425 11:09]:
> g++ --version: "g++ (Debian 10.2.1-6) 10.2.1 20210110"
> ERROR: (test000) testrunner failed, see log

Looking at the tests, they all produce this error and then crash:

| unsupported compiler version 10.2(*), contact author for support

Indeed there's a gcc version check in src/cov_file.C, which does not
know about gcc 10.2 yet. The 10.1 code path got added by
   debian/patches/compilers.patch.

Chris



Bug#987458: libjs-of-ocaml-doc is empty

2021-04-25 Thread Romain Porte
Control: patch

In commit b9b0e260 the documentation is removed in d/rules on purpose,
but the binary package libjs-of-ocaml-docs is not removed from
d/control. This leads to the creation of an empty package.

Please apply attached patch to fix the issue.

Best regards,

Romain, on behalf of the Debian Salzburg BSP.

>From 2e248636a894b8ab9dc25bd815930e4eba194323 Mon Sep 17 00:00:00 2001
From: Romain Porte 
Date: Sun, 25 Apr 2021 12:23:14 +0200
Subject: [PATCH] Remove empty binary package libjs-of-ocaml-docs. Closes:
 #987458

* Non-maintainer upload.
* Remove empty binary package libjs-of-ocaml-docs. Closes: #987458

In commit b9b0e260 the documentation is removed in d/rules on purpose,
but the binary package libjs-of-ocaml-docs is not removed from
d/control. This leads to the creation of an empty package.
---
 debian/changelog |  7 +++
 debian/control   | 11 ---
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index f834b19..f8b645d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+js-of-ocaml (3.8.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove empty binary package libjs-of-ocaml-docs. Closes: #987458
+
+ -- Romain Porte   Sun, 25 Apr 2021 12:22:20 +0200
+
 js-of-ocaml (3.8.0-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index 5f8e4e2..15f05f8 100644
--- a/debian/control
+++ b/debian/control
@@ -102,14 +102,3 @@ Description: OCaml bytecode to JavaScript compiler (runtime)
  This package contains runtime libraries that may be needed by
  server-side programs communicating with clients compiled with
  Js_of_ocaml using JSON.
-
-Package: libjs-of-ocaml-doc
-Section: doc
-Architecture: all
-Multi-Arch: foreign
-Depends: ${misc:Depends}
-Description: OCaml bytecode to JavaScript compiler (documentation)
- Js_of_ocaml is a compiler of OCaml bytecode to JavaScript. It makes
- it possible to run OCaml programs in a web browser.
- .
- This package contains the API reference and examples.
-- 
2.30.2



Bug#987542: unblock: gpsd/3.22-3

2021-04-25 Thread Bernd Zeimetz
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gpsd

Adding missing Breaks/Replaces and fixing a bit of mess in the symbols
files.


gpsd (3.22-3) unstable; urgency=medium

  * [c6838e37] Remove duplicate lines from symbol files.
Thanks to Matthias Klose (Closes: #985930)
  * [5c240253] Mark String::QString(QString const&)@Base as optional.
Required for backporting.
  * [2dfbaa07] Updating debian/control from debian/control.in
  * [c582b2aa] gpsd-tools: add missing Breaks+Replaces
gpsd-tools needs Breaks/Replaces for gpsd-clients (<< 3.20-10)
Thanks to Andreas Beckmann (Closes: #987208)

 -- Bernd Zeimetz   Sun, 25 Apr 2021 12:17:57 +0200


Full diff is attached.

Thanks,

Bernd



unblock gpsd/3.22-3


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index dfef5f900..f0b5369f7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+gpsd (3.22-3) unstable; urgency=medium
+
+  * [c6838e37] Remove duplicate lines from symbol files.
+Thanks to Matthias Klose (Closes: #985930)
+  * [5c240253] Mark String::QString(QString const&)@Base as optional.
+Required for backporting.
+  * [2dfbaa07] Updating debian/control from debian/control.in
+  * [c582b2aa] gpsd-tools: add missing Breaks+Replaces
+gpsd-tools needs Breaks/Replaces for gpsd-clients (<< 3.20-10)
+Thanks to Andreas Beckmann (Closes: #987208)
+
+ -- Bernd Zeimetz   Sun, 25 Apr 2021 12:17:57 +0200
+
 gpsd (3.22-2) unstable; urgency=medium
 
   [ Bernd Zeimetz ]
diff --git a/debian/control b/debian/control
index 30665b4e2..a38b8c82f 100644
--- a/debian/control
+++ b/debian/control
@@ -63,8 +63,8 @@ Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
  libgps28 (= ${binary:Version}),
 Suggests: gpsd
-Breaks: python-gps, gpsd (<< 3.20-9)
-Replaces: python-gps
+Breaks: python-gps, gpsd (<< 3.20-9), gpsd-clients (<< 3.20-10)
+Replaces: python-gps, gpsd-clients (<< 3.20-10)
 Description: Global Positioning System - tools
  The gpsd service daemon can monitor one or more GPS devices connected to
  a host computer, making all data on the location and movements of the
diff --git a/debian/control.in b/debian/control.in
index cb2df897d..7ff2aa444 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -63,8 +63,8 @@ Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
  libgpsLIBGPSSONAME (= ${binary:Version}),
 Suggests: gpsd
-Breaks: python-gps, gpsd (<< 3.20-9)
-Replaces: python-gps
+Breaks: python-gps, gpsd (<< 3.20-9), gpsd-clients (<< 3.20-10)
+Replaces: python-gps, gpsd-clients (<< 3.20-10)
 Description: Global Positioning System - tools
  The gpsd service daemon can monitor one or more GPS devices connected to
  a host computer, making all data on the location and movements of the
diff --git a/debian/libgpsLIBGPSSONAME.symbols 
b/debian/libgpsLIBGPSSONAME.symbols
index 03ae8f936..3f66558b5 100644
--- a/debian/libgpsLIBGPSSONAME.symbols
+++ b/debian/libgpsLIBGPSSONAME.symbols
@@ -9,8 +9,6 @@ libgps.so.LIBGPSSONAME libgpsLIBGPSSONAME #MINVER#
  (c++)"gpsmm::stream(int)@Base" 3.3
  (c++)"gpsmm::waiting(int)@Base" 3.3
  (c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
  (c++)"typeinfo for gpsmm@Base" 3.3
  (c++)"typeinfo name for gpsmm@Base" 3.3
  (c++)"vtable for gpsmm@Base" 3.3
diff --git a/debian/libqgpsmmLIBGPSSONAME.symbols 
b/debian/libqgpsmmLIBGPSSONAME.symbols
index 84edae24e..d3d51ab01 100644
--- a/debian/libqgpsmmLIBGPSSONAME.symbols
+++ b/debian/libqgpsmmLIBGPSSONAME.symbols
@@ -36,18 +36,12 @@ libQgpsmm.so.LIBGPSSONAME libqgpsmmLIBGPSSONAME #MINVER#
  (c++)"gpsmm::waiting(int)@Base" 3.3
  (c++)"gpsmm::clear_fix()@Base" 3.3
  (c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
- (c++)"gpsmm::~gpsmm()@Base" 3.3
-#MISSING: 3.18# (c++|optional)"QDebug::~QDebug()@Base" 3.3
 #MISSING: 3.18# (c++|optional)"QDebug::~QDebug()@Base" 3.3
  (c++|optional)"QString::~QString()@Base" 3.3
- (c++|optional)"QString::~QString()@Base" 3.3
- (c++|optional)"QList::~QList()@Base" 3.5
  (c++|optional)"QList::~QList()@Base" 3.5
  (c++)"typeinfo for gpsmm@Base" 3.3
  (c++)"typeinfo name for gpsmm@Base" 3.3
  (c++)"vtable for gpsmm@Base" 3.3
-#MISSING: 3.18# (c++|optional)"QByteArray::~QByteArray()@Base" 3.3
 #MISSING: 3.18# (c++|optional)"QByteArray::~QByteArray()@Base" 3.3
  (c++)"shiftleft(unsigned char*, int, unsigned short)@Base" 3.12
 #MISSING: 3.17# (c++)"shm_get(int, bool, bool)@Base" 3.15
@@ -158,6 +152,5 @@ libQgpsmm.so.LIBGPSSONAME libqgpsmmLIBGPSSONAME #MINVER#
 #MISSING: 3.20# unix_to_iso8601@Base 3.3
  datum_code_string@Base 3.19
 #MISSING: 3.21.1~dev# nanowait(int, timespec*)@Base 3.21.1
- (c++)"QString::QString(QString const&)@Base" 3.21

Bug#987543: unblock: python-jenkinsapi/0.3.11-5

2021-04-25 Thread Chris Hofstaedtler
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-jenkinsapi

[ Reason ]
Version in testing FTBFS, bug #986511

[ Impact ]
I guess the package goes away.

[ Tests ]
Build test only, really. Given the build failed because of a linter tool
(pylint), and my python experience, and the patch coming from Ubuntu, it
looks safe to me.

[ Risks ]
Leaf package really. Not sure -why- we have it, but alas.

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

[ Other info ]
Maintainer has sadly recently left Debian and orphaned the package.

Best,
Chris


unblock python-jenkinsapi/0.3.11-5


debdiff:

diff -Nru python-jenkinsapi-0.3.11/debian/changelog 
python-jenkinsapi-0.3.11/debian/changelog
--- python-jenkinsapi-0.3.11/debian/changelog   2020-10-28 03:19:59.0 
+
+++ python-jenkinsapi-0.3.11/debian/changelog   2021-04-24 23:29:27.0 
+
@@ -1,3 +1,12 @@
+python-jenkinsapi (0.3.11-5) unstable; urgency=medium
+
+  * QA upload.
+  * Orphan package, see #985165.
+  * Apply patch from Ubuntu to fix FTBFS. (Closes: #986511)
+Thanks: Logan Rosen 
+
+ -- Chris Hofstaedtler   Sat, 24 Apr 2021 23:29:27 +
+
 python-jenkinsapi (0.3.11-4) unstable; urgency=medium
 
   * Fix FTBS due to pylint/python3 changes (Closes: #971179)
diff -Nru python-jenkinsapi-0.3.11/debian/control 
python-jenkinsapi-0.3.11/debian/control
--- python-jenkinsapi-0.3.11/debian/control 2020-10-28 03:19:59.0 
+
+++ python-jenkinsapi-0.3.11/debian/control 2021-04-24 23:29:27.0 
+
@@ -1,13 +1,12 @@
 Source: python-jenkinsapi
 Section: python
 Priority: optional
-Maintainer: Al Stone 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 12), python3-all-dev, python3-lxml, 
  python3-setuptools, python3-pytest, pylint3, dh-python, python3-pbr,
  python3-pylint-common
 Standards-Version: 4.5.0
 Homepage: http://pypi.python.org/pypi/jenkinsapi
-Vcs-Git: https://github.com/ahs3/python-jenkinsapi
 
 Package: python3-jenkinsapi
 Architecture: all
diff -Nru python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch 
python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch
--- python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch  2020-10-28 
03:19:59.0 +
+++ python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch  2021-04-24 
23:29:27.0 +
@@ -1,6 +1,5 @@
-diff -Naur a/jenkinsapi/credential.py b/jenkinsapi/credential.py
 a/jenkinsapi/credential.py 2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/credential.py 2020-10-27 21:03:49.025512695 -0600
+--- a/jenkinsapi/credential.py
 b/jenkinsapi/credential.py
 @@ -83,7 +83,7 @@
  
  def __init__(self, cred_dict):
@@ -70,9 +69,8 @@
  }
 -return super(AmazonWebServicesCredentials, 
self)._get_attributes_xml(data)
 +return super()._get_attributes_xml(data)
-diff -Naur a/jenkinsapi/credentials.py b/jenkinsapi/credentials.py
 a/jenkinsapi/credentials.py2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/credentials.py2020-10-27 21:04:33.021889279 -0600
+--- a/jenkinsapi/credentials.py
 b/jenkinsapi/credentials.py
 @@ -100,8 +100,8 @@
  except JenkinsAPIException as jae:
  raise JenkinsAPIException('Latest version of Credentials '
@@ -104,9 +102,8 @@
  self.poll()
  self.credentials = self._data['credentials']
  if description in self:
-diff -Naur a/jenkinsapi/fingerprint.py b/jenkinsapi/fingerprint.py
 a/jenkinsapi/fingerprint.py2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/fingerprint.py2020-10-27 20:59:57.595597808 -0600
+--- a/jenkinsapi/fingerprint.py
 b/jenkinsapi/fingerprint.py
 @@ -96,14 +96,14 @@
  def validate(self):
  try:
@@ -126,9 +123,8 @@
  return True
  
  def get_info(self):
-diff -Naur a/jenkinsapi/jenkinsbase.py b/jenkinsapi/jenkinsbase.py
 a/jenkinsapi/jenkinsbase.py2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/jenkinsbase.py2020-10-27 20:58:54.431099252 -0600
+--- a/jenkinsapi/jenkinsbase.py
 b/jenkinsapi/jenkinsbase.py
 @@ -84,9 +84,9 @@
  response.raise_for_status()
  try:
@@ -141,9 +137,8 @@
  
  def pprint(self):
  """
-diff -Naur a/jenkinsapi/job.py b/jenkinsapi/job.py
 a/jenkinsapi/job.py2020-02-16 16:46:46.775307980 -0700
-+++ b/jenkinsapi/job.py2020-10-27 20:58:21.502844386 -0600
+--- a/jenkinsapi/job.py
 b/jenkinsapi/job.py
 @@ -89,7 +89,7 @@
  return branches
  
@@ -196,9 +191,8 @@
  
  def __delitem__(self, build_number):
  self.delete_build(build_number)
-diff -Naur a/jenkinsapi/node.py b/jenkinsapi/node.py
 a/jenkinsapi/node.py   2020-02-16 16:46:46.775307980 -0700
-+++ b/jenkinsapi/node.py   2020-10-27 20

Bug#987446: mc: cannot view .zip files (PKZIP archives) containing PDF files any more

2021-04-25 Thread Adrian Bunk
Control: forcemerge -1 985046

On Sat, Apr 24, 2021 at 02:48:27AM +0200, Thorsten Glaser wrote:
> Package: mc
> Version: 3:4.8.26-1
> Severity: important
> X-Debbugs-Cc: t...@mirbsd.de, debian-rele...@lists.debian.org
> 
> @d-release: please consider allowing an mc downgrade to the previous
> upload and upstream version in bullseye.
>...

This bug is a duplicate of 985046.

There seem to be revert and cherry-pick options available for this 
specific issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985046#10
https://midnight-commander.org/ticket/4180


cu
Adrian



Bug#987537: RM: scrollz -- RoQA unmaintained, dead upstream, has security issues

2021-04-25 Thread Salvatore Bonaccorso
On Sun, Apr 25, 2021 at 11:33:32AM +0200, Tobias Frost wrote:
> Package: scrollz
> Severity: serious
> 
> user debian-rele...@lists.debian.org
> usertags -1 + bsp-2021-04-AT-Salzburg
> thank you
> 
> Dear maintainers,
> 
> according to my research, scrollz is a fork of ircii, also in Debian.  
> However,
> scrollz last update was 2016 while icrii is still frequently releasing new
> versions.
> 
> Additionally, even if there was a new upstream version in 2016, it was never
> packaged for Debian. This lets me believe that the package is no longer
> maintained in Debian.
> 
> Due to the fact that the scrollz has an open security issue, is not maintained
> upstream and Debian, having a very low popcon value and ircii being available,
> I think it is probably best to remove the package from Debian at this point.
> 
> If there is no answer to this bug within 3 months, I will reassign this bug to
> ftp.debian.org for the actual removal.
> 
> If you disagree, just close the bug, but it would be great if the package 
> could
> be fixed into back into an releasble state.
> 
> If you agree, please reassign the bug to ftp.debian.org.

FWIW, from security team perspective we think scrollz (and possibly
ircii) should both not be included in bullseye in this form.

Regards,
Salvatore



Bug#987535: ggcov FTBFS: 1/21 tests passed

2021-04-25 Thread Chris Hofstaedtler
* Chris Hofstaedtler  [210425 11:36]:
> Indeed there's a gcc version check in src/cov_file.C, which does not
> know about gcc 10.2 yet. The 10.1 code path got added by
>debian/patches/compilers.patch.

Trivially adding 10.2 in there does fix the FTBFS.
I imagine Alastair will get to it soon though...

Chris

diff -Nru ggcov-0.10/debian/patches/compilers.patch 
ggcov-0.10/debian/patches/compilers.patch
--- ggcov-0.10/debian/patches/compilers.patch2020-07-05 06:11:21.0 
+
+++ ggcov-0.10/debian/patches/compilers.patch2021-04-25 11:30:24.0 
+
@@ -1,16 +1,17 @@
 Author: Alastair McKinstry 
 Description: Support for newer compilers
-Last-Updated: 2020-07-04
+Last-Updated: 2021-04-25
 Forwarded: no

 Index: ggcov-0.10/src/cov_file.C
 ===
 --- ggcov-0.10.orig/src/cov_file.C
 +++ ggcov-0.10/src/cov_file.C
-@@ -1013,6 +1013,7 @@ cov_file_t::read_gcc3_bbg_file(covio_t *
+@@ -1013,6 +1013,8 @@ cov_file_t::read_gcc3_bbg_file(covio_t *
  if (expect_version != BBG_VERSION_GCC33)
  bbg_failed1("unexpected version=0x%08x", format_version_);
  break;
++case _NEWER_VERSION(10,2,'*'):   /* gcc-10.2 in Debian sid/bullseye */
 +case _NEWER_VERSION(10,1,'*'):   /* gcc-10.1 in Debian sid/bullseye */
  case _NEWER_VERSION(10,0,'e'):   /* gcc-10 package in Ubuntu Focal 20.04 
*/
  case _NEWER_VERSION(9,3,'*'):   /* gcc 9.3.0 in debian testing */



Bug#987544: RFP: envoyproxy -- high performance C++ distributed proxy designed for single services and applications

2021-04-25 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: envoyproxy
  Version : 1.18.2
  Upstream Author : Envoy Project Authors
* URL : http://envoyproxy.io/
* License : Apachev2
  Programming Lang: C++
  Description : high performance C++ distributed proxy designed for single 
services and applications

Envoy is an L7 proxy and communication bus designed for large modern service
oriented architectures.

Envoy is a self contained process that is designed to run alongside every
application server. All of the Envoys form a transparent communication mesh in
which each application sends and receives messages to and from localhost and is
unaware of the network topology.

I'm interested in helping out with packaging envoyproxy, but am not
sure if I have the bandwidth to do so myself. I'm filing this RFP primarily
as a way to track status.

See also https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy



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

2021-04-25 Thread Kamil Jonca
Package: libpam-u2f
Version: 1.1.0-1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: kjo...@poczta.onet.pl

I issued directly against pam-u2f module, at 
https://github.com/Yubico/pam-u2f/issues/175
but I am not sure if they want to do anything about it. 
I did some digging and found that pin verification flags are used only to print 
prompt for pin, 
but then there is not checking if pin is not null. 
And libuf2 library, in case of null pin does not perform pin checking.
So my PoC solution is attached (I hope this properly release resources)



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

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

Versions of packages libpam-u2f depends on:
ii  libc6   2.31-11
ii  libfido2-1  1.6.0-2
ii  libpam0g1.4.0-7
ii  libssl1.1   1.1.1k-1

Versions of packages libpam-u2f recommends:
ii  pamu2fcfg  1.1.0-1

libpam-u2f suggests no packages.

-- no debconf information
--- pam-u2f-1.1.0/util.c2020-08-10 09:19:44.0 +0200
+++ pam-u2f-1.1.0-kj/util.c 2021-04-25 13:42:44.707869293 +0200
@@ -1370,8 +1370,12 @@
   goto out;
 }
 
-if (pin_verification == FIDO_OPT_TRUE)
+if (pin_verification == FIDO_OPT_TRUE) {
   pin = converse(pamh, PAM_PROMPT_ECHO_OFF, "Please enter the PIN: ");
+ if (!pin)
+ goto out; 
+  
+   }
 if (user_presence == FIDO_OPT_TRUE ||
 user_verification == FIDO_OPT_TRUE) {
   if (cfg->manual == 0 && cfg->cue && !cued) {


Bug#987546: unblock: node-redis/3.0.2+~cs5.18.1-3

2021-04-25 Thread Yadd
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-redis

[ Reason ]
node-redis is vulnearable to a Regex Denial of Service

[ Impact ]
Medium security risk

[ Tests ]
No change in tests. Both build & autopkgtest passed

[ Risks ]
Change is trivial: just a regex fix. node-redis has no reverse
dependencies for now, so no risk for other packages

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

[ Other info ]
Patch also includes:
 * uploaders list update: Leo is MIA
 * GitHub regex fix in debian/watch

unblock node-redis/3.0.2+~cs5.18.1-3
diff --git a/debian/changelog b/debian/changelog
index 4f546a6..f25dee1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,14 @@
+node-redis (3.0.2+~cs5.18.1-3) UNRELEASED; urgency=medium
+
+  * Fix GitHub tags regex
+  * Uploaders: remove Leo Iannacone, thanks for your work!
+  * Fix potential ReDoS (Closes: CVE-2021-29469)
+
+ -- Yadd   Sun, 25 Apr 2021 13:54:43 +0200
+
 node-redis (3.0.2+~cs5.18.1-2) unstable; urgency=medium
 
+  [ Xavier Guimard ]
   * Add node-lodash-packages in test dependencies
 
  -- Xavier Guimard   Mon, 21 Dec 2020 06:13:22 +0100
diff --git a/debian/control b/debian/control
index 8fecf53..de2c694 100644
--- a/debian/control
+++ b/debian/control
@@ -1,6 +1,6 @@
 Source: node-redis
 Maintainer: Debian Javascript Maintainers 

-Uploaders: Leo Iannacone , Xavier Guimard 
+Uploaders: Yadd 
 Section: javascript
 Priority: optional
 Build-Depends: debhelper-compat (= 13)
diff --git a/debian/copyright b/debian/copyright
index 24794c5..b0ec804 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -21,7 +21,7 @@ License: Expat
 
 Files: debian/*
 Copyright: 2014 Leo Iannacone 
- 2019-2020 Xavier Guimard 
+ 2019-2020 Yadd 
 License: GPL-3
 
 Files: debian/tests/test_modules/intercept-stdout/*
diff --git a/debian/patches/CVE-2021-29469.patch 
b/debian/patches/CVE-2021-29469.patch
new file mode 100644
index 000..d074802
--- /dev/null
+++ b/debian/patches/CVE-2021-29469.patch
@@ -0,0 +1,19 @@
+Description: fix ReDoS
+Author: Leibale Eidelman 
+Origin: upstream, https://github.com/NodeRedis/node-redis/commit/2d11b6dc
+Bug: https://github.com/NodeRedis/node-redis/issues/1569
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-04-25
+
+--- a/lib/utils.js
 b/lib/utils.js
+@@ -127,7 +127,7 @@
+ reply_to_object: replyToObject,
+ print: print,
+ err_code: /^([A-Z]+)\s+(.+)$/,
+-monitor_regex: /^[0-9]{10,11}\.[0-9]+ \[[0-9]+ .+\]( ".+?")+$/,
++monitor_regex: /^[0-9]{10,11}\.[0-9]+ \[[0-9]+ .+\].*"$/,
+ clone: convenienceClone,
+ callback_or_emit: callbackOrEmit,
+ reply_in_order: replyInOrder
diff --git a/debian/patches/series b/debian/patches/series
index 73eead0..250556a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 avoid-failing-test.diff
 disable-tests-failing-with-redis-5.6.diff
 remove-cross-spawn.patch
+CVE-2021-29469.patch
diff --git a/debian/watch b/debian/watch
index ebfa712..34f812e 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,7 +1,7 @@
 version=4
 
 opts=filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/node-redis-$1.tar.gz/ \
- https://github.com/NodeRedis/node_redis/tags .*/archive/v?\.?([\d\.]+).tar.gz 
group
+ https://github.com/NodeRedis/node_redis/tags 
.*/archive/.*/v?\.?([\d\.]+).tar.gz group
 
 opts="searchmode=plain,pgpmode=none,ctype=nodejs,component=redis-commands" \
  https://registry.npmjs.org/redis-commands 
https://registry.npmjs.org/redis-commands/-/redis-commands-(\d[\d\.]*)@ARCHIVE_EXT@
 checksum


Bug#987547: better error message if dpkg-dev not installed

2021-04-25 Thread Marc Haber
Package: debspawn
Version: 0.4.1-1
Severity: wishlist

Hi,

while debspawn recommends build-essential, it can be installed without
dpkg-dev present. In this case, debspawn create fails with a python
backtrace because it cannot find dpkg-architecture.

This should either be a clearer error message ("dpkg-architecture
missing, install dpkg-dev to allow operation") or dpkg-dev should be a
Depends.

Greetings
Marc


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

Kernel: Linux 5.11.15-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debspawn depends on:
ii  debootstrap1.0.123
ii  python33.9.2-3
ii  python3-toml   0.10.1-1
ii  systemd-container  247.3-5
ii  zstd   1.4.8+dfsg-2.1

Versions of packages debspawn recommends:
ii  build-essential  12.9
ii  devscripts   2.21.1

Versions of packages debspawn suggests:
ii  sudo  1.9.6-1~exp1

-- no debconf information



Bug#987548: buster-pu: package node-redis/2.8.0-1+deb10u1

2021-04-25 Thread Yadd
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
rode-redis is vulnerable ro ReDoS (CVE-2021-29469

[ Impact ]
Medium risk

[ Tests ]
No

[ Risks ]
No risk, node-redis has no reverse dependencies and patch is trivial

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Regex update

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index e865de4..5994010 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-redis (2.8.0-1+deb10u1) unstable; urgency=medium
+
+  * Fix potential ReDoS (Closes: CVE-2021-29469)
+
+ -- Yadd   Sun, 25 Apr 2021 14:09:33 +0200
+
 node-redis (2.8.0-1) unstable; urgency=medium
 
   * Add components in gbp.conf and debian/watch (used for test only):
diff --git a/debian/patches/CVE-2021-29469.patch 
b/debian/patches/CVE-2021-29469.patch
new file mode 100644
index 000..d074802
--- /dev/null
+++ b/debian/patches/CVE-2021-29469.patch
@@ -0,0 +1,19 @@
+Description: fix ReDoS
+Author: Leibale Eidelman 
+Origin: upstream, https://github.com/NodeRedis/node-redis/commit/2d11b6dc
+Bug: https://github.com/NodeRedis/node-redis/issues/1569
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-04-25
+
+--- a/lib/utils.js
 b/lib/utils.js
+@@ -127,7 +127,7 @@
+ reply_to_object: replyToObject,
+ print: print,
+ err_code: /^([A-Z]+)\s+(.+)$/,
+-monitor_regex: /^[0-9]{10,11}\.[0-9]+ \[[0-9]+ .+\]( ".+?")+$/,
++monitor_regex: /^[0-9]{10,11}\.[0-9]+ \[[0-9]+ .+\].*"$/,
+ clone: convenienceClone,
+ callback_or_emit: callbackOrEmit,
+ reply_in_order: replyInOrder
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..1d28461
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2021-29469.patch


Bug#986702: openafs-fileserver: Upgrade from stretch broken (missing dependency)

2021-04-25 Thread Adrian Bunk
Control: unarchive 934236
Control: severity 934236 serious
Control: forcemerge 934236 -1

On Fri, Apr 09, 2021 at 12:48:27PM -0700, Benjamin Kaduk wrote:
> On Fri, Apr 09, 2021 at 03:29:48PM -0400, Chaskiel Grundman wrote:
> > Package: openafs-fileserver
> > Version: 1.8.2-1+deb10u1
> > Severity: important
> > 
> > Dear Maintainer,
> > While upgrading a system from stretch (9.9) to buster (10.9), I had a
> > failure in this package:
> > 
> > Setting up openafs-fileserver (1.8.2-1+deb10u1) ...
> > /var/lib/dpkg/info/openafs-fileserver.postinst: 24:
> > /var/lib/dpkg/info/openafs-fileserver.postinst: akeyconvert: not found
> > dpkg: error processing package openafs-fileserver (--configure):
> >  installed openafs-fileserver package post-installation script
> > subprocess returned error exit status 127
> > dpkg: dependency problems prevent configuration of openafs-dbserver:
> >  openafs-dbserver depends on openafs-fileserver; however:
> >   Package openafs-fileserver is not configured yet.
> > 
> > dpkg: error processing package openafs-dbserver (--configure):
> >  dependency problems - leaving unconfigured
> > Errors were encountered while processing:
> >  openafs-fileserver
> >  openafs-dbserver
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > 
> > It appears that this package needs to depend on openafs-krb5, or that
> > the postinst needs to not attempt to convert the keys.
> 
> or only convert the keys if akeyconvert is available, yes.
> 
> Thanks, this is a good catch.

In bullseye the same bug was already fixed in #934236 by adding the 
dependency, missing is a backport of the dependency to buster.

> -Ben

cu
Adrian



Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

2021-04-25 Thread Chris Hofstaedtler
Hi,

* Holger Wansing  [210425 11:34]:
> Chris Hofstaedtler  wrote (Sat, 24 Apr 2021 23:45:13 +0200):
> > * Holger Wansing  [210424 21:42]:
> > > While trying to debug another problem yesterday, I found that the RC1 
> > > graphical
> > > installer fails to go forward, when selecting one of these languages:
> > >   - Kannada
> > >   - Marathi
> > >   - Persian
> > >   - Sinhala
> > 
> > I spent a few hours today on this issue, but did not get very far.
> > Not totally unexpected if you know nothing about the installer.
> > 
> > I have, however, a perf top output to share. I believe this more or less 
> > means
> > the font rendering (pango, fontconfig) is stuck somehow?
> 
> That might support my wild guess, that "Drop fontconfig tweaks" changings 
> could be related.
> https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f
> 
> However, I don't get it, why recent dailies are not affected, while RC1 (and
> alpha3) is ???

While the -exact- same bug does not appear on the
20210424-7/amd64/iso-cd/debian-testing-amd64-netinst.iso image, I
think the bug is still there, just better hidden.
I managed to make debconf hang by:
  - select Marathi
  - on the next screen, click the Back button
  - in the now appearing list, select something else (I think two
above from what was selected)
  - click the Continue button
  - hangs

Chris



Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use error

2021-04-25 Thread Bernd Zeimetz
Hi Aiden,

forwarded to upstream: https://gitlab.com/gpsd/gpsd/-/issues/136

Shouldn't take too long to fix, maybe I'll have a look into it


Bernd

On Sun, 2021-04-25 at 10:57 +, Aiden Morrison wrote:
> Hi Bernd,
> 
> I can get this to manifest with
> ntrip://SNTu0:pa...@caster.dyndns.org:2101/NOT
> 
> The same caster/mountpoint are working with each of the Ublox u-center
> software, the BKG Ntrip Client (https://igs.bkg.bund.de/ntrip/bnc) and the
> previously mentioned ntripclient code on github.
> BKG Ntrip Client - BNC
> BKG Ntrip Client (BNC) The BKG Ntrip Client (BNC) is an Open Source multi-
> stream client program designed for a variety of real-time GNSS
> applications.
> igs.bkg.bund.de
> Please let me know if further information is helpful.
> 
> -Aiden
> From: Bernd Zeimetz 
> Sent: 25 April 2021 11:52
> To: Aiden Morrison ; 987...@bugs.debian.org
> <987...@bugs.debian.org>
> Subject: Re: Bug#987412: gpsd ntrip mountpoint (aka stream) parsing and use
> error 
> Hi,
> 
> do you have a example url for me? Maybe a public ntrip caster with auth,
> that
> shows the bug?
> 
> Thanks,
> 
> Bernd
> 
> On Fri, 2021-04-23 at 13:30 +, Aiden Morrison wrote:
> > Package: gpsd
> > Version: 3.22 (revision 3.22)
> > Error text: gpsd:ERROR not authorized for Ntrip stream
> > caster.address.extension/mountpoint
> >  
> > Reproduction: provide an ntrip stream address per the documentation of
> > gpsd
> > at
> > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgpsd.gitlab.io%2Fgpsd%2Fgpsd.html&data=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J6W2QinFv7DlRv3%2BTzKDFRPcTbgLEbJ5yYUqTznZaiI%3D&reserved=0
> > ) in the form
> > "ntrip://username:passw...@address.of.caster:port/mountpoint" and note
> > that
> > gpsd will throw the above error.
> >  
> > If the configuration string is intentionally malformed to include a "/"
> > after the mountpoint name, this error is not thrown, however the
> > corrections are not sent to the attached GNSS receiver:
> >  
> > cgps reports string
> > {"class":"DEVICE","path":"ntrip://user:p...@address.of.caster:port/mountp
> > oi
> > nt/","activated":0} showing the malformed mountpoint identifier
> >  
> > I can connect to the same ntrip server
> > using 
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnunojpg%2Fntripclient&data=04%7C01%7Caiden.morrison%40sintef.no%7Ced4144881c454d0f9b3708d907cfd559%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637549411485653196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QjyVo3xXClMT1wKpQrYttB5LK37JIt%2FRBMR%2F44PGwNw%3D&reserved=0
> >  as well as two commercial
> > software packages, so the error appears to be in how gpsd is interpreting
> > the connection string.
> >  
> > If credentials would be helpful in reproducing this bug I can be
> > contacted
> > ataiden.morri...@sintef.no
> >  
> >  
> 

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

2021-04-25 Thread Cyril Brulebois
Steve McIntyre  (2021-04-22):
> From checking (as discussed in IRC with Phil), rescue-mode moved from
> 1.78 to 1.80 between those two builds. The only changes were in
> translations, so the problem must be elsewhere. :-(

Must it really?

With a fresh install (with LVM but oh well), using netboot/gtk/mini.iso
from RC 1 gets me a shell into the installed system just fine if the
rescue mode is configured in French (habit letting me smoke test
translation related fun, in addition to getting me my usual layout)…

but that fails if I stick to English.


I've only started looking into it, but I thought I'd drop this quick
note without waiting. ;)



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


signature.asc
Description: PGP signature


Bug#987459: Reverting the doc removal?

2021-04-25 Thread Ole Streicher

Control: tags +patch

Dear maintainer,

During the BSP-2021-szg, I checked this bug, and to me it seems that 
just re-enabling the doc building leads to a buildable and usable -doc 
package:


$ ls -l /usr/share/doc/python3-lmfit/html/
insgesamt 856
-rw-r--r--  1 root root  11458  2. Mär 11:41 bounds.html
-rw-r--r--  1 root root 144289  2. Mär 11:41 builtin_models.html
-rw-r--r--  1 root root  31044  2. Mär 11:41 confidence.html
-rw-r--r--  1 root root  25640  2. Mär 11:41 constraints.html
-rw-r--r--  1 root root  26495  2. Mär 11:41 contents.html
drwxr-xr-x 34 root root   4096 25. Apr 13:55 _downloads
[...]

(Quick check on the contents also show

The python3-jupyter-sphinx dependency (that was removed from build-deps) 
is still not needed, as its use was disabled in

debian/patches/no_jupyter_sphinx.execute.patch.

Therefore, I would propose to just re-enable the building in d/rules, as 
shown in the patch and the MR !2. I don't want to do this myself (yet), 
as I do not understand fully why the -doc build was disabled.


Could you have a look?

Best regards

Ole


From b00d720f36d10c6130332bb5aa49501e47d812b4 Mon Sep 17 00:00:00 2001
From: Ole Streicher 
Date: Sun, 25 Apr 2021 14:11:05 +0200
Subject: [PATCH] Re-enable documentation build

Closes: #987459
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 08ef8e4..0f462ed 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,6 +19,6 @@ override_dh_auto_test:
 	dh_auto_test
 
 override_dh_installdocs-indep:
-	#PYTHONPATH=. http_proxy='localhost' python3 -m sphinx -N -bhtml -D 
mathjax_path="/usr/share/javascript/mathjax/MathJax.js" doc/ build/html 
 # HTML generator
+	PYTHONPATH=. http_proxy='localhost' python3 -m sphinx -N -bhtml -D mathjax_path="/usr/share/javascript/mathjax/MathJax.js" doc/ build/html 
 # HTML generator
 	dh_installdocs -i
-	#dh_installdocs build/html -p python-lmfit-doc --doc-main-package=python3-lmfit
+	dh_installdocs build/html -p python-lmfit-doc --doc-main-package=python3-lmfit
-- 
2.30.2



Bug#955485: Composer not working

2021-04-25 Thread Carlos R. Pasqualini
Dear Maintainer et all



I've been hit by this issue, after setup composer from zero a few days
ago, right now it doesn't even work without parameters:


~: composer 

In BaseIO.php line 128:
  
  Your github oauth token for github.com contains invalid characters:
"ghp_AAA"





I made the workaround of switching from oauth to HTTP Basic Auth in
the file: ~/.config/composer/auth.json


  "http-basic": {
"github.com": {
  "username": "[YOUR-GITHUB-USERNAME]",
  "password": "ghp_[YOUR-PERSONAL-TOKEN]"
}
  }

I found this workaround in:
https://stackoverflow.com/questions/26691681/composer-unexpectedvalueexception-error-will-trying-to-use-composer-to-install


Thanks!



Bug#987491: installation-reports: Successful install AMD A6 - nonfree AMD Radeon firmware needed

2021-04-25 Thread Holger Wansing
Hi,

"Andrew M.A. Cater"  wrote (Sat, 24 Apr 2021 15:26:00 
+):
> Initial boot:   [O ]
> Detect network card:[O ]
> Configure network:  [O ]
> Detect media:   [O ]
> Load installer modules: [O ]
> Clock/timezone setup:   [O ]
> User/password setup:[O ]
> Detect hard drives: [O ]
> Partition hard drives:  [O ]
> Install base system:[O ]
> Install tasks:  [O ]
> Install boot loader:[O ]
> Overall install:[O ]
> 
> Comments/Problems:
> 
> Requires non-free Radeon drivers for r600 - firmware-amd-graphics

please be more specific:
What happened, when no firmware is installed?
Did the system work so far (graphical UI is visible and usable)?
Or was it suffering from problems like "black screen" or "garbled screen" as 
other users reported?


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Bug#987549: unblock: maxima/5.44.0-3

2021-04-25 Thread Camm Maguire
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package maxima

[ Reason ]
RC bug 969410 just filed and fixed, enabling package install when
xemacs21 is installed.

[ Impact ]
Package will be uninstallable if xemacs21 is installed.

[ Tests ]
None.

[ Risks ]
None.  Change reverts to working implementation in 5.43 until xemacs21
supports the newer cl-lib.

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

-
source debdiff maxima_5.44.0-2.dsc to maxima_5.44.0-3.dsc
-
diff -Nru maxima-5.44.0/debian/changelog maxima-5.44.0/debian/changelog
--- maxima-5.44.0/debian/changelog  2020-08-29 18:16:49.0 +
+++ maxima-5.44.0/debian/changelog  2021-04-24 13:41:46.0 +
@@ -1,3 +1,11 @@
+maxima (5.44.0-3) unstable; urgency=high
+
+  * patch imaxima.el for xemacs21 compatibility
+  * Bug fix: "maxima-emacs 5.44 does not work with XEmacs", thanks to
+Agustin Martin (Closes: #969410).
+
+ -- Camm Maguire   Sat, 24 Apr 2021 13:41:46 +
+
 maxima (5.44.0-2) unstable; urgency=medium
 
   * emacs24 -> emacs-gtk in control dependencies
diff -Nru maxima-5.44.0/debian/patches/series 
maxima-5.44.0/debian/patches/series
--- maxima-5.44.0/debian/patches/series 2020-08-26 13:59:20.0 +
+++ maxima-5.44.0/debian/patches/series 2021-04-24 13:40:49.0 +
@@ -23,3 +23,4 @@
 sys-proclaim-fix
 # imaxima-iso-no-html-build
 pass_rtest8_101_104_on_68k2
+xemacs21-compatibility
diff -Nru maxima-5.44.0/debian/patches/xemacs21-compatibility 
maxima-5.44.0/debian/patches/xemacs21-compatibility
--- maxima-5.44.0/debian/patches/xemacs21-compatibility 1970-01-01 
00:00:00.0 +
+++ maxima-5.44.0/debian/patches/xemacs21-compatibility 2021-04-24 
13:40:49.0 +
@@ -0,0 +1,48 @@
+Description: 
+ TODO: Put a short summary on the line above and replace this paragraph
+ with a longer explanation of this change. Complete the meta-information
+ with other relevant fields (see below for details). To make it easier, the
+ information below has been extracted from the changelog. Adjust it or drop
+ it.
+ .
+ maxima (5.44.0-2) unstable; urgency=medium
+ .
+   * emacs24 -> emacs-gtk in control dependencies
+   * compat 13
+   * update lintian-overrides
+   * iconv -t UTF-8 on national encoding files
+Author: Camm Maguire 
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2021-04-24
+
+--- maxima-5.44.0.orig/interfaces/emacs/imaxima/imaxima.el
 maxima-5.44.0/interfaces/emacs/imaxima/imaxima.el
+@@ -80,7 +80,7 @@
+ (require 'advice)
+ 
+ (require 'comint)
+-(require 'cl-lib)
++(require 'cl);FIXME cl-lib, xemacs21 compatibility
+ 
+ ;; XEmacs stuff
+ 
+@@ -174,7 +174,7 @@ Unless optional argument INPLACE is non-
+   :group 'imaxima
+   :type (cons 'choice
+ (mapcar (lambda (type) (list 'const type))
+-(cl-remove-if-not 'imaxima-image-type-available-p
++(remove-if-not 'imaxima-image-type-available-p; FIXME 
cl-remove-if-not, xemacs21 compatibility
+imaxima-image-types
+ 
+ (defcustom imaxima-pt-size 11
-

[ Other info ]


unblock maxima/5.44.0-3

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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#957366: intercal: ftbfs with GCC-10

2021-04-25 Thread Reiner Herrmann
Control: forward -1 https://gitlab.com/esr/intercal/-/issues/4
Control: tags -1 + patch

Hi,

the attached patch fixes the FTBFS with GCC 10.

Kind regards,
  Reiner
diff -u intercal-0.30/debian/rules intercal-0.30/debian/rules
--- intercal-0.30/debian/rules
+++ intercal-0.30/debian/rules
@@ -1,5 +1,6 @@
 #!/usr/bin/make -f
 
+export DEB_CFLAGS_MAINT_APPEND=-fno-toplevel-reorder
 DPKG_EXPORT_BUILDFLAGS=1
 include /usr/share/dpkg/buildflags.mk
 
only in patch2:
unchanged:
--- intercal-0.30.orig/src/perpet.c
+++ intercal-0.30/src/perpet.c
@@ -85,7 +85,7 @@
 /* function created by yacc */
 extern int yyparse(void);
 
-int yydebug;
+extern int yydebug;
 
 /* compilation options */
 bool compile_only; 	/* just compile into C, don't run the linker */


signature.asc
Description: PGP signature


Bug#987504: imagemagick: attempt to perform an operation not allowed by the security policy `EPS'

2021-04-25 Thread Chris Hofstaedtler
* Adrian Bunk  [210425 12:34]:
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/kannel.html
[..]
> https://bugs.launchpad.net/ubuntu/+source/kannel/+bug/1838425

Kannel turned off building of PS docs in 1.4.5-7 (and stopped using
imagemagick); but obv. not in buster.



Bug#987550: unblock: fricas/1.3.6-6

2021-04-25 Thread Camm Maguire
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package fricas

[ Reason ]
RC bug 987456 just filed and fixed, missing build depend resulted in
some packages being empty

[ Impact ]
Empty packages render graphical UI unusable

[ Tests ]
None.

[ Risks ]
None.

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

-
source debdiff fricas_1.3.6-5 to fricas_1.3.6-6
-
diff -Nru fricas-1.3.6/debian/changelog fricas-1.3.6/debian/changelog
--- fricas-1.3.6/debian/changelog   2021-02-13 01:48:46.0 +
+++ fricas-1.3.6/debian/changelog   2021-04-24 13:23:44.0 +
@@ -1,3 +1,11 @@
+fricas (1.3.6-6) unstable; urgency=high
+
+  * libx11-dev -> libxpm-dev in build depends
+  * Bug fix: "fricas-{graphics,hypertex} are empty", thanks to Adrian Bunk
+(Closes: #987456).
+
+ -- Camm Maguire   Sat, 24 Apr 2021 13:23:44 +
+
 fricas (1.3.6-5) unstable; urgency=medium
 
   * clean build-depends
diff -Nru fricas-1.3.6/debian/control fricas-1.3.6/debian/control
--- fricas-1.3.6/debian/control 2021-02-13 01:48:30.0 +
+++ fricas-1.3.6/debian/control 2021-04-24 13:22:47.0 +
@@ -5,7 +5,7 @@
 Rules-Requires-Root: no
 Homepage: http://fricas.sourceforge.net/
 Build-Depends-Indep: dh-elpa, sharutils
-Build-Depends: debhelper-compat ( = 13 ), gcl ( >= 2.6.12-99 ), libgmp3-dev, 
libreadline-dev, libx11-dev
+Build-Depends: debhelper-compat ( = 13 ), gcl ( >= 2.6.12-99 ), libgmp3-dev, 
libreadline-dev, libxpm-dev
 Standards-Version: 4.5.1
 
 Package: fricas
-

[ Other info ]
(Anything else the release team should know.)

unblock fricas/1.3.6-6

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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

2021-04-25 Thread Étienne Mollier
Cyril Brulebois, on 2021-04-25 14:17:36 +0200:
> Steve McIntyre  (2021-04-22):
> > From checking (as discussed in IRC with Phil), rescue-mode moved from
> > 1.78 to 1.80 between those two builds. The only changes were in
> > translations, so the problem must be elsewhere. :-(
> 
> Must it really?
> 
> With a fresh install (with LVM but oh well), using netboot/gtk/mini.iso
> from RC 1 gets me a shell into the installed system just fine if the
> rescue mode is configured in French (habit letting me smoke test
> translation related fun, in addition to getting me my usual layout)…
> 
> but that fails if I stick to English.

Just read that, so did a few more tests:
 1. I just tested Qemu + French locale, I confirm the behavior;
 2. I ensured I was sticking to US Eastern locale on the laptop
with NVMes, I could get to the shell as well.

The "Enter rescue mode" intro window mentions the corresponding
block device, so might be a clue to pinpoint the issue; hope
this is not a red herring.

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


signature.asc
Description: PGP signature


Bug#987332: aprx automatically starts up with really bad default config

2021-04-25 Thread Heikki Hannikainen

On Sun, 25 Apr 2021, Evgeni Golov wrote:


On Thu, Apr 22, 2021 at 12:19:57AM +0300, Heikki Hannikainen wrote:


- Remove N0CALL-1 from the default configuration (comment the line out) so
that it will refuse to start up before configured with the callsign of the
user


Is N0CALL-1 part of the default config aprx ships upstream?


I am afraid it is. Not sure if debian ships the upstream default config 
file or its own.



- Ensure that the instances which have already been started up like this
will shut down again when upgraded to the next version


Not sure this is easily doable after the fact now, but we at least can
prevent new clients from poping up.


This would be very important to make this happen. Shipping a config with 
the "mycall N0CALL-1" line commented out would probably work.


  - Hessu



Bug#987551: unblock: dipy/1.3.0-3

2021-04-25 Thread Étienne Mollier
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Good Day,

Please unblock package dipy

[ Reason ]
dipy 1.3.0-3 fixes the grave bug #987453, since python3-dipy-lib
is unusable otherwise, and lots of submodules are missing from
python3-dipy.  It also addresses the serious bug #987517.

[ Impact ]
Removal of dipy would affect a dozen of users per popcon report.
This is a leaf package, so wouldn't affect buildability nor
installability of other packages in the archive.

[ Tests ]
Automated tests I carried on were those of default Salsa CI.
I'm surprised blhc ended successfully, since resulting shared
objects are missing hardening, per lintian report.  autopkgtest
are notably superficial for the moment.

Tests I manually carried on are:
  * running dipy_fetch to download some resources, since these
tests are not done automatically in any way anymore;
  * testing a couple of commands, such as dipy_align_affine,
or dipy_info, using the result of the download;
  * importing some of the missing cython modules to check that
they are now usable, such as dipy.core.interpolation, or
dipy.denoise.shift_twist_convolution.

[ Risks ]
The change to fill properly the package python3-dipy-lib adds a
lot of new cython modules to dipy, which are most likely not
toroughly field tested in Debian context this late in the hard
freeze.  Lintian reports a lot of warnings, so the package is
perhaps not in the best shape of the archive.  This is a leaf
package, so has very little chance to affect others in the
archive.

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

[ Other info ]
Not being of the field of endeavour myself, my very few testings
may not be representative of normal usage.

unblock dipy/1.3.0-3

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.
diff -Nru dipy-1.3.0/debian/changelog dipy-1.3.0/debian/changelog
--- dipy-1.3.0/debian/changelog 2021-01-20 11:52:53.0 +0100
+++ dipy-1.3.0/debian/changelog 2021-04-25 11:15:12.0 +0200
@@ -1,3 +1,14 @@
+dipy (1.3.0-3) unstable; urgency=medium
+
+  * Team upload.
+  * d/rules: prevent build time test suite from accessing network resources.
+Closes: #987517
+  * d/rules: install .so files in python3-dipy-lib; this makes several dipy
+modules, formerly missing, now usable.
+Closes: #987453
+
+ -- Étienne Mollier   Sun, 25 Apr 2021 11:15:12 
+0200
+
 dipy (1.3.0-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru dipy-1.3.0/debian/rules dipy-1.3.0/debian/rules
--- dipy-1.3.0/debian/rules 2021-01-20 11:52:53.0 +0100
+++ dipy-1.3.0/debian/rules 2021-04-25 10:47:24.0 +0200
@@ -57,6 +57,8 @@
# cd build to prevent use of local/not-built source tree
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
set -x ; \
+   export http_proxy=http://127.0.0.1:9/ ; \
+   export https_proxy=https://127.0.0.1:9/ ; \
for PYTHON in $(PY3VERS); do \
export PYTHONPATH=$$(pybuild --print build_dir --interpreter 
python$$PYTHON); \
echo "I: Running Dipy unittests using $$PYTHON"; \
@@ -69,12 +71,17 @@
done
 endif
 
-## remove .so libraries from main package, and call dh_numpy*
+## move .so libraries into -lib package, and call dh_numpy*
 ## while removing 2 if not present
 _dh_python%:
-   if [ -d debian/$(PACKAGE$*_NAME)/usr/lib ]; then \
-  find debian/$(PACKAGE$*_NAME)/usr/lib -name "*.so" -delete; \
-   fi
+   set -e \
+   ; test -d debian/$(PACKAGE$*_NAME)/usr/lib || exit 0 \
+   ; for lib in $$(find debian/$(PACKAGE$*_NAME)/usr/lib -name "*.so") \
+   ; dosdir=$$(dirname $$lib) \
+   ;   tdir=debian/$(PACKAGE$*_NAME)-lib/$${sdir#*$(PACKAGE$*_NAME)/} \
+   ;   mkdir -p "$${tdir}" \
+   ;   mv -v "$${lib}" "$${tdir}" \
+   ; done
[ -e /usr/bin/dh_numpy$(*:2=) ] && dh_numpy$(*:2=) 
-p$(PACKAGE$*_NAME)-lib || :
dh_python$*
 


signature.asc
Description: PGP signature


Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

2021-04-25 Thread Cyril Brulebois
Cyril Brulebois  (2021-04-24):
> 
> 
> cdebconf-* were updated. There's a change in there but apparently only
> for the text frontend.
> 
> At least for src:cdebconf's udebs, the libc they were built against is
> no longer the same (2.29 vs. 2.31).
> 
> This might very well be a red herring, though.
> 
> 

Red herring confirmed, based on my rebuilding (against testing) a
netboot-gtk image, with all 4 udebs produced by src:cdebconf downgraded
to the previous version (by reinjecting them, deb-reversion'd with an
epoch, through build/localudebs).

Out of curiosity, I've also reverted the deletion of fontconfig tweaks
(due to the other bug that is language and possibly font-specific). I
had little hope, and that didn't change anything indeed…

> FWIW: I plan to debug (likely starting by bisecting) this somewhen
> during the week-end or next week.

I've ran out of (apparently stupid this time around…) wild guesses, so I
suppose after a little nap it's going to be (heavy) hammer time…


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


signature.asc
Description: PGP signature


Bug#957892: ucarp: ftbfs with GCC-10

2021-04-25 Thread Reiner Herrmann
Control: tags -1 + patch

Hi,

the attached patch fixes the FTBFS with GCC 10.
Instead of creating a packed struct, the old code
created a global variable named "__packed".

Kind regards,
  Reiner
--- ucarp-1.5.2.orig/src/ip_carp.h
+++ ucarp-1.5.2/src/ip_carp.h
@@ -70,7 +70,7 @@
 u_int16_t   carp_cksum;
 u_int32_t   carp_counter[2];
 unsigned char   carp_md[20];/* SHA1 HMAC */
-} __packed;
+} __attribute__ ((packed));
 
 #define CARP_DFLTTL 255
 


signature.asc
Description: PGP signature


Bug#987552: FTBFS caused by imagemagick

2021-04-25 Thread Chris Hofstaedtler
Source: muttprint
Version: 0.73-8.1
Severity: serious

Caused by #987504, see that bug for further details.

Log fragment:

dh_testdir
# convert images (and make pics/ build work)
cd pics && \
for i in BabyTuX_color.eps BabyTuX.eps Debian_color.eps Debian.eps; do \
convert $i `basename $i .eps`.png; \
done && \
convert penguin.eps penguin.jpg
convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `PS' @ error/constitute.c/IsCoderAuthorized/421.
convert-im6.q16: no images defined `BabyTuX_color.png' @ 
error/convert.c/ConvertImageCommand/3229.
convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `PS' @ error/constitute.c/IsCoderAuthorized/421.
convert-im6.q16: no images defined `BabyTuX.png' @ 
error/convert.c/ConvertImageCommand/3229.
convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `PS' @ error/constitute.c/IsCoderAuthorized/421.
convert-im6.q16: no images defined `Debian_color.png' @ 
error/convert.c/ConvertImageCommand/3229.
convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `PS' @ error/constitute.c/IsCoderAuthorized/421.
convert-im6.q16: no images defined `Debian.png' @ 
error/convert.c/ConvertImageCommand/3229.
make: *** [debian/rules:23: build-indep-stamp] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2



Bug#987312: please allow ignoring recommends/suggests

2021-04-25 Thread Marc Haber
On Thu, Apr 22, 2021 at 04:22:45AM +0200, Matthias Klumpp wrote:
> Am Mi., 21. Apr. 2021 um 15:51 Uhr schrieb Marc Haber
> :
> > I would like to have a possibility to not install recommends/suggests in
> > the container, to keep the containers small.
> 
> Does passing `--variant=minbase` to `debspawn create` work for you?

Yes. I was not aware of that option, is it mentioned in the docs? I
didnt find the reference in the manpage.

apt inside the container doesn't seem to see the configratuion though. I
would have expected that --variant=minbase would end up with a
similiarly configured apt (debspawn login, apt install devscripts, for
example).

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#974645: gnome-remote-desktop: unable to connect

2021-04-25 Thread Philip Wyett
On Fri, 13 Nov 2020 10:16:44 +0100 jsb...@mimuw.edu.pl (Janusz S. 
=?utf-8?Q?Bie=C5=84?=) wrote:
> Package: gnome-remote-desktop
> Version: 0.1.7-1
> Severity: normal
> 
> Perhaps a stupid mistake of mine, but I'm unable to connect from the
> buster on my desktop to the buster on my computer. I am unable to find
> any advice  on the Internet.
> 
> This bug report is sent from the laptop.  In Settings sharing is On.
> 
> On the desktop I used almost all clients and protocols available. For
> example, Remote Destop Viewer gives "Unable to connect to VNC server".
> 
> I guess some useful information is in logs, but which logs?
> 
> I'm quite anxious to solve the problem quickly because of the bug
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974581.
> 
> I will appreciate your help.
> 
> JSB
> 
> -- System Information:
> Debian Release: 10.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-12-amd64 (SMP w/2 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:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gnome-remote-desktop depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
> ii  libc62.28-10
> ii  libglib2.0-0 2.58.3-2+deb10u2
> ii  libnotify4   0.7.7-4
> ii  libpipewire-0.2-10.2.5-1
> ii  libsecret-1-00.18.7-1
> ii  libvncserver10.9.11+dfsg-1.3+deb10u4
> ii  pipewire 0.2.5-1
> 
> gnome-remote-desktop recommends no packages.
> 
> gnome-remote-desktop suggests no packages.
> 
> -- no debconf information
> 
> -- 
>  ,   
> Janusz S. Bien
> emeryt (emeritus)
> https://sites.google.com/view/jsbien
> 
> 

Hi,

Have you resolved this issue or is it still as reported?

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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


Bug#987527: clonezilla: Fails to install on bullseye

2021-04-25 Thread Chris Hofstaedtler
Control: severity -1 serious

* Matthias Gies  [210425 13:11]:
> clonezilla (3.35.2-2) wird eingerichtet ...
> ln: die symbolische Verknüpfung '/opt/' konnte nicht angelegt werden: Datei 
> oder Verzeichnis nicht gefunden
> dpkg: Fehler beim Bearbeiten des Paketes clonezilla (--configure):
>  »installiertes clonezilla-Skript des Paketes post-installation«-Unterprozess 
> gab den Fehlerwert 1 zurück

I believe packages are not allowed to install stuff into /opt. 
If they are, this should be a normal file install, and not a
postinst hack.

Chris



Bug#987552: FTBFS caused by imagemagick

2021-04-25 Thread Rene Engelhard
block 987552 by 987504

thanks


Hi,

Am 25.04.21 um 15:05 schrieb Chris Hofstaedtler:
> Caused by #987504, see that bug for further details.

Then imagemagick should be fixed. I mean, come on, it's simple image
convert...


Regards,


Rene



Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

2021-04-25 Thread Holger Wansing
Hi,

Chris Hofstaedtler  wrote (Sat, 24 Apr 2021 23:45:13 +0200):
> Hello,
> 
> * Holger Wansing  [210424 21:42]:
> > While trying to debug another problem yesterday, I found that the RC1 
> > graphical
> > installer fails to go forward, when selecting one of these languages:
> > - Kannada
> > - Marathi
> > - Persian
> > - Sinhala
> 
> I spent a few hours today on this issue, but did not get very far.
> Not totally unexpected if you know nothing about the installer.
> 
> I have, however, a perf top output to share. I believe this more or less means
> the font rendering (pango, fontconfig) is stuck somehow?

That might support my wild guess, that "Drop fontconfig tweaks" changings 
could be related.
https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f

However, I don't get it, why recent dailies are not affected, while RC1 (and
alpha3) is ???

(That might be the reason, why this issue slipped through our attention until
now...)

Are there differences during build for the "release builds" (alpha, rc) 
compared to the dailies?

CC'ing Steve for debian-cd side...

Holger



> Good luck,
> Chris
> 
> Samples: 82K of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): 
> 4370334125 lost: 0/0 drop: 0/0
> Overhead  Shared ObjectSymbol
>5.29%  /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2   0x13010
> d [.] pango_default_break 
>1.44%  /lib/libharfbuzz.so.0.20704.00x769b0
> ! [.] 0x000769b0  
>1.17%  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x8487e
> B [.] g_utf8_get_char 
>1.05%  /lib/libharfbuzz.so.0.20704.00x57448
> ! [.] 0x00057448  
>1.04%  /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2   0x1fff2
> d [.] 0x0001fff2  
>1.02%  /lib/libharfbuzz.so.0.20704.00x8eff5
> ! [.] 0x0008eff5  
>0.88%  /lib/libharfbuzz.so.0.20704.00x611d0
> ! [.] 0x000611d0  
>0.83%  /lib/libharfbuzz.so.0.20704.00x5741e
> ! [.] 0x0005741e  
>0.81%  /lib/x86_64-linux-gnu/libc-2.31.so   0x88bbd
> D [.] _int_malloc 
>0.80%  /lib/libharfbuzz.so.0.20704.00x5a9f7
> ! [.] 0x0005a9f7  
>0.79%  /lib/libharfbuzz.so.0.20704.00x573d9
> ! [.] 0x000573d9  
>0.71%  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x3edd8
> B [.] g_hash_table_lookup 
>0.70%  /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2   0xf5a0 
> d [.] g_utf8_get_char@plt 
>0.68%  /lib/libharfbuzz.so.0.20704.00x573ee
> ! [.] 0x000573ee  
>0.60%  /lib/libharfbuzz.so.0.20704.00x5a830
> ! [.] 0x0005a830  
>0.57%  /lib/libharfbuzz.so.0.20704.00x71730
> ! [.] 0x00071730  
>0.57%  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x70590
> B [.] g_slice_free1   
>0.56%  /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.330x1e7883   
> d [.] gtk_text_layout_get_line_display
>0.55%  /lib/libharfbuzz.so.0.20704.00x6a190
> ! [.] 0x0006a190  
>0.52%  /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4600.2   0x34977
> d [.] pango_shape_with_flags  
>0.51%  /lib/libharfbuzz.so.0.20704.00xc210 
> ! [.] 0xc210  
>0.51%  /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8 0x18fff
> B [.] g_object_unref  
>0.46%  /lib/libharfbuzz.so.0.20704.00x578b2
> ! [.] 0x000578b2  
>0.44%  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.80x6ff70
> B [.] g_slice_alloc   
>0.43%  /lib/x86_64-linux-gnu/libc-2.31.so   0x86b1d
> D [.] _int_free   
>0.41%  /lib/libharfbuzz.so.0.20704.00x5a8a4
> ! [.] 0x0005a8a4  
>0.40%  /lib/libharfbuzz.so.0.20704.0 

Bug#987420: closed by Brian Potkin (Re: Bug#987420: hplip seems incompatible with current cups)

2021-04-25 Thread Brian Potkin
On Fri 23 Apr 2021 at 20:00:03 +, Debian Bug Tracking System wrote:

A couple of days ago I said:

> What a coincidence!!! I have an HP Envy 4500. Printing and scanning
> work well with it.
> 
> I am closing the bug report on that basis.

Hello Yadd,

I feel I was a little less than helpful to you when the report was
closed. I would strongly suggest you abandon using HPLIP and instead
read

  https://wiki.debian.org/CUPSDriverlessPrinting

I have used my ENVY 4500 very successfully to print over USB and
wireless using the techniques on that page. In case scanning does not
work with the SANE driver, I would install sane-airscan. That
definitely works.

Cheers,

Brian.



Bug#987553: RM: pynn/experimental -- NVIU; package wasn't removed automatically

2021-04-25 Thread Luca Falavigna
Package: ftp.debian.org
Severity: normal



Bug#987545: Better patch

2021-04-25 Thread Kamil Jońca
Slightly better patch, can handle 0-length PIN (i.e. when we simply push Enter
for PIN)
KJ
--- ../pam-u2f-1.1.0/util.c	2020-08-10 09:19:44.0 +0200
+++ util.c	2021-04-25 15:45:41.780841355 +0200
@@ -1370,8 +1370,21 @@
   goto out;
 }
 
-if (pin_verification == FIDO_OPT_TRUE)
-  pin = converse(pamh, PAM_PROMPT_ECHO_OFF, "Please enter the PIN: ");
+if (pin_verification == FIDO_OPT_TRUE) {
+			pin = converse(pamh, PAM_PROMPT_ECHO_OFF, "Please enter the PIN: ");
+			if (!pin)
+goto out; 
+			else {
+if (0 == strlen(pin)){
+	D(cfg->debug_file, "Empty PIN entered");
+	explicit_bzero(pin, strlen(pin));
+	free(pin);
+	pin = NULL;
+	goto out;
+}
+
+			}
+		}
 if (user_presence == FIDO_OPT_TRUE ||
 user_verification == FIDO_OPT_TRUE) {
   if (cfg->manual == 0 && cfg->cue && !cued) {

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


Bug#987332: aprx automatically starts up with really bad default config

2021-04-25 Thread Evgeni Golov
On Sun, Apr 25, 2021 at 03:41:38PM +0300, Heikki Hannikainen wrote:
> On Sun, 25 Apr 2021, Evgeni Golov wrote:
> 
> > On Thu, Apr 22, 2021 at 12:19:57AM +0300, Heikki Hannikainen wrote:
> > 
> > > - Remove N0CALL-1 from the default configuration (comment the line out) so
> > > that it will refuse to start up before configured with the callsign of the
> > > user
> > 
> > Is N0CALL-1 part of the default config aprx ships upstream?
> 
> I am afraid it is. Not sure if debian ships the upstream default config file
> or its own.

Looks like it's shipping upstream, yeah.

> > > - Ensure that the instances which have already been started up like this
> > > will shut down again when upgraded to the next version
> > 
> > Not sure this is easily doable after the fact now, but we at least can
> > prevent new clients from poping up.
> 
> This would be very important to make this happen. Shipping a config with the
> "mycall N0CALL-1" line commented out would probably work.

I am not the maintainer of aprx, just someone who wants to fix a bug,
so I'd prefer not to have the last call on this, but let me give you my
view:

If we change the default config, but let the service enabled, it will
fail to start (which is *technically* what you want, as it will prevent
wrongly configured installations from connecting to you). At the same
time, everyone who updates from Buster to Bullseye (and has the bad old
config) will face a failed upgrade and has to search why it failed, what
they have to fix and then restart the upgrade.

We're not breaking a working service with this approach, but it also
feels weird towards the user (even if we can question why they have aprx
installed, when it's not properly configured -- or is there any use
without the daemon running correctly?).

I think it should be possible to detect the "N0CALL" configurations on
upgrade and disable the service, thus reaching the same state as with my
above change for new installs.

This, plus some documentation in README.Debian would make the user
expirience much better than a failed upgrade?

Evgeni



Bug#837809: Interesting venture

2021-04-25 Thread ALAN ANDRES GUAJARDO CARO
-



I have a lucrative business venture to discuss with you.



If interested, please get back via email: aa1...@mtazzo.com



Regards!

P A



Bug#987554: wine-development should be replaced with wine in experimental+backports

2021-04-25 Thread Adrian Bunk
Source: wine-development
Version: 5.6-2
Severity: serious

wine-development has already missed the deadline for bullseye,
but IMHO this is a good thing and it should be removed from Debian.

There is only limited value in having the ancient development
release 4.2 in buster today, users would have benefitted more
from wine 5.0 in buster-backports when it entered testing
in January 2020.

bullseye users would also benefit more from wine 6.0 in
bullseye-backports than they would have from
wine-development 5.5 or 5.6 in bullseye.

For development purposes the normal way to maintain development
releases would be a version of wine in experimental.



Bug#977730: [Pkg-privacy-maintainers] Bug#977730: torbrowser-launcher: Signature verification failed, key expired

2021-04-25 Thread Roger Shimizu
On Sun, Dec 20, 2020 at 3:36 AM Jean-Michel Vourgère  wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.3-3
> Severity: important
>
> Dear Maintainer,
>
> When installing on a fresh bullseye, torbrowser is downloaded, then this
> message is printed:
>
> > SIGNATURE VERIFICATION FAILED

I'm wondering whether you really had this problem on 0.3.3-3
It supposed to be fixed since 0.3.2-12
And personally I cannot reproduce this issue on my system using 0.3.3-3~bpo10+1

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



Bug#987555: sbuild: should support -J as well

2021-04-25 Thread Yangfl
Package: sbuild
Severity: wishlist

According to the man page of dpkg-buildpackage:
  -j, --jobs[=jobs|auto]
... Will add itself to the MAKEFLAGS environment variable, which
should cause all subsequent make invocations to inherit the option,
thus forcing the parallel setting on the packaging (and possibly the
upstream build system if that uses make) regardless of their support
for parallel builds, which might cause build failures...

and `-J` seems to be the right option. However, sbuild does not
support `-J`, neither does it mention it will lead to an unsafe option
of `dpkg-buildpackage`. Please add support to the `-J` option, or at
least refer to the `dpkg-buildpackage` man page in sbuild man page.



Bug#976080: pdfxup doesn't work anymore

2021-04-25 Thread Nicolas Markey


> 2) I cannot reproduce the bug. Apparently, it occurred with v1.60 (lines
> 360-361 test the version number of ghostscript). It seems that your bash
> does not correctly interpret "${GSVERSION%.*}", which should return "9".
> Could you try (in bash)
> 
> $ GSVERSION=9.53; echo "${GSVERSION%.*}"

I could figure out where the problem comes from: ghostscript added a
patch level in their version numbers. A way of fixing this is to replace
line 456 of pdfxup v2.00 (or line 363 of pdfxup v1.61, or line 354 of
v1.60), which currently reads

GSVERSION=`$GS --version 2>/dev/null`;

with

GSVERSION=`$GS --version 2>/dev/null|sed -e "s/\(.\.[^\.]*\)\..*/\\1/"`;


Sorry for this. This will be corrected in the next version of pdfxup.

Best wishes,

-- 
Nico



Bug#980155: apparmor="DENIED" profile="torbrowser_firefox" name="/proc/874474/cgroup"

2021-04-25 Thread Roger Shimizu
control: tags -1 +patch

On Fri, Jan 15, 2021 at 9:36 PM Paul Wise  wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.3-3
> Severity: minor
> File: /etc/apparmor.d/torbrowser.Browser.firefox
> Usertags: warnings
>
> When I start torbrowser-launcher I get apparmor denials like the
> following. There don't appear to be any consequences for this denial,
> the Tor Browser window starts up and works just fine. Possibly the
> Firefox sandboxing uses this file but I'm not sure.
>
> Jan 15 20:22:03 audit[874474]: AVC apparmor="DENIED" operation="open" 
> profile="torbrowser_firefox" name="/proc/874474/cgroup" pid=874474 
> comm="firefox.real" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

Thanks for the report!
Enclose the patch I tested OK on my buster-backports system.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
From: Roger Shimizu 
Date: Sun, 25 Apr 2021 22:51:12 +0900
Subject: Update apparmor profile

Closes: #980155
---
 apparmor/torbrowser.Browser.firefox | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/apparmor/torbrowser.Browser.firefox b/apparmor/torbrowser.Browser.firefox
index 57c0359..095b110 100644
--- a/apparmor/torbrowser.Browser.firefox
+++ b/apparmor/torbrowser.Browser.firefox
@@ -90,6 +90,7 @@ profile torbrowser_firefox @{torbrowser_firefox_executable} {
   /usr/share/gnome/applications/ r,
   /usr/share/gnome/applications/kde4/ r,
   /usr/share/poppler/cMap/ r,
+  /etc/xdg/mimeapps.list r,
 
   # Distribution homepage
   /usr/share/homepage/ r,
@@ -121,6 +122,7 @@ profile torbrowser_firefox @{torbrowser_firefox_executable} {
   deny @{HOME}/.cache/fontconfig/** rw,
   deny @{HOME}/.config/gtk-2.0/ rw,
   deny @{HOME}/.config/gtk-2.0/** rw,
+  deny @{PROC}/@{pid}/cgroup r,
   deny @{PROC}/@{pid}/net/route r,
   deny /sys/devices/system/cpu/cpufreq/policy[0-9]*/cpuinfo_max_freq r,
   deny /sys/devices/system/cpu/*/cache/index[0-9]*/size r,


Bug#986995: linux-image-5.10.0-6-amd64: cdc_acm acm_port_activate fails

2021-04-25 Thread Yuri D'Elia
Source: linux
Version: 5.10.28-1
Followup-For: Bug #986995

I can confirm any device controlled by the acm driver has issues
starting with 5.10.28. Sometimes it's possible to just replug the serial
device to fix the issue, however for devices that reconnect after reset,
there's no work-around.

These include most MCU boards, such as arduino.
Downgrading to 5.10.0-6 (5.10.26-1) fixes the issue.

Relevant upstream bug reports:

https://bugzilla.kernel.org/show_bug.cgi?id=212751
https://bugzilla.kernel.org/show_bug.cgi?id=212725



Bug#987332: aprx automatically starts up with really bad default config

2021-04-25 Thread Heikki Hannikainen

On Sun, 25 Apr 2021, Evgeni Golov wrote:


On Sun, Apr 25, 2021 at 03:41:38PM +0300, Heikki Hannikainen wrote:

This would be very important to make this happen. Shipping a config with the
"mycall N0CALL-1" line commented out would probably work.


If we change the default config, but let the service enabled, it will
fail to start (which is *technically* what you want, as it will prevent
wrongly configured installations from connecting to you). At the same
time, everyone who updates from Buster to Bullseye (and has the bad old
config) will face a failed upgrade and has to search why it failed, what
they have to fix and then restart the upgrade.


Right, a failed upgrade would not be good.


We're not breaking a working service with this approach, but it also
feels weird towards the user (even if we can question why they have aprx
installed, when it's not properly configured -- or is there any use
without the daemon running correctly?).


There is no use of the daemon when it is running with its default config. 
It doesn't do anything useful, it just connects to the server and sits 
there. To make it useful, the config needs to be updated with a correct 
callsign, some configuration to attach it to a radio interface, and 
possibly beaconing config.



I think it should be possible to detect the "N0CALL" configurations on
upgrade and disable the service, thus reaching the same state as with my
above change for new installs.


Right, something like a grep for the bad "^mycall\s+N0CALL-1" would be a 
suitable trigger.


  - Hessu



Bug#987556: unblock: stopmotion/0.8.5-3

2021-04-25 Thread Barak A. Pearlmutter
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package stopmotion

[ Reason ]

Change '%s' to %s in stopmotion.mime

[ Impact ]

Minor security issue.

[ Tests ]

n/a

[ Risks ]

Leaf package. Changing '%s' to %s is the only substantive change.

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

unblock stopmotion/0.8.5-3



$ git diff debian/0.8.5-2..debian/0.8.5-3
diff --git a/debian/changelog b/debian/changelog
index af0fe4a..ecfbbd6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+stopmotion (0.8.5-3) unstable; urgency=medium
+
+  * bump policy, no changes required
+  * bump to debhelper 13
+  * Fix day-of-week for changelog entry 0.pre3.4-1
+  * Add pithy comment to debian/watch
+  * stop quoting %s in mimecap entry (closes: #987415)
+
+ -- Barak A. Pearlmutter   Fri, 23 Apr 2021 20:56:40 +0100
+
 stopmotion (0.8.5-2) unstable; urgency=medium
 
   * hack around integer size mismatch to std::min() on 32-bit systems
@@ -466,7 +476,7 @@ stopmotion (0.pre3.4-1) unstable; urgency=low
 
   * Fixed a bug when removing scenes
 
- -- Bjoern Erik Nilsen   Tue, 25 Apr 2005 17:12:36 +0200
+ -- Bjoern Erik Nilsen   Mon, 25 Apr 2005 17:12:36 +0200
 
 stopmotion (0.pre3.3-1) unstable; urgency=low
 
diff --git a/debian/stopmotion.mime b/debian/stopmotion.mime
index 483de5a..dcba5d0 100644
--- a/debian/stopmotion.mime
+++ b/debian/stopmotion.mime
@@ -1 +1 @@
-application/x-stopmotion;  /usr/bin/stopmotion  -caption "Animation Creator" 
'%s';   nametemplate='%s.sto'; test=test "$DISPLAY" != ""; priority=9
+application/x-stopmotion;  /usr/bin/stopmotion  -caption "Animation Creator" 
%s;   nametemplate=%s.sto; test=test "$DISPLAY" != ""; priority=9
diff --git a/debian/control b/debian/control
index 3cc21c7..2c4a90c 100644
--- a/debian/control
+++ b/debian/control
@@ -4,14 +4,14 @@ Priority: optional
 Maintainer: Barak A. Pearlmutter 
 Uploaders: Mahyuddin Susanto ,
   Bjoern Erik Nilsen 
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper-compat (= 13),
pkg-config,
qtbase5-dev, qttools5-dev-tools,
qtmultimedia5-dev,
libtar-dev,
libvorbis-dev,
libxml2-dev
-Standards-Version: 4.4.1
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Homepage: http://linuxstopmotion.sourceforge.net
 Vcs-Git: https://salsa.debian.org/debian/stopmotion.git
diff --git a/debian/watch b/debian/watch
index 1b239b9..0b05a3b 100644
--- a/debian/watch
+++ b/debian/watch
@@ -2,3 +2,7 @@ version=4
 opts="mode=git, pgpmode=none" \
  https://git.code.sf.net/p/linuxstopmotion/code \
  refs/tags/v?([\d\.]+) debian uupdate
+
+## Would use
+##   refs/tags/v?@ANY_VERSION@
+## but that matches things like 0.8.6-RC1.



Bug#987527: clonezilla: Fails to install on bullseye

2021-04-25 Thread Georges Khaznadar
Dear Chris, thank you for the bug report.

I believe that the bug is fixed with the newly uploaded release
3.35.2-3.

What should I do next to allow clonezilla to be included in bullseye ?
Is the upload enough or must I make some other acknowledgement, or send some
e-mail ?

Best regards,   Georges.


Chris Hofstaedtler a écrit :
> Control: severity -1 serious
> 
> * Matthias Gies  [210425 13:11]:
> > clonezilla (3.35.2-2) wird eingerichtet ...
> > ln: die symbolische Verknüpfung '/opt/' konnte nicht angelegt werden: Datei 
> > oder Verzeichnis nicht gefunden
> > dpkg: Fehler beim Bearbeiten des Paketes clonezilla (--configure):
> >  »installiertes clonezilla-Skript des Paketes 
> > post-installation«-Unterprozess gab den Fehlerwert 1 zurück
> 
> I believe packages are not allowed to install stuff into /opt. 
> If they are, this should be a normal file install, and not a
> postinst hack.
> 
> Chris

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature


Bug#987556: unblock: stopmotion/0.8.5-3

2021-04-25 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Barak,

On 25-04-2021 16:46, Barak A. Pearlmutter wrote:
> +  * bump to debhelper 13

This will need to be reverted. See our FAQ [1] section: "I bumped the
debhelper compat level, why is it rejected?" Alternatively, if nothing
else changes in the binary packages, you can provide a diffoscope diff
between a no-change rebuild of 0.8.5-2 and 0.8.5-3, showing that nothing
changed except for the mentioned lines. Note, we'll not engage in 'but
can't this be accepted anyways' discussions.

Paul

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

2021-04-25 Thread Chris Hofstaedtler
* Holger Wansing  [210425 16:53]:
> Chris Hofstaedtler  wrote (Sun, 25 Apr 2021 14:13:05 +0200):
> > While the -exact- same bug does not appear on the
> > 20210424-7/amd64/iso-cd/debian-testing-amd64-netinst.iso image, I
> > think the bug is still there, just better hidden.
> > I managed to make debconf hang by:
> >   - select Marathi
> >   - on the next screen, click the Back button
> >   - in the now appearing list, select something else (I think two
> > above from what was selected)
> >   - click the Continue button
> >   - hangs
> 
> Yes, that way it is still reproducible with recent dailies or self-built
> images.

It might be helpful to try older images, and see if they also show
the hang if triggered like this. Then finding the first one that
doesnt ... maybe that yields a super[cg]lue.

Chris



Bug#987490: falkon FTBFS: dh_install: error: missing files, aborting

2021-04-25 Thread Reiner Herrmann
Hi Georges,

On Sun, Apr 25, 2021 at 05:48:47PM +0200, Georges Khaznadar wrote:
> I believe that the bug is fixed with the newly uploaded release.
> 
> Should I do something else to get falkon included in bullseye, or is it
> enough to wait a few days?

thanks for fixing it.
You need to file an unblock request (reportbug release.debian.org)
and attach a diff between the version in testing and unstable.
If you prefer, I can also take care of that.

Kind regards,
  Reiner


signature.asc
Description: PGP signature


  1   2   >