Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen

[Diederik de Haas]

On Saturday, 9 October 2021 21:28:19 CEST Diederik de Haas wrote:
> I'll try later whether I can reliably reproduce it with hibernate mode.

That appears to be the case. Hibernated my PC yesterday and started it up
today. After some time, I got the msgs again, this time also in dmesg:

# dmesg | tail -n15
[248910.645828] pl2303 5-4:1.0: pl2303 converter detected
[248910.645936] PM: hibernation: Basic memory bitmaps freed
[248910.645937] OOM killer enabled.
[248910.645938] Restarting tasks ... done.
[248910.647538] PM: hibernation: hibernation exit
[248910.650035] snd_hda_codec_hdmi hdaudioC0D0: HDMI: ELD buf size is 0, force 
128
[248910.650051] snd_hda_codec_hdmi hdaudioC0D0: HDMI: invalid ELD data byte 0
[248910.672631] usb 5-4: pl2303 converter now attached to ttyUSB0
[248910.672669] pl2303 5-3:1.0: pl2303 converter detected
[248910.699625] usb 5-3: pl2303 converter now attached to ttyUSB1
[248910.699669] pl2303 5-2:1.0: pl2303 converter detected
[248910.726626] usb 5-2: pl2303 converter now attached to ttyUSB2
[249275.040414] Uhhuh. NMI received for unknown reason 2c on CPU 0.
[249275.040417] Do you have a strange power saving mode enabled?
[249275.040417] Dazed and confused, but trying to continue

HTH,
  Diederik

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

Bug#996012: d-shlibs makes libzstd FTBFS: sed: -e expression #89, char 81: Unmatched ( or \(

[Helmut Grohne]

Package: d-shlibs
Version: 0.101
Severity: serious
Tags: ftbfs
Control: affects -1 + src:libzstd
User: helm...@debian.org
Usertags: rebootstrap

libzstd fails to build from source in unstable on amd64. A build now
ends with:

|debian/rules override_dh_install
| make[1]: Entering directory '/<>'
| # Call d-shlibmove to comply with library packaging guide
| d-shlibmove --commit \
| --multiarch \
| --devunversioned \
| --exclude-la \
| --movedev "debian/tmp/usr/include/*" usr/include \
| --movedev "debian/tmp/usr/lib/pkgconfig/*" 
usr/lib/x86_64-linux-gnu/pkgconfig \
| debian/tmp/usr/lib/lib*.so
| Library package automatic movement utility
| sed: -e expression #89, char 81: Unmatched ( or \(
| make[1]: *** [debian/rules:34: override_dh_install] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:16: binary] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

I think it is fairly safe to bet that this is caused by the d-shlibs
upload. What puzzles me a bit is that build time testing didn't catch
this. And that autopkgtests for d-shlibs aren't failing. Can you also
look into why testing didn't prevent this?

A workaround or quick solution would be appreciated as it breaks all
jobs at https://jenkins.debian.net/view/rebootstrap/.

Helmut

Bug#996007: calamares-settings-debian: Cannot install with encrypted root partition and unencrypted boot partition

[truetechie]

Package: calamares-settings-debian
Version: 11.0.5-2

When installing a system with Calamares and setting up an encrypted root 
partition and an unencrypted boot partition, no password prompt is given on 
boot during the initramfs and simply says that the partition failed to unlock. 
Presumably, there just needs to be a check if the boot partition is encrypted 
rather than simply if the root is encrypted.

I am using UEFI and the unofficial nonfree Cinnamon live image from 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/

Bug#996006: ghemical: Segmentation fault when starting

[Michael Stockenhuber]

Package: ghemical
Version: 3.0.0-5+b1
Severity: important

Dear Maintainer,

Starting ghemical in gnome results in a segfault. An xwindow is opened for less
than a second and then closes. I see the following in syslog
kernel: [ 4311.905429] ghemical[6179]: segfault at 0 ip  sp
7ffe739c2328 error 14 in ghemical[5650ebcd+2a000]
kernel: [ 4311.905439] Code: Unable to access opcode bytes at RIP
0xffd6.

I do not see any other error messages. Makes the program unusable.
Any help would be appreciated.
Best regards
Michael



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

Kernel: Linux 5.10.0-9-amd64 (SMP w/64 CPU threads)
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 ghemical depends on:
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libghemical5v5  3.0.0-4.3
ii  libgl1  1.3.2-1
ii  libglade2-0 1:2.6.4-2.3
ii  libglib2.0-02.66.8-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libgtk2.0-0 2.24.33-2
ii  libgtkglext11.2.0-9
ii  liboglappth21.0.0-2+b2
ii  libopenbabel7   3.1.1+dfsg-6
ii  libpango-1.0-0  1.46.2-3
ii  libstdc++6  10.2.1-6
ii  mpqc2.3.1-21

Versions of packages ghemical recommends:
ii  xfonts-100dpi  1:1.0.4+nmu1.1
ii  xfonts-75dpi   1:1.0.4+nmu1.1

ghemical suggests no packages.

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Spencer Olson]

Cloned nss repo and did a git bisect:  the first commit that causes
problems is at the upstream merge of 3.39 (upstream/3.39).

>From a very brief perusal of the upstream changes, I see there are
some edits with respect to TLS1.3--perhaps this is the reason for our
problems--I haven't yet looked hard at all the upstream changes (or
tried to bisect the upstream repo yet).

On Sat, Oct 9, 2021 at 12:05 PM Spencer Olson  wrote:
>
> Since it doesn't look like any progress has been made on this, I've
> started to work through some debugging.
>
> Right now, it looks like the problem is probably actually due to a
> change in libnss3.  In fact, the problem appears to be specifically in
> libssl3.so from the libnss3 package.
>
> The problem:
>   * certmonger has a hard time finishing the certificate requests
> because it can't seem to authenticate to the dogtag PKI server.
>
> Observations:
>  * When certmonger attempts to request a signed certificate for the
> renewal agent, it temporarily explicitly uses the ipa-ca-agent
> certificate which has been temporarily extracted from the
> /root/ca-agent.p12 storage.
>  * dogtag-submit attempts to use the CURL library to submit the
> request, subsequently approve the request, and then poll for its
> finish.
>  * The initial request does not use/require an encrypted channel, but
> the approval and subsequent queries do.
>  * These attempts to authenticate over this encrypted channel using
> the client certificate are rejected.
>
> Hacks & tests:
>  * By creating a very small c-program that does the same CURL commands
> as dogtag-submit from the certmonger package, this same authorization
> denied can be seen.
>  * By simply replacing the libssl3.so library, using either LD_PRELOAD
> or LD_LIBRARY_PATH, from a prior version, the requests succeed.  As of
> now, I've tried only one other version of libssl3.so (libnss3 3.35
> from ubuntu 18.04).
>  * Also, instead of linking against libcurl-nss and manualy replacing
> the libssl3.so library, success can be found by linking to
> libcurl-gnutls or libcurl-openssl
>
> I suspect that a compile option in libnss3 has to be changed in order
> for this to work again.
>
> Still todo:
>  * I haven't fully discovered which part/option from libnss3 might have 
> changed.
>  * I haven't yet successfully had libnss3 emit much
> debugging--probably have to recompile with DEBUG=1.

Bug#996011: ITP: sphinx-book-theme -- clean book theme for scientific explanations and documentation with Sphinx

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 
X-Debbugs-Cc: debian-de...@lists.debian.org, mo...@debian.org

* Package name: sphinx-book-theme
  Version : 0.1.5
  Upstream Author : Chris Holdgraf
* URL : https://github.com/executablebooks/sphinx-book-theme
* License : BSD-3-Clause
  Programming Lang: Python
  Description : clean book theme for scientific explanations and 
documentation with Sphinx

 This is a lightweight Sphinx theme designed to mimic the look-and-feel of an
 interactive book. It has the following primary features:
 .
  * Bootstrap 4 for visual elements and functionality
  * Flexible content layout that is inspired by beautiful online books, such as
the Edward Tufte CSS guide
  * Visual classes designed for Jupyter Notebooks. Cell inputs, outputs, and
interactive functionality are all supported
  * Launch buttons for online interactivity. For pages that are built with
computational material, connect your site to an online BinderHub for
  * interactive content

This is a new dependency of sphinx-copybutton

Bug#996010: ttf-mscorefonts-installer: Updating the copyright file to reflect recent changes in dir/file names and licensing stuff

[Abhishek Deshpande]

Package: ttf-mscorefonts-installer
Version: 3.7
Severity: normal

Dear Maintainer,

I was recently searching about the licensing stuff of the Microsoft Core Fonts.
For that purpose I opened the copyright file included in the package.

But it seems that the file was updated years ago, and does not reflect many
recent changes in filenames, and locations. For example, the READ_ME!.gz file
that has the licensing terms of font files themselves, does not exist in recent
package versions.

Could you please update the file to reflect recent versions ?



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

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ttf-mscorefonts-installer depends on:
ii  cabextract 1.9-1
ii  debconf [debconf-2.0]  1.5.71+deb10u1
ii  wget   1.20.1-1.1
ii  xfonts-utils   1:7.7+6

Versions of packages ttf-mscorefonts-installer recommends:
ii  fonts-liberation  1:1.07.4-9

ttf-mscorefonts-installer suggests no packages.

-- debconf information excluded

Bug#995986: simple-cdd: Firmware not being included in installer image

[肖盛文]

Would you set

export FORCE_FIRMWARE=1

in your build.conf and try again?

This would add all firmware-nonfree package into your iso.

在 2021/10/9 下午4:33, Scott 写道:

Package: simple-cdd
Version: 0.6.8
Severity: important

Dear Maintainer,

I'm using simple-cdd to build an installer which includes non-free firmware.

I find that the firmware is included in the installer when it is built when 
running on Debian 10, but the firmware is not included in the installer when it 
is built when running on Debian 11.

The result is that I can successfully run the installer on a Thinkpad T440 if 
the installer is built under Debian 10, but an installer built under Debian 11 
when run on the same Thinkpad T440 will ask for missing firmware to be provided 
before it reaches the installer screens which ask for a network to be selected 
and wifi credentials.

My profiles/.packages file has just one line:
firmware-iwlwifi

On Debian 11, when I look in 
/tmp/mirror/pool/non-free/f/firmware-nonfree/, I see the 
firmware-iwlwifi_20210315-3_all.deb package.

But when I look in /tmp/cd-build/bullseye/CD1/firmware/, all I 
see is a dep11/ directory, and I don't see the firmware file.

I don't know enough to know if this is an upstream problem, so I thought I'd 
report it here in the first instance.

If it helps, the project I'm using simple-cdd in is quite a simple one and you 
can see it here: https://github.com/countermeasure/basic-box

Cheers!


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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.35
ii  lsb-release 11.1.0
ii  python3 3.9.2-3
ii  python3-simple-cdd  0.6.8
ii  reprepro5.3.0-1.2
ii  rsync   3.2.3-4
ii  wget1.21-1+b1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  6.0.1-2

Versions of packages simple-cdd suggests:
pn  qemu-system | qemu-kvm  

-- no debconf information



--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995986: simple-cdd: Firmware not being included in installer image

[肖盛文]

Hi,

I don't know enough to know if this is an upstream problem, so I thought I'd 
report it here in the first instance.


The simple-cdd is a Debian native package, it has not other upstream, 
report it to here is the right palace.



--

肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#794960: tt-rss: Does not start on boot

[Sunil Mohan Adapa]

tag 794960 + patch
thanks

On Sat, 08 Aug 2015 11:00:31 -0700 Jeremy Malcolm  
wrote:

[...]

Since I upgraded to Debian 8, the tt-rss daemon no longer starts on
boot.  It appears that when it attempts to start, MySQL is not ready. 
However, I can start it manually.  I can see these errors from systemd:


I am able to reproduce the problem with PostgreSQL 13.0 and tt-rss 
21~git20210204.b4cbc79+dfsg-1 on a Debian Bullseye system (managed by 
FreedomBox). The problem only occurs sometimes. On boot, the service 
shows as failed to start and never retries. FreedomBox uses systemd.


Even though tt-rss.service has Wants= and After= on postgresql.service, 
postgresql is has Type=forking model and I don't believe it notifies 
systemd after startup. Hence after spawning postgresql successfully, 
tt-rss.service is immediately started. However, postgresql may be doing 
house keeping duties like recovering from journal/log on power failure, 
etc. and may not be accepting connections at the moment. If 
postgresql.service starts quickly, tt-rss.service works. Otherwise, it 
fails permanently (for that system boot).


I predict that this bug also happens in other cases. When database is 
being restarted for a security upgrade (say with needsrestart package 
like in case of FreedomBox) and if tt-rss tries to query at that time, 
tt-rss will fail permanently.


The reason for both the bugs is that tt-rss code has exit(101) if db 
connection fails. It does not try again in the next scheduled time after 
waiting 120 seconds.


Both the situations are more prominent in case of slow machine like 
single board computers running on SD cards like in case of FreedomBox.


Solution:

To solve both the problems comprehensively the following service options 
can be introduced:


# Restart the service every 120 seconds always. When tt-rss can't
# connect to a database temporarily, it will exist with exit code 101.
# 120 seconds is the default daemon sleep interval for tt-rss.
[Service]
Restart=always
RestartSec=120s

This essentially introduces a loop around daemon that spawns it every 
120 seconds after it is "done". This is the way the daemon intends to 
run according to its code (barring this bug, of course). So, restarting 
"always" does not seem incorrect.


Merge request available at: 
https://salsa.debian.org/debian/tt-rss/-/merge_requests/3


Another way to do this is to pass options to run it a single time and 
then use a systemd.timer to run it every 120 seconds.


Thanks,

--
Sunil

Bug#996009: RFS: iotop-c/1.20-1~bpo11+1 -- simple top-like I/O monitor (implemented in C)

[Boian Bonev]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "iotop-c":

 * Package name: iotop-c
   Version : 1.20-1~bpo11+1
   Upstream Author : Boian Bonev 
 * URL : https://github.com/Tomas-M/iotop
 * License : GPL-2.0+
 * Vcs : https://github.com/Tomas-M/iotop
   Section : admin

It builds those binary packages:

  iotop-c - simple top-like I/O monitor (implemented in C)

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

  https://mentors.debian.net/package/iotop-c/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/iotop-c/iotop-c_1.20-1~bpo11+1.dsc

