Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Wed, Oct 06, 2021 at 10:37:25AM +0100, Simon McVittie wrote:
> I was under the impression that debianutils is (intended to be)
> a Debian-specific package with no separate upstream existence. Does
> it have releases other than "whatever is in unstable"? Is there an

Yes, one of the many changes that was on hold until the bullseye
release was addressing a (non-deb) downstream request to provide
signed tarballs[0].

> upstream maintainer distinct from its Maintainer and Uploaders, namely
> you and Manoj?

For now it is I.

> "debianutils should consist of utilities maintained in debianutils"
> seems slightly circular. Is there an intended scope for what's in
> debianutils, beyond "things that need to be Essential because they
> always used to be Essential"?

I think that you may have misparsed my sentence.

> I see that CONTRIBUTING documents some of the utilities in debianutils
> as being unsupported/pending deprecation, such that if new features are
> desired, contributors are asked to instead fork the utility and coordinate
> removal from debianutils (and presumably takeover by a new package, given
> their Essential status). Can we infer the utilities you want to continue to
> maintain are everything not on that list?

I would say more that the set of utilities I think should remain in
debianutils for the time being for one reason or another is everything
not on that list.

> debianutils currently has:
> 
> - add-shell, remove-shell, update-shells: Debian-specific(?)
>   maintainer-script infrastructure for maintaining /etc/shells,
>   analogous to how init-system-helpers maintains system services.
>   Clearly at least transitively Essential, because if they were a
>   separate package, the Essential dash and bash would depend on them.

It is my hope that update-shells will obsolete add-shell and remove-shell
as well.

> - ischroot, run-parts, savelog, which (and historically tempfile):
>   these seem more like general-purpose utilities than anything else,
>   and Essential from their wide use without an explicit dependency?
>   Of these, CONTRIBUTING describes ischroot, savelog and which as being
>   unsupported (deprecated or pending deprecation) but presumably
>   run-parts is not in that category?

run-parts is special in that it is roughly feature-complete and, as
far as I am aware, there are no extant alternatives other than Red
Hat's "fork" of debianutils run-parts as a shell script.  I could be
convinced that it shouldn't be Essential though.

ischroot is pretty flawed and I continually regret acquiescing to its
incorporation.  savelog is garbage, but is, as you point out, used by
dpkg.  which was only important for maintainer scripts when POSIX only
specified alternatives like `type` and `command -v` in optional
extensions.  Now which is only important to people using bash, it seems.

>   CONTRIBUTING calls out logrotate as being better than savelog, but
>   savelog gets used by Essential packages like dpkg, and I don't think
>   logrotate is necessarily suitable to be transitively Essential.

I don't have an opinion on that, but if dpkg wants to subsume savelog,
that would be fine by me.

> Yes, and in general I think that direction is fine, as long as the
> transition away from these utilities being in debianutils is done carefully.
> 
> mktemp and readlink were taken over by Essential coreutils, with
> a transitional Pre-Depends; sensible-* were moved to non-Essential
> sensible-utils, with a transitional Depends (making sensible-utils
> transitively Essential for one release) to ensure existing systems didn't
> lose them, and presumably some reasonable plan to ensure that dropping
> them from the Essential set wouldn't break existing packages.

I can't comment on the reasonableness of the plan, as I had nothing to
do with it.

> `command -v` is not always a valid substitute for which(1). For example,
> when Flatpak's test suite builds a tiny container that includes /bin/sh
> and /usr/bin/echo, it can't use `command -v echo` because that would
> find shell builtins as higher-precedence than their ordinary executable
> equivalents. In Flatpak's case, the test happens to be a bash script
> and so can use `command -P echo` or `type -P echo`, but those are
> bash-specific and not always available in a POSIX shell.

Originally, I avoided specifying a particular alternative in the
deprecation warning because the appropriate substitute does indeed
depend on what the user is trying to do.

> None of this implies that what we might call "debianutils upstream" needs
> to be responsible for which(1) and tempfile(1) *forever*; but removing
> functionality from Essential is disruptive, so I think the maintainers
> of debianutils *in Debian* (in practice the same people?)  have a
> responsibility to ensure that debianutils.deb either continues to provide
> the Essential functionality of previous versions, or pulls in a version
> of some transitively-Essential package that takes over the Essential
> 

Bug#996611: /usr/bin/firefox: when starting firefox after my latest dist-upgrade I get a warning about /usr/bin/which

[Johan Laenen]

Package: firefox-esr
Version: 91.2.0esr-1
Severity: minor
File: /usr/bin/firefox
X-Debbugs-Cc: johan.laenen+debianb...@gmail.com

Dear Maintainer,

when starting firefox from the command line I get a warning about
/usr/bin/which:

gargle@msi:~$ firefox &
[1] 1288
gargle@msi:~$ /usr/bin/which: this version of `which' is deprecated; use
`command -v' in scripts instead.

firefox starts without a problem.  I didn't expect this warning.


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.5-1
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-9
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgtk-3-0   3.24.30-3
ii  libnspr4 2:4.32-1
ii  libnss3  2:3.70-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-9
ii  libvpx6  1.10.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.4-6+b2

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6.1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-8
ii  libgssapi-krb5-2   1.18.3-7
ii  pulseaudio 15.0+dfsg1-2

-- no debconf information

Bug#996610: RM: cantor/experimental -- ROM; NVIU

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove cantor from experimental: it is a version older than what
is available in unstable now, and it was not automatically removed
(dunno why).

Thanks,
-- 
Pino

Bug#996362: ruby-raindrops: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed.

[Eric Wong]

