Bug#993286: apt-cacher-ng: Fail to fetch data from Debian repo at dl.google.com

[丰]

Package: apt-cacher-ng
Version: 3.6.4-1
Severity: normal

Dear Maintainer, on the apt-cacher-ng proxy server, I have seen many errors of
apt-cacher-ng failing to fetch data from dl.google.com .

Is it because Google is using object storage to serve their data?

   * What led up to the situation?
apt update via an apt-cacher-ng proxy

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Just run **apt update** on a client with apt-cacher-ng configured

   * What was the outcome of this action?
Err:24 http://dl.google.com/linux/chrome/deb stable InRelease
 Connection failed [IP: 10.0.0.102 3142]
...
W: Failed to fetch
http://dl.google.com/linux/chrome/deb/dists/stable/InRelease
Connection failed
[IP: 10.0.0.102 3142]

If I try fetching the content with curl, the result is like the following:

curl -I http://dl.google.com/linux/chrome/deb/stable/Release
HTTP/1.1 404 Not Found
...

curl -I http://dl.google.com/linux/chrome/deb/dists/stable/InRelease
HTTP/1.1 200 OK
...
Content-Length: 1811
In /var/log/apt-cacher-ng/apt-cacher.err , there are quite a few
lines like the following:

Mon Aug 30 10:55:10 2021|Failed to move stale item
dl.google.com/linux/chrome/deb/dists/stable/InRelease out of the way:
No such file or directory

   * What outcome did you expect instead?
   Get:24 http://dl.google.com/linux/chrome/deb stable InRelease [xxx kB]

-- System Information:
Debian Release: 11
Architecture: amd64 (x86_64)

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  dpkg 1.20.9
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-2
ii  libssl1.11.1.1k-1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-6
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  
ii  libfuse2  2.9.9-5

Regards,
Fonzie

Bug#993285: ITP: xilinx-bootgen -- boot image converter for Xilinx ARM SoCs

[Nobuhiro Iwamatsu]

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

* Package name: xilinx-bootgen
  Version : 2021.1
  Upstream Author : Xilinx Inc
* URL : https://github.com/Xilinx/bootgen.git
* License : Apache-2.0
  Programming Lang: C++
  Description : boot image converter for Xilinx ARM SoCs

  xilinx-bootgen provides tools to generate a boot image (BOOT.BIN)
  for Xilinx ARM SoC (Zynq-7000, Zynq UltraScale + MPSoC, etc) devices.
  This also provides features such as boot authentication and OpenSSL-based
  encryption.

Bug#990858: dask: reproducible builds: embeds build user home directory in html documentation

[Diane Trout]

Hi sorry for being slow about looking at this.

This is the ultimate answer after updating the package and looking to
see where the config block is generated I found this text.

   *Note: for historical reasons we also look in the ``~/.dask``
   directory for config files.  This is deprecated and will soon be
   removed.*
   
I think upstream just removed the block that was causing the
unreproducible change you spotted.

I started thinking that the patch probably wouldn't work correctly
because python IO functions won't internally expand "~" when trying to
open files. So, depending on how widely dask.config.paths is used in
dask,  that might cause problems when opening files.

Thanks you for encouraging me to make better packages.

Diane