Changes since the last upload:

 iotop-c (1.20-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.

Regards,
-- 
  Boian Bonev

Bug#993755: libcrypt.so.1: cannot open shared object file when upgrading from Stretch to Sid

[Otto Kekäläinen]

On Sun, Sep 26, 2021 at 9:27 PM Marco d'Itri  wrote:
>
> On Sep 27, Otto Kekäläinen  wrote:
>
> > Seems this libcrypt1 change not only affects upgrades from Stretch,
> > but in some cases even upgrades from Buster:
> Buster to Bookworm still means skipping a release.

Yeah, but one should be able to skip at least one release, right? What
is the point with e.g. Debian LTS if you can't upgrade from the Debian
LTS version to the newest stable?

Could you please consider if the libcrypt1 change was done in a way so
that at least Buster to Bookworm upgrades would work?

Bug#977427: [debian-mysql] Bug#977427: mariadb-10.5: bullseye: /updates -> -security

[Otto Kekäläinen]

On Sat, May 8, 2021 at 8:27 PM Otto Kekäläinen  wrote:
> Upstream closed the issue
> https://github.com/mroonga/mroonga/issues/353 by removing the file.
>
> Will close the issue once MariaDB imports latest Mroonga and the this
> file is no longer part of MariaDB sources either:
>   storage/mroonga/tools/travis/install.sh

The upstream "fix" in
https://github.com/mroonga/mroonga/commit/8aa9aa44a87a61861109aa99231de267719341cf
went in Mroonga version 11.02, however seems the Mroonga in MariaDB is
still at version 7.0.7 and has not updated for years:
https://github.com/MariaDB/server/tree/10.7/storage/mroonga

Bug#861553: [debian-mysql] Bug#861553: Please enable numa support

[Otto Kekäläinen]

This was submitted as
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/7
but not approved yet due to lacking quality assurance. Will most
likely be done in the 10.6 cycle.

Bug#992560: [debian-mysql] Bug#992560: mariadb-client-core-10.5: erases mysql client command history

[Otto Kekäläinen]

Hello Jan!

Readline was changed to libedit in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/d8796a0e3b5fc4450f4dc80fd159599a7f03997a
because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940879
when readline5 was orphaned. I don't know if anybody has researched
readline8 (https://tracker.debian.org/pkg/readline).

Seems this introduced a couple of regressions that were not caught
during the Bullseye dev/freeze cycle. Unfortunately changing
dependencies in a stable release is not possible. A script that
remediates it as you suggest is something which we could perhaps have.

Leaving this bug report open in case somebody wants to contribute with fixes.

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

[Otto Kekäläinen]

Hello!

The output of `mysql_upgrade
--socket=/run/user/1000/akonadi/mysql.socket` in your log from a
Fedora machine is not relevant. The output is exactly the same as any
normal mysql_upgrade run in Debian or elsewhere.

Your Fedora example would only be relevant if you copy the crashed
database from the Debian host to Fedora, and prove that the exact same
database in a cracked state recovers on Fedora but does not recover on
Debian.

Bug#996006: [Debichem-devel] Bug#996006: ghemical: Segmentation fault when starting

[Daniel Leidert]

Am Sonntag, dem 10.10.2021 um 10:42 +1100 schrieb Michael Stockenhuber:
> Package: ghemical
> Version: 3.0.0-5+b1
> Severity: important
> 
> Dear Maintainer,
> 
> Starting ghemical in gnome results in a segfault. An xwindow is opened for
> less
> than a second and then closes. I see the following in syslog
> kernel: [ 4311.905429] ghemical[6179]: segfault at 0 ip  sp
> 7ffe739c2328 error 14 in ghemical[5650ebcd+2a000]
> kernel: [ 4311.905439] Code: Unable to access opcode bytes at RIP
> 0xffd6.
> 
> I do not see any other error messages. Makes the program unusable.
> Any help would be appreciated.

Can you try this:

export GDK_BACKEND=x11
ghemical

Does it help?


Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

[Vagrant Cascadian]

Control: forwarded 977684 https://github.com/ravinet/mahimahi/pull/147

On 2020-12-18, Vagrant Cascadian wrote:
> On 2020-12-18, Keith Winstein wrote:
>> I am curious -- why is it important that builds be identical between
>> usrmerge systems and non-usrmerge systems?
>
> Because /usr/sbin/iptables is only present on usrmerge systems, if you
> hard-code the paths, then it will only work on usrmerge systems. There
> are typically compatibility symlinks /sbin -> /usr/sbin, so hard-coding
> the other way around is ... less bad... :)
...
>> Still, though, if this is the notion of reproducibility that
>> Debian wants its packages to have, I'm happy to comply and have no quibbles
>> with your patch.
>
>
> Great! Will submit a merge request soon.

Eventually, at least... :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#995972: fixed in d-shlibs 0.101

[Laurent Bigonville]

found 995972 0.101
thanks

On Sat, 09 Oct 2021 11:04:36 + Debian FTP Masters 
 wrote:



> * fix extend quirks libnspr4 libnss3;
> closes: bug#995972, thanks to Laurent Bigonville

Unfortunately it still FTBFS:

d-shlibmove --commit \
--devunversioned \
--multiarch \
--movedev "debian/tmp/usr/include/*" usr/include/ \
--movedev "debian/tmp/usr/lib/sparc64-linux-gnu/pkgconfig/*" \
usr/lib/sparc64-linux-gnu/pkgconfig \
debian/tmp/usr/lib/sparc64-linux-gnu/libsrtp2.so
Library package automatic movement utility
sed: -e expression #89, char 81: Unmatched ( or \(

Bug#995049: p11-kit: FTBFS on hurd-i386 (anf kfreebsd-any)

[Guillem Jover]

Hi!

On Tue, 2021-10-05 at 20:49:53 +0200, Svante Signell wrote:
> Index: p11-kit-0.24.0-2.3/common/unix-peer.c
> ===
> --- p11-kit-0.24.0-2.3.orig/common/unix-peer.c
> +++ p11-kit-0.24.0-2.3/common/unix-peer.c
> @@ -36,7 +36,6 @@
>  
>  #include "unix-peer.h"
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -47,6 +46,13 @@
>  #  include 
>  #endif
>  
> +#ifdef HAVE_GETPEEREID
> +/* Declare getpeereid() */
> +#include 
> +#else
> +#include 
> +#endif
> +
>  /* Returns the unix domain socket peer information.
>   * Returns zero on success.
>   */

This should not be needed if the patch were to use the
libbsd-overlay, which should make it transparent.

> @@ -73,7 +79,8 @@ p11_get_upeer_id (int cfd, uid_t *uid, u
>   *pid = cr.pid;
>  
>  #elif defined(HAVE_GETPEEREID)
> - /* *BSD/MacOSX */
> + /* *BSD/MacOSX/kFreeBSD/Hurd */
> +
>   uid_t euid;
>   gid_t egid;
>  

> Index: p11-kit-0.24.0-2.3/configure.ac
> ===
> --- p11-kit-0.24.0-2.3.orig/configure.ac
> +++ p11-kit-0.24.0-2.3/configure.ac
> @@ -132,6 +132,16 @@ if test "$os_unix" = "yes"; then
>   AC_CHECK_FUNCS([getpeereid])
>   AC_CHECK_FUNCS([getpeerucred])
>   AC_CHECK_FUNCS([issetugid])
> + case "$host_os" in
> + kfreebsd*-gnu | gnu*)
> + have_getpeereid=no
> + AC_CHECK_LIB(bsd, getpeereid, have_getpeereid=yes)
> + if test "x$have_getpeereid" = "xyes"; then
> + AC_DEFINE([HAVE_GETPEEREID], [1], [have getpeereid])
> + AC_SEARCH_LIBS([getpeereid], [bsd])
> + fi
> + ;;
> + esac

This would ideally use the PKG_CHECK_MODULES instead and set the CFLAGS
and LIBS variables appropriately before the other checks so that they
can find the functions provided by libbsd.

>   AC_CACHE_CHECK([for thread-local storage class],
>   [ac_cv_tls_keyword],

Thanks,
Guillem

Bug#996005: ca-certificates: fails upgrading when no new certs selected

[Christoph Anton Mitterer]

Package: ca-certificates
Version: 20211004
Severity: grave
Justification: renders package unusable


Hey.

It seems that when not selecting any of the new certs on upgrade, the package
install fails:
Setting up ca-certificates (20211004) ...
Updating certificates in /etc/ssl/certs...
chmod: cannot access '/etc/ssl/certs/ca-certificates.crt.new': No such file or 
directory
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 1


It did work though on other systems, where I selected some of the new certs.


Cheers,
Chris.

Bug#979100: NMU [RC] connman/1.36-2.3

[Bastian Germann]

I am sponsoring the NMU with the enclosed debdiff.
diff -Nru connman-1.36/debian/changelog connman-1.36/debian/changelog
--- connman-1.36/debian/changelog   2021-06-09 20:48:07.0 +0200
+++ connman-1.36/debian/changelog   2021-10-09 22:49:52.0 +0200
@@ -1,3 +1,12 @@
+connman (1.36-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/copyright: license on client/* is GPL-2+
+Upstream commit 27e37a50 relicensed this to GPL-2+ to fix the license
+incompatibility with GPL-3+ releases of libreadline. (Closes: #979100)
+
+ -- Ross Vandegrift   Sat, 09 Oct 2021 14:49:52 -0600
+
 connman (1.36-2.2) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru connman-1.36/debian/copyright connman-1.36/debian/copyright
--- connman-1.36/debian/copyright   2021-06-09 20:44:49.0 +0200
+++ connman-1.36/debian/copyright   2021-10-09 22:49:52.0 +0200
@@ -87,6 +87,10 @@
 Copyright: 2004-2011 Marcel Holtmann 
 License: GPL-2+
 
+Files: client/*
+Copyright: 2012-2014  Intel Corporation. All rights reserved.
+License: GPL-2+
+
 License: GPL-2
  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License version 2 as

Bug#993907: transmission-qt segfaults when adding a torrent

[Sandro Tosi]

> Upstream has a fix in:
>
> https://github.com/transmission/transmission/commit/16ec15d84be033cbc95ce8c768fe690bd461ad2f
>
> apparently part of:
>
> https://github.com/transmission/transmission/pull/1604

the full fix also includes

https://github.com/transmission/transmission/pull/1604/commits/f5d123946bb83a2e1cf25b688271b45f43c1c314

which needs to be applied before 16ec15d

> That's not part of a release yet, so it would need to be backported into
> Debian.

Unfortunately, upstream code has diverged substantially from what we
have in debian, so for this to be fixed we're going to have to wait
for a new upstream release.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#979100: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

On Sat, 9 Oct 2021 16:04:33 -0600 Ross Vandegrift wrote:

Upstream relicensed the client source to GPL v2 or later in 27e37a50
specifically to address this issue [1].  That change was released in 1.10, but
d/copyright does not reflect it.

I've opened an MR with the fix at [2], but need a sponsor to upload since I'm
DN.  Since the uploader and maintainer have been inactive for some years, and
since this bug has had no reply since January, I'll open a sponsorship request
bug today.

[1] - https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=27e37a50f35cc54c266cbd37e32dadbf3016e5e8 
[2] - https://salsa.debian.org/debian/connman/-/merge_requests/6


Thank you for pointing that out. I take this as RFS and can sponsor it 
as-is.

Bug#979100: Legally problematic GPL-3+ readline dependency

[Ross Vandegrift]

Control: tags -1 pending

Hello,

On Sat, 2 Jan 2021 18:47:07 +0100 Bastian Germann wrote:
> This package depends on libreadline8 which is GPL-3+ licensed. According 
> to debian/copyright parts of your package are GPL-2-only licensed. If 
> that is also (transitively) the case for the binaries that link with 
> libreadline.so.8 it might be legally problematic (see 
> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).

Since enlightenment Build-Depends on connman, I took a look.  I think this
isn't actually a problem. 

According to the docs, readline is only used in the cli client.  I confirmed in
a fresh sid container:

  # dpkg -l connman*
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name  Version Architecture Description
  
+++-=-===--===
  ii  connman   1.36-2.2amd64Intel 
Connection Manager daemon
  ii  connman-dev:amd64 1.36-2.2amd64Development 
files for connman
  ii  connman-doc   1.36-2.2all  ConnMan 
documentation
  ii  connman-vpn   1.36-2.2amd64Intel 
Connection Manager daemon - VPN daemon
  root@b7aa1f65ab2d:/# for i in $(dpkg -l connman* | grep connman | awk '{print 
$2}'); do dpkg -L $i | xargs ldd 2> /dev/null | grep -E '(^/)|libreadline'; 
done | grep -B 1 readline
  /usr/bin/connmanctl:
  libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 
(0x7f3b73d8b000)

Upstream relicensed the client source to GPL v2 or later in 27e37a50
specifically to address this issue [1].  That change was released in 1.10, but
d/copyright does not reflect it.

I've opened an MR with the fix at [2], but need a sponsor to upload since I'm
DN.  Since the uploader and maintainer have been inactive for some years, and
since this bug has had no reply since January, I'll open a sponsorship request
bug today.

[1] - 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=27e37a50f35cc54c266cbd37e32dadbf3016e5e8
 
[2] - https://salsa.debian.org/debian/connman/-/merge_requests/6

Ross

Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer

[Reinhard Tartler]

Control: fixed -1 3.3.1+ds2-1
Control: tags -1 bullseye

Thank you for your bugreport.

On Tue, Oct 5, 2021 at 10:51 AM Will Thompson  wrote:

> Package: podman
> Version: 3.0.1+dfsg1-3+b2
> Severity: important
>
> podman embeds a default seccomp policy, which based on my research is
> identical to that used by docker. The policy embedded in the bullseye
> version of podman is buggy when used to run a container whose glibc is
> 2.33.9000 or newer, due to that version's use of the clone3 syscall. The
> lengthy commit message at
>
> https://github.com/moby/moby/commit/9f6b562dd12ef7b1f9e2f8e6f2ab6477790a6594
> explains the issue in considerable detail.
>

I believe this should be fixed with the changes I'm prepareing in the
context of #994451

Would you mind trying the packages at
https://people.debian.org/~siretart/bug.994451/ and let me know if they fix
this issue as well? I'm fairly confident that it does.

Thank you.


-- 
regards,
Reinhard

Bug#996004: RFS: connman/1.36-2.2 [NMU] [RC] -- Intel Connection Manager daemon

[Ross Vandegrift]

Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: rvandegr...@debian.org

Dear mentors,

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

 * Package name: connman
   Version : 1.36-2.2
   Upstream Author : Marcel Holtmann
 * URL : 
 * License : GPL-2.0, GPL-2.0+
 * Vcs : https://git.kernel.org/pub/scm/network/connman/connman.git/
   Section : net

The release is waiting in this MR:

  https://salsa.debian.org/debian/connman/-/merge_requests/6

I cannot upload since I am DN, and this package isn't in my dak ACL.  The
uploader and maintainer seem inactive for some years, and #979100 has been open
without reply since January.

I don't know if I'm willing to salvage - enlightenment has a B-D on connman,
but I don't actually use it.

Changes since the last upload:

  connman (1.36-2.2) unstable; urgency=medium
  .
* Non-maintainer upload.
* d/copyright: license on client/* is GPL-2+
  Upstream commit 27e37a50 relicensed this to GPL-2+ to fix the license
  incompatibility with GPL-3+ releases of libreadline. (Closes: #979100)

Thanks,
Ross

Bug#996003: grub2: add GRUB_CMDLINE_LINUX_RECOVERY to /etc/default/grub

[Chris Vogel]

Package: grub2
Version: 2.04-20
Severity: wishlist
Tags: patch fixed-upstream

Hi,

I'd like to propose the following patch to add GRUB_CMDLINE_LINUX_RECOVERY to 
/etc/default/grub. The patch is accepted already upstream.

When generating grub.cfg using grub-mkconfig and the scripts 10_linux and
20_linux_xen there is no way to add kernel command line parameters _only_ to
the recovery entries generated.

This is needed to e.g. start a debug shell for systemd using the kernel command 
line parameter "systemd.debug-shell" or to recover in a system with encrypted 
root in situations where the decryption of the root filesystem per crypttab in 
the intiramfs image is broken and the recovery entry should contain information 
how to decrypt the rootfs (cryptopts=).

This patch does not change the default behaviour of GRUB if 
GRUB_CMDLINE_LINUX_RECOVERY is not set in /etc/default/grub.

If GRUB_CMDLINE_LINUX_RECOVERY is set and the generated recovery entry should
include the kernel parameter "single" or "recovery" the parameter must be 
explicitly included in GRUB_CMDLINE_LINUX_RECOVERY.

The patch from upstream is altered to respect the already implemented usage of
GRUB_CMDLINE_LINUX_RECOVERY for including friendly-recovery.

As far as I know all credits for the idea and the initial implementation go to
Kyle Ranking of Purism. If this patch is accepted it closes his bug(wishlist)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922425 .

Regards.


diff -Nru --exclude .gitignore grub2-2.04/debian/changelog 
grub2-2.04/debian/changelog
--- grub2-2.04/debian/changelog 2021-07-11 01:37:36.0 +0200
+++ grub2-2.04/debian/changelog 2021-10-08 22:47:02.0 +0200
@@ -1,3 +1,45 @@
+grub2 (2.04-20.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * apply patch from upstream:
+commit 0e5889b98ac202e0aadf04f4115a810304578219
+Author: Chris Vogel 
+Date:   Wed Sep 15 17:42:29 2021 +0200
+
+templates: Add GRUB_CMDLINE_LINUX_RECOVERY
+
+When generating grub.cfg using grub-mkconfig and the scripts 10_linux 
and
+20_linux_xen there is no way to add kernel command line parameters 
_only_ to
+the recovery entries generated.
+
+This is needed to e.g. start a debug shell in installations using 
systemd
+using the kernel command line parameter "systemd.debug-shell" or to 
recover
+in a system with encrypted root in situations where the decryption of 
the
+root filesystem per crypttab in the intiramfs image is broken and the 
recovery
+entry should contain information how to decrypt the rootfs 
(cryptopts=).
+
+This patch does not change the default behaviour of the GRUB if
+GRUB_CMDLINE_LINUX_RECOVERY is not set.
+
+If GRUB_CMDLINE_LINUX_RECOVERY is set and the generated recovery entry 
should
+include the kernel parameter "single" the parameter must be explicitly 
included
+in GRUB_CMDLINE_LINUX_RECOVERY.
+
+As far as I know all credits for the idea and the initial 
implementation go to
+Kyle Ranking of Purism.
+
+Signed-off-by: Kyle Rankin 
+Signed-off-by: Chris Vogel 
+Reviewed-by: Daniel Kiper 
+  * adopted the patch to respect the changes made to integrate 
friendly-recovery. 
+grubs behaviour will not change with this patch if 
GRUB_CMDLINE_LINUX_RECOVERY
+is not set in /etc/default/grub.
+If GRUB_CMDLINE_LINUX_RECOVERY is set in /etc/default/grub it needs to 
explicitly
+include 'single' or 'recovery' if those are wanted to be in the kernel 
command 
+line of recovery entries.
+
+ -- Chris Vogel   Fri, 08 Oct 2021 22:47:02 +0200
+
 grub2 (2.04-20) unstable; urgency=medium
 
   [ Mathieu Trudel-Lapierre ]
diff -Nru --exclude .gitignore grub2-2.04/debian/default/grub 
grub2-2.04/debian/default/grub
--- grub2-2.04/debian/default/grub  2021-07-11 01:37:36.0 +0200
+++ grub2-2.04/debian/default/grub  2021-10-08 22:47:02.0 +0200
@@ -9,6 +9,17 @@
 GRUB_CMDLINE_LINUX_DEFAULT="@DEFAULT_CMDLINE@"
 GRUB_CMDLINE_LINUX=""
 
+# Unless GRUB_DISABLE_RECOVERY is set to "true", two menu entries will be
+# generated for each Linux kernel: one default entry and one entry for
+# recovery mode.
+# This option lists command-line arguments to add only to the recovery menu
+# entry, before those listed in GRUB_CMDLINE_LINUX.
+# The default is "single" or "recovery" if /lib/recovery-mode/recovery-menu
+# (from package friendly-recovery) is present.
+# If the variable is set and the kernel command line shall include "single"
+# or "recovery" it must be explicitly included.
+# GRUB_CMDLINE_LINUX_RECOVERY="single"
+
 # Uncomment to enable BadRAM filtering, modify to suit your needs
 # This works with Linux (no patch required) and with any kernel that obtains
 # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
diff -Nru --exclude .gitignore 
grub2-2.04/de

Bug#995990: systemctl --now flag has no effect in two circumstances

[Michael Biebl]

Am 09.10.21 um 16:15 schrieb MichaIng:

Package: systemd
Version: 232-25+deb9u13

On current Debian Stretch, the systemctl --now flag, when enabling or 
disabling a service, has no effect in those two cases:


1. The service is already enabled respectively disabled: On newer 
systemd versions (Buster and Bullseye), the service is still started 
respectively stopped, even if the enabled/disabled state does not change.


2. An init.d service exists: In this case the --now flag has no effect, 
regardless whether the service is currently enabled or disabled. On 
newer systemd versions the presence of an init.d service has no effect 
on that flag.


Tested on a current Debian Stretch x86_64/amd64 system.


Thanks for your interest in Debian.
Stretch is old-old-stable by now and doesn't receive any updates anymore 
(aside from maybe security fixes done by the ELTS team.)


As this issue is apparently solved with more recent versions of systemd, 
I'm going to close this bug report.



Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Holger Wansing]

Hi,

David  wrote (Sat, 9 Oct 2021 21:56:24 +1100):
> I see that the suggestion to use 'cat' comes
> from #604839.
> 
> Yes, 'cat' will "work", however I feel there is no
> good reason to use 'cat' there.
> 
> Because the purpose of 'cat' is for concatenating
> multiple files, and it also requires a shell redirection
> from stdout. Both are unnecessary here.
> 
> I suggest this command should be used:
> # cp /usr/lib/syslinux/mbr.bin /dev/sdX

The documentation in the syslinux package also has

A simple MBR, roughly on par with the one installed by DOS (but
unencumbered), is included in the SYSLINUX distribution.  To install
it under Linux, simply type:

cat mbr.bin > /dev/XXX

... where /dev/XXX is the device you wish to install it on.

so I guess there is some good reason to do it this way.

Holger


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

Bug#994724: RFS: lebiniou-data/3.62.1-1 -- datafiles for Le Biniou

[Olivier Girondel]

Thanks, I think it needs the main lebiniou package for the test to succeed, 
since the printing to stderr is fixed there
Regards,

On October 9, 2021 10:39:32 PM GMT+02:00, Adam Borowski  
wrote:
>On Sat, Oct 09, 2021 at 04:31:48PM +0200, Olivier Girondel wrote:
>> Hi Adam,
>> 
>> Any news on this ?
>
>The autopkgtest for lebiniou-data still fails the same way.
>
>I've uploaded as-is, though, as it's possible the official machines are
>configured in a different way.  A bug that affects the schroot backend is
>still a bug, but I don't know if it will cause a failure here.
>
>
>Meow!
>-- 
>⢀⣴⠾⠻⢶⣦⠀
>⣾⠁⢠⠒⠀⣿⡁
>⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
>⠈⠳⣄
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#960729: More issues trying to create an Ubuntu focal image

[Simon McVittie]

Control: block -1 by 951766

On Sat, 09 Oct 2021 at 22:27:57 +0200, Daniel Leidert wrote:
> 2021-10-09 22:02:41 DEBUG STDERR: grub-install: unrecognized option 
> '--force-extra-removable'

This part is a vmdb2 bug and is tracked separately, as #951766.

If debci continues to use vmdb2 (directly or via autopkgtest-build-qemu,
I don't know which one it does), then debci will be unable to support
creating Ubuntu images until vmdb2 does.

autopkgtest-buildvm-ubuntu-cloud, which downloads an official Ubuntu
cloud image and modifies it in-place, might be a better way to get
autopkgtest images to run Ubuntu on qemu (it also doesn't need root if run
by someone with access to /dev/kvm, because it does all its privileged
stuff by booting the image in a temporary qemu instance, which might be
helpful). Doing the equivalent with Debian's official cloud images as a
base is on my list, but it is not a short list, so it's anyone's guess
when/whether I'll get there.

smcv

Bug#996000: general: System does not boot with second monitor attached

[Andy Simpkins]

Control: Severity -1 normal



Package: general
Severity: important
X-Debbugs-Cc: gaff...@live.com

Dear Maintainer,

I installed Debian 11 on a new computer (with a single monitor during 
installation, connected with HDMI).

Installation went well, but the monitor came up with a very limited resolution 
(1024x768, I think).


That isn't surprising, the installer (DI) will try and use only a minimum set 
of possible configurations, in order to function with most hardware it 
encounters

After a bit of googling, I found that the drivers for the Intel graphics on this board (Rocket Lake, UHD 750) were not 
included in the 5.10 kernel that came with Debian Bullseye.  I installed kernel 5.14 from Debian Testing, and that seemed to 
solve the issue - I got full resolution (still with a single monitor attached).


Ack that sounds about right to me too:  AFAICT Rocket Lake, UHD 750 is not yet 
officially supported in the linux kernel; i915 series has a generic driver, but 
not with full support for all devices in the series
this is perhaps a bit too new, and you may have to wait a while for the kernel 
drivers to arrive. [0]

 


Taking the system into use as my main system, I set it up with two monitors, one connected with an HDMI cable, one with a 
DVI cable.  (Both monitors are Benq 24 inch 1920x1080.)



Booting the system, it hangs during boot, with a message "VMC (outside TXT) disabled 
by bios".


This is stating that that you haven't enabled 'Intel virtualization technology' 
- this should have no effect on the graphic driver support, you would need to 
enable this if you want to run Virtual Machines.



Booting the system with only the HDMI-connected monitor attached works as expected, the system completes the boot sequence, 
I can log in and use the system.


Attaching the second monitor after boot also works, both monitors are 
recognized and works
As a workaround, I tried enabling "Intel virtualization technology" in the BIOS.  Booting with both monitors attached, there 
is no longer any error message, but the system still hangs during boot (with a blank screen).


I would expect the system to boot also with two monitors attached.


I would expect this as well - but until there is official support in the kernel 
for your new hardware then I am afraid that you may have to put up with only 
connecting the monitor after boot.

Trying newer, back ported kernels, when they become available, is probably your 
best bet.  You could try watching the kernel.org releases looking specifically 
for the mentions of i915, Rocket Lake, or UHD 750 beforue you try [1]


Very best wishes, and good luck with trying new kernels when they arrive

/Andy
(RattusRattus)

[0] https://gist.github.com/Postrediori/556706b28aff3b831d9e41acb47418c5
[1] https://www.kernel.org/

Bug#995993: RFS: zydis/3.1.0-1 [ITP] -- fast and lightweight x86/x86-64 disassembler library

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name: zydis
   Version : 3.1.0-1
   Upstream Author : zyantific 
 * URL : https://zydis.re
 * License : Expat
   Section : libs

It builds those binary packages:

  libzydis-dev - fast and lightweight x86/x86-64 disassembler library -
development
  libzydis3.1 - fast and lightweight x86/x86-64 disassembler library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/z/zydis/zydis_3.1.0-1.dsc

Changes for the initial release:

 zydis (3.1.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #995921

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYWHGABQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSWmMAQCPNODE2jzrDOrHuJengmbyDEVYgjGm
o2a0Mnej8iPqFwEAiXiqePle70zr/zCiObIH+uV1jlrgjuPhOYRW4CmoJAo=
=fMxW
-END PGP SIGNATURE-

Bug#994724: RFS: lebiniou-data/3.62.1-1 -- datafiles for Le Biniou

[Adam Borowski]

On Sat, Oct 09, 2021 at 04:31:48PM +0200, Olivier Girondel wrote:
> Hi Adam,
> 
> Any news on this ?

The autopkgtest for lebiniou-data still fails the same way.

I've uploaded as-is, though, as it's possible the official machines are
configured in a different way.  A bug that affects the schroot backend is
still a bug, but I don't know if it will cause a failure here.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
⠈⠳⣄

Bug#960729: More issues trying to create an Ubuntu focal image

[Daniel Leidert]

Hi there,

I manually edited /usr/bin/autopkgtest-build-qemu and added:

 debootstrap['mirror'] = mirror
 debootstrap['target'] = 'root'
+debootstrap['components'] = ['main', 'universe']

and got a little bit further. But then vmdb2 gets in the way:

2021-10-09 22:02:41 INFO Exec: ['chroot', '/tmp/tmpsued_j83', 'grub-install', 
'--target=i386-pc', '--no-nvram', '--force-extra-removable', '--no-floppy', 
'--modules=part_msdos part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', 
'/dev/loop0']
2021-10-09 22:02:41 DEBUG STDOUT: 
2021-10-09 22:02:41 DEBUG STDERR: grub-install: unrecognized option 
'--force-extra-removable'

This is due to /usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py:

vmdb.runcmd_chroot(
chroot,
[
"grub-install",
"--target=" + grub_target,
"--no-nvram",
"--force-extra-removable",
"--no-floppy",
"--modules=part_msdos part_gpt",
"--grub-mkdevicemap=/boot/grub/device.map",
image_dev,
],
)

After manually fixing this, it again fails when it comes to this:

2021-10-09 22:15:13 INFO Exec: ['sh', '-ec', 'export AUTOPKGTEST_BUILD_QEMU=1; 
/usr/share/debci/backends/qemu/customize.sh "$ROOT"']
2021-10-09 22:15:14 DEBUG STDOUT: 
2021-10-09 22:15:14 DEBUG STDERR: + readlink -f 
/usr/share/debci/backends/qemu/customize.sh
+ dirname /usr/share/debci/backends/qemu/customize.sh
[..]
+ grep -q ubuntu.com /usr/share/debootstrap/scripts/focal
+ distro=ubuntu
+ [ ubuntu = debian ]
+ proxy_opt=
+ chroot /tmp/tmpm4s6f9l_ apt-config shell PROXY Acquire::http::Proxy
+ RES=
+ eval 
/usr/share/debci/backends/qemu/customize.sh: 43: PROXY: parameter not set

2021-10-09 22:15:14 ERROR Program failed: 2

Then I dropped the proxy stuff from 
/usr/share/debci/backends/qemu/customize.sh and ran it again and it finally
worked.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#996002: python3.10: Please drop EXTRA_OPT_CFLAGS += -O2 for ia64

[John Paul Adrian Glaubitz]

Source: python3.10
Severity: normal
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi!

While testing the python3.10 build on ia64 for bug #995987, I noticed
that the workaround for GCC PR/85412 [1] is no longer necessary and
can therefore be removed.

Thus, could you drop "EXTRA_OPT_CFLAGS += -O2" for ia64? It builds fine
with the default optimization options.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995368: libapache2-mod-proxy-uwsgi - CVE-2021-36160 regression, altered PATH_INFO

[philippe . accorsi]

Hi,

Thanks for your answer but also thanks for the information about wrong 
configuration of apache.


I have tested both solution you explain here and both works good.

If I apply change in Apache configuration (like explain in the official 
documentation about "/") my app works good.

If I just apply your Debian patch, app works good also.

So, we wait for the debian patch for the oldest installation and I now 
can create a fix for Tracim project about wrong usage of "/" in apache2 
configuration.


Thanks a lot for your solution :) :) :)

Best regards.
Philippe
Sys Admin Algoo

Le 2021-10-09 18:04, Sylvain Beucler a écrit :

Hi,

On 05/10/2021 18:41, Sylvain Beucler wrote:

forwarded 995368 https://bz.apache.org/bugzilla/show_bug.cgi?id=65616


The Apache developers say there's an incorrect configuration in the
first place.  For example,
ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081/
should be
ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081
following the warning about slashes in the documentation:
http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass

However, they are currently considering an additional patch to restore
the previous (less strict) behavior.

Philippe, Josef, I prepared a build with the new patch, so you can test 
early:

https://people.debian.org/~beuc/lts/uwsgi/
https://people.debian.org/~beuc/lts/uwsgi/libapache2-mod-proxy-uwsgi_2.0.14+20161117-3+deb9u5_amd64.deb

I'm interested in your feedback.

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Jason Ernst]

So far I have a working build from the main zig repo for amd64, using the
llvm, clang and lld from the debian repos (although this is only possible
in sid because version 12 isn't present in the stable releases).
I've been doing it via docker to ensure a clean build environment:
https://github.com/compscidr/zig-deb/tree/debian-pkg/debian-pkg

It generates all of the needed files, and sings the package according to
guides I've been following from the mentors / maintainers websites.

I think I have figured out how to also produce cross-compiled packages for
other arches using pbuilder, but I'll have to abandon my docker approach
since it doesn't seem to work well with it. Planning on abandoning the
docker approach and using a debian VM in virtualbox (I typically use
Ubuntu).

I'm guessing in order to work in non-sid debian, I'll have to pull in the
actual llvm, lld, and clang sources like the bootstrap repo does. I'm
guessing these also need to be packaged in the debian source package too?

One thing I haven't tried is just using zig itself to do the cross
compiling.

Andrew, happy to work with you on this, if you like instead of dev-ing this
in my own repo, I can make a branch in either the main zig repo, or the
bootstrap repo - whichever you'd prefer. Also happy to jump on a quick call
to discuss.

Jason


On Sat, Oct 9, 2021 at 12:42 PM Andrew Kelley  wrote:

> On Tue, 5 Oct 2021 00:20:09 + Paul Wise  wrote:
> > Please make sure the package is built solely from the source from
> > scratch without any existing binaries using the upstream supported
> > bootstrap process:
> >
> > https://github.com/ziglang/zig-bootstrap/
> >
> > Personally, I think merging zig-bootstrap into the zig source repo
> > would make it easier for distros to use, but I hear upstream isn't
> > interested in that.
>
> Hi pabs,
>
> Upstream is definitely interested in cooperating with Debian maintainers
> to the benefit of our shared users :-)
>
> I'm happy to discuss this suggestion. Here is some information to help
> us sort this out:
>
>   * zig-bootstrap contains copy+pasted upstream sources from
> - LLVM, LLD, Clang
>   - There is currently 1 tiny patch to LLD's build script to adjust
> an include directory to depend on something inside zig-bootstrap rather
> than to an external directory
>   - There are also some deleted files which is merely an attempt to
> reduce tarball size; these could be restored to no harmful effect.
> - Zig (no patches)
> - zlib (no patches)
>
>   * Apart from this, the *only* utility that zig-bootstrap provides is a
> short build script, which does the following process:
> - Build LLVM, Clang, LLD, zlib, zig from source, for the host system
> - Using freshly built native zig, use `zig cc`/`zig c++` to rebuild
> LLVM, Clang, LLD, zlib, and zig again, from source, for the target system
>
> This is useful for upstream to provide portable binaries of Zig,
> however, I suspect that there is a better strategy which is more
> compatible with Debian's guidelines. In fact, I have been keeping
> Debian-friendliness in mind since the very beginning. I suspect you will
> actually find the main build process more amenable to packaging.
>
> In the main upstream repository (https://github.com/ziglang/zig/), it is
> a standard cmake build that I believe is already Debian-compatible. I am
> guessing you found the zig-bootstrap repository because you wanted to
> avoid depending on a zig binary to build zig; what you may not realize
> is that the main zig repository *does not utilize a zig binary* to be
> built. In fact, the main cmake build process does the following things:
>
>   * Use the system C++ compiler to build zig0 executable using system
> LLVM, LLD, Clang, zlib libraries
>   * Use the freshly built zig0 executable to build zig1.o
>   * Re-link some of the build artifacts, swapping in zig1.o, producing
> the zig binary
>
> I believe this is exactly what a Debian package wants, because you will
> end up with a binary that
>   * Uses the system LLVM, LLD, Clang, zlib libraries
>   * Was built with the system C/C++ compiler and linker
>
> I suggest to try out the main, standard way of building Zig and let me
> know if you run into any trouble. I suspect the main issues will be:
>
>   * deps/SoftFloat-3e is a vendored library. I would be happy to improve
> the cmake build script to enable an option to prefer the system
> SoftFloat library instead.
>
>   * lib/libcxx, lib/libcxxabi, lib/libunwind, lib/tsan and lib/include
> are copy+pasted (MIT-compatibly licensed) from other upstreams, and
> there are quite a few patches and preprocessing which is part of the zig
> development process. I am hoping that Debian can grant zig an exception
> for these files and not require them to be built by a debian package.
> These files are part of the "magic" that makes zig attractive in the
> first place, and although these files may look like they should be
> provided by other debian packages, I th

Bug#996000: general: System does not boot with second monitor attached

[Andrew M.A. Cater]

On Sat, Oct 09, 2021 at 09:18:06PM +0200, Asbjørn Sæbø wrote:
> Package: general
> Severity: important
> X-Debbugs-Cc: gaff...@live.com
> 
> Dear Maintainer,
> 
> I installed Debian 11 on a new computer (with a single monitor during 
> installation, connected with HDMI).
> 

What make/model of computer?  A server or desktop?

If you can run lspci or dmesg and quote the line that show the actual
device for video that would help enormously.

> Installation went well, but the monitor came up with a very limited 
> resolution (1024x768, I think).
> After a bit of googling, I found that the drivers for the Intel graphics on 
> this board (Rocket Lake, UHD 750) were not 
> included in the 5.10 kernel that came with Debian Bullseye.  I installed 
> kernel 5.14 from Debian Testing, and that seemed to 
> solve the issue - I got full resolution (still with a single monitor 
> attached).

Not a good idea to do this: mixing releases may cause problems that are hard
to debug and hard to solve. If you can afford to reinstall with just Debian
11, do so. It is likely that your computer needs firmware: this is from 
the non-free archive so is not included by default.

It would be a good idea to use the unofficial image which includes non-free
firmware to test this. The non-free firmware is in non-free because we often
do not have source / cannot modify the files we distribute - but it is 
prepared by Debian developers.

> 
> Taking the system into use as my main system, I set it up with two monitors, 
> one connected with an HDMI cable, one with a 
> DVI cable.  (Both monitors are Benq 24 inch 1920x1080.)
> Booting the system, it hangs during boot, with a message "VMC (outside TXT) 
> disabled by bios".
> 

How did you install  this system initially - via UEFI or in Legacy BIOS mode?

> Booting the system with only the HDMI-connected monitor attached works as 
> expected, the system completes the boot sequence, 
> I can log in and use the system.
> 
> Attaching the second monitor after boot also works, both monitors are 
> recognized and works.
> 
> As a workaround, I tried enabling "Intel virtualization technology" in the 
> BIOS.  Booting with both monitors attached, there 
> is no longer any error message, but the system still hangs during boot (with 
> a blank screen).
> 

This is diagnostic of missing firmware. You probably need 
firmware-linux-nonfree and firmware-misc-nonfree. It might be easiest to
install with just the firmware image.

If not, add contrib and non-free to the stanzas in /etc/apt/sources.list
as in

deb http://deb.debian.org/debian bullseye main contrib non-free
deb-src http://deb.debian.org/debian bullseye main contrib non-free

deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free
deb-src http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free

deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free

then update, upgrade and install at least firmware-linux-nonfree 
and firmware-misc-nonfree

> 
> I would expect the system to boot also with two monitors attached.
> 

This depends very much how the monitors are detected.

All the very best, as ever,

Andy Cater

Bug#995997: linux-image-5.14.0-2-amd64: Apps issue lots of clock_gettime calls on 5.14, performance drop in some cases

[Vladimir K]

Forcing clocksource back to tsc with tsc=nowatchdog fixes the performance 
regression.

Bug#995997: linux-image-5.14.0-2-amd64: Apps issue lots of clock_gettime calls on 5.14, performance drop in some cases.

[Vladimir K]

Seems to be related: 5.14 chooses hpet clocksource, while 5.10 uses tsc:


kernel: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.46-4 (2021-08-03)
kernel: tsc: Fast TSC calibration using PIT
kernel: tsc: Detected 2595.027 MHz processor
kernel: clocksource: refined-jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 7645519600211568 ns
kernel: clocksource: hpet: mask: 0x max_cycles: 0x, 
max_idle_ns: 133484873504 ns
kernel: clocksource: tsc-early: mask: 0x max_cycles: 
0x2567e268986, max_idle_ns: 440795272522 ns
kernel: clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 764504178510 ns
kernel: hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
kernel: hpet0: 3 comparators, 32-bit 14.318180 MHz counter
kernel: clocksource: Switched to clocksource tsc-early
kernel: clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: 
2085701024 ns
kernel: rtc_cmos 00:01: setting system clock to 2021-10-08T21:35:56 UTC 
(1633728956)
kernel: rtc_cmos 00:01: alarms up to one month, 114 bytes nvram, hpet irqs
kernel: sched_clock: Marking stable (940089949, 397183)->(945335255, -4848123)
kernel: tsc: Refined TSC clocksource calibration: 2615.448 MHz
kernel: clocksource: tsc: mask: 0x max_cycles: 0x25b33d90d1e, 
max_idle_ns: 440795316202 ns
kernel: clocksource: Switched to clocksource tsc




kernel: Linux version 5.14.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.3.0-11) 10.3.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 
5.14.9-2 (2021-10-03)
kernel: tsc: Fast TSC calibration using PIT
kernel: tsc: Detected 2595.027 MHz processor
kernel: clocksource: refined-jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 7645519600211568 ns
kernel: clocksource: hpet: mask: 0x max_cycles: 0x, 
max_idle_ns: 133484873504 ns
kernel: clocksource: tsc-early: mask: 0x max_cycles: 
0x2567e268986, max_idle_ns: 440795272522 ns
kernel: clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 764504178510 ns
kernel: hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
kernel: hpet0: 3 comparators, 32-bit 14.318180 MHz counter
kernel: clocksource: Switched to clocksource tsc-early
kernel: clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: 
2085701024 ns
kernel: rtc_cmos 00:01: setting system clock to 2021-10-08T21:38:57 UTC 
(1633729137)
kernel: rtc_cmos 00:01: alarms up to one month, 114 bytes nvram, hpet irqs
kernel: sched_clock: Marking stable (1012272366, 406541)->(1016715343, -4036436)
kernel: tsc: Refined TSC clocksource calibration: 2615.168 MHz
kernel: clocksource: tsc: mask: 0x max_cycles: 0x25b234d5bf1, 
max_idle_ns: 440795256376 ns
kernel: clocksource: Switched to clocksource tsc
kernel: clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as 
unstable because the skew is too large:
kernel: clocksource:   'hpet' wd_nsec: 515995748 wd_now: 
1bec100 wd_last: 14e0528 mask: 
kernel: clocksource:   'tsc' cs_nsec: 512040924 cs_now: 
547cae902 cs_last: 4f7fa46c4 mask: 
kernel: clocksource:   'tsc' is current clocksource.
kernel: tsc: Marking TSC unstable due to clocksource watchdog
kernel: TSC found unstable after boot, most likely due to broken BIOS. Use 
'tsc=unstable'.
kernel: sched_clock: Marking unstable (2098965976, 406565)<-(2103408384, 
-4036436)
kernel: clocksource: Checking clocksource tsc synchronization from CPU 1 to 
CPUs 0,2,4,6.
kernel: clocksource: Switched to clocksource hpet

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Andrew Kelley]

On Tue, 5 Oct 2021 00:20:09 + Paul Wise  wrote:

Please make sure the package is built solely from the source from
scratch without any existing binaries using the upstream supported
bootstrap process:

https://github.com/ziglang/zig-bootstrap/

Personally, I think merging zig-bootstrap into the zig source repo
would make it easier for distros to use, but I hear upstream isn't
interested in that.


Hi pabs,

Upstream is definitely interested in cooperating with Debian maintainers 
to the benefit of our shared users :-)


I'm happy to discuss this suggestion. Here is some information to help 
us sort this out:


 * zig-bootstrap contains copy+pasted upstream sources from
   - LLVM, LLD, Clang
 - There is currently 1 tiny patch to LLD's build script to adjust 
an include directory to depend on something inside zig-bootstrap rather 
than to an external directory
 - There are also some deleted files which is merely an attempt to 
reduce tarball size; these could be restored to no harmful effect.

   - Zig (no patches)
   - zlib (no patches)

 * Apart from this, the *only* utility that zig-bootstrap provides is a 
short build script, which does the following process:

   - Build LLVM, Clang, LLD, zlib, zig from source, for the host system
   - Using freshly built native zig, use `zig cc`/`zig c++` to rebuild 
LLVM, Clang, LLD, zlib, and zig again, from source, for the target system


This is useful for upstream to provide portable binaries of Zig, 
however, I suspect that there is a better strategy which is more 
compatible with Debian's guidelines. In fact, I have been keeping 
Debian-friendliness in mind since the very beginning. I suspect you will 
actually find the main build process more amenable to packaging.


In the main upstream repository (https://github.com/ziglang/zig/), it is 
a standard cmake build that I believe is already Debian-compatible. I am 
guessing you found the zig-bootstrap repository because you wanted to 
avoid depending on a zig binary to build zig; what you may not realize 
is that the main zig repository *does not utilize a zig binary* to be 
built. In fact, the main cmake build process does the following things:


 * Use the system C++ compiler to build zig0 executable using system 
LLVM, LLD, Clang, zlib libraries

 * Use the freshly built zig0 executable to build zig1.o
 * Re-link some of the build artifacts, swapping in zig1.o, producing 
the zig binary


I believe this is exactly what a Debian package wants, because you will 
end up with a binary that

 * Uses the system LLVM, LLD, Clang, zlib libraries
 * Was built with the system C/C++ compiler and linker

I suggest to try out the main, standard way of building Zig and let me 
know if you run into any trouble. I suspect the main issues will be:


 * deps/SoftFloat-3e is a vendored library. I would be happy to improve 
the cmake build script to enable an option to prefer the system 
SoftFloat library instead.


 * lib/libcxx, lib/libcxxabi, lib/libunwind, lib/tsan and lib/include 
are copy+pasted (MIT-compatibly licensed) from other upstreams, and 
there are quite a few patches and preprocessing which is part of the zig 
development process. I am hoping that Debian can grant zig an exception 
for these files and not require them to be built by a debian package. 
These files are part of the "magic" that makes zig attractive in the 
first place, and although these files may look like they should be 
provided by other debian packages, I think if you examine closely you 
will find that they are really derived works that are part of the zig 
project.


I hope this helps. I am happy to work together on this :-)

Warm regards,
Andrew



OpenPGP_signature
Description: OpenPGP digital signature

Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen

[Diederik de Haas]

Package: src:linux
Version: 5.14.9-2
Followup-For: Bug #955407

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I had seen this issue before too and actually had a knuckle and assumed
it was a one-time thing. But I've had 2 more in the last 2 days.
It *may* be related to hibernation as I usually don't use that, but I
had done it a while ago and surely I used it in the last 2 days.
After it has woken up and I'm logged in again, at some point, but not
immediately, I get the following (wall?) notices on all my terminal
windows (and also in KDE's notifications):

==
Message from syslogd@bagend at Oct  9 11:37:40 ...
 kernel:[204388.859511] Uhhuh. NMI received for unknown reason 2c on CPU 0.

Message from syslogd@bagend at Oct  9 11:37:40 ...
 kernel:[204388.859515] Do you have a strange power saving mode enabled?

Message from syslogd@bagend at Oct  9 11:37:40 ...
 kernel:[204388.859516] Dazed and confused, but trying to continue
==

I haven't seen or noticed that anything is broken, everything seems to
work fine. I'm not aware of any 'strange power saving mode'.
I'll try later whether I can reliably reproduce it with hybernate mode.

Most of the system components seems to be included already, but it looks
like the CPU is missing: AMD Ryzen 1800X (gen 1, stepping 1 iirc)

Cheers,
  Diederik

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

** Command line:
BOOT_IMAGE=/vmlinuz-5.14.0-2-amd64 
root=UUID=a2a5e481-0ac6-4e68-818f-38255bf7dd57 ro quiet

** Not tainted

** Kernel log:
[234339.703919] smpboot: Booting Node 0 Processor 9 APIC 0x3
[234339.703233] microcode: CPU9: patch_level=0x08001138
[234339.704185] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[234339.704187] ACPI: \_PR_.C003: Found 2 idle states
[234339.704737] CPU9 is up
[234339.704751] smpboot: Booting Node 0 Processor 10 APIC 0x5
[234339.704082] microcode: CPU10: patch_level=0x08001138
[234339.705019] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[234339.705021] ACPI: \_PR_.C005: Found 2 idle states
[234339.705619] CPU10 is up
[234339.705632] smpboot: Booting Node 0 Processor 11 APIC 0x7
[234339.704922] microcode: CPU11: patch_level=0x08001138
[234339.705925] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[234339.705927] ACPI: \_PR_.C007: Found 2 idle states
[234339.706578] CPU11 is up
[234339.706592] smpboot: Booting Node 0 Processor 12 APIC 0x9
[234339.705803] microcode: CPU12: patch_level=0x08001138
[234339.706929] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[234339.706932] ACPI: \_PR_.C009: Found 2 idle states
[234339.707679] CPU12 is up
[234339.707692] smpboot: Booting Node 0 Processor 13 APIC 0xb
[234339.706815] microcode: CPU13: patch_level=0x08001138
[234339.708036] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[234339.708039] ACPI: \_PR_.C00B: Found 2 idle states
[234339.708821] CPU13 is up
[234339.708846] smpboot: Booting Node 0 Processor 14 APIC 0xd
[234339.707927] microcode: CPU14: patch_level=0x08001138
[234339.709192] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[234339.709195] ACPI: \_PR_.C00D: Found 2 idle states
[234339.710059] CPU14 is up
[234339.710075] smpboot: Booting Node 0 Processor 15 APIC 0xf
[234339.709077] microcode: CPU15: patch_level=0x08001138
[234339.710418] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[234339.710420] ACPI: \_PR_.C00F: Found 2 idle states
[234339.711313] CPU15 is up
[234339.712824] ACPI: PM: Waking up from system sleep state S3
[234339.713468] ACPI: EC: interrupt unblocked
[234339.813943] pcieport :00:01.3: PME: Spurious native interrupt!
[234339.814254] ACPI: EC: event unblocked
[234339.814335] usb usb1: root hub lost power or was reset
[234339.814337] usb usb2: root hub lost power or was reset
[234339.815253] sd 0:0:0:0: [sda] Starting disk
[234339.874760] [drm] PCIE GART of 512M enabled.
[234339.874762] [drm] PTB located at 0x00F40090
[234339.874778] [drm] PSP is resuming...
[234339.907325] nvme nvme0: 7/0/0 default/read/poll queues
[234340.046604] usb 2-8: reset SuperSpeed USB device number 4 using xhci_hcd
[234340.061981] [drm] reserve 0x40 from 0xf40fc0 for PSP TMR
[234340.109208] [drm] kiq ring mec 2 pipe 1 q 0
[234340.127748] ata9: SATA link down (SStatus 0 SControl 300)
[234340.128410] ata6: SATA link down (SStatus 0 SControl 330)
[234340.128430] ata2: SATA link down (SStatus 0 SControl 300)
[234340.128434] ata12: SATA link down (SStatus 0 SControl 300)
[234340.128454] ata16: SATA link down (SStatus 0 SControl 300)
[234340.128954] ata3: SATA link down (SStatus 0 SControl 330)
[234340.129075] ata5: SATA link down (SStatus 0 SControl 330)
[234340.129082] ata13: SATA link do

Bug#996001: phpabtpl: lib-* may not require an autoload.php

[David Prévot]

Package: pkg-php-tools
Version: 1.42
Severity: wishlist
X-Debbugs-Cc: robin Gustafsson 

Hi Robin,

I noticed in php-mockery that composer.json has the following require:

"lib-pcre": ">=7.0",

phpabtpl should not add the following line:

require_once 'LibPcre/autoload.php';

(or at least provide a way to simply ignore it. The fact lib-pcre that
has no vendor/ part seems to make it impossible to ignore it via
debian/pkg-php-tools-autoloaders).

Regards

David


signature.asc
Description: PGP signature

Bug#996000: general: System does not boot with second monitor attached

[Asbjørn Sæbø]

Package: general
Severity: important
X-Debbugs-Cc: gaff...@live.com

Dear Maintainer,

I installed Debian 11 on a new computer (with a single monitor during 
installation, connected with HDMI).

Installation went well, but the monitor came up with a very limited resolution 
(1024x768, I think).
After a bit of googling, I found that the drivers for the Intel graphics on 
this board (Rocket Lake, UHD 750) were not 
included in the 5.10 kernel that came with Debian Bullseye.  I installed kernel 
5.14 from Debian Testing, and that seemed to 
solve the issue - I got full resolution (still with a single monitor attached).

Taking the system into use as my main system, I set it up with two monitors, 
one connected with an HDMI cable, one with a 
DVI cable.  (Both monitors are Benq 24 inch 1920x1080.)
Booting the system, it hangs during boot, with a message "VMC (outside TXT) 
disabled by bios".

Booting the system with only the HDMI-connected monitor attached works as 
expected, the system completes the boot sequence, 
I can log in and use the system.

Attaching the second monitor after boot also works, both monitors are 
recognized and works.

As a workaround, I tried enabling "Intel virtualization technology" in the 
BIOS.  Booting with both monitors attached, there 
is no longer any error message, but the system still hangs during boot (with a 
blank screen).


I would expect the system to boot also with two monitors attached.

Bug#995999: FTBFS: FAIL: TestChunkDiskMapper_WriteChunk_Chunk_IterateChunks

[Shengjing Zhu]

Package: prometheus
Version: 2.24.1+ds-1
Severity: serious
X-Debbugs-Cc: z...@debian.org

Hi,

When rebuild packages, I find it FTBFS.

=== RUN   TestChunkDiskMapper_WriteChunk_Chunk_IterateChunks
--- FAIL: TestChunkDiskMapper_WriteChunk_Chunk_IterateChunks (0.05s)
panic: runtime error: slice bounds out of range [:104326] with capacity 104293 
[recovered]
panic: runtime error: slice bounds out of range [:104326] with capacity 
104293

goroutine 7 [running]:
testing.tRunner.func1.2(0x60da60, 0xc0005f8030)
/usr/lib/go-1.16/src/testing/testing.go:1143 +0x332
testing.tRunner.func1(0xc01e00)
/usr/lib/go-1.16/src/testing/testing.go:1146 +0x4b6
panic(0x60da60, 0xc0005f8030)
/usr/lib/go-1.16/src/runtime/panic.go:965 +0x1b9
github.com/prometheus/prometheus/tsdb/chunks.TestChunkDiskMapper_WriteChunk_Chunk_IterateChunks(0xc01e00)

/build/1st/prometheus-2.24.1+ds/build/src/github.com/prometheus/prometheus/tsdb/chunks/head_chunks_test.go:122
 +0xc9c
testing.tRunner(0xc01e00, 0x637600)
/usr/lib/go-1.16/src/testing/testing.go:1193 +0xef
created by testing.(*T).Run
/usr/lib/go-1.16/src/testing/testing.go:1238 +0x2b3
FAILgithub.com/prometheus/prometheus/tsdb/chunks0.116s


It also FTBFS on tests.reproducible-builds.org, ci.debian.net

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/prometheus.html
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/prometheus/15535224/log.gz

Bug#979096: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

I intend to NMU the package. The debdiff is enclosed.
diff -Nru omake-0.10.3/debian/changelog omake-0.10.3/debian/changelog
--- omake-0.10.3/debian/changelog   2021-02-01 21:59:49.0 +0100
+++ omake-0.10.3/debian/changelog   2021-10-09 20:02:08.0 +0200
@@ -1,3 +1,10 @@
+omake (0.10.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with libedit instead of libreadline (Closes: #979096)
+
+ -- Bastian Germann   Sat, 09 Oct 2021 20:02:08 +0200
+
 omake (0.10.3-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru omake-0.10.3/debian/control omake-0.10.3/debian/control
--- omake-0.10.3/debian/control 2021-02-01 21:56:49.0 +0100
+++ omake-0.10.3/debian/control 2021-10-09 20:00:57.0 +0200
@@ -7,7 +7,7 @@
 Build-Depends:
  debhelper-compat (= 13),
  ocaml-nox,
- libreadline-dev,
+ libeditreadline-dev,
  libncurses5-dev,
  dh-ocaml
 Standards-Version: 4.5.0

Bug#991324: micro-httpd: systemd install dependency fails if binding to IP other than 0.0.0.0

[Martin-Éric Racine]

ti 20. heinäk. 2021 klo 22.49 Sudip Mukherjee
(sudipm.mukher...@gmail.com) kirjoitti:
> On Tue, Jul 20, 2021 at 6:51 PM Martin-Éric Racine
>  wrote:
> >
> > Package: micro-httpd
> > Version: 20051212-15.1
> > Severity: normal
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > The dependencies in the systemd files that currently ship with micro-httpd 
> > only work if micro-httpd is bound to 0.0.0.0 as shipped. If it's bound to 
> > another IP address, systemd will report a failure to launch micro-httpd, 
> > because all network interfaces are not up yet, so the IP we're trying to 
> > bind to hasn't been assigned to any interface yet.
>
> Thanks for using micro-httpd and testing. Will attend to this one and
> also the earlier one that you have raised after the freeze is over.

Hey Sudip!

Would you have time to look into this now?

Martin-Éric

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Spencer Olson]

Since it doesn't look like any progress has been made on this, I've
started to work through some debugging.

Right now, it looks like the problem is probably actually due to a
change in libnss3.  In fact, the problem appears to be specifically in
libssl3.so from the libnss3 package.

The problem:
  * certmonger has a hard time finishing the certificate requests
because it can't seem to authenticate to the dogtag PKI server.

Observations:
 * When certmonger attempts to request a signed certificate for the
renewal agent, it temporarily explicitly uses the ipa-ca-agent
certificate which has been temporarily extracted from the
/root/ca-agent.p12 storage.
 * dogtag-submit attempts to use the CURL library to submit the
request, subsequently approve the request, and then poll for its
finish.
 * The initial request does not use/require an encrypted channel, but
the approval and subsequent queries do.
 * These attempts to authenticate over this encrypted channel using
the client certificate are rejected.

Hacks & tests:
 * By creating a very small c-program that does the same CURL commands
as dogtag-submit from the certmonger package, this same authorization
denied can be seen.
 * By simply replacing the libssl3.so library, using either LD_PRELOAD
or LD_LIBRARY_PATH, from a prior version, the requests succeed.  As of
now, I've tried only one other version of libssl3.so (libnss3 3.35
from ubuntu 18.04).
 * Also, instead of linking against libcurl-nss and manualy replacing
the libssl3.so library, success can be found by linking to
libcurl-gnutls or libcurl-openssl

I suspect that a compile option in libnss3 has to be changed in order
for this to work again.

Still todo:
 * I haven't fully discovered which part/option from libnss3 might have changed.
 * I haven't yet successfully had libnss3 emit much
debugging--probably have to recompile with DEBUG=1.

Bug#995998: tzdata: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: tzdata 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of tzdata debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40

[Samuel Henrique]

Hello Leo,

> Just pushed to the main repo. Please take a look and let me know if it works!

It works nicely!

I have committed a few more changes, pushed it and uploaded the package.

I noticed you didn't add yourself to the Uploaders field and I didn't
do it because I didn't know if you wanted that. But please feel free
to do so if that's your intention.

Thank you!

-- 
Samuel Henrique 

Bug#995997: linux-image-5.14.0-2-amd64: Apps issue lots of clock_gettime calls on 5.14, performance drop in some cases.

[Vladimir K]

Package: src:linux
Version: 5.14.9-2
Severity: normal

Dear Maintainer, after upgrade from 5.10 to 5.14 I noticed severe pefrormance 
regression when running
GZDoom with content above some threshold of complexity.
More info here: https://github.com/coelckers/gzdoom/issues/1479
It seems to be AMD-specific and not GPU-related.

The gist of the symptoms: judging by strace output, on 5.14 applications (not 
just gzdoom) issue lots of
clock_gettime(CLOCK_MONOTONIC,... calls whereas on 5.10 they do not.
In particular case of gzdoom when the game content crosses some degree of 
complexity,
gzdoom process does almost nothing but flooding clock_gettime(), and 
performance drops to standstill.

>From strace
...
clock_gettime(CLOCK_MONOTONIC, {tv_sec=55, tv_nsec=7221346}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=55, tv_nsec=7248727}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=55, tv_nsec=7275614}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=55, tv_nsec=7303488}) = 0
...

This does not happen on 5.10 at all.

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

** Command line:
BOOT_IMAGE=/@/boot/vmlinuz-5.14.0-2-amd64 
root=UUID=859ba516-d84d-458c-ac5c-979ce55ca125 ro rootflags=subvol=@ quiet

** Not tainted

** Kernel log:
[21847.948105] ACPI: \_SB_.PLTF.C003: Found 3 idle states
[21847.948383] CPU3 is up
[21847.948415] smpboot: Booting Node 0 Processor 4 APIC 0x4
[21847.948017] microcode: CPU4: patch_level=0x08608103
[21847.949236] ACPI: \_SB_.PLTF.C004: Found 3 idle states
[21847.949648] CPU4 is up
[21847.949681] smpboot: Booting Node 0 Processor 5 APIC 0x5
[21847.949101] microcode: CPU5: patch_level=0x08608103
[21847.949947] ACPI: \_SB_.PLTF.C005: Found 3 idle states
[21847.950282] CPU5 is up
[21847.950314] smpboot: Booting Node 0 Processor 6 APIC 0x6
[21847.949854] microcode: CPU6: patch_level=0x08608103
[21847.950691] ACPI: \_SB_.PLTF.C006: Found 3 idle states
[21847.951321] CPU6 is up
[21847.951381] smpboot: Booting Node 0 Processor 7 APIC 0x7
[21847.950992] microcode: CPU7: patch_level=0x08608103
[21847.951672] ACPI: \_SB_.PLTF.C007: Found 3 idle states
[21847.952095] CPU7 is up
[21847.952988] ACPI: PM: Waking up from system sleep state S3
[21847.957364] ACPI: EC: interrupt unblocked
[21848.004289] ACPI: EC: event unblocked
[21848.004709] pci :00:00.2: can't derive routing for PCI INT A
[21848.004715] pci :00:00.2: PCI INT A: no GSI
[21848.004776] [drm] PCIE GART of 1024M enabled.
[21848.004779] [drm] PTB located at 0x00F40090
[21848.004795] [drm] PSP is resuming...
[21848.024666] [drm] reserve 0x40 from 0xf47f80 for PSP TMR
[21848.034112] nvme nvme1: 16/0/0 default/read/poll queues
[21848.105569] nvme nvme0: 16/0/0 default/read/poll queues
[21848.133966] amdgpu :06:00.0: amdgpu: RAS: optional ras ta ucode is not 
available
[21848.144289] amdgpu :06:00.0: amdgpu: RAP: optional rap ta ucode is not 
available
[21848.144293] amdgpu :06:00.0: amdgpu: SECUREDISPLAY: securedisplay ta 
ucode is not available
[21848.144298] amdgpu :06:00.0: amdgpu: SMU is resuming...
[21848.144345] amdgpu :06:00.0: amdgpu: dpm has been disabled
[21848.145269] amdgpu :06:00.0: amdgpu: SMU is resumed successfully!
[21848.146596] [drm] kiq ring mec 2 pipe 1 q 0
[21848.147535] [drm] DMUB hardware initialized: version=0x01010019
[21848.199782] ACPI: \: failed to evaluate _DSM (0x1001)
[21848.199787] ACPI: \: failed to evaluate _DSM (0x1001)
[21848.199788] ACPI: \: failed to evaluate _DSM (0x1001)
[21848.199788] ACPI: \: failed to evaluate _DSM (0x1001)
[21848.259234] usb 3-3: reset high-speed USB device number 3 using xhci_hcd
[21848.261103] usb 1-3: reset high-speed USB device number 3 using xhci_hcd
[21848.319629] ata1: SATA link down (SStatus 0 SControl 300)
[21848.323298] ata2: SATA link down (SStatus 0 SControl 300)
[21848.541531] usb 3-4: reset full-speed USB device number 4 using xhci_hcd
[21848.545081] [drm] VCN decode and encode initialized successfully(under DPG 
Mode).
[21848.545134] [drm] JPEG decode initialized successfully.
[21848.545332] amdgpu :06:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
[21848.545334] amdgpu :06:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 
on hub 0
[21848.545336] amdgpu :06:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 
on hub 0
[21848.545336] amdgpu :06:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 
on hub 0
[21848.545337] amdgpu :06:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 
on hub 0
[21848.545338] amdgpu :06:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 
on hub 0
[21848.545339] amdgpu :06:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 
on hub 0
[21848.545339] amdgpu :06:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 
on hub 0
[21848.545340] amdgpu :06:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 
on hub 0
[2

Bug#984041: duma: ftbfs with GCC-11

[Bastian Germann]

Control: fixed -1 duma/2.5.21-2

On Wed, 03 Mar 2021 16:11:45 + Matthias Klose wrote:

createconf.c:169:12: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  169 | *( (unsigned long long int *) addr ) = 0L;
  |^
createconf.c:179:19: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
  179 |   TYPE addr = (TYPE)(buffer) + offset;
  |   ^
createconf.c:182:12: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  182 | *( (unsigned char *) addr ) = 0;
  |^
createconf.c:183:12: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  183 | *( (unsigned short int*) addr ) = 0;
  |^
createconf.c:184:12: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  184 | *( (unsigned int *)  addr ) = 0;
  |^
createconf.c:185:12: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  185 | *( (unsigned long int *) addr ) = 0L;
  |^
createconf.c:186:12: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  186 | *( (float *) addr ) = 0.0F;


I could not reproduce the error with the current version.

Bug#995923: linux: Regression in 5.14: no more multichannel audio on Rock64

[Diederik de Haas]

Control: tag -1 patch

On Friday, 8 October 2021 10:43:14 CEST Diederik de Haas wrote:
> In kernel 5.13 on my Rock64, `pactl list cards` correctly identified my
> AVR (SC-1224) and had various multichannel audio profiles I could choose
> from. Since kernel 5.14, `paclt list cards` no longer identifies my AVR and
> I only have stereo audio profiles.

I went on my first 'git bisect' action on the upstream code and that identified 
commit 907f0a3051869a61499905377212500155bd28ec as the first bad commit, with 
commit message "ASoC: simple-card: Fill in driver name".

No idea why that commit would break multichannel audio, but I built a 5.14.10 
upstream kernel with 2 changes:
- Kernel config changes (to arm64/defconfig) ~ the same as I had proposed for 
the Debian kernel (PMIC + audio related)
- Reverting of commit 907f0a3051869a61499905377212500155bd28ec

And when I booted into that, I had my multichannel audio back again \o/

I haven't yet built a new Debian kernel with this change, but I would be 
extremely surprised if it wouldn't fix the issue there too.

FWIW, my 'git bisect' log:
==

Good commit: bd31b9efbf549d9630bf2f269a3a56dcb29fcac1
Bad commit:  d6b63b5b7d7f363c6a54421533791e9849adf2e0

$ git checkout rock64-5.14-dev-4-gd6b63b5b7d
$ git bisect start
$ git bisect bad
$ git bisect good bd31b9efbf549d9630bf2f269a3a56dcb29fcac1
$ git bisect good 498386d1c4d98a72db7a2f51473593ad563b45ae
$ git bisect good c50f381afcab30125e43258bba9316054c4ddfac
$ git bisect good 4cb9d648f669c4e31bec4447c98553c65079681b
$ git bisect good 590cfb082837cc6c0c595adf1711330197c86a58
$ git bisect bad f5e2d697d3cbd6d20684eddd3e280809c30e37a1
$ git bisect good bf35a1eeaca618341409f94c90271bb14d1c484a
$ git bisect bad 657e473e8813f62c536f74650188d078f9fff345
$ git bisect good 0ba0f44fd516b34c9f40cd82fd480705d0f378dc
$ git bisect bad 4b1d51715d1cf78a1527fe426fc0278dcfea1959
$ git bisect bad 907f0a3051869a61499905377212500155bd28ec
907f0a3051869a61499905377212500155bd28ec is the first bad commit
commit 907f0a3051869a61499905377212500155bd28ec
Author: Guido Günther 
Date:   Tue Jun 22 10:27:09 2021 +0200

ASoC: simple-card: Fill in driver name

 
==

I guess this should be reported upstream, but I have no idea who that would be 
and how and where to report it.

Cheers,
  Diederik

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

Bug#995851: qcelemental: please package latest upstream release

[Andrey Rahmatullin]

Control: severity -1 serious
Control: tags -1 + ftbfs upstream fixed-upstream
Control: found -1 0.17.0+dfsg-3
Control: retitle -1 FTBFS: tests fail with new pydantic

Unfortunately the build-time tests fail too so it FTBFS.
Fixed by https://github.com/MolSSI/QCElemental/pull/266

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#995867: xtensor: mipsel FTBFS (relocation truncated to fit: R_MIPS_CALL16)

[Drew Parsons]

Source: xtensor
Followup-For: Bug #995867
Control: retitle -1 mipsel FTBFS (relocation truncated to fit: R_MIPS_CALL16)

The problem with undefined `__umodsi3' `__udivsi3' is not easily
reproduced.

But the mipsel build failure is consistent.

The more common symptom is "relocation truncated" errors
e.g.

[ 39%] Linking CXX executable test_xreducer
cd /<>/obj-mipsel-linux-gnu/test && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/test_xreducer.dir/link.txt --verbose=1
/usr/bin/c++ -O0 -std=c++14 -Wunused-parameter -Wextra -Wreorder -Wconversion 
-Wsign-conversion -Wold-style-cast -Wunused-variable 
-ftemplate-backtrace-limit=0 -Wl,-z,relro -rdynamic 
CMakeFiles/test_xreducer.dir/main.cpp.o 
CMakeFiles/test_xreducer.dir/test_xreducer.cpp.o -o test_xreducer  -lpthread 
cd /<>/obj-mipsel-linux-gnu/test && /usr/bin/c++  
-I/<>/include -O0 -std=c++14 -Wunused-parameter -Wextra -Wreorder 
-Wconversion -Wsign-conversion -Wold-style-cast -Wunused-variable 
-ftemplate-backtrace-limit=0 -MD -MT 
test/CMakeFiles/test_xexpression_traits.dir/main.cpp.o -MF 
CMakeFiles/test_xexpression_traits.dir/main.cpp.o.d -o 
CMakeFiles/test_xexpression_traits.dir/main.cpp.o -c 
/<>/test/main.cpp
CMakeFiles/test_xreducer.dir/test_xreducer.cpp.o: in function 
`__gthread_active_p()':
test_xreducer.cpp:(.text+0x1c): relocation truncated to fit: R_MIPS_GOT16 
against `__pthread_key_create@@GLIBC_2.0'
CMakeFiles/test_xreducer.dir/test_xreducer.cpp.o: in function 
`xt::xreducer_features::xreducer_features()':
test_xreducer.cpp:(.text+0x23c): relocation truncated to fit: R_MIPS_CALL16 
against `_Unwind_Resume@@GCC_3.0'
test_xreducer.cpp:(.text+0x2ac): relocation truncated to fit: R_MIPS_CALL16 
against `_Unwind_Resume@@GCC_3.0'
CMakeFiles/test_xreducer.dir/test_xreducer.cpp.o: in function 
`xt::_DOCTEST_ANON_FUNC_2()':
test_xreducer.cpp:(.text+0x418): relocation truncated to fit: R_MIPS_CALL16 
against `raise@@GLIBC_2.0'
test_xreducer.cpp:(.text+0x4b0): relocation truncated to fit: R_MIPS_CALL16 
against `__cxa_begin_catch@@CXXABI_1.3'
test_xreducer.cpp:(.text+0x4e0): relocation truncated to fit: R_MIPS_CALL16 
against `__cxa_end_catch@@CXXABI_1.3'
test_xreducer.cpp:(.text+0x504): relocation truncated to fit: R_MIPS_CALL16 
against `__cxa_end_catch@@CXXABI_1.3'
test_xreducer.cpp:(.text+0x5a4): relocation truncated to fit: R_MIPS_CALL16 
against `_Unwind_Resume@@GCC_3.0'
CMakeFiles/test_xreducer.dir/test_xreducer.cpp.o: in function 
`xt::_DOCTEST_ANON_FUNC_4()':
test_xreducer.cpp:(.text+0x70c): relocation truncated to fit: R_MIPS_CALL16 
against `raise@@GLIBC_2.0'
test_xreducer.cpp:(.text+0x7a4): relocation truncated to fit: R_MIPS_CALL16 
against `__cxa_begin_catch@@CXXABI_1.3'
test_xreducer.cpp:(.text+0x7d4): additional relocation overflows omitted from 
the output
collect2: error: ld returned 1 exit status
make[3]: *** [test/CMakeFiles/test_xreducer.dir/build.make:116: 
test/test_xreducer] Error 1


"relocation truncated" together with the virtual memory exhaustion
seen without -O0 suggests the test program is simply too large to link.

But the problem persists even if XTENSOR_TESTS in tests/CMakeLists.txt
is reduced to one file.

Bug#994442: [REOPEN] python3-pyo: Silently crash with 4/167 dead streams

[Eriberto Mota]

Control: reopen 994442 !

Reopening. Sorry, my changelog for blhc closed a wrong bug.

Regards,

Eriberto

Bug#924139: OVAL generation code migrated to python3

[Sébastien Delafond]

See https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/737.

Bug#930603: libdockapp-dev: pkg-config file Requires xext without dependency on libxext-dev

[Andreas Metzler]

On 2021-10-09 Jeremy Sowden  wrote:
> On 2019-08-13, at 19:09:33 +0200, Andreas Metzler wrote:
>> On 2019-06-16 Douglas Torrance wrote:
>>> On Sun, Jun 16, 2019 at 7:30 AM Andreas Metzler wrote:
 /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc:
 Requires: x11 xext xpm

 Therefore anything build-depending on libdockapp-dev and using
 pkg-config to locate the library will FTBFS unless it has a direct
 b-d on libxext-dev.
[...]
>> the respective patch moves "Requires: x11 xext xpm" to
>> Requires.private.  That does not really fix the bug. pkg-config
>> --cflags requires that not only Requires but also Requires.private are
>> is resolvable (even when --static is not present) i.e. xext.pc would
>> still need to be present.

>> I think this would be the correct fix:
>> - @echo 'Requires.private: x11 xext xpm' >> $@
>> + @echo 'Requires.private: x11 xpm' >> $@
>> + @echo 'Libs.private: -lext' >> $@

> Doesn't that mean that we lose information?  What if libxext is
> installed in a non-standard location, and we need the -L${libdir} to
> find it?

> I think the right thing to do is to add a b-d on libxext-dev to
> libdockapp-dev.

Hello Jeremy,

 Adding libxext-dev to libdockapp-dev's Depends would work perfectly
fine for me.

---
I think it is a little bit of grey area, not and black and white. Having
xext in Requires.private broke pkgconfig and introduced this bug. Some
third-party packages needed to work around this and we could inflate
libdockapp-dev's dependencies to fix it. There is no real gain for e.g.
Debian packages in having xext in Requires.private.

OTOH for non-dist packages you raise a valid point. However the breakage
seems to be constrained to a corner case:
 + xext is installed in non-standard location and this non-standard
   location is a different one than either x11 or xpm
 + static linking is wanted. (Or we are on an exotic arch which requires
   explicit linking against all indirect deps).

When I submitted the report I probably had my mindset in a Debian context
not an upstream one and suggested the optimal-for-Debian solution. But
it is probably an error to micro-optimize and invest that much thought
into it.

cu Andreas

Bug#604839: Bug#988472: Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 09 Oct 2021 at 11:21:54 +0200, Holger Wansing wrote:

> Hi,

Hello Holger,

Thank you for your consideration

> Brian Potkin  wrote (Sun, 3 Oct 2021 14:45:29 +0100):
> >  > You should be able to see to which device the USB stick was mapped
> >  > by running the command dmesg after inserting it.
> > 
> > I would add lsblk, with a link to its manual page.
> > 
> >  You should be able to see to which device the USB stick was mapped
> >  by running the command lsblk before and after inserting it. The
> >  output of dmesg (as root) is another discovery method.
> 
> Ok, applied (similar).

Looks good.
 
> > --
> > 
> >  > If you use the wrong device the result could be that all information
> >  > on for example a hard disk could be lost.
> > 
> > Surely it would be quite surprising if all information was not lost?
> > Why not continue the dire warning, particularly as the process is done
> > as root? "would" instead of "could"?
> 
> I would simplify that to 
> "If you use the wrong device the result could be that all
> information on for example a hard disk is lost."

Sorry, it appears I wasn't very clear. What I wrote was not intended as
replacemet text but a short commentary on whether there is a possibility
or a certainty of data being lost. Changing one word in your text and
putting in a couple of commas:

  "If you use the wrong device the result will be that all
   information on, for example, a hard disk is lost."

> > -
> > 
> >  > Debian installation images for this architecture are created using
> >  > the “isohybrid”...
> > 
> > I do not understand why "isohybrid" needs to be enclosed in double
> > quotes. Two links:
> 
> Ok, I replaced the quotes by a bold font.

Better.
 
> >   https://joeyh.name/blog/entry/Debian_USB_install_from_hybrid_iso/
> >   https://blog.einval.com/2011/01/07
> > 
> > I have forgotten whether the Guide policy allows referencing pages
> > outside the Debian infrastructure.
> > 
> > ---
> > 
> >  > If you have chosen the mini.iso to be written the USB stick, the
> >  > second partition doesn't have to be created, as - very nice - ...
> > 
> > The original ("very nicely") is OK and better English (IMO).
> 
> Ok, applied.

Thanks.


> Brian Potkin  wrote (Sun, 3 Oct 2021 15:51:28 +0100):
> > On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> > 
> > [...]
> > 
> > > I had some understanding issues, mostly in chapter
> > > "Manually copying files to the USB stick — the flexible way"
> > 
> > I have never really understood what is so special about syslinux and
> > mbr.bin in the context of using hd-media. GRUB should always be at
> > hand on a Linux machine. This is my flexible way:
> > 
> > 1. dd if=/dev/zero of=/dev/sdb count=100
> >(Could be omitted).
> > 
> > 2. cfdisk /dev/sdb (FAT).
> > 
> > 3. mkfs.vfat /dev/sdb1
> >dosfslabel /dev/sdb1 LABEL.
> >(Download dosfstools).
> > 
> > 4. mount /dev/sdb1 /mnt
> >grub-install --boot-directory=/mnt/boot /dev/sdb
> > 
> > 5. cp vmlinuz /mnt/boot
> >cp initrd.gz /mnt/boot
> > 
> > 6. cp  /mnt
> > 
> > 7. # An example grub.cfg.
> >menuentry 'Debian 11.0.0' {
> >linux /boot/vmlinuz shared/ask_device=manual \
> >shared/enter_device=/dev/disk/by-label/LABEL
> >initrd /boot/initrd.gz
> >}
> > 
> > 8. cp grub.cfg /mnt/boot/grub
> > 
> > 9. Boot.
> > 
> > More detail at https://wiki.debian.org/Installation+Archive+USBStick.
> > To declare an interest - I wrote that page.
> 
> I personally have no strict preference on syslinux.
> However, the proposed alternative does not look much easier to me ...
> (leaving only the pro, that syslinux does not need to be installed)
> 
> 
> Other opinions?
> 
> 
> 
> 
> Brian Potkin  wrote (Sun, 3 Oct 2021 19:40:00 +0100):
> > On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> > 
> > [...]
> > 
> > > - Because a long time has passed by since the last overhaul of this 
> > > chapter,
> > >   maybe there is some more, that could be changed, for example because of
> > >   changed/new technology or experience?
> > 
> > Regarding 4.3.2. at
> > 
> >   
> > https://people.debian.org/~holgerw/installation-guide_2021-10-02/amd64/ch04s03.html
> > 
> > 
> >  > An alternative way to set up your USB stick is to manually copy
> >  > the installer files,...
> > 
> > This section has been about since the dawn of time :). It predates the
> > advent of isohybrid technology and could be said to have served its
> > purpose and be retired. An alternative would be to leave it there and
> > introduce it as follows:
> > 
> >  Prior to isohybrid technology being used for all Debian ISOs, this way
> >  was the method used to boot from a USB device. It has been superseded
> >  by the technique in Section 4.3.1 [LINK] but has been left here for
> 

Bug#995994: firmware-atheros: Only testing version of firmware-atheros works with bullseye 11.1 for QCA9377

[Romain]

Package: firmware-atheros
Version: 20210818-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
=> update from Debian 11 to Debian 11.1
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
=> on reboot, my Atheros QCA9377 was not recognized
   
   *Upgrading firmware-atheros from stable (20210315-3) to testing (20210818-1) 
fixed the problem (staying on stable for the rest) 

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


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

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

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools  0.140

-- no debconf information

Bug#992555: 5.10.0-9 still affected

[Hendrik Buchner]

I've done the upgrade from 11.0 to 11.1. The new kernel 5.10.0-9 is
still affected and the oldstable 4.19 still does the job.

Bug#995991: lintian: match for static-library-has-unneeded-sections may not be sufficiently precise

[Roberto C. Sanchez]

Package: lintian
Version: 2.108.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In using lintian 2.108.0 to check a build of the mongo-c-driver package
prior to uploading version 1.19.1-1, I encountered many occurrences of
the static-library-has-unneeded-sections warning.  This warning did not
occur with previous versions of lintian nor on previous versions of
mongo-c-driver.

Based on a brief investigation of the diff between 2.107.0 and 2.108.0,
I suspect that in lib/Lintian/Check/Libraries/Static.pm, these lines may
be the cause:

my @EXTRA_SECTIONS = qw{.note .comment};
my @not_needed
  = grep { exists $member_objdump->{SH}{$_} } @EXTRA_SECTIONS;

In the libbson-dev and libmongoc-dev binary packages, there are static
libraries that contain the section '.note.GNU-stack'.  Could it be
possible that this check is matching '.note.GNU-stack' and mistaking it
for a '.note' section?

Regards,

- -Roberto

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAmFhw9QACgkQLNd4Xt2n
sg+XtxAAoMqbpij5XP1BT3XvMR1rfJA6I/djTpDhOaSqemSBr6CO2+/QnoyjbAl6
gDd2f24E4srYxI9WxXOg4jKcWnLH5BRktjnN4+zgueXVbw71/zatMKurZGHjw/vB
Ql7iDXI2lRC22LA0yZtrUwzXM+L7Cfmo/KUxQW8Zv+eURo64TAoCs7RWhouAr4z/
HjHT2weuiYMzqGNW67UUedew7c1qjJX2uZSc9iYBJQSrpgw8CRCsKIvXd9hxW8nP
zXBWptF0VTl/2yuRqerszRStpbRbezRS76zpYsGteh2uHy4TjTyUqiafnuV7yQag
1+x0rzNTVGwnPRq/OIhbCQOySxZOODniCbcO2ghF2d7SjZ/hp+Ftiz2fLrVRApoV
6qjO+Z/dJ6iEiPqjjgk+DpK94d2E89bzhEXmh6YTt/5OgfUEutHnFB26zGECoKE8
mI5mXVcmYHGgzAaZi5ABUW1FvZYdkW+h3rMt9tc39gMmhyOHujvo0uQQgiLApiW9
PH3e7pKEkscIxmZYkvs1cA/R1VldFdYaVIZrZajKUkn4sDHxDbx5A0MCGnJc8sbb
A7vS+4x7UmWYoilCOz7QLvioSD0L4u+i4F4W6WwvepMPT9y2n+i9oCKOYShpw2JM
OpRLge6pqQ/uIQSg3ffC0BMOSFDqDxBmjNX7CHizVNZo9VVRhoo=
=FQQL
-END PGP SIGNATURE-

Bug#995368: libapache2-mod-proxy-uwsgi - CVE-2021-36160 regression, altered PATH_INFO

[Sylvain Beucler]

Hi,

On 05/10/2021 18:41, Sylvain Beucler wrote:

forwarded 995368 https://bz.apache.org/bugzilla/show_bug.cgi?id=65616


The Apache developers say there's an incorrect configuration in the 
first place.  For example,

ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081/
should be
ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081
following the warning about slashes in the documentation:
http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass

However, they are currently considering an additional patch to restore 
the previous (less strict) behavior.


Philippe, Josef, I prepared a build with the new patch, so you can test 
early:

https://people.debian.org/~beuc/lts/uwsgi/
https://people.debian.org/~beuc/lts/uwsgi/libapache2-mod-proxy-uwsgi_2.0.14+20161117-3+deb9u5_amd64.deb

I'm interested in your feedback.

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#938964: please don't install runit-helper on everyone's system

[Lorenzo]

Hi Noah,

On Wed, 4 Sep 2019 07:10:24 -0700 Noah Meyerhans 
wrote:

> I think unifying the functionality of this package with
> init-system-helpers would be preferable. But beyond just polluting the
> package namespace, I'm a bit annoyed by the stuff that this package
> leaves around the filesystem as well. In particular, /var/log/runit
> shouldn't exist on systems that don't even have runit installed.
> /etc/runit is similarly annoying.
> 
> I think it'd be worthwhile to come up with a slightly more
> sophisticated mechanism for populating runit configuration on systems
> that actually need such configuration, while also eliminating noise
> on systems that don't need it. I'm happy to create a separate bug for
> the filesystem issues if you'd like to track them separately from the
> package name issues.
> 
> noah

I'm looking for a way to fix all this kind of problems once for all.
Please look at #942053 and #935939: if you have additional complains
open a separate bug against dh-runit package and list all the filesystem issues 
there.

Regards,
Lorenzo

Bug#995936: dh-elpa doesn't work on package versions with buildN or ubuntuN suffixes

[David Bremner]

Matthias Klose  writes:
>
> dh-elpa doesn't work on package versions with buildN or ubuntuN suffixes, 
> errors
> out with:
>
> Invalid version syntax: ‘0.49build1’
>
>
> patch at
> http://launchpadlibrarian.net/562638722/dh-elpa_2.0.8_2.0.8ubuntu1.diff.gz
>
> however the patch doesn't work yet, packages still ftbfs like
> https://launchpadlibrarian.net/562650646/buildlog_ubuntu-impish-amd64.lbdb_0.49build1_BUILDING.txt.gz
>
> any idea what's still missing?

OK, ftbfs is fixed, and I looked at it a bit more.

I think lbdb might just be a special case. It's a native package and
creates lbdb-pkg.el from debian/changelog via configure.  dh_elpa
assumes that if upstream provides a foo-pkg.el then it has legal
metadata in it; in this case that isn't the case.  I guess you could
patch configure.ac.

I don't know how much work would to defend against this kind of "wrong
input" in dh_elpa. The actual failure is in package-load-descriptor, a
standard emacs function, so some kind of preprocessing pass would be
needed. I don't know how many packages are affected by issue, it seems
to require native package.

cheers,

d

Bug#950972: press: Broken/mangled space characters in 10.3 and 9.12 point release announcements

[Guillem Jover]

Control: tags -1 patch

Hi!

On Sat, 2020-02-08 at 23:32:56 +0100, Salvatore Bonaccorso wrote:
> Just checked quickly, in the script there is a U+00A0 (0xc2 0xa0) which seem 
> to
> cause the issue. If I replace the space with "normal" space U+0020, then the
> issue disapear. The issue at least is triggerable as well with older issues 
> not
> only the recent 2020 ones.

As has been mentioned in the bug report, there are other UTF-8
literals in the script, so replacing that one character does not fix
the issue.

> I do not know if this is the right solution, but attached patch with the 
> above.

See above.

I think the attached patch is the correct fix. I think I can push to
the repo, so if no one has any concerns I might do that during the
weekend.

Thanks,
Guillem
From 1dcd625cd3282e66782cbe13e3fada43dd59e139 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 9 Oct 2021 16:38:39 +0200
Subject: [PATCH] DPNhtml2mail: Set stdout encoding to UTF-8

We are printing UTF-8 characters, and should make the output match,
otherwise we get local encodings.
---
 dpn/scripts/DPNhtml2mail.pl | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dpn/scripts/DPNhtml2mail.pl b/dpn/scripts/DPNhtml2mail.pl
index 8188dc5b..d4682d73 100755
--- a/dpn/scripts/DPNhtml2mail.pl
+++ b/dpn/scripts/DPNhtml2mail.pl
@@ -148,6 +148,8 @@ my $default_dpn_url  = 'https://www.debian.org/News/weekly/';
 my $default_news_mail = 'pr...@debian.org';
 my $default_news_url  = 'https://www.debian.org/News/';
 
+binmode STDOUT, ':utf8';
+
 # Option parsing
 GetOptions(\%opts, 'u|url=s', 'i|issue=s', 'l|lang=s', 'd|debug', 't|type=s', 'm|mail=s', 'wrap-list', 'do-not-wrap=s');
 
-- 
2.33.0

Bug#942053: dh-runit: generates dangling symlinks

[Lorenzo]

Hi,

Just a quick update on this bug

On Wed, 09 Oct 2019 18:01:56 +0200 Sven Joachim  wrote:
> Package: dh-runit
> Version: 2.8.14
> 
> The fix for bug #934500 has the side effect of introducing broken
> symlinks[1] into packages using it, causing complaints by tools that
> report such oddities, e.g. adequate(1) or symlinks(1):
> 
> ,
> | $ sudo symlinks -r /etc | grep dangling
> | dangling: /etc/sv/ssh/log/supervise -> /run/runit/supervise/ssh.log
> | dangling: /etc/sv/ssh/supervise -> /run/runit/supervise/ssh
> | $ adequate openssh-server
> | openssh-server: broken-symlink /etc/sv/ssh/log/supervise ->
> /run/runit/supervise/ssh.log | openssh-server: broken-symlink
> /etc/sv/ssh/supervise -> /run/runit/supervise/ssh `
> 
> I find that quite annoying.
> 

With the fix for #935939 I'm also considering to create the supervise
symlinks only in systems where runit is installed.

> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.3.5-nouveau (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to
> /bin/dash Init: systemd (via /run/systemd/system)
> 
> 
> 1. For people who actually use runit as init system the symlinks are
>probably not broken, but that is currently a small minority.

With runit-init the symlinks are not broken; also when you are using
runit under another init system (like with runit-run package) the
symlinks may be not broken.

Regards,
Lorenzo

Bug#930603: libdockapp-dev: pkg-config file Requires xext without dependency on libxext-dev

[Jeremy Sowden]

On 2019-08-13, at 19:09:33 +0200, Andreas Metzler wrote:
> On 2019-06-16 Douglas Torrance wrote:
> > On Sun, Jun 16, 2019 at 7:30 AM Andreas Metzler wrote:
> >> /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc:
> >> Requires: x11 xext xpm
>
> >> Therefore anything build-depending on libdockapp-dev and using
> >> pkg-config to locate the library will FTBFS unless it has a direct
> >> b-d on libxext-dev.
>
> >> I think the error is in the pkg-config file, not in the Debian
> >> package.  Since the headers of libdockapp-dev do not #include (and
> >> therefore expose) headers from libxext-dev the pkg-config should
> >> have (at most)
> >> Libs.private: -lext
> >> instead of the requires.
>
> > This was fixed in git upstream a while ago [1], but there hasn't
> > been a new release yet.  I'll work on that soon.
>
> the respective patch moves "Requires: x11 xext xpm" to
> Requires.private.  That does not really fix the bug. pkg-config
> --cflags requires that not only Requires but also Requires.private are
> is resolvable (even when --static is not present) i.e. xext.pc would
> still need to be present.
>
> I think this would be the correct fix:
> - @echo 'Requires.private: x11 xext xpm' >> $@
> + @echo 'Requires.private: x11 xpm' >> $@
> + @echo 'Libs.private: -lext' >> $@

Doesn't that mean that we lose information?  What if libxext is
installed in a non-standard location, and we need the -L${libdir} to
find it?

I think the right thing to do is to add a b-d on libxext-dev to
libdockapp-dev.

J.


signature.asc
Description: PGP signature

Bug#994724: RFS: lebiniou-data/3.62.1-1 -- datafiles for Le Biniou

[Olivier Girondel]

Hi Adam,

Any news on this ?

Best regards,

--
Olivier Girondel

Bug#995990: systemctl --now flag has no effect in two circumstances

[MichaIng]

Package: systemd
Version: 232-25+deb9u13

On current Debian Stretch, the systemctl --now flag, when enabling or 
disabling a service, has no effect in those two cases:


1. The service is already enabled respectively disabled: On newer 
systemd versions (Buster and Bullseye), the service is still started 
respectively stopped, even if the enabled/disabled state does not change.


2. An init.d service exists: In this case the --now flag has no effect, 
regardless whether the service is currently enabled or disabled. On 
newer systemd versions the presence of an init.d service has no effect 
on that flag.


Tested on a current Debian Stretch x86_64/amd64 system.

Best regards,

Micha

Bug#935939: Does not respect local admin changes and recreates files in /etc/sv

[Lorenzo]

Control: tags -1 moreinfo

On Wed, 28 Aug 2019 09:42:31 +0200 Michael Biebl 
wrote:
> Package: openssh-server
> Version: 1:8.0p1-5
> Severity: important
> 
> Since I have no use for runit, I removed the /etc/sv directory.
> Unfortunately, if the openssh-server package is upgraded (or
> reinstalled), the local admin choice is not respected and the files in
> /etc/sv are recreated.


Hi Michael,

I'm considering an option to ship runit services somewhere else
in the filesystem, likely under /usr/share/runit/sv/, and then copy the
whole service directory into /etc/ during install or upgrade of the
package, but only in systems where runit is installed.

Would you be satisfied with such solution?


Regards,
Lorenzo

Bug#630880: this bug is fixed in salsa

[R Lewis]

For anyone watching this bug, i believe it is closed by the enhanced diff
mode (merged in salsa (thanks Marcos!), and pending an upload):

Once the version in salsa is uploaded if If you add

DIFF_MODE="true"

to /etc/chkrootkit.conf then the cron job will filter the output to give
you stable output when common network managing tools are employed (there
are instructions in the output as to how to then mark the output as
'expected', and then you will get no output. )

(I still think there is more that could be done to make filtering easier,
but i think the version on salsa fixed the immediate issues raised here)

Bug#995975: apt-cacher-ng: Listens on 0.0.0.0 despite "BindAddress" being set

[Eduard Bloch]

Control: severity 995975 important
Control: 995975 notreproducible

> I set "BindAddress: localhost" in /etc/apt-cacher-ng/acng.conf

I smell a source of confusion here. Please read that file from the start.

# IMPORTANT NOTE:
#
# THIS FILE IS MAYBE JUST ONE OF MANY CONFIGURATION FILES IN THIS DIRECTORY.
# SETTINGS MADE IN OTHER FILES CAN OVERRIDE VALUES THAT YOU CHANGE HERE. GO
# LOOK FOR OTHER CONFIGURATION FILES! CHECK THE MANUAL AND INSTALLATION NOTES
# (like README.Debian) FOR MORE DETAILS!

So, please do a "grep -i bindaddr /etc/apt-cacher-ng/*.conf" and report
what's there.

> -- Configuration Files:
> /etc/apt-cacher-ng/acng.conf changed [not included]
> /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
> '/etc/apt-cacher-ng/security.conf'
>
> -- debconf information:
> * apt-cacher-ng/tunnelenable: false
>   apt-cacher-ng/cachedir: keep
>   apt-cacher-ng/proxy: keep
> * apt-cacher-ng/gentargetmode: Set up now and update later

Maybe there is some debconf issue, since this value would keep updating
/etc/apt-cacher-ng/zz_debconf.conf on every update. OTOH, this:

>   apt-cacher-ng/bindaddress: keep

... should also disable the assignment of BindAddress directory.

Please post zz_debconf.conf of whatever was identified by grep.

> when i restart the service it is indeed listening on 127.0.0.1:3142 (for tcp)
> But when apt-cacher starts doing something (I use it via sbuild) it also 
> starts
> listening on 0.0.0.0 + a random port for udp. I would expect 127.0.0.1:41044 
> only in:

That does not make sense. First, apt-cacher is not apt-cacher-ng (its a
different package). Second: no listening ports are bound after the
startup in apt-cacher-ng.

> ss -tunlp|grep apt
> udp   UNCONN 0  0 0.0.0.0:41044  0.0.0.0:*
> users:(("apt-cacher-ng",pid=2584993,fd=11))
> tcp   LISTEN 0  250 127.0.0.1:3142   0.0.0.0:*
> users:(("apt-cacher-ng",pid=2584993,fd=10))

I cannot see 0.0.0.0:3142 here, and especially not in TCP context. What do you 
mean?
The UDP socket is probably the DNS resolver.

> isnt this a security risk? (It gets flagged by the tiger package as such - 
> now I do know that
> in fact it may be a low risk and that it is easily mitigated via firewall 
> rules, but i dont want
> apt-cacher-ng listening on any external ip, especially when the config 
> explicitly tells it not to.)
> this did not happen in the 'buster' version, so is a regression in the new 
> stable release
>
> I also wonder why the default setting is so permissive - surely the biggest 
> use-case is for building on

What exactly is the security risk? The default setting? Well, you
install a network daemon, wouldn't a normal user expect it to listen on
the network??

> a localhost via sbuild or similar, and people who want to provide a cache to 
> other machines would be able
> to change the default. (but any default is fine as long as it can be changed 
> - but the above shows the
> change isnt working)

But they can change the default on installation or via debconf.

dpkg-reconfigure -plow apt-cacher-ng

> Thanks for considering to fix this

Not sure what to fix yet.

Best regards,
Eduard.

Bug#995567: Can't handle cross-signed Let's Encrypt CA

[Miao Wang]

control: tag -1 + patch

A fix has been merged by upstream.

https://github.com/lavv17/lftp/commit/285c61c

Bug#994153: This bug is pending

[R Lewis]

Thanks to Marcos a fix is merged in salsa

Bug#995952: undertime: Getting TypeError with any timezone

[Antoine Beaupré]

Control: severity -1 normal

On 2021-10-08 15:24:56, Gabriel Filion wrote:
> Package: undertime
> Version: 2.6.0
> Severity: grave
> Justification: renders package unusable
>
> Hello,
>
> I'm currently getting stack traces consistently when using undertime. No 
> matter
> the timezone that I request, I get a stack trace with a TypeError exception:
>
> $ undertime pt
> Traceback (most recent call last):
>   File "/usr/bin/undertime", line 994, in 
> main(args)
>   File "/usr/bin/undertime", line 733, in main
> timezones += filter(None, [guess_zone(z) for z in args.timezones])
> TypeError: 'NoneType' object is not iterable
>
> $ undertime PST
> WARNING: date provided cannot be parsed: PST
> Traceback (most recent call last):
>   File "/usr/bin/undertime", line 994, in 
> main(args)
>   File "/usr/bin/undertime", line 733, in main
> timezones += filter(None, [guess_zone(z) for z in args.timezones])
> TypeError: 'NoneType' object is not iterable
>
> If I run that last command with pdb,
>
> e.g. python3 -m pdb /usb/bin/undertime PST
>
> and then (r)un the program until the error, I can see that args.timezones is
> set to None:
>
> (Pdb) type(args.timezones)
> 
>
>
> now from there, I tried using "undertime -t PST" and that actually worked. So
> there must be something off with the default value to -t

I should have documented this possibly more clearly in the NEWS.Debian
file, or maybe make a 3.x release, but I changed the semantics of the
commandline arguments quite significantly. The arguments are now a time,
and you need to provide a -t (or add it to your config file) for
undertime to work.

I'll take this bug report as a request to improve the error message
and/or data structure. Really, args.timezones should be an empty list
instead of None here, I think.

A.

-- 
L'homme construit des maisons parce qu'il est vivant, mais il écrit des
livres parce qu'il se sait mortel.
- Daniel Pennac, Comme un roman

Bug#604839: Bug#988472: Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Holger Wansing]

Hi,

Brian Potkin  wrote (Sun, 3 Oct 2021 14:45:29 +0100):
>  > You should be able to see to which device the USB stick was mapped
>  > by running the command dmesg after inserting it.
> 
> I would add lsblk, with a link to its manual page.
> 
>  You should be able to see to which device the USB stick was mapped
>  by running the command lsblk before and after inserting it. The
>  output of dmesg (as root) is another discovery method.

Ok, applied (similar).

> --
> 
>  > If you use the wrong device the result could be that all information
>  > on for example a hard disk could be lost.
> 
> Surely it would be quite surprising if all information was not lost?
> Why not continue the dire warning, particularly as the process is done
> as root? "would" instead of "could"?

I would simplify that to 
"If you use the wrong device the result could be that all
information on for example a hard disk is lost."

> 
> -
> 
>  > Debian installation images for this architecture are created using
>  > the “isohybrid”...
> 
> I do not understand why "isohybrid" needs to be enclosed in double
> quotes. Two links:

Ok, I replaced the quotes by a bold font.

>   https://joeyh.name/blog/entry/Debian_USB_install_from_hybrid_iso/
>   https://blog.einval.com/2011/01/07
> 
> I have forgotten whether the Guide policy allows referencing pages
> outside the Debian infrastructure.
> 
> ---
> 
>  > If you have chosen the mini.iso to be written the USB stick, the
>  > second partition doesn't have to be created, as - very nice - ...
> 
> The original ("very nicely") is OK and better English (IMO).

Ok, applied.




Brian Potkin  wrote (Sun, 3 Oct 2021 15:51:28 +0100):
> On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> 
> [...]
> 
> > I had some understanding issues, mostly in chapter
> > "Manually copying files to the USB stick — the flexible way"
> 
> I have never really understood what is so special about syslinux and
> mbr.bin in the context of using hd-media. GRUB should always be at
> hand on a Linux machine. This is my flexible way:
> 
> 1. dd if=/dev/zero of=/dev/sdb count=100
>(Could be omitted).
> 
> 2. cfdisk /dev/sdb (FAT).
> 
> 3. mkfs.vfat /dev/sdb1
>dosfslabel /dev/sdb1 LABEL.
>(Download dosfstools).
> 
> 4. mount /dev/sdb1 /mnt
>grub-install --boot-directory=/mnt/boot /dev/sdb
> 
> 5. cp vmlinuz /mnt/boot
>cp initrd.gz /mnt/boot
> 
> 6. cp  /mnt
> 
> 7. # An example grub.cfg.
>menuentry 'Debian 11.0.0' {
>linux /boot/vmlinuz shared/ask_device=manual \
>shared/enter_device=/dev/disk/by-label/LABEL
>initrd /boot/initrd.gz
>}
> 
> 8. cp grub.cfg /mnt/boot/grub
> 
> 9. Boot.
> 
> More detail at https://wiki.debian.org/Installation+Archive+USBStick.
> To declare an interest - I wrote that page.

I personally have no strict preference on syslinux.
However, the proposed alternative does not look much easier to me ...
(leaving only the pro, that syslinux does not need to be installed)


Other opinions?




Brian Potkin  wrote (Sun, 3 Oct 2021 19:40:00 +0100):
> On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> 
> [...]
> 
> > - Because a long time has passed by since the last overhaul of this chapter,
> >   maybe there is some more, that could be changed, for example because of
> >   changed/new technology or experience?
> 
> Regarding 4.3.2. at
> 
>   
> https://people.debian.org/~holgerw/installation-guide_2021-10-02/amd64/ch04s03.html
> 
> 
>  > An alternative way to set up your USB stick is to manually copy
>  > the installer files,...
> 
> This section has been about since the dawn of time :). It predates the
> advent of isohybrid technology and could be said to have served its
> purpose and be retired. An alternative would be to leave it there and
> introduce it as follows:
> 
>  Prior to isohybrid technology being used for all Debian ISOs, this way
>  was the method used to boot from a USB device. It has been superseded
>  by the technique in Section 4.3.1 [LINK] but has been left here for
>  educational and  historical purposes and in case it proves of use to a
>  user.

Basically I could follow that proposal, I have trimmed it a bit to:

"Prior to isohybrid technology being used for &debian; installation images, the
methods documented in the chapters below were used to prepare media for
booting from USB devices.
This has been superseded by the technique in ,
but has been left here for educational and historical purposes and in case it
proves of use to a user."

However, I am quite uncomfortable with the last sentence
"... and in case it proves of use to a user."

Could we use some sort of easier English for this (better understanding)? 
Proposal?


> 
> 
> 
>  > 

Bug#995425: Possible to get fix to 5.10?

[Salvatore Bonaccorso]

Hi,

On Fri, Oct 08, 2021 at 07:31:46PM -0500, ng wrote:
> Hello,  I was just wondering if in the near future this fix will be
> available for linux in the stable branch.

Yes it will (in fact it is in 5.10.71) and so will be included for
Debian itself once the bullseye kernel will be rebased (usually at
point release times, which just happened, but updating to 5.10.70).

Regards,
Salvatore

Bug#995987: python3.10: Please build with -DWITH_PYMALLOC_RADIX_TREE=0 on ia64

[John Paul Adrian Glaubitz]

Source: python3.10
Severity: normal
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi!

Python 3.10 introduced a new memory allocator which is not compatible with
64-bit systems with large virtual address spaces at the moment because it
assumes address spaces to be limited to 48 bits [1].

This causes the Python interpretor to segfault on ia64. This problem can
be avoided by building with -DWITH_PYMALLOC_RADIX_TREE=0. For me, the following
change to debian/rules was sufficient:

--- debian/rules.orig   2021-10-08 12:10:19.0 +
+++ debian/rules2021-10-09 12:04:40.362349542 +
@@ -179,6 +179,7 @@
 # on ia64, disable -O3 until gcc bug #85412 is fixed
 ifeq ($(DEB_HOST_ARCH),ia64)
 EXTRA_OPT_CFLAGS += -O2
+DPKG_CPPFLAGS += -DWITH_PYMALLOC_RADIX_TREE=0
 endif
 # see #972202, and https://gcc.gnu.org/PR97431
 ifneq (,$(filter $(DEB_HOST_ARCH), hppa sh4))

FWIW, I think we can even drop the "EXTRA_OPT_CFLAGS += -O2" again as I could
build cpython from git without overriding the optimization level on the ia64
porterbox.

Thanks,
Adrian

> [1] https://github.com/python/cpython/pull/14474

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2021-10-08 12:10:19.0 +
+++ debian/rules2021-10-09 12:04:40.362349542 +
@@ -179,6 +179,7 @@
 # on ia64, disable -O3 until gcc bug #85412 is fixed
 ifeq ($(DEB_HOST_ARCH),ia64)
 EXTRA_OPT_CFLAGS += -O2
+DPKG_CPPFLAGS += -DWITH_PYMALLOC_RADIX_TREE=0
 endif
 # see #972202, and https://gcc.gnu.org/PR97431
 ifneq (,$(filter $(DEB_HOST_ARCH), hppa sh4))

Bug#995989: ITP: libbraille-input -- Braille input engine for IBus-Braille and Sharada-Braille-Writer.

[Samuel Thibault]

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

* Package name: libbraille-input
  Version : 0.7.3
  Upstream Author : Nalin 
* URL : https://github.com/zendalona/libbraille-input
* License : GPL
  Programming Lang: Python
  Description : Braille input engine for IBus-Braille and 
Sharada-Braille-Writer.

 This engine can convert braille input events to text and call asociated
 callback functions. Here braille input means inputing text in Perkins-like
 way, i.e. braille patterns.

 It supports several braille tables, contracted braille and abbreviations.

Bug#995988: ITP: sbw -- Simple text editor with braille input

[Samuel Thibault]

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

* Package name: sbw
  Version : 3.6
  Upstream Author : Nalin 
* URL : 
https://github.com/zendalona/sbwhttps://github.com/zendalona/sbw
* License : GPL
  Programming Lang: Python
  Description : Simple text editor with braille input

Sharada-Braille-Writer allows one to use the PC keyboard to type text in
graphical desktops in a Perkins-like way, i.e. braille patterns.

It supports several braille tables, contracted braille and abbreviations.

Bug#995969: release.debian.org: bullseye update requested for refpolicy

[Russell Coker]

Package: release.debian.org
Severity: normal

[Reason]

Improvement to refpolicy for ppp, wireshark, acngtool, root login on boot
failure, and systemd-timesyncd.

[Impact]

Allows pppox (for common NBN devices in Australia to work.

Allows Wireshark to do the X stuff it wants to do (not functional otherwise).
Also allow it to get network state.

Allows acngtool to manage it's log files.

Allows kmod, ifconfig, and ping to be run by the sysadmin after the regular
boot process has failed.

Allows systemd-timesyncd to restart generic units.

[ Tests ]
Tested all of this manually.

[ Risks ]
No real risk, just added new allow rules.

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

diff -Nru refpolicy-2.20210203/debian/changelog 
refpolicy-2.20210203/debian/changelog
--- refpolicy-2.20210203/debian/changelog   2021-06-14 09:47:05.0 
+1000
+++ refpolicy-2.20210203/debian/changelog   2021-10-04 15:06:54.0 
+1100
@@ -1,3 +1,22 @@
+refpolicy (2:2.20210203-8) unstable; urgency=medium
+
+  * Label /etc/ppp/ip-pre-up as pppd_initrc_exec_t
+  * Allow wireshark to rw DRI devices, read crypto sysctls, rw the xserver
+mesa shader cache, read the kernel network state, have execmem access
+(probably needed for one of the many shared objects it uses), have setsched
+access, execute lib files (for it's helper programs), manage xdg config
+files (gives warning if it can't do this), manage xdg cache, and read xdg
+data files.
+  * Allow acngtool_t the dac_override capability for managing log files
+  * Allow pppd to connect create and ioctl pppox_socket and allow it to map
+pppd_runtime_t files.
+  * Allow kmod_t, ifconfig_t, and ping_t to use unallocated ttys (for sysadmin
+login on boot failure)
+  * Allow ntpd_t to start and stop generic units when systemd is used, for
+systemd-timesyncd.
+
+ -- Russell Coker   Mon, 04 Oct 2021 15:06:54 +1100
+
 refpolicy (2:2.20210203-7) unstable; urgency=medium
 
   * Allow certbot to create /var/log/letsencrypt and /var/lib/letsencrypt
diff -Nru refpolicy-2.20210203/debian/patches/0027-services 
refpolicy-2.20210203/debian/patches/0027-services
--- refpolicy-2.20210203/debian/patches/0027-services   2021-06-14 
09:47:05.0 +1000
+++ refpolicy-2.20210203/debian/patches/0027-services   2021-08-13 
03:54:44.0 +1000
@@ -128,7 +128,14 @@
  
  # Uses sd_notify() to inform systemd it has properly started
  init_dgram_send(aptcacher_t)
-@@ -99,8 +105,12 @@ allow acngtool_t self:unix_stream_socket
+@@ -93,14 +99,19 @@ sysnet_mmap_config_files(aptcacher_t)
+ # acngtool local policy
+ #
+ 
++allow acngtool_t self:capability dac_override;
+ allow acngtool_t self:tcp_socket create_stream_socket_perms;
+ allow acngtool_t self:unix_stream_socket create_socket_perms;
+ 
  allow acngtool_t aptcacher_conf_t:dir list_dir_perms;
  allow acngtool_t aptcacher_conf_t:file mmap_read_file_perms;
  
@@ -1874,3 +1881,60 @@
  ##Create block devices in on a tmpfs filesystem with the
  ##fixed disk type via an automatic type transition.
  ## 
+Index: refpolicy-2.20210203/policy/modules/services/ppp.fc
+===
+--- refpolicy-2.20210203.orig/policy/modules/services/ppp.fc
 refpolicy-2.20210203/policy/modules/services/ppp.fc
+@@ -8,6 +8,7 @@ HOME_DIR/\.ppprc   --  gen_context(system_u
+ /etc/ppp/.*secrets--  gen_context(system_u:object_r:pppd_secret_t,s0)
+ /etc/ppp/resolv\.conf --  gen_context(system_u:object_r:pppd_etc_rw_t,s0)
+ /etc/ppp/(auth|ip(v6|x)?)-(up|down)   --  
gen_context(system_u:object_r:pppd_initrc_exec_t,s0)
++/etc/ppp/ip-pre-up--  
gen_context(system_u:object_r:pppd_initrc_exec_t,s0)
+ 
+ /usr/bin/ipppd--  
gen_context(system_u:object_r:pppd_exec_t,s0)
+ /usr/bin/ppp-watch--  gen_context(system_u:object_r:pppd_exec_t,s0)
+Index: refpolicy-2.20210203/policy/modules/services/ppp.te
+===
+--- refpolicy-2.20210203.orig/policy/modules/services/ppp.te
 refpolicy-2.20210203/policy/modules/services/ppp.te
+@@ -86,6 +86,7 @@ allow pppd_t self:socket create_socket_p
+ allow pppd_t self:netlink_route_socket nlmsg_write;
+ allow pppd_t self:tcp_socket { accept listen };
+ allow pppd_t self:packet_socket create_socket_perms;
++allow pppd_t self:pppox_socket { connect create ioctl };
+ 
+ allow pppd_t pppd_devpts_t:chr_file { rw_chr_file_perms 
setattr_chr_file_perms };
+ 
+@@ -108,6 +109,7 @@ files_tmp_filetrans(pppd_t, pppd_tmp_t,
+ 
+ manage_dirs_pattern(pppd_t, pppd_runtime_t, pppd_runtime_t)
+ manage_files_pattern(pppd_t, pppd_runtime_t, pppd_runtime_t)
++allow pppd_t pppd_runtime_t:file map;
+ files_runtime_filetrans(pppd_t, pppd_runtime_t, { dir file })
+ 
+ can_exec(pppd_t, pppd_exec_t)
+Index: refpolicy-2.20210203/policy/m

Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2

[Étienne Mollier]

Hi Mike, Hi Thomas,

Mike Bayer, on 2021-10-08:
> you woujld have better luck changing epigrass to use automap instead:   
> https://docs.sqlalchemy.org/en/14/orm/extensions/automap.html

Thanks Mike for your recommendation!  This is very useful for me
and others who might stumble on this bug entry.

Thomas, when trying to see whether epigrass could easily be
ported away of sqlsoup, I ended up with other issues documented
in bug #995966.  I don't know how much time is of the essence to
you, but I don't expect a timely resolution of the issues at
play.  A reasonable course of action might be to drop epigrass
and python-sqlsoup of Testing sooner than later, for the time
being.  What do you think?

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


signature.asc
Description: PGP signature

Bug#995966: epigrass: epirunner and epidash fail to run due to missing dash modules

[Étienne Mollier]

Package: epigrass
Version: 3.0.0+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When investigating #995781 to see whether sqlsoup could be
replaced by automap, per sqlsoup upstream suggestion since
their program is not maintained anymore, I realised I couldn't
run epigrass related programs at all.  The epidash program
crashes with:

$ epidash 
Traceback (most recent call last):
  File "/usr/bin/epidash", line 33, in 
sys.exit(load_entry_point('epigrass==3.0', 'console_scripts', 
'epidash')())
  File "/usr/bin/epidash", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in 
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in 
_find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in 
exec_module
  File "", line 228, in 
_call_with_frames_removed
  File "/usr/lib/python3/dist-packages/Epigrass/epidash.py", line 1, in 

import dash
ModuleNotFoundError: No module named 'dash'

The epirunner program fails to execute anything meaningul, even
the -h flag to get help:

$ epirunner -h
Traceback (most recent call last):
  File "/usr/bin/epirunner", line 33, in 
sys.exit(load_entry_point('epigrass==3.0', 'console_scripts', 
'epirunner')())
  File "/usr/bin/epirunner", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in 
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in 
_find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in 
exec_module
  File "", line 228, in 
_call_with_frames_removed
  File "/usr/lib/python3/dist-packages/Epigrass/manager.py", line 20, 
in 
from Epigrass.simobj import graph, edge, siteobj
  File "/usr/lib/python3/dist-packages/Epigrass/simobj.py", line 19, in 

from Epigrass import epimodels
  File "/usr/lib/python3/dist-packages/Epigrass/epimodels.py", line 15, 
in 
import numba
  File "/usr/lib/python3/dist-packages/numba/__init__.py", line 19, in 

from numba.core import config
  File "/usr/lib/python3/dist-packages/numba/core/config.py", line 16, 
in 
import llvmlite.binding as ll
  File "/usr/lib/python3/dist-packages/llvmlite/binding/__init__.py", 
line 4, in 
from .dylib import *
  File "/usr/lib/python3/dist-packages/llvmlite/binding/dylib.py", line 
3, in 
from llvmlite.binding import ffi
  File "/usr/lib/python3/dist-packages/llvmlite/binding/ffi.py", line 
137, in 
from pkg_resources import resource_filename
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
3243, in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
3226, in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
3255, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
568, in _build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
886, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
772, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'dash_html_components' 
distribution was not found and is required by epigrass

On the good news side, past in the docs/source/install.rst file,
which is merely for informational purpose, I haven't seen any
reference to sqlsoup in the source code, so removing dependency
to python3-sqlsoup shouldn't be too much of a problem hopefully.

I see stubs of packaging for dash python modules [1, 2, 3] on
salsa, and will have some spare cycles this weekend to have a
fresh look at them if that helps.

[1]: https://salsa.debian.org/med-team/python-dash
[2]: https://salsa.debian.o

Bug#995986: simple-cdd: Firmware not being included in installer image

[Scott]

Package: simple-cdd
Version: 0.6.8
Severity: important

Dear Maintainer,

I'm using simple-cdd to build an installer which includes non-free firmware.

I find that the firmware is included in the installer when it is built when 
running on Debian 10, but the firmware is not included in the installer when it 
is built when running on Debian 11.

The result is that I can successfully run the installer on a Thinkpad T440 if 
the installer is built under Debian 10, but an installer built under Debian 11 
when run on the same Thinkpad T440 will ask for missing firmware to be provided 
before it reaches the installer screens which ask for a network to be selected 
and wifi credentials.

My profiles/.packages file has just one line:
firmware-iwlwifi

On Debian 11, when I look in 
/tmp/mirror/pool/non-free/f/firmware-nonfree/, I see the 
firmware-iwlwifi_20210315-3_all.deb package.

But when I look in /tmp/cd-build/bullseye/CD1/firmware/, all I 
see is a dep11/ directory, and I don't see the firmware file.

I don't know enough to know if this is an upstream problem, so I thought I'd 
report it here in the first instance.

If it helps, the project I'm using simple-cdd in is quite a simple one and you 
can see it here: https://github.com/countermeasure/basic-box

Cheers!


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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.35
ii  lsb-release 11.1.0
ii  python3 3.9.2-3
ii  python3-simple-cdd  0.6.8
ii  reprepro5.3.0-1.2
ii  rsync   3.2.3-4
ii  wget1.21-1+b1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  6.0.1-2

Versions of packages simple-cdd suggests:
pn  qemu-system | qemu-kvm  

-- no debconf information

Bug#986109: closed by Debian FTP Masters (Bug#986109: Removed package(s) from unstable)

[intrigeri]

Thanks!

Bug#995985: transition: vala

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: v...@packages.debain.org
Severity: normal

I request permission to do the vala transition.

We can do a binNMU for valabind. I confirmed that valabind builds
successfully against the new vala version.

https://release.debian.org/transitions/html/auto-vala.html

Thank you,
Jeremy Bicha

Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709

[spi]

Am 30.09.21 um 22:03 schrieb Hans van Kranenburg:

Hi spi, Salvatore,

On 8/5/21 1:58 PM, s...@gmxpro.de wrote:


In preparation for the bug report for upstream I did some more
investigation.

The kernel panic also occurs without bonding interfaces but needs much
more time to happen. With a bonding interface it happens within some
seconds. Without bonding interfaces it needs like a minute with the
network discovery being re-launched for 2 or 3 times. The kernel panic
is still the same about the bnx2 driver.

In the constellation without a bonding interface the kernel panic only
occurs if
- opnsense as a domU is running (this domU bounds all bridged interfaces
as default gateway for all networks)


Just FWIW, I'm seeing this bug-mail-thread now, and it rings a bell.

I spent some time in the past to debug crashing BCM5719 (4x1G) nics in
HP DL360 G8/9 series servers. In this case, the firmware inside the nic
crashed, so the symptoms were different. This happened only when having
a Xen domU active as router, which was routing incoming traffic packets
(from outside the box) back to the outside again.

02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.3 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)

Also, 2x 1G were bonded, I use openvswitch with LACP for that.

The symptoms are obviously different, mine looked like this:

tg3 :02:00.2 eth1: transmit timed out, resetting
tg3 :02:00.2 eth1: 0x: 0x165714e4, 0x00100546, 0x0201,
0x00800010
tg3 :02:00.2 eth1: 0x0010: 0x92b3000c, 0x, 0x92b4000c,
0x
tg3 :02:00.2 eth1: 0x0020: 0x92b5000c, 0x, 0x,
0x22be103c

tg3 :02:00.2 eth1: 0x7000: 0x0808, 0x, 0x,
0x4cd8
tg3 :02:00.2 eth1: 0x7010: 0xdbbd2b97, 0x010080f3, 0x00d70081,
0x03008200
tg3 :02:00.2 eth1: 0x7020: 0x, 0x, 0x0406,
0x10004000
tg3 :02:00.2 eth1: 0x7030: 0x0002, 0x4cdc, 0x001f,
0x
tg3 :02:00.2 eth1: 0: Host status block
[0001:0070:(:0563:):(:0094)]
tg3 :02:00.2 eth1: 0: NAPI info
[0070:0070:(016a:0094:01ff)::(068c:::)]
tg3 :02:00.2 eth1: 1: Host status block
[0001:0083:(::):(015b:)]
tg3 :02:00.2 eth1: 1: NAPI info
[0051:0051:(::01ff):0124:(0124:0124::)]
tg3 :02:00.2 eth1: 2: Host status block
[0001:00d8:(0e96::):(:)]
tg3 :02:00.2 eth1: 2: NAPI info
[00a4:00a4:(::01ff):0e5b:(065b:065b::)]
tg3 :02:00.2 eth1: 3: Host status block
[0001:0013:(::):(:)]
tg3 :02:00.2 eth1: 3: NAPI info
[00f8:00f8:(::01ff):072f:(072f:072f::)]
tg3 :02:00.2 eth1: 4: Host status block
[0001:009c:(::0736):(:)]
tg3 :02:00.2 eth1: 4: NAPI info
[007c:007c:(::01ff):0716:(0716:0716::)]
tg3 :02:00.2: tg3_stop_block timed out, ofs=1400 enable_bit=2
tg3 :02:00.2: tg3_stop_block timed out, ofs=c00 enable_bit=2
tg3 :02:00.2 eth1: Link is down
tg3 :02:00.2 eth1: Link is up at 1000 Mbps, full duplex
tg3 :02:00.2 eth1: Flow control is off for TX and off for RX
tg3 :02:00.2 eth1: EEE is disabled


- sysctl parameter net.bridge.bridge-nf-call-ip6tables is set to 0.

If both conditions are not met no kernel panic oaccurs.


What I found out in the end is that using `ethtool -K $iface tso off` is
a workaround to not make it trigger some obscure bug inside the nic that
makes it crash.

So, I think my actual suggestion would be, even while it does not look
like the same thing, but it's still Broadcom stuff which can have
*cough* weird issues... if you can reliably reproduce the problem, then
can you try setting tso off on the physical interfaces in dom0 and try
again? In Dutch we say "nooit geschoten altijd mis".



The next time I do maintenance I'll rerun the tests and set "ethtool -K
$iface tso off". "ethtool -K ${int} tx off" is alreday configured on the
server and I also tried tso off and others as well but didn't pay
attention to this bug at that time - as said the kernel panic doesn't
occur immediately but only after some minutes.

In German it is "wer nicht wagt, der nicht gewinnt" ;-)


Other IPv6 related sysctl parameters are set on dom0 like
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1


The layer2-iptables settings are
net.bridge.bridge-nf-call-ip6tables = 0 ***



Do you recall what your setting for net.bridge.bridge-nf-call-ip6tables was?



net.bridge.bridge-nf-call-iptables = 1


net.bridge.bridge-nf-call-arptables = 0




As said, if I don't se

Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709

[spi]

Did you got any response on your reporting upstream?


No, not yet. Troubleshooting took quite some time and in the meantime
there is a new upstream kernel version available. So I need to rerun all
tests again. As this is a productive server I can only shutdown the
server every now and then on weekends.

Cheers,
Sebastian

Bug#995984: new upstream (590)

[Daniel Baumann]

Package: less
Severity: wishlist

Hi Milan,

long time no see :)

Any chance you could upload the current less upstream version (590 atm) 
to sid? Do you need any help with it?


Regards,
Daniel

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[David]

On Sun, 3 Oct 2021 at 05:03, Holger Wansing  wrote:
>
> I'm thinking about (long overdue) updating chapter
> https://d-i.debian.org/doc/installation-guide/en.amd64/ch04s03.html
> "Preparing Files for USB Memory Stick Booting".

> - #988472 proposes to no longer use "install-mbr" to install an MBR on the
>   stick, but use 'cat /usr/lib/syslinux/mbr.bin >/dev/sdX' instead.
>   Any objections or comments on this?
>   (Works fine for me so far.)

Hello

Thank you very much for your work on Debian.

I see that the suggestion to use 'cat' comes
from #604839.

Yes, 'cat' will "work", however I feel there is no
good reason to use 'cat' there.

Because the purpose of 'cat' is for concatenating
multiple files, and it also requires a shell redirection
from stdout. Both are unnecessary here.

I suggest this command should be used:
# cp /usr/lib/syslinux/mbr.bin /dev/sdX

That would be consistent with the similar command
used in Section 4.3.1 on the same page:
# cp debian.iso /dev/sdX

And that is what the 'cp' command is for ...
copying files :)

Bug#995965: containerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

[Jörn Heusipp]

Hi!


It's same. And I have requested the release team to rebuild all Go packages on
i386.

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


Sorry, I was not aware of that bug report. That should solve it indeed.

Thanks,
Jörn

Bug#995982: xz-utils: Please ship localized man pages

[Helge Kreutzmann]

Package: xz-utils
Version: 5.2.5-2
Severity: wishlist

Previously, localized man pages for xz-utils were shipped by
manpages-xx, e.g. manpages-de.

During the development cycle of bullseye, upstream strated shipping
the localized man pages and manpages-xx stopped shipping them.

However, the Debian packages does not contain the localized man pages.

Could you enable and ship the localized manpages, possibly in a
backport as well?

Thanks


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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xz-utils depends on:
ii  libc6 2.31-13
ii  liblzma5  5.2.5-2

xz-utils recommends no packages.

xz-utils suggests no packages.

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#621788: Please support encryption without separate /boot, with encryption support in current GRUB2

[Gregor Riepl]

> Current GRUB2 supports directly reading encrypted partitions via
> dm-crypt and LUKS.  This allows setting up an encrypted disk without a
> separate unencrypted /boot partition.  Please consider supporting this
> configuration in debian-installer.

Grub currently doesn't support LUKS2 very well.
For example, PBKDF2 has to be used instead of Argon2 for key derivation.
The Debian Installer currently doesn't allow changing this.

Even worse, I haven't had any success at creating a LUKS2 volume that
grub-efi-amd64-signed recognizes.

Additionally, partman doesn't recognize LUKS1 partitions well and cannot
create any either. This makes it much harder to install Debian on a
LUKS1 volume.

Please add support for this scenario, as the additional unencrypted
/boot partition is unnecessary on UEFI systems and increases the attack
surface of encrypted disks.

Bug#995980: assimp FTCBFS: very wrong python dependency and more issues

[Helmut Grohne]

Source: assimp
Version: 5.0.1~ds0-3
Tags: patch
Control: clone -1 -2
Control: retitle -2 rules-require-build-prerequisite gives bogus advice
Control: reassign -2 lintian
Control: severity -2 important
Control: tags -2 - patch
Control: affects -2 src:assimp
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debhel...@packages.debian.org
X-Debbugs-Cc: debian-cr...@lists.debian.org

assimp fails to cross build from source. It attempts to build a python
module, but it ultimately fails doing so. While inspecting this, I
discovered that assimp "Build-Depends: python3:any | python3-all:any |
python3-dev:any | python3-all-dev:any | dh-sequence-python3". This is
wrong on so many levels.

For starters, sbuild ignores any alternative in unstable, so in
practice, this happens to become "python3:any". Any other alternative is
simply ignored and shouldn't be there.

Then, issuing a dependency on python3-dev:any without libpython3-dev is
practically never correct. That could be a separate lintian tag, but
that's not too bad here as python3-dev isn't needed. Either you go
python3-dev or you go python3-dev:any, libpython3-dev or you have a very
special and unusual use case that I have never encountered anywhere.

Also listing dh-sequence-python3 there is bogus. You already added
"--with python3" in debian/rules. This is duplicate at best. Either
should be dropped, but enabling a dh-addon in an alternative is clearly
not right, and debhelper should likely fail hard when encountering that.
Niels, do you agree?

I wondered how one would come up with such a strange dependency and
asked #debian-mentors for help. Kindly, a user named "itd" pointed me at
the lintian tag rules-require-build-prerequisite, which very likely is
the cause for this. Please disable the tag right now as it does more
harm than good. While the tag isn't bad per-se, the advice it gives
misleads users and produces broken packages. I request hiding or
disabling it now and then figuring out what it really should say.

Back to assimp. I looked into this to make it cross buildable, right?
And it was failing in Python-ish stuff. So why do we actually build the
Python module? Did I say module? It's not an extension? No, it isn't.
And we really don't have to build it in an arch-only build. So the key
to making assimp cross buildable is to make an arch-only build fully
skip the Python stuff. And once you do that, you don't care about :any
annotations anymore as those are practically irrelevant in
Build-Depends-Indep.

So I've attached a patch for assimp to fix the cross build and the
strange build dependency. Please consider applying it.

Helmut
diff --minimal -Nru assimp-5.0.1~ds0/debian/changelog 
assimp-5.0.1~ds0/debian/changelog
--- assimp-5.0.1~ds0/debian/changelog   2021-10-06 09:02:14.0 +0200
+++ assimp-5.0.1~ds0/debian/changelog   2021-10-08 20:49:28.0 +0200
@@ -1,3 +1,15 @@
+assimp (5.0.1~ds0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix python build dependency. (Closes: #-1)
++ Alternatives in Build-Depends are ignored.
++ Enable the python3 dh addon once only.
++ Build python module in indep build only.
++ Move python Build-Depends to B-D-I.
++ Drop the :any nonsense.
+
+ -- Helmut Grohne   Fri, 08 Oct 2021 20:49:28 +0200
+
 assimp (5.0.1~ds0-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru assimp-5.0.1~ds0/debian/control 
assimp-5.0.1~ds0/debian/control
--- assimp-5.0.1~ds0/debian/control 2021-10-06 09:02:14.0 +0200
+++ assimp-5.0.1~ds0/debian/control 2021-10-08 20:49:28.0 +0200
@@ -15,8 +15,10 @@
  libstb-dev,
  libutfcpp-dev,
  zlib1g-dev | libz-dev,
- python3:any | python3-all:any | python3-dev:any | python3-all-dev:any | 
dh-sequence-python3,
  doxygen,
+Build-Depends-Indep:
+ dh-sequence-python3,
+ python3,
 Rules-Requires-Root: no
 Vcs-Git: https://salsa.debian.org/debian/assimp.git
 Vcs-Browser: https://salsa.debian.org/debian/assimp
diff --minimal -Nru assimp-5.0.1~ds0/debian/rules assimp-5.0.1~ds0/debian/rules
--- assimp-5.0.1~ds0/debian/rules   2021-10-06 09:02:14.0 +0200
+++ assimp-5.0.1~ds0/debian/rules   2021-10-08 20:49:28.0 +0200
@@ -33,7 +33,7 @@
 export PYBUILD_NAME=pyassimp
 
 %:
-   dh $@ --with python3 --buildsystem=cmake
+   dh $@ --buildsystem=cmake
 
 override_dh_auto_configure:
dh_auto_configure -- \
@@ -50,8 +50,10 @@
 
 override_dh_auto_build:
dh_auto_build
+ifneq ($(filter python3-pyassimp,$(shell dh_listpackages)),)
dh_auto_build --buildsystem=pybuild -- \
-d port/PyAssimp/
+endif
cd obj-$(DEB_HOST_GNU_TYPE)/doc && doxygen Doxyfile
cd doc && doxygen Doxyfile_Cmd
 
@@ -61,8 +63,10 @@
 
 override_dh_auto_install:
dh_auto_install
+ifneq ($(filter python3-pyassimp,$(shell dh_listpackages)),)
dh_auto_install --buildsystem=pybuild -- \
-d port/PyAssimp/
+endif
# IrrXML is not packaged 

Bug#995979: pamix FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[Helmut Grohne]

Source: pamix
Version: 1.6~git20180112.ea4ab3b-3
Severity: serious
Tags: ftbfs

pamix fails to build from source in unstable on amd64, because ncurses
added format string annotations to some functions. A non-parallel build
now ends as follows:

| [ 53%] Building CXX object CMakeFiles/pamix.dir/src/pamix_ui.cpp.o
| /usr/bin/c++ -DFEAT_UNICODE -I"/<>/include" -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -MD -MT 
CMakeFiles/pamix.dir/src/pamix_ui.cpp.o -MF 
CMakeFiles/pamix.dir/src/pamix_ui.cpp.o.d -o 
CMakeFiles/pamix.dir/src/pamix_ui.cpp.o -c "/<>/src/pamix_ui.cpp"
| /<>/src/pamix_ui.cpp: In member function ‘void 
pamix_ui::redrawAll()’:
| /<>/src/pamix_ui.cpp:106:52: error: format not a string literal 
and no format arguments [-Werror=format-security]
|   106 |   mvprintw(lineNumber++, 1, applicationName.c_str());
|   |^
| /<>/src/pamix_ui.cpp:124:64: error: format not a string literal 
and no format arguments [-Werror=format-security]
|   124 |   mvprintw(curY, curX + remainingChars + 1, displayName.c_str());
|   |^
| /<>/src/pamix_ui.cpp: In member function ‘void 
pamix_ui::drawHeader() const’:
| /<>/src/pamix_ui.cpp:187:22: warning: format ‘%d’ expects 
argument of type ‘int’, but argument 5 has type ‘std::map >::size_type’ {aka ‘long unsigned int’} [-Wformat=]
|   187 |  mvprintw(0, 1, "%d/%d", m_Entries->empty() ? 0 : m_SelectedEntry + 
1, m_Entries->size());
|   | ~^
 ~
|   |  |
|
|   |  int  
std::map >::size_type {aka 
long unsigned int}
|   | %ld
| cc1plus: some warnings being treated as errors
| make[3]: *** [CMakeFiles/pamix.dir/build.make:163: 
CMakeFiles/pamix.dir/src/pamix_ui.cpp.o] Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:86: CMakeFiles/pamix.dir/all] Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:139: all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
| make: *** [debian/rules:7: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#995965: containerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

[Shengjing Zhu]

Control: block -1 by 995946

Hi,

On Sat, Oct 09, 2021 at 10:07:12AM +0200, Jörn Heusipp wrote:
> Package: containerd
> Version: 1.5.7~ds1-1
> Severity: important
> X-Debbugs-Cc: osm...@problemloesungsmaschine.de
> 
> Dear Maintainer,
> 
> Starting containerd results in Illegal Instruction on a 32bit x86 system.
> 
> Looking at the core dump with gdb shows the offending instruction as
> 0x808ef13   movsd  %xmm0,0x44(%esp) 
> .
> This is an SSE2 instruction, however, my CPU only supports SSE1.
> 
> As containerd is written in Go, this is likely due to
> , thus building with GO386=softfloat
> might fix the issue.
> 
> See related bug report on dockerd (#995708).

It's same. And I have requested the release team to rebuild all Go packages on
i386.

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

Bug#995978: RM: libgdal28 -- ROM; NBS; Cruft prevents removal of libepsilon

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 995977
Control: block 994073 by -1

Please remove the libgdal28 binary package from the archive after the
removal of the opencv cruft (#995977) to unblock the removal of
libepsilon (#994073).

Kind Regards,

Bas