Antonio Terceiro  wrote:
> Source: ruby-raindrops
> Version: 0.19.0-2
> > ===
> > Error: test_unix(TestLinux): TypeError: no implicit conversion of Hash into 
> > Integer
> > /<>/debian/ruby-raindrops/usr/lib/ruby/vendor_ruby/raindrops/linux.rb:60:in
> >  `read'
> > /<>/debian/ruby-raindrops/usr/lib/ruby/vendor_ruby/raindrops/linux.rb:60:in
> >  `unix_listener_stats'
> > /<>/test/test_linux.rb:26:in `test_unix'

This is fixed in raindrops v0.19.1 (2020-01-08):
https://yhbt.net/raindrops-public/20200108093633.GA30847@dcvr/

And v0.19.2 (2021-05-25) fixes compatibility with GC.compact:
https://yhbt.net/raindrops-public/20210525233405.GA6904@dcvr/

Bug#996604: linux-image-5.14.0-3-amd64: atheros eeprom country ignored and set to "unset"

[Adrien CLERC]

Package: src:linux
Version: 5.14.12-1
Severity: normal

Hi,

After upgrading from linux-image-5.10.0-8-amd64, my access point stopped 
working on the 5GHz band. It seems that the EEPROM country is ignored, 
or misunderstood by the kernel. I have the following at module load:


oct. 15 23:42:21 belette64 kernel: ath: EEPROM regdomain: 0x21
oct. 15 23:42:21 belette64 kernel: ath: EEPROM indicates we should 
expect a direct regpair map

oct. 15 23:42:21 belette64 kernel: ath: Country alpha2 being used: BB
oct. 15 23:42:21 belette64 kernel: ath: Regpair used: 0x21

However, here is the output of "iw reg get":

global
country 00: DFS-UNSET
    (2402 - 2472 @ 40), (N/A, 20), (N/A)
    (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
    (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
    (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
    (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
    (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
    (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
    (57240 - 63720 @ 2160), (N/A, 0), (N/A)

phy#0
country 99: DFS-UNSET
    (2402 - 2472 @ 40), (N/A, 20), (N/A)
    (5140 - 5360 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
    (5715 - 5860 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN

For phy0 the country is set to 99, leading to non-IR on all 5GHz bands. 
Since user defined country can only be more restrictive, and not more 
permissive, I thus can't have an AP on this band.


In linux-image-5.10.0-8-amd64 I get exactly the same output at module 
loading, but "iw reg get" reports:


global
country FR: DFS-ETSI
    (2400 - 2483 @ 40), (N/A, 20), (N/A)
    (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
    (5725 - 5875 @ 80), (N/A, 13), (N/A)
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0
country BB: DFS-FCC
    (2402 - 2482 @ 40), (N/A, 20), (N/A)
    (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
    (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
    (5735 - 5835 @ 80), (N/A, 30), (N/A)

Thus the physical country is set accordingly to the EEPROM.

Switching between both kernels without changing anything else (i.e. 
/lib/firmware/regulatory.db is exactly the same for both kernels).


I have no clue for now. Feel free to make me test something.


Have a nice day,

Adrien


-- Package-specific info:
** Version:
Linux version 5.14.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.3.0-11) 10.3.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP 
Debian 5.14.12-1 (2021-10-14)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.14.0-3-amd64 
root=UUID=e9729b58-f4f0-42f5-8c74-11d093341df7 ro quiet zswap.enabled=1 
zswap.max_pool_percent=25


** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

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

** Model information
sys_vendor:
product_name:
product_version:
chassis_vendor:
chassis_version:
bios_vendor: American Megatrends Inc.
bios_version: 4.6.4
board_vendor:
board_name:
board_version:

** Loaded modules:
ath9k
ath9k_common
ath9k_hw
ath
mac80211
cfg80211
libarc4
tcp_diag
udp_diag
inet_diag
dm_mod
nft_reject_inet
nf_reject_ipv4
nf_reject_ipv6
nft_reject
rfcomm
binfmt_misc
sctp
ip6_udp_tunnel
udp_tunnel
bridge
stp
llc
nft_objref
nft_ct
nft_redir
nft_nat
cmac
algif_hash
ecb
algif_skcipher
af_alg
bnep
uas
usb_storage
btusb
btrtl
btbcm
btintel
bluetooth
nft_counter
jitterentropy_rng
sha512_ssse3
hid_generic
sha512_generic
ctr
drbg
ansi_cprng
ecdh_generic
ecc
nft_chain_nat
usbhid
hid
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
snd_hda_intel
snd_intel_dspcfg
snd_intel_sdw_acpi
iTCO_wdt
at24
intel_pmc_bxt
snd_hda_codec
iTCO_vendor_support
watchdog
gma500_gfx
evdev
snd_hda_core
snd_hwdep
drm_kms_helper
ehci_pci
snd_pcm
uhci_hcd
ehci_hcd
intel_powerclamp
i2c_i801
r8169
cec
snd_timer
coretemp
pcspkr
sg
i2c_smbus
snd
rc_core
e1000
realtek
usbcore
mdio_devres
serio_raw
rfkill
lpc_ich
libphy
i2c_algo_bit
usb_common
soundcore
battery
nf_tables
video
button
nf_nat_rtsp(OE)
nf_nat
nf_conntrack_rtsp(OE)
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
nfsd
drm
nfnetlink
auth_rpcgss
nfs_acl
lockd
overlay
grace
fuse
sunrpc
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
ahci
libahci
libata
psmouse
scsi_mod
fan


** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
13: wlp1s0:  mtu 1500 qdisc noqueue state DOWN 
group default qlen 1000

    link/ether f8:1a:67:09:a3:44 brd 

Bug#996597: linux-image-5.10.0-9-amd64: OS boot does not complete successfully

[ilmarranen]

Package: linux-image-5.10.0-9-amd64
Version: 5.10.70-1
Severity: normal
X-Debbugs-Cc: alex.ilmar4s...@mail.ru

Dear Maintainer, after upgrade to linux-image-5.10.0-9 OS stuck before run GUI 
on tty1.
SDDM service status is running without errors, but not starting in tty7.
Rollback to 5.10.0-8 complitely solved the problem.
Syslog and kernel.log does not contain significant (new for my
installation) errors.

I am ready to provide additional information, since I do not know where to 
start looking for the source of the problem.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 linux-image-5.10.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-9-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-9-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.04-20
pn  linux-doc-5.10  

Bug#983505: Help progress for doas persistence

[Ryan Kavanagh]

On Sat, Oct 16, 2021 at 01:42:49AM +0100, Scupake wrote:
> I do intend to upload it soon, [...] I will try to contact
> them tommorow

OK. I'm happy to sponsor the package if that doesn't work out.

Best,
Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A

Bug#985187: Patch to remove build path from tools/cl2c

[Vagrant Cascadian]

The attached patch removes build paths from the resulting binaries,
which makes it easier to verify the reproducibility of a build without
needing to know the path from which it was originally built.

I ran "make fate" with and without the patch applied, and all of the
tests that passed as of commit 3cc3f5de2afda5b8f880c0817e9d67c2dafbfe1e
still passed (fate-sws-slice-yuv422-12bit-rgb48 and
fate-sws-slice-bgr0-nv12 both failed regardless of weather the patch was
applied).

This was originally reported at https://bugs.debian.org/985187

With this change applied, the ffmpeg package in Debian should build
reproducibly:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ffmpeg.html


Thanks for maintaining and developing ffmpeg, it is a very useful tool!


live well,
  vagrant
From b86db13adc6a27337cd93af174356d80ead1a5a9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 13 Mar 2021 03:52:51 +
Subject: [PATCH 1/1] tools/cl2c: Strip full path from input file in embedded
 output.

Without this patch, the full build path gets embedded into various
binaries shipped in the package, for example, libavfilter.a contains
a reference to:

  #line 1 "/build/1st/ffmpeg-4.3.2/libavfilter/opencl/avgblur.cl"

By not embedding the build path, it makes it easier to recreate the
build environment and reproduce the build:

  https://reproducible-builds.org/docs/build-path/

Originally submitted to Debian as:

  https://bugs.debian.org/985187

Signed-off-by: Vagrant Cascadian 
---
 tools/cl2c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/cl2c b/tools/cl2c
index e3f92bab1c..48444e61a7 100755
--- a/tools/cl2c
+++ b/tools/cl2c
@@ -23,11 +23,13 @@ input="$1"
 output="$2"
 
 name=$(basename "$input" | sed 's/.cl$//')
+# Avoid embedded the build path, using only the basename of the input file.
+base_input=$(basename "$input")
 
 cat >$output <

signature.asc
Description: PGP signature

Bug#994538: dh-python: alias /usr/bin/python disappears after installation

[Stefano Rivera]

tag -1 + moreinfo

Hi Jérémie (2021.09.17_05:08:02_-0700)
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

Please include *something* to explain what happened, otherwise we'll
close this bug.
The questions in the template above would be the things to answer.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#983505: Help progress for doas persistence

[Scupake]

Hello,

Yes, I do intend to upload it soon, last time I contacted my sponsor
they couldn't upload it due to being on vacation, I will try to contact
them tommorow

-- 
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#996609: ITP: gtksourceview5 -- shared libraries for the GTK4 syntax highlighting widget

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: jer...@bicha.net

Package Name: libgtksourceview-5-0
Version: 5.2.0
Upstream Author: Many GNOME developers
License: LGPL-2.1+
Programming Lang: C

Description: Shared libraries for the GTK4 syntax highlighting widget
 GtkSourceView is a text widget that extends the standard GTK 4 text widget
 GtkTextView. It improves GtkTextView by implementing syntax highlighting
and
 other features typical of a source editor.
 .
 This package contains the shared libraries required by applications to use
 this widget.

Other Info
--
This library will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/gtksourceview5

gtksourceview5 is for GTK4 apps
gtksourceview4 is for GTK3 apps
gtksourceview3 is an older library for GTK3 apps. GTK3 apps should switch
to gtksourceview4 soon
gtksourceview2 was for GTK2 apps and has recently been removed from Debian
Unstable.

References
---
https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview-5.0/porting-guide-3-to-4.html

https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview-5.0/porting-guide-4-to-5.html

And since you'll need to port from GTK3 to GTK4 to use gtksourceview5:
https://docs.gtk.org/gtk4/migrating-3to4.html

Thanks,
Jeremy Bicha

Bug#996592: RFS: workflow/0.9.8-1 [ITP] -- Parallel computing and asynchronous web server engine

[Lance Lin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: workflow
   Version : 0.9.8-1
   Upstream Author : Li Yingxin 
 * URL : https://github.com/sogou/workflow * License : 
Apache-2.0
 * Vcs : https://salsa.debian.org/debian/workflow Section : 
libs

It builds those binary packages:

  libworkflow1 - Parallel computing and asynchronous web server engine
  libworkflow-dev - Parallel computing and asynchronous web server engine

To access further information about this package, please visit the following 
URL: https://mentors.debian.net/package/workflow/ Alternatively, one can 
download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/w/workflow/workflow_0.9.8-1.dsc 
Changes for the initial release:

 workflow (0.9.8-1) unstable; urgency=medium
 .
   * debian/patches/*: Removed online tests
   * debian/rules: Removed temporary skipping of make check
   * debian/control: Added libworkflow-dev
   * debian/rules: Removed unused comment line
   * Added install files
   * Initial release (Closes: #995460)

Regards,

Lance Lin 

GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

signature.asc
Description: OpenPGP digital signature

Bug#996608: linux-source-5.10: Mising dependency: dwarves

[Elliott Mitchell]

Package: linux-source-5.10
Version: 5.10.70-1

SSIA.  Debian's 5.10 configuration will NOT build without the "dwarves"
package (`pahole`).  In light of this some package, likely
linux-source-5.10 should recommend "dwarves".


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#996607: transition: mutter and GNOME Shell 41 (libmutter-9)

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
Forwarded: https://release.debian.org/transitions/html/auto-mutter.html

I know it only seems like yesterday that we did the mutter 40 transition;
but it was delayed by a few months by the freeze, and a GNOME release
cycle is only 6 months long, so it's already time for the next major
release. This is staged in experimental, and is not entangled with
other packages like evolution-data-server, gsettings-desktop-schemas
and libgweather this time round.

As usual this will require sourceful uploads of:

* mutter
* gnome-shell
* gnome-shell-extensions
* budgie-desktop (non-GNOME-team but the maintainer is usually very quick,
  and has already uploaded a suitable version to experimental)

and then updates or removal for most Shell extensions.

Tracker: https://release.debian.org/transitions/html/auto-mutter.html

I already did some mass-bug-filing for extensions, tracked by
.
Some are already fixed in experimental, or even in unstable for extensions
that happen to be compatible with both 40 and 41. Many of the rest were
already autoremoved from testing due to incompatibility with Shell 40.

smcv

Bug#996606: linux: leftovers on purge of linux-image-5.*

[Christoph Anton Mitterer]

Source: linux
Version: 5.14.12-1
Severity: normal


Hey.


There are some leftovers when purging:
Purging configuration files for linux-image-5.14.0-2-amd64 (5.14.9-2) ...
rmdir: failed to remove '/lib/modules/5.14.0-2-amd64': Directory not empty
dpkg: warning: while removing linux-image-5.14.0-2-amd64, directory 
'/lib/modules/5.14.0-2-amd64' not empty so not removed

# find /lib/modules/5.14.0-2-amd64
/lib/modules/5.14.0-2-amd64
/lib/modules/5.14.0-2-amd64/updates
/lib/modules/5.14.0-2-amd64/updates/dkms
/lib/modules/5.14.0-2-amd64/updates/dkms/openafs.ko



Maybe that needs to be assigned to dkms or the openafs packages,
but one could also say that perhaps the linux-image-5.* package
should simply forcibly delete everything in the modules dir on purge.

So please reassign as you think it's appropriate :-)


Thanks,
Chris.

Bug#996605: ITP: r-cran-susier -- Sum of Single Effects Linear Regression

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-susier -- Sum of Single Effects Linear Regression
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-susier
  Version : 0.11.42
  Upstream Author : Gao Wang
* URL : https://cran.r-project.org/package=susieR
* License : MIT
  Programming Lang: GNU R
  Description : Sum of Single Effects Linear Regression
 Implements methods for variable selection in linear
 regression based on the "Sum of Single Effects" (SuSiE) model, as
 described in Wang et al (2020) . These methods
 provide simple summaries, called "Credible Sets", for accurately
 quantifying uncertainty in which variables should be selected.
 The methods are motivated by genetic fine-mapping applications,
 and are particularly well-suited to settings where variables are
 highly correlated and detectable effects are sparse. The fitting
 algorithm, a Bayesian analogue of stepwise selection methods
 called "Iterative Bayesian Stepwise Selection" (IBSS), is simple
 and fast, allowing the SuSiE model be fit to large data sets
 (thousands of samples and hundreds of thousands of variables).

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

Bug#995883: ITP: python-npx -- extensions for NumPy

[Drew Parsons]

On 2021-10-07 18:04, Drew Parsons wrote:

Package: wnpp

...

* Package name: python-npx
  Version : 0.0.20
* URL : https://github.com/nschloe/npx




https://salsa.debian.org/python-team/packages/python-npx

waiting for numpy 1.20

Bug#996581: Unnecessarry syslog message on rootless exim4 shutdown

[IB Development Team]

Package: exim4-daemon-heavy
Version: 4.94.2-7

When stopping (i.e. with "kill -SIGTERM ") rootless exim4 
(run with uid/gid 1234/1234), syslog message is generated


   exim: only uid=0 or uid=101 can use -oP and -oPX (uid=1234 euid=1234 
| 1234)


even if this process was started without -oP/-oPX, with just

   /usr/sbin/exim -bdf -q5m

No such problem with identical exim4 config in buster 
(exim4-daemon-heavy 4.92-8+deb10u6).


--
Regards,
Paweł Bogusławski

IB Development Team
E: d...@ib.pl

Bug#996603: urlscan: Recommends libcanberra-gtk3-module for no obvious reason

[Simon McVittie]

Package: urlscan
Version: 0.9.5-1
Severity: normal

While discussing a system integration issue involving libcanberra-gtk3-module
and Flatpak, I was surprised to find that urlscan has a Recommends on
libcanberra-gtk3-module. This is a GtkModule that looks for GTK events
such as windows closing, modal dialogs appearing, etc. and generates sound
events for them, each of which can optionally be associated with a sound
effect via a theme.

urlscan doesn't seem to have anything to do with GTK, or GUIs, or anything
that would involve sounds at all. What is this Recommends for? I can't
see any reason why urlscan would want even a Suggests on
libcanberra-gtk3-module.

I see this has been queried before, in #813456, where Tavis Ormandy
suggested that this might have been a copy-and-paste error. The dependency
seems to have been added in 0.8.2-1, without any mention in the changelog,
by a maintainer who did one upload and then abandoned the package; the
only change since then was to reduce it from a Depends to a Recommends
for #813456.

smcv

Bug#996602: meld: is the dependency on libcanberra-gtk3-module genuinely useful?

[Simon McVittie]

Package: meld
Version: 3.20.4-1
Severity: wishlist

While discussing a system integration issue involving libcanberra-gtk3-module
and Flatpak, I was surprised to find that meld Depends on
libcanberra-gtk3-module. This is a GtkModule that looks for GTK events
such as windows closing, modal dialogs appearing, etc. and generates sound
events for them, each of which can optionally be associated with a sound
effect via a theme.

I'm slightly confused that event sounds are considered more important for
a graphical diff viewer than for any other random GUI application. I could
understand something like a chat app wanting audible alerts, but unless
meld has functionality I was not previously aware of, it isn't clear to me
why sounds would be particularly desirable there?

Is this dependency really needed, or could it be reduced to a Recommends
or Suggests, or dropped completely? I would have expected meld to not have
this dependency at all, not even at Suggests level.

The dependency was added when replacing meld 1.x (GTK 2) with meld 3.x
(GTK 3):

>   * Update dependencies to use GTK 3 libraries and GObject introspection,
> namely libgtk-3-0, python-gi, libgtksourceview-3.0-1,
> gir1.2-gtksource-3.0, python-gi-cairo and libcanberra-gtk3-module

but in the GTK 2 version, the only dependencies were python-gtk2,
python-glade and python-gobject-2, with additional Recommends on
python-gnome2, python-gconf and python-gtksourceview2. None of those
seem like things that should have pulled in libcanberra-gtk-module,
which was the GTK 2 equivalent of libcanberra-gtk3-module, so I'm not
sure where that dependency came from?

smcv

Bug#996601: bullseye-pu: package libdatetime-timezone-perl/1:2.47-1+2021d

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.47-1+2021d to bullseye,
with the data from the Olson db release 2021 as a quilt patch.

Manually stripped debdiff attached.

IIUIC, the change for Fiji DST is effective in about a month, so
there's no immediate hurry, but at some point this might be material
for -updates and/or the next point release.

Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmFqAspfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYnQA/+JM3oT21eO6oXV65NaO5xxQ2u1WgSj/ieWrZUPz3i+B7Os7g7xGxhA5DD
eEbwpGK0wtwk66dNy6v2xoDcdJn+ydGt4f9YapcdW3X1a8ZvUGfrkuXol+PWs761
08uxL6/glt05Mdix5nJVXWWkscWDuZQJ3ooqg5mqFWy4L/KpqSxqEESFLO2Jp5os
UBGccntePeBjQ451MyHLM4dr8mBKOQItrq/u5aE9mYwxEZjF8fHPH8lgWQVNK9fB
gXRvMoNDb6ERusp/kal8bpBTSUKkl/6dOJXQ8gUZKCUd/DobBnxYhiUnkPGU7772
+F0ShOXiFJ6VSWdDuA31fjrTZ++uUhG0Hl3qbQhrlXLW5bQKhydWX2wHhNUJNPIZ
uUUC5o6mxTgQwok2+CSk7GVEOs7YGl0O285sZUcu4hEJtWabyE71msTFMmynUePr
mqVYSHbFqcUYbwwyXMYUlzEygqdJCueOExVaGF+erFXpbmSSFrBGpPGsa3pDfVRm
EGjJVhJoO1oyjNgKz2s46FR7CSqB7Es4tVAnnADxc1nz3i5DCru/umEpCXtxgoay
wGZU7OrKoxmZJPTN8/Cb/6lZd+XvSc/7AeORXnqKULjWy8EOyJmFONvsiK4gWaZ8
15jzToAAKpK0bZmwxYWYAO4W+QK9i7HQXH8xX2fcQzCAso13CnU=
=FseV
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.47/debian/changelog 
libdatetime-timezone-perl-2.47/debian/changelog
--- libdatetime-timezone-perl-2.47/debian/changelog 2021-09-28 
12:45:47.0 +0200
+++ libdatetime-timezone-perl-2.47/debian/changelog 2021-10-16 
00:14:43.0 +0200
@@ -1,3 +1,11 @@
+libdatetime-timezone-perl (1:2.47-1+2021d) bullseye; urgency=medium
+
+  * Update to Olson database version 2021d.
+This update includes fixes for the zone links for Atlantic/Jan_Mayen and
+America/Virgin (2021c), and contemporary changes for Fiji (2021d).
+
+ -- gregor herrmann   Sat, 16 Oct 2021 00:14:43 +0200
+
 libdatetime-timezone-perl (1:2.47-1+2021b) bullseye; urgency=medium
 
   * Update to Olson database version 2021b.
diff -Nru libdatetime-timezone-perl-2.47/debian/patches/olson-2021d 
libdatetime-timezone-perl-2.47/debian/patches/olson-2021d
--- libdatetime-timezone-perl-2.47/debian/patches/olson-2021d   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/patches/olson-2021d   2021-10-16 
00:14:43.0 +0200
@@ -0,0 +1,7084 @@
+Description: Update to Olson DB 2021d
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2021-10-16
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2021b
++# Generated from debian/tzdata/africa.  Olson data version 2021d
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2021b'}
++sub olson_version {'2021d'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Pacific/Fiji.pm
 b/lib/DateTime/TimeZone/Pacific/Fiji.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/australasia.  Olson data version 2021b
++# Generated from debian/tzdata/australasia.  Olson data version 2021d
+ #
+ # Do not edit this file directly.
+ #
+@@ -286,26 +286,8 @@
+ ],
+ [
+ 63746488800, #utc_start 2021-01-16 14:00:00 (Sat)
+-63772495200, #  utc_end 2021-11-13 14:00:00 (Sat)
+-63746532000, #  local_start 2021-01-17 02:00:00 (Sun)
+-63772538400, #local_end 2021-11-14 02:00:00 (Sun)
+-43200,
+-0,
+-'+12',
+-],
+-[
+-63772495200, #utc_start 2021-11-13 14:00:00 (Sat)
+-63777938400, #  utc_end 2022-01-15 14:00:00 (Sat)
+-63772542000, #  local_start 2021-11-14 03:00:00 (Sun)
+-63777985200, #local_end 2022-01-16 03:00:00 (Sun)
+-46800,
+-1,
+-'+13',
+-],
+-[
+-63777938400, #utc_start 2022-01-15 14:00:00 (Sat)
+ 63803944800, #  utc_end 2022-11-12 14:00:00 (Sat)
+-63777981600, #  local_start 2022-01-16 02:00:00 (Sun)
++63746532000, #  local_start 2021-01-17 02:00:00 (Sun)
+ 63803988000, #local_end 2022-11-13 02:00:00 (Sun)
+ 43200,
+ 0,
+@@ -493,9 +475,9 @@
+ ],
+ ];
+ 
+-sub olson_version {'2021b'}
++sub olson_version {'2021d'}
+ 
+-sub has_dst_changes {26}
++sub has_dst_changes {25}
+ 
+ sub _max_year {2031}
+ 
+@@ -545,19 +527,8 @@
+ 
+ my $rules = [
+   bless( {
+-'at' => '3:00',
+-'from' => '2015',
+-'in' => 'Jan',
+-'letter' => '',
+-'name' => 'Fiji',
+-'offset_from_std' => 0,
+-'on' => 'Sun>=12',
+-'save' => '0',
+-'to' => 'max'
+-  }, 'DateTime::TimeZone::OlsonDB::Rule' ),
+-  bless( {
+ 'at' => '2:00',
+-  

Bug#996600: buster-pu: package libdatetime-timezone-perl/1:2.23-1+2021d

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.23-1+2021d to buster,
with the data from the Olson db release 2021 as a quilt patch.

Manually stripped debdiff attached.

IIUIC, the change for Fiji DST is effective in about a month, so
there's no immediate hurry, but at some point this might be material
for -updates and/or the next point release.

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmFqAsxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaSPBAAxbYcfNTDoxXhqfRUwTeHj1E/H/yI7N0Urv+w83jFon7DpWCGuRZ3dlyR
iWGFmiSgE4rTwqIadl2MGA6wlR3OcmuPCvPX2fiAAiJx3HqTSgXhToJgIWfVTRd5
sQlyELaEN8kVo3C1X/5v1+aUjRHlMmWRCUg5sRvzkKN0GHlk/iB+a7JEDQEYOEM5
IIm2Ki1G+Sc0RmBH8/MYWPSqkQBHCURjFRcx7pBTLokSjlnLNMQbvGHtkhLf2wZO
q9GOZ5w83kZFFTR9e3sg8H2rEkQx3GTrLVRet8IVseX6RUW6MtQIm+3s2v3dC3FH
Dj3HtYXnqp6B9qrpDKz0TG0gsNtj5IcACCJmNWVRFG30SOIdbehA6JeXpeeiDWS8
r1cUO82+IhAIA5pBEKTIUIQvPFZEU3TGXJw3yziyrnDERMPuy1yQK3RlLq17tMHT
2/hjcx8zT6pKVuBvCkJQscgJ2PvOyZ/6Bwxt17cFEWZ/IxRILur08UBbF2fPN9+c
8Gq+xLr2E4CceL+VFl4H7Wk8RMCjQIO61ttP2mORVKQ91p8wjtSIhTDH1nwheu9w
/4GL4C+Rm+JG1hSlxXEdcr0739IFNZcs3arUq5dLJlHgwiG8AbyB7HtLq8dhARUS
qxibUHpH+9Mx1REvJeIjJXBpWKBUOMp31IbYA7CraoPTAmClGxU=
=X4TH
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.23/debian/changelog 
libdatetime-timezone-perl-2.23/debian/changelog
--- libdatetime-timezone-perl-2.23/debian/changelog 2021-09-28 
13:10:27.0 +0200
+++ libdatetime-timezone-perl-2.23/debian/changelog 2021-10-16 
00:24:05.0 +0200
@@ -1,3 +1,11 @@
+libdatetime-timezone-perl (1:2.23-1+2021d) buster; urgency=medium
+
+  * Update to Olson database version 2021d.
+This update includes fixes for the zone links for Atlantic/Jan_Mayen and
+America/Virgin (2021c), and contemporary changes for Fiji (2021d).
+
+ -- gregor herrmann   Sat, 16 Oct 2021 00:24:05 +0200
+
 libdatetime-timezone-perl (1:2.23-1+2021b) buster; urgency=medium
 
   * Update to Olson database version 2021b.
diff -Nru libdatetime-timezone-perl-2.23/debian/patches/olson-2021d 
libdatetime-timezone-perl-2.23/debian/patches/olson-2021d
--- libdatetime-timezone-perl-2.23/debian/patches/olson-2021d   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.23/debian/patches/olson-2021d   2021-10-16 
00:24:05.0 +0200
@@ -0,0 +1,7084 @@
+Description: Update to Olson DB 2021d
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2021-10-06
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2021b
++# Generated from debian/tzdata/africa.  Olson data version 2021d
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2021b'}
++sub olson_version {'2021d'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Pacific/Fiji.pm
 b/lib/DateTime/TimeZone/Pacific/Fiji.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/australasia.  Olson data version 2021b
++# Generated from debian/tzdata/australasia.  Olson data version 2021d
+ #
+ # Do not edit this file directly.
+ #
+@@ -286,26 +286,8 @@
+ ],
+ [
+ 63746488800, #utc_start 2021-01-16 14:00:00 (Sat)
+-63772495200, #  utc_end 2021-11-13 14:00:00 (Sat)
+-63746532000, #  local_start 2021-01-17 02:00:00 (Sun)
+-63772538400, #local_end 2021-11-14 02:00:00 (Sun)
+-43200,
+-0,
+-'+12',
+-],
+-[
+-63772495200, #utc_start 2021-11-13 14:00:00 (Sat)
+-63777938400, #  utc_end 2022-01-15 14:00:00 (Sat)
+-63772542000, #  local_start 2021-11-14 03:00:00 (Sun)
+-63777985200, #local_end 2022-01-16 03:00:00 (Sun)
+-46800,
+-1,
+-'+13',
+-],
+-[
+-63777938400, #utc_start 2022-01-15 14:00:00 (Sat)
+ 63803944800, #  utc_end 2022-11-12 14:00:00 (Sat)
+-63777981600, #  local_start 2022-01-16 02:00:00 (Sun)
++63746532000, #  local_start 2021-01-17 02:00:00 (Sun)
+ 63803988000, #local_end 2022-11-13 02:00:00 (Sun)
+ 43200,
+ 0,
+@@ -493,9 +475,9 @@
+ ],
+ ];
+ 
+-sub olson_version {'2021b'}
++sub olson_version {'2021d'}
+ 
+-sub has_dst_changes {26}
++sub has_dst_changes {25}
+ 
+ sub _max_year {2031}
+ 
+@@ -545,19 +527,8 @@
+ 
+ my $rules = [
+   bless( {
+-'at' => '3:00',
+-'from' => '2015',
+-'in' => 'Jan',
+-'letter' => '',
+-'name' => 'Fiji',
+-'offset_from_std' => 0,
+-'on' => 'Sun>=12',
+-'save' => '0',
+-'to' => 'max'
+-  }, 'DateTime::TimeZone::OlsonDB::Rule' ),
+-  bless( {
+ 'at' => '2:00',
+-'from' 

Bug#996599: xdmf: reproducible builds: Embeds number and type of processor

[Vagrant Cascadian]

Source: xdmf
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: cpu uname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The processor type and number of processors is embedded in
/usr/lib/x86_64-linux-gnu/cmake/Xdmf/XdmfConfig.cmake, which cause
reproducibility issues.

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/diffoscope-results/xdmf.html

  set(XDMF_CMAKE_HOST_SYSTEM_PROCESSOR»   »   "x86_64")
vs.
  set(XDMF_CMAKE_HOST_SYSTEM_PROCESSOR»   »   "i686")

  set(XDMF_CMAKE_SYSTEM_PROCESSOR»»"x86_64")
vs.
  set(XDMF_CMAKE_SYSTEM_PROCESSOR»»"i686")

  set(XDMF_MPIEXEC_MAX_NUMPROCS»  »  "9")
vs.
  set(XDMF_MPIEXEC_MAX_NUMPROCS»  »  "10")

The attached patch to debian/rules fixes this by removing these values
from the XdmfConfig.cmake file.

Without knowing xdmf well, I am NOT sure if it is ok to remove these
values from XdmfConfig.cmake, though in order to use the .cmake file it
would seem best to regenerate it in the environment in which is used
rather than the environment where the package happened to be built.

So it is also unclear if XdmfConfig.cmake actually needs to be included
in the package; a better course of action *might* be to remove the file
entirely.


With this patch applied(or removing XdmfConfig.cmake from the package),
xdmf should (really this time!) become reproducible on
tests.reproducible-builds.org.


Thanks for maintaining xdmf!


live well,
  vagrant
From fa766ebd467308ba91f8fedaf03901a51dfe09a7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 15 Oct 2021 22:05:14 +
Subject: [PATCH] debian/rules: Sanitize XdmfConfig.cmake to fix
 reproducibility issues due to processor.

Remove XDMF_CMAKE_SYSTEM_PROCESSOR, XDMF_CMAKE_HOST_SYSTEM_PROCESSOR
and XDMF_MPIEXEC_MAX_NUMPROCS. The number and type of CPU may not be
consistent with the environment that the package is built for, and
make it hard to build reproducibly.

https://tests.reproducible-builds.org/debian/issues/unstable/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
 debian/rules | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index f7f3f42..6399a86 100755
--- a/debian/rules
+++ b/debian/rules
@@ -91,11 +91,15 @@ override_dh_auto_install:
 		cp debian/build-serial-$$p/lib/__*.so   $(PY3DEST)/usr/lib/$$p/dist-packages/xdmf/NoMpi ; \
 		cp debian/build-mpi-$$p/lib/__*.so   $(PY3DEST)/usr/lib/$$p/dist-packages/xdmf ; \
 		done
-	# Remove build path and kernel version, and adjust path to
-	# uname to make build reproducible
+	# Remove build path and kernel version, adjust path to uname,
+	# and remove sytem processor and number of processors to make
+	# build reproducible
 	sed -i -e "s,$(CURDIR),BUILDDIR,g" \
 		-e "s,/usr/bin/uname,/bin/uname,g" \
 		-e "s,$(shell uname -r),,g" \
+		-e "/XDMF_CMAKE_SYSTEM_PROCESSOR/d" \
+		-e "/XDMF_CMAKE_HOST_SYSTEM_PROCESSOR/d" \
+		-e "/XDMF_MPIEXEC_MAX_NUMPROCS/d" \
 		debian/tmp/$(LIBDIR)/cmake/Xdmf/XdmfConfig.cmake
  
 override_dh_auto_fixperms:
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#996598: [ld][glibc]: Adopt SHT_RELR/DT_RELR to decrease PIE and shared object size

[Fangrui Song]

Source: glibc
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: sylves...@debian.org

The SHT_RELR/DT_RELR format encodes relative relocations in a very efficient 
way (quite usually takes just 3% or smaller space).
The size optimization can greatly decrease the virtual memory size of PIE and 
shared objects with many R_*_RELATIVE relocations.

E.g. The clang executable's virtual memory size is 8.2% smaller with 
SHT_RELR/DT_RELR. The size varies across projects, but I anticipate at least 5% 
decrease for most projects.

% ~/projects/bloaty/Release/bloaty clang.pie.relr -- clang.pie
FILE SIZEVM SIZE
 --  -- 
  [NEW]  +163Ki  [NEW]  +163Ki.relr.dyn
  +4.9% +32  +5.4% +32.dynamic
  +2.5%  +8  [ = ]   0.shstrtab
 -99.5% -13.8Mi -99.5% -13.8Mi.rela.dyn
  -8.3% -13.6Mi  -8.2% -13.6MiTOTAL

The SHT_RELR/DT_RELR relocation format requires linker and loader support.

* On the linkder side, ld.lld has supported .relr.dyn/SHT_RELR/DT_RELR 
(`--pack-dyn-relocs=relr`) for a long time and the support has been stable 
since 2019-09 (after I fixed an address oscillating bug).
* On the loader (glibc ld.so) side, a patch exists 
https://sourceware.org/pipermail/libc-alpha/2021-October/131768.html
  but lack of GNU ld support may impede its adoption among Linux distributions.
  User support is also important to push the patch forward. (ia64 according to 
folks isn't an issue. glibc doesn't implement ELFCLASS32 for ia64 AFAICT.)

(
Worth noting that the Linux kernel's arm64 port supports SHT_RELR/DT_RELR since 
2019.
ChromeOS has maintained a local glibc patch since around 2018.)

So I file this ticket seeking for support (comment on 
https://sourceware.org/bugzilla/show_bug.cgi?id=27924). I hope that with 
sufficient attention from users,
someone (e.g. a GNU ld maintainer) will eventually stand up and implement 
`--pack-dyn-relocs=relr` for GNU ld 
(https://sourceware.org/bugzilla/show_bug.cgi?id=27923).
Even in the absence of GNU ld support, I hope glibc can accept the DT_RELR 
patch, so that ld.lld users can use `--pack-dyn-relocs=relr`.

See also Gentoo: https://bugs.gentoo.org/818376 Fedora: 
https://bugzilla.redhat.com/show_bug.cgi?id=2014699 Arch Linux: 
https://bugs.archlinux.org/task/72433

Bug#996204: transition: numerical library stack

[Drew Parsons]

On 2021-10-15 21:02, Sebastian Ramacher wrote:

Control: tags -1 confirmed

On 2021-10-12 13:09:02 +0200, Drew Parsons wrote:


I'd like to proceed with a transition of the numerical library stack.
This involves

...

Please go ahead

Cheers




Ben file:

title = "numerical library stack";
is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~ 
"libpetsc-.*3.15";

is_good = .depends ~ "libpetsc-.*3.15";
is_bad = .depends ~ "libpetsc-.*3.14";




Thanks Sebastian.  I'll start from superlu (and xtensor already 
underway).


Drew

Bug#996576: ITP: vixl -- ARMv8 Runtime Code Generation Library

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: vixl
  Version : 5.1.0
  Upstream Author : Linaro 
* URL : https://github.com/Linaro/vixl
* License : BSD-3-Clause
  Programming Lang: C++
  Description : ARMv8 Runtime Code Generation Library

Vixl is an AArch32 and AArch64 Runtime Code Generation Library.
.
It contains three components: assemblers to generate ARM code at runtime,
disassemblers that can print any instruction emitted by the assemblers and a
simulator that can simulate any instruction emitted by the A64 assembler.

This is a dependency of Dynarmic (#995917), a dependency of the yuzu emulator
(#947399)


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYWnBpRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuScMaAQDNanZekkb05SrxgLlWwHMBk3AyDIew
Nd4D51pi0w8icAEAyq+ZAQMFigCknG2VQpFGxnE2TOZEaigQCRowmDkKYQ4=
=HgSx
-END PGP SIGNATURE-

Bug#996596: [linux-image-amd64] dkms error on kernel image removal

[Lyndon Brown]

Package: linux-image-amd64
Version: 5.14.12-1

I tried to purge linux-image-5.14.0-1-amd64 yesterday and ran into an
error. I additionally tried to purge linux-image-5.14.0-2-amd64 today
following the release of linux-image-5.14.0-3-amd64 and ran into the
same error, which I've copied below.

Please can you advise how to clean up after the failure, is removal of
the old '/lib/modules/5.14.0-x-amd64' directories and their contents
sufficient?

$ sudo dpkg --purge linux-image-5.14.0-2-amd64
(Reading database ... 274461 files and directories currently installed.)
Removing linux-image-5.14.0-2-amd64 (5.14.9-2) ...
/etc/kernel/prerm.d/dkms:
dkms: removing:   (5.14.0-2-amd64) (x86_64)
Error! Arguments  and  are not specified.
Usage: remove / or
   remove -m / or
   remove -m  -v 
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.14.0-3-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.14.0-3-amd64
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-5.14.0-2-amd64
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.14.0-3-amd64
Found initrd image: /boot/initrd.img-5.14.0-3-amd64
Adding boot menu entry for EFI firmware configuration
done
Purging configuration files for linux-image-5.14.0-2-amd64 (5.14.9-2) ...
rmdir: failed to remove '/lib/modules/5.14.0-2-amd64': Directory not empty
dpkg: warning: while removing linux-image-5.14.0-2-amd64, directory 
'/lib/modules/5.14.0-2-amd64' not empty so not removed

Bug#993958: apt: Unnecessarily provide empty dir /lib/systemd/

[Boyuan Yang]

Control: close 993958

It seems that debhelper/13.5.2 has reverted related changes. Closing this bug
report until a real merged-user solution is implemented.

Thanks,
Boyuan Yang

On Wed, 08 Sep 2021 12:10:34 -0400 Boyuan Yang  wrote:
> Package: apt
> Severity: normal
> Version: 2.3.9
> X-Debbugs-CC: j...@debian.org
> 
> Dear Debian APT Maintainers,
> 
> % dpkg -c ./apt_2.3.9_amd64.deb | grep systemd    
> drwxr-xr-x root/root 0 2021-09-07 11:25 ./lib/systemd/
> -rwxr-xr-x root/root 16029 2021-09-07 11:25
> ./usr/lib/apt/apt.systemd.daily
> drwxr-xr-x root/root 0 2021-09-07 11:25 ./usr/lib/systemd/
> drwxr-xr-x root/root 0 2021-09-07 11:25 ./usr/lib/systemd/system/
> -rw-r--r-- root/root   389 2021-09-07 11:25
./usr/lib/systemd/system/apt-
> daily-upgrade.service
> -rw-r--r-- root/root   184 2021-09-07 11:25
./usr/lib/systemd/system/apt-
> daily-upgrade.timer
> -rw-r--r-- root/root   326 2021-09-07 11:25
./usr/lib/systemd/system/apt-
> daily.service
> -rw-r--r-- root/root   156 2021-09-07 11:25
./usr/lib/systemd/system/apt-
> daily.timer
> 
> 
> Since systemd system services are now installed under /usr/lib/systemd,
> obviously we do not need to provide the empty directory /lib/systemd/
anymore.
> The systemd binary package always provides it instead. Please consider
> revising the build system and do not generate /lib/systemd/ directory in the
> .deb file.


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

Bug#8639: --force-script-errors

[Glenn Washburn]

On Thu, 10 Apr 1997 11:12:17 +0200 j...@office.individual.net (Martin
Schulze) wrote:
> Package: dpkg
> Version: 1.4.0.6
> Type: Feature request
> 
> dpkg should be able to --install, --remove and --purge even if one of
> the {pre,post}{inst,rm} scripts fail.
> 
> In fact I mistakenly broke some of my installation scripts which resulted
> in the need to hack within dpkg's database manually.  This is ugly.
> 
> Regards
> 
>   Joey
> 
> -- 
> Individual Network e.V._/OrgaTech KG i.Gr.
> j...@office.individual.net_/  j...@orgatech.de
> Geschaeftszeit: Di+Mi+Fr, 15-18 Uhr  _/Tel: (0441) 9808556
> 

20+ years later and I'd like to second this feature request. It would
be nice to suppress post install script errors. This way if we want to
bubble an error for other errors, but not this one we are able to.

Glenn

Bug#951354: wget2: Please package new version (1.99.2)

[Boyuan Yang]

Control: retitle -1 wget2: Please package new 2.0.0 version

On Fri, 14 Feb 2020 22:22:36 -0500 Boyuan Yang  wrote:
> Source: wget2
> Version: 1.99.1-2.1
> Severity: normal
> 
> Dear wget2 maintainer,
> 
> A new release of wget2 (wget2 1.99.1) is now available. Please consider
> packaging it in Debian. Thanks!

Dear Debian wget2 packge maintainer,

The upstream has released the 2.0.0 new version. Please consider packaging it
in Debian. Thanks!

Regards,
Boyuan Yang


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

Bug#836483: ITA: gkermit -- A serial and network comm. package

[Bastian Germann]

Control: retitle -1 ITA: gkermit -- A serial and network comm. package

Bug#996594: ardour shows no GUI after asking for and confirming session (core dumped)

[T. J. Pinkert]

Package: ardour
Version: 1:6.5.0+ds0-1
Severity: important
X-Debbugs-Cc: t.j.pink...@alumnus.utwente.nl

Dear Maintainer,

I recently upgraded to Debian bullseye. Ardour was working fine on the
oldstable.
Upon starting ardour it gets as far as showing the session selection dialogue,
but then crashes.

Up till now I have not found a solution for the problem. However, when I
started ardour from the commandline I got the following debug information as
last few lines of the output:
...
no more csLADSPA plugins
ardour-6.5.0~ds0: src/freeverb/revmodel.cpp:37: void revmodel::setrate(int):
Assertion `rate <= TUNING_MAX_SAMPLE_RATE' failed.
Aborted (core dumped)
user@machine:~$

