Bug#1005367: ITP: r-cran-lobstr -- visualize R data structures with trees

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-lobstr -- visualize R data structures with trees
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-lobstr
  Version : 1.1.1
  Upstream Author : Hadley Wickham,
* URL : https://cran.r-project.org/package=lobstr
* License : GPL-3
  Programming Lang: GNU R
  Description : visualize R data structures with trees
 A set of tools for inspecting and understanding R data
 structures inspired by str(). Includes ast() for visualizing abstract
 syntax trees, ref() for showing shared references, cst() for showing
 call stack trees, and obj_size() for computing object sizes.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-lobstr

Bug#1005356: ITP: rockhopper -- system for analyzing bacterial RNA-seq data

[Andreas Tille]

Am Sat, Feb 12, 2022 at 07:47:03AM +0100 schrieb Pierre Gruet:
> Eventually, all the .class files in the archive were just igv and its
> dependencies, so that I could remove all of them and have igv as the sole
> dependency of the binary package :-)

This would simplify things ... thanks to the effort you have put into igv.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1005366: ITP: ukui-bluetooth -- Bluetooth manager for UKUI desktop environment

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 
X-Debbugs-Cc: debian-de...@lists.debian.org, jianfen...@ubuntukylin.com

* Package name: ukui-bluetooth
  Version : 1.0.2
  Upstream Author : Tang guang 
* URL : https://github.com/ukui/ukui-bluetooth
* License : GPL-2+
  Programming Lang: C++,
  Description : Bluetooth manager for UKUI desktop environment

 A lightweight bluetooth management utility based on libkf5bluezqt
 for UKUI desktop environment.

This package will maintained by Kylin team.

Bug#1005356: ITP: rockhopper -- system for analyzing bacterial RNA-seq data

[Pierre Gruet]

Hi,

Le 12/02/2022 à 06:42, Andreas Tille a écrit :

Very cool!


You're welcome!

Eventually, all the .class files in the archive were just igv and its 
dependencies, so that I could remove all of them and have igv as the 
sole dependency of the binary package :-)


Best regards,

--
Pierre

Bug#1005356: ITP: rockhopper -- system for analyzing bacterial RNA-seq data

[Andreas Tille]

Very cool!

Am Fri, Feb 11, 2022 at 10:08:25PM +0100 schrieb Pierre Gruet:
> Package: wnpp
> Severity: wishlist
> Owner: Debian-med team 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org
> 
> * Package name: rockhopper
>   Version : 2.0.3
>   Upstream Author : Brian Tjaden
> * URL : https://cs.wellesley.edu/~btjaden/Rockhopper
> * License : GPL-3+
>   Programming Lang: Java
>   Description : system for analyzing bacterial RNA-seq data
> 
> Rockhopper is a comprehensive and user-friendly system for
> computational analysis of bacterial RNA-seq data. As input, Rockhopper
> takes RNA sequencing reads output by high-throughput sequencing
> technology (FASTQ, QSEQ, FASTA, SAM, or BAM files). Rockhopper supports
> the following tasks:
> * Reference based transcript assembly (when one or more reference
>   genomes are available)
>   - Aligning reads to genomes
>   - Assembling transcripts
>   - Identifying transcript boundaries and novel transcripts such as
> small RNAs
> * De novo transcript assembly (when reference genomes are unavailable)
> * Normalizing data from different experiments
> * Quantifying transcript abundance
> * Testing for differential gene expression
> * Characterizing operon structures
> * Visualizing results in a genome browser
> 
> The package will be team-maintained by Debian-med team.
> 
> 

-- 
http://fam-tille.de

Bug#1005364: python3-xlsxwriter: emits syntax warnings on every use

[Hamish Moffatt]

Package: python3-xlsxwriter
Version: 1.1.2-0.2
Severity: normal

xlsxwriter in bullseye reports SyntaxErrors on every use.

/usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:358: SyntaxWarning: "is" 
with a literal. Did you mean "=="?
  if token is '':


I think the bullseye version needs to be patched to fix this.

Hamish

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

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

Versions of packages python3-xlsxwriter depends on:
ii  python3  3.9.2-3

python3-xlsxwriter recommends no packages.

python3-xlsxwriter suggests no packages.

-- no debconf information

Bug#983645: plans for capnproto

[Tom Lee]

Hey meskio,

0.9.1 is being actively worked on, biggest blocker at this point is around
making sure we have all our copyright attributions correct I think. A few
important architectures were also FTBFS with the last upload but believe we
have a fix for that.

I think we should expect 0.9.1 in sid "soon" but it's hard to give an exact
timeline at this point. Bear with me if you can but go ahead and upload to
experimental for now if you're blocked.

Cheers,
Tom


On Fri, Feb 11, 2022 at 2:00 AM meskio  wrote:

> Hello Tom,
>
> I'm the maintainer of the laminar[0] debian package, which uses capnproto.
> There
> are several fixes that we care about included in capnproto >= 0.9.0. I see
> 0.9.1
> is already in experimental. What are your plans for it? Might it graduate
> to sid
> soon? Or will it take some time in experimental?
>
> I'm thinking if is worth it for me to upload the new version of laminar
> into
> experimental or wait for capnproto to get into sid.
>
> Thanks.
>
> [0] https://laminar.ohwg.net/
>
>
> Quoting Jan-Benedict Glaw (2022-02-10 11:09:57)
> >   * Under some circumstances, laminard didn't accept any further web
> > requests when a client shut down the connection kind of at the
> > wrong point. That was an issue with capnproto
> > (https://github.com/capnproto/capnproto/pull/1407), which has no
> > new release yet after that was merged. I hope Tom Lee will package
> > capnproto quickly with the next release. Right now, Debian's 0.7
> > version is quite dated...
>
> --
> meskio | https://meskio.net/
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  My contact info: https://meskio.net/crypto.txt
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Nos vamos a Croatan.



-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#1005362: RM: webauth -- ROM; RC buggy, obsolete, security

[Russ Allbery]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: r...@debian.org

I'm the former maintainer of the webauth package, which provides an
Apache-based web single sign-on system.  I maintained the software as
upstream when I worked for Stanford University.

Stanford chose to replace the software after I left with Shibboleth
and has done no further work on it.  At this point, it's unlikely that
anyone will pick up maintenance.  Since this is a security package
with some known protocol flaws (including lack of hash agility and use
of SHA-1), I don't feel comfortable continuing to include it in Debian.
I don't think anyone is in a good position to provide security support
for it.

It currently has a fixable RC bug due to running perlcritic during
the build, so is not present in testing.

Bug#975016: #975016 - OpenJDK 17 support state for Bullseye

[Matthias Klose]

On 2/10/22 11:26, Moritz Mühlenhoff wrote:
> Am Thu, Feb 03, 2022 at 03:59:00PM +0100 schrieb Thorsten Glaser:
>> Hi Holger,
>>
>>> and filed against src:debian-security-support, as openjdk-17 seems to be
>>> supported and src:debian-security-support's purpose is to documented what's
>>
>> no, 11 is supported, 17 is just for users to run third-party
>> stuff on (IIUC).
> 
> In Bullseye 11 is the default Java and fully covered by security support.
> 
> 17 can be installed (and it can also take over the typical alternatives),
> but nothing pulls it in via dependencies. But if anyone needs to run an
> application requiring 17, this is the JRE of choice (those are rare at
> this point, but it will change over the life time of Bullseye).
> 
> And yes there have been security updates for 17 already, but it's a best 
> effort
> thing. If someone commits to rebuild the openjdk-17 uploads to unstable
> for bullseye-security (along with proper testing), we can also omit a note
> for src:debian-security-support.

"along with proper testing" means, that we can turn on again the tests during
the build, which requires a heap of new upstream versions for jtreg, jtharness,
testng, groovy, and probably much more.

Matthias

Bug#1005311: xserver-xorg-video-nvidia: Package has unmet dependencies

[Andreas Beckmann]

On 11/02/2022 17.05, Andreas Beckmann wrote:
Does the nvidia driver support the new xorg-video-abi-25 in the new Xorg 
version? There was nothing in upstream's changelog, yet.


There is now an untested branch in git with the dependency fix: 
470+xserver21


I've found that:

https://forums.developer.nvidia.com/t/xorg-server-21-1-released-any-eta-on-compatible-nvidia-drivers/193422

philmmanjaro wrote on Nov 11

  So far 470xx and 495xx series work. [...]

philmmanjaro wrote on Nov 16

  [...] Only 470xx and 495xx series adopted to ABI_VIDEODRV_VERSION 
25.2 so far. [...]


ionen wrote on Dec 20

  To update, 390.147 released a few days ago supports xorg-21.1 [...]


My guesses for an Xorg Xserver 21 compatibility table:

  510.47.03  (2022-02-01) assume still supported ;-)
  495.46 (2021-12-13) supported according to philmmanjaro
  470.103.01 (2022-01-31) supported according to philmmanjaro
! 460.106.00 (2021-10-26) EoL, assume not supported
  450.172.01 (2022-01-31) probably supported
! 418.226.00 (2021-10-26) assume not supported
  390.147(2021-12-16) supported according to ionen
! 340.108(2019-12-23) EoL, not supportable

Andreas

Bug#1005361: ITP: python-rcon -- RCON protocol client implementation

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-rcon
  Version : 1.3.8
  Upstream Author : Richard Neumann 
* URL : https://github.com/conqp/rcon
* License : GPL-3+
  Programming Lang: Python
  Description : RCON protocol client implementation

 Python 3 library, which provides a client to interact with RCON servers. The
 RCON protocol is used to remotely control a game server, i.e.  execute commands
 on a game server and receive the respective results.

I intend to maintain this package as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmIG56ARHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wq7iAf+J605AIxJqQ1mi7DpPi+PlYPMRCdcUeAK
vTG+IrFs+N3LFvrloTHT5eYj0k3ujzkKdejUaeB3Dkg54kv1LL4fq5H8hz4DIIc8
tdRZnH/v9KBnGXwkqFjNItHbfz2O+Z+iAF5Ail8QcvvwHBB5aRswFPfoCBNxgPYF
9zliFkAVlV1xhLx3YoLC9Os4PrDMBZWazPzcdfZ1eYvAWpsFIdz7iVQpg0Qqmfw/
ySC8ie7ugs+a5NfEdi/elOXsAb75hLYD+VW9ZIb7F00uuWZb6iki3HRELjqPYkCL
proYg7e73kQUb2gB4Xa8+mrnDybGbcn4sy6IZPk6N392TLGYYCcrCA==
=JMBN
-END PGP SIGNATURE-

Bug#1005360: RFS: xca/2.4.0-2 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : xca
Version : 2.4.0-2
Upstream Author : Christian Hohnstaedt
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

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


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

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

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.4.0-2.dsc

Changes since the last upload:

xca (2.4.0-2) unstable; urgency=medium
.
* New patches added:
- d/patches/xca-240-ossl3.patch: Upstream OpenSSL 3.0 compatibility
patches to allow builds and compat with OpenSSL 3.0.

While I forgot to put this in the changelog, this fixes the FTBFS that 
is addressed in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001498 - these 
changes are also reverse compat with OpenSSL older versions that are 
present in Unstable and there are no FTBFS errors present there during 
this build.  It also appears to run and work fine from the tests I've 
done locally in an Unstable VM.



Regards,


Thomas Ward

Bug#1005359: xserver-xorg-core: Intel HD Graphics 610: blank screen

[Jakub Wilk]

Package: xserver-xorg-core
Version: 2:21.1.3-2

After recent upgrades, the X server no longer works for me: I get only 
blank screen. Worse, the blankness remains even after I zap the server.

Downgrading xserver-xorg-core to 2:1.20.14-1 fixed it for me.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 2020-09-08 17:48 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 2022-02-09 11:19 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 610 
[8086:5902] (rev 04)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 226 2018-07-19 11:01 90-xpra-virtual.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37.90.20220130) #1 SMP 
PREEMPT Debian 5.16.7-2 (2022-02-09)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 25227 2022-02-11 22:50 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[70.035]
X.Org X Server 1.21.1.3
X Protocol Version 11, Revision 0
[70.036] Current Operating System: Linux borsuk 5.16.0-1-amd64 #1 SMP 
PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64
[70.036] Kernel command line: BOOT_IMAGE=/vmlinuz-5.16.0-1-amd64 
root=/dev/mapper/root ro rootdelay=1
[70.036] xorg-server 2:21.1.3-2 (https://www.debian.org/support)
[70.036] Current version of pixman: 0.40.0
[70.036]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[70.036] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[70.036] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 11 22:49:24 
2022
[70.044] (==) Using config directory: "/etc/X11/xorg.conf.d"
[70.044] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[70.047] (==) No Layout section.  Using the first Screen section.
[70.047] (==) No screen section available. Using defaults.
[70.047] (**) |-->Screen "Default Screen Section" (0)
[70.047] (**) |   |-->Monitor ""
[70.048] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[70.048] (==) Automatically adding devices
[70.048] (==) Automatically enabling devices
[70.048] (==) Automatically adding GPU devices
[70.048] (==) Automatically binding GPU devices
[70.048] (==) Max clients allowed: 256, resource mask: 0x1f
[70.054] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[70.054]Entry deleted from font path.
[70.054] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[70.054]Entry deleted from font path.
[70.054] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[70.054]Entry deleted from font path.
[70.056] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[70.056]Entry deleted from font path.
[70.056] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[70.056]Entry deleted from font path.
[70.056] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
built-ins
[70.056] (==) ModulePath set to "/usr/lib/xorg/modules"
[70.056] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[70.056] (II) Loader magic: 0x568877c0
[70.056] (II) Module ABI versions:
[70.056]X.Org ANSI C Emulation: 0.4
[70.056]X.Org Video Driver: 25.2
[70.056]X.Org XInput driver : 24.4
[70.056]X.Org Server Extension : 10.0
[70.057] (EE) dbus-core: error connecting to system bus: 
org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket 
/run/dbus/system_bus_socket: No such file or directory)
[70.057] (++) using VT number 10

[70.057] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[70.058] (II) xfree86: Adding drm device (/dev/dri/card0)
[70.058] (II) Platform probe for 
/sys/devices/pci:00/:00:02.0/drm/card0
[70.069] (--) PCI:*(0@0:2:0) 8086:5902:1565:3114 rev 4, Mem @ 
0xde00/16777216, 0xc000/268435456, I/O @ 0xf000/64, BIOS @ 
0x/131072
[70.069] (II) LoadModule: "glx"
[70.070] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[

Bug#1005358: No beep after a reboot

[Bjarni Ingi Gislason]

Package: alsa-utils
Version: 1.2.6-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

  A beep could not be produed

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

  Creating a beep with:

  sound=$(printf '\007')
  printf "$sound" > /dev/tty

   * What was the outcome of this action?

  No sound.

   * What outcome did you expect instead?

  The usual, a beep.

###

  First noticed after an "fsck ..." forced a reboot in "checkroot.sh"

  Also occures after a "shutdown -r now".

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

Kernel: Linux 5.15.15-2 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages alsa-utils depends on:
ii  kmod  29-1
ii  libasound21.2.6.1-1
ii  libatopology2 1.2.6.1-1
ii  libc6 2.33-5
ii  libfftw3-single3  3.3.8-2
ii  libncursesw6  6.3-2
ii  libsamplerate00.2.2-1
ii  libtinfo6 6.3-2
ii  lsb-base  11.1.0

alsa-utils recommends no packages.

Versions of packages alsa-utils suggests:
pn  dialog  

-- Configuration Files:
/etc/init.d/alsa-utils changed [not included]
(added option --no-ucm;  has no effect on bug)

-- no debconf information

-- 
Bjarni I. Gislason

Bug#1005357: developers-reference: fix formatting issues in French translation

[Philippe SWARTVAGHER]

Package: developers-reference
Version: 12.2
Severity: minor
Tags: patch upstream

Dear Maintainer,

(first bug report and patch to Debian here ! :) )

I attach a patch fixing some minor formatting issues in the French
translation of the documentation.

Philippe.From 0cea9fba86c07091a6993dbc54a17f7a53deeb4e Mon Sep 17 00:00:00 2001
From: Philippe SWARTVAGHER 
Date: Fri, 11 Feb 2022 22:28:40 +0100
Subject: [PATCH] fr/tools.po: fix formatting issues

Signed-off-by: Philippe SWARTVAGHER 
---
 source/locales/fr/LC_MESSAGES/tools.po | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/source/locales/fr/LC_MESSAGES/tools.po b/source/locales/fr/LC_MESSAGES/tools.po
index dd8501b..251245b 100644
--- a/source/locales/fr/LC_MESSAGES/tools.po
+++ b/source/locales/fr/LC_MESSAGES/tools.po
@@ -263,7 +263,7 @@ msgid ""
 "tree before and after. ``piuparts`` reports any files that have been "
 "added, removed, or modified during this process."
 msgstr ""
-"``piuparts`` s'assure que les ``paquets .deb`` gèrent correctement leur "
+"``piuparts`` s'assure que les paquets ``.deb`` gèrent correctement leur "
 "installation, leur mise à niveau et leur retrait. Il le fait en créant "
 "une installation minimale de Debian dans un ``chroot`` et en installant, "
 "mettant à niveau et retirant les paquets dans cet environnement, puis en "
@@ -1164,7 +1164,7 @@ msgstr "``maint-guide``"
 
 #: ../tools.rst:556
 msgid "The ``maint-guide`` package contains the Debian New Maintainers' Guide."
-msgstr "Le paquet ``maint-guide``fournit le guide du nouveau responsable Debian."
+msgstr "Le paquet ``maint-guide`` fournit le guide du nouveau responsable Debian."
 
 #: ../tools.rst:558
 msgid ""
@@ -1198,7 +1198,7 @@ msgid ""
 " Java library."
 msgstr ""
 "En plus du tutoriel principal, il fournit trois exercices pratiques sur "
-"la modification du paquet ``grep``, l'empaquetage du jeu ``gnujump``et "
+"la modification du paquet ``grep``, l'empaquetage du jeu ``gnujump`` et "
 "enfin sur l'empaquetage d'une bibliothèque Java."
 
 #: ../tools.rst:574
@@ -1214,7 +1214,7 @@ msgid ""
 "directly, and then lists all opportunities for contribution (not just the"
 " new ones)."
 msgstr ""
-"`how-can-i-help`` montre les possibilités de contribuer à Debian. Il est "
+"``how-can-i-help`` montre les possibilités de contribuer à Debian. Il est "
 "ancré à ``APT`` pour lister ces opportunités de contributions à Debian "
 "sur des paquets installés localement (paquets orphelins, bogues marqués «"
 " newcomer » — pour débutant) après chaque invocation d'``APT``. Le "
@@ -1273,7 +1273,7 @@ msgstr ""
 "``debiandoc-sgml`` fournit la définition de type de document (``Document "
 "Type Definition`` ou ``DTD``) SGML pour DebianDoc, souvent utilisé pour "
 "la documentation Debian, mais est maintenant déconseillé (``docbook-xml``"