On Fri, 2021-07-09 at 07:08 -0700, Vagrant Cascadian wrote:
> Package: dask
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: environment
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> The home directory is embedded in html documentation:
> 
>  
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/dask.html
> 
>   /usr/share/doc/python-dask-doc/html/configuration.html
> 
>   ...
> ['/etc/dask',·'/usr/etc/dask',·'/nonexist
> ent/first-build/.config/dask',·'/nonexistent/first-
> build/.dask'] ...
> vs.
>   ...
> ['/etc/dask',·'/usr/etc/dask',·'/nonexist
> ent/second-build/.config/dask',·'/nonexistent/second-
> build/.dask'] ...
> 
> 
> The attached patch fixes this by modifying dask/config.py to not
> expand
> the tilde to the user home dir.
> 
> While the patch does make the documentation reproducible, it needs
> some
> run-time testing to ensure that dask works correctly with the patch
> applied (e.g. the configuration is checked for in the user's
> ~/.config/dask and ~/.dask directories)! Someone familiar with dask
> should test this before applying the patch!
> 
> If it causes issues, taking a deeper look into fixing this in the
> documentation will be needed.
> 
> 
> With this patch applied, dask should become reproducible in the
> tests.reproducible-builds.org infrastructure.
> 
> 
> Thanks for maintaining dask!
> 
> 
> live well,
>   vagrant



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

Bug#993284: grub-efi-amd64: grub-install: using the option "--bootloader-id='custom name'" boots into the GRUB console instead of the menu

[L. Manuel Arrieta]

Package: grub-efi-amd64
Version: 2.04-20
Severity: normal

I am in the process of making a diagnose & manteinance Debian setup onto a
USB stick that can boot in whatever PC drops in my hands. Working on
having a custom EFI boot entry I encountered that adding the --bootloade-id
option in grub-install makes the system boot into the GRUB console
instead of the usual GRUB menu. Not GRUB rescue, the regular GRUB
console.

I can get in there by manually bring it
up with the following GRUB commands:

set prefix=(hd1,gpt3)/boot #or whenever /boot/grub resides
insmod normal
normal

I tried almost all combinations of adding --recheck, --no-nvram and
--removable, but it seems that it the route isn't EFI/debian or EFI/BOOT
the system won't boot on the menu.

Weird enought I copied grub.cfg into EFI/[custom-name] and it seems to
work, but the frame of the menu is compsided of the unknown square
unicode character

Currently testing on a MacBook Pro 9,2, did some test on a brand-new
Lenovo L340

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda4 / btrfs rw,relatime,ssd,space_cache,subvolid=256,subvol=/@rootfs 0 0
/dev/sda3 /boot ext4 rw,relatime 0 0
/dev/sda2 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

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

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

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

export menuentry_id_option

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

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

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod btrfs
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
f54db690-2754-45a1-99f9-89dd272a4268
else
  search --no-floppy --fs-uuid --set=root f54db690-2754-45a1-99f9-89dd272a4268
fi
font="/@rootfs/usr/share/grub/unicode.pf2"
fi

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

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod btrfs
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
f54db690-2754-45a1-99f9-89dd272a4268
else
  search --no-floppy --fs-uuid --set=root f54db690-2754-45a1-99f9-89dd272a4268
fi
insmod png
if background_image 
/@rootfs/usr/share/desktop-base/homeworld-theme/grub/grub-4x3.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-f54db690-2754-45a1-99f9-89dd272a4268' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 
--hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  
fb944508-a5a3-48b4-b4df-8037ae333f1d
else
  search --no-floppy --fs-uuid --set=root 
fb944508-a5a3-48b4-b4df-8037ae333f1d
fi
echo'Loading Linux 5.10.0-8-amd64 ...'
linux   /vmlinuz-5.10.0-8-amd64 

Bug#993282: bullseye-pu: package galera-4 26.4.9-0+deb11u1

[Otto Kekäläinen]

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

New upstream version 26.4.9 includes multiple bug fixes, see
https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.9.txt

Getting the latest version to Bullseye is important as the upstream
bugs might cause data loss or data to drift in the Galera cluster.


Changelog:

galera-4 (26.4.9-0+deb11u1) bullseye; urgency=medium

  [ Otto Kekäläinen ]
  * New upstream release 26.4.9. Includes multiple bug fixes, see

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.9.txt
  * Restore CK_TIMEOUT_MULTIPLIER in debian rules to avoid unnecassary
test failures due to slow builders

  [ Andreas Beckmann ]
  * Solve circular Conflicts with galera-3 by no longer providing a virtual
galera package (Closes: #990708)

 -- Otto Kekäläinen   Sun, 29 Aug 2021 20:05:11 -0700

Full debdiff attached.


debian-26.4.9-0+deb11u1.debdiff.xz
Description: application/xz


debian-26.4.9-0+deb11u1.debdiff.stat.xz
Description: application/xz

Bug#993265: RFS: runit/2.1.2-42 -- system-wide service supervision

[Adam Borowski]

On Sun, Aug 29, 2021 at 07:02:49PM +0200, Lorenzo Puliti wrote:
>  * Package name: runit
>Version : 2.1.2-42

>  runit (2.1.2-42) unstable; urgency=medium
>  .
>* Release to unstable
>* getty-run: add hvc0 service, disabled by default:
>this is usually needed by Xen hypervisor
>* Add a default-syslog virtual service:
>to increase portability, services that log to syslog
>can depend on this rather than on a specific
>syslog daemon
>* shutdown.c:
>- try to fix FTBFS on Hurd (Closes: #992629)
>- distinguish between halt and shutdown flags:
>  The -r flag ( as reboot) now only works with shutdown;
>  Add a -f flag to shutdown (skip fsck next boot);
>  Add -F flag to shutdown (force fsck next boot);
>  The -f (as force a shutdown) and -w/--wtmp-only flags now
>   only work with halt.
>  (Closes: #992631)
>- Add a -n flag to halt, to skip sync() before reboot/poweroff;
>  also, always check for runit.nosync flag file before invoking
>  sync()  (Closes: #992641)
>- make halt '-f' flag a noop when runit is init. This way runit
>  can use its own code to reboot/poweroff the system; users
>  can still use the long '--force' option to force a shutdown
>  without signaling the init (Closes: #899246)
>* Update shutdown(8) manpage
>* Bump Standards Version to 4.6.0, no change required
>* Update lintian overrides for 'alternative init but not init.d script'

Uploaded.

That "default-syslog" that's consists of a 10min sleep looks strange...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#993133: bullseye-pu: package shiro/1.3.2-4+deb11u1

[Roberto C . Sánchez]

I removed the top line of the change log (the security team reference),
rebuilt, and re-uploaded.  Thanks again for all the help and for your
patience with my mistake.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#990340: glances: contains prebuilt javascript without source

[Daniel Echeverri]

Hello!

El mar, 10 de ago. de 2021 a la(s) 14:54, Alexis Murzeau (amub...@gmail.com)
escribió:

> Control: tag -1 + patch
>
> On Tue, 29 Jun 2021 01:44:06 +0530 Pirate Praveen <
> prav...@onenetbeyond.org> wrote:
> > It uses webpack to build.
> >
> >
> https://github.com/nicolargo/glances/blob/develop/glances/outputs/static/package.json#L28
> >
> > cd glances/outputs/static && webpack
> >
> > in debian/rules with required build dependencies added should work. Most
> build dependencies are already packaged.
> > --
> > Sent from my p≡p for Android.
>
> Most (non-dev) dependencies are not in Debian [0] (like angular) so
> I've made a MR [1] that simply remove pre-built files.
>
> This makes the remote web interface probably useless, but the package
> can still be used for most usages (I guess, in standalone mode for
> example, which is the only mode I use).
>
> [1] npm2deb output on package.json (modified to add required "name" key):
> Dependencies:
> NPM   Debian
> glances-web-ui (FIX_ME version)   None
> ├─ angular (^1.7.9)   None
> ├─ angular-hotkeys (^1.7.0)   None
> ├─ bootstrap (^3.4.1) None
> ├─ favico.js (^0.3.10)None
> └─ lodash (^4.17.15)  node-lodash
> (4.17.21+dfsg+~cs8.31.189.20210220-1)
>
> Build dependencies:
> NPM   Debian
> clean-webpack-plugin (^0.1.19)None
> copy-webpack-plugin (^4.6.0)  node-copy-webpack-plugin
> (5.1.2+~cs9.0.2-4)
> css-loader (^0.28.11) node-css-loader
> (5.0.1+~cs14.0.5-2)
> del (^2.2.1)  node-del (5.1.0-2)
> exports-loader (^0.7.0)   node-exports-loader
> (1.1.1-2)
> file-loader (^1.1.11) node-file-loader
> (6.2.0-2)
> html-loader (^0.5.5)  None
> less (^3.10.3)less.js (3.13.0+dfsg-5)
> less-loader (^4.1.0)  node-less-loader
> (5.0.1-2)
> ngtemplate-loader (^2.0.1)None
> node-sass (^4.14.0)   node-node-sass
> (4.14.1+git20200512.e1fc158+dfsg-4)
> sass-loader (^6.0.7)  None
> style-loader (^0.20.3)node-style-loader
> (2.0.0-2)
> url-loader (^0.6.2)   node-url-loader (4.1.1-3)
> webpack (^3.12.0) node-webpack
> (5.6.0+~cs6.4.0-1~exp2)
>
>
> [0] https://salsa.debian.org/debian/glances/-/merge_requests/2
>
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|
>
>
This week, I will work to new revision of glances to fix this problem.

Alexis, really Thanks you very much for the MR!!, although I don't like the
idea of break web interface, I think we don't have many options.

Johannes Schauer Marin Rodrigues, Do you agree with this solution?

Regards

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1

[Roberto C . Sánchez]

I removed the top line of the change log (the security team reference),
rebuilt, and re-uploaded.  Thanks again for all the help and for your
patience with my mistake.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#993279: tty-solitaire: please make the build reproducible

[Chris Lamb]

Source: tty-solitaire
Version: 1.3.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
tty-solitaire could not be built reproducibly.

This is because it embedded the build path in the documentation via
--usage and help2man:

 -usage: \fI\,/build/1st/tty\-solitaire\-1.3.0/ttysolitaire\/\fP [OPTIONS]
 +usage: \fI\,/build/2/tty\-solitaire\-1.3.0/2nd/ttysolitaire\/\fP [OPTIONS]

A patch is attached that changes the usage output to not include
the full contents of argv[0], but strip them using basename(3).

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0001-reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0001-reproducible-build.patch  2021-08-30 
03:19:25.835174888 +0100
@@ -0,0 +1,22 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-08-30
+
+--- tty-solitaire-1.3.0.orig/src/ttysolitaire.c
 tty-solitaire-1.3.0/src/ttysolitaire.c
+@@ -1,5 +1,6 @@
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -33,7 +34,7 @@ int main(int argc, char *argv[]) {
+   {"no-background-color", no_argument, _background_color, 1},
+   {0, 0, 0, 0}};
+ 
+-  program_name = argv[0];
++  program_name = basename(argv[0]);
+ 
+   while ((option = getopt_long(argc, argv, "hvp:", options, _index)) !=
+  -1) {
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2021-08-30 03:18:51.789327094 +0100
@@ -0,0 +1 @@
+0001-reproducible-build.patch

Bug#993280: wpa_supplicant: EAPOL: Supplicant port status: Unauthorized

[Hor Jiun Shyong]

Package: wpa_supplicant
Version: 2.9.0-21

wpa_supplicant -iwlx503eaaa688e4 -c/etc/wpa -dd -Dnl80211
...
wlx503eaaa688e4: WPS: UUID based on MAC address:
dd4dc2bd-f55e-5989-94db-b911fe0980b0
ENGINE: Loading builtin engines
ENGINE: Loading builtin engines
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: Supplicant port status: Unauthorized
nl80211: Skip set_supp_port(unauthorized) while not associated
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
...

I have tested on 2 different laptops (builtin wifi) and also with an USB
wifi adapter.  All produce the same result:  "EAPOL: Supplicant port
status: Unauthorized".

I am using Debian GNU/Linux testing/bookworm, kernel 5.10.0-8-amd64 #1 SMP
Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux and libc6 2.31-17


Regards,
Hor Jiun Shyong 何俊雄

Bug#993171: mutter: Is it time to stop patching synaptics support back in?

[Daniel van Vugt]

Libinput is enough for most people, although it does have some touchpad 
sloppiness on some laptops that I only know how to fix with Synaptics. I don't 
know if people are actually making use of it though...


It might be a better idea to drop the Synaptics patch and we can propose patches 
to Libinput instead.



On 28/8/21 6:43 pm, Simon McVittie wrote:

Source: mutter
Version: 40.2.1-1
Severity: normal
X-Debbugs-Cc:  daniel.van.v...@canonical.com

We are currently patching both mutter and gnome-control-center to reinstate
synaptics support, a change that was specifically rejected by upstream in
.

This seems to have been intended to be a temporary thing for Ubuntu 18.04.
Since then, we've had two stable releases of Debian and two LTS releases
of Ubuntu, and GNOME in Debian has switched to Wayland by default; so
it seems like it might be worth revisiting that decision. Do we still
need the synaptics X11 driver, or is libinput now enough?

 smcv

Bug#922545: [pkg-lxc-devel] Bug#922545: lxc: FTBFS on hppa - symbol mismatch

[John David Anglin]

On 2019-02-19 4:54 a.m., Pierre-Elliott Bécue wrote:
> I'll need more information to action your bug.
With 1:4.0.10-1, the only missing symbol is lxc_log_category_seccomp@Base 
1:3.0.2.

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/liblxc1/DEBIAN/symbols doesn't match 
completely debian/liblxc1.symbols
--- debian/liblxc1.symbols (liblxc1_1:4.0.10-1_hppa)
+++ dpkg-gensymbolssWsm0O    2021-08-27 19:27:05.880833302 +
@@ -340,7 +340,7 @@
  lxc_log_category_process_utils@Base 1:4.0.4
  lxc_log_category_rbd@Base 1:3.0.2
  lxc_log_category_rsync@Base 1:3.0.2
- lxc_log_category_seccomp@Base 1:3.0.2
+#MISSING: 1:4.0.10-1# lxc_log_category_seccomp@Base 1:3.0.2
  lxc_log_category_selinux@Base 1:3.0.2
  lxc_log_category_start@Base 1:3.0.2
  lxc_log_category_state@Base 1:3.0.2

The same error occurs on alpha, m68k, sh4 and sparc64.

I see in the build log:
Build-Depends: bash-completion, debhelper-compat (= 13), dh-apparmor, dh-exec, 
docbook2x, doxygen, graphviz, libapparmor-dev, libcap-dev,
libgnutls28-dev, liblua5.2-dev, libpam0g-dev, libseccomp-dev [!alpha !hppa 
!m68k !sh4 !sparc64], libselinux-dev, linux-libc-dev, pkg-config

libseccomp-dev is available on hppa but not on the other arches.  lxc build 
successfully on hppa if I include the libseccomp-dev
dependency.  Wasn't able to fix symbol issue.

Regards,
Dave Anglin

-- 
John David Anglin  dave.ang...@bell.net

Bug#993278: systemd unit warns about "Special user nobody"

[Antoine Beaupre]

Package: irtt
Version: 0.9.0-2+b17
Severity: normal

I get this when i `systemctl daemon-reload` here:

aoû 29 20:03:56 angela systemd[1]: /lib/systemd/system/irtt.service:9: Special 
user nobody configured, this is not safe! 

I suspect it might be because User=nobody is used in the service
file... If you need any dumb user, why not use DynamicUser=?

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 irtt depends on:
ii  libc6  2.31-13

irtt recommends no packages.

irtt suggests no packages.

-- no debconf information

Bug#967047: plymouth-start.service: Unit configured to use KillMode=none

[Antoine Beaupre]

Package: plymouth
Version: 0.9.5-3
Followup-For: Bug #967047

> Here is the MR:
https://salsa.debian.org/debian/plymouth/-/merge_requests/3

LGTM. Any reason why this isn't merged? Upstream adopted it, although
not on both units and they also used:

IgnoreOnIsolate=true

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 plymouth depends on:
ii  init-system-helpers  1.60
ii  initramfs-tools  0.140
ii  libc62.31-13
ii  libdrm2  2.4.104-1
ii  libplymouth5 0.9.5-3
ii  lsb-base 11.1.0
ii  systemd  247.3-6
ii  udev 247.3-6

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 11.0.3
ii  plymouth-themes  0.9.5-3

-- no debconf information

Bug#993277: buster-pu: package krb5/1.17-3+deb10u3

[Sam Hartman]

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


[ Reason ]
This is the same no-dsasecurity fix and memory leak fix I submitted to bullseye.

[ Impact ]

Authenticated attackers can crash the KDC.
Independently there is a memory leak that a user reported as bothering them.

[ Tests ]

I've run autopkgtests against buster to confirm that the code
generally works.  This is an upstream patch that there are tests for
at least on upstream trunk to confirm the DOS has been fixed.

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
comxlex, alternatives available.)

[ Cxecklist ]
  [x] *all* changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in (old)stable

diff --git a/debian/.git-dpm b/debian/.git-dpm
index a67f6f6c72..fcd6a7f36e 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-e860e33ab6bda2e20c3671ba34b114ad81219622
-e860e33ab6bda2e20c3671ba34b114ad81219622
+668523c82a2446609f3eab8688c8837c59b97de2
+668523c82a2446609f3eab8688c8837c59b97de2
 a75eb54fd955cbf7a8ac44e527fd0e400e87844a
 a75eb54fd955cbf7a8ac44e527fd0e400e87844a
 krb5_1.17.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index 9b8237f05e..45d55810ea 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+krb5 (1.17-3+deb10u3) buster; urgency=high
+
+  * Fix KDC null dereference crash on FAST request with no server field,
+CVE-2021-37750, Closes: #992607
+  * Fix memory leak in krb5_gss_inquire_cred, Closes: #991140
+
+
+ -- Sam Hartman   Sun, 29 Aug 2021 16:23:02 -0600
+
 krb5 (1.17-3+deb10u2) buster-security; urgency=high
 
   * Import upstream patch for CVE-2021-36222, Closes: #991365
diff --git 
a/debian/patches/0014-Fix-KDC-null-deref-on-TGS-inner-body-null-server.patch 
b/debian/patches/0014-Fix-KDC-null-deref-on-TGS-inner-body-null-server.patch
new file mode 100644
index 00..223bcb0e25
--- /dev/null
+++ b/debian/patches/0014-Fix-KDC-null-deref-on-TGS-inner-body-null-server.patch
@@ -0,0 +1,45 @@
+From d2ced8994880ee278f92f4277e1a90ed0835208f Mon Sep 17 00:00:00 2001
+From: Greg Hudson 
+Date: Tue, 3 Aug 2021 01:15:27 -0400
+Subject: Fix KDC null deref on TGS inner body null server
+
+After the KDC decodes a FAST inner body, it does not check for a null
+server.  Prior to commit 39548a5b17bbda9eeb63625a201cfd19b9de1c5b this
+would typically result in an error from krb5_unparse_name(), but with
+the addition of get_local_tgt() it results in a null dereference.  Add
+a null check.
+
+Reported by Joseph Sutton of Catalyst.
+
+CVE-2021-37750:
+
+In MIT krb5 releases 1.14 and later, an authenticated attacker can
+cause a null dereference in the KDC by sending a FAST TGS request with
+no server field.
+
+ticket: 9008 (new)
+tags: pullup
+target_version: 1.19-next
+target_version: 1.18-next
+
+(cherry picked from commit d775c95af7606a51bf79547a94fa52ddd1cb7f49)
+---
+ src/kdc/do_tgs_req.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/src/kdc/do_tgs_req.c b/src/kdc/do_tgs_req.c
+index 587342a6c9..622b48fc53 100644
+--- a/src/kdc/do_tgs_req.c
 b/src/kdc/do_tgs_req.c
+@@ -201,6 +201,11 @@ process_tgs_req(krb5_kdc_req *request, krb5_data *pkt,
+ status = "FIND_FAST";
+ goto cleanup;
+ }
++if (sprinc == NULL) {
++status = "NULL_SERVER";
++errcode = KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN;
++goto cleanup;
++}
+ 
+ errcode = get_local_tgt(kdc_context, >realm, header_server,
+ _tgt, _tgt_storage);
diff --git 
a/debian/patches/0015-Fix-defcred-leak-in-krb5-gss_inquire_cred.patch 
b/debian/patches/0015-Fix-defcred-leak-in-krb5-gss_inquire_cred.patch
new file mode 100644
index 00..95467220b9
--- /dev/null
+++ b/debian/patches/0015-Fix-defcred-leak-in-krb5-gss_inquire_cred.patch
@@ -0,0 +1,42 @@
+From 668523c82a2446609f3eab8688c8837c59b97de2 Mon Sep 17 00:00:00 2001
+From: Greg Hudson 
+Date: Wed, 21 Jul 2021 13:44:30 -0400
+Subject: Fix defcred leak in krb5 gss_inquire_cred()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Commit 1cd2821c19b2b95e39d5fc2f451a035585a40fa5 altered the memory
+management of krb5_gss_inquire_cred(), introducing defcred to act as
+an owner pointer when the function must acquire a default credential.
+The commit neglected to update the code to release the default cred
+along the successful path.  The old code does not trigger because
+cred_handle is now reassigned, so the default credential is leaked.
+
+Reported by Pavel Březina.
+
+(a minimal alternative to commit 593e16448e1af23eef74689afe06a7bcc86e79c7)
+
+ticket: 9016
+version_fixed: 1.18.4
+
+(cherry picked from commit b92be484630b38e26f5ee4bd67973fbd7627009c)
+---
+ src/lib/gssapi/krb5/inq_cred.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git 

Bug#993276: bullseye-pu: package krb5/1.18.3-6+deb11u1

[Sam Hartman]

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


[ Reason ]

Fixing one no-DSA security advisory an an memory leak that was actually 
bothering a user enough to get tracked down.
I've confirmed that package passes autopkgtest on bullseye.

[ Impact ]
Authenticated attackers can crash a KDC and if they do it fast enough it won't 
auto-restart.
A memory leak will persist.

[ Tests ]

Upstream has introduced tests to confirm the fixes.
The changes are very small and targeted.

[ Risks ]

Small changes easily reviewed.

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

[ Changes ]
diff --git a/debian/changelog b/debian/changelog
index f4beefd80c..0be31136f4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+krb5 (1.18.3-6+deb11u1) bullseye; urgency=medium
+
+  * Fix KDC null dereference crash on FAST request with no server field,
+CVE-2021-37750, Closes: #992607
+  * Fix memory leak in krb5_gss_inquire_cred, Closes: #991140
+
+
+ -- Sam Hartman   Sun, 29 Aug 2021 16:38:12 -0600
+
 krb5 (1.18.3-6) unstable; urgency=high
 
   * Pull in upstream patch to fix CVE-2021-36222 (KDC NULL dereference),
diff --git 
a/debian/patches/0011-Fix-KDC-null-deref-on-TGS-inner-body-null-server.patch 
b/debian/patches/0011-Fix-KDC-null-deref-on-TGS-inner-body-null-server.patch
new file mode 100644
index 00..970a80cc89
--- /dev/null
+++ b/debian/patches/0011-Fix-KDC-null-deref-on-TGS-inner-body-null-server.patch
@@ -0,0 +1,44 @@
+From: Greg Hudson 
+Date: Tue, 3 Aug 2021 01:15:27 -0400
+Subject: Fix KDC null deref on TGS inner body null server
+
+After the KDC decodes a FAST inner body, it does not check for a null
+server.  Prior to commit 39548a5b17bbda9eeb63625a201cfd19b9de1c5b this
+would typically result in an error from krb5_unparse_name(), but with
+the addition of get_local_tgt() it results in a null dereference.  Add
+a null check.
+
+Reported by Joseph Sutton of Catalyst.
+
+CVE-2021-37750:
+
+In MIT krb5 releases 1.14 and later, an authenticated attacker can
+cause a null dereference in the KDC by sending a FAST TGS request with
+no server field.
+
+ticket: 9008 (new)
+tags: pullup
+target_version: 1.19-next
+target_version: 1.18-next
+
+(cherry picked from commit d775c95af7606a51bf79547a94fa52ddd1cb7f49)
+---
+ src/kdc/do_tgs_req.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/src/kdc/do_tgs_req.c b/src/kdc/do_tgs_req.c
+index 241f34e..386ed5f 100644
+--- a/src/kdc/do_tgs_req.c
 b/src/kdc/do_tgs_req.c
+@@ -208,6 +208,11 @@ process_tgs_req(krb5_kdc_req *request, krb5_data *pkt,
+ status = "FIND_FAST";
+ goto cleanup;
+ }
++if (sprinc == NULL) {
++status = "NULL_SERVER";
++errcode = KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN;
++goto cleanup;
++}
+ 
+ errcode = get_local_tgt(kdc_context, >realm, header_server,
+ _tgt, _tgt_storage, _tgt_key);
diff --git 
a/debian/patches/0012-Fix-defcred-leak-in-krb5-gss_inquire_cred.patch 
b/debian/patches/0012-Fix-defcred-leak-in-krb5-gss_inquire_cred.patch
new file mode 100644
index 00..3c81bf0666
--- /dev/null
+++ b/debian/patches/0012-Fix-defcred-leak-in-krb5-gss_inquire_cred.patch
@@ -0,0 +1,41 @@
+From: Greg Hudson 
+Date: Wed, 21 Jul 2021 13:44:30 -0400
+Subject: Fix defcred leak in krb5 gss_inquire_cred()
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Commit 1cd2821c19b2b95e39d5fc2f451a035585a40fa5 altered the memory
+management of krb5_gss_inquire_cred(), introducing defcred to act as
+an owner pointer when the function must acquire a default credential.
+The commit neglected to update the code to release the default cred
+along the successful path.  The old code does not trigger because
+cred_handle is now reassigned, so the default credential is leaked.
+
+Reported by Pavel Březina.
+
+(a minimal alternative to commit 593e16448e1af23eef74689afe06a7bcc86e79c7)
+
+ticket: 9016
+version_fixed: 1.18.4
+
+(cherry picked from commit b92be484630b38e26f5ee4bd67973fbd7627009c)
+---
+ src/lib/gssapi/krb5/inq_cred.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/src/lib/gssapi/krb5/inq_cred.c b/src/lib/gssapi/krb5/inq_cred.c
+index a8f2541..cd8384d 100644
+--- a/src/lib/gssapi/krb5/inq_cred.c
 b/src/lib/gssapi/krb5/inq_cred.c
+@@ -197,9 +197,7 @@ krb5_gss_inquire_cred(minor_status, cred_handle, name, 
lifetime_ret,
+ mechs = GSS_C_NO_OID_SET;
+ }
+ 
+-if (cred_handle == GSS_C_NO_CREDENTIAL)
+-krb5_gss_release_cred(minor_status, (gss_cred_id_t *));
+-
++krb5_gss_release_cred(minor_status, );
+ krb5_free_context(context);
+ *minor_status = 0;
+ return((lifetime == 

Bug#973428: rtl8712u firmware isn't installed on installation bootstrap

[Holger Wansing]

Control: tag -1 moreinfo

Sam Imberman  wrote (Fri, 30 Oct 2020 08:20:27 -0400):
> The installer did not succeed in setting up my wireless network card
> properly.
> This is a Netis WF-2106 USB wireless card. It looks to me like it failed to
> load the rtl8712u firmware, but I'm not sure why.
> I'm attaching the debug logs.
> This is using a bleeding-edge installation image but I've had similar
> results with other less-recent images like the normal Testing one.

Would you be in the position for testing this with a current bullseye
installer?
There have been major improvements regarding firmware installation 
shortly before the release of Bullseye.
You will need to use one of the unofficial images with firmware included 
for such test:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/


Thanks
Holger


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

Bug#967896: Failed to load firmware chunk for iwlwifi Intel(R) Dual Band Wireless AC 9560 on debian-installer

[Holger Wansing]

Control: tag -1 moreinfo

Pier Paolo Franco  wrote:
> Debian installer warns about missing firmware for iwlwifi Intel wireless
> AC9560, so I manually copied over (on subsequent attempt)
> - debian packages (firmware-misc-nonfree, firmware-nonfree,
> firmware-iwlwifi),
> - tried to get ucodes (34, 38, 41) from USB drive (grabbed from
> https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/buster/current/),
> 
> - manually copied ucodes avaible for Debian buster in /lib/firmware and
> outside in /lib/ (iwlwifi-9000-pu-jf-b0-34, 38, 41 and 43 .ucode)
> - iwlwifi-9000-pu-jf-b0-34 from
> https://www.intel.it/content/www/it/it/support/articles/05511/network-and-i-o/wireless-networking.html
> 
> Neither works. This is a blocking issue on my Lenovo Yoga C640 without any
> LTE or ethernet fallback.

Would you be in the position for testing this with a current bullseye
installer?
There have been major improvements regarding firmware installation 
shortly before the release of Bullseye.
You will need to use one of the unofficial images with firmware included 
for such test:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/


Thanks
Holger



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

Bug#992624: systemd: logind.conf.d

[Josh Triplett]

On Sun, Aug 22, 2021 at 03:33:23PM +, Clint Adams wrote:
> On Sun, Aug 22, 2021 at 10:56:34AM +0200, Michael Biebl wrote:
> > Hm, I'm a bit torn on this. If we go this route, then in order to be
> > consistent, we'd have to create a whole bunch of such directories, basically
> > for all those files:
> 
> I understand the desire to be consistent, and I don't want to argue
> for or against it, so I'll just talk about my experience.
> 
> On laptops I override HandleLidSwitchExternalPower (and sometimes
> HandleLidSwitch).  Historically this has meant dealing with the
> conffile handling question on every single update.  Seeing this
> time that there is now a drop-in directory available means the
> possibility that I can just put a file in there and never have
> to answer that question again.
> 
> The lack of the directory makes me question whether I have the
> path correct or if logind will actually look there.  I have gone
> ahead and made the directory myself though, and placed a
> lidswitch.conf therein, but if the directory had been there already
> I would have just blindly assumed that it would work (probably even
> if I had failed to name it with a ".conf" suffix).
> 
> So, is it worth it?  I don't know either.

I added the support for some of these .d directories upstream, and I had
these exact kinds of drop-ins in mind. I have a configuration .deb that
I install on various systems for this exact bit of configuration:

~$ dpkg -L josh-config-logind
/.
/etc
/etc/systemd
/etc/systemd/logind.conf.d
/etc/systemd/logind.conf.d/josh-config-logind.conf
/usr
/usr/share
/usr/share/doc
/usr/share/doc/josh-config-logind
/usr/share/doc/josh-config-logind/changelog.gz
/usr/share/doc/josh-config-logind/copyright
~$ cat /etc/systemd/logind.conf.d/josh-config-logind.conf
[Login]
HandleLidSwitch=lock

(I should actually update those configuration packages to install their
configuration in /usr rather than /etc.)

I would very much prefer that we *not* add a bunch of empty directories
in /etc, or for that matter in /usr. The manpages specifically list the
paths for this, and those paths do work. And those directories will
naturally come into existence when a package installs a file into them,
and disappear when nothing installs files into them.

I personally find it *much* easier to get a handle on a system's
configuration in /etc when I can see at a glance what configuration
directories actually contain configuration files, without having a pile
of empty directories or empty configuration files.

I'd like to request that, now that the release has happened, we change
systemd's install-sysconfdir option to "false".

- Josh Triplett

Bug#969631: can base-passwd provide the user _apt?

[Colin Watson]

On Sun, Aug 29, 2021 at 11:31:05AM -0700, Russ Allbery wrote:
> Colin Watson  writes:
> > I think it's an interesting idea and worth pursuing, but on the face of
> > it it seems that this would end up violating policy 9.2.2:
> 
> >   "Globally allocated by the Debian project, the same on every Debian
> >   system."
> 
> > ... because the UID of the _apt user in fact wouldn't be the same on
> > every Debian system, and I can imagine that this might cause trouble
> > somewhere.
> 
> My first reaction is that from a strictly Policy perspective you may be
> reading that requirement too strictly.

Certainly possible, and also it's extremely rare for issues about the
global static range to come up at all so we've never really litigated
the exact boundaries of this text.

> I would read that as a statement of intention, not a requirement: the
> intent is for this UID to be the same on every Debian system, but this
> may not be the case in practice due to upgrades.  (Which seems
> obviously true or we could never add a new user.)

It's only an issue for users that were already created by some other
package (unless you count the small number of non-system users that
might conflict with any addition, in the absence of "_" prefixes and the
like).

This is also literally the first reasonably compelling case there's been
for adding a new entry to passwd.master in my time as base-passwd
maintainer (since 2002).

> That said, it does feel weird to switch to this sort of static allocation
> and not have a migration strategy for existing systems and leave them on
> an old UID.  I know that it's not an explicit design goal of the project,
> but I like the idea that continuously upgraded systems will converge on
> the state that they would get if they were newly-installed, and that seems
> valuable for long-term upgrade support.
> 
> My intuition is also that the case where a UID change will cause problems,
> namely:
> 
> >   I'm mostly just worried about users using file:/ or copy:/ methods
> >   and having given _apt access to them, they'd break.
> 
> is relatively rare (but maybe I'm wrong about this?), so I'm not sure that
> it outweighs the simplicity advantages of converging on the same UID in
> the long run.

It does feel likely to be rare, but maybe Julian or somebody else on
deity@ can elaborate on whether this is something they've seen much in
the wild.

A UID migration would also require changing the ownership of (at least)
/var/cache/apt/archives/partial, /var/lib/apt/lists/auxfiles, and
/var/lib/apt/lists/partial.  Maybe something like "find /etc/apt
/var/cache/apt /var/lib/apt -user _apt" would make this less fragile,
but it still seems like an awkward thing to be doing in base-passwd's
postinst.  Helmut said in the original bug report that "libapt always
chowns it to _apt"; I don't know how reliable this is or whether libapt
does it for all the relevant directories.  If it's absolutely reliable
then maaaybe we could skip that step, though it feels a bit risky.

> >   I think it'd be best if we don't change existing _apt users, but only
> >   dealt with new systems for now. I mean we could prompt users about
> >   changing the uid
> 
> This is certainly a gentler migration, but I think the prompt or providing
> some simple migration path would be valuable so that, in the long run,
> people can converge their systems to the new configuration.  Maybe a
> compromise would be to make the prompt have a fairly low urgency level?
> We could then tell people in the release notes that if they're not using
> _apt in some special way, they can dpkg-reconfigure base-passwd and let it
> migrate the UID.

Conceivable.  I'm not sure how much that would actually help converge
the mass of systems, numerically.

> > Of course, another approach to the overall problem might be
> > declarative user creation in dpkg, e.g. #685734 and
> > https://wiki.debian.org/Teams/Dpkg/Spec/SysUser.  But that's clearly
> > a lot of work, and this change wouldn't preclude it.
> 
> This does seem like clearly the right solution in the long run for all
> problems of this sort, though.  I wouldn't want to add many statically
> allocated UIDs.  (But if anything qualifies for one, _apt is a
> reasonable candidate.)

It's a slightly weird one too, because (aside from the file:/ or copy:/
case) it seems mostly like the sort of user that could be anonymous
outside of the lifetime of an apt process, analogous to systemd's
DynamicUser.  But I guess there's no way to do something like that
outside of systemd, much less on systems that don't run systemd at all.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails

[Hilmar Preuße]

On 8/29/21 10:12 AM, Andreas Günther wrote:

Am Samstag, 28. August 2021, 17:09:37 CEST schrieb Hilmar Preuße:


Hi,


Hmm, weird: the modules in question should be provided by
proftpd-mod-wrap & proftpd-mod-crypto, should should have installed.
Could you check if the files /usr/lib/proftpd/mod_tls.so &
/usr/lib/proftpd/mod_wrap.so do exist?

Hilmar

Hi Hilmar,

both,
/usr/lib/proftpd/mod_wrap.so
and
/usr/lib/proftpd/mod_tls.so
doesn't exist.

But that also seems logical to me, because in order to be able to install
proftpd-mod-wrap and proftpd-mod-crypto, proftpd-core has to be completely
installed because of the dependencies. But the installation of proftpd-core
fails right from the start.

dpkg: Error while editing the package proftpd-core (--configure):
   The "installed proftpd-core script of the post-installation package"
subprocess returned the error value 1
dpkg: Dependency problems prevent configuration of proftpd-mod-crypto:
   proftpd-mod-crypto depends on proftpd-core (= 1.3.7a + dfsg-12); but:
   Package proftpd-core is not yet configured.

At the moment I think something is going wrong with the installation of
proftpd-core.


When splitting off the wrap and the crypto modules into own packages I
put them into recommends to make sure they are installed.

proftpd-dfsg (1.3.7a-2) unstable; urgency=medium

  [ Hilmar Preusse ]
  * Move modules depending on libsodium & libwrap0 into own packages.
New packages are recommended.

Francesco later decided to put them into Suggests:

proftpd-dfsg (1.3.7a+dfsg-3) unstable; urgency=medium

  * Moved -mod-wrap and -mod-crypto among Suggests, thanks to changes
to default
template for modules.conf.

So, you probably have a custom modules.conf and refused to use the one
from the package maintainers. So solution could be: either install these
packages or use the modules.conf from the package. Please send the
output of

apt install proftpd-core proftpd-basic proftpd-mod-crypto proftpd-mod-wrap

I'm wondering why this does not work: all packages should be unpacked
before the proftpd-core is configured, so all files needed to configure
proftpd-core should be available.

Hilmar
--
#206401 http://counter.li.org

Bug#993275: ng: stores wrong paths to cp and ls if built on merged-/usr system

[Simon McVittie]

Source: ng
Version: 1.5~beta1-9
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If gnunet is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or installing
the usrmerge package into an existing installation), the paths to cp and
ls are recorded in the binary package as being in /usr/bin, rather than the
canonical /bin.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ng.html

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends=usrmerge and once without.

I suspect the same thing would happen if ng was built on a system where
/bin and /usr/bin had instead been unified via a symlink farm.

The problematic situation is if the package is *built* on a unified-/usr
system, but *used* on a non-unified-/usr system. In this situation,
/usr/bin/cp, etc. exist on the build system but not on the system where
the package will be used, resulting in the features that use this
executable not working correctly.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends=usrmerge.

Some developers advocate unifying /bin with /usr/bin via a symlink farm
in /bin instead of merged-/usr, but that strategy would have a similar
practical effect on this particular package, and the same solution would
be required.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

smcv
>From 483dd087b93e02d30a7bf1f022c35d3f88f74d07 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 29 Aug 2021 22:15:25 +0100
Subject: [PATCH] d/rules: Specify canonical paths of cp, ls, mv, rmdir

When ng is built on a system where both /usr/bin/cp and /bin/cp
exist (either merged-/usr or via a symlink farm), this results in storing
/usr/bin/cp in the installed programs, which will not work as intended
on systems where only the traditional path /bin/cp exists.

ls is in a similar situation. mv and rmdir are checked by ./configure
but not hard-coded anywhere; give them the same treatment for symmetry.

Signed-off-by: Simon McVittie 
---
 debian/rules | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index 3363b4b..9f0f48b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,13 @@ export CC
 
 DOCDIR = usr/share/doc/ng-common
 
+configure_environment = \
+	ac_cv_path_cp_cmd=/bin/cp \
+	ac_cv_path_ls_cmd=/bin/ls \
+	ac_cv_path_mv_cmd=/bin/mv \
+	ac_cv_path_rmdir_cmd=/bin/rmdir \
+	$(NULL)
+
 configure: configure-stamp
 configure-stamp:
 	dh_testdir
@@ -34,21 +41,21 @@ build-stamp:
 
 	# vanilla ng-latin
 	cp -p debian/config-latin.h config.h
-	./configure
+	$(configure_environment) ./configure
 	$(MAKE)
 	mv ng ng-latin
 	$(MAKE) confclean
 
 	# ng-cjk
 	cp -p debian/config-cjk.h config.h
-	./configure
+	$(configure_environment) ./configure
 	$(MAKE)
 	mv ng ng-cjk
 	$(MAKE) confclean
 
 	# ng-cjk-canna
 	cp -p debian/config-cjk-canna.h config.h
-	./configure --enable-canna
+	$(configure_environment) ./configure --enable-canna
 	$(MAKE) CANNADEF="-DCANNA" CANNALIB="-lcanna"
 	cp -p ng ng-cjk-canna
 
-- 
2.33.0

Bug#993214: mpi4py: autopkgtest regression around 2021-08-25

[Drew Parsons]

On 2021-08-30 00:05, Drew Parsons wrote:

On 2021-08-29 20:27, Graham Inggs wrote:
Even better would be to add the following section to 
debian/tests/control:


# Dummy test so that changes to other packages trigger our 
autopkgtests

# on ci.debian.net
Test-Command: /bin/true
Depends: libpmix-dev,
libucx-dev [amd64 arm64 ppc64el],
Restrictions: hint-testsuite-triggers

Refer
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst



That's a great idea, Graham.  I assume Lisandro will have 3.1 fixed
soon for s390x since he's identified the cause of the failure. So I'll
make the change in experimental rather than unstable.




Graham, when I run autopkgtest, it skips the dummy test, which is what 
we want, but it does so with the message


  SKIP unknown restriction hint-testsuite-triggers


"unknown restriction", is this normal?  If so it's a bit misleading 
since the hint is not supposed to be "unknown".


Drew

Bug#993214: mpi4py: autopkgtest regression around 2021-08-25

[Drew Parsons]

On 2021-08-29 20:27, Graham Inggs wrote:
Even better would be to add the following section to 
debian/tests/control:


# Dummy test so that changes to other packages trigger our autopkgtests
# on ci.debian.net
Test-Command: /bin/true
Depends: libpmix-dev,
libucx-dev [amd64 arm64 ppc64el],
Restrictions: hint-testsuite-triggers

Refer
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst



That's a great idea, Graham.  I assume Lisandro will have 3.1 fixed soon 
for s390x since he's identified the cause of the failure. So I'll make 
the change in experimental rather than unstable.


Drew

Bug#992165: installation-reports: Failure to bring up KDE - intrusive firmware prompt stopped first boot

[Holger Wansing]

Control: tag -1 moreinfo


"Andrew M.A. Cater"  wrote:
> Install proceeded normally until first boot.
> 
> That proceeded normally until Starting SDDM
> 
> Firmware prompt came up seeking firmware for network interface (r8168e) and 
> WiFi Ralink - rt3290
> 
> This machine would also normally require old AMD Radeon drivers.

If you want to have non-free firmware to be installed during installation,
you need to use one of the unofficial installer images with firmware
included:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/


Please report, if this fixes the problem for you.



Holger



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

Bug#685264: merge bugs 685264, 705155 and 746206?

[Don Armstrong]

forcemerge 685264 705155 746206
thanks

On Fri, 27 Aug 2021, Vincent Lefevre wrote:
> Shouldn't these bugs be merged?
>
> 685264: debbugs: obey “Control” field in pseudoheader of messages to 
> ‘nnn-d...@bugs.debian.org’
> 705155: allow Control: commands at -done and -forwarded
> 746206: Control: pseudoheaders do not work for -done bugs; finish() called 
> too early

Yep. Merging them.

-- 
Don Armstrong  https://www.donarmstrong.com

I've had so much good luck recently I was getting sated with it. It's
like sugar, good luck. At first it's very sweet, but after a while you
start to think: any more of this and I shall be sick.
 -- Adam Roberts _Yellow Blue Tibia_ p301

Bug#993274: machine unbootable after upgrade

[Toni Mueller]

Package: upgrade-reports
Severity: grave


Hi,

I have recently upgraded a machine from Buster to Bullseye. The machine
runs on an mdadm RAID1. After the upgrade, it had the symptom outlined
in #931896.

I followed the upgrade process, as described in

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html


After completing this procedure, I ran

# apt install -f
# dpkg --configure -a

which both came up empty, suggesting that there was really no problem
left.


Since the machine didn't boot after upgrade, I'd say that warrants
'grave'.


As a fix, once I got access to the machine, running

# lsblk

to figure out the boot disks, then manually installing grub there like
this:


# grub-install /dev/sda
# grub-install /dev/otherdisk


solved the problem.


I am not sure why the upgrade process didn't handle this case, but think
the severity of the problem warrants a warning in the release notes.



Cheers,
Toni

Bug#960988: installation-report: Installation report for HP Pavillion X360 14-cd0004la

[Holger Wansing]

Hi,

Gunnar Wolf  wrote (Tue, 19 May 2020 00:33:32 -0500):
> The Buster installer could not find my wireless card (RTL 8821CE).
> 
> I performed the install using a spare external wireless interface; after
> booting to the installed system, I found an unofficial module supporting
> this hardware at:
> 
> https://github.com/tomaspinho/rtl8821ce

Maybe you could give it a try with a current Bullseye installer?


Holger



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

Bug#992918: gwenview: fails to save jpg/jpeg image

[Fufu Fang]

If I installed the libjpeg62-turbo from Debian Buster, the
"automatically select filename
extension (.jfif)" would change into "automatically select filename
(.jpeg)". 

I suspect it is the problem with libjpeg62-turbo.


On Sun, 2021-08-29 at 13:17 +0100, Ian Goddard wrote:
> On Sun, 29 Aug 2021 10:27:30 +0200 Francesco 
> wrote:
> > Package: gwenview
> > Version: 4:21.08.0-1
> > Followup-For: Bug #992918
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where
> > appropriate ***
> > 
> >    * What led up to the situation?
> >    Maybe a shared QT library bug, not only gwenview is affected
> 
> Kolourpaint is also affected.
> 
> I noticed that for both Gwenview & Kolourpaint when the format JPEG
> is 
> selected on the save menu the file extension is set to .jpe rather
> than 
> .jpeg or .jpg.   Correcting the extension doesn't resolve the problem
> but maybe this is a quirk of the same library.
> 
> Krita is not affected.
> 

Bug#993273: ITP: virify -- finds viruses in metagenomic and metatranscriptomic data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: virify -- finds viruses in metagenomic and metatranscriptomic data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: virify
  Version : 0.3.0
  Upstream Author : Martín Beracochea 
* URL : https://github.com/EBI-Metagenomics/emg-viral-pipeline
* License : Apache-2.0
  Programming Lang: Python
  Description : finds viruses in metagenomic and metatranscriptomic data
 This pipeline is run when there is an interest in finding viruses in
 a sample but one does not really know what to look for. The sequences
 provides all RNA sequences or all DNA sequences that it could find,
 likely somehow helped biochemically to increase chances to find the
 viral DNA/RNA, not the host's DNA/RNA, but any such enrichment is
 not ultimately required. Just sequence more, aka "deeper". Once this
 analysis is run, one will likely define PCR tests for the virus(es)
 identified.
 .
 VIRify is a recently developed pipeline for the detection, annotation,
 and taxonomic classification of viral contigs in metagenomic and
 metatranscriptomic assemblies. The pipeline is part of the repertoire of
 analysis services offered by the European Bioinformatics Institute.
 .
 VIRify’s taxonomic classification
 relies on the detection of taxon-specific profile hidden Markov models
 (HMMs), built upon a set of 22,014 orthologous protein domains and
 referred to as ViPhOGs.
 ,
 The pipeline is implemented and available in CWL and Nextflow.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/virify

Bug#993265: RFS: runit/2.1.2-42 -- system-wide service supervision

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org


Dear mentors,

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

 * Package name: runit
   Version : 2.1.2-42
   Upstream Author : Gerrit Pape 
 * URL : http://smarden.org/runit/
 * License : BSD-3-clause, GPL-3+
 * Vcs : https://salsa.debian.org/debian/runit
   Section : admin

It builds those binary packages:

  runit-init - system-wide service supervision (as init system)
  getty-run - runscripts to supervise getty processes
  runit-systemd - transitional package for runit-systemd users
  runit-run - service supervision (systemd and sysv integration)
  runit - system-wide service supervision

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-42.dsc

  git repo:  https://salsa.debian.org/debian/runit/-/tree/next

Changes since the last upload:

 runit (2.1.2-42) unstable; urgency=medium
 .
   * Release to unstable
   * getty-run: add hvc0 service, disabled by default:
   this is usually needed by Xen hypervisor
   * Add a default-syslog virtual service:
   to increase portability, services that log to syslog
   can depend on this rather than on a specific
   syslog daemon
   * shutdown.c:
   - try to fix FTBFS on Hurd (Closes: #992629)
   - distinguish between halt and shutdown flags:
 The -r flag ( as reboot) now only works with shutdown;
 Add a -f flag to shutdown (skip fsck next boot);
 Add -F flag to shutdown (force fsck next boot);
 The -f (as force a shutdown) and -w/--wtmp-only flags now
  only work with halt.
 (Closes: #992631)
   - Add a -n flag to halt, to skip sync() before reboot/poweroff;
 also, always check for runit.nosync flag file before invoking
 sync()  (Closes: #992641)
   - make halt '-f' flag a noop when runit is init. This way runit
 can use its own code to reboot/poweroff the system; users
 can still use the long '--force' option to force a shutdown
 without signaling the init (Closes: #899246)
   * Update shutdown(8) manpage
   * Bump Standards Version to 4.6.0, no change required
   * Update lintian overrides for 'alternative init but not init.d script'

Regards,
-- 
  Lorenzo Puliti

Bug#991822: src:wine: dh_auto_clean deletes unrelated files outside of package source

[Bálint Réczey]

Control: tags -1 patch

Bálint Réczey  ezt írta (időpont: 2021. aug.
2., H, 18:14):
>
> Package: src:wine
> Severity: critical
> Version: 5.0.3-3
>
> Hi,
>
> The following snippet in debian/rules wiped out every package source
> next to wine and the wine source dir itself, too, because my $HOME is
> stored in git:
>
> ...
> override_dh_auto_clean:
> git clean -Xdf || true
> ...
>
> It is not safe to assume that the package source is always a git directory.

I suggest using the attached fix.

Cheers,
Balint
From 6f8850be5fe0023040183e4f776f8cc2cb6c8ecd Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Sun, 29 Aug 2021 13:08:13 +0200
Subject: [PATCH] debian/rules: Don't run git clean in dh_auto_clean

Let "make clean" clean up built files instead.

Closes: #991822
---
 debian/rules | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index d6cf8cd6e98..33048be6fe0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -255,7 +255,6 @@ override_dh_clean:
 	make -f debian/rules debian/control
 
 override_dh_auto_clean:
-	git clean -Xdf || true
 	make -f debian/rules debian/control
 ifeq (,$(filter $(DEB_HOST_ARCH),i386 amd64))
 	# remove zlib patch on non x86 architectures
@@ -263,5 +262,4 @@ ifeq (,$(filter $(DEB_HOST_ARCH),i386 amd64))
 	QUILT_PATCHES=debian/patches quilt delete system/zlib.patch || true
 endif
 	QUILT_PATCHES=debian/patches quilt push -af || true
-	rm -f Makefile
 	dh_auto_clean
-- 
2.30.2

Bug#940427: RFA: golang-github-syncthing-notify

[Aloïs Micard]

> Hi, I'm interested in helping out the Debian Go team and considering
> this is something I use constantly, I would definitely be willing to
> help maintain it.

Hi Jai, are you still interested in maintaining this package?
If so and need a sponsor feel free to ping me. Otherwise
I would be interested in becoming the maintainer.

Cheers,

-- 
Aloïs Micard 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#993272: allow using multiple SRV records to load balance mirrors without CDNs

[Pirate Praveen]

Package: apt
version: 2.3.8
severity: wishlist

If I understand correctly, the current SRV record implementation is 
targetting CDNs so all servers will be responsind to the same hostname 
and will have certificates matching the main hostname.


I'm exploring the possibility of using SRV records to transparently 
load balance between multiple mirrors. This works well for http but 
will fail for https.


Current DNS setting is,

$ dig +noall +answer -t SRV _https._tcp.fasttrack-mirror.fsci.in
_https._tcp.fasttrack-mirror.fsci.in. 60 IN SRV 10 1 443 
fasttrack.debian.net.
_https._tcp.fasttrack-mirror.fsci.in. 60 IN SRV 10 1 443 
mirror.linux.pizza.


and the error
Err:3 https://fasttrack-mirror.fsci.in/debian-fasttrack 
bullseye-fasttrack InRelease
 Certificate verification failed: The certificate is NOT trusted. The 
name in the certificate does not match the expected. Could not 
handshake: Error in the certificate verification. [IP: 185.181.160.236 
443]


This is expected because neither fasttrack.debian.net nor 
mirror.linux.pizza has tls certificates for fasttrack-mirror.fsci.in


Would it be possible to use the hostnames mentioned in SRV records for 
retrieving the data instead of the main hostname? Is there any security 
concerns for doing that?


See https://salsa.debian.org/fasttrack-team/support/-/issues/25 for 
things I tried already

Bug#993271: RFA: ninka -- license identification tool for source code

[Luca Falavigna]

Package: wnpp
Severity: normal

I request an adopter for the ninka package.

The package description is:
 Ninka is a lightweight license identification tool for source code. It is
 sentence-based, and provides a simple way to identify open source licenses in
 a source code file. It is capable of identifying several dozen different
 licenses (and their variations).
 .
 Ninka has been designed to be lightweight, fast and accurate.
 .
 This package contains the standard ninka application.

Bug#988017: installation-reports: Looked like a successful upgrade...

[Paul Gevers]

Hi Randall,

On Mon, 03 May 2021 13:56:07 -0500 Randall Dukes 
wrote:
> only 1 notice required attention: irc user location changed since Buster.  
> Good job Debian Folks!

Can you elaborate a bit what you mean as I don't understand what you're
reporting? Are you talking about the issues with Freenode?

Also, can you confirm that apart from that issue, you're just reporting
a successful upgrade?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#969631: can base-passwd provide the user _apt?

[Marco d'Itri]

On Aug 29, Colin Watson  wrote:

> I can see the issue there.  Adding another prompt that every Debian user
> will need to consider on upgrade to the next release is pretty
> undesirable, though - I actively try to avoid that in base-passwd
> changes.  So maybe the policy violation, i.e. ending up with an
> inconsistent _apt UID on upgraded systems, is in fact the better option?
Ys.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#993269: e-antic FTBFS with flint 2.8.0

[Adrian Bunk]

Source: e-antic
Version: 0.1.8+ds-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=e-antic=0.1.8%2Bds-1%2Bb1

...
../poly_extra/fmpz_poly_randtest_irreducible.c:25:5: error: too few arguments 
to function ‘fmpz_mod_poly_randtest_irreducible’
   25 | fmpz_mod_poly_randtest_irreducible(q, state, len);
  | ^~
In file included from ../poly_extra/fmpz_poly_randtest_irreducible.c:13:
/usr/include/flint/fmpz_mod_poly.h:185:16: note: declared here
  185 | FLINT_DLL void fmpz_mod_poly_randtest_irreducible(fmpz_mod_poly_t f,
  |^~
../poly_extra/fmpz_poly_randtest_irreducible.c:27:5: error: too few arguments 
to function ‘fmpz_mod_poly_get_fmpz_poly’
   27 | fmpz_mod_poly_get_fmpz_poly(p, q);
  | ^~~
In file included from ../poly_extra/fmpz_poly_randtest_irreducible.c:13:
/usr/include/flint/fmpz_mod_poly.h:323:16: note: declared here
  323 | FLINT_DLL void fmpz_mod_poly_get_fmpz_poly(fmpz_poly_t f,
  |^~~
../poly_extra/fmpz_poly_randtest_irreducible.c:40:5: error: too few arguments 
to function ‘fmpz_mod_poly_clear’
   40 | fmpz_mod_poly_clear(q);
  | ^~~
In file included from ../poly_extra/fmpz_poly_randtest_irreducible.c:13:
/usr/include/flint/fmpz_mod_poly.h:118:16: note: declared here
  118 | FLINT_DLL void fmpz_mod_poly_clear(fmpz_mod_poly_t poly,
  |^~~
make[2]: *** [Makefile:2719: poly_extra/fmpz_poly_randtest_irreducible.lo] 
Error 1

Bug#988017: installation-reports: Looked like a successfull upgrade

[Holger Wansing]

Control: reassign -1 upgrade-reports

Reassigning to correct package


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

Bug#993107: theano: autopkgtest depends on libclblas-dev which is not in testing *and* has skip-not-installable

[Rebecca N. Palmer]

Control: tags -1 pending

This is the same underlying problem as #992673, but for this one it 
looks like switching to clblast is enough to pass the tests we actually 
run.  (Which isn't all of them because the GPU part of theano has never 
fully worked under OpenCL, but we already warn the user about that.)

Bug#993268: ITP: mashmap -- mapping whole genomes or long reads (PacBio/ONT) to reference

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: mashmap -- mapping whole genomes or long reads (PacBio/ONT) to 
reference
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: mashmap
  Version : 2.0
  Upstream Author : Copyright:  
* URL : https://github.com/marbl/MashMap
* License : PD
  Programming Lang: C
  Description : mapping whole genomes or long reads (PacBio/ONT) to 
reference
 MashMap implements a fast and approximate algorithm for computing local
 alignment boundaries between long DNA sequences. It can be useful
 for mapping genome assembly or long reads (PacBio/ONT) to reference
 genome(s). Given a minimum alignment length and an identity threshold
 for the desired local alignments, Mashmap computes alignment boundaries
 and identity estimates using k-mers. It does not compute the alignments
 explicitly, but rather estimates a k-mer based Jaccard similarity using
 a combination of Minimizers and MinHash. This is then converted to an
 estimate of sequence identity using the Mash distance. An appropriate
 k-mer sampling rate is automatically determined using the given minimum
 local alignment length and identity thresholds. The efficiency of the
 algorithm improves as both of these thresholds are increased.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/mashmap

Bug#993128: libvpx6: Unable to use camera or share screen on WebRTC conferences

[Jacob Byrd]

Same here also seems to be affecting Firefox as well but I can only trace
an error message with Chrome.

Bug#969631: can base-passwd provide the user _apt?

[Russ Allbery]

Colin Watson  writes:

> I think it's an interesting idea and worth pursuing, but on the face of
> it it seems that this would end up violating policy 9.2.2:

>   "Globally allocated by the Debian project, the same on every Debian
>   system."

> ... because the UID of the _apt user in fact wouldn't be the same on
> every Debian system, and I can imagine that this might cause trouble
> somewhere.

My first reaction is that from a strictly Policy perspective you may be
reading that requirement too strictly.  I would read that as a statement
of intention, not a requirement: the intent is for this UID to be the same
on every Debian system, but this may not be the case in practice due to
upgrades.  (Which seems obviously true or we could never add a new user.)

That said, it does feel weird to switch to this sort of static allocation
and not have a migration strategy for existing systems and leave them on
an old UID.  I know that it's not an explicit design goal of the project,
but I like the idea that continuously upgraded systems will converge on
the state that they would get if they were newly-installed, and that seems
valuable for long-term upgrade support.

My intuition is also that the case where a UID change will cause problems,
namely:

>   I'm mostly just worried about users using file:/ or copy:/ methods
>   and having given _apt access to them, they'd break.

is relatively rare (but maybe I'm wrong about this?), so I'm not sure that
it outweighs the simplicity advantages of converging on the same UID in
the long run.

>   I think it'd be best if we don't change existing _apt users, but only
>   dealt with new systems for now. I mean we could prompt users about
>   changing the uid

This is certainly a gentler migration, but I think the prompt or providing
some simple migration path would be valuable so that, in the long run,
people can converge their systems to the new configuration.  Maybe a
compromise would be to make the prompt have a fairly low urgency level?
We could then tell people in the release notes that if they're not using
_apt in some special way, they can dpkg-reconfigure base-passwd and let it
migrate the UID.

> Of course, another approach to the overall problem might be declarative
> user creation in dpkg, e.g. #685734 and
> https://wiki.debian.org/Teams/Dpkg/Spec/SysUser.  But that's clearly a
> lot of work, and this change wouldn't preclude it.

This does seem like clearly the right solution in the long run for all
problems of this sort, though.  I wouldn't want to add many statically
allocated UIDs.  (But if anything qualifies for one, _apt is a reasonable
candidate.)

-- 
Russ Allbery (r...@debian.org)  

Bug#993180: Bullseye

[Scorpion2185]

On Debian 11 (amd64) every time that I starts mirage I have that error:

Traceback (most recent call last):

File "qrc:/src/backend/matrix_client.py", line 399, in _start

[...]

I can't verified the session on revolt or element, it appears only in the page 
where you can delete sessions.
I don't know if it is related.

Is it possible to have the new version of python3-matrix-nio backported or 
updated for stable?

Bug#993046: libssh: CVE-2021-3634 - bullseye update prepared

[Moritz Muehlenhoff]

Hi Martin,

On Sat, Aug 28, 2021 at 01:54:50PM +0200, Martin Pitt wrote:
> Hello Salvatore and Laurent,
> Is that ok with you, in particular the not-quite-CVE patches? Should I upload
> directly or put the dsc somewhere?

Ack, that looks good. Please build with -sa (security.d.o and ftp.d.o don't 
share
tarballs ans libssh is new in bullseye-security) and upload to security-master.

Cheers,
Moritz

Bug#993214: mpi4py: autopkgtest regression around 2021-08-25

[Graham Inggs]

Even better would be to add the following section to debian/tests/control:

# Dummy test so that changes to other packages trigger our autopkgtests
# on ci.debian.net
Test-Command: /bin/true
Depends: libpmix-dev,
libucx-dev [amd64 arm64 ppc64el],
Restrictions: hint-testsuite-triggers

Refer 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst

Bug#993267: ITP: virsorter2 -- classifier to detect DNA and RNA virus genomes

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: virsorter2 -- classifier to detect DNA and RNA virus genomes
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: virsorter2
  Version : 2.2.3
  Upstream Author : Jiarong Guo 
* URL : https://github.com/jiarong/VirSorter2
* License : GPL-2.0
  Programming Lang: Python
  Description : classifier to detect DNA and RNA virus genomes
 VirSorter is a customizable pipeline to identify viral sequences from
 (meta)genomic data.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/virsorter2

Bug#969631: can base-passwd provide the user _apt?

[Colin Watson]

[For debian-devel readers; the original stated motivation for this bug
was being able to trim down the de-facto-essential set by removing
adduser from it.]

On Wed, Aug 25, 2021 at 09:54:35AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Helmut Grohne (2020-09-06 09:48:26)
> > Another benefit of this change (if a static uid is allocated) is that we
> > improve reproducible installations where currently uids may depend on
> > configuration order.
> 
> I'm very interested in having this bug fixed because of the reason above.
> 
> And there is yet another use-case that would be solved by the _apt user being
> shipped by base-passwd: since apt would no longer require adduser, we would
> automatically get DPKG_ROOT support for Essential:yes packages plus apt.
> 
> What do we need to implement this change? I observed that when I apply this
> patch to base-passwd:
> 
> diff -Nru base-passwd-3.5.51/passwd.master 
> base-passwd-3.5.51+nmu1/passwd.master
> --- base-passwd-3.5.51/passwd.master   2021-07-10 13:57:43.0 +0200
> +++ base-passwd-3.5.51+nmu1/passwd.master  2021-08-24 20:08:52.0 
> +0200
> @@ -15,4 +15,5 @@
>  list:*:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
>  irc:*:39:39:ircd:/run/ircd:/usr/sbin/nologin
>  gnats:*:41:41:Gnats Bug-Reporting System 
> (admin):/var/lib/gnats:/usr/sbin/nologin
> +_apt:*42:42::/nonexistent:/usr/sbin/nologin
>  nobody:*:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
> 
> Then not only will the _apt user be created as expected, but I also observed
> that when upgrading base-passwd on a system with an existing _apt user with 
> uid
> 100 from basepasswd 3.5.51 to my patched 3.5.51+nmu1, the uid of the _apt user
> remained the same as it should.

I think it's an interesting idea and worth pursuing, but on the face of
it it seems that this would end up violating policy 9.2.2:

  "Globally allocated by the Debian project, the same on every Debian
  system."

... because the UID of the _apt user in fact wouldn't be the same on
every Debian system, and I can imagine that this might cause trouble
somewhere.

Is this a serious enough problem to be worth fixing?  I'm not sure, so
CCing debian-devel for wider discussion.  Julian's point earlier in the
bug thread was:

  I'm mostly just worried about users using file:/ or copy:/ methods
  and having given _apt access to them, they'd break.
  
  I think it'd be best if we don't change existing _apt users, but only
  dealt with new systems for now. I mean we could prompt users about
  changing the uid

I can see the issue there.  Adding another prompt that every Debian user
will need to consider on upgrade to the next release is pretty
undesirable, though - I actively try to avoid that in base-passwd
changes.  So maybe the policy violation, i.e. ending up with an
inconsistent _apt UID on upgraded systems, is in fact the better option?

Of course, another approach to the overall problem might be declarative
user creation in dpkg, e.g. #685734 and
https://wiki.debian.org/Teams/Dpkg/Spec/SysUser.  But that's clearly a
lot of work, and this change wouldn't preclude it.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#993266: Reupload protobuf to unstable

[Pirate Praveen]

Package: ruby-google-protobuf
version: 3.12.4-1
severity: wishlist

ruby-pg-query needs google-protobuf ~> 3.15.5. I'd like to upload 
ruby-pg-query to unstable, so please upload a newer 
ruby-google-protobuf to unstable. I can help with rebuilds if needed.


Thanks
Praveen

Bug#993214: mpi4py: autopkgtest regression around 2021-08-25

[Graham Inggs]

Hi Drew

I followed the discussion on the upstream issue.
What do you think of adding some extra test dependencies to mpi4py's
debian/tests/control?

 Depends: python3-mpi4py,
+libpmix-dev,
+libucx-dev [amd64 arm64 ppc64el],
 python3-cffi,
 python3-dill,
 python3-distutils,

This will make sure mpi4py's autopkgtests are run when pmix and ucx
are updated as well.

Regards
Graham

Bug#980230: fonts-allerta is proposing 2 font files but LibreOffice is proposing only one

[Matt McInerney]

Hi Serge,

I don't think I can be much help here. I don't really have any experience
with font files in Libreoffice.

Best of luck with it

best,
Matt

On Wed, Aug 11, 2021 at 3:17 PM Serge Pouliquen  wrote:

> Hi,
>
> I took time to make some tests with files from official website.
> The problem is still present with libreoffice.
> Is there a debian page about stuff to check when a font is not appearing
> in font list ?
>
> Debian files looks not up to date.
> md5sum for debian files
> b0b0b4e19b80cf1efe2074ac45066130
> /usr/share/fonts/opentype/allerta/allerta_medium.otf
> 46019393b8fc0cc3a55684c18ab36f4e
> /usr/share/fonts/opentype/allerta/allerta_stencil.otf
> md5sum for official website
> 5c452f83f43801f04eff595b0e8a8835  allerta_medium.otf
> 5ded992908f415149c9de35c73adbf70  allerta_stencil.otf
>
> I tried to open official otf files with font forge, I got a warning
> message:
> This font contains both a kern table and a GPOS table.
>The kern table will only be read if there is no kern feature in GPOS
> Warning: Mac and Windows entries in the name table differ for the
>Fullname string in the language English (US)
>Mac String: Allerta Medium
>Windows String: Allerta-Medium
>
> I'm not a font specialist. Is it possible that there is any relation ?
>
> Regards,
> Serge
>
> On 20/01/2021 21:01, Matt McInerney wrote:
> > I'm not familiar with this issue, but you can try downloading the
> > original files here: http://pixelspread.com/allerta/
> > 
> > There are two weights in a few different file types you can try
> >
>

Bug#993264: gita: [security] Version in stable is using unsafe YAML loader

[Andrew Savchenko]

Package: gita
Severity: important
X-Debbugs-Cc: and...@lists.savchenko.net

Dear Maintainer,

Currently packaged version of `gita` uses unsafe `yaml.FullLoader`.

This is fixed upstream:
https://github.com/nosarthur/gita/compare/v0.12.9...v0.13.6#diff-b1d7ea073af79fb37be4b16f769ba60acb68546d0661f89c1d13b1975b5ba3aeL60-R61

Please consider either upgrading to any version >= v0.13.XX or patching
the code in Debian with `Loader=yaml.SafeLoader` / `yaml.safe_load()`


-- 
With regards,
A


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

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

Versions of packages gita depends on:
ii  git   1:2.30.2-1
ii  python3   3.9.2-3
ii  python3-yaml  5.3.1-5

gita recommends no packages.

gita suggests no packages.

Bug#993263: RFS: grcompiler/5.2.1-0.1 [NMU] -- Compiler of smart (graphite) fonts

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "grcompiler":

 * Package name: grcompiler
   Version : 5.2.1-0.1
   Upstream Author : silgraphite-de...@lists.sourceforge.net
 * URL : https://github.com/silnrsi/grcompiler
 * License : LGPL-2.1+ or CPL-0.5+
 * Vcs : https://salsa.debian.org/fonts-team/grcompiler
   Section : devel

It builds those binary packages:

  grcompiler - Compiler of smart (graphite) fonts

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/grcompiler/grcompiler_5.2.1-0.1.dsc

Changes since the last upload:

 grcompiler (5.2.1-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload
   * New upstream version 5.2.1 (Closes: #993261)
   * Drop upstream patches

Regards,
Bastian

Bug#993262: digikam-private-libs: depends on libkf5akonadicontact5-20.08 which is not available anymore in Sid

[Sébastien KALT]

Package: digikam-private-libs
Version: 4:7.1.0-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since last update of libkf5akonadicontact5 to version 4:21.08.0-1, digikam is
not installable because digikam-private-libs depends on libkf5akonadicontact5
version 20.08 :

# apt install digikam
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 digikam-private-libs : Depends: libkf5akonadicontact5-20.08
E: Unable to correct problems, you have held broken packages.

digikam and digikam-private-libs where uninstalled during the dist-upgrade
which upgraded libkf5akonadicontact5.

Regards,

Sébastien

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

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

Versions of packages digikam-private-libs depends on:
ii  kio  5.85.0-2
ii  libavcodec58 7:4.4-5
ii  libavfilter7 7:4.4-5
ii  libavformat587:4.4-5
ii  libavutil56  7:4.4-5
ii  libc62.31-17
ii  libexiv2-27  0.27.3-3
ii  libexpat12.2.10-2
ii  libgcc-s111.2.0-3
ii  libgl1   1.3.2-1
ii  libgomp1 11.2.0-3
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  libkf5akonadicontact54:21.08.0-1
pn  libkf5akonadicontact5-20.08  
ii  libkf5calendarcore5abi2  5:5.85.0-2
ii  libkf5completion55.85.0-2
ii  libkf5configcore55.85.0-2
ii  libkf5configgui5 5.85.0-2
ii  libkf5configwidgets5 5.85.0-2
ii  libkf5contacts5  5:5.85.0-2
ii  libkf5coreaddons55.85.0-2
ii  libkf5filemetadata3  5.85.0-2
ii  libkf5i18n5  5.85.0-2
ii  libkf5iconthemes55.85.0-2
ii  libkf5kiocore5   5.85.0-2
ii  libkf5kiowidgets55.85.0-2
ii  libkf5notifications5 5.85.0-3
ii  libkf5notifyconfig5  5.85.0-2
ii  libkf5sane5  21.08.0-1
ii  libkf5service-bin5.85.0-2
ii  libkf5service5   5.85.0-2
ii  libkf5solid5 5.85.0-2
ii  libkf5threadweaver5  5.85.0-2
ii  libkf5widgetsaddons5 5.85.0-2
ii  libkf5windowsystem5  5.85.0-2
ii  libkf5xmlgui55.85.0-2
ii  liblcms2-2   2.12~rc1-2
ii  liblensfun1  0.3.2-6
ii  liblqr-1-0   0.4.2-2.1
ii  libmagick++-6.q16-8  8:6.9.11.60+dfsg-1.3
ii  libmagickcore-6.q16-68:6.9.11.60+dfsg-1.3
ii  libmarblewidget-qt5-28   4:21.08.0-2
ii  libopencv-core4.54.5.3+dfsg-1
ii  libopencv-dnn4.5 4.5.3+dfsg-1
ii  libopencv-imgcodecs4.5   4.5.3+dfsg-1
ii  libopencv-imgproc4.5 4.5.3+dfsg-1
ii  libpng16-16  1.6.37-3
ii  libqt5concurrent55.15.2+dfsg-10
ii  libqt5core5a 5.15.2+dfsg-10
ii  libqt5dbus5  5.15.2+dfsg-10
ii  libqt5gui5   5.15.2+dfsg-10
ii  libqt5network5   5.15.2+dfsg-10
ii  libqt5printsupport5  5.15.2+dfsg-10
ii  libqt5sql5   5.15.2+dfsg-10
ii  libqt5webenginecore5 5.15.5+dfsg-2
ii  libqt5webenginewidgets5  5.15.5+dfsg-2
ii  libqt5widgets5   5.15.2+dfsg-10
ii  libqt5x11extras5 5.15.2-2
ii  libqt5xml5   5.15.2+dfsg-10
ii  libqt5xmlpatterns5   5.15.2-3
ii  libqtav1 1.13.0+ds-4
ii  libqtavwidgets1  1.13.0+ds-4
ii  libstdc++6   11.2.0-3
ii  libswscale5  7:4.4-5
ii  libtiff5 4.2.0-1
ii  libx11-6 2:1.7.2-1
ii  libx265-192  3.4-2
ii  libxml2  2.9.10+dfsg-6.7
ii  libxslt1.1   1.1.34-4

digikam-private-libs recommends no packages.

Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1

[Adam D. Barratt]

On Sun, 2021-08-29 at 12:25 -0400, Roberto C. Sánchez wrote:
> On Sun, Aug 29, 2021 at 05:17:02PM +0100, Adam D. Barratt wrote:
> > As it turns out, the bullseye upload is still sat on upload.d.o,
> > because:
> > 
> > Aug 29 15:31:17 processing /shiro_1.3.2-4+deb11u1_source.changes
> > Aug 29 15:31:17 shiro_1.3.2.orig.tar.xz doesn't exist (ignored for
> > now)
> > 
> > My assumption is that both of your .changes reference the same
> > .orig.tar.xz. If they were uploaded close together, then the queue
> > daemon will have removed the .orig from the queue together with the
> > files from the buster upload, thus stranding the bullseye upload. 
> 
> Yes, they reference the same .orig.tar.gz and I uploaded
> simultaneously.
> 
> > To
> > avoid this, either space the uploads further apart, or don't
> > include
> > the .orig in more than one of them - in fact, if the upstream
> > tarball
> > is the same as is already in the archive, you don't need to include
> > it
> > in either.
> > 
> Is this because the upload is going to the main FTP archive, rather
> than the security archive first?  It seems that the "always use -sa
> to build a u1 update" needs to only be for uploads targeted at
> security.d.o.

In general, that's correct, yeah - the security archive won't tend to
already have the orig, whereas the main archive will.

It's not an issue to include / reference it for the main archive
anyway, but as a consequence you will get this issue if you do so for
two uploads that occur close together. (I'd assume that you'll also hit
it if you upload for buster-security and bullseye-security under
similar circumstances.)

Regards,

Adam

Bug#993261: Import new upstream version

[Bastian Germann]

Source: grcompiler
Severity: normal

Version 5.2.1 is released. All patches on 5.2-2.2 except patch 7 can be dropped after importing the 
new version. Please upload it.

Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1

[Roberto C . Sánchez]

On Sun, Aug 29, 2021 at 05:17:02PM +0100, Adam D. Barratt wrote:
> 
> As it turns out, the bullseye upload is still sat on upload.d.o,
> because:
> 
> Aug 29 15:31:17 processing /shiro_1.3.2-4+deb11u1_source.changes
> Aug 29 15:31:17 shiro_1.3.2.orig.tar.xz doesn't exist (ignored for now)
> 
> My assumption is that both of your .changes reference the same
> .orig.tar.xz. If they were uploaded close together, then the queue
> daemon will have removed the .orig from the queue together with the
> files from the buster upload, thus stranding the bullseye upload. 

Yes, they reference the same .orig.tar.gz and I uploaded simultaneously.

> To
> avoid this, either space the uploads further apart, or don't include
> the .orig in more than one of them - in fact, if the upstream tarball
> is the same as is already in the archive, you don't need to include it
> in either.
> 
Is this because the upload is going to the main FTP archive, rather than
the security archive first?  It seems that the "always use -sa to build
a u1 update" needs to only be for uploads targeted at security.d.o.

> In this case, you'll either need to dcut the remaining files from the
> previous upload, or wait for the queue daemon to delete them on its
> own.
> 
> I've flagged the buster upload for rejection, once dak notices, so feel
> free to re-upload that once you receive the rejection confirmation (and
> bullseye once it times out, or you dcut it).
> 
Great!  Thanks for the info, as the single REJECT seemed strange when I
was expecting two of them.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1

[Adam D. Barratt]

On Fri, 2021-08-27 at 15:47 -0400, Roberto C.Sánchez wrote:
> On Fri, Aug 27, 2021 at 08:33:44PM +0100, Adam D. Barratt wrote:
> > On Fri, 2021-08-27 at 13:45 -0400, Roberto C. Sanchez wrote:
> > > I have prepared an update for shiro in buster.  This has been
> > > coordinated with the package maintainer and at the recommendation
> > > of
> > > the
> > > security team and with their concurrence, it is being proposed
> > > for
> > > the
> > > next buster point release.
> > 
> > +shiro (1.3.2-4+deb10u1) buster; urgency=medium
> > +
> > +  * Non-maintainer upload by the Security Team.
> > 
> > fwiw, I at least find it a little confusing to have debdiffs claim
> > to
> > be uploads by the Security Team when they were neither produced (so
> > far
> > as I can tell) nor uploaded by that team, nor released via the
> > security
> > archive.
> > 
> Quite right.  I originally prepared the uploads as security updates,
> but then changed course to the point release route.  Would you like
> to REJECT the uploads and I can upload again with a fixed changelog?

As it turns out, the bullseye upload is still sat on upload.d.o,
because:

Aug 29 15:31:17 processing /shiro_1.3.2-4+deb11u1_source.changes
Aug 29 15:31:17 shiro_1.3.2.orig.tar.xz doesn't exist (ignored for now)

My assumption is that both of your .changes reference the same
.orig.tar.xz. If they were uploaded close together, then the queue
daemon will have removed the .orig from the queue together with the
files from the buster upload, thus stranding the bullseye upload. To
avoid this, either space the uploads further apart, or don't include
the .orig in more than one of them - in fact, if the upstream tarball
is the same as is already in the archive, you don't need to include it
in either.

In this case, you'll either need to dcut the remaining files from the
previous upload, or wait for the queue daemon to delete them on its
own.

I've flagged the buster upload for rejection, once dak notices, so feel
free to re-upload that once you receive the rejection confirmation (and
bullseye once it times out, or you dcut it).

Regards,

Adam

Bug#865793: hsetroot FTCBFS: uses the build architecture pkg-config

[Vincent Bernat]

 ❦ 24 June 2017 22:31 +02, Helmut Grohne:

> hsetroot fails to cross build from source, because the patch added in
> #735758 uses the build architecture pkg-config. It should be using the
> PKG_PROG_PKG_CONFIG macro and access pkg-config through $PKG_CONFIG
> instead. After doing so, hsetroot cross builds successfully. Please
> consider applying the attached patch.

I have just uploaded a new version. Unfortunately, the build system is
now a very simple makefile. It accepts PKG_CONFIG as an environment
variable to change the location of pkg-config. Would this work when
crosscompiling?

Thanks.
-- 
No violence, gentlemen -- no violence, I beg of you!  Consider the furniture!
-- Sherlock Holmes

Bug#993260: RFS: apng2gif/1.8-3 [ITA] -- tool for converting APNG images to animated GIF format

[xiao shen wen（肖盛文）]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : apng2gif
Version : 1.8-3
Upstream Author : Max Stepi 
* URL : http://apng2gif.sourceforge.net
* License : zlib-libpng
* Vcs : https://salsa.debian.org/atzlinux-guest/apng2gif
Section : graphics

It builds those binary packages:

apng2gif - tool for converting APNG images to animated GIF format

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/a/apng2gif/apng2gif_1.8-3.dsc


Changes since the last upload:

apng2gif (1.8-3) unstable; urgency=medium
.
[ xiao sheng wen(肖盛文) ]
* add debian/gbp.conf, set debian-branch = debian/latest
* d/control:
- New maintainer (Closes: #920071)
- Bump Standards-Version: 4.6.0
- Bump debhelper-compat (= 13)
- add Rules-Requires-Root: no
- Update Homepage: http://apng2gif.sourceforge.net
* add d/upstream/metadata
* d/watch: update to version=4
* d/copyright: Files: debian/* add New maintainer xiao sheng wen
* Update manpages: delete outdated APNG homepage, fix typo
* d/rules:
- delete "LDFLAGS += -Wl,--as-needed"
- delete unused override_dh_installchangelogs
- delete unused CC,CFLAGS variables
- add execute_before_dh_installman target

Regards,

--
肖盛文 xiao sheng wen
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
GnuPG Public Key: 0x2F338C7DC7909957



OpenPGP_0x2F338C7DC7909957.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993254: sorry wrong tag

[k_f]

the accessibility tag is wrong, yes the package is inaccessible but not because 
it is missing accessibility-features

Bug#982907: init-system-helpers: use new needs-reload/needs-restart unit interface

[Niels Thykier]

Felipe Sateler:
> Hi!
> 
> On Tue, Aug 24, 2021 at 2:38 PM Niels Thykier  wrote:
> 
>> [...]
> 
> Not Michael, but if I can offer my thoughts, this is not something that
> could be done in i-s-h (or at least, not something that we could do
> transparently). This is because presumably there are postinst scripts that
> assume post-debhelper-block the new version is already running. So I
> believe what would be needed is:
> 
> 1. Support in i-s-h to activate this mode, probably via a new flag.
> 2. Support in debhelper to enable/disable this new method.
> 3. A trigger in systemd to do the final reload.
> 
> I believe requiring the new daemon version to be already updated by
> postinst time would be quite rare, so I think point 2 could be enabled by
> default in a new compat level.
> 
> Thoughts?
> 


Hi,

>From a debhelper PoV, that seems fine to me if the systemd side can
support it (the trigger part).

~Niels

Bug#984518: With Bullseye release this situation consists!!

[Holger Wansing]

Hi,

Steve McIntyre  wrote (Wed, 18 Aug 2021 11:46:29 +0100):
> Hi Karl-Heinz,
> 
> On Wed, Aug 18, 2021 at 12:37:33PM +0200, Karl-Heinz Künzel wrote:
> >Just did a short test here with 'debian-11.0.0-amd64-netinst.iso'.
> >
> >The situation still consists! BLACK SCREEN after successful
> >installation. No warning, no message, no hint.
> >
> >THIS IS NOT NICE!! And I don't have an AMD graphic,
> >but a simple Nvidia GT 1030 .
> 
> This might be a missing firmware issue - could you please try with the
> "firmware included" image:
> 
>   
> https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/11.0.0+nonfree/amd64/iso-cd/firmware-11.0.0-amd64-netinst.iso
> 
> and see if that fixes your problem?

@Karl-Heinz:
any news on this?

I remember that we confirmed several months ago, that this was indeed an issue
of missing firmware in your case.

Shortly before the release of Bullseye, the installer has received an
significant improvement for exactly this problem, so chances are high, that
the use of such an nonfree image with firmware included fixes the problem for 
you.


Schönen Gruß
Holger



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

Bug#993254: phonon-backend-gstreamer: Version 4:4.10.0 missing

[k_f]

Package: phonon-backend-gstreamer
Version: 4:4.10.0-1
Severity: important
Tags: a11y

Dear Maintainer,

while trying to update my system, phonon-backend-gestreamer 4:4.10.0 could not be found searching 
https://packages.debian.org/. I found that no such packge is availible, and looking at

https://buildd.debian.org/status/fetch.php?pkg=phonon-backend-gstreamer=amd64=4%3a4.10.0-1=1573068051=0

I found it just was not build, while the -common package still depends on it see 
https://packages.debian.org/bookworm/phonon-backend-gstreamer-common.


kind regard
Karl

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (590, 'testing'), (550, 'stable'), (500, 'testing-security'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages phonon-backend-gstreamer depends on:
ii  gstreamer1.0-plugins-bad [gstreamer1.0-audiosink]   1.18.4-3
ii  gstreamer1.0-plugins-base   1.18.4-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-audiosink]  1.18.4-2
ii  gstreamer1.0-pulseaudio 1.18.4-2
ii  libc6   2.31-13
ii  libgl1  1.3.2-1
ii  libgl1-mesa-glx 20.3.5-1
ii  libglib2.0-02.66.8-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libphonon4  4:4.10.2-1
ii  libqt4-opengl   4:4.8.7+dfsg-20
ii  libqtcore4  4:4.8.7+dfsg-20
ii  libqtgui4   4:4.8.7+dfsg-20
ii  libstdc++6  10.2.1-6
ii  phonon-backend-gstreamer-common 4:4.9.0-1

Versions of packages phonon-backend-gstreamer recommends:
ii  gstreamer1.0-plugins-good  1.18.4-2

Versions of packages phonon-backend-gstreamer suggests:
ii  gstreamer1.0-plugins-ugly  1.18.4-2

-- no debconf information

Bug#911313: that's probably not related to dolphin

[Alex Volkov]

As in my case, gwenview didn't respect the single-click setting either. So, 
probably, it's some more global configuration inconsistency in plasma, kde5 or 
qt5. Removing `qt5ct` along with it's user config, and setting explicitly 
`[KDE]/SingleClick=true` in `.config/kdeglobals` fixed it for me.

Bug#993259: software-properties-gtk does not delete repository keys

[Heiko Hösch]

Package: software-properties-gtk
Version: 0.96.20.2-2.1
Severity: important

The software properties application does not delete
keys. I install a key. Let's say the google Linux
repositories key. I type in the command line (as root):

wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo 
apt-key add -


Now I open the Software & Updates Aplication (In my case it is
software-properties-gtk). I select the authentication tab where you
have options for the keys. It shows the keys, but when I click on
the button for removing a key, it doesn't remove it.

The list of keys seems to update when you press the button that
should delete a key. When you try to delete a key from the bottom
of the list, the list is shown from the top again. So it seems
to update the list like it should after deleting a key, I think.
But it doesn't delete the selected key. You can only add keys with
software-properties-gtk.

The error is in the file "SoftwarePropertiesGtk.py".
It is in that passage:


    def remove_key_clicked(self, widget):
    """Remove a trusted software vendor key"""
    selection = self.treeview_auth.get_selection()
    (model, a_iter) = selection.get_selected()
    if a_iter == None:
    return
    key = model.get_value(a_iter, 0)
    try:
    if not self.backend.RemoveKey(key[:8]):
    error(self.main,
  _("Error removing the key"),
  _("The key you selected could not be removed. "
    "Please report this as a bug."))
    except dbus.DBusException as e:
    if e._dbus_error_name == 
'com.ubuntu.SoftwareProperties.PermissionDeniedByPolicy':
    logging.error("Authentication canceled, changes have 
not been saved")



The error is the "key[:8]" here. It gives the first eight characters of 
the key that is
chosen here. It must use the whole sixteen characters. The application 
shows a key like
that: "8C42FC58D8752769". The "key[:8]" lets the application choose the 
first eight characters.
That won't work when you try to delete a key with "apt-key rm" in the 
command line.
You can delete the key in the command line with "apt-key rm" with the 
whole sixteen
characters. (The application uses "apt-key rm". You can look this up in 
"AptAuth.py"
in the package "python3-software-properties".) If you just change the 
"key[:8]" to

"key[:16]", the application (software-properties-gtk) can delete keys.

I think there should be an update when the bug is fixed, because the 
user interface is an
important part of the operating system. There shouldn't be a button that 
doesn't work in
a stable version for day-to-day use. Furthermore, removing apt keys 
should be possible
to ensure safety. Such a small change should be possible. It just 
ensures that the program

gets the right variable. Nothing else needs to be changed to fix this bug.

I also do not want this bug again if you ever make an update of the 
concerned files, so

please make an updated version


_

Ihr Recht auf Privatsph�re. Sch�tzen Sie Ihre Daten und wechseln jetzt zu eclipso 
Mail & Cloud - https://www.eclipso.de

Bug#982147: mgba: Please provide a libmgba-dev package

[Sébastien Noel]

Hi !

On Sat, 6 Feb 2021 13:41:04 -0800 Ryan Tandy wrote:

What is the software that would like to use this? Is it (or would it
eventually be) in Debian?


New version of Dolphin, the Gamecube and Wii emulator (src:dolphin-emu),
have now the possibility to link to libmgba. You can read more info
about that here: https://dolphin-emu.org/blog/2021/07/21/integrated-gba/
(it requires a more recent version of mgba, but that's another topic)

I know that unfortunately the official dolphin debian package is stuck
to a very old version, but I hope that this will change
in the near future (see #986739).

It would be very cool if we can ship a libmgba-enabled dolphin package
in Debian, so I hope that a libmgba-dev package is not completely
out-of-the-question now that bullseye is released :-)

Best regards,

Sébastien

Bug#993257: bind9: /etc/default/bind9 renamed in bullseye

[Mario Thomann]

Package: bind9
Version: 1:9.16.15-1
Severity: normal
Tags: d-i

Dear Maintainer,

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

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

in bullseye /etc/default/bind9 is not considered anymore (like in
previous versions). Now it have to be /etc/default/named 
This should be mentioned in the upgrade process




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

Kernel: Linux 5.10.0-8-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)

Versions of packages bind9 depends on:
ii  adduser3.118
ii  bind9-libs 1:9.16.15-1
ii  bind9-utils1:9.16.15-1
ii  debconf [debconf-2.0]  1.5.77
ii  dns-root-data  2021011101
ii  init-system-helpers1.60
ii  iproute2   5.10.0-4
ii  libc6  2.31-13
ii  libcap21:2.44-1
ii  libfstrm0  0.6.0-1+b1
ii  libjson-c5 0.15-2
ii  liblmdb0   0.9.24-1
ii  libmaxminddb0  1.5.2-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libssl1.1  1.1.1k-1
ii  libuv1 1.40.0-2
ii  libxml22.9.10+dfsg-6.7
ii  lsb-base   11.1.0
ii  netbase6.3
ii  zlib1g 1:1.2.11.dfsg-2

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.16.15-1
ii  dnsutils   1:9.16.15-1
pn  resolvconf 
pn  ufw

-- Configuration Files:
/etc/bind/db.root [Errno 2] No such file or directory: '/etc/bind/db.root'
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]
/etc/default/named changed [not included]

-- debconf information:
  bind9/start-as-user: bind
  bind9/different-configuration-file:
  bind9/run-resolvconf: false

Bug#964284: guile-gnutls: update to use guile 3.0

[Andreas Metzler]

On 2021-08-28 Vagrant Cascadian  wrote:
> I talked to rlb breifly who thought recent versions of guile-3.0 in
> Debian may work around and/or fix the triggering issue for
> guile-gnutls. Would you be up for trying to switch guile-gnutls to
> guile-3.0 again?

Hello,

I just made a test-upload to experimental.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#993002: [Pkg-samba-maint] Bug#993002: cifs-utils: I tried mount with credential archive (username, password and domain) wiht -o credential=mycredential.txt, all sec= and all -m options without suc

[Jelmer Vernooij]

On Thu, Aug 26, 2021 at 04:21:23AM -0300, mount -t cifs unable to mount shared 
folders on windows server active director wrote:
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I can connect to same folder with gvfs-mout (smb://) into Thunar file 
> mannager and with smbclient into Bash Shell,
> while I suppose that has a bug in mount wiht cifs-utils.
> 
>* What was the outcome of this action?
> I can't mount shared windows foders with mount -t cifs 
> //myserver/sharedfolder /mointpoint.
What happens if you do this? What errors do you get, and what's in
dmesg?

Jelmer


signature.asc
Description: PGP signature

Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL

[Florian Weimer]

* Aurelien Jarno:

> I have been looking at the corresponding instruction, this is:
>
> 2ed0 <__cpu_indicator_init@GCC_4.8.0>:
> 2ed0:   f3 0f 1e fb endbr32
>
> This is an Intel CET instruction, and it seems your CPU doesn't support
> executing it. Anyway this shows that the problem is in libgcc-s1, I am
> therefore reassigning the bug.

Correct, CET uses long NOPs, which are not supported by some x86 CPUs
and trap on them.

Thanks,
Florian

Bug#993245: bash: "command -v ls" response "alias ls='ls --color=auto'" is not consistent with dash and ksh: "/usr/bin/ls"

[Ralex]

Package: bash
Severity: normal
X-Debbugs-Cc: ral...@protonmail.com




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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#993256: [debian-keyring]

[Sherry Williams]

Package: debian-keyring Version: 2021.07.26 Severity: Tags: X-Debbugs-CC:
Dear Maintainer, *** Please consider answering these questions, where
appropriate *** * What led up to the situation? * What exactly did you do
(or not do) that was effective (orineffective)? * What was the outcome of
this action? * What outcome did you expect instead? *** End of the template
- remove these lines ***

Bug#992034: installation-guide: Include a note on how to change init system during install

[Holger Wansing]

Hi,

Am 28. August 2021 09:37:26 MESZ schrieb Philip Hands :
>Holger Wansing  writes:
>> Moreover, when thinking about this implementation, I'm quite uncomfortable 
>> with 
>> adding such paragraph into the "Using individual components" section, since 
>> this 
>> "change-init-system part" is no "installer component" like the others in 
>> this 
>> section (say: there is no 'change-init-system udeb').
>>
>> Therefore, I would be in favor of adding a separate section for such things 
>> as
>> section 6.5 after the "Loading missing firmware" section, like this:
[...]
>> + 
>> + Miscellaneous adaptions
>
>"adaptions" strikes me as slightly odd english -- I think
>"customisations" or "adjustments" would be a better choice.
>
>On the other hand the preceding sections are about how we accommodate
>people's preferences via debconf settings, so this is actually quite a
>departure from that, because it's something that people want to change
>that has to be done outside debconf, so the section heading should
>probably refer to that difference somehow.
>
>How about "Variations requiring manual intervention"?

Hmm, seems a bit cumbersome to me (but not a native
English speaker), and would people be able to imagine, 
what such chapter is about, judged from that headline?

@Justin?


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#992918: gwenview: fails to save jpg/jpeg image

[Ian Goddard]

On Sun, 29 Aug 2021 10:27:30 +0200 Francesco  wrote:

Package: gwenview
Version: 4:21.08.0-1
Followup-For: Bug #992918

Dear Maintainer,

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

   * What led up to the situation?
   Maybe a shared QT library bug, not only gwenview is affected


Kolourpaint is also affected.

I noticed that for both Gwenview & Kolourpaint when the format JPEG is 
selected on the save menu the file extension is set to .jpe rather than 
.jpeg or .jpg.   Correcting the extension doesn't resolve the problem 
but maybe this is a quirk of the same library.


Krita is not affected.

Bug#892058: Thank you for the reminder

[Sherry Williams]

Date: Sat, 21 Nov 2020 16:38:53 -0500 >From: Alex Chernyakhovsky
>- >Body: This is a multi-part MIME message sent by reportbug.
> > >--

Bug#992734: [PATCH] scripts/add-key: use mktemp instead of tempfile

[Sherry Williams]

Date: Wed, 25 Aug 2021 11:44:54 -0500 >From: Gunnar Wolf >-
>Body: tags 992734 + pending >thanks > >Thank you very much for the patch,
Clint! > >I have added it to our working tree. Next time we upload a
package, >the changelog will take care of closing this bug.

Bug#361539: Re: Errors importing keys with readonly debian-keyring.gpg

[Sherry Williams]

Date: Wed, 28 Mar 2012 13:55:28 -0400 >From: Samuel Bronson >-
>Body:
SGkgRnJhbmshCgpGcmFuayBLw7xzdGVyIHdyb3RlOgo+IE5pa29sYXVzIFNjaHVseiA8bWljcm9zY2h1bHpAd2ViLmRlPiB3cm90ZToKPiAKPiA+IFBhY2thZ2U6IGRlYmlhbi1rZXlyaW5nCj4gPiBWZXJzaW9uOiAyMDA1LjA1LjI4Cj4gPiBTZXZlcml0eTogbm9ybWFsCj4gPgo+ID4gSGksCj4gPgo+ID4gYXMgc3VnZ2VzdGVkIGluIHRoZSBkZWJpYW4ta2V5cmluZyBSRUFETUUsIEkndmUgYWRkZWQgdGhlIERlYmlhbiBrZXlyaW5ncwo+ID4gZGlyZWN0bHk6Cj4gPgo+ID4gLC0tLS1bIH4vLmdudXBnL2dwZy5jb25mIF0KPiA+IHwga2V5cmluZyAvdXNyL3NoYXJlL2tleXJpbmdzL2RlYmlhbi1rZXlyaW5nLmdwZwo+ID4gfCBrZXlyaW5nIC91c3Ivc2hhcmUva2V5cmluZ3MvZGViaWFuLWtleXJpbmcucGdwCj4gPiB8IGtleXNlcnZlciB3d3drZXlzLmRlLnBncC5uZXQKPiA+IGAtLS0tCj4gPgo+ID4gSGVyZSdzIGEgdHlwZXNjcmlwdCBvZiB3aGF0IGhhcHBlbnMgaW1wb3J0aW5nIGEga2V5Ogo+ID4KPiA+IHBlbmVsb3BlW25pa29sYXVzXSQgZ3BnIC0tcmVjdi1rZXlzIFhYWFhYWFhYCj4gPiBncGc6IHJlcXVlc3Rpbmcga2V5IFhYWFhYWFhYIGZyb20gaGtwIHNlcnZlciB3d3drZXlzLmRlLnBncC5uZXQKPiA+IGdwZzoga2V5IFhYWFhYWFhYOiBwdWJsaWMga2V5ICI8aWQ+IiBpbXBvcnRlZAo+ID4gZ3BnOiBjYW4ndCBjcmVhdGUgYC91c3Ivc2hhcmUva2V5cmluZ3MvZGViaWFuLWtleXJpbmcuZ3BnLnRtcCc6IFJlYWQtb25seSBmaWxlIHN5c3RlbQo+IAo+IEhpIE5pa29sYXVzLAo+IAo+IEkgdGhpbmsgdGhpcyBpcyBub3QgYSBidWcuICBZb3UganVzdCBtaXNzZWQgdGhlIG5leHQgcGFyYWdyYXBoIGluIHRoZQo+IFJFQURNRSwgdGVsbGluZyB5b3UKPiAKPiAsLS0tLQo+IHwgR1BHIGNhbm5vdCBtb2RpZnkga2V5cyBpbiB0aGVzZSByb290LW93bmVkIGZpbGVzLiAgSW4gb3JkZXIgdG8gZWRpdCBvcgo+IHwgc2lnbiBrZXlzIGluIHRoZSBEZWJpYW4ga2V5cmluZyB5b3Ugd2lsbCBmaXJzdCBuZWVkIHRvIGltcG9ydCB0aGVtIHRvCj4gfCB5b3VyIHBlcnNvbmFsIGtleXJpbmcuICBJZiB+Ly5nbnVwZy9ncGcuY29uZiBsaXN0cyB0aGUgZGViaWFuLWtleXJpbmcKPiB8IGZpbGVzLCBrZXlzIGFscmVhZHkgaW4gdGhlIERlYmlhbiBrZXlyaW5nIHdpbGwgbm90IGJlIGltcG9ydGVkIHRvIHlvdXIKPiB8IHBlcnNvbmFsIGtleXJpbmcuICBZb3UgY2FuIHVzZSAiZ3BnIC0tbm8tb3B0aW9ucyAtLWltcG9ydCIgdG8gZm9yY2UKPiB8IEdQRyB0byBpZ25vcmUgZ3BnLmNvbmYgYW5kIGltcG9ydCBrZXlzIHRvIHlvdXIgcGVyc29uYWwga2V5cmluZyBvbmx5Lgo+IGAtLS0tCgpIbW0uICBJJ20gbm90IHZlcnkgZmx1aWQgd2l0aCBnbnVwZywgYnV0IGZpcnN0LCB0aGUgUkVBRE1FIHNlY3Rpb24geW91J3JlCmNpdGluZyBzdGFydHMgd2l0aCB0aGUgY2xlYXIgc3RhdGVtZW50OiAKCiwtLS0tWyBSRUFETUUgXQp8IFVzaW5nIHRoZSBkZWJpYW4ta2V5cmluZyB3aXRoIGdwZwp8IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp8CnwgQWRkIHRoZXNlIGxpbmVzIHRvIHRoZSBib3R0b20gb2YgeW91ciB+Ly5nbnVwZy9ncGcuY29uZlsxXSBmaWxlOgp8Cnwga2V5cmluZyAvdXNyL3NoYXJlL2tleXJpbmdzL2RlYmlhbi1rZXlyaW5nLmdwZwp8IGtleXJpbmcgL3Vzci9zaGFyZS9rZXlyaW5ncy9kZWJpYW4ta2V5cmluZy5wZ3AKYC0tLS0KCkFuZCB0aGlzIF9kb2VzIG5vdCB3b3JrXy4gCgo+IFNob3VsZCB3ZSBjbG9zZSB0aGlzIGJ1Zz8KCiAgICBTZWNvbmQsIEkgbWF5IGJlIGxhY2tpbmcgdGhlIG5lY2Vzc2FyeSBpbnNpZ2h0IGhvdyBnbnVwZyB3b3JrcywgYnV0CklJUkMsIHdoZW4gSSBpbmNsdWRlZCB0aGUgZ2l2ZW4gImtleXJpbmciIGxpbmVzIGluIH4vZ3BnLmNvbmYsICBpdCB3YXMKbm90IHRoZSBwcm9jZWR1cmUgb2YgImVkaXRpbmcgb3Igc2lnbmluZyBrZXlzIGluIHRoZSBEZWJpYW4ga2V5cmluZyIKdGhhdCBmYWlsZWQsIGJ1dCB0aGUgcHJvY2VkdXJlIG9mIGltcG9ydGluZyAoYW55KSBrZXlzIGluIG15IHByaXZhdGUKa2V5cmluZy4gIFRoaXMgaXMgZGlmZmVyZW50IGZyb20gd2hhdCB0aGUgcGFyYWdyYXBoIHlvdSBjaXRlZCBzcGVha3MKYWJvdXQuCgpIQU5ELCAKTmlrb2xhdXMKCg

Bug#993045: Please bring back the -unsafe-string switch

[Stéphane Glondu]

Control: tags 993045 + wontfix

Le 26/08/2021 à 21:42, Julien Puydt a écrit :
> a part of scilab (modelica) is written in OCaml, but needs the -unsafe-
> string switch ; unfortunately:
> 
> /usr/bin/ocaml: OCaml has been configured with -force-safe-string: -
> unsafe-string is not available.

The -unsafe-string switch is obsolete and will eventually disappear; its
unavailability is upstream default behavior. scilab should be fixed to
not need it (and this should be done upstream).

> Can you please re-enable unsafe strings?

No.

How come this is an issue only now? The transition to OCaml 4.11.1 (the
first version with unsafe strings disabled in Debian) was done last
November...


Cheers,

-- 
Stéphane

Bug#993216: [Pkg-rust-maintainers] Bug#993216: dh-cargo timestamp fix doesn't cover changelogs installed to /usr/share/doc

[James McCoy]

On Sat, Aug 28, 2021 at 06:36:24PM +0100, Ximin Luo wrote:
> plugwash:
> > package: dh-cargo
> > 
> > Recently a substantial number of upstream cargo packages started using 
> > timestamps the ftpmasters
> > consider reject-worthy, I believe this was done in the name of 
> > reproducibility.
> > 
> 
> On what basis are you forming your belief? Because I worked on 
> reproducibility for a couple of years (and was advising the rustc guys about 
> it), and this method is not suitable for that purpose.

Cargo package[0] uses tar-rs' HeaderMode::Deterministic when adding files
to the tar archive (or an explicit mtime of 1 for generated files).

HeaderMode::Deterministic sets the mtime for the member to a hard-coded
date which was 0 (epoch)[1], then 123456789 (Nov 29, 1973)[2], and now
1153704088 (Jul 23, 2006)[3].

We already had a workaround for the generated files, and further
workarounds were recently added for the non-generated files.

[0]: 
https://github.com/rust-lang/cargo/blob/bf505afa92245afda23e8f121a34af836789ab2e/src/cargo/ops/cargo_package.rs#L546-L576
[1]: 
https://github.com/alexcrichton/tar-rs/commit/207be8862216b2f57730b21e10193c9aa5d6eaac
[2]: 
https://github.com/alexcrichton/tar-rs/commit/e81f172113c44742c9e096c296f3055abd2dfa0b
[3]: 
https://github.com/alexcrichton/tar-rs/commit/60c6bd81d73fd0e340cfb0e147aae13ce23e18c6

> >From what I gather during previous discussions, some overzealous FTP person 
> >ages ago decided to add this over-reaching check, to reject other 
> >bad-quality packages, without thinking about the long-term consequences of 
> >it. Now we must all suffer the consequences.

The comment in dak around these checks is:

"""check timestamps of files in binary packages

Files in the near future cause ugly warnings and extreme time travel
can cause errors on extraction.
"""

Have you tried discussing this with ftp-team again?

> The correct fix is to undo this injustice, not to leech volunteers' time with 
> this sort of bullshit. Covid has killed several million people in the past 
> couple years due to government incompetence and inaction, I don't want to 
> care about fucking timestamps, ESPECIALLY when it has nothing to do with 
> reproducibility.

The checks from the ftp-team have nothing to do with reproducibility.
That was the justification for the changes done on /Rust's/ side.

The existing code in dh-cargo just sets mtime to $SOURCE_DATE_EPOCH for
files it installs, but other files (like upstream's changelog) are
installed by other debhelper commands.

Maybe we need a dh_cargo-timestamp helper that can be automatically run
just before dh_builddeb to adjust the timestamp for all files in binary
packges?

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

Bug#960961: Please update path to udisks2-inhibit

[Mike Fleetwood]

This has been fixed in GParted 1.3.1 released 2021-July-19 [1], by this
commit [2].

Thanks,
Mike Fleetwood (GParted Developer)


[1] https://gparted.org/news.php?item=240

[2] Commit 325c6eb2 "Handle change in path for udisks2-inhibit executable (!84)"

https://gitlab.gnome.org/GNOME/gparted/-/commit/325c6eb2475e1edc2d2a366b4f306f3713efb8d3

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Michael Kogan]

Am So., 29. Aug. 2021 um 13:51 Uhr schrieb Andrej Shadura :

> Thanks very much for your offer, but at the moment the only thing blocking
> it is me uploading the package :) The extra dependency is now in Debian, so
> I can proceed with uploading Shutter too before I go on my holiday.
>
> --
> Cheers,
>   Andrej
>

That's great news, thanks for the update!

Bug#993255: golang-github-containers-common: Detection of systemd user session fails in certain scenarios

[Hannah Rittich]

Package: golang-github-containers-common
Version: 0.33.4+ds1-1
Severity: normal

When the environment variable `DBUS_SESSION_BUS_ADDRESS` contains the GUID,
the detection of the systemd user session fails. This happens, e.g., when
starting konsole using krunner on KDE. In this case podman will print a long
error message and refuses to use systemd for cgroup management.

To reproduce:

  1. Start KDE.
  2. Right click the desktop and start KRunner.
  3. Enter "konsole" and hit enter.
  4. The environment variable `DBUS_SESSION_BUS_ADDRESS` should look as
 follows.

 unix:path=/run/user/.../bus,guid=...

  5. In the window of konsole enter `podman image ls`. A warning message is 
shown.

Looking at the code, I would assume that the error is in the file
`pkg/config/config.go` starting at line 539. Comparing with the upstream code
[1] suggests that the error has been fixed in upstream. Replacing the code
block starting at line 539 with the code block at [1] should solve the issue.
A patch file is attached. I did, however, not test the patch.

[1]: 
https://github.com/containers/common/blob/74022015478a9621623656b7998c87f198295df9/pkg/config/config.go#L641


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

Kernel: Linux 5.10.0-8-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 golang-github-containers-common depends on:
ii  golang-github-containers-image  5.10.3-1

golang-github-containers-common recommends no packages.

golang-github-containers-common suggests no packages.

-- no debconf information
diff -Naur golang-github-containers-common-0.33.4+ds1.orig/pkg/config/config.go 
golang-github-containers-common-0.33.4+ds1/pkg/config/config.go
--- golang-github-containers-common-0.33.4+ds1.orig/pkg/config/config.go
2021-08-29 13:44:23.361683928 +0200
+++ golang-github-containers-common-0.33.4+ds1/pkg/config/config.go 
2021-08-29 13:45:32.322985875 +0200
@@ -538,10 +538,15 @@
 
session := os.Getenv("DBUS_SESSION_BUS_ADDRESS")
hasSession := session != ""
-   if hasSession && strings.HasPrefix(session, "unix:path=") {
-   _, err := os.Stat(strings.TrimPrefix(session, "unix:path="))
-   hasSession = err == nil
-   }
+   if hasSession {
+   for _, part := range strings.Split(session, ",") {
+   if strings.HasPrefix(part, "unix:path=") {
+   _, err := os.Stat(strings.TrimPrefix(part, 
"unix:path="))
+   hasSession = err == nil
+   break
+   }
+   }
+   } 
 
if !hasSession {
logrus.Warningf("The cgroupv2 manager is set to systemd but 
there is no systemd user session available")

Bug#951374: RFP: gh -- the GitHub CLI

[Anthony Fok]

Hi Brian,

Sorry for the late reply.

On Mon, Aug 16, 2021 at 10:56 PM Brian Thompson  wrote:
> On Mon, 2021-08-16 at 21:27 -0600, Anthony Fok wrote:
> >
> > Now, you might run into a problem when actually trying to name the
> > package "github-cli" (or even "gh") because dh-make-golang 0.4.0 does
> > not allow for overriding the package name.  For example:
> >
> > dh-make-golang -type p -pristine-tar github.com/cli/cli
> >
> > would name the package "cli"... I am working on packaging the latest
> > dh-make-golang and will try to add a flag to allow overriding the
> > package name, to be uploaded as dh-make-golang 0.4.1 or 0.5.0.
>
> It sounds like this functionality is required for what we are trying to 
> achieve.
> I am not very familiar with the golang family and its surrounding 
> infrastructure
> regarding Debian. Perhaps I am not best-equipped to package the github-cli 
> tool,
> but I am always willing to learn.

That's awesome!  Welcome to the Debian Go Packaging Team!
You may start by taking a look at  https://go-team.pages.debian.net/ .

I am happy to report that dh-make-golang 0.5.0-1 has been uploaded,
which means now you can name the package "gh" (to match the name of
the Debian package provided upstream on GitHub) by using the following
command:

dh-make-golang -pristine-tar -program_package_name gh github.com/cli/cli

(the -pristine-tar option is just my personal preference and is optional.)

> > Then there are the yet-to-be-packaged dependencies.  Just so that you
> > know, the following packages that github-cli depends on have already
> > been packaged but currently sitting in the
> > https://ftp-master.debian.org/new.html NEW queue:
> >
> >  * golang-github-yuin-goldmark-emoji 1.0.1-1
> >  * golang-github-muesli-reflow 0.3.0-1
> >  * golang-github-shurcool-graphql 0.0~git20200928.18c5c31-1
> >  * golang-github-shurcool-githubv4 0.0~git20210725.83ba7b4-1

Hurray!  These 4 packages have entered Debian!  (Thanks to FTP Masters!)

> > I'll report back here if I were to package and upload more of these
> > dependencies so as to avoid duplication of work.

> It sounds like we should pause the github-cli technical packaging work until
> dependent features and packages are added to the ecosystem. Would you agree 
> with
> that? I'm not seeing any BTS tags specific to RFPs (or bugs in general) for
> marking it as "blocked", as we would say in the corporate world. Although I am
> not sure that is even necessary.

Well, we won't know what the dependencies are until we start packaging
gh, so we would start by running dh-make-golang which will give us
more information such as the yet-to-be-packaged dependencies.

Yes, it would be a good idea to mark the relevant ITP/RFP bugs as
blocking for gh.  Not strictly necessary, but definitely helpful to
have the ITP/RFP bugs connected to this bug, otherwise it is hard to
keep track of them.

So yes, with the new dh-make-golang 0.5.0, you can start packaging gh
and its dependencies any time now!  Make sure to double check the NEW
queue and WNPP to ensure you are not doing work that has already been
done by others.  :-)

Let's begin!

Cheers,
Anthony

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hi,

On Sun, 29 Aug 2021, at 13:49, Michael Kogan wrote:
> Am Fr., 20. Aug. 2021 um 06:52 Uhr schrieb jiho lee :
>> Hi Andrej.
>> 
>> Is there anything else I need to support regarding shutter packaging?
>> 
>> There is a future society, but my future is not what others do.
>> Dept. of Information Science, Graduate School, Korea National Open University
> 
> Anything we can do from upstream to get this moving? We have now up to date 
> packages for Arch/Manjaro, Fedora, Gentoo, so Debian is the by far biggest 
> distro which hasn't packaged Shutter yet...

Thanks very much for your offer, but at the moment the only thing blocking it 
is me uploading the package :) The extra dependency is now in Debian, so I can 
proceed with uploading Shutter too before I go on my holiday.

-- 
Cheers,
  Andrej

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Michael Kogan]

Am Fr., 20. Aug. 2021 um 06:52 Uhr schrieb jiho lee :

> Hi Andrej.
>
> Is there anything else I need to support regarding shutter packaging?
> 
> 
> There is a future society, but my future is not what others do.
> Dept. of Information Science, Graduate School, Korea National Open
> University
>

Anything we can do from upstream to get this moving? We have now up to date
packages for Arch/Manjaro, Fedora, Gentoo, so Debian is the by far biggest
distro which hasn't packaged Shutter yet...

Bug#802453: config file conflict, shell session: can't leave emacs

[Ansgar]

found 802453 2.3.8
thanks

I can confirm that this bug still exists in current apt versions (Ctrl-C
does nothing in a shell spawned from dpkg's conffile prompt running
under apt).

Ansgar

Bug#993004: yt: tests fail with h5py 3

[Ole Streicher]

Control: tags -1 pending
Control: block -1 by 992999

The new version of yt is ready. However it depends on a new package 
"unyt" that is currently in NEW.

Bug#993253: man page gone

[積丹尼 Dan Jacobson]

Package: binutils-common
Version: 2.37-4
Severity: wishlist
File: /usr/share/man/man1/strings.1.gz

$ zcat /usr/share/man/man1/strings.1.gz | wc
  0   0   0

$ dlocate -L binutils-common
Package binutils-common is not installed or 
/var/lib/dpkg/info/binutils-common.list is empty.

Bug#993252: Astroquery doesn't work with Astropy 4.3.1

[Ole Streicher]

Package: python3-astroquery
Version: 0.4.1+dfsg-4
Severity: serious

Dear maintainer,

The unit tests of astrquery errors with astropy version 4.3.1 which is
currently in unstable. Could you please update astroquery to the latest
version 0.4.3, which should resolve this?

A test log is here:

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroquery/14913971/log.gz

and the relevant error:

 ERROR collecting vo_conesearch/validator/tests/test_inpect.py _
ImportError while importing test module 
'/usr/lib/python3/dist-packages/astroquery/vo_conesearch/validator/tests/test_inpect.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/astroquery/vo_conesearch/validator/tests/test_inpect.py:8:
 in 
from astropy.utils.data import _find_pkg_data_path, get_pkg_data_filename
E   ImportError: cannot import name '_find_pkg_data_path' from 
'astropy.utils.data' (/usr/lib/python3/dist-packages/astropy/utils/data.py)


Thank you!

Cheers

Ole

Bug#993251: ruby-kramdown: Package kramdown vanished without notice or transitional package

[Axel Beckert]

Package: ruby-kramdown
Version: 2.3.1-2

Hi,

aptitude refused to upgrade ruby-kramdown initially, because I have the
package "kramdown" installed and it has a hard dependency on
"ruby-kramdown (= 2.3.0-5)".

It seems that the package "kramdown" is no more built by the
ruby-kramdown source package. This opens a bunch of questions about this
questionable change:

* Why is it removed at all?
* Why is this not mentioned in the according debian/changelog entry?
* Why is there no transitional package?

So please either:

* Reinstantiate the kramdown package (my preferred choice), or
* if you really want to get rid of, at least provide a transitional
  package for the period of one Debian Stable release.

And:

* Mention (potentially retroactively) in the debian/changelog that and
  why it was removed or at least that it is now (i.e. with a future
  upload) a transitional package plus the reason for that.

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

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ruby-kramdown depends on:
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  ruby  1:2.7+2
ii  ruby-coderay  1.1.3-4
ii  ruby-prawn2.3.0+dfsg-1
ii  ruby-prawn-table  0.2.2-1
ii  ruby-rouge3.21.0-1
ii  ruby-stringex 2.8.5-1

ruby-kramdown recommends no packages.

Versions of packages ruby-kramdown suggests:
ii  libjs-mathjax  2.7.9+dfsg-1

-- no debconf information

Bug#993250: mpb-doc: examples include non-reproducible Makefile containing facts only true for build system

[Simon McVittie]

Package: mpb-doc
Version: 1.11.1-3
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpaths usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

mpb-doc contains example files accompanied by a Makefile. This Makefile
contains facts that were true on the system where the package was built
but not necessarily true on the system where it will be used, notably the
absolute path to the build directory and the absolute paths to grep
and mkdir.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961747 is an example
of a similar bug report in a different package, illustrating the two
possible solutions:

- either:
  1. force the canonical paths to grep, mkdir etc. to be discovered
  2. canonicalize the Makefile to omit the absolute build paths
- or:
  - don't ship this Makefile at all, because it is probably not directly
useful to an end user: they would have to regenerate it from
Makefile.in to build the examples successfully, because Autotools
build systems are not typically intended to be portable between
directory locations or between machines

An implementation of the second approach is attached.

Thanks,
smcv
>From fe124c7a628027216b29c9cda9ae4a3250b88071 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 29 Aug 2021 11:48:45 +0100
Subject: [PATCH] d/rules: Remove generated Makefile from examples

Autotools build systems are generally not intended to be portable between
directories or between systems, and this Makefile contains absolute paths
to the package's build directory and detected absolute paths to tools
such as grep, making it non-reproducible.

Signed-off-by: Simon McVittie 
---
 debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/rules b/debian/rules
index b277bfb..fbce572 100755
--- a/debian/rules
+++ b/debian/rules
@@ -113,3 +113,8 @@ override_dh_auto_test:
 override_dh_installdocs:
 	dh_installdocs
 	rm -rf debian/mpb-doc/usr/share/doc/mpb-doc/html/mpb-mkdocs-theme/license
+
+override_dh_installexamples:
+	dh_installexamples
+	rm -f debian/mpb-doc/usr/share/doc/mpb*/examples/Makefile
+	rm -f debian/mpb-doc/usr/share/doc/mpb*/examples/Makefile.gz
-- 
2.33.0

Bug#993249: gnunet: stores wrong path to ifconfig if built on merged-/usr system

[Simon McVittie]

Source: gnunet
Version: 0.13.1-2
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If gnunet is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or installing
the usrmerge package into an existing installation), the path to ifconfig
is recorded in the binary package as /usr/sbin/ifconfig, rather than the
canonical /sbin/ifconfig.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/gnunet.html

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends=usrmerge and once without.

I suspect the same thing would happen if ifconfig was built on a system
where /sbin and /usr/sbin had instead been unified via a symlink farm.

The problematic situation is if the package is *built* on a unified-/usr
system, but *used* on a non-unified-/usr system. In this situation,
/usr/sbin/ifconfig exists on the build system but not on the system where
the package will be used, resulting in the features that use this
executable not working correctly.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends=usrmerge. I was unable to verify
this on unstable due to #993247, but it works on bullseye.

Some developers advocate unifying /sbin with /usr/sbin via a symlink farm
in /bin instead of merged-/usr, but that strategy would have a similar
practical effect on this particular package, and the same solution would
be required.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

smcv
>From 070a018b98e01a44b3231f4549f63cb7a09cc599 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 29 Aug 2021 11:06:42 +0100
Subject: [PATCH] d/rules: Specify canonical path for ifconfig

When this package is built on a system where both /usr/sbin/ifconfig and
/sbin/ifconfig exist (either merged-/usr or via a symlink farm), this
results in storing /usr/sbin/ifconfig in gnunet-config.h, which will
not work as intended on systems where only the traditional path
/sbin/ifconfig exists.

Signed-off-by: Simon McVittie 
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 7784791..045fe76 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@ include /usr/share/dpkg/architecture.mk
 	dh ${@}
 
 override_dh_auto_configure-arch:
-	dh_auto_configure -- --disable-rpath --with-microhttpd=yes $(shell dpkg-buildflags --export=configure)
+	dh_auto_configure -- --disable-rpath --with-microhttpd=yes $(shell dpkg-buildflags --export=configure) VAR_IFCONFIG_BINARY=/sbin/ifconfig
 
 override_dh_auto_configure-indep:
 
-- 
2.33.0

Bug#974038: cronie RFA to O

[Christian Kastner]

Control: retitle 974038 O: cronie -- Process Scheduling Daemon

I RFA'ed the package nearly two years ago. My hope was to find someone
to guide through a transition from src:cron to src:cronie as the default
job scheduler for Debian.

That did not happen, so unfortunately, it is now time to orphan the package.

As, until recently, also the main maintainer of src:cron (from which I
also stepped down a while ago), I still believe that src:cronie should
replace our src:cron as the default cron daemon.

Note that src:cron itself is in need of a new maintainer, see #984736.

Bug#993248: machinectl fails to bind mount a directory into a container

[shilin . aleksej]

Package: systemd-container
Version: 247.3-6

Hi,

machinectl seems to always fail when trying to bind mount a directory
into a container.

Steps to reproduce:

   1. sudo deboostrap bullseye /var/lib/machines/test
   2. sudo systemd-nspawn -M test
   3. Set root password, install dbus…
   4. sudo systemd-nspawn -bM test
   5. sudo machinectl bind test /path/to/some/dir --mkdir
   
The last command reliably fails with error message:

   Failed to bind mount: Failed to mount: No such file or directory
   
There is also an error message in systemd journal:

   авг 29 13:24:33 lenovo [18009]: Failed to mount
   /run/host/incoming/5Ok22y (type n/a) on  (MS_MOVE ""): No such
   file or directory
   
It doesn't depend on whether the target directory exists or not.

Bind mounts using --bind=… systemd-nspawn option work as expected.

--
Regards,
Алексей Шилин

Bug#993247: gnunet: FTBFS in unstable: checking for libunistring version... 0.0.0

[Simon McVittie]

Source: gnunet
Version: 0.13.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

While investigating reproducible-builds issues I tried building gnunet
for unstable using sbuild, on a Debian 11 'bullseye' virtual machine. The
build failed with this error:

> Setting up libunistring-dev:amd64 (0.9.10-6) ...
...
> checking for libunistring... yes
> checking how to link with libunistring... 
> /usr/lib/x86_64-linux-gnu/libunistring.so
> checking for libunistring version... 0.0.0
> configure: error: GNUnet requires libunistring >= 0.9.1.1

Full log attached.

I suspect this was triggered by a recent change in some other package,
because the build on reproducible-builds.org was successful a few
weeks ago.

smcv


gnunet_0.13.1-2_amd64_20210829t102219.build.gz
Description: application/gzip

Bug#993179: ncurses: enable format function attributes by default

[Thomas Dickey]

On Sat, Aug 28, 2021 at 04:16:11PM -0400, Thomas Dickey wrote:
> On Sat, Aug 28, 2021 at 03:47:37PM +0200, Christian Göttsche wrote:
> > On Sat, 28 Aug 2021 at 15:27, Thomas Dickey  wrote:
> > >
> > > sure - they're conditioned on a nonstandard extension to C.
> > > Debian can provide some patch which hardcodes that condition,
> > > but as I recall it, there's no clean way to provide this in
> > > standard C.
> > >
> > 
> > Yes, these function attributes are GNU extensions.
> > But GCC_PRINTFLIKE is defined via `__attribute__`[1], and if __GNUC__
> > is not set, `__attribute__` is defined empty.
> > So the attributes are only enabled if the compiler defines __GNUC__
> > and then the compiler should support those.
> 
> I believe you're misreading the source-code.
> 
> The GCC_PRINTF symbol is defined if the (build-time) configure check decides
> that the compiler supports the feature (i.e., while the compiler may accept
> __attribute__, it may not accept a particular parameter).  Ditto for 
> GCC_SCANF.

however, on review I agree that I can drop those symbols from the header
file (it's been redundant in building any of my programs for some time).

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


signature.asc
Description: PGP signature

Bug#993233: squashfs-tools 4.5 are incompatible with snap 2.49-1+b5

[Tomas Jura]

Hi

The squashfs-tools 4.5 are incompatible with snap 2.49-1+b5

The problem is solved by this pull request 
https://github.com/snapcore/snapd/pull/10567


All snaps are not usable now. A new release of debian package is 
necessary soon.


Tomas

Bug#993246: clevis: stores wrong path to systemd-reply-password if built on merged-/usr system

[Simon McVittie]

Source: clevis
Version: 16-2
Severity: important
Tags: bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If clevis is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or
installing the usrmerge package into an existing installation), the
path to systemd-reply-password is recorded in the binary package
as /usr/lib/systemd-reply-password, rather than the canonical
/lib/systemd-reply-password.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/clevis.html

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends=usrmerge and once without.

I suspect the same thing would happen if clevis was built on a system
where /lib and /usr/lib had instead been unified via a symlink farm.

The problematic situation is if the package is *built* on a unified-/usr
system, but *used* on a non-unified-/usr system. In this situation,
/usr/lib/systemd-reply-password exists on the build system but not on
the system where clevis will be used, resulting in the features that
use this executable not working correctly.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

I see that debian/patches/debian/2021-02-10.build-on-non-usrmerge.patch
tries to resolve this, but it doesn't seem to be having the desired
effect, because /usr is checked before /lib. Since you're applying a
Debian-specific patch for this *anyway*, I think the easiest solution
is likely to be to change this patch so that the patched result just
hard-codes the canonical path:

sd_reply_pass = find_program(
  join_paths('/', 'lib', 'systemd', 'systemd-reply-password'),
  required: false
)

Some developers advocate unifying /lib with /usr/lib via a symlink farm
in /lib instead of merged-/usr, but that strategy would have a similar
practical effect on this particular package, and the same solution would
be required.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

smcv