The sample rate for the selected session is 48 kHz for professional audio.
I think this must be a bug in the software. Ardour is supposed to be capable of
running at 48 kHz or higher sampling rates.

Best regards,


Tjeerd Pinkert

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

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

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


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

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

Versions of packages ardour depends on:
ii  ardour-data   1:6.5.0+ds0-1
ii  ardour-lv2-plugins1:6.5.0+ds0-1
ii  libarchive13  3.4.3-2+b1
ii  libasound21.2.4-1.1
ii  libatkmm-1.6-1v5  2.28.0-3
ii  libaubio5 0.4.9-4+b4
ii  libc6 2.31-13+deb11u2
ii  libcairo2 1.16.0-5
ii  libcairomm-1.0-1v51.12.2-4
ii  libcurl3-gnutls   7.74.0-1.3+b1
ii  libcwiid1 0.6.91-2+b1
ii  libdbus-1-3   1.12.20-2
ii  libfftw3-single3  3.3.8-2
ii  libfluidsynth22.1.7-1.1
ii  libfontconfig12.13.1-4.2
ii  libgcc-s1 10.2.1-6
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libglibmm-2.4-1v5 2.64.2-2
ii  libgtk2.0-0   2.24.33-2
ii  libgtkmm-2.4-1v5  1:2.24.5-4
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  liblilv-0-0   0.24.12-2
ii  liblo70.31-1
ii  liblrdf0  0.6.1-2
ii  libltc11  1.3.1-1
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libpangoft2-1.0-0 1.46.2-3
ii  libpangomm-1.4-1v52.42.1-1
ii  libpulse0 14.2-2
ii  libqm-dsp01.7.1-4
ii  librubberband21.9.0-1
ii  libsamplerate00.2.1+ds0-1
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libsndfile1   1.0.31-2
ii  libstdc++610.2.1-6
ii  libsuil-0-0   0.10.10-1
ii  libtag1v5 1.11.1+dfsg.1-3
ii  libusb-1.0-0  2:1.0.24-3
ii  libvamp-hostsdk3v52.10.0-1
ii  libvamp-sdk2v52.10.0-1
ii  libwebsockets16   4.0.20-2
ii  libx11-6  2:1.7.2-1
ii  libxml2   2.9.10+dfsg-6.7