-" ou ``python3-sphinx``devraient être utilisés à la place)."
+" ou ``python3-sphinx`` devraient être utilisés à la place)."
 
 #: ../tools.rst:606
 msgid "``debian-keyring``"

base-commit: 755c1eb73ebc1bcdcb0ae19246b118c3b3b3da02
-- 
2.34.1

Bug#1005197: pcmemtest: please make the build partly reproducible

[Thomas Schmitt]

Hi,

Chris Lamb wrote:
> Did you try the --invariant flag?

Well, i step aside and let this question reach Felix. :))

  https://manpages.debian.org/unstable/dosfstools/mkdosfs.8.en.html
says that this is what we need if my theory about the second difference
is correct:

  --invariant
Use constants for normally randomly generated or time based data
such as volume ID and creation time. Multiple runs of mkfs.fat on
the same device create identical results with this option.


So the options to be added to the mkdosfs runs in the hope for a fully
reproducible ISO are:

  -i 12345678 --invariant

If a more more individual -i number is desired, one could use something
like

  -i $(printf '%8.8x' "$SOURCE_DATE_EPOCH" | head -c 8)


Have a nice day :)

Thomas

Bug#1005307: Accepted libnbd 1.10.5-1 (source) into unstable

[Salvatore Bonaccorso]

Source: libnbd
Source-Version: 1.10.5-1

Hi Hilko

On Fri, Feb 11, 2022 at 09:04:42PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Fri, 11 Feb 2022 13:33:00 +0100
> Source: libnbd
> Architecture: source
> Version: 1.10.5-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Hilko Bengen 
> Changed-By: Hilko Bengen 
> Changes:
>  libnbd (1.10.5-1) unstable; urgency=medium
>  .
>* New upstream version 1.10.5

This should fix as well CVE-2022-0485 / #1005307.

Closing the bug now manually.

It would be great to have when known the CVE identifiers recorded in
debian/changelog as well.  This makes our live easier to track
vulnerabilities ;-)

Regards,
Salvatore

Bug#913491: libkf5config-dev: wrong cmake reference to kconfig_compiler_kf5 / cannot reproduce

[Aurélien COUDERC]

Dear Nick,

I cannot seem to reproduce this issue currently in testing.

Running :
apt source subtitlecomposer
sudo apt build-dep .
mkdir build && cd build
cmake ..
works correctly.

Do you still see the issue ?
May I close the bug ?

Thanks & happy hacking !
--
Aurélien

Bug#909436: libdrm: FTBFS on hurd-i386 (#909436, updated and new patches)

[Svante Signell]

On Tue, 2022-01-18 at 17:46 +0100, Svante Signell wrote:
> Hello again,
> 
> libdrm still FTBFS on GNU/Hurd, now at 2.4.109-2. Attached are two
> updated patches, hurd-port.diff and path_max.diff and two new ones.
> hurd_port.diff, path_max.diff, tests_amdgpu_ras_tests.c.diff and 
> tests_amdgpu_amdgpu_test.c.diff.
> 
> The above patches will be submitted to upstream in due time.  For
> completeness they are attached here, and as they were not included in
> the email announcing them, dated 06 Dec 2021.
> 
The patches are now submitted to
https://gitlab.freedesktop.org/mesa/drm/-/issues/24

Would this be enough to make upstream aware, or is something else
needed, like a merge request?

Thanks!

Bug#1005356: ITP: rockhopper -- system for analyzing bacterial RNA-seq data

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: rockhopper
  Version : 2.0.3
  Upstream Author : Brian Tjaden
* URL : https://cs.wellesley.edu/~btjaden/Rockhopper
* License : GPL-3+
  Programming Lang: Java
  Description : system for analyzing bacterial RNA-seq data

Rockhopper is a comprehensive and user-friendly system for
computational analysis of bacterial RNA-seq data. As input, Rockhopper
takes RNA sequencing reads output by high-throughput sequencing
technology (FASTQ, QSEQ, FASTA, SAM, or BAM files). Rockhopper supports
the following tasks:
* Reference based transcript assembly (when one or more reference
  genomes are available)
  - Aligning reads to genomes
  - Assembling transcripts
  - Identifying transcript boundaries and novel transcripts such as
small RNAs
* De novo transcript assembly (when reference genomes are unavailable)
* Normalizing data from different experiments
* Quantifying transcript abundance
* Testing for differential gene expression
* Characterizing operon structures
* Visualizing results in a genome browser

The package will be team-maintained by Debian-med team.

Bug#1005355: bullseye-pu: package ldap2zone/0.2-11+deb11u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-edu-pkg-t...@alioth-lists.debian.net, 
debian-...@lists.debian.org

[ Reason ]

In Debian Edu, the ldap2zone package is used and called via CRON hourly.
When using deprecated tempfile command a warning gets generated to stderr
that ends up in the CRON mail. Thus, an hourly mail on the internal MTA
(root@postoffice.intern) for a CRON job that acutally succeeds.

[ Impact ]
Noisy root mailbox on Debian Edu mainservers.

[ Tests ]
Manual tests on a deployed school network.

[ Risks ]
None, really.

[ 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 ]