Versions of packages ardour recommends:
ii  ardour-video-timeline  1:6.5.0+ds0-1

ardour suggests no packages.

Bug#996593: vim: CVE-2021-3875

[Salvatore Bonaccorso]

Source: vim
Version: 2:8.2.3455-2
Severity: important
Tags: security upstream fixed-upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:8.2.2434-3
Control: found -1 2:8.1.0875-5

Hi,

The following vulnerability was published for vim.

CVE-2021-3875[0]:
| vim is vulnerable to Heap-based Buffer Overflow


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3875
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3875
[1] https://github.com/vim/vim/commit/35a319b77f897744eec1155b736e9372c9c5575f
[2] https://huntr.dev/bounties/5cdbc168-6ba1-4bc2-ba6c-28be12166a53/

Regards,
Salvatore

Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Glenn,

Quoting Glenn Washburn (2021-10-15 21:39:08)
> > While running dpkg with --root and --force-script-chrootless avoids the
> > chroot() call and thus, allows installing packages without the root user in
> > theory, the DPKG_ROOT mechanism and the avoidance of the chroot() was *not*
> > added to dpkg so that packages can be installed as a user other than root.
> > The
> 
> I never claimed it was. I suspect your email was written having not
> read my response because I address this. And do not make this claim
> about DPKG_ROOT. I know that it is for installing in alternate root (/)
> directories, and is an orthagonal concept to the root user. This is why
> the title of the bug is phrased with an and, indicating that they are
> separate things.

okay. It is customary to open one bug per issue instead of conflating multiple
problems into a single bug.

> > DPKG_ROOT mechanism exists because it allows creating foreign architecture
> > chroots for architectures that do not have qemu support yet or for which
> > emulation support is too slow. So DPKG_ROOT is something that helps us with
> > handling chroots for foreign architectures, bootstrapping Debian as well as
> > using Debian in an embedded systems context.
> I'm curious what you think about the UML use case that I laid out in my
> response to Michael.

User Mode Linux?

> > I agree with what Michael already wrote above. Glenn, before you open bugs
> > against a number of packages, please explain your use-case to a wider
> > audience.  Maybe on the debian-devel mailing list. Without more
> > information, I don't see a use-case of being able to install packages
> > without being the root user.
> 
> Ok. To the extent that packages do not respect DPKG_ROOT, I consider
> that a bug of the individual package (some packages do respect
> DPKG_ROOT and most don't need to care). Does Debian has an official
> policy around this? Like perhaps explicitly saying that packages may
> ignore DPKG_ROOT? Even if it does, the bug falls into the wishlist
> category. So I'm still failing to see how the bugs I submitted should
> not have been submitted.

Before filing multiple bugs of the same category (a mass bug filing), the issue
should be discussed on the debian-devel mailing list as written up here:

https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#reporting-lots-of-bugs-at-once-mass-bug-filing

> > For cases where you still want to do that, there is fakeroot and there are
> > Linux user namespaces. I maintain a debootstrap alternative called
> > mmdebstrap which allows one to create a chroot without being root that
> > makes use of fakeroot and unshare. So I can confirm that it is already
> > possible to run dpkg --install without being the root user and I currently
> > don't see a reason why adding support of running maintainer scripts without
> > being uid 0 would be necessary in practice.
> 
> I'll have to take a look, this is the first I've heard of this package.
> However, neither are commonly installed on systems and aren't installed on
> the system that I have an unprivileged account on.

mmdebstrap is a single script that you can copy around without installing it.
It just needs apt and dpkg installed.

> dpkg itself has no issue with running as a non-root user, the issues are with
> the packages themselves.

Yes, dpkg can do it. But this is not a question of whether dpkg can do it. This
is a question of policy about whether we want to support installing packages
like that in Debian. More on that below.

> As I mention in my other response, I've created a wrapper script that allows
> installing to arbitrary user-controlled directories with commonly installed
> tools on debian-based systems. Yes, it does rely on DPKG_ROOT working where
> needed.

So you want to have a directory, maybe in your $HOME and fill that directory
with packages in their installed state, right? And you want to be able to do
this without root, right? Try doing this:

mmdebstrap --variant=essential --include=somepkg unstable ./some/directory

This will put essential packages and "somepkg" into ./some/directory.

> Correct me if I'm wrong, but I need certain privileges to use the unshare
> system call, right? I just ran "unshare -m  bash" and I get permission
> denied. I see in strace the log message:
> 
>   unshare(CLONE_NEWNS) = -1 EPERM (Operation not permitted)

That's why you have to unshare the user namespace first, like this:

$ lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC' -- 
/usr/sbin/chroot ./debian-rootfs /bin/bash

Or like this:

$ unshare --map-root-user -m whoami
root

> > Glenn, if you want to help with DPKG_ROOT, you are welcome to do so! Just 
> > write
> > patches and submit merge requests to the salsa repository linked above. 
> > After
> > your patches are tested and show that they result in a bit-by-bit identical
> > chroot, you can open a bug against the respective source packages with a
> > working patch.
> 
> 

Bug#996591: libgclib: CVE-2021-42006

[Salvatore Bonaccorso]

Source: libgclib
Version: 0.12.7+ds-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpertea/gclib/issues/11
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libgclib.

CVE-2021-42006[0]:
| An out-of-bounds access in GffLine::GffLine in gff.cpp in GCLib 0.12.7
| allows an attacker to cause a segmentation fault or possibly have
| unspecified other impact via a crafted GFF file.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-42006
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42006
[1] https://github.com/gpertea/gclib/issues/11

Regards,
Salvatore

Bug#996590: evolution-rss: CVE-2021-39361: Missing TLS certificate verification

[Salvatore Bonaccorso]

Source: evolution-rss
Version: 0.3.96-4
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/evolution-rss/-/issues/11
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.3.96-2
Control: found -1 0.3.95-9

Hi,

The following vulnerability was published for evolution-rss.

CVE-2021-39361[0]:
| In GNOME evolution-rss through 0.3.96, network-soup.c does not enable
| TLS certificate verification on the SoupSessionSync objects it
| creates, leaving users vulnerable to network MITM attacks. NOTE: this
| is similar to CVE-2016-20011.

TTBOMK, no fix exists yet at time of writing, bug filled to track the
upstream issue downstream so far.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39361
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39361
[1] https://gitlab.gnome.org/GNOME/evolution-rss/-/issues/11

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#996589: cloudcompare FTBFS on !amd64

[Adrian Bunk]

Source: cloudcompare
Version: 2.11.3-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=cloudcompare=2.11.3-2

There are at least two separate errors:

...
/<>/plugins/core/Standard/qRANSAC_SD/RANSAC_SD_orig/MiscLib/AlignedAllocator.h:
 In member function ‘T* MiscLib::AlignedAllocator::allocate(MiscLib::AlignedAllocator::size_type, 
std::allocator::const_pointer)’:
/<>/plugins/core/Standard/qRANSAC_SD/RANSAC_SD_orig/MiscLib/AlignedAllocator.h:30:29:
 error: there are no arguments to ‘aligned_alloc’ that depend on a template 
parameter, so a declaration of ‘aligned_alloc’ must be available [-fpermissive]
   30 | #define a_malloc(sz, align) aligned_alloc((align), (sz))
  | ^
...


...
make[3]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libavutil.so', 
needed by 'plugins/core/Standard/qAnimation/libQANIMATION_PLUGIN.so'.  Stop.
make[3]: *** Waiting for unfinished jobs
...

Bug#996588: imagemagick: CVE-2021-39212

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for imagemagick.

CVE-2021-39212[0]:
| ImageMagick is free software delivered as a ready-to-run binary
| distribution or as source code that you may use, copy, modify, and
| distribute in both open and proprietary applications. In affected
| versions and in certain cases, Postscript files could be read and
| written when specifically excluded by a `module` policy in
| `policy.xml`. ex. policy domain="module" rights="none"
| pattern="PS" /. The issue has been resolved in ImageMagick 7.1.0-7
| and in 6.9.12-22. Fortunately, in the wild, few users utilize the
| `module` policy and instead use the `coder` policy that is also our
| workaround recommendation: policy domain="coder" rights="none"
| pattern="{PS,EPI,EPS,EPSF,EPSI}" /.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39212
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39212
[1] 
https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-qvhr-jj4p-j2qr

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#996587: Support method of waiting for release of db lock

[Glenn Washburn]

Package: dpkg
Version: 1.20.9

Apt somewhat recently added the ability for an invocation of apt to
wait until the db lock which was held by another apt instance is
released[1]. It would be nice to have similar functionality in dpkg. I
propose two solutions.

The simplest and least work, is to return an error code indicating that
a dpkg exited due to a lock already being held (exit code 3 is the next
available). This allows scripts to know that dpkg failed due to a held
lock and can then do its own retry logic. Currently the returned error
doesn't allow the caller to determine that the failure was due to a
held lock (yes, output could be parsed, but that's a big hack).

The second solution is to add an option, perhaps -w and --wait ,
which tells dpkg to wait a specified amount of time to the lock to be
released. If the timeout is exceeded the exit code should be unique to
a failure due to a held lock, as in the first solution. Otherwise,
dpkg should try to grab the lock and perform the requested action.

Glenn

[1] https://salsa.debian.org/apt-team/apt/-/merge_requests/109/diffs

Bug#996586: heimdal: CVE-2021-3671

[Salvatore Bonaccorso]

Source: heimdal
Version: 7.7.0+dfsg-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.5.0+dfsg-3

Hi,

The following vulnerability was published for heimdal.

CVE-2021-3671[0]:
| A null pointer de-reference was found in the way samba kerberos server
| handled missing sname in TGS-REQ (Ticket Granting Server - Request).
| An authenticated user could use this flaw to crash the samba server.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3671
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3671
[1] 
https://github.com/heimdal/heimdal/commit/04171147948d0a3636bc6374181926f0fb2ec83a
[2] 
https://github.com/heimdal/heimdal/commit/773802aecfb4b6a73817fa522faeb55b2a7cdb2a

Regards,
Salvatore

Bug#990789: LERC compression in TIFF

[GCS]

Hi Antonio,

On Fri, Oct 15, 2021 at 8:18 AM Antonio Valentino
 wrote:
> would you accept a patch for this?
 I would be very impressed if you can do it with a patch only.

Regards,
Laszlo/GCS

Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT

[Glenn Washburn]

Hi Johannes,

On Fri, 15 Oct 2021 20:24:12 +0200
Johannes Schauer Marin Rodrigues  wrote:

> Hi Michael & Glenn,
> 
> On Fri, 15 Oct 2021 12:26:38 +0200 Michael Biebl  wrote:
> > Am 15.10.21 um 11:14 schrieb Michael Biebl:
> > > Am 15.10.21 um 07:53 schrieb Glenn Washburn:
> > >> Probably the easiest solution would be to exit early from the post 
> > >> install
> > >> if the current user is not root. There's probably a more subtle fix that
> > >> preserves more functionality (eg. maybe updating the hwdb in PKG_ROOT?),
> > >> what ever gets the post install to not fail in this scenario works for 
> > >> me.
> > > 
> > > Package installations need to be done as root.
> > > I don't think the package would benefit if we'd litter the maintainer 
> > > scripts with id checks.
> > > 
> > > Please elobare what the use case is here?
> > 
> > I notice that you filed multiple bugs against various packages [1].
> > I don't think this is particularly helpful as long as dpkg doesn't 
> > officially support installations as non-root.
> > 
> > If you want to allow non-root installations, then this needs to be 
> > discussed with the dpkg maintainer and ideally on debian-devel.
> > While this might be a laudable goal, my guess is that with the way packages
> > are built today, this is not (easily) possible.
> 
> Helmut just made me aware of this bug as well as few others by Glenn that talk
> about "PKG_ROOT" and asked me to follow up on the topic. Assuming that
> "PKG_ROOT" is a typo and actually "DPKG_ROOT" is meant (Glenn, could you
> clarify?), then it is important to know that DPKG_ROOT is about root as in the
> root path ("/") and not as in the root user. The DPKG_ROOT variable that is 
> set

Yes, I meant DPKG_ROOT.

> for maintainer scripts if dpkg is run with --root and
> --force-script-chrootless. Helmut and I are working on making the 
> Essential:yes
> package set work with DPKG_ROOT and we have submitted patches for all source
> packages that are still missing support for it and we have a salsa CI pipeline
> that makes sure that our patches allow a bit-by-bit identical chroot compared
> to installations without DPKG_ROOT:
> https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

Great news!

> 
> While running dpkg with --root and --force-script-chrootless avoids the
> chroot() call and thus, allows installing packages without the root user in
> theory, the DPKG_ROOT mechanism and the avoidance of the chroot() was *not*
> added to dpkg so that packages can be installed as a user other than root. The

I never claimed it was. I suspect your email was written having not
read my response because I address this. And do not make this claim
about DPKG_ROOT. I know that it is for installing in alternate root (/)
directories, and is an orthagonal concept to the root user. This is why
the title of the bug is phrased with an and, indicating that they are
separate things.

> DPKG_ROOT mechanism exists because it allows creating foreign architecture
> chroots for architectures that do not have qemu support yet or for which
> emulation support is too slow. So DPKG_ROOT is something that helps us with
> handling chroots for foreign architectures, bootstrapping Debian as well as
> using Debian in an embedded systems context.

I'm curious what you think about the UML use case that I laid out in my
response to Michael.

> I agree with what Michael already wrote above. Glenn, before you open bugs
> against a number of packages, please explain your use-case to a wider 
> audience.
> Maybe on the debian-devel mailing list. Without more information, I don't see 
> a
> use-case of being able to install packages without being the root user. 

Ok. To the extent that packages do not respect DPKG_ROOT, I consider
that a bug of the individual package (some packages do respect
DPKG_ROOT and most don't need to care). Does Debian has an official
policy around this? Like perhaps explicitly saying that packages may
ignore DPKG_ROOT? Even if it does, the bug falls into the wishlist
category. So I'm still failing to see how the bugs I submitted should
not have been submitted.

> For
> cases where you still want to do that, there is fakeroot and there are Linux
> user namespaces. I maintain a debootstrap alternative called mmdebstrap which
> allows one to create a chroot without being root that makes use of fakeroot 
> and
> unshare. So I can confirm that it is already possible to run dpkg --install
> without being the root user and I currently don't see a reason why adding
> support of running maintainer scripts without being uid 0 would be necessary 
> in
> practice.

I'll have to take a look, this is the first I've heard of this package.
However, neither are commonly installed on systems and aren't installed
on the system that I have an unprivileged account on. dpkg itself has
no issue with running as a non-root user, the issues are with the
packages themselves. As I mention in my other response, I've created a
wrapper script that allows 

Bug#996585: ITP: r-cran-mixsqp -- Quadratic Programming for Estimation of Mixture Proportions

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-mixsqp -- Quadratic Programming for Estimation of Mixture 
Proportions
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-mixsqp
  Version : 0.3
  Upstream Author : Youngseok Kim
* URL : https://cran.r-project.org/package=mixsqp
* License : MIT
  Programming Lang: GNU R
  Description : Quadratic Programming for Estimation of Mixture Proportions
 Provides an optimization method based on sequential
 quadratic programming (SQP) for maximum likelihood estimation of
 the mixture proportions in a finite mixture model where the
 component densities are known. The algorithm is expected to obtain
 solutions that are at least as accurate as the state-of-the-art
 MOSEK interior-point solver (called by function "KWDual" in the
 'REBayes' package), and they are expected to arrive at solutions
 more quickly when the number of samples is large and the number of
 mixture components is not too large. This implements the "mix-SQP"
 algorithm, with some improvements, described in Y. Kim,
 P. Carbonetto, M. Stephens & M. Anitescu (2020)
 .

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

Bug#996584: (some kind of) transition: add python3.10 as a supported python3 version

[Matthias Klose]

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

Please setup a tracker to add python3.10 as a supported python3 version. This is
non-blocking, as packages can migrate on their own once built. I'm not yet
starting this, just want to have an overview of affected packages.

Please re-use the final version of the python3.9 tracker (#966426).

Bug#996583: xir FTBFS

[Adrian Bunk]

Source: xir
Version: 1.3.2-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xir.html
https://buildd.debian.org/status/logs.php?pkg=xir=1.3.2-1

...
/<>/src/xir/graph/elf2xir.cpp: In instantiation of ‘std::ostream& 
{anonymous}::operator<<(std::ostream&, const std::vector&) [with T = 
std::__cxx11::basic_string; std::ostream = std::basic_ostream]’:
/<>/src/xir/graph/elf2xir.cpp:1010:33:   required from here
/<>/src/xir/graph/elf2xir.cpp:403:19: error: loop variable ‘x’ 
creates a copy from type ‘const std::__cxx11::basic_string’ 
[-Werror=range-loop-construct]
  403 |   for (const auto x : v) {
  |   ^
/<>/src/xir/graph/elf2xir.cpp:403:19: note: use reference type to 
prevent copying
  403 |   for (const auto x : v) {
  |   ^
  |   &
...

Bug#996582: ITP: r-cran-coloc -- Colocalisation Tests of Two Genetic Traits

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-coloc -- Colocalisation Tests of Two Genetic Traits
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-coloc
  Version : 5.1.0
  Upstream Author : Chris Wallace
* URL : https://cran.r-project.org/package=coloc
* License : GPL-2
  Programming Lang: GNU R
  Description : Colocalisation Tests of Two Genetic Traits
 Performs the colocalisation tests described in
 Giambartolomei et al (2013) ,
 Wallace (2020) ,
 Wallace (2021) .

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

Bug#996204: transition: numerical library stack

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-10-12 13:09:02 +0200, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky 
> 
> I'd like to proceed with a transition of the numerical library stack.
> This involves
> 
> superlu   5.2.2+dfsg1 -> 5.3.0+dfsg1  (both libsuperlu5 so not really a 
> transition)
> superlu-dist  libsuperlu-dist6 -> libsuperlu-dist7
> hypre 2.18.2 -> 2.22.1 (internal within libhypre-dev)
> mumps libmumps-5.3 -> libmumps-5.4
> scotch6.1.0 -> 6.1.1 (both libscotch-6.1 so not a transition)
> petsc libpetsc-.*3.14 -> libpetsc-.*3.15
> slepc libslepc-.*3.14 -> libslepc-.*3.15
> (together with petsc4py, slepc4py)
> 
> Header packages libxtensor-dev, libxtensor-blas-dev will also be
> upgraded (xtl-dev 0.7.2 already got uploaded to unstable).
> 
> fenics-dolfinx will upgrade
>   libdolfinx-.*2019.2 -> libdolfinx-.*0.3
> (along with other fenics components). There is currently some problem
> with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf.
> I'll skip the demo_poisson_mpi tests for them if necessary.
> 
> sundials 5.7.0 is incompatible with hypre 2.22, Anton Gladky (cc:d) will
> upgrade to sundials 5.8.0.
> 
> openmpi/mpi4py/h5py have recently migrated to testing so shouldn't give
> any particular trouble (apart from the known 32-bit dolfinx problem)
> 
> auto transitions are already in place:
> 
> https://release.debian.org/transitions/html/auto-superlu-dist.html
> https://release.debian.org/transitions/html/auto-mumps.html
> https://release.debian.org/transitions/html/auto-petsc.html
> https://release.debian.org/transitions/html/auto-slepc.html

Please go ahead

Cheers

> 
> 
> Ben file:
> 
> title = "numerical library stack";
> is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~ "libpetsc-.*3.15";
> is_good = .depends ~ "libpetsc-.*3.15";
> is_bad = .depends ~ "libpetsc-.*3.14";
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996568: transition: fcl

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/auto-fcl.html

On 2021-10-15 15:58:13 +, Jose Luis Rivero wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> 
> Dear Release Team:
> 
> I'm the maintainer of fcle, upstream has released 0.7.0
> version some weeks ago. We have 0.7.0-2 in experimental, it builds
> in all arches that it did before (hppa builder segfaults on compilation
> but I doubt it has to do with version bump).
> 
> ratt rebuilt the dependencies it found, including DART, just fine:
> https://build.osrfoundation.org/job/debian-ratt-builder/118/console
> 
> """
> 2021/10/08 22:35:48 Building package 1 of 1: dart
> 2021/10/08 22:35:48 DEBUG - sbuild args
> []string{"--arch-all", "--dist=unstable", "--nolog", "dart_6.9.5-4", 
> "--extra-package=libfcl-dev_0.7.0-1_amd64.deb", 
> "--extra-package=libfcl0.7-dbgsym_0.7.0-1_amd64.deb", 
> "--extra-package=libfcl0.7_0.7.0-1_amd64.deb"}
> 2021/10/08 22:51:04 Build results:
> 2021/10/08 22:51:04 PASSED: dart

Please go ahead

Cheers

> """
> 
> Ben file:
> 
> title = "fcl";
> is_affected = .depends ~ "libfcl0.6" | .depends ~ "libfcl0.7";
> is_good = .depends ~ "libfcl0.7";
> is_bad = .depends ~ "libfcl0.6";
> 
> Thanks!
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Dirk Eddelbuettel]

On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| > 
| > Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
| > and I didn't use that.
| 
| No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the SOVERSION
| is 25. gsl 2.6 had current=25, age=0. Increasing current was correct,
| increasing age wasn't.

I will admit not fully understanding the three components used as eg in
upstream's configuire.ac:

dnl Library versioning (C:R:A == current:revision:age)
dnl See the libtool manual for an explanation of the numbers
dnl
dnl gsl-1.0libgsl 0:0:0  libgslcblas 0:0:0
[...]
dnl gsl-2.6libgsl 25:0:0   libgslcblas 0:0:0 
dnl gsl-2.7libgsl 26:0:1   libgslcblas 0:0:0 

and

GSL_CURRENT=26
GSL_REVISION=0
GSL_AGE=1

If I understand you correctly we needed / need

dnl gsl-2.7libgsl 26:0:0   libgslcblas 0:0:0 

GSL_CURRENT=26
GSL_REVISION=0
GSL_AGE=0

Is that correct (as far as the Debian package goes) ?

What do you (ie Sebastian) suggest we do going forward?  Be more careful
about increasing CURRENT (only) when the ABI changes? (And I CC'ed Patrick
from GSL upstream now.)

Dirk


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

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Sebastian Ramacher]

On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
> 
> Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
> and I didn't use that.

No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the SOVERSION
is 25. gsl 2.6 had current=25, age=0. Increasing current was correct,
increasing age wasn't.

Cheers

> 
> So a new package will be forthcoming, and likely need a transition.  That
> means I should upload to experimental first, right, to then request the
> transition?  (I'll read up on it later today as a refresher but I guess
> Graham is fully immersed in this practice?)
> 
> Dirk
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Michael & Glenn,

On Fri, 15 Oct 2021 12:26:38 +0200 Michael Biebl  wrote:
> Am 15.10.21 um 11:14 schrieb Michael Biebl:
> > Am 15.10.21 um 07:53 schrieb Glenn Washburn:
> >> Probably the easiest solution would be to exit early from the post install
> >> if the current user is not root. There's probably a more subtle fix that
> >> preserves more functionality (eg. maybe updating the hwdb in PKG_ROOT?),
> >> what ever gets the post install to not fail in this scenario works for me.
> > 
> > Package installations need to be done as root.
> > I don't think the package would benefit if we'd litter the maintainer 
> > scripts with id checks.
> > 
> > Please elobare what the use case is here?
> 
> I notice that you filed multiple bugs against various packages [1].
> I don't think this is particularly helpful as long as dpkg doesn't 
> officially support installations as non-root.
> 
> If you want to allow non-root installations, then this needs to be 
> discussed with the dpkg maintainer and ideally on debian-devel.
> While this might be a laudable goal, my guess is that with the way packages
> are built today, this is not (easily) possible.

Helmut just made me aware of this bug as well as few others by Glenn that talk
about "PKG_ROOT" and asked me to follow up on the topic. Assuming that
"PKG_ROOT" is a typo and actually "DPKG_ROOT" is meant (Glenn, could you
clarify?), then it is important to know that DPKG_ROOT is about root as in the
root path ("/") and not as in the root user. The DPKG_ROOT variable that is set
for maintainer scripts if dpkg is run with --root and
--force-script-chrootless. Helmut and I are working on making the Essential:yes
package set work with DPKG_ROOT and we have submitted patches for all source
packages that are still missing support for it and we have a salsa CI pipeline
that makes sure that our patches allow a bit-by-bit identical chroot compared
to installations without DPKG_ROOT:
https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

While running dpkg with --root and --force-script-chrootless avoids the
chroot() call and thus, allows installing packages without the root user in
theory, the DPKG_ROOT mechanism and the avoidance of the chroot() was *not*
added to dpkg so that packages can be installed as a user other than root. The
DPKG_ROOT mechanism exists because it allows creating foreign architecture
chroots for architectures that do not have qemu support yet or for which
emulation support is too slow. So DPKG_ROOT is something that helps us with
handling chroots for foreign architectures, bootstrapping Debian as well as
using Debian in an embedded systems context.

I agree with what Michael already wrote above. Glenn, before you open bugs
against a number of packages, please explain your use-case to a wider audience.
Maybe on the debian-devel mailing list. Without more information, I don't see a
use-case of being able to install packages without being the root user. For
cases where you still want to do that, there is fakeroot and there are Linux
user namespaces. I maintain a debootstrap alternative called mmdebstrap which
allows one to create a chroot without being root that makes use of fakeroot and
unshare. So I can confirm that it is already possible to run dpkg --install
without being the root user and I currently don't see a reason why adding
support of running maintainer scripts without being uid 0 would be necessary in
practice.

Glenn, if you want to help with DPKG_ROOT, you are welcome to do so! Just write
patches and submit merge requests to the salsa repository linked above. After
your patches are tested and show that they result in a bit-by-bit identical
chroot, you can open a bug against the respective source packages with a
working patch.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#996580: vmdb2 hangs in the mkpart plugin after a lvcreate because of device mapper paths

[Josip Rodin]

Package: vmdb2
Version: 0.22-1
Severity: important

Hi,

I'm trying to replace vmdebootstrap with vmdb2, but this tool still doesn't
work for me with a pretty basic use case based on the manual:

% head -15 myvm.vmdb2.yml
steps:
  - lvcreate: "vg0"
name: "myvm-root"
size: 4G
  - mklabel: msdos
device: "{{ image }}"
  - mkpart: primary
device: "{{ image }}"
start: 0%
end: 100%
tag: /
  - kpartx: "{{ image }}"
  - mkfs: ext4
partition: /
  - mount: /

% sudo vmdb2 myvm.vmdb2.yml --image /dev/vg0/myvm-root --verbose --log 
myvm.vmdb2.log
Load spec file myvm.vmdb2.yml
Exec: ['dpkg', '--print-architecture']
Exec: ['lvcreate', '--name', 'myvm-root', '--size', '4G', 'vg0']
Exec: ['parted', '-s', '/dev/vg0/myvm-root', 'mklabel', 'msdos']
Exec: ['parted', '-m', '/dev/dm-0', 'print']
Exec: ['parted', '-s', '/dev/dm-0', '--', 'mkpart', 'primary', 'ext2', '0%', 
'100%']
Exec: ['parted', '-m', '/dev/dm-0', 'print']

And then it just sits there. Attaching a strace shows a loop:

% sudo strace -p 77503
strace: Process 77503 attached
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=751734}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)
select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
stat("/dev/dm-01", 0x7fff8d70a7f0)  = -1 ENOENT (No such file or directory)

So I looked into the code to find the culprit, and found it in
/usr/lib/python3/dist-packages/vmdb/plugins/mkpart_plugin.py

It passes the device parameter through os.path.realpath() which results in
/dev/dm-0, which in turn is actively bad for the rest of the partitioning
logic as you can't simply tack on the partition numbers onto a device path
like that.

I tried passing in /dev/mapper/vg0-myvm--root as that device parameter, but
realpath() destroys that as well by resolving it into /dev/dm-0 again.

That doesn't happen for parted, though, that one could work:

% sudo parted -m /dev/mapper/vg0-myvm--root print
BYT;
/dev/mapper/vg0-myvm--root:4295MB:dm:512:4096:msdos:Linux device-mapper 
(linear):;
1:1049kB:4295MB:4294MB:::;

>From this output, the diff logic could actually generate
/dev/mapper/vg0-myvm--root1 which would indeed work, but, again, realpath()
is unyielding.

So, maybe detect the use of device mapper paths? If realpath resolves into 
/dev/dm*, abort with an error message saying use /dev/mapper/ as the device?
And then have an exception for /dev/mapper paths so that it doesn't even
try to run realpath on those?

Otherwise I'm going to have to work around this by doing lvcreate and
losetup outside of vmdb2, I guess.

Please fix this. TIA.

-- 
Josip Rodin

Bug#996578: ITS: gsmlib

[Boyuan Yang]

Source: gsmlib
Version: 1.10+20120414.gita5e5ae9a-0.5
Severity: important
X-Debbugs-CC: m...@debian.org

Dear package gsmlib maintainer in Debian,

After looking into the package you maintain (gsmlib, 
https://tracker.debian.org/pkg/gsmlib), I found that this package
received no maintainer updates in the past 13 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to package the latest upstream git snapshot,
clean up packaging and review/fix all Debian bug reports.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Nov 05, 2021) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#996577: duplicity: Name error on backend HubiC (Basidentity)

[BertrandB21]

Package: duplicity
Version: 0.8.17-1+b1
Severity: normal

Dear Maintainer,

Since the change of stable version i gopt an error on duplicty,
I try wiht last version of pyrax

the error :
File 
"/usr/lib/python3/dist-packages/duplicity/backends/pyrax_identity/hubic.py", 
line 35, in 
class HubicIdentity(BaseIdentity):
 NameError: name 'BaseIdentity' is not defined

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

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

Versions of packages duplicity depends on:
ii  gnupg  2.2.27-2
ii  libc6  2.31-13+deb11u2
ii  librsync2  2.3.1-1
ii  python33.9.2-3
ii  python3-fasteners  0.14.1-2
ii  python3-future 0.18.2-5
ii  python3-lockfile   1:0.12.2-2.2

Versions of packages duplicity recommends:
ii  python3-oauthlib  3.1.0-2
ii  python3-paramiko  2.7.2-1
ii  python3-pexpect   4.8.0-2
ii  python3-urllib3   1.26.5-1~exp1
ii  rsync 3.2.3-4+deb11u1

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
pn  par2 
pn  python3-boto 
ii  python3-pip  20.3.4-4
ii  python3-swiftclient  1:3.10.1-2
pn  tahoe-lafs   

-- no debconf information

Bug#996542: Post install fails when run as non-root user and does not respect PKG_ROOT

[Glenn Washburn]

On Fri, 15 Oct 2021 12:26:38 +0200
Michael Biebl  wrote:

> Am 15.10.21 um 11:14 schrieb Michael Biebl:
> > Control: tags -1 + moreinfo
> > 
> > Am 15.10.21 um 07:53 schrieb Glenn Washburn:
> >> Package: udev
> >> Version: 247.3-5
> >>
> >> Probably the easiest solution would be to exit early from the post
> >> install if the current user is not root. There's probably a more subtle
> >> fix that preserves more functionality (eg. maybe updating the hwdb in
> >> PKG_ROOT?), what ever gets the post install to not fail in this
> >> scenario works for me.
> > 
> > Package installations need to be done as root.
> > I don't think the package would benefit if we'd litter the maintainer 
> > scripts with id checks.
> > 
> > Please elobare what the use case is here?

Package installation does not need to be done as root. In fact, many
packages install just fine as a non-root user (even if they were never
intended to be installed that way). In fact, dpkg and apt/apt-get allow
this, though its not a common mode of operation. And this is something
commonly requested. If you search on the various stack exchange sites
and google you'll see lots of people wanting to do non-root installs.

My use case is that I have an unprivileged account on a debian system
and I want to install packages. To avoid dependency hell, I'd like to
use apt/apt-get to figure out the dependencies and download them. If I
already have that, then it would be nice to have apt/apt-get install the
packages via dpkg, not least because I can create a wrapper that allows
other scripts to transparently install as non-root and to a directory
of my choosing, which I've already created.

Now one of the most straight forward ways to solve this problem is to
use chroot to install into another root. However, this is not an
option, as chroot requires privileges I don't have.

And yes there are other ways to skin this cat, for instance, the most
obvious alternative is to use dpkg-deb -X to install to an alternate
root. You still have the dependency hell issue, but that's not
insurmountable by using apt-get -s and parsing the output. The thing
is, this method is more hacky, potentially more error-prone, and
results in something less featureful (eg. dpkg-query doesn't work).

The one thing the dpkg-deb -X method has going for it, is that it does
not run post install scripts. So I wouldn't get the errors I'm getting
because, unfortunately, there isn't a way (that I know of) to tell dpkg
to not run post install scripts on install. But not running post
install also a strike against it. There may be some useful actions
taken in those scripts in making the installed package useful/runnable.
From what I've seen, this is generally not the case, but there's a lot
of packages I haven't looked at.

And my use case is also, not just wanting to install to be run as a
regular user. I want to build a directory tree that will be overlayed
on to the real root in a UML instance. If I didn't need to run the
installed binaries outside the UML, then the propose solution would
work as is. However, because I need to run some binaries outsdie the
UML, I'll need to fix broken symlinks pointing to an absolute path in
the alternate root, which also isn't hard to do. This mostly applied to
unversioned library paths which point to a path with the version (I
believe mostly used in *-dev packages). Something to explore might be
to have all symlink destinations be relative to their location (see
realpath --relative-to).

> 
> I notice that you filed multiple bugs against various packages [1].
> I don't think this is particularly helpful as long as dpkg doesn't 
> officially support installations as non-root.

Can you point me to public documentation confirming this point of view?
My evidence to the contrary is the man page dpkg(1) itself. Under the
--force-* options:

  not-root: Try to (de)install things even when not root.

and

  script-chrootless: Run maintainer scripts without chroot(2)ing into
  instdir even if the package does not support this mode of operation
  (since dpkg 1.18.5).

More evidence for my case can be found in man 5 dpkg.cfg where it
lists several locations that dpkg looks for configuration files. One is
"~/.dpkg.cfg". Now why would it search for a configuration file in the
home directory of a user if running as a non-root user was not
officially allowable?

I think what you really mean is that most packages were not written
with this use case in mind, and I would find that credible. Most don't
really need to have been, but a few do.
> 
> If you want to allow non-root installations, then this needs to be 
> discussed with the dpkg maintainer and ideally on debian-devel.
> While this might be a laudable goal, my guess is that with the way 
> packages are built today, this is not (easily) possible.

Dpkg supports non-root installations perfectly fine and as mentioned I
have a working wrapper script called apt-user, which configures things
such that package installs can be 

Bug#996561: qepcad fails autopkgtests on !amd64, !i386

[Torrance, Douglas]

Control: tags -1 confirmed

On Fri 15 Oct 2021 10:29:40 AM EDT, Nilesh Patra  wrote:

qepcad fails its autopkgtests on every non-x86 arch as seen here.
Can you fix this?


I confirmed that QEPCAD isn't functioning for me locally on an armhf system
(Raspberry Pi).  I'll see if I can track down the issue.

Doug


signature.asc
Description: PGP signature

Bug#996574: ITP: golang-k8s-kube-openapi -- Kubernetes OpenAPI spec generation & serving

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-k8s-kube-openapi
  Version : 0.0~git20211014.b3fe75c-1
  Upstream Author : Kubernetes
* URL : https://github.com/kubernetes/kube-openapi
* License : Apache-2.0
  Programming Lang: Go
  Description : Kubernetes OpenAPI spec generation & serving

 Kube OpenAPI This repo is the home for Kubernetes OpenAPI discovery
 spec generation. The goal is to support a subset of OpenAPI features
 to satisfy kubernetes use-cases but implement that subset with little
 to no assumption about the structure of the code or routes. Thus, there
 should be no kubernetes specific code in this repo.
 .
 There are two main parts:
  - A model generator that goes through .go files, find and generate model
 definitions.
  - The spec generator that is responsible for dynamically generate
 the final OpenAPI spec using web service routes or combining
 other OpenAPI/Json specs.  Contributing Please see CONTRIBUTING.md
 (CONTRIBUTING.md) for instructions on how to contribute.

Bug#996575: qtconnectivity5-examples: Unknown module(s) in QT: nfc

[Bardot Jerome]

Package: qtconnectivity5-examples
Version: 5.15.2-2
Severity: important
X-Debbugs-Cc: bardot.jer...@gmail.com

Dear Maintainer,

After a copy of the content of
/usr/lib/x86_64-linux-gnu/qt5/examples/nfc
in my home and open the .pro

4 error (one by subproject) are display : 
:-1: erreur : Project ERROR: Unknown module(s) in QT: nfc


Maybe i miss something but should examples run without issue ?
Also exemple are not show in qtcreator.


thx for your work.

J.




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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages qtconnectivity5-examples depends on:
ii  dpkg  1.20.9
ii  libc6 2.32-4
ii  libqt5bluetooth5  5.15.2-2
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libqt5nfc55.15.2-2
ii  libqt5qml55.15.2+dfsg-8
ii  libqt5quick5  5.15.2+dfsg-8
ii  libqt5widgets55.15.2+dfsg-12
ii  libstdc++611.2.0-9

qtconnectivity5-examples recommends no packages.

qtconnectivity5-examples suggests no packages.

Bug#996461: nvidia-kernel-dkms: DKMS tree already contains: nvidia-current-470.74

[Drew Parsons]

On 2021-10-15 19:23, Andreas Beckmann wrote:

On 14/10/2021 12.15, Drew Parsons wrote:

Package: nvidia-kernel-dkms
Version: 470.74-1
Severity: serious
Justification: fails to configure

Upgrade to the new nvidia-driver 470.74-1 (nvidia-kernel-dkms) fails
at the configuration step with this error message:

$ sudo aptitude
Performing actions...
Setting up nvidia-kernel-dkms (470.74-1) ...
Removing old nvidia-current-470.74 DKMS files...
Loading new nvidia-current-470.74 DKMS files...
Error! DKMS tree already contains: nvidia-current-470.74
You cannot add the same module/version combo more than once.


What happened earlier?
Did you somehow try to manually install the 470.74 driver from the .run 
file?


No, I didn't try any manual installations. Only upgrading nvidia-driver 
and nvidia-kernel-dkms etc to the version in experimental at times.




What happened at the first configuration attempt of the package?
You should find the full transcript of upgrading to 470 somewhere in
/var/log/apt/term.log*



/var/log/apt/term.log tells me it was upgrading from 470.63.01-1

Nothing unusual in the unpacking step (I guess we can ignore the message 
"Deleting from: /lib/modules/5.14.0-1-amd64/

rmdir: failed to remove '': No such file or directory"),

...
Unpacking nvidia-vdpau-driver:i386 (470.74-1) over (470.63.01-1) ...
Preparing to unpack .../056-nvidia-kernel-dkms_470.74-1_amd64.deb ...
Module nvidia-current-470.63.01 for kernel 5.14.0-1-amd64 (x86_64).
Before uninstall, this module version was ACTIVE on this kernel.

nvidia-current.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.14.0-1-amd64/
rmdir: failed to remove '': No such file or directory
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.



nvidia-current-modeset.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.14.0-1-amd64/
rmdir: failed to remove '': No such file or directory
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module 
version.

...
Deleting module nvidia-current-470.63.01 completely from the DKMS tree.
Unpacking nvidia-kernel-dkms (470.74-1) over (470.63.01-1) ...
Preparing to unpack .../057-nvidia-kernel-support_470.74-1_amd64.deb ...
Unpacking nvidia-kernel-support (470.74-1) over (470.63.01-1) ...
...


Then setup step shows no errors, until
...
Setting up nvidia-vdpau-driver:amd64 (470.74-1) ...
Setting up nvidia-vdpau-driver:i386 (470.74-1) ...
Setting up libgl1-nvidia-glvnd-glx:amd64 (470.74-1) ...
Setting up nvidia-kernel-dkms (470.74-1) ...
Loading new nvidia-current-470.74 DKMS files...
Building for 5.14.0-2-amd64
Building initial module for 5.14.0-2-amd64
+ [ clean = modules ]
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: 
../crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: 
../crypto/bio/bss_file.c:76

sign-file: /root/dkms.key: No such file or directory
Error! Bad exit status 1 for sign tool.
Consult 
/var/lib/dkms/nvidia-current/470.74/5.14.0-2-amd64/x86_64/log/make.log 
for more information.

dpkg: error processing package nvidia-kernel-dkms (--configure):
 installed nvidia-kernel-dkms package post-installation script 
subprocess returned error exit status 11

Setting up libgles-nvidia1:amd64 (470.74-1) ...
Setting up libegl-nvidia0:amd64 (470.74-1) ...
Setting up nvidia-smi (470.74-1) ...
dpkg: dependency problems prevent configuration of nvidia-driver:
 nvidia-driver depends on nvidia-kernel-dkms (= 470.74-1) | 
nvidia-kernel-470.74; however:

  Package nvidia-kernel-dkms is not configured yet.
  Package nvidia-kernel-470.74 is not installed.
  Package nvidia-kernel-dkms which provides nvidia-kernel-470.74 is not 
configured yet.


dpkg: error processing package nvidia-driver (--configure):
 dependency problems - leaving unconfigured
Setting up nvidia-driver-bin (470.74-1) ...


I guess that reference to bss_file.c must be a clue, if not the 
reference to the missing /root/dkms.key


The 470.74/5.14.0-2 make.log in the error message shows no errors 
itself, but the last line is

"Signing /var/lib/dkms/nvidia-current/470.74/build/nvidia.ko"

Drew

Bug#996573: gcc-arm-none-eabi: Please set Rules-Requires-Root: no.

[Vagrant Cascadian]

Source: gcc-arm-none-eabi
Severity: wishlist
Tags: patch

Please consider setting "Rules-Requires-Root: no" in debian/control,
though only after applying the fixes in #996572 so that the package can
build reproducibly!

Patch attached!

live well,
  vagrant
From 96724894c5256a1fa14a742382b00313daa096cb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 15 Oct 2021 17:10:36 +
Subject: [PATCH 3/3] debian/control: Set Rules-Requires-Root to "no".

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 19ca1e40a..9c9d610a9 100644
--- a/debian/control
+++ b/debian/control
@@ -34,6 +34,7 @@ Build-Depends:
  xz-utils,
  libisl-dev,
 Standards-Version: 4.2.0
+Rules-Requires-Root: no
 Homepage: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
 Vcs-Git: https://salsa.debian.org/debian/gcc-arm-none-eabi.git
 Vcs-Browser: https://salsa.debian.org/debian/gcc-arm-none-eabi
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#996572: gcc-arm-none-eabi: reproducible builds: source tarball includes non-deterministic files

[Vagrant Cascadian]

Source: gcc-arm-none-eabi
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness username timestamps fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The file /autom4te.cache/requests includes non-deterministic ordering,
and is shipped inside /usr/src/gcc-arm-none-eabi-source.tar.xz

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/gcc-arm-none-eabi.html

Patch to debian/rules attached which excludes autom4ate.cache from the
tarball, as well as sorting by name, set the user and group ids, and
setting the timestamp using SOURCE_DATE_EPOCH. These additional
normalizations will be needed if Rules-Requires-Root is ever enabled.

It might be worth considering excluding .pc from the tarball as well;
though this isn't strictly necessary for reproducible builds.


This patch alone does not fix all reproducibility issues (e.g. build
paths, which are only tested on unstable and experimental), but with the
patch from #996194 applied, this should become reproducible once it
migrates to bookworm.


Thanks for maintaining gcc-arm-none-eabi!


live well,
  vagrant
From 5d35d46092e41d95d3f9e76d8043c044ddbdca07 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 15 Oct 2021 17:07:51 +
Subject: [PATCH 2/3] debian/rules: Generate tarball reproducibly.

Exclude autom4ate.cache directory (contains autogenerated
non-deterministic files), sort by name, set the user and group ids,
and set timestamp using SOURCE_DATE_EPOCH.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 07d9a2571..8f2e6526a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -101,7 +101,7 @@ override_dh_strip:
 override_dh_install:
 	dh_install -p$(PACKAGE_GCC) --sourcedir $(GCC_DEB_TMP_DIR)
 	mkdir -p $(GCC_SOURCE_DEB_TMP_DIR)/usr/src
-	tar --exclude=build --exclude=.git --exclude=debian -C $(TOP_DIR) -c -f - . | xz -T0 > $(GCC_SOURCE_DEB_TMP_DIR)/usr/src/$(PACKAGE_GCC_SOURCE).tar.xz
+	tar --exclude=build --exclude=.git --exclude=debian --exclude=autom4te.cache --sort=name --mtime="@$(SOURCE_DATE_EPOCH)" --owner=0 --group=0 --numeric-owner -C $(TOP_DIR) -c -f - . | xz -T0 > $(GCC_SOURCE_DEB_TMP_DIR)/usr/src/$(PACKAGE_GCC_SOURCE).tar.xz
 	dh_install -p$(PACKAGE_GCC_SOURCE) --sourcedir $(GCC_SOURCE_DEB_TMP_DIR)
 
 override_dh_compress:
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#996461: nvidia-kernel-dkms: DKMS tree already contains: nvidia-current-470.74

[Andreas Beckmann]

On 14/10/2021 12.15, Drew Parsons wrote:

Package: nvidia-kernel-dkms
Version: 470.74-1
Severity: serious
Justification: fails to configure

Upgrade to the new nvidia-driver 470.74-1 (nvidia-kernel-dkms) fails
at the configuration step with this error message:

$ sudo aptitude
Performing actions...
Setting up nvidia-kernel-dkms (470.74-1) ...
Removing old nvidia-current-470.74 DKMS files...
Loading new nvidia-current-470.74 DKMS files...
Error! DKMS tree already contains: nvidia-current-470.74
You cannot add the same module/version combo more than once.


What happened earlier?
Did you somehow try to manually install the 470.74 driver from the .run 
file?


What happened at the first configuration attempt of the package?
You should find the full transcript of upgrading to 470 somewhere in 
/var/log/apt/term.log*


Andreas

Bug#996571: lutris: since the latest update lutris creates a lutris.log file in $HOME

[mister01x]

Package: lutris
Version: 0.5.9-1
Severity: minor
X-Debbugs-Cc: mister...@web.de

Dear Maintainer,

since the latest upgrade of lutris it creates a lutris.log file in $HOME
whenever a game is started, if the file already exists the log is appended.

While I appreciate the fact that lutris provides logs imho it should not
put them directly in $HOME and instead put it inside of $XDG_STATE_HOME,
into $XDG_DATA_HOME/lutris/ or let the user decide where to safe the log.

Thanks for maintaining lutris

Marcel

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

Kernel: Linux 5.14.12-2-siduction-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lutris depends on:
ii  cabextract   1.9-3
ii  curl 7.74.0-1.3+b1
ii  fluid-soundfont-gs   3.1-5.3
ii  gir1.2-gnomedesktop-3.0  41.0-1
ii  gir1.2-gtk-3.0   3.24.30-3
ii  gir1.2-notify-0.70.7.9-3
ii  gir1.2-webkit2-4.0   2.34.0-1
ii  mesa-utils   8.4.0-1+b2
ii  p7zip16.02+dfsg-8
ii  psmisc   23.4-2
ii  python3  3.9.2-3
ii  python3-dbus 1.2.18-3
ii  python3-distro   1.6.0-2
ii  python3-gi   3.42.0-1+b1
ii  python3-lxml 4.6.3+dfsg-1
ii  python3-magic2:0.4.24-1
ii  python3-pil  8.3.2-1
ii  python3-requests 2.25.1+dfsg-2
ii  python3-setproctitle 1.2.2-2
ii  python3-yaml 5.4.1-1
ii  unzip6.0-26
ii  x11-xserver-utils7.7+8

Versions of packages lutris recommends:
ii  gvfs-backends1.48.1-2
ii  libwine-development  6.0+repack-1
ii  python3-evdev1.4.0+dfsg-1+b1
ii  winetricks   0.0+20210206-2

Versions of packages lutris suggests:
ii  gamemode  1.6.1-1

-- no debconf information

Bug#996570: libapache2-mod-proxy-uwsgi: ProxyPass sends wrong PATH_INFO to uwsgi

[Christopher Odenbach]

Package: libapache2-mod-proxy-uwsgi
Version: 2.4.38-3+deb10u6
Severity: important

Dear Maintainer,

after installing version 2.4.38-3+deb10u6 our uwsgi webservice did not
work anymore. The apache2 config contains the line

 ProxyPass /networks/v1/ 
unix:/var/run/uwsgi/networks-api.socket|uwsgi://networks/v1/ retry=0

A request to

 https://server.uni-paderborn.de/networks/v1/name/imt_infra_ntp

used to result in PATH_INFO set to "/name/imt_infra_ntp", so stripping
off the first two directories "/networks/v1/" as set in the config.

Version 2.4.38-3+deb10u6 contains a security fix for setting PATH_INFO,
but it seems to get confused with directories: In our case PATH_INFO
is set to "/v1/name/imt_infra_ntp" which renders our uwsgi webservice
useless.

Thanks for fixing,

Christopher

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

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

Versions of packages libapache2-mod-proxy-uwsgi depends on:
ii  apache2  2.4.38-3+deb10u5

libapache2-mod-proxy-uwsgi recommends no packages.

libapache2-mod-proxy-uwsgi suggests no packages.

-- no debconf information

Bug#996569: getmail6 naming issues

[Charles Cazabon]

Package: getmail6
Version: 6.14-1

Hi,

I'm the original author of getmail, which was included in the Debian
repositories for a long time (until you dropped most packages depending on
Python 2).  getmail6 is a fork of getmail.  I'm fine with forking; I chose the
GPLv2 for a reason.

However, the getmail6 package contains numerous bugs that are not present in
getmail (they keep coming up, and I have reasons to believe this will continue
to be the case for a significant time), and this is imposing a significant
support burden on me.  It also is harming the reputation of getmail, which has
a long (23 years) history of very, very few bugs.

No matter what the getmail6 documentation says, when users hit a problem with
getmail6, they just web-search "getmail" and end up reporting it to my getmail
users' mailing list, or directly to my personal email.  And they generally do
not mention the version number they're using.  It takes signficant time and
work to actually get to the point where I can point out that they're using
getmail6 and not getmail, and that the bug they've hit is not present in
getmail.

So: fork is fine.  Imposing a large support burden on the original project is
not.  I would appreciate it if this package/project was renamed to something
that does not contain the word "getmail" or anything confusingly similar.  I
don't particularly care what - just as long as the package/project does not
contain "getmail", which will significantly reduce the likelihood of users of
that project from contacting me for support.

I have requested this of the getmail6 author but have not had a positive
response from him yet.  Perhaps Sudip Mukherjee, the Debian package
maintainer, can either help persuade the author of that package to change its
name, or can rename the Debian package if not.

Thank you,

Charles
-- 
--
Charles Cazabon  
Software, consulting, and services available at http://pyropus.ca/
--

Bug#995904: Please add wipefs --recursive

[Chris Hofstaedtler]

Hello Trent W. Buck,

* Trent W. Buck  [211008 04:36]:
> Package: util-linux
> Version: 2.36.1-8
> Severity: wishlist
> File: /sbin/wipefs
> 
> wipefs is not recursive, which leads to this unexpected behaviour:
[..]
> If wipefs was recursive, this sort of thing wouldn't happen.
> I guess libblkid already provides the necessary functionality, and
> zeroing out a few extra blocks is a small I/O cost for the large gain in 
> "principle of least surprise".
> 
> The manpage implicitly suggests to work around this by doing "wipefs 
> /dev/vdb*".
> This works if you are root and the device is visible to the kernel, as above.
> However you are working "rootless" and thus cannot e.g. "sudo kpartx -a", you 
> can't do that.
> You could pass offsets to "wipefs --offset=$((1024*1024)) /tmp/dummy.img", 
> but that's an error-prone pain.

Thank you for your bug report. However I am not sure what exactly
you are asking for. If its a new feature you are asking for, or a
design change, please discuss it on the upstream mailing list:

  E-MAIL:  util-li...@vger.kernel.org
  URL: http://vger.kernel.org/vger-lists.html#util-linux
  ARCHIVE: https://lore.kernel.org/util-linux/

I imagine upstream or other upstream contributors will have ideas
then.

Please reply with a link to the upstream discussion once this has
been discussed.

Thanks,
Chris

Bug#816393: Works now?

[Helge Kreutzmann]

Hello,
for what is worth:
helge@samd:/tmp$ debget nghttp2
Get:1 http://172.16.18.51:/ftp.de.debian.org/debian bullseye/main
amd64 nghttp2 all 1.43.0-1 [14.4 kB]
Fetched 14.4 kB in 0s (117 kB/s)

Best greetings

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


signature.asc
Description: PGP signature

Bug#983977: (no subject)

[Tobias Frost]

Control: tags -1 fixed-upstream

This seems to be fixed upstream with svn commit r391. I'll take a look in 
updating
the package soon(tm)...

--
tobi

Bug#996505: cryptsetup: set CRYPTTAB_OPTION_tries for keyscripts when not explicitly set

[Guilhem Moulin]

On Thu, 14 Oct 2021 at 23:43:32 +0200, Christoph Anton Mitterer wrote:
> I've noted that when there is no explicit tries=n in crypttab, that
> CRYPTTAB_OPTION_tries isn't set either for the keyscripts.

There is a 1:1 mapping between CRYPTTAB_OPTION_* and known options in
crypttab's 4th column, and I think we should keep that invariant.

I guess the default tries=3 is extremely unlikely to change because it's
arguably part of the API.  3rd party scripts might have hardcoded it and
changing it might break things.  I suggest you hardcode it as well.  An
alternative would be to add CRYPTTAB_TRIES_LEFT, but I'm not sure it's
worth the trouble.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#996566: Bug#995566 RFP: ldid -- tool to (pseudo-)codesign Mach-O files

[Nick Chan]

For OpenSSL, it uses OpenSSL 3.

Bug#994941: Additional patch

[Chris Hofstaedtler]

Hello Alexandre,

* Alexandre Ghiti  [211012 15:39]:
> Although the initial patchset works, I think it would be cleaner to
> also change the translation files so that they take into account the
> changes in the partition names.
> 
> I attach 2 debdiff:
> - util_linux_debdiff_2.patch: it can be applied on top of the first
> patch that was already applied.
> - util_linux_debdiff_complete.patch: the debdiff for all the changes,
> the one already applied and the new one.

Thanks for the follow up, but I believe your translation patch is
basically a no-op:
- Your initial patch changed the source strings.
- If my understanding of gettext is correct, the changed source
  strings would just show up untranslated.
- The "translated" strings are not really translations but 1:1
  just the exact same strings as the original source strings.

Translators will pick up the source string change on their own time,
and in the meantime I believe there is no user-visible change.
I would very much like to avoid carrying the translation patch in
Debian for this reason, and just wait for upstream and upstream
translators to do their thing.

Please let me know if I missed something or you have additional
insight :-)

Many thanks,
Chris

Bug#996568: transition: fcl

[Jose Luis Rivero]

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


Dear Release Team:

I'm the maintainer of fcle, upstream has released 0.7.0
version some weeks ago. We have 0.7.0-2 in experimental, it builds
in all arches that it did before (hppa builder segfaults on compilation
but I doubt it has to do with version bump).

ratt rebuilt the dependencies it found, including DART, just fine:
https://build.osrfoundation.org/job/debian-ratt-builder/118/console

"""
2021/10/08 22:35:48 Building package 1 of 1: dart
2021/10/08 22:35:48 DEBUG - sbuild args
[]string{"--arch-all", "--dist=unstable", "--nolog", "dart_6.9.5-4", 
"--extra-package=libfcl-dev_0.7.0-1_amd64.deb", 
"--extra-package=libfcl0.7-dbgsym_0.7.0-1_amd64.deb", 
"--extra-package=libfcl0.7_0.7.0-1_amd64.deb"}
2021/10/08 22:51:04 Build results:
2021/10/08 22:51:04 PASSED: dart
"""

Ben file:

title = "fcl";
is_affected = .depends ~ "libfcl0.6" | .depends ~ "libfcl0.7";
is_good = .depends ~ "libfcl0.7";
is_bad = .depends ~ "libfcl0.6";

Thanks!

Bug#996567: ITP: r-cran-terra -- GNU R spatial data analysis

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-terra -- GNU R spatial data analysis
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-terra
  Version : 1.4
  Upstream Author : Robert J. Hijmans,
* URL : https://cran.r-project.org/package=terra
* License : GPL-3+
  Programming Lang: GNU R
  Description : GNU R spatial data analysis
 Methods for spatial data analysis with raster and vector data. Raster
 methods allow for low-level data manipulation as well as high-level
 global, local, zonal, and focal computation. The predict and interpolate
 methods facilitate the use of regression type (interpolation, machine
 learning) models for spatial prediction, including with satellite remote
 sensing data. Processing of very large files is supported. See the
 manual and tutorials on  to get started.
 'terra' is very similar to the 'raster' package; but 'terra' can do
 more, is easier to use, and it is faster.

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

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Dirk Eddelbuettel]

Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
and I didn't use that.

So a new package will be forthcoming, and likely need a transition.  That
means I should upload to experimental first, right, to then request the
transition?  (I'll read up on it later today as a refresher but I guess
Graham is fully immersed in this practice?)

Dirk

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

Bug#988597: trash-cli version too old

[Jonathan Dowland]

On Wed, Oct 13, 2021 at 10:16:24AM +0100, Jonathan Dowland wrote:

Eyeballing the failures again quickly now, I think the majority of the
failures will be due to not finding the actual test utilities in an
expected place in the chroot, variations on:

   python3: can't open file
   '/<>/.pybuild/cpython3_3.9/build/trash-put': [Errno 2]
   No such file or directory


Expanding on this a bit, the build phase runs

/usr/bin/python3 setup.py build 


Which outputs the following (elided)


running build_py
creating /<>/.pybuild/cpython3_3.9/build/trashcli
copying trashcli/fstab.py -> 
/<>/.pybuild/cpython3_3.9/build/trashcli

...

running build_scripts
creating build
creating build/scripts-3.9
copying and adjusting trash -> build/scripts-3.9

...

Note: the initial 'copying' lines are to a path
/<>/.pybuild/cpython3_3.9/build/trashcli, but the latter
ones are to just "build/scripts-3.9". And indeed, if I run

sbuild --build-failed-commands '%SBUILD_SHELL'

I'm dropped into a shell in the build environment after the test

failure. Right now that's /build/trash-cli-Nkmibk, which has the
unpacked source at trash-cli-0.21.7.24, which corresponds to the
<> substitution in the output above.

I see the path
/build/trash-cli-Nkmibk/trash-cli-0.21.7.24/.pybuild/cpython3_3.9/build,
corresponding to the first set of "copying" lines above, and containing
"tests" and "trashcli". And I see
/build/trash-cli-Nkmibk/trash-cli-0.21.7.24/build/scripts-3.9,
containing the command-line tools, corresponding to the second set of
'copying' lines above.

When the tests are executed, the following is run

cd /<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest tests

And so at the time the tests run the command line tools are not in $PWD
and tests/run_command.py::run_command constructs a path that is not
valid.

So... the question is, why does the "build_py" phase of
distutils/setuptools have the correct path, where is that being
specified? Why doesn't the "build_scripts" phase also have the correct
path, and where can we specify that?

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#996556: ITP: gnome-shell-extension-vertical-overview -- GNOME shell extension for vertical stacked workspaces

[Tobias Frost]

Package is now in NEW.

Repo: https://salsa.debian.org/debian/gnome-shell-extension-vertical-overview

Bug#996566: RFP: ldid -- tool to (pseudo-)codesign Mach-O files

[Nick Chan]

Package: wnpp
Version: N/A; reported 2021-10-15
Severity: wishlist

* Package name: ldid
* Version: 2.1.5-procursus1
* Upstream Author: Hayden Seay 
* URL: https://github.com/ProcursusTeam/ldid
* License: AGPL-3.0
* Description: tool to (pseudo-)codesign Mach-O files

Mach-O files are macOS/iOS/Darwin executables.

This tool has been forked many times over, so there is not a singular
upstream. This is apparently the most maintained fork.

Static Linux binaries are in upstream available at:
https://github.com/ProcursusTeam/ldid/releases/tag/v2.1.5-procursus1

There are no working makefile/build script for Linux in upstream. However,
it could be compiled by

```
cc -c -o lookup2.o lookup2.c
c++ -c -o ldid.o ldid.cpp -std=c++11
c++ -std=c++11 ldid.o lookup2.o -lplist-2.0 -lcrypto -o ldid
```
.

-lplist-2.0 is for libplist-2.0 and -lcrypto is from openssl.

Additionally, there are man pages in upstream in these two files: `ldid.1`
(english) and `ldid.1.zh_TW` (Chinese traditional).

Bug#991761: [Pkg-javascript-devel] Bug#991761: ITP: swc -- A super-fast typescript / javascript compiler written in rust

[Jérémy Lal]

Le ven. 15 oct. 2021 à 16:20, Jonas Smedegaard  a écrit :

> Hi Jérémy,
>
> Quoting Jérémy Lal (2021-08-01 12:01:46)
> > * Package name: swc
>
> What is status on this?
>

Nothing done.


> Would you be interested in my help on creating+maintaining this?
>

Of course ! I created this ITP to lure someone into it :)
First thing is to make sure debian rustc version matches upstream
requirement...

Jérémy

Bug#996565: nmudiff: misleading delay header on non-dd use case

[Raúl Benencia]

Source: devscripts
Severity: minor
Tags: patch
X-Debbugs-Cc: r...@kalgan.cc


Dear maintainer,

When running "nmudiff" with "--non-dd" set, the header "[Replace XX
with correct value]" should not be printed because a non-dd doesn't
have privileges to push to the deferred upload queue.