+  * debian/patches:
++ Update 0004_revert-broken-zones.patch. Stop using deprecated $(tempfile)
+  command. (Closes: #1005354)

[ Other info ]
None.
diff -Nru ldap2zone-0.2/debian/changelog ldap2zone-0.2/debian/changelog
--- ldap2zone-0.2/debian/changelog  2018-08-14 21:43:26.0 +0200
+++ ldap2zone-0.2/debian/changelog  2022-02-11 21:49:57.0 +0100
@@ -1,3 +1,11 @@
+ldap2zone (0.2-11+deb11u1) bullseye; urgency=medium
+
+  * debian/patches:
++ Update 0004_revert-broken-zones.patch. Stop using deprecated $(tempfile)
+  command. (Closes: #1005354)
+
+ -- Mike Gabriel   Fri, 11 Feb 2022 21:49:57 +0100
+
 ldap2zone (0.2-11) unstable; urgency=medium
 
   * debian/patches:
diff -Nru ldap2zone-0.2/debian/patches/0004_revert-broken-zones.patch 
ldap2zone-0.2/debian/patches/0004_revert-broken-zones.patch
--- ldap2zone-0.2/debian/patches/0004_revert-broken-zones.patch 2016-04-18 
01:15:32.0 +0200
+++ ldap2zone-0.2/debian/patches/0004_revert-broken-zones.patch 2022-02-11 
21:48:41.0 +0100
@@ -16,7 +16,7 @@
 -  if $ldap2zone $domain $LDAP_URI $TTL > /tmp/$domain; then
 -  lines=$(cat /tmp/$domain | wc -l)
 -  [ $lines -gt 1 ] && mv /tmp/$domain 
$BIND_DATA/${PREFIX}${domain}
-+  TMPFILE=$(tempfile)
++  TMPFILE=$(mktemp)
 +  CURRENT=$BIND_DATA/${PREFIX}${domain}
 +  OLD=$BIND_DATA/${PREFIX}${domain}.old-$$
 +  if $ldap2zone $domain $LDAP_URI $TTL > $TMPFILE; then

Bug#1005353: buster-pu: package apache-log4j2/2.11.1-2

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org

Hi,

I would like to fix CVE-2021-44832 in Buster. Apache Log4j2 has been
affected by some serious remote code execution vulnerabilities in the
past months. The most severe ones have been already addressed in
buster-security with version 2.17.0-1~deb10u1. CVE-2021-44832 is less
severe thus the security team decided to mark this issue as no-dsa.

I have prepared a backport of the current Log4j2 version in testing
which again is a new upstream release instead of a targeted fix. I am
confident this one works as well as the other upgrades before and I
recommend to use it in oldstable from now on.

[ 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

Regards,

Markus


apache-log4j2_buster.debdiff.gz
Description: application/gzip

Bug#1005326: no-code-sections triggered on non-ELF files

[Felix Lechner]

Hi,

On Fri, Feb 11, 2022 at 12:09 PM Marc Dequènes  wrote:
>
> Could you consider improving the check?

Yes, I'd like to.

> readelf fails with "readelf: Error: Not an ELF file - it has the wrong
> magic bytes at the start"

I confirmed that Lintian's invocation produces that error for
usr/lib/dxvk/wine64-development/d3d10.dll.a in dxvk, but how can we
tell such archives apart from those that are legitimately broken?

Kind regards
Felix Lechner

Bug#1005351: bullseye-pu: package apache-log4j2/2.16.0-1~deb11u1

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org

Hi,

I would like to fix CVE-2021-44832 in Bullseye. Apache Log4j2 has been
affected by some serious remote code execution vulnerabilities in the
past months. The most severe ones have been already addressed in
buster-security with version 2.17.0-1~deb11u1. CVE-2021-44832 is less
severe thus the security team decided to mark this issue as no-dsa.

I have prepared a backport of the current Log4j2 version in testing
which again is a new upstream release instead of a targeted fix. I am
confident this one works as well as the other upgrades before and I
recommend to use it in stable from now on.

[ 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

Regards,

Markus


apache-log4j2_bullseye.debdiff.gz
Description: application/gzip

Bug#1005350: big icons despite compact mode

[VA]

Version: 2.6.6+dfsg.1-1
Package: keepassxc

In the app, icons are way too big, bigger than they were before, even 
when "compact mode" is enabled (actually this option doesn't seem to 
work at all).
See attached screenshot of how it looks now. Previously, the icon size 
used to be more like this: 
https://keepassxc.org/images/screenshots/database_view.png

Bug#1005197: pcmemtest: please make the build partly reproducible

[Chris Lamb]

[merging two replies]

Hi Thomas,

> I wonder whether the "file list" in "data.tar.xz" of
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
> is made from the files in the ISO or from the input files on hard disk.

That can safely be ignored for our purposes. That "file list" is
merely repeating that the two .debs have different contents... but
they have different contents because the two ISO files within them are
different; something we already know.

> First an observation from digging in pcmemtest/1.5-2/build64/Makefile:
> What about target grub-memtest.iso ?
> It has its own xorriso run and EFI System Partition image.
> I guess they need treatment for reproducibility, too.

Ah, that does sound plausible, although I am now really quite out of
my depth in terms of ISO/EFI/xorriso knowledge.

> The other difference could be a neighbor of "directory volume label",
> which Wikipedia mentions as a kind of mirror of "Partition Volume Label".
> If i get it right then this is in the name and extension fields of
> a "Directory entry".
> The differing bytes would then be the timestamps "Create time" at offset
> 0x0E and "Last Modified time" at offset 0x16. Probably the date fields at
> 0x10 and 0x18 could show differences, too.
>
> But i am far off my usual playground now.

Same. ;)

> Maybe Chris already knows a good trick to enforce values for those time
> and date fields in FAT filesystems.

Hm. Well, I remember doing some work on dosfstools and/or mtools in
order that they could generate deterministic output, but it has been
quite a few years now. Did you try the --invariant flag? (There were
also some patches flying around to fix mtools serialising/saving
uninitialised memory as well, but I think most of them got applied, at
least in Debian.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#652580: a working package ready for review and testing

[David A. Redick]

The source has been moved from gitorious to github.

https://github.com/david-a-redick/beret

https://github.com/david-a-redick/beret-data

Doing `make debian-build` in each will produce all the various
artifacts in the parent directory (via debuild).

This is my first attempt at packaging for Debian so I might have missed
something.

Please let me know what my next steps are?

Bug#1004767: telegram-desktop: FTBFS with ffmpeg 5.0

[Nicholas Guriev]

Hello!

I have prepared the telegram-desktop package for the FFmpeg transition
by means of FFmepeg-v5.0.patch (sorry for a typo, I will rename the
patch in a next upload).

For success, it is also necessary to rebuild the libtgowt package, I
mentioned in the previous email [1]. Or we end up with linker errors.
The package contains static library and build depends on -dev packages
of FFmpeg. But for uncertain reason, it is not in the auto-ffmpeg
transition plan. Is metadata missing somewhere?

 [1]: https://bugs.debian.org/1005255#15



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

Bug#1005255: telegram-desktop: error: ‘Config’ is not a member of ‘webrtc’

[Nicholas Guriev]

Hello!

The error in the tgcalls module happened due to an incompatibility with
the libtgowt package. I was updating Telegram Desktop, and it is tied a
much to the library, dedicated WebRTC fork.

I uploaded a new upstream version yesterday and the error was gone.
Sorry for the inconvenience.



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

Bug#1005136: Outdated URL in README.keyfile-update

[Micha Lenk]

Control: tags -1 pending

Am 07.02.22 um 18:57 schrieb Christoph Biedl:

the document /usr/share/doc/aqbanking-tools/README.keyfile-update conteins a
link to the AqBanking manual. That address is no longer valid and I could not
find a new place that provides that informmation. Possibly is just not
really needed any longer - do I read correctly it refers to version 3.0
which was uploaded some 14 years ago?


I looked into it, and I couldn't find a new place that provides that 
information either. I intend to just remove that paragraph in my next 
upload (the rest of the README.keyfile-update apparently still applies).


Kind regards,
Micha

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

> > [in scripts/mk/Makefile.am], I suggest to rename
> > scripts/mk/{default,buildtools}.mk to scripts/mk/*.mk.sed or similar
> > (for example, .sed.mk in order to keep syntax highlighting).  Distinct
> > source and object files would also simplify scripts/mk/Makefile a lot.

> Yeah, that would be more convenient, the problem is that these files
> need to have specific pathnames during tests, which are different from
> the ones at run-time. Those could be set from the environment, but that
> would miss the case where the variable is completely missing from the
> file. :)

Would this be OK?

dpkg_datadir := $(shell $(dir $(lastword $(MAKEFILE_LIST

If I remember well, only GNU Make supports this, but else something
like
dpkg_datadir != dirname `echo $(MAKEFILE_LIST) | sed 's/.* //'`
could probably be improved to compute the result only once.

> The main issue I see is that this trades performance depending on the
> mode of operation. Some of these variables are (currently) not
> expected to be set by the driver calling debian/rules (in Debian we
> still have to support that being any thing :/), but then most of our
> tools do go through dpkg-buildpackage. So the various «.mk» cannot
> expect these variables to be previously set, but should assume that
> the common case is them being executed through dpkg-buildpackage, and
> that one setting some of those, which means unconditionally setting
> some of them will make the package builds somewhat slower. The other
> variables should then not be set if not used, as that would slow down
> packages that do not need them.

As far as I have tested, my suggestion behaves exactly like the
current one. The only difference is that when several variables are
unset, the related dpkg-{architecture,buildflags,..} tool is called
only once.

> Ideally, most of this would not be needed at all, because we could
> rely on dpkg-buildpackage having exported all of these, which it
> already needs to compute in most cases anyway, but this is something
> we cannot have in Debian for now. I'm pondering adding a mode, not to
> be used by Debian, which could be used by local packages or other
> distros though.

A variable like DEB_BUILD_FLAGS_ALREADY_SET could shortcut all tests,
but I wonder if the speed gain would be worth the added complexity,
assuming that each dpkg-{architecture,buildflags,...} is called at
most once and only if at least a variable is both unset and actually
read.

> I'll go over these in the coming days.

I will do my best to rebase before that :-)

Bug#1005349: joystick: jscal needs an option to not continue with any button

[Mikko Tuumanen]

Package: joystick
Version: 1:1.7.1-1
Severity: normal

Dear Maintainer,

jscal asks user to move axis to a position and push any button.
This causes a problem when a trigger of a gamepad is both axis and a
button. In this case when user pulls the trigger, a button event is sent
and jscal continues before user has had a change to move the trigger to
the requested position. The problem appears with ZEROPLUS P4 Wired Gamepad.

I wrote a patch to add -b option to jscal to choose one button to use as
the continue button.

-- Package-specific info:

  looking at device 
'/devices/pci:00/:00:01.2/:20:00.0/:21:08.0/:2a:00.3/usb3/3-6/3-6.2/3-6.2:1.3/0003:0C12:0E16.000A/input/input38/js0':
KERNEL=="js0"
SUBSYSTEM=="input"
DRIVER==""
ATTR{power/async}=="disabled"
ATTR{power/control}=="auto"
ATTR{power/runtime_active_kids}=="0"
ATTR{power/runtime_active_time}=="0"
ATTR{power/runtime_enabled}=="disabled"
ATTR{power/runtime_status}=="unsupported"
ATTR{power/runtime_suspended_time}=="0"
ATTR{power/runtime_usage}=="0"

  looking at parent device 
'/devices/pci:00/:00:01.2/:20:00.0/:21:08.0/:2a:00.3/usb3/3-6/3-6.2/3-6.2:1.3/0003:0C12:0E16.000A/input/input38':
KERNELS=="input38"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{capabilities/abs}=="3003f"
ATTRS{capabilities/ev}=="1b"
ATTRS{capabilities/ff}=="0"
ATTRS{capabilities/key}=="3fff 0 0 0 0"
ATTRS{capabilities/led}=="0"
ATTRS{capabilities/msc}=="10"
ATTRS{capabilities/rel}=="0"
ATTRS{capabilities/snd}=="0"
ATTRS{capabilities/sw}=="0"
ATTRS{id/bustype}=="0003"
ATTRS{id/product}=="0e16"
ATTRS{id/vendor}=="0c12"
ATTRS{id/version}=="0111"
ATTRS{inhibited}=="0"
ATTRS{name}=="ZEROPLUS P4 Wired Gamepad"
ATTRS{phys}=="usb-:2a:00.3-6.2/input3"
ATTRS{power/async}=="disabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="0"
ATTRS{power/runtime_active_time}=="0"
ATTRS{power/runtime_enabled}=="disabled"
ATTRS{power/runtime_status}=="unsupported"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="0"
ATTRS{properties}=="0"
ATTRS{uniq}==""

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

Kernel: Linux 5.15.11 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.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 joystick depends on:
ii  libc6  2.31-13+deb11u2
ii  libsdl2-2.0-0  2.0.14+dfsg2-3

Versions of packages joystick recommends:
ii  evtest   1:1.34-1
ii  inputattach  1:1.7.1-1

joystick suggests no packages.

-- no debconf information
diff -ur a/utils/jscal.c b/utils/jscal.c
--- a/utils/jscal.c 2019-10-05 22:52:45.0 +0300
+++ b/utils/jscal.c 2022-02-11 20:26:46.574281686 +0200
@@ -76,6 +76,8 @@
 
 }
 
+static int button = -1;
+
 int get_time(void)
 {
struct timeval tv;
@@ -154,6 +156,7 @@
puts("Usage: jscal ");
putchar('\n');
puts("  -c --calibrate Calibrate the joystick");
+   puts("  -b --buttonButton to continue 
calibrating");
puts("  -h --help  Display this help");
puts("  -s   --set-correctionSets correction to specified 
values");
puts("  -t --test-center   Tests if joystick is 
corectly calibrated");
@@ -265,16 +268,29 @@
 
 
b = js.buttons;
+   const char * push_msg;
+   if(button == -1) {
+   push_msg = "Move axis %d to %s position and push any button.\n";
+   }else{
+   push_msg = "Move axis %d to %s position and push the button.\n";
+   }
 
for (axis = 0; axis < axes; axis++)
for (pos = 0; pos < NUM_POS; pos++) {
while(b ^ js.buttons) wait_for_event(fd, );
-   printf("Move axis %d to %s position and push any 
button.\n", axis, pos_name[pos]);
+   printf(push_msg, axis, pos_name[pos]);
 
-   while (!(b ^ js.buttons)) {
-   print_position(axis, js.axis[axis]);
-   wait_for_event(fd, );
-   }
+   if(button == -1) 
+   while (!(b ^ js.buttons)) {
+   print_position(axis, js.axis[axis]);
+   wait_for_event(fd, );
+   }
+   else
+while (!(js.buttons & button)) {
+print_position(axis, js.axis[axis]);
+  

Bug#549429: error: too small lower memory (0x99100 > 0x96000)

[Fabio Fantoni]

Hi, this should be solved in 5.31b+dfsg-1 if I remember good.

Can someone tell me if this issue still reproducible on latest version 
of memtest86+ please? (5.31b+dfsg-4)




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001995: libcrypto++: ftbfs on armhf

[Jeffrey Walton]

Hi Everyone,

The patch to work around the failed compile is located at
https://github.com/weidai11/cryptopp/issues/1094#issuecomment-1035656572
. The patch is against Crypto++ 8.6.

The patch was tested in a Debian Unstable QEMU/Chroot for armel and
armhf. It tested Ok.

The changes in the diff will be part of Crypto++ 8.7. We should be
releasing Crypto++ 8.7 within the next 15 days or so. I plan on early
March 2022.

Jeff

Bug#319837: memtest86+: does not work: wouldn't fit into memory

[Fabio Fantoni]

Hi, this should be solved in 5.31b+dfsg-1 if I remember good.

Can someone tell me if this issue still reproducible on latest version 
of memtest86+ please? (5.31b+dfsg-4)




OpenPGP_signature
Description: OpenPGP digital signature

Bug#254210: memtest86+: Memtest86+ incorrectly generates BadRAM-patch location information

[Fabio Fantoni]

This issue is very old, in latest 2 versions in git there is the part 
changed but different from the patch, I suppose was fixed long time ago.


Can you tell me if the issue is still present on latest version instead?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005348: RFS: filezilla/3.58.0-1 -- Full-featured graphical FTP/FTPS/SFTP client

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: filezilla
   Version : 3.58.0-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : BSD-like, permissive, CC0-1.0, MIT, GPL-2+
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla - Full-featured graphical FTP/FTPS/SFTP client
  filezilla-common - Architecture independent files for filezilla

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.58.0-1.dsc

Changes since the last upload:

 filezilla (3.58.0-1) unstable; urgency=medium
 .
   * New upstream version 3.58.0
   * Updated libfilezilla-dev versioned build-dep to 0.36.0 or greater
   * Remove unnecessary build-dep version constraints as suggested by Janitor

Note: Will be imported into salsa once clears mentors into unstable.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1005347: ITP: onevpl-intel-gpu -- Intel oneVPL GPU Runtime

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: onevpl-intel-gpu
  Version : 22.2.0
  Upstream Author : Intel
* URL : https://github.com/oneapi-src/oneVPL-intel-gpu
* License : MIT
  Programming Lang: C, C++
  Description : Intel oneVPL GPU Runtime

 Intel oneVPL GPU Runtime is a Runtime implementation of oneVPL
 API for Intel Gen GPUs. Runtime provides access to hardware-accelerated
 video decode, encode and filtering.

 Supported video encoders: HEVC, AVC, MPEG-2, JPEG, VP9  
 Supported video decoders: HEVC, AVC, VP8, VP9, MPEG-2, VC1, JPEG, AV1  
 Supported video pre-processing filters: Color Conversion, Deinterlace, Denoise,
 Resize, Rotate, Composition  

Bug#1005253: [Pkg-shadow-devel] Bug#1005253: shadow: Improved manual page useradd.8

[Markus Hiereth]

Hi Serge,

"Serge E. Hallyn"  schrieb am 11. Februar 2022 um 18:13
 
> Thanks.  The diff is especially helpful.  Although a few of these hunks
> appear to be just changes to the line breaks.

> > @@ -219,14 +221,17 @@
> > 
> > 
> >   
> > -   The number of days after a password expires until the account is
> > -   permanently disabled. A value of 0 disables the account as soon
> > -   as the password has expired, and a value of -1 disables the
> > -   feature.
> > +defines the number of days after the password exceeded its 
> > maximum
> > +age where the user is expected to replace this password. The 
> > value
> 
> How about 'number of days after the password exceeded its maximum
> age during which the user may login by immediately replacing this
> password. The value is stored in the shadow password file.'

I also thought that there is something better then "where the user..."


> >   
> > If not specified, useradd will use the
> > -   default inactivity period specified by the
> > +   default inactivity onset specified by the
> 
> "onset" is weird here.

I looked up in a dictionary: "onset is the first attack or beginning
(of something bad)" . There are similar usages: "onset of winter", a
"hard onset" in phonetics, in medicine they speak of the "onset" of a
disease.

What do you think of "begin of inactivity"?

You know I also suggested "grace period". But, expressing it this way,
the connection to inactivity gets lost.

I really dislike "inactivity period" as the user does not define the
duration of inactivity but the number of days he will be able to do
something against a shift of his account into the inactive state.



> > INACTIVE variable in
> > /etc/default/useradd, or -1 by default.
> >   
> > @@ -237,8 +242,9 @@
> >   -g, 
> > --gidGROUP
> > 
> > 
> > + 
> 
> This i assume is leftover marker to be dropped.

Sure.


> > @@ -398,10 +407,18 @@
> >   -o, --non-unique
> > 
> > 
> > - Allow the creation of a user account with a duplicate 
> > (non-unique) UID.
> > + 
> > +   allows the creation of an account with an already existing
> > +   UID.
> > + 
> >   
> > This option is only valid in combination with the
> > -   -u option.
> > +   -u option. As a user identity
> > +   serves as
> > +   key to map between users on one hand and permissions, file
> > +   ownerships and other aspects that determine the system's
> > +   behavior on the other hand, more than one login name
> > +   will access the account of the given UID.
> >   
> > 
> >
> > @@ -410,14 +427,25 @@
> >   -p, 
> > --passwordPASSWORD
> > 
> > 
> > + 
 
> Drop this?

yes

 
> > @@ -488,11 +516,11 @@
> > 
> > 
> >   
> > -   The name of the user's login shell. The default is to leave this
> > -   field blank, which causes the system to select the default login
> > -   shell specified by the SHELL variable in
> > -   /etc/default/useradd, or an empty string
> > -   by default.
> > +sets the path to the user's login shell. Without this option,
> > +the system will use the SHELL variable 
> > specified
> > +   in /etc/default/useradd, or, if that is as
> > +   well not set, the field for the login shell in /etc/passwd
> > +   remains empty.
> >   
> > 
> >
> > @@ -533,13 +561,16 @@
> >
> >
> > 
> > - -Z, 
> > --selinux-userSEUSER
> > + -Z, --selinux
> > + -userSEUSER
 
> Is the line break here accidental?

Yes. I did not care for line breaks. This is a case where it would be
better avoided or done in another way, without separation of --selinux-user.

> > 
> > 
> >   
> > -   The SELinux user for the user's login. The default is to leave this
> > -   field blank, which causes the system to select the default SELinux
> > -   user.
> > +   defines the SELinux user for the new account. Without this
> > +   option, a SELinux uses the default user. Note that the
> 
> s/a SELinux/SELinux/

Yes.



> > +   shadow system doesn't store the selinux-user, it uses
> > +   semanage
> > +   8 for that.
> >   
> > 
> >
> > @@ -561,7 +592,7 @@
> >   
> >   
> > 
> > - The path prefix for a new user's home directory. The
> > + The path prefix for new users' home directory. The
> 
> the 'a' is more natural in English.

No problen, use the singular



> > @@ -578,7 +609,8 @@
> > -e, 
> > --expiredateEXPIRE_DATE
> >   
> >   
> > -   The date on which the user account is disabled.
> > +   

All of these can be be erased

> > +   The date on which newly created user accounts are 
> > disabled.
> > 
> >   This option sets the EXPIRE variable in
> >   /etc/default/useradd.
> > @@ -590,9 +622,12 @@

Bug#1005346: /usr/bin/unattended-upgrade: does not use the 'TMP' environment variable

[Pascal Dupuis]

Package: unattended-upgrades
Version: 2.8
Severity: important
File: /usr/bin/unattended-upgrade
X-Debbugs-Cc: cdemi...@gmail.com

Dear Maintainer,

   * I ugraded my raspi 3B from raspian (armhf) to debian arm64. To
 reduce the amount of writes on the SD card, I use tmp.mount with

Options=mode=1777,strictatime,nosuid,nodev,noexec,size=128M,nr_inodes=400k
 that's right: in memory, very small size, no exec. With such
 settings, 'unattended-upgrades' fails as it tries to execute a
 script from /tmp
   * other programs are run as: env TMP=/var/tmp some_command
 in case they require to generate and execute some script. But
 this approach sometimes fails with unattended-upgrades

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-dbus   1.2.16-5
ii  python3-distro-info1.0
ii  ucf3.0043
ii  xz-utils   5.2.5-2

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-30
ii  cron [cron-daemon]  3.0pl1-137
ii  systemd-sysv247.3-6

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx  
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
pn  needrestart
ii  powermgmt-base 1.36
ii  python3-gi 3.38.0-2

-- debconf information:
  unattended-upgrades/enable_auto_updates: true

Bug#1005343: nmu: asterisk-flite_3.0-4

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu asterisk-flite_3.0-4 . ANY . unstable . -m "rebuild against 
asterisk-1:18.10.0~dfsg+~cs6.10.40431411-1"

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmIGoHwACgkQLHwxRsGg
ASFhMQ/9G8Ef5zhHcBYz898NFx3l9hw8g0cITEyoNZgo/f5Kqi5H1AEoEYV5i99Q
YZORP89rFcwhy8jVN4ggBB6IIVzmAiWf0mo0QTExd5vfAjPrk6/y1AXIf2IM7xSX
LU6rAhIGMh6ITVuBjlzmWwj3hKWa7vtuXupLdcf+jVUJ9SpJqpOnOuI46hG8+pHb
kQxXidURsrQbBHocTdTYAD279VI9XdTCg7dKQRS3iZa2rNoO/dJfXC3riCWvOyFv
NC1Gx8L1MHhBnn8cd9etmP4xKu202HhSRKpjUgRsZ3LOtDqHaYYtvd/qW0aPJTJv
M+LhQ0xTJzgXRgT15JUSHjczoqydd6v7u59IyTRx/kaRL385W6H1kMTezPIjU9fY
rwyiGu3LwHDlEfj0OV/kXHPQwRkw9Yp7ROkDWalyvdeomg6r3EmWd7eEw7C37K3Q
DOgYEJsHh9UULwTvA38MJM6j1Ddd+aNKJqAlxsv1dAHBxV3tZvmd1EVqBhAHlOpl
/HYBh6/B43ju6BKbF1i7jQiv5WTxhKMR1EKctrodzNHaYOaS6b7nYBhCEd5glizf
AiJPqWx888NEcumnKHNTBlwCzVqM/o8CAlffcSlc2vHVf8YIKY1KY2MUR+zBGzFX
rrUNoWguaQ0KshOw41nCwBaAllEXwWp1wZKpt98NyhWiQOtCu+8=
=9LuI
-END PGP SIGNATURE-

Bug#979886: jquery-throttle-debounce: node-uglify is deprecated in favor of uglifyjs

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2022-02-11 18:12:30)
> As a rule of thumb, node-* packages are for Node.js library 
> interfaces, and packages containing command-line tools implemented in 
> Node.js use package names with the node- prefix.


Correction: packages providing command-line tools use a package name 
_without_ the node- prefix.

That package naming style is specifically to allow reverse dependencies 
to declare dependency on either _library_ API or _command-line_ ABI.

This package depends only on command-line ABI which remained roughly 
same across v2 and v3 of UglifyJS, but now blocks removal of v2 branch 
because it needlessly declares a dependency on library API (which 
historically was the only thing offered, so not complaining here!).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1005328: RM: uglifyjs/2.8.29-8

[Jonas Smedegaard]

[ adding Yadd as cc ]

Quoting Sebastian Ramacher (2022-02-11 15:25:19)
> On 2022-02-11 14:48:00 +0100, Jonas Smedegaard wrote:
> > Quoting Sebastian Ramacher (2022-02-11 13:24:16)
> > > Control: tags -1 moreinfo
> > > 
> > > On 2022-02-11 12:08:52 +0100, Jonas Smedegaard wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: rm
> > > > X-Debbugs-Cc: Debian Javascript Maintainers 
> > > > 
> > > > 
> > > > uglifyjs v2 was last updated upstream in 2017, and has no real
> > > > maintainer in Debian since December 2020 - see bug#958117
> > > > 
> > > > The package should not be released with bookworm, but may still have
> > > > reverse (build-)dependencies, and I therefore request removal only from
> > > > testing for now.  Please advice if another approach is more sensible.
> > > 
> > > So this is the same request as #968137. The current situation is:
> > > 
> > > I: [2022-02-11T12:19:15+] - trying: -uglifyjs
> > > I: [2022-02-11T12:19:15+] - skipped: -uglifyjs (0, 33, 62)
> > > I: [2022-02-11T12:19:15+] - got: 123+0: 
> > > a-3:a-0:a-0:a-0:i-119:m-0:m-0:p-0:s-1
> > > I: [2022-02-11T12:19:15+] - * amd64: rails, ruby-uglifier 
> > 
> > Package requested for removal is src:uglifyjs, building binary package 
> > node-uglify which provides virtual package uglifyjs.
> > 
> > Packages (build-)depending (unversioned or with only lower bounds) on 
> > "uglifyjs" should _not_ break: Such dependency is satisfied by package 
> > src:uglify-js, building binary package uglifyjs.
> > 
> > (i.e. there are 2 packages, one with and one without dash)
> > 
> > 
> > > Checking reverse dependencies...
> > [ false positive satisfied by src:uglify-js snipped ]
> > 
> > > ruby-uglifier: ruby-uglifier
> > 
> > Current upstream code FTBFS with Uglifyjs: see bug#981224
> > 
> > v2 branch currently in Debian unstable last update upstream in 2015: 
> > https://github.com/lautis/uglifier/tags?after=v3.0.0
> > 
> > 
> > > # Broken Build-Depends:
> > [ false positives satisfied by src:uglify-js snipped ]
> > 
> > > class.js: node-uglify
> > 
> > Bug#979888
> > 
> > > flightgear-phi: node-uglify
> > 
> > Bug#979902
> > 
> > > jquery-coolfieldset: node-uglify
> > 
> > Bug#979906
> > 
> > > jquery-lazyload: node-uglify
> > 
> > Bug#979911
> > 
> > > jquery-reflection: node-uglify
> > 
> > Bug#979907
> > 
> > > jquery-watermark: node-uglify
> > 
> > Bug#979943
> > 
> > > jquery-caret.js: node-uglify
> > 
> > Bug#979934
> > 
> > > jquery-simpletreemenu: node-uglify
> > 
> > Bug#979940
> > 
> > > jquery-throttle-debounce: node-uglify
> > 
> > Bug#979886
> > 
> > > raphael: node-uglify (>= 1.1.1-2~)
> > 
> > Bug#979937
> > 
> > > ruby-rails-assets-favico.js: node-uglify
> > 
> > Bug#979962
> > 
> > > ruby-rails-assets-jquery-fullscreen-plugin: node-uglify
> > 
> > Bug#979955
> > 
> > > ruby-rails-assets-perfect-scrollbar: node-uglify
> > 
> > Bug#979936
> > 
> > > ruby-uglifier: libjs-uglify
> > 
> > (see reasons at build-dependency above)
> > 
> > > slick: node-uglify
> > 
> > Bug#979954
> > 
> > > sockjs-client: node-uglify (>= 2.0)
> > 
> > Bug979958
> > 
> > 
> > > If you want to get uglifyjs removed from testing, there needs to 
> > > be an upgrade path to uglify-js 3.15.0 or all of these packages 
> > > need to be updated. So what's your plan here?
> > 
> > I have no plan.  What plan might be sensible?
> 
> As I have no idea what uglifyjs is used for, I cannot tell you. If 
> it's a drop in replacement, update the build dependencies or establish 
> an upgrade path via transitional packages. If it's not, patch them.
> 
> In the end, the above bugs need to be fixed to get uglifjs removed.

@Yadd: You did the mass-filing - can I ask you to please bump severity, 
since the normal process of bumping _after_ a package releationship 
changes to be a FTBFS cannot be used here because src:uglifyjs is 
transitively a key package.  Maybe my post to bug#979886 is useful for 
such followup mail.


> > > > (I tried to get the package auto-kicked from testing by filing 
> > > > release-critical bug#958117 but evidently that didn't work.)
> > > 
> > > uglifyjs is a key package, so auto-removal does not apply.
> > 
> > What does "key package" mean?  Simply that other packages 
> > (build-)depend on it, or perhaps some manually maintained list by 
> > the release team?
> > 
> > If the latter, then please remove src:uglifyjs as key package and 
> > instead treat src:uglify-js as key package.
> 
> You can check with the link Paul sent. It looks like other key 
> packages (there seems to be a path from reportbug via pytest to 
> uglifjs) build-depend on it. (Build)-Dependencies of key packages are 
> again key packages. So it will only be removed from the key package 
> list once those dependencies are fixed.

Ah, thanks - now I understand how to use the link from Paul.

Seems it is jquery-throttle-debounce that turns src:uglifyjs into a key 
package.

I 

Bug#1005253: [Pkg-shadow-devel] Bug#1005253: shadow: Improved manual page useradd.8

[Serge E. Hallyn]

On Wed, Feb 09, 2022 at 11:18:04PM +0100, Markus Hiereth wrote:
> Source: shadow
> Version: 4.8.1
> Severity: normal
> 
> Dear Serge,
> 
> attached to this bugreport the improved file useradd.8.xml and a diff.
> A last check is certainly reasonable.

Thanks.  The diff is especially helpful.  Although a few of these hunks
appear to be just changes to the line breaks.

...

> --- shadow-4.8.1/man/useradd.8.xml2020-01-17 16:47:56.0 +0100
> +++ shadow-4.8.1_mh/man/useradd.8.xml 2022-02-09 23:09:13.241687932 +0100
> @@ -143,11 +143,11 @@
>   
>   
> 
> - The default base directory for the system if 
> -dHOME_DIR is not specified.
> - BASE_DIR is
> - concatenated with the account name to define the home directory. 
> - If the -m option is not used,
> - BASE_DIR must exist.
> + The default base directory for the system if
> + -dHOME_DIR
> + is not specified.  BASE_DIR is
> + concatenated with the account name to define the home
> + directory.
> 
> 
>   If this option is not specified, useradd
> @@ -165,7 +165,7 @@
>   
> 
>   Any text string. It is generally a short description of the
> - login, and is currently used as the field for the user's full
> + account, and is currently used as the field for the user's full
>   name.
> 
>   
> @@ -177,12 +177,14 @@
>   
> 
>   The new user will be created using
> - HOME_DIR as the value for the user's
> - login directory. The default is to append the
> + HOME_DIR as the value for the
> + user's login directory. The default is to append the
>   LOGIN name to
> - BASE_DIR and use that as the login
> - directory name. The directory HOME_DIR
> - does not have to exist but will not be created if it is missing.
> + BASE_DIR and use that as the
> + login directory name.  If the directory
> + HOME_DIR does not exist, then
> + it will be created unless the -M option
> + is specified.
> 
>   
>
> @@ -219,14 +221,17 @@
>   
>   
> 
> - The number of days after a password expires until the account is
> - permanently disabled. A value of 0 disables the account as soon
> - as the password has expired, and a value of -1 disables the
> - feature.
> +defines the number of days after the password exceeded its 
> maximum
> +age where the user is expected to replace this password. The 
> value

How about 'number of days after the password exceeded its maximum age
during which the user may login by immediately replacing this password. The 
value
is stored in the shadow password file.'

> +is stored in the shadow password file. An input of 0 will 
> disable an
> +expired password with no delay. An input of -1 will blank the
> +respective field in the shadow password file. See 
> + shadow5
> +for more information.
> 
> 
>   If not specified, useradd will use the
> - default inactivity period specified by the
> + default inactivity onset specified by the

"onset" is weird here.

>   INACTIVE variable in
>   /etc/default/useradd, or -1 by default.
> 
> @@ -237,8 +242,9 @@
> -g, 
> --gidGROUP
>   
>   
> +   

This i assume is leftover marker to be dropped.

> 
> - The group name or number of the user's initial login group. The
> + The name or the number of the user's primary group. The
>   group name must exist. A group number must refer to an already
>   existing group.
> 
> @@ -249,7 +255,7 @@
>   set to yes (or
>   -U/--user-group is specified on the command
>   line), a group will be created for the user, with the same
> - name as her loginname. If the variable is set to
> + name as the loginname. If the variable is set to
>   no (or
>   -N/--no-user-group is specified on the
>   command line), useradd will set the primary group of the new
> @@ -315,14 +321,17 @@
>   (UID_MIN, UID_MAX,
>   UMASK, PASS_MAX_DAYS
>   and others).
> -   
> 
> - Example: 
> -KPASS_MAX_DAYS=-1
> - can be used when creating system account to turn off password
> - aging, even though system account has no password at all.
> - Multiple -K options can be specified, e.g.:
> - 
> -KUID_MIN=100
> - 
> -KUID_MAX=499
> +   
> + Example:
> + -KPASS_MAX_DAYS
> + =-1 can be used
> + when creating an account to turn off password aging.
> + Multiple -K options can be specified,
> + e.g.:
> + -KUID_MIN
> + =100-K
> + UID_MAX=499

Bug#1004946: Cannot hold down backspace to delete password

[Jamie Zawinski]

On Feb 11, 2022, at 8:51 AM, Daniel Kahn Gillmor  wrote:
> 
> If the regression is caused by changes in how XInput/XInput2 behave,
> then maybe this problem should be addressed in that package.  I'm
> reassigning this report there and marking that it affects xscreensaver.

I have no reason to believe that XInput2 has not always behaved that way. You 
are noticing it now because XScreenSaver only began using XInput2 as of 6.x.

Stating the problem/annoyance more concisely:

XInput2 does not send auto-repeat press/release events in the same manner as 
XNextEvent.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#979886: jquery-throttle-debounce: node-uglify is deprecated in favor of uglifyjs

[Jonas Smedegaard]

Source: jquery-throttle-debounce
Version: 1.1+dfsg.1-1.1
Followup-For: Bug #979886

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: severity -1 serious
Control: tags -1 +patch

Please fix this issue: UglifyJS v2 is unmaintained since years.

UglifyJS v3 was changed internally by kept most (possibly all) of the
same runtime options.

As a rule of thumb, node-* packages are for Node.js library interfaces,
and packages containing command-line tools implemented in Node.js use
package names with the node- prefix.

Since jquery-throttle-debounce only use the command-line interface of
UglifyJS, provided equally for v2 and v3 branches of the project, the
fix is to simply depend on the package name "uglifyjs" provided by both.

Concretely: Change to build-depend on uglifyjs (not on node-uglify).

NB! I have raised severity of this bugreport, since python3-pytest-cov
depends on this package, causing uglifyjs to transitively be treated as
a so-called "key package" not following common transition processes:
https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmIGmPsACgkQLHwxRsGg
ASFvPQ//SQ5lv/PkqE/o+ZrzNcSmyPqr1kZ/U0/JECuqfReytjtPO3HqU4sLFdEp
ektrf+E6KPq8akivRsML+u840QorMGUVOXMl5+cBGxisBB7ZhD9C9LUUrlZzM2GS
no+VY/bQiTnXsxD8MLtKEJmaWCKizBWvChi3b0poWC+QpzlmMTPEuUWCpJGxCGSi
t2LyzR6q/Vn1URCYKhrcJJMW82jOiIE5YsT+3xTKaITtHqcbuylPabgKzTOhj4bF
oJJtIr3aR9AG+YRZaRhM9sNq2RIf9OUCuQEiF+N4aKXzCCTUqo9MpOX6TDFJSvQB
EIQV5mX0Rh26P9NE+iuNPeTIBLNrEFmJOdg9V8xrU0WqLDLuw4KTS2po+Jiu/Igp
LHnvfzsykFJkgqa8ZXaWvQo6qudqTqeNGO7BTZFCgbxXGgg4/iYWGrVfFFSDlb6v
6UnbjA7nkAStnlapklMlSzcwbHuNqn6N/cvgPZ7lL5d8Xh4plZvcIQ9H6X0ZsbZQ
PiHsCZOiqWRtjZ7dxt2C9KSCt/WdsTqe4LnXhkyu9l9O8x7vFMS3fh2WpOtdjdK1
x50SScMP/n7qm6B5w21a19R3Lf/hs9VEIrZOQg6jdF81zx7iWaLZKG32K/lFUOTp
/pUmJcYsbiL5xIYFnXoQD5Qjuvnak2PK8VzbKFC2fTE9y8SV6cI=
=5JpY
-END PGP SIGNATURE-

Bug#1005342: ITP:php-fideloper-proxy - Set trusted proxies for Laravel

[Katharina Drexel]

Package: wnpp

* Package name: php-fideloper-proxy
  Upstream Author : Chris Fidao 
* License : MIT
  Description : Set trusted proxies for Laravel
 Setting a trusted proxy allows for correct URL generation, redirecting,
 session handling and logging in Laravel when behind a reverse proxy
 such as a load balancer or cache.

Regards
Katharina

Bug#924848: telegram-cli: B-D on wolfssl obsolete and potentially even harmful?

[Axel Beckert]

Hi,

according to https://tracker.debian.org/pkg/telegram-cli, telegram-cli
is threatened to be removed from testing due to an RC bug in the
wolfssl source package. But at least in the resulting binary package,
I see no relation to wolfssl, not even indirectly via libtgl.

The only occurrences of wolfssl in the telegram-cli source package
seem in the Debian packaging:

[…]it20160323.6547c0b21 → fgrep -r wolf
debian/rules:   dh_auto_configure -- --disable-openssl 
OPENSSL_INCLUDES="-I/usr/include/wolfssl -DWC_NO_HARDEN"
debian/control:   libwolfssl-dev,

But the resulting package does not have any dependency on wolfssl:

$ apt-cache show telegram-cli | fgrep wolf
$ apt-cache show telegram-cli | fgrep ssl
$

Neither does so libtgl — in contrary, it depends on OpenSSL libraries:

$ apt-cache show libtgl-0.0.0.20160623-0 | fgrep wolf
$ apt-cache show libtgl-0.0.0.20160623-0 | fgrep ssl 
Depends: libc6 (>= 2.17), libevent-2.1-7 (>= 2.1.8-stable), libssl1.1 (>= 
1.1.0), zlib1g (>= 1:1.1.4)
 same time - your messages sync seamlessly across any number of your phones,
$

So IMHO the wolfssl configure options and the build-dependency on
wolfssl actually _must_ be removed as the configure option seems to
have no effect and the build-dependency is not used and hence
unnecessary and (at least with regards to potential testing removal)
even harmful.

I actually wonder if this build-dependency stems from a time before
telegram-cli was build without libtgl and was just forgotten to be
removed.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1005341: libc++-13-dev: clang++ -stdlib=libc++ -fsanitize=fuzzer fails

[Sylvestre Ledru]

Le 11/02/2022 à 18:00, 0e4e63f6...@posteo.se a écrit :
> Package: libc++-13-dev
> Version: 1:13.0.1-2
> Severity: normal
[...]
>
> /usr/bin/ld:
> /usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.fuzzer-x86_64.a(FuzzerIO.cpp.o):
> in function `fuzzer::FileToVector(std::__cxx11::basic_string std::char_traits, std::allocator > const&, unsigned long,
> bool)':
> (.text._ZN6fuzzer12FileToVectorERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmb+0x30):
> undefined reference to `std::basic_ifstream std::char_traits
> >::basic_ifstream(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::_Ios_Openmode)'
> /usr/bin/ld:
> (.text._ZN6fuzzer12FileToVectorERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmb+0x64):
> undefined reference to `std::istream::seekg(long, std::_Ios_Seekdir)'
> ...
>
Interesting, it fails with 12 too.

but
clang++-13 -fsanitize=fuzzer /tmp/a.cpp

works
S

Bug#1005341: libc++-13-dev: clang++ -stdlib=libc++ -fsanitize=fuzzer fails

[0e4e63f6d6b]

Package: libc++-13-dev
Version: 1:13.0.1-2
Severity: normal

Steps to reproduce:

File /tmp/a.cpp:

#include 
#include 
extern "C" int LLVMFuzzerTestOneInput(const uint8_t*, size_t) { return 
0; }


Run clang++:

clang++-13 -stdlib=libc++ -fsanitize=fuzzer /tmp/a.cpp

Output:

/usr/bin/ld: 
/usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.fuzzer-x86_64.a(FuzzerIO.cpp.o): 
in function `fuzzer::FileToVector(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, unsigned long, 
bool)':
(.text._ZN6fuzzer12FileToVectorERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmb+0x30): 
undefined reference to `std::basic_ifstream 
>::basic_ifstream(std::__cxx11::basic_string, std::allocator > const&, std::_Ios_Openmode)'
/usr/bin/ld: 
(.text._ZN6fuzzer12FileToVectorERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmb+0x64): 
undefined reference to `std::istream::seekg(long, std::_Ios_Seekdir)'

...

Older versions work fine:

clang++-11 -stdlib=libc++ -fsanitize=fuzzer /tmp/a.cpp && echo $?
0

Bug#1005340: bullseye-pu: package golang-1.15/1.15.15-1~deb11u3

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: z...@debian.org, t...@security.debian.org

[ Reason ]
Backport patches for CVE-2022-23806 CVE-2022-23772 CVE-2022-23773

[ Impact ]

+ CVE-2022-23806: crypto/elliptic: fix IsOnCurve for big.Int values
  that are not valid coordinates
+ CVE-2022-23772: math/big: prevent large memory consumption in
  Rat.SetString
+ CVE-2022-23773: cmd/go: prevent branches from materializing into versions

All are minor security issues, so I'd like to go with stable-pu.

[ Tests ]

For CVE-2022-23806 and CVE-2022-23772, regression tests are backported as well.

For CVE-2022-23773 the tests in upstream patch are hard to backport, so I test
it manully. The test is similar with upstream patch[1]

[1] 
https://github.com/golang/go/commit/fa4d9b8e2bc2612960c80474fca83a4c85a974eb#diff-6d41824e441b8846a74c31ab4968dc114a1e650c05172e1f89826ea9e55d4c5aR421

For example, running

  GOPROXY=direct /usr/lib/go-1.15/bin/go get 
vcs-test.golang.org/git/semver-branch.git@v1.0.0

Will get same result and error in [1].

[ Risks ]

Patch for CVE-2022-23806 and CVE-2022-23772 are trivial and easy to review.
Patch for CVE-2022-23773 is larger, and is backported by 3way merge.

[ 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
  [ ] the issue is verified as fixed in unstable
  golang-1.15 has been removed from unstable.

[ Changes ]

See attachment.

[ Other info ]

CVE-2022-23806 and CVE-2022-23772 are for Go std library, which is statically
linked in all Go programs. But these issues look like too minor to rebuild all
Go programs.
diff -Nru golang-1.15-1.15.15/debian/changelog 
golang-1.15-1.15.15/debian/changelog
--- golang-1.15-1.15.15/debian/changelog2021-12-04 17:37:57.0 
+0800
+++ golang-1.15-1.15.15/debian/changelog2022-02-11 23:45:44.0 
+0800
@@ -1,3 +1,14 @@
+golang-1.15 (1.15.15-1~deb11u3) bullseye; urgency=medium
+
+  * Backport patches for CVE-2022-23806 CVE-2022-23772 CVE-2022-23773
++ CVE-2022-23806: crypto/elliptic: fix IsOnCurve for big.Int values
+  that are not valid coordinates
++ CVE-2022-23772: math/big: prevent large memory consumption in
+  Rat.SetString
++ CVE-2022-23773: cmd/go: prevent branches from materializing into versions
+
+ -- Shengjing Zhu   Fri, 11 Feb 2022 23:45:44 +0800
+
 golang-1.15 (1.15.15-1~deb11u2) bullseye; urgency=medium
 
   * Backport patch for CVE-2021-38297
diff -Nru golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch 
golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch
--- golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch
1970-01-01 08:00:00.0 +0800
+++ golang-1.15-1.15.15/debian/patches/0012-CVE-2022-23806.patch
2022-02-11 23:45:44.0 +0800
@@ -0,0 +1,132 @@
+From: Filippo Valsorda 
+Date: Wed, 2 Feb 2022 09:15:44 -0800
+Subject: CVE-2022-23806
+
+Origin: backport, https://github.com/golang/go/commit/6b3e741a
+---
+ src/crypto/elliptic/elliptic.go  |  5 +++
+ src/crypto/elliptic/elliptic_test.go | 81 
+ src/crypto/elliptic/p224.go  |  5 +++
+ 3 files changed, 91 insertions(+)
+
+diff --git a/src/crypto/elliptic/elliptic.go b/src/crypto/elliptic/elliptic.go
+index f93dc16..afedf18 100644
+--- a/src/crypto/elliptic/elliptic.go
 b/src/crypto/elliptic/elliptic.go
+@@ -71,6 +71,11 @@ func (curve *CurveParams) polynomial(x *big.Int) *big.Int {
+ }
+ 
+ func (curve *CurveParams) IsOnCurve(x, y *big.Int) bool {
++  if x.Sign() < 0 || x.Cmp(curve.P) >= 0 ||
++  y.Sign() < 0 || y.Cmp(curve.P) >= 0 {
++  return false
++  }
++
+   // y² = x³ - 3x + b
+   y2 := new(big.Int).Mul(y, y)
+   y2.Mod(y2, curve.P)
+diff --git a/src/crypto/elliptic/elliptic_test.go 
b/src/crypto/elliptic/elliptic_test.go
+index e80e773..bb16b0d 100644
+--- a/src/crypto/elliptic/elliptic_test.go
 b/src/crypto/elliptic/elliptic_test.go
+@@ -721,3 +721,84 @@ func testMarshalCompressed(t *testing.T, curve Curve, x, 
y *big.Int, want []byte
+   t.Errorf("point did not round-trip correctly: got (%v, %v), 
want (%v, %v)", X, Y, x, y)
+   }
+ }
++
++func testAllCurves(t *testing.T, f func(*testing.T, Curve)) {
++  tests := []struct {
++  name  string
++  curve Curve
++  }{
++  {"P256", P256()},
++  {"P256/Params", P256().Params()},
++  {"P224", P224()},
++  {"P224/Params", P224().Params()},
++  {"P384", P384()},
++  {"P384/Params", P384().Params()},
++  {"P521", P521()},
++  {"P521/Params", P521().Params()},
++  }
++  if testing.Short() {
++  tests = tests[:1]
++  }
++  for _, test := range tests {
++  

Bug#1004946: Cannot hold down backspace to delete password

[Daniel Kahn Gillmor]

Control: reopen 1004946
Control: reassign 1004946 libxi6 2:1.8-1
Control: affects 1004946 + xscreensaver

On Fri 2022-02-04 07:29:55 +0100, martin f krafft wrote:
> Package: xscreensaver
> Version: 6.02+dfsg1-2
> Severity: normal
>
> If I know I mistyped the password, I am used to holding down 
> backspace to erase all characters, effectively making use of the key 
> repeat. This stopped working with version 6, and now holding down 
> the key only ever removes a single character.

On Thu 2022-02-03 22:59:34 -0800, Jamie Zawinski wrote:

> For some reason, the XInput2 extension doesn't auto-repeat certain
> keys that used to auto-repeat when read the "old" way. Unfortunately
> there's nothing I can do about this. I process only the keystrokes
> that I receive.
>
> However you can use the traditional keystrokes ^U and ^X to clear the
> whole line.

As i understand it, XInput2 is provided by libxi6, from the libxi source
package.

This is a significant regression in user experience, and definitely
something confusing for users who see the backspace key and don't
understand why it's not repeating as expected.  Ctrl-U or Ctrl-X might
be an acceptable workaround for weirdos like the three of us, but it is
decidedly user-unfriendly for a screensaver to work this way.  Holding
down backspace to clear screwed up keystrokes is an incredibly common
usage pattern for password entry fields.

If the regression is caused by changes in how XInput/XInput2 behave,
then maybe this problem should be addressed in that package.  I'm
reassigning this report there and marking that it affects xscreensaver.

--dkg


signature.asc
Description: PGP signature

Bug#1005339: general: usbmouse+keyboard lag on closing the lid or issuing xrandr --output eDP-1 --off

[Mario Natiello]

Package: general
Severity: normal

Dear Maintainer,

   * What led up to the situation?
with an external monitor attached, closing the lid or issuing
  xrandr --output eDP-1 --off
to disable the laptop screen.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 close laptop lid or issue above xrandr command
 
   * What was the outcome of this action?
the usbmouse and keyboard lag

   * What outcome did you expect instead?
normal behaviour of usbmouse and keyboard

Note: By issuing
xrandr --auto
usbmouse+keyboard return to normal, but the laptop screen is on, even
if lid is closed

Linux  5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
x86_64 GNU/Linux
Debian 11 bullseye

-- 
Mario Natiello

Bug#1004927: ITP: libtree -- ldd as a tree

[Guillem Jover]

Hi!

On Thu, 2022-02-03 at 19:31:20 +0100, Gürkan Myczko wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Gürkan Myczko 
> X-Debbugs-Cc: debian-de...@lists.debian.org

Hmm, thought I had replied already, now that I just saw this in NEW.

> * Package name: libtree
>   Version : 3.0.2
>   Upstream Authors: Harmen Stoppels
>   URL : https://github.com/haampie/libtree
> * License : MIT
>   Description : ldd as a tree
>  This is tool like ldd with these features:
>  - turns ldd into a tree
>  - explains why shared libraries are found and why not

The name seems rather confusing, I'd assume this is a library
providing some kind of tree structure support or similar.

Could upstream perhaps rename this to something like lddtree or
similar?

Thanks,
Guillem

Bug#1005311: xserver-xorg-video-nvidia: Package has unmet dependencies

[Andreas Beckmann]

On 11/02/2022 11.48, Michael Tatge wrote:

since updating today the nvidia driver package doesn't work anymore.
It depends on xserver-xorg-video-nvidia which has unmet dependencies itself.

Depends: xserver-xorg-core (< 2:1.20.99) but 2:21.1.3-2 is to be installed


Not to forget
  Depends: xorg-video-abi-24 but it is not installable or ...

Does the nvidia driver support the new xorg-video-abi-25 in the new Xorg 
version? There was nothing in upstream's changelog, yet.



Andreas

Bug#1003548: transition: libwebp

[Sebastian Ramacher]

On 2022-02-11 07:27:42 -0800, Jeff Breidenbach wrote:
> # remove the moreinfo tag
> tags 1003548 - moreinfo
> thanks
> 
> Sebastian, may we move forward with ibwebp?

The perl 5.34 transition is currently ongoing. As libwebp and perl 5.34
collide, libwebp will need to wait until perl is done.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1003548: transition: libwebp

[Jeff Breidenbach]

# remove the moreinfo tag
tags 1003548 - moreinfo
thanks

Sebastian, may we move forward with ibwebp?

Bug#951311: Cannot reproduce with texlive-fonts-recommended 2020.20210202-3 or 2021.20220204-1

[Felix Dörre]

Hello,

Is this problem still occurring? I am using bless 0.6.0-7 with 
texlive-fonts-recommended 2020.20210202-3 or 2021.20220204-1 and both 
seem to be fine.


--
Kind regards,
Felix Dörre

Bug#1004710: Please pass "-r" to useradd when needed

[Bálint Réczey]

Hi All,

On Fri, 11 Feb 2022 07:21:38 +0100 Johannes Schauer Marin Rodrigues
 wrote:
> Hi Jason,
>
> Quoting Jason Franklin (2022-02-11 03:14:23)
> > I have been helping Marc Haber with some of the issues in adduser, so I
> > suppose it is appropriate for me to chime in here.
> >
> > Thanks so much for the report and for the investigative work so far!
> >
> > Here are my thoughts...
> >
> > The "good" chroot has version 1:4.8.1-2 of passwd, and the "bad" chroot
> > has version 1:4.11.1+dfsg1-1 of passwd. The changes between these two
> > versions were substantial.
> >
> > > Quoting Bálint Réczey (2022-02-10 22:46:50)
> > > > Apparently useradd correctly guessed system user ranges in the past,
> > > > but this is not something to rely on.
> >
> > I do not think "useradd" ever attempted to guess whether a UID being
> > added was in the system user range. Instead, it looks like hardcoded
> > settings in the source code changed between the two versions above. To
> > see this, you may reference the upstream shadow repository...
> >
> > Commit: 
> > https://github.com/shadow-maint/shadow/commit/bbf4b79bc49fd1826eb41f6629669ef0b647267b
> >
> > The key part of that change was this:
> >
> > - static const char *def_create_mail_spool = "no";
> > + static const char *def_create_mail_spool = "yes";
> >
> > The "adduser" command never set the "-r" option previously, but the
> > default in the upstream source was to not create the mail spool
> > directories.  Thus, this problem never surfaced.
> >
> > > the recent upload of shadow 1:4.11.1+dfsg1-1 made above patch necessary as
> > > otherwise useradd will create empty directories in /var/mail and
> > > /var/spool/mail for the system users _apt, systemd-network and 
> > > systemd-resolve.
> > > This in turn breaks the testsuite of my package mmdebstrap.
> >
> > I think setting the "-r" option is the right approach, but we need to
> > make sure that the new option doesn't do anything else that we do not
> > expect for it to do. I can see that it does more than just omit creating
> > the mail spool by default.
> >
> > The "passwd" package could be patched temporarily to undo the change
> > from "no" to "yes" above. That would put us back at the old behavior for
> > the time being. This patch could be removed in the not-to-far future, as
> > I am committed to helping with supporting adduser and with fixing bugs
> > new and old, including this one. :)
> >
> > Looking forward to hearing what Marc and others think on this one.
>
> thank you for chiming in and putting more details on the table!
>
> The change you found indeed seems like the creation of the spool directories 
> is
> intentional.

Yes, thank you Jason for digging deeper. The change is intentional
upstream, but I'd like to revert the behaviour in Debian to not change
defaults:
https://salsa.debian.org/rbalint/shadow/-/commit/b96c915fb68d3591c56f54b687e87af25579fe73

I'm happy that we agree on passing "-r" from adduser. I plan doing a
new shadow upload next week with the revert and possibly with other
fixes leaving this bug open because it is still a valid issue even
with the original defaults.

Cheers,
Balint

> I can also see how setting the -r option might have unintended side-effects.
>
> But the information you found already helps me to work around this problem 
> from

Bug#1005294: [Pkg-javascript-devel] Bug#1005294: Emscripten attempts to run invalid closure-compiler command

[Jonas Smedegaard]

Quoting Jeremy James (2022-02-11 14:59:06)
> I would suggest updating the arguably faulty patch to just have the
> following for tools/building.py's get_closure_compiler() (optionally
> fixing the upstream comment typo):
> --
> def get_closure_compiler():
>   # First check if the user configured a specific CLOSURE_COMPILER in
> thier settings
>   if config.CLOSURE_COMPILER:
> return config.CLOSURE_COMPILER
> 
>   # Otherwise use the system-shared one
>   return ['closure-compiler']
> --
> And then it would actually call closure-compiler and it might just
> inspire somebody more au fait with the respective packages (and how to
> approach such a problem) to address the 16 or so reverse-dependencies
> of closure-compiler mentioned in #916145?

Makes sense now.  Thanks for elaborating!

I think a better approach is to simply set CLOSURE_COMPILER by default 
and (build-)depend on closure-compiler.

Please consider sharing if you write a closure-compiler wrapper script - 
might be sensible to ship with emscripten package, e.g. by setting 
CLOSURE_COMPILER=/usr/share/emscripten/closure-compiler_wrapper by 
default.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1005317: git-buildpackage: Make it easier to support an extra packaging branch (for derivatives)

[Guido Günther]

Hi Arnaud,
On Fri, Feb 11, 2022 at 01:33:47PM +0700, Arnaud Rebillout wrote:
> Package: git-buildpackage
> Version: 0.9.25
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> 
>   Dear Maintainer, dear Guido,
> 
> At Kali Linux we use gbp to maintain our packages. We have around 500
> packages total, among which 40 are forked from Debian. Kali Linux being
> a rolling distribution, those 40 packages are kept in sync with their
> counterpart in Debian testing, meaning that we update them often.
> 
> We use the same workflow for pretty much all of our packages: 3 git
> branches (packaging, upstream and pristine-tar), and no upstream git
> history. We use "gbp import-orig" for all the Kali specific packages,
> and "gbp import-dsc" for all the Debian forks.
> 
> All in all, gbp works great for us, but nothing is never perfect :)
> 
> 
> THE PROBLEM
> 
> For our Debian forks, we actually have 4 branches (or 2 when it's a
> native package): we have the packaging branch (named "kali/master"), the
> usual upstream and pristine-tar branches, but we also have the "upstream
> distro" branch (named "debian") that contains the unmodified source from
> Debian, as imported by "gbp import-dsc".
> 
> Just to clarify, let me describe how we maintain such a 4-branches git
> repo:
> 
> * Step 1.  $ gbp import-dsc --debian-branch=debian
>   -> ie. update the 3 branches upstream, pristine-tar and debian.
> 
> * Step 2.  $ git merge debian
>   -> ie. merge the debian branch into the kali/master branch. This is
>  when we resolve our merge conflicts, since the Kali changes live
>  on the kali/master branch.
> 
> (Note: this workflow was mentioned in https://bugs.debian.org/670612)
> 
> This workflow works very well, and keeping our Debian forks in sync with
> Debian is fairly straightforward.
> 
> Our issue is that the 4th branch (the "debian" branch) lives out of the
> realm of gbp. Therefore it's ignored by the gbp commands that deal with
> git branches, and we always need additional steps to handle this branch.
> In particular:
> 
> * gbp clone: Won't setup this branch, one has to do it manually:
> 
> gbp clone
> cd 
> git branch debian origin/debian
> 
> * gbp pull: Won't pull it, one has to do it manually:
> 
> gbp pull
> git checkout debian
> git merge
> git checkout -
> 
>   (or: pull all branches)
> 
> gbp pull --all
> 
> * gbp push: Won't push it, one has to do it manually:
> 
> gbp push
> git checkout debian
> git push
> git checkout -
> 
>   (or: push with git)
> 
> git push origin : --follow-tags
> 
>   (or: if the --tips option in #908204 was implemented, we could do:)
> 
> gbp push --tips
> 
> These additional steps are trivial, but they are also easy to forget.
> One thing that keeps biting me is that I often forget to pull the
> "debian" branch. So I work on the package, update it, make it ready for
> upload, and at the last moment, when I want to push all the git
> branches, git refuses, because I worked with an outdated branch and my
> modifications are not fast-forwardable. So I have to restart from zero,
> or force push, or whatever.
> 
> 
> THE TENTATIVE IMPROVEMENTS
> 
> So I've been thinking hard about ways to prevent that to happen, and
> more generally, about how I could get gbp to clone/pull/push this 4th
> branch automatically, so that there's no need for additional steps.
> 
> Here are some ideas, starting with the worst one:
> 
>   1) the "upstream distro" concept
> 
> An ambitious and complicated way could be to teach gbp about the concept
> of an "upstream distro" (meaningful only for Debian derivatives), and
> define in the gbp.conf what is the "upstream-distro-branch", the
> "upstream-distro-tag", and more if needed. And then let gbp do the right
> thing (TM). In other words, hammer a new concept into gbp.
> 
> IMO: way too complicated.
> 
>   2) the "extra branche(s)" idea
> 
> Instead, a lighter approach could be to teach gbp about "extra
> branches", without defining what those branches are for. "gbp clone"
> would setup those branches, and "gbp pull" would pull it. That's super
> easy to implement. The complicated part is that "gbp push", as far as I
> can see, would not know what to do with this branch, due to the way it
> works. And therefore it wouldn't push it. Unless the option "--tips"
> mentioned in #908204 is implemented, and in such case we could document
> that gbp will push the extra branches only when --tips is enabled.
> 
> It's not super elegant (and maybe not super useful) to introduce an
> option for extra branches, and then say that it's only supported by
> clone and pull, but not supported by push. So I'm not super convinced
> myself...
> 
>   3) more hooks
> 
> I've noticed that some gbp actions have a "--postxxx" argument, to allow
> users to run hooks. That could help!
> 
> There's already a "--postclone" option. I can add this snippet in
> debian/gbp.conf, and it works:
> 
> 

Bug#1005338: Exception when building git-buildpackage API docs

[Guido Günther]

Package: pydoctor
Version: 21.12.1-1
Severity: normal
Affects: git-buildpackage

Hi,
I *think* since the switch to python3.9 pydoctor fails to build gbp's
API docs:

make apidocs
pydoctor -v --config=.pydoctor.cfg
adding directory /var/scratch/src/git-buildpackage/git-buildpackage/gbp
adding directory 
/var/scratch/src/git-buildpackage/git-buildpackage/tests/doctests
processing ['gbp.scripts.create_remote_repo']
processing ['gbp.scripts.create_remote_repo', 'gbp.deb.changelog']
processing ['gbp.scripts.create_remote_repo', 'gbp.deb.changelog', 
'gbp.command_wrappers']
processing ['gbp.scripts.create_remote_repo', 'gbp.config']
processing ['gbp.scripts.create_remote_repo', 'gbp.config', 'gbp.errors']
…
Package 'gbp.rpm'
ZopeInterfaceModule 'gbp.rpm.changelog'
ZopeInterfaceClass 'gbp.rpm.changelog.ChangelogError'
ZopeInterfaceClass 'gbp.rpm.changelog._ChangelogHeader'
ZopeInterfaceClass 'gbp.rpm.changelog._ChangelogEntry'
Traceback (most recent call last):
  File "/usr/lib/python3.9/xml/sax/expatreader.py", line 217, in feed
self._parser.Parse(data, isFinal)
xml.parsers.expat.ExpatError: undefined entity: line 1, column 46

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/web/_flatten.py", line 321, in 
_flattenTree
element = next(stack[-1])
  File "/usr/lib/python3/dist-packages/twisted/web/_flatten.py", line 237, in 
_flattenElement
result = renderMethod(request, rootClone)
  File 
"/usr/lib/python3/dist-packages/pydoctor/templatewriter/pages/functionchild.py",
 line 73, in functionBody
return self.docgetter.get(self.ob)
  File 
"/usr/lib/python3/dist-packages/pydoctor/templatewriter/pages/__init__.py", 
line 71, in get
return epydoc2stan.format_docstring(ob)
  File "/usr/lib/python3/dist-packages/pydoctor/epydoc2stan.py", line 744, in 
format_docstring
fh.handle(Field.from_epydoc(field, source))
  File "/usr/lib/python3/dist-packages/pydoctor/epydoc2stan.py", line 600, in 
handle
m(field)
  File "/usr/lib/python3/dist-packages/pydoctor/epydoc2stan.py", line 529, in 
handle_type
self.types[name] = field.format()
  File "/usr/lib/python3/dist-packages/pydoctor/epydoc2stan.py", line 353, in 
format
return self.body.to_stan(_EpydocLinker(self.source))
  File "/usr/lib/python3/dist-packages/pydoctor/epydoc/markup/__init__.py", 
line 134, in to_stan
self._stan = Tag('', children=node2stan.node2stan(self.to_node(), 
docstring_linker).children)
  File "/usr/lib/python3/dist-packages/pydoctor/node2stan.py", line 42, in 
node2stan
return html2stan(''.join(html))
  File "/usr/lib/python3/dist-packages/pydoctor/stanutils.py", line 30, in 
html2stan
stan = XMLString(b'%s' % html).load()[0]
  File "/usr/lib/python3/dist-packages/twisted/web/template.py", line 402, in 
__init__
self._loadedTemplate = _flatsaxParse(NativeStringIO(s))
  File "/usr/lib/python3/dist-packages/twisted/web/template.py", line 356, in 
_flatsaxParse
parser.parse(fl)
  File "/usr/lib/python3.9/xml/sax/expatreader.py", line 111, in parse
xmlreader.IncrementalParser.parse(self, source)
  File "/usr/lib/python3.9/xml/sax/xmlreader.py", line 125, in parse
self.feed(buffer)
  File "/usr/lib/python3.9/xml/sax/expatreader.py", line 221, in feed
self._err_handler.fatalError(exc)
  File "/usr/lib/python3.9/xml/sax/handler.py", line 38, in fatalError
raise exception
xml.sax._exceptions.SAXParseException: :1:46: undefined entity

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pydoctor", line 33, in 
sys.exit(load_entry_point('pydoctor==21.12.1', 'console_scripts', 
'pydoctor')())
  File "/usr/lib/python3/dist-packages/pydoctor/driver.py", line 482, in main
writer.writeIndividualFiles(subjects)
  File "/usr/lib/python3/dist-packages/pydoctor/templatewriter/writer.py", line 
81, in writeIndividualFiles
self._writeDocsFor(ob)
  File "/usr/lib/python3/dist-packages/pydoctor/templatewriter/writer.py", line 
103, in _writeDocsFor
self._writeDocsFor(o)
  File "/usr/lib/python3/dist-packages/pydoctor/templatewriter/writer.py", line 
103, in _writeDocsFor
self._writeDocsFor(o)
  File "/usr/lib/python3/dist-packages/pydoctor/templatewriter/writer.py", line 
103, in _writeDocsFor
self._writeDocsFor(o)
  File "/usr/lib/python3/dist-packages/pydoctor/templatewriter/writer.py", line 
101, in _writeDocsFor
self._writeDocsForOne(ob, fobj)
  File "/usr/lib/python3/dist-packages/pydoctor/templatewriter/writer.py", line 
123, in _writeDocsForOne
flattenToFile(fobj, page)
  File "/usr/lib/python3/dist-packages/pydoctor/templatewriter/writer.py", line 
31, in flattenToFile
raise err
twisted.web.error.FlattenerError: Exception while flattening:
  
  Tag <>
  [[Tag('html', children=['\n', '  ', '\n', '\n', '  ', Tag('', 
children=['Head']), '\n', '\n', '  ', Tag('body', children=['\n', '\n', '', 

Bug#977821: dxvk FTCBFS: build vs host confusion

[duck]

Quack,

Sorry for the lag and thanks for your explanation and patch. I have 
committed it and it will land in the next upload. Currently the Salsa 
check is broken due to #991384 so I cannot be sure it builds fine.


As for the headers, `Multi-Arch` is already set to `foreign` for all 
three binary packages, is that ok?


Regards.
\_o<

--
Marc Dequènes

Bug#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

On Fri, 2022-02-11 at 15:32 +0100, Marc Haber wrote:
> How about doing a release with all accumulated changes? It's called
> unstable for a reason, and frankly, I don't feel like putting ourselves
> into a rush just because another package broke ours.

I am certainly on board with this. Rushing is never good.

We will take our time and do this right. :)

It looks like Johannes will be able to work around this on his end for
now. I will put together a PR with tests in the near future to get this
fixed the right way.

-- 
Jason Franklin

Bug#1004710: Please pass "-r" to useradd when needed

[Marc Haber]

On Thu, Feb 10, 2022 at 11:24:44PM -0500, Jason Franklin wrote:
> Does this all sound reasonable?

How about doing a release with all accumulated changes? It's called
unstable for a reason, and frankly, I don't feel like putting ourselves
into a rush just because another package broke ours.

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#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

On Fri, 2022-02-11 at 07:21 +0100, Johannes Schauer Marin Rodrigues
wrote:
> I can also see how setting the -r option might have unintended side-effects.
> 
> But the information you found already helps me to work around this problem 
> from
> the side of my package mmdebstrap. :)

Oh, cool! This is great to hear. It takes some of the time crunch off.

There are several useradd features that need to be incorporated into the
adduser code. This needs to be done carefully.

The "-r" option is one such feature. I will confirm this bug and make it
a priority to introduce this fix into the code with proper review and
tests and what not.

Thanks!

-- 
Jason Franklin

Bug#1005328: RM: uglifyjs/2.8.29-8

[Sebastian Ramacher]

On 2022-02-11 14:48:00 +0100, Jonas Smedegaard wrote:
> Quoting Sebastian Ramacher (2022-02-11 13:24:16)
> > Control: tags -1 moreinfo
> > 
> > On 2022-02-11 12:08:52 +0100, Jonas Smedegaard wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: rm
> > > X-Debbugs-Cc: Debian Javascript Maintainers 
> > > 
> > > 
> > > uglifyjs v2 was last updated upstream in 2017, and has no real
> > > maintainer in Debian since December 2020 - see bug#958117
> > > 
> > > The package should not be released with bookworm, but may still have
> > > reverse (build-)dependencies, and I therefore request removal only from
> > > testing for now.  Please advice if another approach is more sensible.
> > 
> > So this is the same request as #968137. The current situation is:
> > 
> > I: [2022-02-11T12:19:15+] - trying: -uglifyjs
> > I: [2022-02-11T12:19:15+] - skipped: -uglifyjs (0, 33, 62)
> > I: [2022-02-11T12:19:15+] - got: 123+0: 
> > a-3:a-0:a-0:a-0:i-119:m-0:m-0:p-0:s-1
> > I: [2022-02-11T12:19:15+] - * amd64: rails, ruby-uglifier 
> 
> Package requested for removal is src:uglifyjs, building binary package 
> node-uglify which provides virtual package uglifyjs.
> 
> Packages (build-)depending (unversioned or with only lower bounds) on 
> "uglifyjs" should _not_ break: Such dependency is satisfied by package 
> src:uglify-js, building binary package uglifyjs.
> 
> (i.e. there are 2 packages, one with and one without dash)
> 
> 
> > Checking reverse dependencies...
> [ false positive satisfied by src:uglify-js snipped ]
> 
> > ruby-uglifier: ruby-uglifier
> 
> Current upstream code FTBFS with Uglifyjs: see bug#981224
> 
> v2 branch currently in Debian unstable last update upstream in 2015: 
> https://github.com/lautis/uglifier/tags?after=v3.0.0
> 
> 
> > # Broken Build-Depends:
> [ false positives satisfied by src:uglify-js snipped ]
> 
> > class.js: node-uglify
> 
> Bug#979888
> 
> > flightgear-phi: node-uglify
> 
> Bug#979902
> 
> > jquery-coolfieldset: node-uglify
> 
> Bug#979906
> 
> > jquery-lazyload: node-uglify
> 
> Bug#979911
> 
> > jquery-reflection: node-uglify
> 
> Bug#979907
> 
> > jquery-watermark: node-uglify
> 
> Bug#979943
> 
> > jquery-caret.js: node-uglify
> 
> Bug#979934
> 
> > jquery-simpletreemenu: node-uglify
> 
> Bug#979940
> 
> > jquery-throttle-debounce: node-uglify
> 
> Bug#979886
> 
> > raphael: node-uglify (>= 1.1.1-2~)
> 
> Bug#979937
> 
> > ruby-rails-assets-favico.js: node-uglify
> 
> Bug#979962
> 
> > ruby-rails-assets-jquery-fullscreen-plugin: node-uglify
> 
> Bug#979955
> 
> > ruby-rails-assets-perfect-scrollbar: node-uglify
> 
> Bug#979936
> 
> > ruby-uglifier: libjs-uglify
> 
> (see reasons at build-dependency above)
> 
> > slick: node-uglify
> 
> Bug#979954
> 
> > sockjs-client: node-uglify (>= 2.0)
> 
> Bug979958
> 
> 
> > If you want to get uglifyjs removed from testing, there needs to be an 
> > upgrade path to uglify-js 3.15.0 or all of these packages need to be 
> > updated. So what's your plan here?
> 
> I have no plan.  What plan might be sensible?

As I have no idea what uglifyjs is used for, I cannot tell you. If it's
a drop in replacement, update the build dependencies or establish an
upgrade path via transitional packages. If it's not, patch them.

In the end, the above bugs need to be fixed to get uglifjs removed.

> > > (I tried to get the package auto-kicked from testing by filing
> > > release-critical bug#958117 but evidently that didn't work.)
> > 
> > uglifyjs is a key package, so auto-removal does not apply.
> 
> What does "key package" mean?  Simply that other packages (build-)depend 
> on it, or perhaps some manually maintained list by the release team?
> 
> If the latter, then please remove src:uglifyjs as key package and 
> instead treat src:uglify-js as key package.

You can check with the link Paul sent. It looks like other key packages
(there seems to be a path from reportbug via pytest to uglifjs)
build-depend on it. (Build)-Dependencies of key packages are again key
packages. So it will only be removed from the key package list
once those dependencies are fixed.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1005337: pynac can be removed from Debian

[Tobias Hansen]

Source: pynac
Version: 0.7.29-2
Severity: normal

Hi Julien,

pynac was merged into sagemath 9.5, see https://trac.sagemath.org/ticket/32386
Since pynac has no other use than the one in sage (according to that ticket) I 
suggest that you request removal of pynac from Debian unstable.

Best wishes,
Tobias

Bug#1005294: [Pkg-javascript-devel] Bug#1005294: Emscripten attempts to run invalid closure-compiler command

[Jeremy James]

> Yes, this is a known issue, documented in README.Debian:
> https://salsa.debian.org/js-team/emscripten/-/blob/debian/latest/debian/README.Debian#L50
> ...
> Thanks for the suggestion.  I wonder if such change will actually be any
> better: I very much doubt that the horribly old closure-compiler
> available in Debian can do *anything* sensible, but would be happy if
> proven wrong.
>
> Did you test that suggested change, using closure-compiler in Debian?

Well, it certainly can't be worse - this error is caused by the debian
patch! But yes, the packaged closure-compiler from 2013 is somewhat
unsuitable for use generally. In this case, I was hoping to create a
/usr/local/bin/closure-compiler script and use that instead.

If I install that package and explicitly set CLOSURE_COMPILER to
/usr/bin/closure-compiler then I get the inevitable following:

building:ERROR: Closure compiler run failed:
building:ERROR: "--language_out" is not a valid option

If I grab a recent closure-compiler JAR [1] and create a wrapper script:

cat >/usr/local/bin/closure-compiler < Sounds like you have some knowledge/experience here.

To be fair, I'm just trying to get this working for some automated
builds rather than getting deep into the internals of emscripten, but
I really would prefer not to have to create custom versions of tools
like emscripten if at all possible. For example there's another
frustrating issue for parallel builds that it always wants to create
~/.emscripten even if --generate-config is used but that's upstream
and I'll send a bug to them (I do, however, want to use the debian
feature of automatically setting CLANG_ADD_VERSION/LLVM_ADD_VERSION to
save having to install the llvm-defaults related packages).

> I am open to improving README.Debian, but will need help: Please provide
> suggestions for rephrased text.

I would suggest updating the arguably faulty patch to just have the
following for tools/building.py's get_closure_compiler() (optionally
fixing the upstream comment typo):
--
def get_closure_compiler():
  # First check if the user configured a specific CLOSURE_COMPILER in
thier settings
  if config.CLOSURE_COMPILER:
return config.CLOSURE_COMPILER

  # Otherwise use the system-shared one
  return ['closure-compiler']
--
And then it would actually call closure-compiler and it might just
inspire somebody more au fait with the respective packages (and how to
approach such a problem) to address the 16 or so reverse-dependencies
of closure-compiler mentioned in #916145?

Best wishes,
Jeremy

[1] https://mvnrepository.com/artifact/com.google.javascript/closure-compiler

Bug#1005335: [Pkg-javascript-devel] Bug#1005335: eslint: Please update to node-regenerate-unicode-properties 10

[Jonas Smedegaard]

Quoting Yadd (2022-02-11 14:30:44)
> node-regenerate-unicode-properties API changed. Here is a patch to use 
> version 10 (pushed to experimental)

Thanks.

Please bump severity when this is actionable for packaging targeted 
unstable.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#629506: memtest86+ crashes

[Fabio Fantoni]

hi, version < 5.31b+dfsg-1 was crashing/freezing on major of cases for 
different issues, the latest version use the latest upstream beta 
version and additional patches solved all freeze/crash cases I saw 
except multiboot (now disabled by default)


If the issue is still reproducible also on latest version version can 
you tell me please? (even if in this report I saw at least 2 different 
issues)




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000865: git-buildpackage: gbp pq: should export non-ASCII authors as UTF-8, without quoted-printable or base64

[Guido Günther]

Hi,
On Tue, Nov 30, 2021 at 11:59:16AM +, Simon McVittie wrote:
> Package: git-buildpackage
> Version: 0.9.25
> Severity: wishlist
> 
> To reproduce: add patches to the patch series whose author has a non-ASCII
> name, for example commit b01f371ce61f8077bb70a2b6024f4163fafffc5c in
> GTK 3, from Nelson Benítez León; then `gbp pq export`.
> 
> Expected result: Debian packaging is an 8-bit-clean format that expects
> UTF-8, so the patch in debian/patches should have
> "From: Nelson Benítez León ", encoded in UTF-8.
> 
> Actual result: the Python modules used by gbp pq assume a 7-bit email
> transport, and the patch in debian/patches starts with
> "From: =?utf-8?b?TmVsc29uIEJlbsOtdGV6IExlw7Nu?= ",
> which is not very good from the perspective of crediting the appropriate
> author or human-readability of the patch.
> 
> Names with fewer non-ASCII characters end up in quoted-printable rather
> than base64, for example Timm Bäder -> =?utf-8?q?Timm_B=C3=A4der?=, which
> is slightly more readable but still not great.
> 
> Would it be possible to tell the email modules to avoid using this encoding,
> or explicitly decode UTF-8 in the email headers during DEP-3
> formatting?

I'd welcome patches here.
Cheers,
 -- Guido

Bug#1005328: RM: uglifyjs/2.8.29-8

[Jonas Smedegaard]

Quoting Sebastian Ramacher (2022-02-11 13:24:16)
> Control: tags -1 moreinfo
> 
> On 2022-02-11 12:08:52 +0100, Jonas Smedegaard wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: rm
> > X-Debbugs-Cc: Debian Javascript Maintainers 
> > 
> > 
> > uglifyjs v2 was last updated upstream in 2017, and has no real
> > maintainer in Debian since December 2020 - see bug#958117
> > 
> > The package should not be released with bookworm, but may still have
> > reverse (build-)dependencies, and I therefore request removal only from
> > testing for now.  Please advice if another approach is more sensible.
> 
> So this is the same request as #968137. The current situation is:
> 
> I: [2022-02-11T12:19:15+] - trying: -uglifyjs
> I: [2022-02-11T12:19:15+] - skipped: -uglifyjs (0, 33, 62)
> I: [2022-02-11T12:19:15+] - got: 123+0: 
> a-3:a-0:a-0:a-0:i-119:m-0:m-0:p-0:s-1
> I: [2022-02-11T12:19:15+] - * amd64: rails, ruby-uglifier 

Package requested for removal is src:uglifyjs, building binary package 
node-uglify which provides virtual package uglifyjs.

Packages (build-)depending (unversioned or with only lower bounds) on 
"uglifyjs" should _not_ break: Such dependency is satisfied by package 
src:uglify-js, building binary package uglifyjs.

(i.e. there are 2 packages, one with and one without dash)


> Checking reverse dependencies...
[ false positive satisfied by src:uglify-js snipped ]

> ruby-uglifier: ruby-uglifier

Current upstream code FTBFS with Uglifyjs: see bug#981224

v2 branch currently in Debian unstable last update upstream in 2015: 
https://github.com/lautis/uglifier/tags?after=v3.0.0


> # Broken Build-Depends:
[ false positives satisfied by src:uglify-js snipped ]

> class.js: node-uglify

Bug#979888

> flightgear-phi: node-uglify

Bug#979902

> jquery-coolfieldset: node-uglify

Bug#979906

> jquery-lazyload: node-uglify

Bug#979911

> jquery-reflection: node-uglify

Bug#979907

> jquery-watermark: node-uglify

Bug#979943

> jquery-caret.js: node-uglify

Bug#979934

> jquery-simpletreemenu: node-uglify

Bug#979940

> jquery-throttle-debounce: node-uglify

Bug#979886

> raphael: node-uglify (>= 1.1.1-2~)

Bug#979937

> ruby-rails-assets-favico.js: node-uglify

Bug#979962

> ruby-rails-assets-jquery-fullscreen-plugin: node-uglify

Bug#979955

> ruby-rails-assets-perfect-scrollbar: node-uglify

Bug#979936

> ruby-uglifier: libjs-uglify

(see reasons at build-dependency above)

> slick: node-uglify

Bug#979954

> sockjs-client: node-uglify (>= 2.0)

Bug979958


> If you want to get uglifyjs removed from testing, there needs to be an 
> upgrade path to uglify-js 3.15.0 or all of these packages need to be 
> updated. So what's your plan here?

I have no plan.  What plan might be sensible?


> > (I tried to get the package auto-kicked from testing by filing
> > release-critical bug#958117 but evidently that didn't work.)
> 
> uglifyjs is a key package, so auto-removal does not apply.

What does "key package" mean?  Simply that other packages (build-)depend 
on it, or perhaps some manually maintained list by the release team?

If the latter, then please remove src:uglifyjs as key package and 
instead treat src:uglify-js as key package.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#985072: RM: python-ceilometerclient -- ROM; Deprecated upstream

[Thomas Goirand]

On 2/11/22 06:21, Scott Kitterman wrote:

On Fri, 12 Mar 2021 15:37:02 +0100 Thomas Goirand  wrote:

Package: ftp.debian.org
Severity: normal


Hi,

It's been a few OpenStack releases that there's no ceilometer-api service in
OpenStack (only old-stable has it), and therefore, python-ceilometerclient
is deprecated upstream. These days, Ceilometer directly pushes metrics to
Gnocchi.

So, let's remove python-ceilometerclient from Sid and Bullseye before we
release.


Zigo,

What's the plan for this?  It doesn't look like the rdepends situation has
changed much in almost a year (there's even a new one):

Checking reverse dependencies...
# Broken Depends:
ceilometer: python3-ceilometer
heat: python3-heat
openstack-meta-packages: openstack-clients
vitrage-tempest-plugin: vitrage-tempest-plugin
watcher: python3-watcher

# Broken Build-Depends:
ceilometer: python3-ceilometerclient
heat: python3-ceilometerclient
watcher: python3-ceilometerclient

This is now the lowest numbered rm bug still open.  Would you please get the
rdepends sorted and then remove the moreinfo tag so we can get this done or
decide it's not going to happen and close the bug.

Thanks,

Scott K


Hi Scott,

Thanks a lot for the ping, I have to admit I forgot about this.

The last dependency issue was solved upstream (for Watcher, with patch 
at [1] merged last month), so I was able to fix all problems. I uploaded 
all fixes to Sid a few minutes ago, though maybe you need to wait until 
these are reaching testing? Please let me know.


Cheers,

Thomas Goirand (zigo)

[1] https://review.opendev.org/c/openstack/watcher/+/823606

Bug#970862: Halllo

[Heggings kate]

Hallo, ich hoffe du hast meine Nachricht erhalten.
Ich brauche schnelle Antworten
Danke.
Katie

Bug#1005335: eslint: Please update to node-regenerate-unicode-properties 10

[Yadd]

Package: eslint
Version: 6.4.0~dfsg+~6.1.9-2
Severity: wishlist
Tags: patch

Hi,

node-regenerate-unicode-properties API changed. Here is a patch to use
version 10 (pushed to experimental)

Cheers,
Yadd
diff --git a/debian/control b/debian/control
index 138fd942..ae22a9a6 100644
--- a/debian/control
+++ b/debian/control
@@ -53,7 +53,7 @@ Build-Depends:
  node-progress ,
  node-proxyquire ,
  node-recast ,
- node-regenerate-unicode-properties  ,
+ node-regenerate-unicode-properties (>= 10)  ,
  node-regexpp  ,
  node-semver ,
  node-shelljs ,
@@ -99,7 +99,7 @@ Depends:
  node-mkdirp,
  node-optionator,
  node-progress,
- node-regenerate-unicode-properties,
+ node-regenerate-unicode-properties (>= 10),
  node-regexpp,
  node-semver,
  node-strip-json-comments,
diff --git a/debian/patches/1001_use_regenerate-unicode-properties.patch 
b/debian/patches/1001_use_regenerate-unicode-properties.patch
index 5fa41188..717046e2 100644
--- a/debian/patches/1001_use_regenerate-unicode-properties.patch
+++ b/debian/patches/1001_use_regenerate-unicode-properties.patch
@@ -11,9 +11,9 @@ This patch header follows DEP-3: 
http://dep.debian.net/deps/dep3/
  
//--
  
 -const LETTER_PATTERN = require("./utils/patterns/letters");
-+const letters = 
require("regenerate-unicode-properties/General_Category/Letter.js"),
-+lettersUppercase = 
require("regenerate-unicode-properties/General_Category/Uppercase_Letter.js"),
-+lettersLowercase = 
require("regenerate-unicode-properties/General_Category/Lowercase_Letter.js");
++const letters = 
require("regenerate-unicode-properties/General_Category/Letter.js").characters,
++lettersUppercase = 
require("regenerate-unicode-properties/General_Category/Uppercase_Letter.js").characters,
++lettersLowercase = 
require("regenerate-unicode-properties/General_Category/Lowercase_Letter.js").characters;
  const astUtils = require("./utils/ast-utils");
  
  
//--
@@ -54,7 +54,7 @@ This patch header follows DEP-3: 
http://dep.debian.net/deps/dep3/
  "natural-compare": "^1.4.0",
  "optionator": "^0.8.2",
  "progress": "^2.0.0",
-+"regenerate-unicode-properties": "^1.0.0",
++"regenerate-unicode-properties": "^10.0.0",
  "regexpp": "^2.0.1",
  "semver": "^6.1.2",
  "strip-ansi": "^5.2.0",

Bug#1005321: [git-buildpackage/master] pq: Check if repo is clean before importing patches

[Guido Günther]

tag 1005321 pending
thanks

Date:   Fri Feb 11 11:35:01 2022 +0100
Author: Guido Günther 
Commit ID: 8db5af7326c581014ca07dcd98beac30f2c90d4f
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=8db5af7326c581014ca07dcd98beac30f2c90d4f
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=8db5af7326c581014ca07dcd98beac30f2c90d4f

pq: Check if repo is clean before importing patches

Closes: #1005321

  

Bug#1005197: pcmemtest: please make the build partly reproducible

[Thomas Schmitt]

Hi,

First an observation from digging in pcmemtest/1.5-2/build64/Makefile:
What about target grub-memtest.iso ?
It has its own xorriso run and EFI System Partition image.
I guess they need treatment for reproducibility, too.


Felix Zielcke wrote:
> Here's the output for the 64bit ISO:
> [...]
> │ │ │  00179000: eb3c 906d 6b66 732e 6661 7400 0204 0100 .<.mkfs.fat.
> │ │ │  00179010: 0200 0200 20f8 0600 2000 0200     ...  ...
> │ │ │ -00179020:   8000 296c 13ae 4d4d 454d 5445 ..)l..MMEMTE
> │ │ │ +00179020:   8000 29d6 8629 594d 454d 5445 ..)..)YMEMTE
> │ │ │  00179030: 5354 2d45 5350 4641 5431 3220 2020 0e1f  ST-ESPFAT12 ..
> [...]
> │ │ │ -0017aa00: 4d45 4d54 4553 542d 4553 5008  a750 MEMTEST-ESPP
> │ │ │ -0017aa10: 4b54 4b54  a750 4b54    KTKT...PKT..
> │ │ │ +0017aa00: 4d45 4d54 4553 542d 4553 5008  0951 MEMTEST-ESPQ
> │ │ │ +0017aa10: 4b54 4b54  0951 4b54    KTKT...QKT..
> │ │ │  0017aa20: 4546 4920 2020 2020 2020 2010  186a  EFI j

The clear text looks like EFI System Partition (ESP).

The byte address 0x00179000 = 1,544,192 would roughly match the end of an
ISO 9660 filesystem which only has the 1440 KiB of /boot/floppy.img as
payload.
So it would be roughly at the start of the partition in the ISO created by
  -append_partition 2 0xef ./esp.img

A partition editor listing like
  /sbin/fdisk -l memtestx64.iso
or a run of
  xorriso -indev memtestx64.iso -report_system_area plain
would tell where partition 2 begins and whether the byte addresses are
located in there.

Assumed that the differences are indeed inside partition 2:
The content of the appended partition image does not get altered by xorriso.
So i would expect that differences stem from the creation of ./esp.img.

Do i get it right from
  https://sources.debian.org/src/pcmemtest/1.5-2/build64/Makefile/#L121
that esp.img stems from
  /sbin/mkdosfs -n MEMTEST-ESP -F12 -C esp.img 4096
  mcopy -s -i esp.img iso/EFI ::
?

Assumed yes:
We see in the first difference the string "MEMTEST-ESPFAT12" which would
match the "Partition Volume Label" and "File system type" fields as of
  
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Extended_BIOS_Parameter_Block
The differing byte would then be a part of "Volume ID (serial number)".
In man mkdosfs i read
   -i volume-id
   Sets  the volume ID of the newly created filesystem; volume-id is a
   32-bit hexadecimal number (for example, 2e24ec82). The default is a
   number which depends on the filesystem creation time.

So consider to add an option -i to the mkdosfs run and give it either
a constant number or a number which gets reproducibly derived from
variable SOURCE_DATE_EPOCH.

--

The other difference could be a neighbor of "directory volume label",
which Wikipedia mentions as a kind of mirror of "Partition Volume Label".
If i get it right then this is in the name and extension fields of
a "Directory entry".
The differing bytes would then be the timestamps "Create time" at offset
0x0E and "Last Modified time" at offset 0x16. Probably the date fields at
0x10 and 0x18 could show differences, too.

But i am far off my usual playground now.
Maybe Chris already knows a good trick to enforce values for those time
and date fields in FAT filesystems.


Have a nice day :)

Thomas

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Holger Levsen]

On Fri, Feb 11, 2022 at 01:33:08PM +0100, Enrico Zini wrote:
> > However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian 
> > to
> > download upgrades for dom0, which is Fedora based. So the package is 
> > certainly
> > not unusable for everyone, thus downgrading severity...
> Fair enough: it might be just a matter of documenting that dnf cannot be
> used to boostrap an RPM-based distribution from a Debian system.

there's also " #794495 Mock fails to track installed packages" and
"#923352 RFA: rpm -- package manager for RPM" plus on I've just learned
on #qubes that Qubes has to work around the rpmdb location difference
as well...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

When this virus is over, I still want some of you all to stay away from me.


signature.asc
Description: PGP signature

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Enrico Zini]

On Fri, Feb 11, 2022 at 06:38:16AM +0100, Mihai Moldovan wrote:

> While Debian's rpm utility uses a homedir-based RPMDB, nothing else, 
> especially
> not Fedora, expects that and, since dnf uses the system-version of RPM to
> bootstrap, you'll run into exactly such issues.
> 
> I can't do anything about that, other than try to NMU a version of RPM that 
> has
> this patch removed, but that might break tools like alien and I'm not very
> interested in spending a lot of time on that.

On Fri, Feb 11, 2022 at 12:23:52PM +, Holger Levsen wrote:

> However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian to
> download upgrades for dom0, which is Fedora based. So the package is certainly
> not unusable for everyone, thus downgrading severity...

Fair enough: it might be just a matter of documenting that dnf cannot be
used to boostrap an RPM-based distribution from a Debian system.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Holger Levsen]

control: severity -1 important

On Wed, Feb 02, 2022 at 06:05:24PM +0100, Enrico Zini wrote:
> thank you for packaging dnf in Debian!

thank you for filing this bug report, Enrico! 

However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian to
download upgrades for dom0, which is Fedora based. So the package is certainly
not unusable for everyone, thus downgrading severity...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

People call vaccine mandates "Orwellian" even though Orwell died at 46 of
tuberculosis, which is now preventable with a vaccine.


signature.asc
Description: PGP signature

Bug#1005328: RM: uglifyjs/2.8.29-8

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-02-11 12:08:52 +0100, Jonas Smedegaard wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> X-Debbugs-Cc: Debian Javascript Maintainers 
> 
> 
> uglifyjs v2 was last updated upstream in 2017, and has no real
> maintainer in Debian since December 2020 - see bug#958117
> 
> The package should not be released with bookworm, but may still have
> reverse (build-)dependencies, and I therefore request removal only from
> testing for now.  Please advice if another approach is more sensible.

So this is the same request as #968137. The current situation is:

I: [2022-02-11T12:19:15+] - trying: -uglifyjs
I: [2022-02-11T12:19:15+] - skipped: -uglifyjs (0, 33, 62)
I: [2022-02-11T12:19:15+] - got: 123+0: 
a-3:a-0:a-0:a-0:i-119:m-0:m-0:p-0:s-1
I: [2022-02-11T12:19:15+] - * amd64: rails, ruby-uglifier 

If one checks with dak:

Will remove the following packages from testing:

libjs-uglify |   2.8.29-8 | all
node-uglify |   2.8.29-8 | all
  uglifyjs |   2.8.29-8 | source

Maintainer: Debian Javascript Maintainers 


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
node-dryice: node-dryice
ruby-uglifier: ruby-uglifier

# Broken Build-Depends:
angular.js: uglifyjs
asciimathtml: uglifyjs
autosize.js: uglifyjs
awesomplete: uglifyjs
backbone: uglifyjs (>= 3)
bignumber.js: uglifyjs
blockui: uglifyjs
bootsidemenu.js: uglifyjs
c3: uglifyjs
chartkick.js: uglifyjs
class.js: node-uglify
coffeescript: uglifyjs
d3: uglifyjs
d3-tip.js: uglifyjs
dask.distributed: uglifyjs
elycharts.js: uglifyjs
eonasdan-bootstrap-datetimepicker: uglifyjs
explorercanvas: uglifyjs
flightgear-phi: node-uglify
flot: uglifyjs
gettext.js: uglifyjs
gitgraph.js: uglifyjs
glowing-bear: uglifyjs
highlight.js: uglifyjs
jquery-areyousure: uglifyjs
jquery-caret.js: node-uglify
jquery-coolfieldset: node-uglify
jquery-goodies: uglifyjs
jquery-i18n.js: uglifyjs
jquery-lazyload: node-uglify
jquery-minicolors: uglifyjs
jquery-reflection: node-uglify
jquery-simpletreemenu: node-uglify
jquery-throttle-debounce: node-uglify
jquery-typeahead.js: uglifyjs
jquery-ui-touch-punch.js: uglifyjs
jquery-watermark: node-uglify
jquery.sparkline: uglifyjs
jqueryui: uglifyjs
json-js: uglifyjs (>= 3)
jsrender: uglifyjs
jstimezonedetect.js: uglifyjs
knowl.js: uglifyjs
kytos-sphinx-theme: uglifyjs
ldap-account-manager: uglifyjs
leaflet: uglifyjs (>= 3)
leaflet-geometryutil: uglifyjs
leaflet-markercluster: uglifyjs (>= 3)
lemonldap-ng: uglifyjs
libjs-autolink: uglifyjs
libjs-blazy: uglifyjs
libjs-bootbox: uglifyjs (>= 3)
libjs-chosen: uglifyjs (>= 2)
libjs-cssrelpreload: uglifyjs
libjs-dropzone: uglifyjs
libjs-jquery-center: uglifyjs
libjs-jquery-jstree: uglifyjs
libjs-jquery-markitup: uglifyjs
libjs-jquery-scrollto: uglifyjs
libjs-jquery-timeago: uglifyjs
libjs-jsxc: uglifyjs
libjs-material-design-lite: uglifyjs
libjs-qunit: uglifyjs (>= 3)
libjs-sdp: uglifyjs (>= 3)
libjs-term.js: uglifyjs
libjs-webrtc-adapter: uglifyjs (>= 3)
lightbox2.js: uglifyjs (>= 3.6.3)
modernizr: uglifyjs
moment-timezone.js: uglifyjs
mustache.js: uglifyjs
node-ansi-up: uglifyjs
node-async: uglifyjs
node-autolinker: uglifyjs
node-big.js: uglifyjs
node-bluebird: uglifyjs
node-bootstrap-tour: uglifyjs
node-browser-pack: uglifyjs
node-browserify-lite: uglifyjs
node-chart.js: uglifyjs
node-chroma-js: uglifyjs
node-deep-eql: uglifyjs
node-dryice: uglifyjs
node-es5-shim: uglifyjs
node-es6-shim: uglifyjs
node-eventemitter2: uglifyjs
node-expect.js: uglifyjs
node-fast-levenshtein: uglifyjs
node-functional-red-black-tree: uglifyjs (>= 3)
node-immutable-tuple: uglifyjs
node-imurmurhash: uglifyjs
node-inflected: uglifyjs
node-is-typedarray: uglifyjs
node-iscroll: uglifyjs
node-jsonselect: uglifyjs
node-katex: uglifyjs
node-knockout: uglifyjs
node-lodash: uglifyjs
node-lunr: uglifyjs (>= 3)
node-moment: uglifyjs
node-mousetrap: uglifyjs
node-n3: uglifyjs (>= 3)
node-nouislider: uglifyjs (>= 3.13.0)
node-pinkyswear: uglifyjs
node-q: uglifyjs
node-seedrandom: uglifyjs
node-sink-test: uglifyjs
node-sprintf-js: uglifyjs
node-stable: uglifyjs
node-turbolinks: uglifyjs
node-tweetnacl: uglifyjs
node-typedarray-to-buffer: uglifyjs
node-umd: uglifyjs
node-util: uglifyjs
node-uuid: uglifyjs
node-websocket: uglifyjs
node-with: uglifyjs
node-zrender: uglifyjs
olm: uglifyjs (>= 3)
openlayers: uglifyjs
pegjs: uglifyjs
polymake: uglifyjs
prefixfree: uglifyjs
prosody-modules: uglifyjs
pympler: uglifyjs
python-django-colorfield: uglifyjs
queue-async: uglifyjs
rainbow.js: uglifyjs
raphael: node-uglify (>= 1.1.1-2~)
requirejs: uglifyjs
requirejs-text: uglifyjs
reqwest: uglifyjs
rickshaw: uglifyjs
ruby-rails-assets-favico.js: node-uglify
ruby-rails-assets-jquery-fullscreen-plugin: node-uglify
ruby-rails-assets-perfect-scrollbar: node-uglify
ruby-uglifier: libjs-uglify
sax.js: uglifyjs
science.js: uglifyjs
select2.js: 

Bug#1005328: RM: uglifyjs/2.8.29-8

[Paul Gevers]

Hi Jonas,

On 11-02-2022 12:08, Jonas Smedegaard wrote:

(I tried to get the package auto-kicked from testing by filing
release-critical bug#958117 but evidently that didn't work.)


That would work if uglifyjs was not a key-package. We can only remove it 
if that's no longer the case, and then autoremoval will do it's work. 
Have you filed bugs with revers (build) dependencies already? It needs 
to be fixed there.


Paul

https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
- reason: jquery-throttle-debounce build-depends node-uglify
  source: uglifyjs
(Be aware, the above reason my not be the only one reason why it's in 
key packages, it's just the first that the script encountered)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999693: Re,

[Heather Williams]

How are you doing? My name is Heather Williams,, please can I have a chat
with you? Have a nice day and remain safe.

Bug#1005331: tt-rss: entries don't get automatically marked as read

[Giuseppe Bilotta]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1
Severity: normal

After a recent update, it seems entries can only get marked as read manually 
and one by one.
Entries do not get marked as read when the link is followed,
and trying to mark all the entries in a feed as read nothing happens,
even after confirming OK at the dialog.
Marking an item as read manually ('M' key) works.
Trying this with the JS log open shows no errors.
Pressing the M key results in an RPC call, while the other actions do not.

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

Kernel: Linux 5.16.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tt-rss depends on:
ii  dbconfig-common 2.0.21
ii  dbconfig-mysql  2.0.21
ii  debconf [debconf-2.0]   1.5.79
ii  fonts-material-design-icons-iconfont6.1.0+dfsg-1
ii  init-system-helpers 1.61
ii  libapache2-mod-php  2:8.1+92
ii  libapache2-mod-php8.1 [libapache2-mod-php]  8.1.2-1+b1
ii  libjs-dojo-core 1.15.4+dfsg1-1
ii  libjs-dojo-dijit1.15.4+dfsg1-1
ii  libjs-scriptaculous 1.9.0-2.1
ii  lsb-base11.1.0
ii  php 2:8.1+92
ii  php-cli 2:8.1+92
ii  php-intl2:8.1+92
ii  php-json2:8.1+92
ii  php-mbstring2:8.1+92
ii  php-mysql   2:8.1+92
ii  php-php-gettext 1.0.12-5
ii  php-psr-log 1.1.4-2
ii  php-xml 2:8.1+92
ii  php8.1 [php]8.1.2-1
ii  php8.1-cli [php-cli]8.1.2-1+b1
ii  php8.1-intl [php-intl]  8.1.2-1+b1
ii  php8.1-mbstring [php-mbstring]  8.1.2-1+b1
ii  php8.1-xml [php-xml]8.1.2-1+b1
ii  phpqrcode   1.1.4-3.1

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.52-1
ii  ca-certificates 20211016
ii  php-curl2:8.1+92
ii  php-gd  2:8.1+92
pn  php-mcrypt  
ii  php8.1-curl [php-curl]  8.1.2-1+b1
ii  php8.1-gd [php-gd]  8.1.2-1+b1

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- Configuration Files:
/etc/default/tt-rss changed:
DISABLED=0
FORKING=0

/etc/tt-rss/config.php changed:
http://tt-rss.oblomov.eu');
// This should be set to a fully qualified URL used to access
// your tt-rss instance over the net, such as: 
https://example.org/tt-rss/
// The value should be a constant string literal. Please don't use
// PHP server variables here - you might introduce security
// issues on your install and cause hard to debug problems.
// If your tt-rss instance is behind a reverse proxy, use the external 
URL.
define('SINGLE_USER_MODE', false);
// Operate in single user mode, disables all functionality related to
// multiple users and authentication. Enabling this assumes you have
// your tt-rss directory protected by other means (e.g. http auth).
define('SIMPLE_UPDATE_MODE', false);
// Enables fallback update mode where tt-rss tries to update feeds in
// background while tt-rss is open in your browser.
// If you don't have a lot of feeds and don't want to or can't run
// background processes while not running tt-rss, this method is 
generally
// viable to keep your feeds up to date.
// Still, there are more robust (and recommended) updating methods
// available, you can read about them here: 
https://tt-rss.org/wiki/UpdatingFeeds
// *
// *** Files and directories ***
// *
define('PHP_EXECUTABLE', '/usr/bin/php');
// Path to PHP *COMMAND LINE* executable, used for various command-line 
tt-rss
// programs and update daemon. Do not try to use CGI binary here, it 
won't work.
// If you see HTTP headers being displayed while running tt-rss scripts,
// then most probably you are using the CGI binary. If you are unsure 
what to
// put in here, ask your hosting provider.
define('LOCK_DIRECTORY', 

Bug#1005330: ITP:php-svg-sanitizer - SVG sanitizer for PHP

[Katharina Drexel]

Package: wnpp

* Package name: php-svg-sanitizer
  Upstream Author : Daryll Doyle 
* License : GPL-2+
  Description : SVG sanitizer in PHP.
 Attempt at building a decent SVG sanitizer in PHP.
 The work is laregely borrowed from DOMPurify.

Regards
Katharina

Bug#1005329: python3-zlmdb: ships /usr/lib/python3/dist-packages/flatbuffers/*.py

[Andreas Beckmann]

Package: python3-zlmdb
Version: 21.1.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-zlmdb_21.1.1-1_all.deb ...
  Unpacking python3-zlmdb (21.1.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-zlmdb_21.1.1-1_all.deb (--unpack):
   trying to overwrite 
'/usr/lib/python3/dist-packages/flatbuffers/__init__.py', which is also in 
package python3-flatbuffers 1.12.1~git20200711.33e2d80+dfsg1-0.6
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-zlmdb_21.1.1-1_all.deb


cheers,

Andreas


python3-flatbuffers=1.12.1~git20200711.33e2d80+dfsg1-0.6_python3-zlmdb=21.1.1-1.log.gz
Description: application/gzip

Bug#966273: Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0

[Guillem Jover]

Hi!

On Mon, 2021-02-01 at 00:06:45 +0100, Chris Hofstaedtler wrote:
> Control: reassign -1 ftp.debian.org
> Control: retitle -1 RM: fam -- RoQA; replaced by gamin; unmaintained; 
> upstream dead
> Control: tags -1 + moreinfo

> please remove fam. Upstream is long gone, and gamin is a maintained
> drop in alternative. The previous Debian maintainer of fam has
> orphaned it.

Hmm, gamin might have been maintained (at least relative to fam) at the
time it was introduced, but it does not look that way anymore, neither
upstream nor Debian TBH:

See f.ex.:

  https://gitlab.gnome.org/GNOME/glib/-/merge_requests/219
  https://bugzilla.gnome.org/show_bug.cgi?id=482704
  https://gitlab.gnome.org/Archive/gamin (archived)
  https://people.gnome.org/~veillard/gamin/sources/ (last release 2008)
  https://mail.gnome.org/archives/gamin-list/ (last mail 2016)

I think gamin should be removed from Debian too.

Thanks,
Guillem

Bug#1005197: pcmemtest: please make the build partly reproducible

[Felix Zielcke]

Am Freitag, dem 11.02.2022 um 11:41 +0100 schrieb Thomas Schmitt:
> Hi,
> 
> Felix Zielcke wrote:
> > I modifed the patch now to use --set_all_file_dates.
> 
> I wonder whether the "file list" in "data.tar.xz" of
>  
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffosc
> ope-results/pcmemtest.html
> is made from the files in the ISO or from the input files on hard
> disk.
> 
> In the latter case, it would be better to use the solution of Chris
> which enforces dates on hard disk.
> But then this solution should also enforce user id and group id
> numbers
> on hard disk.
> 
> > 
Ah ok. I can try that.

> > diffoscope still tells me some differences in the ISOs.
> 
> Is there a chance to quote some of the found differences here ?
> If it's about meta data of the ISO then i would be the person to
> decode
> them and to make first theories from where the deviations might come.
> 
> 
Here's the output for the 64bit ISO:

 │ ├── ./usr/lib/pcmemtest/memtestx64.iso
│ │ │┄ Format-specific differences are supported for ISO 9660 CD images but no 
file-specific differences were detected; falling back to a binary diff. file(1) 
reports: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'PCMemTest64' 
(bootable)
│ │ │ @@ -96508,15 +96508,15 @@
│ │ │  00178fb0:          
│ │ │  00178fc0:          
│ │ │  00178fd0:          
│ │ │  00178fe0:          
│ │ │  00178ff0:          
│ │ │  00179000: eb3c 906d 6b66 732e 6661 7400 0204 0100  .<.mkfs.fat.
│ │ │  00179010: 0200 0200 20f8 0600 2000 0200     ... ...
│ │ │ -00179020:   8000 296c 13ae 4d4d 454d 5445  ..)l..MMEMTE
│ │ │ +00179020:   8000 29d6 8629 594d 454d 5445  ..)..)YMEMTE
│ │ │  00179030: 5354 2d45 5350 4641 5431 3220 2020 0e1f  ST-ESPFAT12   ..
│ │ │  00179040: be5b 7cac 22c0 740b 56b4 0ebb 0700 cd10  .[|.".t.V...
│ │ │  00179050: 5eeb f032 e4cd 16cd 19eb fe54 6869 7320  ^..2...This 
│ │ │  00179060: 6973 206e 6f74 2061 2062 6f6f 7461 626c  is not a bootabl
│ │ │  00179070: 6520 6469 736b 2e20 2050 6c65 6173 6520  e disk.  Please 
│ │ │  00179080: 696e 7365 7274 2061 2062 6f6f 7461 626c  insert a bootabl
│ │ │  00179090: 6520 666c 6f70 7079 2061 6e64 0d0a 7072  e floppy and..pr
│ │ │ @@ -96922,16 +96922,16 @@
│ │ │  0017a990:          
│ │ │  0017a9a0:          
│ │ │  0017a9b0:          
│ │ │  0017a9c0:          
│ │ │  0017a9d0:          
│ │ │  0017a9e0:          
│ │ │  0017a9f0:          
│ │ │ -0017aa00: 4d45 4d54 4553 542d 4553 5008  a750  MEMTEST-ESPP
│ │ │ -0017aa10: 4b54 4b54  a750 4b54     KTKT...PKT..
│ │ │ +0017aa00: 4d45 4d54 4553 542d 4553 5008  0951  MEMTEST-ESPQ
│ │ │ +0017aa10: 4b54 4b54  0951 4b54     KTKT...QKT..
│ │ │  0017aa20: 4546 4920 2020 2020 2020 2010  186a  EFIj
│ │ │  0017aa30: 4954 4954  186a 4954 0200    ITIT...jIT..
│ │ │  0017aa40:          
│ │ │  0017aa50:          
│ │ │  0017aa60:          
│ │ │  0017aa70:          
│ │ │  0017aa80:          

Bug#1005328: RM: uglifyjs/2.8.29-8

[Jonas Smedegaard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: Debian Javascript Maintainers 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

uglifyjs v2 was last updated upstream in 2017, and has no real
maintainer in Debian since December 2020 - see bug#958117

The package should not be released with bookworm, but may still have
reverse (build-)dependencies, and I therefore request removal only from
testing for now.  Please advice if another approach is more sensible.

(I tried to get the package auto-kicked from testing by filing
release-critical bug#958117 but evidently that didn't work.)


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmIGQ8EACgkQLHwxRsGg
ASGcbw//TF1/n+bTOHNqo2UR5/PNAs818+b7CN2uKH+xFXSY3seSnyE95DEHng7K
2rNOTgo7Io2mOvQ2ND+vE0niPqm/p1wwFl70q1Owl0TQ4Dibw5MniXjc55wwQxX4
8wfJY3c4xlLneeiIr9+AskrqbafonDrRTxCC+NAtvTSQSBgsPdOUDPG15umHwSu3
/sx6bfsmH/LzSw6L6/yiskys3C4CfA4FYlcPdKZK+gWkmb+VWdhn1T4hRaUAN2I8
HCuJFGQns7ckb7O/RwSnOkC5ct9c00P8Y1O1kEUxkrGlBmMEq0mIvlCEP63t31Ud
ZtmJt/K4WQJ4G/IVfG4/dtcEomPGmZIn07CFEqOU9B1r++nubeCULiCa2Tc9WsmQ
eTziPFTcX24lRQ+O69ukg5G+N5WHKKu9uHYacZJa9jdS6qe5TKp07IH+BwTe4w9E
LyG8AegBAVjnJ8U68B+KWFXrdpAkcjv3En7IeU3vryUXNPsZr2b3go/Ac2XecdFX
268H9z2rlUiamWQ6bOUNW8DYRvHF7CFNlVJ0tfgyo1bLNNjKjEwCfkHsTSsXQOt5
8g0UkVc168m//PrXQlNWJLWUV4VT+p0QLQGoEC6ES6N61U0H8zVRBEu048b3DFs3
W0QBhZDHxyJUAm1MbiAnRGmzY4/dxkFs4uZmAXRU/zired3XnaM=
=40Qo
-END PGP SIGNATURE-

Bug#1005327: avahi-daemon: Incomplete (useless) messages in /var/log/daemon.log

[Rene Hogendoorn]

Package: avahi-daemon
Version: 0.8-5
Severity: normal




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

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

Versions of packages avahi-daemon depends on:
ii  adduser  3.118
ii  bind9-host [host]1:9.18.0-2
ii  dbus 1.12.20-3
ii  host 1:9.10.3.dfsg.P4-12.6
ii  init-system-helpers  1.61
ii  libavahi-common3 0.8-5
ii  libavahi-core7   0.8-5
ii  libc62.33-5
ii  libcap2  1:2.44-1
ii  libdaemon0   0.14-7.1
ii  libdbus-1-3  1.12.20-3
ii  libexpat12.4.4-1
ii  lsb-base 11.1.0

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.15.1-1

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- Configuration Files:
/etc/avahi/avahi-daemon.conf changed:
[server]
use-ipv4=yes
use-ipv6=yes
deny-interfaces=enp6s0.11
ratelimit-interval-usec=100
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
publish-hinfo=no
publish-workstation=no
publish-dns-servers=192.168.7.10
[reflector]
[rlimits]


-- no debconf information

avahi-daemon spams the /var/log/daemon.log file with frequent incomplete
(and, hence, useless) log entries.
There is no indication why they are reported and it is not apparent how
they can be disabled to prevent the spamming.
The following is an extract from /var/log/daemon.log, indicating the
problem:

Feb 11 11:26:37 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipps._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prio
Feb 11 11:26:37 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipp._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prior
Feb 11 11:26:41 arrakis named[3024855]: validating plex.tv/A: no valid 
signature found
Feb 11 11:27:26 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipps._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prio
Feb 11 11:27:26 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipp._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prior
Feb 11 11:28:16 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipp._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prior
Feb 11 11:28:19 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipps._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prio
Feb 11 11:29:06 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipp._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prior
Feb 11 11:29:07 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipps._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prio
Feb 11 11:29:12 arrakis systemd[1]: Started Session 10183 of User hogend.
Feb 11 11:29:54 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipp._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C UFR 
II" "adminurl=https://arrakis.local.:631/printers/Canon-MF645C-UFR-II; 
"note=Home" "prior
Feb 11 11:29:56 arrakis avahi-daemon[3238266]: Record 
[Canon\032MF645C\032Colour\032Laserjet\032\064\032arrakis._ipps._tcp.local#011IN#011TXT
 "txtvers=1" "qtotal=1" "rp=printers/Canon-MF645C-UFR-II" "ty=Canon MF645C 

Bug#1005200: lintian: prefer-uscan-symlink should to single maintainer packages at most

[Mattia Rizzolo]

On Tue, Feb 08, 2022 at 04:31:43PM -0500, Scott Kitterman wrote:
> As a general case, correct package updating should not depend on
> non-default local setups.

About the "non-default": while working on version=5 of d/watch, I plan
on changing defaults in a way that having no filenamemangle will save
the file using the format package_version.orig.tar.xz

Just FYI.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1005311: xserver-xorg-video-nvidia: Package has unmet dependencies

[Michael Tatge]

Package: xserver-xorg-video-nvidia
Version: 470.103.01-1
Followup-For: Bug #1005311

Dear Maintainer,

since updating today the nvidia driver package doesn't work anymore.
It depends on xserver-xorg-video-nvidia which has unmet dependencies itself.

Depends: xserver-xorg-core (< 2:1.20.99) but 2:21.1.3-2 is to be installed


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

Kernel: Linux 5.16.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xserver-xorg-video-nvidia depends on:
ii  libc6  2.33-5
ii  libnvidia-glcore   470.103.01-1
ii  nvidia-alternative 470.103.01-1
ii  nvidia-installer-cleanup   20151021+13
ii  nvidia-legacy-check470.103.01-1
ii  nvidia-support 20151021+13
pn  xorg-video-abi-24 | xorg-video-abi-23 | xorg-video-abi-20 | x  
ii  xserver-xorg-core  2:21.1.3-2

Versions of packages xserver-xorg-video-nvidia recommends:
pn  nvidia-driver  
ii  nvidia-kernel-dkms [nvidia-kernel-470.103.01]  470.103.01-1
pn  nvidia-settings
pn  nvidia-vdpau-driver

Versions of packages xserver-xorg-video-nvidia suggests:
ii  nvidia-kernel-dkms  470.103.01-1

Bug#1005287: node-csstype: Build drops "; " in typescript declarations

[Yadd]

On 11/02/2022 11:42, Yadd wrote:

On 11/02/2022 11:10, Yadd wrote:

On 11/02/2022 09:18, Julien Puydt wrote:

Le jeudi 10 février 2022 à 16:20 +0100, Yadd a écrit :

On 10/02/2022 15:38, Yadd wrote:

Package: node-csstype
Version: 3.0.10-1
Severity: grave
Justification: renders package unusable

debian/rules launches `ts-node --files build.ts --start` which
(only)
modifies indes.d.ts and index.js.flow. The result is unusable with
tsc:

    /usr/share/nodejs/csstype/index.d.ts:18305:8 - error TS1005: ';'
expected.

All final ";" are dropped.


Removing override_dh_auto_build fixes the problem (using upstream
index.d.ts and index.js.flow which are readable)

@Julien, could you take a look ?


I think the problem is that in index.d.ts we have:

   export type SvgAttributes = 

   export type Globals = 

while upstream has:

   export type SvgAttributes = 

   export type Globals = 

so the missing ';' is a red herring: we don't get the SvgAttributes
like we should, and that's the real problem.

I see that debian/nodejs/extlinks does have mdn-browser-compat-data,
but it creates node_modules/@mdn/browser-compat-data -- I don't know
why it does that, but it's what's breaking things as far a I can tell.

Do you know how to fix it?


You can push @mdn/browser-compat-data from debian/nodejs/extlinks to 
debian/nodejs/extcopies but problem existed before this change.


Tested: same problem


I used my tools to find the problem. It is in our 
mdn-browser-compat-data (hacked from @mdn/browser-compat-data) which 
differs from upstream. Build works fine with mdn-browser-compat-data 
downloaded with npm. Upstream wants this:


   "mdn-browser-compat-data": 
"git+https://github.com/mdn/browser-compat-data.git#a9a17ff717b73cb9bb7072357a080509b73e22bb; 


Found: /usr/share/nodejs/mdn-browser-compat-data is a link to 
/usr/share/nodejs/@mdn/browser-compat-data, so package.json "name" has 
bad value. This should be a directory with its package.json and links to 
@mdn/browser-compat-data files


This needs a mainscript (symlink_to_dir)

Bug#1005287: node-csstype: Build drops "; " in typescript declarations

[Yadd]

On 11/02/2022 11:10, Yadd wrote:

On 11/02/2022 09:18, Julien Puydt wrote:

Le jeudi 10 février 2022 à 16:20 +0100, Yadd a écrit :

On 10/02/2022 15:38, Yadd wrote:

Package: node-csstype
Version: 3.0.10-1
Severity: grave
Justification: renders package unusable

debian/rules launches `ts-node --files build.ts --start` which
(only)
modifies indes.d.ts and index.js.flow. The result is unusable with
tsc:

    /usr/share/nodejs/csstype/index.d.ts:18305:8 - error TS1005: ';'
expected.

All final ";" are dropped.


Removing override_dh_auto_build fixes the problem (using upstream
index.d.ts and index.js.flow which are readable)

@Julien, could you take a look ?


I think the problem is that in index.d.ts we have:

   export type SvgAttributes = 

   export type Globals = 

while upstream has:

   export type SvgAttributes = 

   export type Globals = 

so the missing ';' is a red herring: we don't get the SvgAttributes
like we should, and that's the real problem.

I see that debian/nodejs/extlinks does have mdn-browser-compat-data,
but it creates node_modules/@mdn/browser-compat-data -- I don't know
why it does that, but it's what's breaking things as far a I can tell.

Do you know how to fix it?


You can push @mdn/browser-compat-data from debian/nodejs/extlinks to 
debian/nodejs/extcopies but problem existed before this change.


Tested: same problem


I used my tools to find the problem. It is in our 
mdn-browser-compat-data (hacked from @mdn/browser-compat-data) which 
differs from upstream. Build works fine with mdn-browser-compat-data 
downloaded with npm. Upstream wants this:


  "mdn-browser-compat-data": 
"git+https://github.com/mdn/browser-compat-data.git#a9a17ff717b73cb9bb7072357a080509b73e22bb;


Cheers,
Yadd

Bug#1005197: pcmemtest: please make the build partly reproducible

[Thomas Schmitt]

Hi,

Felix Zielcke wrote:
> I modifed the patch now to use --set_all_file_dates.

I wonder whether the "file list" in "data.tar.xz" of
  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffosc
ope-results/pcmemtest.html
is made from the files in the ISO or from the input files on hard disk.

In the latter case, it would be better to use the solution of Chris
which enforces dates on hard disk.
But then this solution should also enforce user id and group id numbers
on hard disk.


> diffoscope still tells me some differences in the ISOs.

Is there a chance to quote some of the found differences here ?
If it's about meta data of the ISO then i would be the person to decode
them and to make first theories from where the deviations might come.


Have a nice day :)

Thomas

Bug#1005324: ITP: valgrind-if-available -- dependency package to pull in Valgrind if it's available

[Adam Borowski]

On Fri, Feb 11, 2022 at 10:58:26AM +0100, Ansgar wrote:
> On Fri, 2022-02-11 at 10:37 +0100, Adam Borowski wrote:
> >  This metapackage installs Valgrind on architectures where it is
> > available.
> >  As the list of archs where Valgrind works changes quite often,
> 
> The list is the same for all of oldoldstable, oldstable, stable,
> testing and unstable though:
> 
> +---
> | valgrind   | 1:3.12.0~svn20160714-1+b1 | oldoldstable| amd64, arm64, 
> armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> | valgrind   | 1:3.14.0-3| oldstable   | source, amd64, 
> arm64, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> | valgrind   | 1:3.16.1-1| stable  | source, amd64, 
> arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x
> | valgrind   | 1:3.18.1-1| testing | source, amd64, 
> arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x
> | valgrind   | 1:3.18.1-1| unstable| source, amd64, 
> arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x
> +---
> 
> So this would just be "Depends: valgrind" on all architetures?

There's no armel on your lists.

There's no support for most -ports archs, including riscv64 which is
supposed to be released with bookworm.

And x32 is on valgrind's archs list but fails to build.

We also had valgrind quite broken on some archs due to a glibc update, with
no fix for a year (any threaded program segfaulted).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk,
⣾⠁⢠⠒⠀⣿⡁   ash nazg gimbatul,
⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk
⠈⠳⣄   agh burzum-ishi krimpatul.

Bug#1005326: no-code-sections triggered on non-ELF files

[duck]

Package: lintian
Version: 2.114.0


Quack,

no-code-sections is triggered on dxvk, and also on wine, but these are 
not ELF files since it's targeted for Windows. Of course an override is 
possible but here there's an obvious way to avoid a false positive since 
readelf fails with "readelf: Error: Not an ELF file - it has the wrong 
magic bytes at the start", or maybe by using `objdump -a` or some other 
method to first check the archive format (I'm really not an expert in 
this area). Could you consider improving the check?


Regards.
\_o<

--
Marc Dequènes

Bug#991384: libwine-development fails to install on arm*: head: cannot open '/usr/aarch64-w64-mingw32/lib/zlib*.dll' for reading: No such file or directory

[duck]

Quack,

Could you have a look at this bug please?
I'm trying to fix cross-compilation problems on dxvk but cannot even get 
a test build to run because of this issue:

  https://salsa.debian.org/aviau/dxvk/-/jobs/2455425

Regards.
\_o<

--
Marc Dequènes

Bug#1005197: pcmemtest: please make the build partly reproducible

[Felix Zielcke]

Am Donnerstag, dem 10.02.2022 um 16:24 -0800 schrieb Chris Lamb:
> Hi Thomas,
> 
> > > Have you had a look at the diffoscope output after this patch is
> > > applied?
> > 
> > Where can a curious bystander get that look ?
> 
> I was referring to a hypothetical diff that you might generate
> locally; updating the result on tests.reproducible-builds.org would
> require a new upload. :)
> 
> > i see in the isoinfo output only differences of user id, group id,
> > and timestamps of /boot and /boot/floppy.img.
> [...]
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1005197;filename=pcmemtest.diff.txt;msg=5
> > should fix both.
> 
> It perhaps should, but alas it does not. When I apply my patch, the
> user ID, group ID and timestamp differences do disappear for me too,
> but that is not the only difference I see. I mean, hence why I said
> that my patch "does not make the ISOs entirely reproducible; there is
> another part or parts of the image that elude me right now". :)
> 
> I wouldn't jump to the conclusion that it is a bug in xorriso just
> yet. It might be reproducible for you locally, but it is likely I am
> varying more things between my two builds. And even more on
> tests.reproducible-builds.org.
> 
> The next step might be to upload with this patch so we can both work
> with the same output on tests.reproducible-builds.org.
> 
> >   --set_all_file_dates "=$SOURCE_DATE_EPOCH"
> 
> Ah, neat. :)  Yes, of course, feel free to use this over touch(1).
> 
> 

Hi Thomas and Chris,

thanks very much for your efforts.
I modifed the patch now to use --set_all_file_dates.

diffoscope still tells me some differences in the ISOs. I built it
multiple times with cowbuilder.

As soon as it migrated to bookworm I'll do an upload with the patch.

Regards,
Felix