Please consider applying the attached patch.

Thank you.
>From 5bc171e521a80d9fdb83cad6cfa74368acdc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ra=C3=BAl=20Benencia?= 
Date: Fri, 15 Oct 2021 07:55:04 -0700
Subject: [PATCH] nmudiff: fix misleading delay header on non-dd use case

---
 scripts/nmudiff.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/nmudiff.sh b/scripts/nmudiff.sh
index 3fd6aee2..b3987bfd 100755
--- a/scripts/nmudiff.sh
+++ b/scripts/nmudiff.sh
@@ -371,7 +371,7 @@ fi
 
 TMPNAM="$(mktemp -t "$(basename "$1").X")"
 
-if [ "$NMUDIFF_DELAY" = "XX" ] && [ "$NMUDIFF_TEMPLATE" = "" ]; then
+if [ "$NMUDIFF_DELAY" = "XX" ] && [ "$NMUDIFF_TEMPLATE" = "" ] && ! [ 
"$NMUDIFF_NONDD" = "yes" ]; then
 DELAY_HEADER="
 [Replace XX with correct value]"
 fi
-- 
2.30.2

Bug#993219: [debian-mysql] Bug#993219: mariadb-server-core: Akonadi database - mysql_upgrade fails always with "FATAL ERROR: Can't execute 'mysqlcheck'"

[Ulrich Beckmann]

Otto,

I don't have the crashed database available. What I say is, that I have 3 
working Akonadi databases, one in a fresh Bullseye install.

In any case the call of mysql_upgrade fails.
bequimao@bullseye-kde-vm:~$ mysql_upgrade --defaults-file=/home/
bequimao/.local/share/akonadi/mysql.conf --socket=/run/user/1000/akonadi/
mysql.socket -v
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Can't execute 'mysqlcheck'
bequimao@bullseye-kde-vm:~$ 

So any future database migration would fail. A database migration in the past 
might have failed, see mysql.err in the attachments to message #17.

Ulrich

Bug#996564: lftp: copyright file is inaccurate

[Bastian Germann]

Source: lftp
Version: 4.8.4-2
Severity: important

lftp's copyright file references the correct license file GPL-3 but says it was version 2. 
Also, there is code by other copyright holders (FSF; Bjorn Reese and Daniel Stenberg) that 
is partly licensed under additional licenses.

Bug#996561: qepcad fails autopkgtests on !amd64 and !i386

[Nilesh Patra]

On Fri, 15 Oct 2021 19:59:40 +0530 Nilesh Patra  wrote:
> Package: qepcad
> Version: 1.74+ds-2
> Severity: serious
> X-Debbugs-Cc: dtorra...@piedmont.edu
> 
> Hi Doug,
> 
> qepcad fails its autopkgtests on every non-x86 arch as seen here.
> Can you fix this?
> 
> https://qa.debian.org/excuses.php?package=qepcad

Precisely, the error is:

qepcad < debian/tests/anai && qepcad < debian/tests/edge-square-product && 
qepcad < debian/tests/quartic && qepcad < debian/tests/hong-liska-steinberg && 
cad2d < debian/tests/cad2d
autopkgtest [07:03:40]: test command1: [---
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
bash: line 1:  2418 Aborted qepcad < 
debian/tests/positive-semidefinite
autopkgtest [07:06:04]: test command1: ---]
autopkgtest [07:06:04]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 134
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#993824: transition: libqalculate

[Sebastian Ramacher]

On 2021-10-03 21:42:59, Sebastian Ramacher wrote:
> Hi Norbert, Phil
> 
> On 2021-09-27 10:22:31 +0900, Norbert Preining wrote:
> > Hi Phil,
> > 
> > I pushed a commit with initial changes for libqalculate20-data dummy
> > package. Please take a look.
> 
> Any news regarding libqalculate20-data?

Friendly ping. I can NMU if needed.

Cheers
-- 
Sebastian Ramacher

Bug#996539: ITP: sqlitecpp -- a smart and easy to use C++ SQLite3 wrapper

[Eduard Bloch]

Control: merge 996539 948701

Hallo,
* YaNing Lu [Fri, Oct 15 2021, 05:18:13AM]:
>Package: wnpp
>Severity: wishlist
>X-Debbugs-Cc: [1]debian-de...@lists.debian.org

Did my response to the private mail get lost?

Since you apparently prefered not to take over #948701, I will merge
them in BTS so they get closed together automatically.

Best regards,
Eduard.

Bug#996563: ITP: ifcfg -- Python cross-platform network interface discovery (ifconfig/ipconfig/ip)

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ifcfg
  Version : 0.22
  Upstream Author : BJ Dierkes
* URL : https://github.com/ftao/python-ifcfg
* License : BSD
  Programming Lang: Python
  Description : Python cross-platform network interface discovery 
(ifconfig/ipconfig/ip)

Ifcfg is a cross-platform library for parsing ifconfig and ipconfig output in
Python. It is useful for pulling information such as IP, Netmask, MAC Address,
Hostname, etc.

Maintainership ideally would be shared with python team

Bug#984186: libloki: ftbfs with GCC-11

[Lukas Märdian]

Package: libloki
Version: 0.1.7-3
Followup-For: Bug #984186
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com
Control: tags -1 patch

Dear Maintainer,

GCC 11 defaults to C++17 which does not allow dynamic exception specifications
anymore: https://gcc.gnu.org/gcc-11/porting_to.html

In Ubuntu, the attached patch was applied to replace the throw(...)
specifications in the recommended way:

  * Fix FTBFS with GCC-11 by avoiding dynamic exception specifications


Thanks for considering the patch.

Cheers,
  Lukas

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

Kernel: Linux 5.13.0-16-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
only in patch2:
unchanged:
--- libloki-0.1.7.orig/include/loki/SmallObj.h
+++ libloki-0.1.7/include/loki/SmallObj.h
@@ -459,7 +459,7 @@
 /// @note MSVC complains about non-empty exception specification lists.
 static void * operator new ( std::size_t size )
 #else
-static void * operator new ( std::size_t size ) throw ( std::bad_alloc 
)
+static void * operator new ( std::size_t size ) noexcept(false)
 #endif
 {
 typename MyThreadingModel::Lock lock;
@@ -468,7 +468,7 @@
 }
 
 /// Non-throwing single-object new returns NULL if allocation fails.
-static void * operator new ( std::size_t size, const std::nothrow_t & 
) throw ()
+static void * operator new ( std::size_t size, const std::nothrow_t & 
) noexcept
 {
 typename MyThreadingModel::Lock lock;
 (void)lock; // get rid of warning
@@ -482,7 +482,7 @@
 }
 
 /// Single-object delete.
-static void operator delete ( void * p, std::size_t size ) throw ()
+static void operator delete ( void * p, std::size_t size ) noexcept
 {
 typename MyThreadingModel::Lock lock;
 (void)lock; // get rid of warning
@@ -512,8 +512,7 @@
 /// @note MSVC complains about non-empty exception specification lists.
 static void * operator new [] ( std::size_t size )
 #else
-static void * operator new [] ( std::size_t size )
-throw ( std::bad_alloc )
+static void * operator new [] ( std::size_t size ) noexcept(false)
 #endif
 {
 typename MyThreadingModel::Lock lock;
@@ -523,7 +522,7 @@
 
 /// Non-throwing array-object new returns NULL if allocation fails.
 static void * operator new [] ( std::size_t size,
-const std::nothrow_t & ) throw ()
+const std::nothrow_t & ) noexcept
 {
 typename MyThreadingModel::Lock lock;
 (void)lock; // get rid of warning
@@ -537,7 +536,7 @@
 }
 
 /// Array-object delete.
-static void operator delete [] ( void * p, std::size_t size ) throw ()
+static void operator delete [] ( void * p, std::size_t size ) noexcept
 {
 typename MyThreadingModel::Lock lock;
 (void)lock; // get rid of warning

Bug#996562: ITP: pytest-repeat -- pytest-repeat is a plugin for pytest that makes it easy to repeat a single test, or multiple tests, a specific number of times.

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pytest-repeat
  Version : 0.9.1
  Upstream Author : Bob Silverberg and others developers in pytest-repeat repo
* URL : https://github.com/pytest-dev/pytest-repeat
* License : MPLv2.0
  Programming Lang: Python
  Description : pytest-repeat is a plugin for pytest that makes it easy to 
repeat a single test, or multiple tests, a specific number of times.

Ideally maintainership will be shared with the debian-python team

Bug#996561: qepcad fails autopkgtests on !amd64, !i386

[Nilesh Patra]

Package: qepcad
Version: 1.74+ds-2
Severity: serious
X-Debbugs-Cc: dtorra...@piedmont.edu

Hi Doug,

qepcad fails its autopkgtests on every non-x86 arch as seen here.
Can you fix this?

https://qa.debian.org/excuses.php?package=qepcad

Nilesh

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

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

Bug#991761: [Pkg-javascript-devel] Bug#991761: ITP: swc -- A super-fast typescript / javascript compiler written in rust

[Jonas Smedegaard]

Hi Jérémy,

Quoting Jérémy Lal (2021-08-01 12:01:46)
> * Package name: swc

What is status on this?

Would you be interested in my help on creating+maintaining this?


 - 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#996560: mailman3 breaks web url

[Eggert Ehmke]

Package: mailman3-full
Version: 3.2.1-1

I installed the package mailman3-full and configured the files in 
/etc/mailman3
/usr/share/mailman3-web/

Next I created an apache virtual host entry in 
/etc/apache2/sites-available/
 
and used the content of 
/etc/mailman3/apache.conf
as a template. 


I enabled the apache modules proxy and proxy_uwsgi.

After restarting the services apache2 and mailman3-web, I accessed the website 
in a 
browser via url:
https://lists.my-tld/mailman3/


The page showed:
 *Seite nicht gefunden* 
Diese Seite ist entweder nicht vorhanden, oder sie wurde an einen anderen Ort 
verschoben. 


With DEBUG = True, it shows:
 *Page not found (404)* 
*Request Method:*
GET
*Request URL:*
https://lists.my-tld/mailman//


Using the URLconf defined in urls, Django tried these URL patterns, in this 
order: 
 1. ^$ 
 2. ^postorius/ 
 3. ^hyperkitty/ 
 4. ^user-profile/delete$ [name='mm_user_account_delete'] 
 5. ^user-profile/$ [name='mm_user_profile'] 
 6. ^accounts/ 
 7. ^admin/ 
The current path, /, didn't match any of these. 
Note that in the Request URL, the name "mailman3" has been replaced by 
"mailman", 
making the URL invalid. 
This behavior could be reproduced in two separate installations on different 
machines.


As a workaround, I changed this line in the apache vhost config from:
ProxyPass /mailman3 
unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost
to:
   ProxyPass /mailman 
unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost
Note the other references to /mailman3 had to stay to access the static css 
files.
This solved the problem for me, but that is not an acceptable behaviour. 


Also note that the mailing lists had been installed some weeks before and ran 
fine during 
that time. 
Some update in the Debian system caused this fault.
 
   I am using Debian GNU/Linux 10.11, kernel 4.19.0-16-amd64
  and libc6 2.28-10

Kind Regards
Eggert

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Dirk Eddelbuettel]

Graham,

On 15 October 2021 at 13:34, Graham Inggs wrote:
| > Yes. And I follow upstream. They didn't change :-/
| 
| Right, so please speak to your upstream.  Dropping (or renaming) a

Done.

Looks like a 2.8 release is coming, so maybe the soname gets cleaned up there
and we get to do (yet another full) transition (which is really the best way
to handle this under changes).

| symbol is changing the ABI in a backward-incompatible way, and they
| need to bump the SONAME (or revert the change).
| 
| This is not something Debian-specific, this is how shared objects in
| Unix work [1][2].

Thanks for the pointers. As you may imagine, I actually already have come
across this practice in my 26 years with Debian .

Best,  Dirk

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

Bug#995720: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Build-Depends:
perl6-readline: perl6-tap-harness

Bug#995398: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Depends:
debian-design: design-desktop-web

Bug#996558: knot: FTBFS with new automake (putting "none required" into build flags)

[Lukas Märdian]

Package: knot
Version: 3.0.5-1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

knot fails to build from source with newer autotools:


libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wall -DNDEBUG -Wall -Wshadow -Werror=format-security -Werror=implicit 
-Werror=attributes -Wstrict-prototypes -Wl,-Bsymbolic-functions -flto=auto 
-Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -o .libs/kxdpgun 
utils/kxdpgun/kxdpgun-load_queries.o utils/kxdpgun/kxdpgun-main.o 
utils/kxdpgun/kxdpgun-popenve.o none required  ./.libs/libcontrib.a 
./.libs/libknot.so -lcap-ng
/usr/bin/ld: cannot find none: No such file or directory
/usr/bin/ld: cannot find required: No such file or directory
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:3354: kxdpgun] Error 1


The problem was fixed upstream:
https://gitlab.nic.cz/knot/knot-dns/-/commit/70dc4a5c85b65678662854c18a3475371ef4a8eb

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

  * Fix FTBFS with new automake, using upstream commit
+ debian/patches/70dc4a5c85b65678662854c18a3475371ef4a8eb.patch


Thanks for considering the patch.

Cheers,
  Lukas

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

Kernel: Linux 5.13.0-16-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
knot-3.0.5/debian/patches/70dc4a5c85b65678662854c18a3475371ef4a8eb.patch 
knot-3.0.5/debian/patches/70dc4a5c85b65678662854c18a3475371ef4a8eb.patch
--- knot-3.0.5/debian/patches/70dc4a5c85b65678662854c18a3475371ef4a8eb.patch
1970-01-01 01:00:00.0 +0100
+++ knot-3.0.5/debian/patches/70dc4a5c85b65678662854c18a3475371ef4a8eb.patch
2021-10-15 15:14:17.0 +0200
@@ -0,0 +1,60 @@
+From 70dc4a5c85b65678662854c18a3475371ef4a8eb Mon Sep 17 00:00:00 2001
+From: Daniel Salzman 
+Date: Wed, 14 Jul 2021 14:29:13 +0200
+Subject: [PATCH] configure: fix AC_SEARCH_LIBS usage if the result is cached
+ with value 'none required'
+
+---
+ configure.ac | 14 +-
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 0d3552045..c8f1f4548 100644
+--- a/configure.ac
 b/configure.ac
+@@ -613,9 +613,10 @@ AS_IF([test "$enable_cap_ng" != "no"],[
+ AC_CHECK_HEADER([cap-ng.h], [
+   save_LIBS="$LIBS"
+   AC_SEARCH_LIBS([capng_apply], [cap-ng], [
+-enable_cap_ng=yes
+-cap_ng_LIBS="$ac_cv_search_capng_apply"
++AS_IF([test "$ac_cv_search_capng_apply" != "none required"],
++  [cap_ng_LIBS="$ac_cv_search_capng_apply"], [cap_ng_LIBS=])
+ AC_SUBST([cap_ng_LIBS])
++enable_cap_ng=yes
+   ])
+   LIBS="$save_LIBS"
+ ])
+@@ -631,7 +632,8 @@ AS_IF([test "$enable_cap_ng" = yes],
+ 
+ save_LIBS="$LIBS"
+ AC_SEARCH_LIBS([pthread_create], [pthread], [
+-  pthread_LIBS="$ac_cv_search_pthread_create"
++  AS_IF([test "$ac_cv_search_pthread_create" != "none required"],
++[pthread_LIBS="$ac_cv_search_pthread_create"], [pthread_LIBS=])
+   AC_SUBST([pthread_LIBS])
+ ],[
+   AC_MSG_ERROR([pthreads not found])
+@@ -640,7 +642,8 @@ LIBS="$save_LIBS"
+ 
+ save_LIBS="$LIBS"
+ AC_SEARCH_LIBS([dlopen], [dl], [
+-  dlopen_LIBS="$ac_cv_search_dlopen"
++  AS_IF([test "$ac_cv_search_dlopen" != "none required"],
++[dlopen_LIBS="$ac_cv_search_dlopen"], [dlopen_LIBS=])
+   AC_SUBST([dlopen_LIBS])
+ ],[
+   AC_MSG_ERROR([dlopen not found])
+@@ -649,7 +652,8 @@ LIBS="$save_LIBS"
+ 
+ save_LIBS="$LIBS"
+ AC_SEARCH_LIBS([pow], [m], [
+-  math_LIBS="$ac_cv_search_pow"
++  AS_IF([test "$ac_cv_search_pow" != "none required"],
++[math_LIBS="$ac_cv_search_pow"], [math_LIBS=])
+   AC_SUBST([math_LIBS])
+ ],[
+   AC_MSG_ERROR([math not found])
+-- 
+GitLab
+
diff -Nru knot-3.0.5/debian/patches/series knot-3.0.5/debian/patches/series
--- knot-3.0.5/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ knot-3.0.5/debian/patches/series2021-10-15 15:14:17.0 +0200
@@ -0,0 +1 @@
+70dc4a5c85b65678662854c18a3475371ef4a8eb.patch

Bug#996559: minimap2 FTBFS on !x86

[Adrian Bunk]

Source: minimap2
Version: 2.22+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=minimap2=2.22%2Bdfsg-1

...
cc -c -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -fopenmp-simd -O3 -DSIMDE_ENABLE_OPENMP 
-DUSE_SIMDE -DSIMDE_ENABLE_NATIVE_ALIASES -g -Wall -O2 -Wc++-compat  -msse2 
-Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_KALLOC  ksw2_ll_sse.c -o ksw2_ll_sse.o
cc: error: unrecognized command-line option ‘-msse2’
make[2]: *** [Makefile:64: ksw2_ll_sse.o] Error 1

Bug#994979: python-tomli: please make the build reproducible

[Stefano Rivera]

FYI, this will be fixed in the next dh-python upload: 
https://salsa.debian.org/python-team/tools/dh-python/-/commit/2ef6ff13748984258d5da000c17d9cdad707b9ae

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#993294: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Build-Depends:
libjxmpp-java: libidn11-java

Bug#983488: O: lftp -- needs new maintainer

[Bastian Germann]

On Mon, 22 Mar 2021 10:16:20 +0100 n...@debian.org wrote:

Yes you are right. After your email I worked on the package but the
bullseye freeze policy doesn't allow new package versions anymore.:(


Hi Noël,

I have filed a request for a new lftp release at #995920.
It is now long after the bullseye release, so please consider uploading your work or make 
this ticket a RFH or orphan again.


Thanks,
Bastian

Bug#630750: [Adduser-devel] Bug#630750: default NAME_REGEX value in /etc/adduser.conf is incorrect

[Goebel . Matthias . Da]

I can confirm this bug. I just came across this on Ubuntu 20.04. I 
prefer the proposal by Laurent Martelli.


Summarizing the discussion, it looks like this bug can be fixed by 
simply replacing the line

  #NAME_REGEX="^[a-z][-a-z0-9_]*\$"
in adduser.conf by
  #NAME_REGEX="^[a-z][-a-z0-9_]*$"

Best,
tueftler11

Bug#996557: linux-image-5.14.0-3-686-pae-unsigned: just about every sse2 program crashes with a SIGFPE

[Jiri Palecek]

Package: src:linux
Version: 5.14.12-1
Severity: serious
X-Debbugs-Cc: Jiri Palecek 

Dear Maintainer,

when I booted my system with the latest kernel from unstable, many of
the applications didn't work. That includes plasmashell (so I couldn't
log in into plasma) and chromium.

I ran xterm (which worked) and some of these failing programs under gdb
and found they all tripped on some sse2 instructions with a
SIGFPE. However, all the programs work under the kernel from
linux-image-5.14.0-2-.

Regards
Jiri Palecek

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

** Model information

** PCI devices:
00:00.0 RAM memory [0500]: NVIDIA Corporation MCP61 Host Bridge [10de:03e2] 
(rev a1)
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 ISA bridge [0601]: NVIDIA Corporation MCP61 LPC Bridge [10de:03e1] (rev 
a2)
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: nForce2_smbus
Kernel modules: i2c_nforce2

00:01.2 RAM memory [0500]: NVIDIA Corporation MCP61 Memory Controller 
[10de:03f5] (rev a2)
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0 Controller 
[10de:03f2] (rev a3) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:04.0 PCI bridge [0604]: NVIDIA Corporation MCP61 PCI bridge [10de:03f3] (rev 
a1) (prog-if 01 [Subtractive decode])
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn-
Capabilities: 

00:05.0 Audio device [0403]: NVIDIA Corporation MCP61 High Definition Audio 
[10de:03f0] (rev a2)
Subsystem: ASUSTeK Computer Inc. MCP61 High Definition Audio [1043:840c]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:06.0 IDE interface [0101]: NVIDIA Corporation MCP61 IDE [10de:03ec] (rev a2) 
(prog-if 8a [ISA Compatibility mode controller, supports both channels switched 
to PCI native mode, supports bus mastering])
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: pata_amd
Kernel modules: pata_amd, ata_generic

00:07.0 Bridge [0680]: NVIDIA Corporation MCP61 Ethernet [10de:03ef] (rev a2)
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: forcedeth
Kernel modules: forcedeth

00:08.0 IDE interface [0101]: NVIDIA Corporation MCP61 SATA Controller 
[10de:03f6] (rev a2) (prog-if 85 [PCI native mode-only controller, supports bus 
mastering])
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: sata_nv
Kernel modules: sata_nv, ata_generic

00:08.1 IDE interface [0101]: NVIDIA Corporation MCP61 SATA Controller 
[10de:03f6] (rev a2) (prog-if 85 [PCI native mode-only controller, supports bus 
mastering])
Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard [1043:83a4]
Control: I/O+ Mem+