Bug#985699: xtensor: tests fail on less common architectures

[Drew Parsons]

Source: xtensor
Followup-For: Bug #985699

0.23.10-10 skips the test_xnpy tests on s390x, hppa, powerpc, ppc64,
sparc64.

That just ignores the problem, enabling the package to build and get
tested by other packages on these arches. It doesn't fix the problem.

Bug#994911: error modifying deb822 object while iterating

[Niels Thykier]

On Thu, 23 Sep 2021 00:43:50 + Jelmer Vernooij 
wrote:
> Package: python3-debian
> Version: 0.1.41
> Severity: normal
> 
> Modifying a deb822 file while iterating over it results in a RuntimeError:
> 
> ...
>   File 
> "/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
>  line 2208, in iter_keys
> yield from self._kvpair_elements
> RuntimeError: dictionary keys changed during iteration
> 
> (This doesn't happen with the default deb822 implementation)
> 
> [...]


Hi,

Can you provide the code snippet that triggers this bug?

As I understand it, this is "normal" for a dict depending on the exact
usage, which is why I would like to see what you were doing when you
triggered the bug. :)

Example with dict:

 d = {'a': 1, 'b': 2}
 for e in d:
> ...   if d[e] == 2:
> ... d['z'] = 1
> ... 
> Traceback (most recent call last):
>   File "", line 1, in 
> RuntimeError: dictionary changed size during iteration
 for e in d:
> ... d[e] = 2
> ... 
 


Thanks,
~Niels

Bug#995923: Forwarded upstream

[Diederik de Haas]

Control: forwarded -1 https://lore.kernel.org/all/4974503.Y8KB3sNASq@bagend/

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

Bug#993624: RM: eckit [armel i386 armhf mipsel] -- ROM; 32-bit archs no longer supported

[Sebastiaan Couwenberg]

On Fri, 03 Sep 2021 20:50:51 +0100 Alastair McKinstry wrote:
> Please remove the 32-bit archs - they are no longer supported upstream

Looks like this cannot happen until at least fckit & metkit are also
removed from these architectures:

 $ dak rm -Rn -b -a armel,i386,armhf,mipsel \
   eckit libeckit-dev libeckit-utils libeckit0d
 W: -a/--architecture implies -p/--partial.
 Will remove the following packages from unstable:

 libeckit-dev |   1.16.3-1 | armel, armhf, i386, mipsel
 libeckit-utils |   1.16.3-1 | armel, armhf, i386, mipsel
 libeckit0d |   1.16.3-1 | armel, armhf, i386, mipsel

 Maintainer: Alastair McKinstry 

 --- Reason ---

 --

 Checking reverse dependencies...
 # Broken Depends:
 fckit: libfckit0d
 metkit: libmetkit-dev
 libmetkit-utils
 libmetkit0d

 # Broken Build-Depends:
 atlas-ecmwf: libeckit-dev (>= 1.4.7-7)
 fckit: libeckit-dev (>= 1.15.4-1~)
 fdb: libeckit-dev
 metkit: libeckit-dev (>= 1.16.0-1~)
 metview: libeckit-dev (>= 1.10.1~)
 odc: libeckit-dev (>= 1.16.0-1~)

 Dependency problem found.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#996013: transition: poco

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition the new POCO version. The auto generated ben
file looks fine and I have rebuild all reverse dependencies
successfully.

Cheers Jochen

Bug#996014: transition: orocos-kdl

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition orocos-kdl. The auto generated ben file looks
fine and I've rebuild all reverse dependencies successfully.

Cheers Jochen

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

[Marco d'Itri]

On Oct 10, Otto Kekäläinen  wrote:

> Yeah, but one should be able to skip at least one release, right? What
No.

> Could you please consider if the libcrypt1 change was done in a way so
> that at least Buster to Bookworm upgrades would work?
This has already been discussed: feel free to do the work required by 
the glibc maintainer.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#996015: debian-faq: remove obsolete usenet links / Re: Debian FAQ Usenet newsgroup

[Joost van Baal-Ilić]

Package: debian-faq
Severity: normal

Hi Sebul,

On Sun, Oct 10, 2021 at 05:07:34AM +0900, sebul / https://sebuls.blogspot.kr
wrote:
> Hello.
> https://www.debian.org/doc/manuals/debian-faq/support.en.html#s12.2.5
> 12.2.5. Usenet newsgroups
> say Linux Online and LinuxJournal
> But these links say page not found.
> 
> Where is usenet for debian?

These links are obsolete and should be removed.  I don't think there's
a specific usenet group dedicated to Debian; and I'm not quite sure
we should refer to one if such a group would exist.

Thanks for bringing this up.

(Now reporting this in our Bugtracking System; Patches welcome! :-)

Bye,

Joost

Bug#996016: libreoffice: fails to send email

[Alex]

Package: libreoffice
Severity: normal

Dear Maintainer,

When I created a document in libreoffice and when I would send it as 
mail attachment, Libreoffice simply doesn't open my mailprogram defined 
in KDE.
When I start libreoffice in a shell, I got error messages when sending 
the document as mail. In fact, I defined Thunderbird as my mail program 
in KDE->Settings.

The error message I got is:

moz=/usr/bin/thunderbird
FOPTS=-L
Befehlzeile: if file -L /usr/bin/thunderbird | grep script > /dev/null 
&& grep [NM]PL /usr/bin/thunderbird > /dev/null

/usr/lib/libreoffice/program/senddoc: 64: file: Permission denied
3
$1=/usr/bin/thunderbird
/usr/bin/thunderbird -compose 
subject='FEO',attachment='file:///tmp/lu3553l027nu.tmp/lu3553l027nx.tmp/FEO.ods'

$2=subject='FEO',attachment='file:///tmp/lu3553l027nu.tmp/lu3553l027nx.tmp/FEO.ods'
/usr/lib/libreoffice/program/senddoc: 77: /usr/bin/thunderbird: 
Permission denied


I modified the script senddoc with several echo commands to get an 
output which component is causing the error.
As you can see, I got a permission denied on /usr/bin/thunderbird. I 
checked the permissions and those seemed to be ok, and when I start 
thunderbird directly in the shell, it will start.
So I disabled apparmor. I completely uninstalled it and after a reboot, 
the sending by mail attachment works as expected.


This is only an ugly workaround to get it work again, so help please.

Thank you

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

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_LU.UTF-8, LC_CTYPE=de_LU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice depends on:
ii libreoffice-base 1:7.0.4-4
ii libreoffice-calc 1:7.0.4-4
ii libreoffice-core 1:7.0.4-4
ii libreoffice-draw 1:7.0.4-4
ii libreoffice-impress 1:7.0.4-4
ii libreoffice-math 1:7.0.4-4
ii libreoffice-report-builder-bin 1:7.0.4-4
ii libreoffice-writer 1:7.0.4-4
ii python3-uno 1:7.0.4-4

Versions of packages libreoffice recommends:
ii fonts-crosextra-caladea 20130214-2.1
ii fonts-crosextra-carlito 20130920-1.1
ii fonts-dejavu 2.37-2
ii fonts-liberation 1:1.07.4-11
ii fonts-liberation2 2.1.3-1
ii fonts-linuxlibertine 5.3.0-6
ii fonts-noto-core 20201225-1
ii fonts-noto-extra 20201225-1
ii fonts-noto-mono 20201225-1
ii fonts-noto-ui-core 20201225-1
pn fonts-sil-gentium-basic 
ii libreoffice-java-common 1:7.0.4-4
pn libreoffice-nlpsolver 
ii libreoffice-report-builder 1:7.0.4-4
pn libreoffice-script-provider-bsh 
pn libreoffice-script-provider-js 
pn libreoffice-script-provider-python 
ii libreoffice-sdbc-mysql 1:7.0.4-4
ii libreoffice-sdbc-postgresql 1:7.0.4-4
pn libreoffice-wiki-publisher 

Versions of packages libreoffice suggests:
ii cups-bsd 2.3.3op2-3+deb11u1
ii default-jre [java8-runtime] 2:1.11-72
ii firefox-esr 78.15.0esr-1~deb11u1
ii ghostscript 9.53.3~dfsg-7+deb11u1
ii gnupg 2.2.27-2
pn gpa 
ii gstreamer1.0-libav 1.18.4-3
ii gstreamer1.0-plugins-bad 1.18.4-3
ii gstreamer1.0-plugins-base 1.18.4-2
ii gstreamer1.0-plugins-good 1.18.4-2
ii gstreamer1.0-plugins-ugly 1.18.4-2
ii hunspell-de-at [hunspell-dictionary] 20161207-9
ii hunspell-de-ch [hunspell-dictionary] 20161207-9
ii hunspell-de-de [hunspell-dictionary] 20161207-9
ii hunspell-en-us [hunspell-dictionary] 1:2019.10.06-1
ii hyphen-de [hyphen-hyphenation-patterns] 1:7.1.0~rc3-3
ii imagemagick 8:6.9.11.60+dfsg-1.3
ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3
ii libgl1 1.3.2-1
pn libofficebean-java 
pn libreoffice-gnome | libreoffice-plasma 
pn libreoffice-grammarcheck 
ii libreoffice-help-de [libreoffice-help] 1:7.0.4-4
ii libreoffice-l10n-de [libreoffice-l10n] 1:7.0.4-4
pn libreoffice-librelogo 
ii libsane1 1.0.31-4.1
ii libxrender1 1:0.9.10-1
ii myspell-fr-gut [myspell-dictionary] 1:1.0-32.1
ii mythes-de [mythes-thesaurus] 20160424-4
ii mythes-de-ch [mythes-thesaurus] 20160424-4
pn openclipart2-libreoffice | openclipart-libreoffice 
ii openjdk-11-jre [java8-runtime] 11.0.12+7-2
pn pstoedit 
ii thunderbird 1:78.14.0-1~deb11u1
pn unixodbc 

Bug#996017: synfigstudio: New version availabe (bug fixing)

[Davide Prina]

Package: synfigstudio
Version: 1.4.0+dfsg-1+b1
Severity: wishlist
X-Debbugs-Cc: davide.pr...@gmail.com

Dear mainteiner,

there is a new version (1.4.2 2021.07.29) available.
Version 1.4.1 and 1.4.2 fix a lot of bugs of version 1.4.0 present in
Debian.

see the Changelog here
https://github.com/synfig/synfig/blob/v1.4.2/ChangeLog.md

I don't want to report bugs in Debian that are already fixed in 1.4.2
version.

Ciao
Davide

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

Kernel: Linux 5.14.9-dp-20211009 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages synfigstudio depends on:
ii  libatkmm-1.6-1v52.28.2-1
ii  libc6   2.32-4
ii  libcairo2   1.16.0-5
ii  libcairomm-1.0-1v5  1.12.2-4
ii  libgcc-s1   11.2.0-8
ii  libglib2.0-02.70.0-1+b1
ii  libglibmm-2.4-1v5   2.66.1-1
ii  libgtk-3-0  3.24.30-3
ii  libgtkmm-3.0-1v53.24.5-1
ii  libmlt++7   7.0.1-3
ii  libpangomm-1.4-1v5  2.46.1-1
ii  libsigc++-2.0-0v5   2.10.4-2
ii  libstdc++6  11.2.0-8
ii  libsynfig0a 1.4.0+dfsg-2.1
ii  libxml++2.6-2v5 2.40.1-3

Versions of packages synfigstudio recommends:
ii  synfig-examples  1.4.0+dfsg-2.1

synfigstudio suggests no packages.

-- no debconf information

Bug#995903: console logs

[V V]

Hello.
More details on that:
1) Attempt to open downloads:
[2323:2323:1010/125446.121796:ERROR:CONSOLE(146)] "Uncaught TypeError:
Cannot read properties of undefined (reading 'length')", source:
chrome://downloads/manager.js
2) Attempt to open history:
[2323:2323:1010/125644.918153:ERROR:CONSOLE(283)] "Uncaught TypeError:
Cannot read properties of undefined (reading 'querying')", source:
chrome://history/history_list.js (283)
[2323:2323:1010/125644.924414:ERROR:CONSOLE(431)] "Uncaught TypeError:
Cannot read properties of undefined (reading 'length')", source:
chrome://history/history_list.js (431)
[2323:2323:1010/125644.929009:ERROR:CONSOLE(1)] "Uncaught TypeError: Cannot
read properties of undefined (reading 'substr')", source:
chrome://resources/polymer/v3_0/polymer/polymer_bundled.min.js (1)

Probable upstream bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=1249296

With best regards,
Vladimir

Bug#996016: libreoffice: fails to send email

[Rene Engelhard]

found 996016 1:7.0.4-4

retitlle 996016 ibreoffice: fails to send email with Thunderbird set as
mailer in KDE

tag 996016 + moreinfo

tag 996016 + unreproducible

thanks


Hi,


Am 10.10.21 um 11:30 schrieb Alex:
> Package: libreoffice
> Severity: normal
>
> Dear Maintainer,
>
> When I created a document in libreoffice and when I would send it as
> mail attachment, Libreoffice simply doesn't open my mailprogram
> defined in KDE.
> When I start libreoffice in a shell, I got error messages when sending
> the document as mail. In fact, I defined Thunderbird as my mail
> program in KDE->Settings.
And what is in LO settings?

> As you can see, I got a permission denied on /usr/bin/thunderbird. I
checked the permissions and those seemed to be ok, and when I start
thunderbird directly in the shell, it will start.

> So I disabled apparmor. I completely uninstalled it and after a
> reboot, the sending by mail attachment works as expected.
>
> This is only an ugly workaround to get it work again, so help please.
>
What if you set your mailer as xdg-email? That one is explicitely allowed:


profile libreoffice-senddoc /usr/lib/libreoffice/program/senddoc {
  #include 

  #include 

  /{usr/,}bin/sh    rmix,
  /{usr/,}bin/bash  rmix,
  /{usr/,}bin/dash  rmix,
  /{usr/,}bin/sed   rmix,
  /usr/bin/dirname  rmix,
  /usr/bin/basename rmix,
  /{usr/,}bin/grep  rmix,
  /{usr/,}bin/uname rmix,
  /usr/bin/xdg-open rPUx,
  /usr/bin/xdg-email    rPUx,
  /dev/null rw,
  /usr/lib/libreoffice/program/uri-encode rmpux,
  /usr/share/libreoffice/share/config/* r,
  owner
@{HOME}/.config/libreoffice{,dev}/?/user/uno_packages/cache/log.txt rw,
}


xdg-email will send with your preferred e-mail programm (see man xdg-email).


I just tried it: LOs default has sensible-lomua set. That one opened
Thunderbird in my  GNOME and happily set mail.

case `basename "$MAILER"` in
    sensible-lomua)
    if [ -x /usr/bin/xdg-email ] ; then
    MAILER=/usr/bin/xdg-email
    elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kde-open ] \
   || [ -x /usr/bin/gnome-open ] \
   || [ -x /usr/bin/xdg-open ]; then
    # use an undefined mailer, to trigger the default handling
    MAILER=undefined
    elif [ -n "$GNOME_DESKTOP_SESSION_ID" -a -x /usr/bin/evolution
]; then
    MAILER=/usr/bin/evolution
    elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kmail ]; then
    MAILER=/usr/bin/kmail
    elif [ -x /usr/bin/evolution ]; then
    # default
    MAILER=/usr/bin/evolution
    elif [ -x /usr/bin/icedove ]; then
    # fallback
    MAILER=/usr/bin/icedove
    elif [ -x /usr/bin/thunderbird ]; then
    # fallback
    MAILER=/usr/bin/thunderbird
    fi
    ;;
esac


... using xdg-email.

Regards,


Rene

Bug#922425: submitted #996003 to solve this

[Chris Vogel]

submited 

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

to solve this issue. It is a backport from a patch accepted upstream at GNU 
grub2.

Bug#996018: linux-image-5.10.0-9-amd64: linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type

[Jonas]

Package: src:linux
Version: 5.10.70-1
Severity: important

Dear Maintainer,

I can't use kernel 5.10 cat I have a building module error

===
$ sudo dpkg-reconfigure linux-image-5.10.0-9-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.10.0-9-amd64:
Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j8 KERNELRELEASE=5.10.0-9-amd64 -C /lib/modules/5.10.0-9-amd64/build
M=/var/lib/dkms/asus/1.0/build/src modules...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.10.0-9-amd64 (x86_64)
Consult /var/lib/dkms/asus/1.0/build/make.log for more information.
.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-9-amd64



$ cat /var/lib/dkms/asus/1.0/build/make.log
DKMS make.log for asus-1.0 for kernel 5.10.0-9-amd64 (x86_64)
dim. 10 oct. 2021 12:17:37 CEST
make : on entre dans le répertoire « /usr/src/linux-headers-5.10.0-9-amd64 »
  CC [M]  /var/lib/dkms/asus/1.0/build/src/hid-asus.o
  CC [M]  /var/lib/dkms/asus/1.0/build/src/i2c-hid.o
/var/lib/dkms/asus/1.0/build/src/i2c-hid.c:42:10: fatal error:
linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type
   42 | #include 
  |  ^
compilation terminated.
make[2]: *** [/usr/src/linux-headers-5.10.0-9-common/scripts/Makefile.build:285
: /var/lib/dkms/asus/1.0/build/src/i2c-hid.o] Erreur 1
make[2]: *** Attente des tâches non terminées
make[1]: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:1846 :
/var/lib/dkms/asus/1.0/build/src] Erreur 2
make: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:185 : __sub-make]
Erreur 2
make : on quitte le répertoire « /usr/src/linux-headers-5.10.0-9-amd64 »


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

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: N501VW
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: N501VW.300
board_vendor: ASUSTeK COMPUTER INC.
board_name: N501VW
board_version: 1.0   

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor Host Bridge/DRAM Registers [8086:1910] (rev 07)
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Host Bridge/DRAM Registers [1043:1080]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe 
Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:191b] (rev 06) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:1080]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 07)
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Thermal Subsystem [1043:1080]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset 
Family USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. 100 Series/C230 Series Chipset Family 
USB 3.0 xHCI Controller [1043:201f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 Signal processing controller [1180]: Intel Corporation 100 Series/C230 
Series Chipset Family Thermal Subsystem [8086:a131] (rev 31)
Subsystem: ASUSTeK Computer Inc. 100 Series/C230 Series Chipset Family 
Thermal Subsystem [1043

Bug#996019: debootstrap: bootstrap of ubuntu impish is failing

[Sylvestre Ledru]

Package: debootstrap
Version: 1.0.124
Severity: normal

Dear Maintainer,

$ sudo debootstrap impish impish 
https://www-ftp.lip6.fr/pub/linux/distributions//Ubuntu/archive/ 
I: impish uses zstd compression, setting --extractor=ar option
I: Retrieving InRelease 
I: Retrieving Packages 
I: Validating Packages
[...]
I: Validating zlib1g 1:1.2.11.dfsg-2ubuntu7
I: Chosen extractor for .deb packages: ar
I: Extracting base-files...
I: Extracting base-passwd...
E: Extracting .//var/cache/apt/archives/base-passwd_3.5.51_amd64.deb requires 
the zstdcat command, which is not available

adding --include=zstd doesn't fix the issue
[...]
I: Retrieving zstd 1.4.8+dfsg-2.1
I: Validating zstd 1.4.8+dfsg-2.1
I: Chosen extractor for .deb packages: ar
I: Extracting base-files...
I: Extracting base-passwd...
E: Extracting .//var/cache/apt/archives/base-passwd_3.5.51_amd64.deb requires 
the zstdcat command, which is not available

Thanks,
Sylvestre

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'oldstable-updates'), (500, 
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages debootstrap depends on:
ii  wget  1.21-1+b1

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2021.1.1
ii  gnupg   2.2.27-2

Versions of packages debootstrap suggests:
ii  binutils2.37-7
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.2.5-2
pn  zstd

-- no debconf information

Bug#994911: error modifying deb822 object while iterating

[Niels Thykier]

On Sun, 10 Oct 2021 08:41:55 +0200 Niels Thykier  wrote:
> On Thu, 23 Sep 2021 00:43:50 + Jelmer Vernooij 
> wrote:
> > Package: python3-debian
> > Version: 0.1.41
> > Severity: normal
> > 
> > Modifying a deb822 file while iterating over it results in a RuntimeError:
> > 
> > ...
> >   File 
> > "/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
> >  line 2208, in iter_keys
> > yield from self._kvpair_elements
> > RuntimeError: dictionary keys changed during iteration
> > 
> > (This doesn't happen with the default deb822 implementation)
> > 
> > [...]
> 
> 
> Hi,
> 
> Can you provide the code snippet that triggers this bug?
> 
> As I understand it, this is "normal" for a dict depending on the exact
> usage, which is why I would like to see what you were doing when you
> triggered the bug. :)
> 
> Example with dict:
> 
>  d = {'a': 1, 'b': 2}
>  for e in d:
> > ...   if d[e] == 2:
> > ... d['z'] = 1
> > ... 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > RuntimeError: dictionary changed size during iteration
>  for e in d:
> > ... d[e] = 2
> > ... 
>  
> 
> 
> Thanks,
> ~Niels
> 
> 

Thinking some more about, this *might* be fixed as a side effect of:

https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/69/diffs?commit_id=2832d2fc306b10f56ff910e6e1cf990ccdb9e9b4

(but it is hard to tell for sure without the concrete code you were using)

Feel free to cherry-pick that commit out of the branch/MR if you need it. :)

Thanks,
~Niels

Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Jan Mojzis]

Repacked version without exe-binary is in the git repository:
https://salsa.debian.org/debian/bearssl

Best regards,
Jan

> On 5 Oct 2021, at 19:44, Jan Mojzis  wrote:
> 
> Ok
> I understand,
> first i will contact ‘upstream’ to remove the binary from the package.
> 
> Jan
> 
>> On 5 Oct 2021, at 19:03, Bastian Germann  wrote:
>> 
>> Am 05.10.21 um 18:59 schrieb Jan Mojzis:
>>> Hello,
>>> I have removed the patch, it wasn’t good idea.
>>> The exe binary doesn’t affect debian package.
>>> So I just updates the d/source/include-binary file.
>> 
>> Hi Jan,
>> 
>> Actually, it does affect the source package legally. You cannot know without 
>> a long process of reverse engineering what is contained in the binary. Odds 
>> are that it violates the distribution permission of additional software that 
>> is included but not documented.
>> 
>> So if you want the package sponsored by me, you would have to repack, 
>> removing that file from the source package.
>> 
>> Thanks,
>> Bastian
>> 
> 

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

[Jeremy Sowden]

On 2021-10-09, at 18:52:49 +0200, Andreas Metzler wrote:
> 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.
>
>  Adding libxext-dev to libdockapp-dev's Depends would work
> perfectly fine for me.

I've pushed a commit to add the dependency, plus a few other things.

> --- 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).

Agreed.

J.


signature.asc
Description: PGP signature

Bug#996020: openscad: Buffer overflows in STL parser (CVE-2020-28599, CVE-2020-28600)

[Kristian Nielsen]

Package: openscad
Version: 2019.01~RC2-2
Severity: important

There is a bug in the import() function in OpenSCAD when importing STL
files. Certain invalid files can cause out-of-bounds accesses, potentially
causing arbitrary code execution.

The bug is associated with these CVEs:

  https://security-tracker.debian.org/tracker/CVE-2020-28599
  https://security-tracker.debian.org/tracker/CVE-2020-28600

As seen in these links, the bug affects the openscad version in buster (and
stretch), but is fixed in newer upstream releases (meaning bullseye,
testing, and unstable are unaffected). The upstream fix is in this git
commit 07ea60f82e94a155f4926f17fad8e8366bc74874:

  
https://github.com/openscad/openscad/commit/07ea60f82e94a155f4926f17fad8e8366bc74874

This commit contains the fix to the C++ source code. It also adds tests to
the testsuite which test for this bug.

This is considered a minor security issue. The plan is to get it fixed in
buster through a point release.

 - Kristian.

-- Package-specific info:
Output of /usr/share/bug/openscad:
$ glxinfo |grep 'OpenGL .* string:'
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.5
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

-- 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: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openscad depends on:
ii  lib3mf11.8.1+ds-4
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libboost-program-options1.74.0 1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-9
ii  libc6  2.31-13
ii  libcairo2  1.16.0-5
ii  libdouble-conversion3  3.1.5-6.1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libgcc-s1  10.2.1-6
ii  libgl1 1.3.2-1
ii  libglew2.1 2.1.0-4+b1
ii  libglib2.0-0   2.66.8-1
ii  libglu1-mesa [libglu1] 9.0.1-1
ii  libgmp10   2:6.2.1+dfsg-1
ii  libharfbuzz0b  2.7.4-1
ii  libhidapi-libusb0  0.10.1+dfsg-1
ii  libmpfr6   4.1.0-3
ii  libopencsg11.4.2-3
ii  libqscintilla2-qt5-15  2.11.6+dfsg-2
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gamepad5 5.15.2-2
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libspnav0  0.2.3-1+b2
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.2-1
ii  libxml22.9.10+dfsg-6.7
ii  libzip41.7.3-1

Versions of packages openscad recommends:
ii  openscad-mcad  2019.05-1

Versions of packages openscad suggests:
pn  geomview  
pn  librecad  
ii  meshlab   2020.09+dfsg1-1
ii  openscad-testing  2021.01-2

-- no debconf information

Bug#995934: python-gevent: diff for NMU version 20.9.0-2.1

[GCS]

On Sat, Oct 9, 2021 at 7:25 AM Sandro Tosi  wrote:
> On Fri, Oct 8, 2021 at 3:12 PM László Böszörményi (GCS)  
> wrote:
> >  I can't devote enough time to this package. Feel free any of you
> > taking this package to the Python Team and maintain it there.
>
> I can help maintain this package, just because I maintain one of its
> rdeps. Do you have a git repo you're using to package python-gevent?
> if so, we can migrate that under
> https://salsa.debian.org/python-team/packages (if not, we're going to
> create it from the source packages).
 Long story short, I don't have one.

> Do you still want to be in the Uploaders list?
 It's up to your decision. I can't devote time to the package. You can
put me there, but don't expect much work.

> since we're talking about this, did you give it a thought if you want
> to start maintaining your other python packages under the DPT
> umbrella?
 Will think about it and let you know soon, sending separate emails about those.

Regards,
Laszlo/GCS

Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap

[Jerome BENOIT]

Hello Bill, thanks for the correction and sorry for my late reaction.
I have just updated the gap-io package accordingly. All looks fine.
Meanwhile I have noticed that
/usr/lib/gap/sysinfo.gap and /usr/lib/x86_64-linux-gnu/gap/sysinfo.gap
are actually the same files.
Cheers,
Jerome

On Fri, 24 Sep 2021 13:27:28 +0200 Bill Allombert  wrote:

Le Sun, Apr 18, 2021 at 08:40:41PM +0200, Jerome BENOIT a écrit :

Hello Jerome,
I am working on updating GAP to 4.11.1, sorry for the delay.

> > > I have just packaged the last version 4.7.1 of gap-io.
> > > Its build machinery has changed. It now uses a Gap makefile 
Makefile.gappkg .
> > > This makefile implicitly assumes (?=) that the gap and gac are into 
GAPPATH
> > > as passed at configuration time. The GAPPATH is /usr/lib/gap or 
/usr/lib//gap :
> > > the former contains gac, the latter gap. It would be nice to have
> > > both
> at least
> > > in one of the GAPPATH.
> > 
> > Why not set GAPPATH to /usr/bin then ?
> 
> Because GAPPATH is also used to get access to sysinfo.gap .


OK, so if I move gac to /usr/lib//gap, will it work ?

Cheers,
--
Bill. 

Imagine a large red swirl here. 





--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996021: ITP: cvelib -- library and a command line interface for the CVE Services API

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: cvelib
  Version : 0.4.0
  Upstream Author : Red Hat Security Response Team 
* URL : https://github.com/RedHatProductSecurity/cvelib
* License : Expat
  Programming Lang: Python
  Description : library and a command line interface for the CVE Services 
API

cvelib is a library and a command line interface to interact with the
MITRE CVE Services API, including functions to reserve one or more CVE
IDs for a CNA, filter and list reserved CVEs owned by a CNA, and
administration of user and tokes for a CNA.

This package installs the library for Python 3 and a CLI tool.

Bug#996022: transgui: Does not connect to 3.00 server, fails with 'Duplicate object member: "status"'

[Eduardo M Kalinowski]

Package: transgui
Version: 5.18.0+dfsg-1+b1
Severity: important
Tags: patch upstream

I upgraded my server that runs transmission-deamon to bullseye, the server is
now running version 3.00-1. This upgrade has rendered the client (running
testing) unable to connect, it fails with the message 'Duplicate object member:
"status"'.

This bug is not specific to Debian, and has been reported upstream at
https://github.com/transmission-remote-gui/transgui/issues/1325 . There's a
patch at https://github.com/transmission-remote-gui/transgui/pull/1329 that has
not been incorporated upstream yet (for over a year now), please consider
including that patch in the Debian package.



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

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

Versions of packages transgui depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libx11-6 2:1.7.2-2+b1

transgui recommends no packages.

transgui suggests no packages.

Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap

[Bill Allombert]

Le Sun, Oct 10, 2021 at 02:02:28PM +0200, Jerome BENOIT a écrit :
> Hello Bill, thanks for the correction and sorry for my late reaction.
> I have just updated the gap-io package accordingly. All looks fine.

Great!

> Meanwhile I have noticed that
> /usr/lib/gap/sysinfo.gap and /usr/lib/x86_64-linux-gnu/gap/sysinfo.gap
> are actually the same files.

Yes. I plan to remove /usr/lib/gap/sysinfo.gap once nobody use it
anymore. And idem for /usr/lib/gap/gac.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#996018: Acknowledgement (linux-image-5.10.0-9-amd64: linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type)

[Jonas]

This is not the reason for the absence of kernels 5.10 at startup
After the migration to bullseye it was missing update-grub.

Bug#996024: buster-pu: package ruby-httpclient/2.8.3-3+deb10u1

[Antonio Terceiro]

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

[ Reason ]
ruby-httpclient uses a vendored copy of a CA certificate bundle, and
that is a ticking time bomb. This update fixes that by removing that
vendored copy and making it use the system CA certificate bundle by
default.

[ Impact ]
The main package affected by this is apt-listbugs, which stopped being
able to download bug data information from bugs.debian.org due to the
recent expiration of the old Let's Encrypt root certificate.

[ Tests ]
The added autopkgtest test fails without the patch and passes without
it. apt-listbugs is now able to fetch bug data information again.

[ Risks ]
The changes are simple enough and this is a low risk update.

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

[ Changes ]

The changes are simple enough that I feel copy-pasting from the
changelog is enough:

* Add simple autopkgtest to check a basic SSL connection
* Add patch to use the system certificate store (Closes: #995448)
* debian/rules: remove embedded CA certificate store
* Add dependency on ca-certificates
diff --git a/debian/changelog b/debian/changelog
index a164bb1..e6d96d5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+ruby-httpclient (2.8.3-3+deb10u1) buster; urgency=medium
+
+  * Add simple autopkgtest to check a basic SSL connection
+  * Add patch to use the system certificate store (Closes: #995448)
+  * debian/rules: remove embedded CA certificate store
+  * Add dependency on ca-certificates
+
+ -- Antonio Terceiro   Sun, 10 Oct 2021 09:24:03 -0300
+
 ruby-httpclient (2.8.3-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index e50868f..e38581d 100644
--- a/debian/control
+++ b/debian/control
@@ -21,6 +21,7 @@ Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
 Depends: ruby | ruby-interpreter,
  ruby-http-cookie (>= 1.0),
+ ca-certificates,
  ${misc:Depends},
  ${shlibs:Depends}
 Description: HTTP client library for ruby
diff --git a/debian/patches/0008-Use-system-CA-certificate-store.patch b/debian/patches/0008-Use-system-CA-certificate-store.patch
new file mode 100644
index 000..3ec8820
--- /dev/null
+++ b/debian/patches/0008-Use-system-CA-certificate-store.patch
@@ -0,0 +1,33 @@
+From: Antonio Terceiro 
+Date: Wed, 6 Oct 2021 10:03:32 -0300
+Subject: Use system CA certificate store
+
+---
+ lib/httpclient/ssl_config.rb | 7 +--
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+diff --git a/lib/httpclient/ssl_config.rb b/lib/httpclient/ssl_config.rb
+index f6e7ce9..d4e48f2 100644
+--- a/lib/httpclient/ssl_config.rb
 b/lib/httpclient/ssl_config.rb
+@@ -249,7 +249,7 @@ class HTTPClient
+ # Loads default trust anchors.
+ # Calling this method resets all existing sessions.
+ def load_trust_ca
+-  load_cacerts(@cert_store)
++  set_default_paths
+   change_notify
+ end
+ 
+@@ -413,11 +413,6 @@ class HTTPClient
+   nil
+ end
+ 
+-# Use 2048 bit certs trust anchor
+-def load_cacerts(cert_store)
+-  file = File.join(File.dirname(__FILE__), 'cacert.pem')
+-  add_trust_ca_to_store(cert_store, file)
+-end
+   end
+ 
+ 
diff --git a/debian/patches/series b/debian/patches/series
index f1a4a0e..3764163 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@
 0004-Add-upstream-changelog.patch
 0005-tweak-test-dep-change.patch
 disable-test-proxy-ssl.patch
+0008-Use-system-CA-certificate-store.patch
diff --git a/debian/rules b/debian/rules
index 118221b..bdf2c5b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,3 +6,8 @@ export LANG=C.UTF-8
 
 %:
 	dh $@ --buildsystem=ruby --with ruby
+
+
+override_dh_auto_install:
+	dh_auto_install
+	rm --verbose $(CURDIR)/debian/ruby-httpclient/usr/lib/ruby/vendor_ruby/httpclient/*.pem
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..d5b55a2
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: ssl-smoke-test
+Restrictions: needs-internet, allow-stderr
diff --git a/debian/tests/ssl-smoke-test b/debian/tests/ssl-smoke-test
new file mode 100644
index 000..ce81ca0
--- /dev/null
+++ b/debian/tests/ssl-smoke-test
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+set -exu
+
+httpclient get https://bugs.debian.org/


signature.asc
Description: PGP signature

Bug#996023: buster-pu: package openscad/2019.01~RC2-2

[Kristian Nielsen]

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

[ Reason ]

This is a fix for two minor security issues in buster:

  https://security-tracker.debian.org/tracker/CVE-2020-28599
  https://security-tracker.debian.org/tracker/CVE-2020-28600

It was coordinated with the security team to take this through
buster-proposed-updates rather than handle through the security team.

[ Impact ]

In theory the bug could allow arbitrary code execution from loading a
carefully crafted STL file into desktop application openscad. OpenSCAD is a
script language/compiler for programatically building 3D models, eg. for
3D-printing purposes. STL is a file format for storing 3D model data. The
OpenSCAD language has functions for reading STL files. Thus to exploit this
bug would involve a user loading or writing an openscad script which
references the malicious STL file. Thus not too likely a scenario, but on
the other hand probably still well within what is considered a security
issue nowadays.

[ Tests ]

The patch (from upstream) includes test cases for the bugs. I verified that
these tests fail without the fix, and that they pass with the fix. In
addition, openscad has a comprehensive test suite, all of which passes in
the fixed package.

[ Risks ]

The risk from this upload is low:

 - The fix only touches the STL import function. All other functionality in
   the program is unaffected.
 - The patch has received extensive testing in later upstream releases.
 - The fix is covered in an automatic test suite, all of which passes.

The addition of new tests in the upload is not strictly necessary to fix the
bug. It seems good to include them (to have a higher confidence that the
backport of the fix actually works). But an alternative is to prepare a
smaller upload containg *just* the changes to the C++ source (and
corresponding d/changelog entry).

[ Checklist ]

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

[ Changes ]

1. Fixes to the C++ source code import_stl() function to properly handle
invalid input files. This is a straight backport of the upstream fix.

2. Addition of three new tests to the automatic test suite, which test the
fix.

[ Other info ]

The attached debdiff contains three binary files. These are part of the
additions to the test suite. They are images containing the expected
graphical output of the openscad program from the tests.


buster_openscad_debdiff.txt
Description: Binary data

Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1

[Felix Geyer]

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

[ Reason ]
libseccomp 2.5.1 only knows about syscall up to Linux 5.8.
The proposed changes add the syscalls up to Linux 5.14.

[ Impact ]
Syscalls for Linux 5.9 and 5.10 can't be allowed.

Software built with support for newer kernels (often the case in containers)
expect newer syscalls to work or return ENOSYS.
If that syscall is not supported by libseccomp and a default filter action of
returning EPERM is used, such software will break.
Therefore you often need to be able to allow a syscall even when the running
kernel doesn't support it.

[ Tests ]
* autopkgtest passes on amd64
* Verified adding a filter for the close_range() syscall works (new in 5.9)
* Verified that systemd and Docker run

[ Risks ]
The changes only extend the syscall csv table and add new syscall defines.

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

[ Changes ]
Cherry-pick upstream commits to support syscalls up to Linux 5.14.diff -Nru libseccomp-2.5.1/debian/changelog libseccomp-2.5.1/debian/changelog
--- libseccomp-2.5.1/debian/changelog   2020-12-21 10:50:30.0 +0100
+++ libseccomp-2.5.1/debian/changelog   2021-10-10 13:35:59.0 +0200
@@ -1,3 +1,9 @@
+libseccomp (2.5.1-1+deb11u1) bullseye; urgency=medium
+
+  * Add support for syscalls up to Linux 5.14.
+
+ -- Felix Geyer   Sun, 10 Oct 2021 13:35:59 +0200
+
 libseccomp (2.5.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libseccomp-2.5.1/debian/patches/series 
libseccomp-2.5.1/debian/patches/series
--- libseccomp-2.5.1/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libseccomp-2.5.1/debian/patches/series  2021-10-10 13:05:00.0 
+0200
@@ -0,0 +1,3 @@
+syscalls_update_the_syscall_table_to_v5.12-rc7.patch
+syscalls_add_close_range_syscall.patch
+syscalls_update_to_Linux_v5.14-rc7.patch
diff -Nru 
libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch 
libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch
--- libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch  
1970-01-01 01:00:00.0 +0100
+++ libseccomp-2.5.1/debian/patches/syscalls_add_close_range_syscall.patch  
2021-10-10 13:05:00.0 +0200
@@ -0,0 +1,30 @@
+From ac849e7960547d418009a783da654d5917dbfe2d Mon Sep 17 00:00:00 2001
+From: Sascha Grunert 
+Date: Fri, 16 Jul 2021 12:13:36 +0200
+Subject: [PATCH] syscalls: add close_range() syscall
+
+The syscall has been added a while ago so we should support resolving
+it, too.
+
+Signed-off-by: Sascha Grunert 
+Reviewed-by: Tom Hromatka 
+[PM: subject line tweak]
+Signed-off-by: Paul Moore 
+(imported from commit 01e5750e7c84bb14e5a5410c924bed519209db06)
+---
+ include/seccomp-syscalls.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h
+index 7b69214c..1ca500be 100644
+--- a/include/seccomp-syscalls.h
 b/include/seccomp-syscalls.h
+@@ -476,6 +476,8 @@
+ 
+ #define __SNR_close   __NR_close
+ 
++#define __SNR_close_range __NR_close_range
++
+ #ifdef __NR_connect
+ #define __SNR_connect __NR_connect
+ #else
diff -Nru 
libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch
 
libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch
--- 
libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch
1970-01-01 01:00:00.0 +0100
+++ 
libseccomp-2.5.1/debian/patches/syscalls_update_the_syscall_table_to_v5.12-rc7.patch
2021-10-10 13:05:00.0 +0200
@@ -0,0 +1,73 @@
+From c56a00fe173a7dd5a8326431ae28863ce432bbc1 Mon Sep 17 00:00:00 2001
+From: Paul Moore 
+Date: Sat, 17 Apr 2021 16:30:48 -0400
+Subject: [PATCH] syscalls: update the syscall table to v5.12-rc7
+
+Due to additional ABIs in main we can't do a simple backport or copy
+of the syscall table so we are generating it directly in the
+release-2.5 branch.
+
+This patch also fixes the missing faccessat2() #defines in the
+seccomp-syscalls.h header file.
+
+Signed-off-by: Paul Moore 
+---
+ include/seccomp-syscalls.h | 2 ++
+ src/syscalls.csv   | 6 +-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h
+index 2a4ebd3d..7b69214c 100644
+--- a/include/seccomp-syscalls.h
 b/include/seccomp-syscalls.h
+@@ -564,6 +564,8 @@
+ 
+ #define __SNR_faccessat   __NR_faccessat
+ 
++#define __SNR_faccessat2  __NR_faccessat2
++
+ #ifdef __NR_fadvise64
+ #define __SNR_fadvise64   __NR_fadvise64
+ #else
+diff --git a/src/syscalls.csv b/src/syscalls.csv
+index 11d087a6..4c82869

Bug#996026: bullseye-pu: package ruby-httpclient/2.8.3-3+deb11u1

[Antonio Terceiro]

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

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
ruby-httpclient uses a vendored copy of a CA certificate bundle, and
that is a ticking time bomb. This update fixes that by removing that
vendored copy and making it use the system CA certificate bundle by
default.

[ Impact ]
The main package affected by this is apt-listbugs, which stopped being
able to download bug data information from bugs.debian.org due to the
recent expiration of the old Let's Encrypt root certificate.

[ Tests ]
The added autopkgtest test fails without the patch and passes without
it. apt-listbugs is now able to fetch bug data information again.

[ Risks ]
The changes are simple enough and this is a low risk update.

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

[ Changes ]

The changes are simple enough that I feel copy-pasting from the
changelog is enough:

* Add simple autopkgtest to check a basic SSL connection
* Add patch to use the system certificate store (Closes: #995448)
* debian/rules: remove embedded CA certificate store
* Add dependency on ca-certificates
diff --git a/debian/changelog b/debian/changelog
index a164bb1..3708b17 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+ruby-httpclient (2.8.3-3+deb11u1) bullseye; urgency=medium
+
+  * Add simple autopkgtest to check a basic SSL connection
+  * Add patch to use the system certificate store (Closes: #995448)
+  * debian/rules: remove embedded CA certificate store
+  * Add dependency on ca-certificates
+
+ -- Antonio Terceiro   Sun, 10 Oct 2021 09:24:03 -0300
+
 ruby-httpclient (2.8.3-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index e50868f..e38581d 100644
--- a/debian/control
+++ b/debian/control
@@ -21,6 +21,7 @@ Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
 Depends: ruby | ruby-interpreter,
  ruby-http-cookie (>= 1.0),
+ ca-certificates,
  ${misc:Depends},
  ${shlibs:Depends}
 Description: HTTP client library for ruby
diff --git a/debian/patches/0008-Use-system-CA-certificate-store.patch b/debian/patches/0008-Use-system-CA-certificate-store.patch
new file mode 100644
index 000..3ec8820
--- /dev/null
+++ b/debian/patches/0008-Use-system-CA-certificate-store.patch
@@ -0,0 +1,33 @@
+From: Antonio Terceiro 
+Date: Wed, 6 Oct 2021 10:03:32 -0300
+Subject: Use system CA certificate store
+
+---
+ lib/httpclient/ssl_config.rb | 7 +--
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+diff --git a/lib/httpclient/ssl_config.rb b/lib/httpclient/ssl_config.rb
+index f6e7ce9..d4e48f2 100644
+--- a/lib/httpclient/ssl_config.rb
 b/lib/httpclient/ssl_config.rb
+@@ -249,7 +249,7 @@ class HTTPClient
+ # Loads default trust anchors.
+ # Calling this method resets all existing sessions.
+ def load_trust_ca
+-  load_cacerts(@cert_store)
++  set_default_paths
+   change_notify
+ end
+ 
+@@ -413,11 +413,6 @@ class HTTPClient
+   nil
+ end
+ 
+-# Use 2048 bit certs trust anchor
+-def load_cacerts(cert_store)
+-  file = File.join(File.dirname(__FILE__), 'cacert.pem')
+-  add_trust_ca_to_store(cert_store, file)
+-end
+   end
+ 
+ 
diff --git a/debian/patches/series b/debian/patches/series
index f1a4a0e..3764163 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@
 0004-Add-upstream-changelog.patch
 0005-tweak-test-dep-change.patch
 disable-test-proxy-ssl.patch
+0008-Use-system-CA-certificate-store.patch
diff --git a/debian/rules b/debian/rules
index 118221b..bdf2c5b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,3 +6,8 @@ export LANG=C.UTF-8
 
 %:
 	dh $@ --buildsystem=ruby --with ruby
+
+
+override_dh_auto_install:
+	dh_auto_install
+	rm --verbose $(CURDIR)/debian/ruby-httpclient/usr/lib/ruby/vendor_ruby/httpclient/*.pem
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..d5b55a2
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: ssl-smoke-test
+Restrictions: needs-internet, allow-stderr
diff --git a/debian/tests/ssl-smoke-test b/debian/tests/ssl-smoke-test
new file mode 100644
index 000..ce81ca0
--- /dev/null
+++ b/debian/tests/ssl-smoke-test
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+set -exu
+
+httpclient get https://bugs.debian.org/


signature.asc
Description: PGP signature

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

[MichaIng]

The LTS team has no interest in fixing this IMHO major usage bug on the 
init system?


Since we didn't see this earlier among user user base, chances are high 
that it has been caused by the last package update (security repo) from 
08 Jul 2021.


I'll try to verify this by pulling an earlier package from the regular 
repo and compare the behaviour with other architectures.


Best regards,

Micha

Bug#995985: transition: vala

[Sebastian Ramacher]

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

On 2021-10-09 07:38:06, Jeremy Bicha wrote:
> 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

Please go ahead.

Cheers
-- 
Sebastian Ramacher

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

[Olivier Girondel]

On 10/9/21 11:01 PM, Olivier Girondel wrote:
Thanks, I think it needs the main lebiniou package for the test to 
succeed, since the printing to stderr is fixed there

Regards,



Hi Adam,

I can confirm 
https://ci.debian.net/data/autopkgtest/testing/amd64/l/lebiniou/15867923/log.gz 
should be fixed by lebiniou-3.62.1-1, which is on mentors.debian.net. 
Can you please upload it as well ?


Thanks,

--
Olivier

Bug#996027: [9203248275263]

[Ahmad Niazi]

Package: 9203248275263
Version: SoapFault - faultcode: 'SOAP-ENV:Server' faultstring: 'Processing
Failure' faultactor: 'null' detail: org.kxml2.kdom.Node@41b8a6f
Severity: 
Tags: 
X-Debbugs-CC: 
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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

Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines?

[Nathaniel Filardo]

It occurs to me, quite belatedly, that it may be worth asking the
author, reviewers, and signers of the change in question their
thoughts on this bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279

In particular, on ppc64 systems, Linux typically is configured to use
a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page.  It
looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
something (perhaps in userspace, even, eek?) is requesting
4KiB-but-not-64KiB alignment of this buffer.

Any insight you could offer would be deeply appreciated.
Thanks,
--nwf;

Bug#996023: Acknowledgement (buster-pu: package openscad/2019.01~RC2-2)

[Kristian Nielsen]

The openscad bug tracking this issue is #996020:

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

 - Kristian.

Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Ondrej Zary]

Package: mariadb-server
Version: 1:10.3.31-0+deb10u1
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,
upgrading mariadb-server from 1:10.3.29-0+deb10u1 to 1:10.3.31-0+deb10u1 failed
because mariadb failed to start. /var/log/mysql/error.log:

2021-10-10 15:12:49 0 [ERROR] InnoDB: corrupted TRX_NO 10002001c6986c3
2021-10-10 15:12:49 0 [ERROR] InnoDB: Plugin initialization aborted with error 
Data structure corruption
2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' init function returned error.
2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE 
failed.
2021-10-10 15:12:50 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2021-10-10 15:12:50 0 [ERROR] Aborting

Fortunately, it works after downgrading back to 10.3.29.
Data does not seem to be corrupted.

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages mariadb-server depends on:
ii  mariadb-server-10.3  1:10.3.31-0+deb10u1

mariadb-server recommends no packages.

mariadb-server suggests no packages.

-- debconf-show failed

Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines?

[Xi Ruoyao]

On Sun, 2021-10-10 at 14:46 +0100, Nathaniel Filardo wrote:
> It occurs to me, quite belatedly, that it may be worth asking the
> author, reviewers, and signers of the change in question their
> thoughts on this bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279
> 
> In particular, on ppc64 systems, Linux typically is configured to use
> a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page.  It
> looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
> something (perhaps in userspace, even, eek?) is requesting
> 4KiB-but-not-64KiB alignment of this buffer.

Christian told me the buffer should be aligned to *CPU* page boundary,
or the page table in AMDGPU driver will be corrupted:

> the value of num_entries must always be a multiple of 
> AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables.

> You need to identify the root cause of this, most likely start or last
> are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.

IMO f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
dev_info.gart_page_size" should be backported along with this, which
makes the kernel to provide the CPU page size to libdrm and mesa and
correct userspace behavior.  I'm not sure why only one is backported.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[Michael Shuler]

On 10/9/21 6:40 PM, Christoph Anton Mitterer wrote:

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


Good find - patch attached to check if file exists before chmod & mv.

--
Kind regards,
Michael
diff --git a/debian/changelog b/debian/changelog
index 2a146c2..7b1e0bc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ca-certificates (20211010) UNRELEASED; urgency=medium
+
+  [ Michael Shuler ]
+  * Fix error on install when TEMPBUNDLE missing. Closes: #996005
+
+ -- Michael Shuler   Sun, 10 Oct 2021 09:10:28 -0500
+
 ca-certificates (20211004) unstable; urgency=low
 
   [ Debian Janitor ]
diff --git a/sbin/update-ca-certificates b/sbin/update-ca-certificates
index 789867f..0265205 100755
--- a/sbin/update-ca-certificates
+++ b/sbin/update-ca-certificates
@@ -187,8 +187,12 @@ then
   fi
 fi
 
-chmod 0644 "$TEMPBUNDLE"
-mv -f "$TEMPBUNDLE" "$CERTBUNDLE"
+# chmod and mv only if TEMPBUNDLE exists or install may fail, #996005
+if [ -f "$TEMPBUNDLE" ]
+then
+  chmod 0644 "$TEMPBUNDLE"
+  mv -f "$TEMPBUNDLE" "$CERTBUNDLE"
+fi
 # Restore proper SELinux label after moving the file
 [ -x /sbin/restorecon ] && /sbin/restorecon "$CERTBUNDLE" >/dev/null 2>&1
 

Bug#996019: debootstrap: bootstrap of ubuntu impish is failing

[Dimitri John Ledkov]

On Sun, 10 Oct 2021 12:41:45 +0200 Sylvestre Ledru 
wrote:
> Package: debootstrap
> Version: 1.0.124
> Severity: normal
>
> Dear Maintainer,
>
> $ sudo debootstrap impish impish
https://www-ftp.lip6.fr/pub/linux/distributions//Ubuntu/archive/
> I: impish uses zstd compression, setting --extractor=ar option
> I: Retrieving InRelease
> I: Retrieving Packages
> I: Validating Packages
> [...]
> I: Validating zlib1g 1:1.2.11.dfsg-2ubuntu7
> I: Chosen extractor for .deb packages: ar
> I: Extracting base-files...
> I: Extracting base-passwd...
> E: Extracting .//var/cache/apt/archives/base-passwd_3.5.51_amd64.deb
requires the zstdcat command, which is not available
>
> adding --include=zstd doesn't fix the issue

One needs to install zstd on the host, including zstd in the debootstrap
set will not help.

Does $ sudo apt install zstd => fix the issue for you?



> [...]
> I: Retrieving zstd 1.4.8+dfsg-2.1
> I: Validating zstd 1.4.8+dfsg-2.1
> I: Chosen extractor for .deb packages: ar
> I: Extracting base-files...
> I: Extracting base-passwd...
> E: Extracting .//var/cache/apt/archives/base-passwd_3.5.51_amd64.deb
requires the zstdcat command, which is not available
>
> Thanks,
> Sylvestre
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (600, 'unstable'), (500, 'oldstable-updates'), (500,
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages debootstrap depends on:
> ii  wget  1.21-1+b1
>
> Versions of packages debootstrap recommends:
> pn  arch-test   
> ii  debian-archive-keyring  2021.1.1
> ii  gnupg   2.2.27-2
>
> Versions of packages debootstrap suggests:
> ii  binutils2.37-7
> pn  squid-deb-proxy-client  
> pn  ubuntu-archive-keyring  
> ii  xz-utils5.2.5-2
> pn  zstd
>
> -- no debconf information
>

Bug#996027:

[Ahmad Niazi]

ahmadniazi...@gmail.com

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

[MichaIng]

Okay, first I verified that it is an issue on all architectures, even on 
Raspberry Pi with the dedicated Raspbian armv6hf package builds.


Then I sadly found that downgrading all systemd source packages to 
232-25+deb9u12 does not solve the issue. Also I wasn't able to find 
another recent package upgrade which may be related, though I still 
cannot believe that this issue exists for a long time, as we should have 
received more reports from our users.


Is there a history of all updated packages within Debian's APT 
repositories? I have no local upgrade history (apt/dpkg logs), sadly on 
Stretch testing systems.


Upgrading to 241-5~bpo9+1 from Stretch backports btw solves it, though 
this is not applicable in all cases, e.g. Raspbian systems where 
backports are not available.


Best regards,

Micha

Bug#994173: completion broken on "apt-get u"

[Gabriel F. T. Gomes]

On Mon, 04 Oct 2021 09:01:55 +0200
Philipp Marek  wrote:
>
> Perhaps I can find out what went wrong...
> do you have any ideas? readline settings,
> some shell function interfering (wrong completion load order?), ...??

I don't. There are too many variables. :/

> Next time that happens, I'll dump all functions and env vars,
> and compare to a working shell setup...

Thanks!

Bug#995034: Only single dash completions shown

[Gabriel F. T. Gomes]

On Mon, 04 Oct 2021 04:28:27 +0800
積丹尼 Dan Jacobson  wrote:
> 
> perltidy debian
> perltidy upstream
> bash-completion debian
> bash-completion upstream

Yeah, I know it's sometimes hard to tell where to submit bug reports
to. On the other hand, it looks like you are doing a good job of it.
Reporting upstream bugs upstream, then asking for backports downstream.

Cheers,
Gabriel

Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Otto Kekäläinen]

Hello!

Thanks for reporting. Could you please check if this has been reported
upstream at jira.mariadb.org?

There isn't much we can do about InnoDB internals in Debian packaging.

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

[MichaIng]

raspbian is not maintained by Debian, fwiw.


Indirectly it is, since Raspbian uses the unmodified (at least in all 
cases I'm aware of) Debian package sources and ships the same updates 
shortly after they have been pushed to the Debian (source) repositories 
(including debian-security), just build for armv6hf.


But yes, not an issue of Debian where affected users can solve it via 
backports, if required.


Best regards,

Micha

Bug#931597: transmission: Lift 1024 open files limit

[Vitaly Potyarkin]

> This appears to have been reverted with
>
> https://github.com/transmission/transmission/commit/5d6922f7d6f71001de091272ad61724973c14293

The reversal commit is not part of any branches of upstream Transmission.
I don't know why ckerr needed to revert the changes back in 2020, but it was
most likely just some short-lived experimental branch.

At the moment (2021-10-10) master branch still contains the fix I submitted:

https://github.com/transmission/transmission/blob/a4d7e11a14f16b4bac69b99d4c0da055847b9625/libtransmission/web.cc#L524-L539

It didn't get merged in time for 3.0, but it is merged now and it will almost
definitely be a part of the next Transmission release.
So, the fix will eventually make it into Debian - let's hope that the next
Transmission release will come before Bookworm freeze.

I agree that this bug report should remain closed.
I'm adding this note just to provide correct information regarding the
reversal commit.

Bug#996029: firmware-iwlwifi: Filter bogus warning with "firmware: failed to load iwl-debug-yoyo.bin"

[Hideki Yamane]

Package: firmware-iwlwifi
Severity: minor

Hi,

 During looking logs, I've found that iwlwifi puts warning as below.

> 7月 09 21:04:01 elitebook830 kernel: iwlwifi :01:00.0: firmware: failed to 
> load iwl-debug-yoyo.bin (-2)
> 7月 09 21:04:01 elitebook830 kernel: firmware_class: See 
> https://wiki.debian.org/Firmware for information about missing firmware

 But my college says iwl-debug-yoyo.bin is for debugging used by Intel,
 so users don't need it (we're not sure why debug output is enabled by 
default...)


 How about putting "options iwlwifi enable_ini=0" in 
/etc/modprobe.d/iwlwifi.conf
 to ignore this bogus warning?

Bug#996030: transition: libsidplayfp

[GCS]

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

Hi RMs,

 Small transition of libsidplayfp, affecting audacious-plugins, mpd and qmmp.
I will upload its counterpart, sidplayfp when the transition is
allowed to start.

Regards,
Laszlo/GCS

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

[Sudip Mukherjee]

Hi Martin-Éric,

On Sat, Oct 9, 2021 at 7:14 PM Martin-Éric Racine
 wrote:
>
> 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?

Sorry for the delay, but too busy with $dayjob to properly do and test it.
Since you are using it and have it working with the configuration
changes, will you mind doing a NMU to it (and the other two) please.
And if you are doing NMU please feel free to upload to 0-day.


--
Regards
Sudip

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

[Spencer Olson]

Did some more investigation.  I downloaded the packages that are being used
on centos stream 8.  First I tried my test code with their version of
libssl3.so preloaded:  it failed in the same way as all the others
failed--not surprisingly since its version is much later than the 3.39
version where this changed.

Then, I downloaded and took a look at "dogtag-submit" from the CentOS
Stream 8 (RedHat) certmonger package.  As far as I can tell, their version
of "dogtag-submit" is *not* linked against libcurl-nss.so at all like the
version on debian sid.  Instead, all their certmonger helper programs are
linked against the OpenSSL version (libcurl.so.4).

So, I think that we should just link these against the openssl version, as
the RedHat packages do and get things to work again.

This raises two other issues:
- is there truly a bug in the ssl portion of the nss library?  If so, this
should probably be brought to the attention.
- perhaps the libcurl package ought to be reconfigured such that one can
install the dev packages simultaneously.  Right now, libcurl-nss also makes
a symlink "libcurl.so" that makes it conflict with the libcurl-openssl
package to which the "libcurl.so.x.x" lib belongs to.  I think that the
libcurl-gnutls package might do the same thing.

My next step will be do rebuild freeipa and certmonger with the
libcurl-openssl-dev package in place instead of the libcurl-nss-dev and
then try reinstalling.


On Sat, Oct 9, 2021 at 9:59 PM Spencer Olson  wrote:
>
> 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#995403: cert_fingerprint not working for self-signed certificate after upgrade

[Sudip Mukherjee]

Control: forwarded https://github.com/OfflineIMAP/offlineimap3/issues/89
---

Hi Joey,

On Thu, Sep 30, 2021 at 5:51 PM Joey Hess  wrote:
>
> Package: offlineimap
> Version: 7.3.3+dfsg1-1+0.0~git20210825.4ca9c75+dfsg-1
> Severity: normal
>
> ERROR: Unknown SSL protocol connecting to host 'kitenet.net' for repository 
> 'kite'. OpenSSL responded:
> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed 
> certificate (_ssl.c:1129)

Sorry for the inconvenience, I have reported it upstream and will
revert the change in Debian if its not fixed upstream in the next few
days. I will also add testing with a self signed certificate to the
autopkgtests so that this is not repeated.


-- 
Regards
Sudip

Bug#995999: FTBFS: FAIL: TestChunkDiskMapper_WriteChunk_Chunk_IterateChunks

[Martina Ferrari]

The GH issue you linked seems to be fixed upstream already with this 
patch: https://github.com/prometheus/prometheus/pull/8538/files


On 09/10/2021 19:34, Shengjing Zhu wrote:

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



--
Martina Ferrari (Tina)

Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Ondrej Zary]

Haven't found this exact problem. This seems to be closest but the error 
messages are different: https://jira.mariadb.org/browse/MDEV-25981

I'm going to copy the datadir to another machine and debug it further.

On Sunday 10 October 2021 16:55:45 Otto Kekäläinen wrote:
> Hello!
>
> Thanks for reporting. Could you please check if this has been reported
> upstream at jira.mariadb.org?
>
> There isn't much we can do about InnoDB internals in Debian packaging.


-- 
Ondrej Zary

Bug#995046: 3.2.3-7 fails with libc6-2.30

[Samuel Henrique]

Hello Eugene,

> > >  Yes, this issue may occure when libc6 vesion is outdated in normal
> > >  upgrade process.
> >
> > I would disagree on the definition of a normal upgrade process, one
> > would never end up with a combination of incompatible rsync + libc,
> > that can only happen if somebody installs a package that is not
> > supported by Debian (not from the official repos) and that package
> > holds libc back (thus running an unsupported version)[4].
>
>  I had several (at least 2 distinct) live systems with this post-upgrade
>  problem. They have backups, but now it too late: now those backups are
>  replaced by new ones.
>
>  However, it requires some clarification what is "normal upgrade" process.
>  I do not run full-upgrade ("aptitude safe-upgrade" in my taste) if some
>  new package it to be installed. I simply check dependences to be sure
>  that new package does not bring risk to break functionality of important
>  services on production system. The full-upgrade is performed on a schedule,
>  once a week or two, and requires additional monitoring of the system's
>  behaviour. For example, I have an LXC containter with libc-2.31-17,
>  which was not updated at least a month (file libc.so.6 dated 23-Aug).

You generally don't need to run full-upgrade on a stable Debian
release, that's true.
But if you are upgrading between major Debian releases, you are
required to perform a full-upgrade and install everything that it says
so there, if you fail to do it, you are running an unstable system
because you are mixing packages from different major releases.

This is where "normal upgrade" comes in, as soon as you upgrade to a
new Debian major release and don't perform full-upgrade, you're in
"unknown territory" (not officially supported/not normal).
We have lots of QA and CI tools that ensure things don't break in
multiple different scenarios, but this is one where we can't ensure
things will work (and don't test for it).

>  Running "apt-get update ; aptitude -R install rsync" I got rsync-3.2.3-8
>  without libc6 update. I consider this as a normal situation, because
>  I have no obligation to do full-upgrade when I install some package.

This is true generally speaking, but if you break the upgrade process
when going to a new major release, then this is not the case anymore,
the system can now be considered unstable. Anything you install might
require full-upgrade because this should have been done at the time
when you switched major releases.
You are bound to keep hitting issues like this one because it's not a
supported system where we can predict what's gonna happen, our tooling
doesn't test for such scenarios.

The correct approach would be to stick to the previous release, and/or
use backports, or solve the issues blocking the system from performing
a full-upgrade (which are issues that only arises with third party
packages, since we do have automated tests that ensure systems with
official packages-only are able to fully upgrade).

>  However, this combination (rsync-3.2.3-8 + libc6-2.31-17) is not
>  functional: rsync replies "failed to set permissions [...] Function
>  not implemented (38)".

I'd like to mention again, that even though I think you might be
risking too much with a system that bumped to a bigger major version
without a full-upgrade, and that this is not officially supported by
Debian, this is still a valid and real issue that you hit, and I will
solve it.
I also trust that you know what you're doing with those systems, and I
don't mean to say what you should or should not do. As long as you're
aware of the risks involved and understand that this is an unsupported
scenario with hidden issues, it should be fine.

> > I did try to reproduce the issue on Jessie, with libc 2.28, but I was
> > able to run "rsync -va /etc/ld.so.cache /tmp" with no issues.
>
>  Did you try the last rsync binary with libc6-2.28?
>  I tried and got an error (see below).

There was an issue on my reproduction steps, I'm now able to reproduce
the issue on Buster and Bullseye.

For the record and future references:
rsync 3.2.3-8 can be built on any Debian release as of now, the issue
only arises when a package built with libc6-dev >= 2.32 is installed
on a system that contains libc6 < 2.32.
Our dpkg-symbols solution is not able to identify this and naturally
choses a lower version requirement for the libc6 dependency.

Reproduction can be done on a Buster/Bullseye VM by installing an
rsync 3.2.3-8 that was compiled with libc6-dev >= 2.32 and running:
rsync -va /etc/ld.so.cache /tmp

I'm currently studying what's the best approach on solving this in a
clean manner, and I have updated upstream on this matter[0].

My previous plan still stands; I'd like to try to solve this outside
of the packaging of rsync, if possible, but if not I will bump rsync's
dependency to libc6 >=2.32 when it gets compiled with libc6-dev 2.32.

>> Just a small correction, I see you mentioned lchown, but the issue is
>> related to l

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

[Timo Aaltonen]

On 10.10.2021 18.41, Spencer Olson wrote:
Did some more investigation.  I downloaded the packages that are being 
used on centos stream 8.  First I tried my test code with their version 
of libssl3.so preloaded:  it failed in the same way as all the others 
failed--not surprisingly since its version is much later than the 3.39 
version where this changed.


Then, I downloaded and took a look at "dogtag-submit" from the CentOS 
Stream 8 (RedHat) certmonger package.  As far as I can tell, their 
version of "dogtag-submit" is *not* linked against libcurl-nss.so at all 
like the version on debian sid.  Instead, all their certmonger helper 
programs are linked against the OpenSSL version (libcurl.so.4).


So, I think that we should just link these against the openssl version, 
as the RedHat packages do and get things to work again.


Hmm, thanks.. indeed certmonger is still built against libcurl4-nss-dev, 
I've changed it to openssl now and see how it goes against gitlab CI..



This raises two other issues:
- is there truly a bug in the ssl portion of the nss library?  If so, 
this should probably be brought to the attention.
- perhaps the libcurl package ought to be reconfigured such that one can 
install the dev packages simultaneously.  Right now, libcurl-nss also 
makes a symlink "libcurl.so" that makes it conflict with the 
libcurl-openssl package to which the "libcurl.so.x.x" lib belongs to.  I 
think that the libcurl-gnutls package might do the same thing.


My next step will be do rebuild freeipa and certmonger with the 
libcurl-openssl-dev package in place instead of the libcurl-nss-dev and 
then try reinstalling.


No need to rebuild freeipa.


--
t

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Hannes von Haugwitz]

Hi,

On Fri, Sep 24, 2021 at 02:42:07PM +0530, Charles wrote:
> I would like to adopt the logcheck package

On Thu, Sep 23, 2021 at 12:10:16PM +0100, R Lewis wrote:
> Very keen to keep logcheck in the distribution and looking to get involved
> in Debian (spare time only).
>
> happy to submit patches etc but how should that be done - to the bts or via
> salsa? will anyone review and merge things?

@Jose Do you still plan to adopt logcheck? You might want to collaborate
with Richard and Charles to maintain the package all together.

> Is there an email list to enable collaboration and discussion?

You can use the #logcheck channel on the OFTC IRC network to collaborate
and discuss logcheck with some users and previous maintainers.

Best regards

Hannes

Bug#996032: compass-blueprint-plugin: contains ruby functions

[Jonas Smedegaard]

Package: compass-blueprint-plugin
Version: 1.0.0-4
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The Blueprint stylesheets contain functions implemented in Ruby and
only loaded when used together with Compass.

Compass is dead upstream, and dropped from Debian.

These stylesheets are still useful and valuable with contemporary
Sass implementations if those few functions are re-implemented:

This:

  #{enumerate(".pull", 1, $blueprint-grid-columns)} { ... }

can be replaced by the combination of this once:

  %pull-base {

and this for each use:

  @extend %pull-base;

when used only at one place, which is the case for these stylesheets.



This:

  #{headers(all)} { ... }

can be replaced by this:

  h1, h2, h3, h4, h5, h6 { ... }


This:

  #{elements-of-type(html5-block)} { ... }

can be replaced by this:

  article, aside, details, figcaption, figure, footer, header, hgroup, main, 
menu, nav, section, summary { ... }


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFjGUQACgkQLHwxRsGg
ASE3tRAAmgKWZodOn8pGvlDZtWCIT7/29/oLs9NST3FIoWTJDg5tcvZF3u991RWg
UR+vkhI4mIqOhN/Eg4jpM38dghf6G1PxabQIrkKkC5CnaeAI3lojp+33Y7drBU1F
1wdAs30vtYWu6/yfBYXoMDY0JbFFeskvTrxcjBwVVmAbTEAHVHKpfvplyuKZZNjc
gcdS+LwCJ85DOoYH7jydsi/ybFMxOBBOhb/+5rgJbpL1oJfvpYx4bwEYRRv4PVl6
Cr2xp31bwqKD2BCTCxlmlmQK5WrbOqnOh34s+DRjLBGp2txcwMw13otcV9dswW4s
PBIavvqbS7IswevMyWgCkpS8bOBh5SES6wNzUI/rk/oMOS8p3z0yFKcgb4Xu06Rg
6FuCr7LGb24D9Wct6USacu1kAAoBtbxQatadt6r+2ElShSfPUMVKZWGFKxkiKqt2
7+TK370GGn5az3ws4qeou4Y63C0Pv8Q7YUGLYgdOirV5kfO4VzXkPA0NYGtajnc2
/sCx5re762EVt6n8iRHp/GkIIbpxHSL+0U3HAGrlpr0AAtAAxw0Fo2/SKXJiuEW5
uQ9mVvueF498EmyZ7W9lbHN56b4QIsyXkadJQOJ64+Vt6C/16XNjoci8IyxL7Wk/
oKcYXXZ6p16eS9BSui5X6/uqA9S0HR7lvrcAqzqWiCsU2COqsmQ=
=Q/hN
-END PGP SIGNATURE-

Bug#960009: postfix needs a new journalmatch parameter

[Mike Gerber]

found 960009 0.11.2-2

This bug is also affecting bullseye. The default postfix instance logs 
to _SYSTEMD_UNIT=postfix@-.service, see also 
/usr/share/doc/postfix/README.Debian.gz. Changing the journalmatch 
accordingly fixes the problem.



Workaround in terms of ansible:


- name: "fix up postfix filter journalmatch (debian)"
  lineinfile:
    path: /etc/fail2ban/filter.d/postfix.conf
    regex: '^journalmatch'
    line: 'journalmatch = _SYSTEMD_UNIT=postfix@-.service'
  when: ansible_distribution == 'Debian' or ansible_distribution == 
'Ubuntu'

  notify: restart fail2ban


Should I submit a patch?

Bug#996033: ftp.debian.org: ROM: its -- retired upstream five years ago

[Dirk Eddelbuettel]

Severity: normal
Package: its

The its package was retired from CRAN five years ago [1] upon the request of
its original author (who is a friend), but I kept it in Debian because it was
generally useful. However, as time and packaging standards move on (while the
package remains frozen) it is getting a little further away from best
practices.  So in sum, it is time to remove it from Debian.  Its sources will
remain available at CRAN in its archive/ location [2].

It has no reverse dependencies apart from a meta package that can be updated
easily.

Dirk

[1] https://cran.r-project.org/web/packages/its/index.html
[2] https://cran.r-project.org/src/contrib/Archive/its/

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

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

[Spencer Olson]

On Sun, Oct 10, 2021, 10:38 Timo Aaltonen  wrote:

> On 10.10.2021 18.41, Spencer Olson wrote:
> > Did some more investigation.  I downloaded the packages that are being
> > used on centos stream 8.  First I tried my test code with their version
> > of libssl3.so preloaded:  it failed in the same way as all the others
> > failed--not surprisingly since its version is much later than the 3.39
> > version where this changed.
> >
> > Then, I downloaded and took a look at "dogtag-submit" from the CentOS
> > Stream 8 (RedHat) certmonger package.  As far as I can tell, their
> > version of "dogtag-submit" is *not* linked against libcurl-nss.so at all
> > like the version on debian sid.  Instead, all their certmonger helper
> > programs are linked against the OpenSSL version (libcurl.so.4).
> >
> > So, I think that we should just link these against the openssl version,
> > as the RedHat packages do and get things to work again.
>
> Hmm, thanks.. indeed certmonger is still built against libcurl4-nss-dev,
> I've changed it to openssl now and see how it goes against gitlab CI..
>

Maybe the CI will finish before I can get back to my testing.


> > This raises two other issues:
> > - is there truly a bug in the ssl portion of the nss library?  If so,
> > this should probably be brought to the attention.
> > - perhaps the libcurl package ought to be reconfigured such that one can
> > install the dev packages simultaneously.  Right now, libcurl-nss also
> > makes a symlink "libcurl.so" that makes it conflict with the
> > libcurl-openssl package to which the "libcurl.so.x.x" lib belongs to.  I
> > think that the libcurl-gnutls package might do the same thing.
> >
> > My next step will be do rebuild freeipa and certmonger with the
> > libcurl-openssl-dev package in place instead of the libcurl-nss-dev and
> > then try reinstalling.
>
> No need to rebuild freeipa.
>

Yep, you are right.  I thought I had seen that freeipa had installed some
executables with linkage to libcurl-nss in /use/lib/certmonger, but i was
mistaken.

Bug#996034: ttyd: Upload to bullseye-backports

[Boyuan Yang]

Package: ttyd
Severity: normal
X-Debbugs-CC: dan...@debian.org

Dear Debian ttyd package maintainer,

I have received lots of request about using ttyd in Debian Stable. However,
package ttyd missed Debian 11. As a result, I am looking into uploading ttyd
onto bullseye-backports.

I have rebuilt 1.6.3-3 and ttyd/1.6.3+20210924-1 against bullseye-backports
and it seems that everything would work well. I guess I will upload the
package onto bullseye-backports soon, and the bpo version would most likely be
a no-change backport. According to https://backports.debian.org/Contribute/ ,
package maintenance in stable-backports is not relavant to package maintainer
in regular unstable/testing/stable/..., so I can maintain this package in
backports. If you find anything that needs coordination, please feel free to
let me know.

Thanks,
Boyuan Yang


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

Bug#995856: "sysread() isn't allowed on :utf8 handles at /usr/share/perl5/Expect.pm line 849."

[Joergen Haegg]

> JFI: the same happens with upstream 1.35;
> I could work around the problem via LC_ALL=C.

Hmm, strange. So a new version would not help.

Maybe this has some connection to your problem?
https://github.com/perl/perl5/issues/14839

Bug#810287: Error in jail.conf configuration file in [roundcube-auth] section

[neingeist]

notfound 810287 0.11.2-2

fixed 810287 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye). (There's another bug with the 
logfile path now being errors.log, not errors and this also needs a 
file-based backend, but this is not the issue here.)

Bug#996035: AttributeError: 'NoneType' object has no attribute 'section'

[Matus UHLAR - fantomas]

Package: kthresher
Version: 1.4.1-2

Hello,

kthresher does not remove old kernel, --dry-run fails with:

# kthresher --dry-run
INFO: Attempting to read /etc/kthresher.conf.
INFO: Options found: ['include'].
INFO: Valid setting found "include"
INFO:   include = /etc/kthresher.d/*.conf
INFO: Options: {'dry_run': True, 'headers': False, 'keep': 1, 'purge': False, 
'verbose': False, 'include': '/etc/kthresher.d/*.conf'}
INFO: - DRY RUN -
INFO: Running kernel is linux-image-5.10.0-9-amd64 v[5.10.70-1]
Traceback (most recent call last):
 File "/usr/bin/kthresher", line 33, in 
   sys.exit(load_entry_point('kthresher==1.4.1', 'console_scripts', 
'kthresher')())
 File "/usr/lib/python3/dist-packages/kthresher.py", line 481, in main
   kthreshing(purge=False, headers=options["headers"], keep=options["keep"])
 File "/usr/lib/python3/dist-packages/kthresher.py", line 275, in kthreshing
   section = pkg.candidate.section or ''
AttributeError: 'NoneType' object has no attribute 'section'

This is apparently caused by installed package (minecraft-launcher) that has
no Section: defined.

While I agree that the package probably should have Section: header,
I believe kthresher should not crash in such case.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Emacs is a complicated operating system without good text editor.

Bug#960009: postfix needs a new journalmatch parameter

[Sylvestre Ledru]

Le 10/10/2021 à 18:45, Mike Gerber a écrit :
> found 960009 0.11.2-2
>
> This bug is also affecting bullseye. The default postfix instance logs
> to _SYSTEMD_UNIT=postfix@-.service, see also
> /usr/share/doc/postfix/README.Debian.gz. Changing the journalmatch
> accordingly fixes the problem.
>
>
> Workaround in terms of ansible:
>
>
> - name: "fix up postfix filter journalmatch (debian)"
>   lineinfile:
>     path: /etc/fail2ban/filter.d/postfix.conf
>     regex: '^journalmatch'
>     line: 'journalmatch = _SYSTEMD_UNIT=postfix@-.service'
>   when: ansible_distribution == 'Debian' or ansible_distribution ==
> 'Ubuntu'
>   notify: restart fail2ban
>
>
> Should I submit a patch?
>
yeah go ahead and propose a MR here:

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

many thanks

S

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[Stefano Rivera]

Package: autopkgtest
Version: 5.17
Severity: normal
Tags: patch

lxd is not packaged for Debian at the moment (ITP #768073), so the
common way to install it on Debian is through snapd.

Unfortunately executing any confined snapped binaries outputs a line on
stderr:
> WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
> confinement

autopkgtest's VirtSubProc will (by default) fail if anything is emitted
to stderr, breaking the build immediately:

> : failure: ['lxc', 'launch', '--ephemeral', 
> 'autopkgtest/debian/unstable/amd64', 'autopkgtest-lxd-uqbaqs'] unexpectedly 
> produced stderr output `WARNING: cgroup v2 is not fully supported yet, 
> proceeding with partial confinement
> '
> Undefined return value after 'open'
> E: Error creating chroot session: skipping python3.10

This message can't be suppressed, as far as I am aware, so the easiest is to
just not fail when we see them.

I've been using sbuild + autopkgtest + snapped lxd successfully with this patch
for several months.
There are probably prettier ways of dealing with the problem (and even
filtering these messages from the output), but this has the benefit of being
simple.

SR

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
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 autopkgtest depends on:
ii  apt-utils   2.3.9
ii  libdpkg-perl1.20.9
ii  procps  2:3.3.17-5
ii  python3 3.9.2-3
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
ii  autodep8  0.25

Versions of packages autopkgtest suggests:
pn  fakemachine   
pn  lxc   
pn  lxd   
ii  ovmf  2020.11-5
pn  ovmf-ia32 
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:6.1+dfsg-6
ii  schroot   1.6.10-12
pn  vmdb2 

-- no debconf information
From d420aa1953b891778b57a96a53cb58774a76c6a2 Mon Sep 17 00:00:00 2001
From: Stefano Rivera 
Date: Sun, 10 Oct 2021 10:58:37 -0700
Subject: [PATCH] Ignore innoccuous warnings from snapped lxd

They don't mean that the command has failed
---
 lib/VirtSubproc.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/VirtSubproc.py b/lib/VirtSubproc.py
index bf948e6..01acdaa 100644
--- a/lib/VirtSubproc.py
+++ b/lib/VirtSubproc.py
@@ -186,6 +186,10 @@ def check_exec(argv, downp=False, outp=False, timeout=0, fail_on_stderr=True):
 if status:
 bomb("%s%s failed (exit status %d, stderr %r)" %
  ((downp and "(down) " or ""), argv, status, err))
+# Ignore innoccuous warnings from snapped lxd
+if (err == 'WARNING: cgroup v2 is not fully supported yet, proceeding with '
+   'partial confinement\n'):
+err = ''
 if fail_on_stderr and err:
 bomb("%s unexpectedly produced stderr output `%s'" %
  (argv, err))
-- 
2.33.0

Bug#946826: (no subject)

[Mike Gerber]

notfound 946826 0.11.2-2

fixed 946826 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye).

Bug#983588: xmlgraphics-commons: reproducible builds: Set timezone to UTC when SOURCE_DATE_EPOCH is set

[tony mancill]

On Fri, Oct 08, 2021 at 06:16:33PM -0700, Vagrant Cascadian wrote:
> On 2021-02-26, Vagrant Cascadian wrote:
> 
> This should fix reproducibility issues in several other packages; is
> there anything else I can do to help getting this fix into Debian?

Err.. no, this is 100% on me.  I will prepare an upload soon.

Thank you for the patch!
tony


signature.asc
Description: PGP signature

Bug#910362: fail2ban: tmpfiles.d/fail2ban-tmpfiles.conf uses /var/run instead of /run

[Mike Gerber]

notfound 910362 0.11.2-2

fixed 910362 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye).

Bug#996037: docknot: autopkgtest regression: Can't open /tmp/autopkgtest-lxc.91wiy1gt/downtmp/autopkgtest_tmp/smokenyzokG/lib/App/DocKnot.pm

[Paul Gevers]

Source: docknot
Version: 5.00-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of docknot the autopkgtest of docknot fails in
testing when that autopkgtest is run with the binary packages of docknot
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
docknotfrom testing5.00-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=docknot

https://ci.debian.net/data/autopkgtest/testing/amd64/d/docknot/15856761/log.gz

t/cli/spin.t ...
ok 1 - use App::DocKnot::Command;
ok 2 - An object of class 'App::DocKnot::Command' isa
'App::DocKnot::Command'
ok 3 - spin-thread (output specified)
ok 4 - spin-thread (standard output)
t/cli/spin.t spin: Can't open
/tmp/autopkgtest-lxc.91wiy1gt/downtmp/autopkgtest_tmp/smokenyzokG/lib/App/DocKnot.pm:
No such file or directory
cannot remove path when cwd is /tmp/siWfjiZgNP/software/docknot/api for
/tmp/siWfjiZgNP:  at /usr/lib/x86_64-linux-gnu/perl-base/File/Temp.pm
line 2616.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 29 just after 4.
Dubious, test returned 29 (wstat 7424, 0x1d00)

[...]

t/spin/tree.t ..
ok 1 - require App::DocKnot::Spin;
Can't open
/tmp/autopkgtest-lxc.91wiy1gt/downtmp/autopkgtest_tmp/smokenyzokG/lib/App/DocKnot.pm:
No such file or directory at /usr/share/perl5/App/DocKnot/Spin.pm line 318.
cannot remove path when cwd is /tmp/pjCamv3na8/software/docknot/api for
/tmp/pjCamv3na8:  at /usr/lib/x86_64-linux-gnu/perl-base/File/Temp.pm
line 2616.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.
Dubious, test returned 255 (wstat 65280, 0xff00)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996038: sphinxcontrib-httpdomain: Extension unusable due to botched patch

[Martina Ferrari]

Source: sphinxcontrib-httpdomain
Version: 1.7.0-1
Severity: grave
Justification: renders package unusable

Last year, in commit e0233aea I backported a fix to a bug in the plugin setup()
function. More recently, in commit 61f14798, the patch was refreshed
incorrectly leading to a duplicated call to add_domain, which renders the
package completely unusable (see error below).

The fix is very simple: the patch needs to be removed as the problem it
addressed  was already fixed upstream.


$ sphinx-build -v docs/ build/docs
Running Sphinx v4.2.0

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 276, in 
build_main
app = Sphinx(args.sourcedir, args.confdir, args.outputdir,
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 231, in 
__init__
self.setup_extension(extension)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 387, in 
setup_extension
self.registry.load_extension(self, extname)
  File "/usr/lib/python3/dist-packages/sphinx/registry.py", line 442, in 
load_extension
metadata = setup(app)
  File "/usr/lib/python3/dist-packages/sphinxcontrib/httpdomain.py", line 763, 
in setup
app.add_domain(HTTPDomain)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 724, in 
add_domain
self.registry.add_domain(domain, override=override)
  File "/usr/lib/python3/dist-packages/sphinx/registry.py", line 164, in 
add_domain
raise ExtensionError(__('domain %s already registered') % domain.name)
sphinx.errors.ExtensionError: domain http already registered



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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[Paul Gevers]

Hi Stefano,

On 10-10-2021 20:06, Stefano Rivera wrote:
> Unfortunately executing any confined snapped binaries outputs a line on
> stderr:
>> WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
>> confinement

Does this happen on all suites? I thought bullseye defaults to cgroup
v2, so it would surprise me a bit if it would be an error there.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996037: docknot: autopkgtest regression: Can't open /tmp/autopkgtest-lxc.91wiy1gt/downtmp/autopkgtest_tmp/smokenyzokG/lib/App/DocKnot.pm

[Russ Allbery]

Paul Gevers  writes:

> With a recent upload of docknot the autopkgtest of docknot fails in
> testing when that autopkgtest is run with the binary packages of docknot
> from unstable. It passes when run with only packages from testing. In
> tabular form:

Thanks for the report and apologies for the delay in fixing this!  There
was a test suite change that requires an additional file from the source
tree be available and I need to fix the test configuration.  Will fix this
shortly.

Thank you so much for generating these bug reports.  They're incredibly
helpful!

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

Bug#902413: systemd-tmpfiles migration warning

[Mike Gerber]

notfound 902413 0.11.2-2

fixed 902413 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye aka stable).

Bug#996040: qml-module-qtpositioning: Bogus Altitude, Direction and Speed values with geoclue2 backend

[Teemu Ikonen]

Package: qml-module-qtpositioning
Version: 5.15.2+dfsg-2
Severity: important
Tags: upstream
X-Debbugs-Cc: tpiko...@gmail.com

The Altitude, Direction and Speed values are always set to 1 in Position
values from QML PositionSource at least when running with the geoclue2
backend.

To repeat, run this QML script with `qmlscene` on system with GeoClue2
as a position source (the values below are from modem-gps GeoClue
source):

```
import QtPositioning 5.15

PositionSource {
id: src
updateInterval: 1000
active: true

onPositionChanged: {
var coord = src.position.coordinate;
var pos = src.position;
console.log("Latitude:", coord.latitude);
console.log("Longitude:", coord.longitude);
console.log("horizontalAccuracy:", pos.horizontalAccuracy,
pos.horizontalAccuracyValid);
console.log("Altitude:", coord.altitude, pos.altitudeValid);
console.log("Speed:", pos.speed, pos.speedValid);
console.log("Direction:", pos.direction, pos.directionValid);
console.log("Timestamp:", pos.timestamp);
console.log("");
}
}
```

I get this output (after getting a GPS fix):

```
qml: Latitude: 
qml: Longitude: 
qml: horizontalAccuracy: 1 true
qml: Altitude: 1 true
qml: Speed: 1 true
qml: Direction: 1 true
qml: Timestamp: Sun Oct 10 21:14:26 2021 GMT+0300
qml: 
qml: Latitude: 
qml: Longitude: 
qml: horizontalAccuracy: 1 true
qml: Altitude: 1 true
qml: Speed: 1 true
qml: Direction: 1 true
qml: Timestamp: Sun Oct 10 21:14:27 2021 GMT+0300
qml: 
qml: Latitude: 
qml: Longitude: 
qml: horizontalAccuracy: 1 true
qml: Altitude: 1 true
qml: Speed: 1 true
qml: Direction: 1 true
qml: Timestamp: Sun Oct 10 21:14:28 2021 GMT+0300
```

At the same time, the geoclue test client
`/usr/libexec/geoclue-2.0/demos/where-am-i` gives this output:

```
New location:
Latitude:
Longitude:   
Accuracy:1.00 meters
Altitude:29.10 meters
Speed:   0.026536 meters/second
Heading: 0.00°
Timestamp:   Sun Oct 10 21:14:38 2021 (1633889678 seconds since the
Epoch)

New location:
Latitude:
Longitude:   
Accuracy:1.00 meters
Altitude:28.90 meters
Speed:   0.037632 meters/second
Heading: 0.00°
Timestamp:   Sun Oct 10 21:14:39 2021 (1633889679 seconds since the
Epoch)

New location:
Latitude:
Longitude:   
Accuracy:1.00 meters
Altitude:28.20 meters
Speed:   0.014104 meters/second
Heading: 0.00°
Timestamp:   Sun Oct 10 21:14:40 2021 (1633889680 seconds since the
Epoch)

```

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

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

Versions of packages qml-module-qtpositioning depends on:
ii  libc6  2.32-4
ii  libqt5core5a   5.15.2+dfsg-12
ii  libqt5positioning5 5.15.2+dfsg-2
ii  libqt5positioning5-plugins 5.15.2+dfsg-2
ii  libqt5positioningquick55.15.2+dfsg-2
ii  libqt5qml5 [qtdeclarative-abi-5-15-2]  5.15.2+dfsg-8
ii  libqt5quick5   5.15.2+dfsg-8
ii  libstdc++6 11.2.0-8

qml-module-qtpositioning recommends no packages.

qml-module-qtpositioning suggests no packages.

-- no debconf information

Bug#990223: fixed in pcp 5.3.4-1

[Sunil Mohan Adapa]

On Thu, 07 Oct 2021 23:18:50 + Debian FTP Masters 
 wrote:

Source: pcp
Source-Version: 5.3.4-1
Done: Nathan Scott 



Unfortunately, the solution didn't seem to work. piuparts still failed 
with the latest version[1]. This is presumably because the environment 
under which piuparts has installed the package, systemd was not detected 
and the changes were still made to the configuration file.


We could either drop the changes for non-systemd systems entirely or 
patch the init.d file to pickup a newly environmental file dropped in by 
zeroconf.


Links:

1) https://piuparts.debian.org/sid/fail/pcp-zeroconf_5.3.4-1.log

--
Sunil

Bug#995957: dbconfig-common: Spews "/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead."

[Paul Gevers]

Control: tags -1 confirmed pending

Hi Guilhem,

On 08-10-2021 23:21, Guilhem Moulin wrote:
> /usr/share/dbconfig-common/internal/* (and also 
> /usr/share/dbconfig-common/dpkg/postrm)
> call which(1), which is currently deprecated.
> 
> $ rgrep -E "^[^#]*which" /usr/share/dbconfig-common
> /usr/share/dbconfig-common/internal/sqlite:which sqlite >/dev/null 
> 2>&1
> /usr/share/dbconfig-common/internal/sqlite:which sqlite3 >/dev/null 
> 2>&1
> /usr/share/dbconfig-common/internal/mysql:which mysqld >/dev/null 2>&1
> /usr/share/dbconfig-common/internal/common:if ! which 
> mysql >/dev/null; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> psql >/dev/null 2>&1; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> sqlite >/dev/null 2>&1; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> sqlite3 >/dev/null 2>&1; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> createdb >/dev/null; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> dropdb >/dev/null; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> createuser >/dev/null; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> dropuser >/dev/null; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> pg_dump >/dev/null; then
> /usr/share/dbconfig-common/internal/common:if ! which 
> mysqldump >/dev/null; then
> /usr/share/dbconfig-common/dpkg/postrm:if which ucf >/dev/null 
> 2>&1; then
> 
> Some calls void the standard error but not all.  In particular, `which mysql 
> >/dev/null;`
> causes roundcube-core.postinst to spew
> 
> /usr/bin/which: this version of `which' is deprecated; use `command -v' 
> in scripts instead.
> 
> Here is a trivial patch following the suggested workaround from the
> debianutils maintainer.

Thanks for the report. I had committed nearly the same change locally.
Can you elaborate why you removed some "2>&1" strings on top of that?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[stefanor]

Hi Paul (2021.10.10_18:38:03_+)
> > Unfortunately executing any confined snapped binaries outputs a line on
> > stderr:
> >> WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
> >> confinement
> 
> Does this happen on all suites? I thought bullseye defaults to cgroup
> v2, so it would surprise me a bit if it would be an error there.

Yes, this was happening pre-bullseye, too. (And, in fact, there were
several other issues with lxd images in bullseye that have since been
resolved, I don't know what the state is in the release.)

The issue is that snap is warning that it doesn't completely support
cgroup v2, yet. But it does work.

See #934372 etc.

SR

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

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[Paul Gevers]

Hi,

On 10-10-2021 20:51, stefa...@debian.org wrote:
> The issue is that snap is warning that it doesn't completely support
> cgroup v2, yet. But it does work.
> 
> See #934372 etc.

Shouldn't that bug be raised in severity, considering the request you
are now asking from autopkgtest? I'm not really enthusiastic to add this
kind of "work around" code for a bug that's already known for 2 years.
Maybe there should be a warning in snapd to silence that warning?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

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

[Timo Aaltonen]

On 10.10.2021 20.04, Spencer Olson wrote:



On Sun, Oct 10, 2021, 10:38 Timo Aaltonen > wrote:


On 10.10.2021 18.41, Spencer Olson wrote:
 > Did some more investigation.  I downloaded the packages that are
being
 > used on centos stream 8.  First I tried my test code with their
version
 > of libssl3.so preloaded:  it failed in the same way as all the
others
 > failed--not surprisingly since its version is much later than the
3.39
 > version where this changed.
 >
 > Then, I downloaded and took a look at "dogtag-submit" from the
CentOS
 > Stream 8 (RedHat) certmonger package.  As far as I can tell, their
 > version of "dogtag-submit" is *not* linked against libcurl-nss.so
at all
 > like the version on debian sid.  Instead, all their certmonger
helper
 > programs are linked against the OpenSSL version (libcurl.so.4).
 >
 > So, I think that we should just link these against the openssl
version,
 > as the RedHat packages do and get things to work again.

Hmm, thanks.. indeed certmonger is still built against
libcurl4-nss-dev,
I've changed it to openssl now and see how it goes against gitlab CI..


Maybe the CI will finish before I can get back to my testing.


And it did, this error is fixed now :)

But it fails later on, so there's some work still to catch up with the 
current distro, but at least this particular annoyance is resolved, so 
many thanks for figuring it out! I was sure the reason was something 
silly and related to the SSL stack (or maybe ciphers) but was blind to 
see it.



--
t

Bug#841744: fail2ban: jail.conf refers to wrong man section

[Mike Gerber]

notfound 841744 0.11.2-2

fixed 841744 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye aka stable) - the man page is now in 
section 5.

Bug#953529: Networking support in Keepassxc

[tony mancill]

On Tue, Oct 27, 2020 at 07:20:38PM -0500, Andreas Kloeckner wrote:
> So I would prefer that networking support is retained in KeepassXC, or
> if it were to be disabled, I would prefer if it were done in a separate
> package, e.g. keepassxc-nonetwork or some such.

A separate binary package would be nice, although I would prefer that
the default binary have networking disabled and users could opt-in by
installing keepassxc-netenabled (or whatever you decide to name it).

Of course, that's just my opinion.  For my systems, I always recompile
the source package with -DWITH_XC_NETWORKING=OFF.

In any event, thank you for maintaining KeePassXC.
tony


signature.asc
Description: PGP signature

Bug#995957: dbconfig-common: Spews "/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead."

[Guilhem Moulin]

Hi elbrus!

On Sun, 10 Oct 2021 at 20:52:51 +0200, Paul Gevers wrote:
> Thanks for the report. I had committed nearly the same change locally.
> Can you elaborate why you removed some "2>&1" strings on top of that?

AFAIK with some `which` implementations one wants to silence the
standard error to avoid “foobar is not found” error messages, but per
current POSIX specs 
that's not needed for `command -v`:

  -v
Write a string to standard output that indicates the pathname or
command that will be used by the shell, in the current shell
execution environment (see Shell Execution Environment), to invoke
command_name, but do not invoke command_name.
[…]
Otherwise, no output shall be written and the exit status shall
reflect that the name was not found.

AFAICT the debianutils maintainer also suggest to use `command -v foobar
>/dev/null` as replacement for `which foobar >/dev/null [2>&1]`.  Its
5.3-1 NEWS entry reads:

  * The 'which' utility will be removed in the future.  Shell scripts
often use it to check whether a command is available.  A more
standard way to do this is with 'command -v'; for example:
  if command -v update-icon-caches >/dev/null; then
update-icon-caches /usr/share/icons/...
  fi
'2>/dev/null' is unnecessary when using 'command': POSIX says "no
output shall be written" if the command isn't found.  It's also
unnecessary for the debianutils version of 'which', and hides the
deprecation warning.

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: subscribe -1

On Sun, 10 Oct 2021 16:13:29 +0200 Ondrej Zary  wrote:
> Package: mariadb-server
> Version: 1:10.3.31-0+deb10u1
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> upgrading mariadb-server from 1:10.3.29-0+deb10u1 to 1:10.3.31-0+deb10u1
failed
> because mariadb failed to start. /var/log/mysql/error.log:
> 
> 2021-10-10 15:12:49 0 [ERROR] InnoDB: corrupted TRX_NO 10002001c6986c3
> 2021-10-10 15:12:49 0 [ERROR] InnoDB: Plugin initialization aborted with
error Data structure corruption
> 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' init function returned error.
> 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE
ENGINE failed.
> 2021-10-10 15:12:50 0 [ERROR] Unknown/unsupported storage engine: InnoDB
> 2021-10-10 15:12:50 0 [ERROR] Aborting
> 
> Fortunately, it works after downgrading back to 10.3.29.
> Data does not seem to be corrupted.
> 

For what's it's worth I'm experiencing the same issue on my installation. I
took me some time to find that bug (and I started to dig how to repair innodb
stuff. Good to know downgrading should help, thanks.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFjNSIACgkQ3rYcyPpX
RFsxlQgAo0eUU9T8XaIsYIw/jx4dmbRf9DO8/IxPvFuMw0zkn7JO2LxL61IRIcAa
SDljx7UjnJpTpJ6Nc6XXQ8sU3EIb4qUen1dRME383jcUEAN0Yh3F2cvBmNkjV7bN
rDdRf74leH76uYo9sPIgWnZwy2U2I9HVKhlD3uo2MF53ksem1yVJh3Jvll5w0ZsM
SsMCO2wTjq3RFbc38bqKASSh/+UvXAxxY/6R6bxc+YIWqsim9z8XQ9TKZXdnjPS+
aOcJblZarGOjdC2AwbeT9GVaBoaCx9V9RlQDn3WoMvVhHvjfI32j+tEG1uWnicC/
q1tnUp/9oBnvt8eYDbRY3ny3oC6ylA==
=oOyd
-END PGP SIGNATURE-

Bug#996016: libreoffice: fails to send email

[Rene Engelhard]

[ please always keep the Bug in CC so that discussions about it get
recorded.

Readding. ]


Hi.

Am 10.10.21 um 20:44 schrieb Alex:
> And what is in LO settings?
> LO Settings point to /usr/lib/thunderbird

OK, as I guessed. Then anything can be in KDEs session doesn't matter.

> What if you set your mailer as xdg-email?
>
>
> That works as expected. Thanks.
>
As expected. And xdg-email knows what you want thunderbird :-)

> I just tried it: LOs default has sensible-lomua set. That one opened
>> Thunderbird in my  GNOME and happily set mail.
>>
Although best is to keep it as sensible-lomua which then runs xdg-open
>> case `basename "$MAILER"` in
>>  sensible-lomua)
>>  if [ -x /usr/bin/xdg-email ] ; then
>>  MAILER=/usr/bin/xdg-email

[...]


And as said sensible-lomua (which is the default setting in LO) is more
or less a redirection also defaulting to actually calling xdg-email anyway.


Can we close this as "user configuration error"? :)


Regards,


Rene

Bug#996041: metview: FTBFS in bookworm: unresolved symbols

[Sebastian Ramacher]

Source: metview
Version: 5.10.2-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

metview fails to build in bookworm:
| /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -std=gnu++14  -Wdate-time -D_FORTIFY_SOURCE=2 -pipe 
-fpermissive -Wno-write-strings -Wno-deprecated -Werror=return-type -O3 
-DNDEBUG -Wl,-z,relro -Wl,-z,now-Wl,--disable-new-dtags 
CMakeFiles/Eccharts.dir/Eccharts.cc.o -o ../../../bin/Eccharts  
-Wl,-rpath,/<>/debian/build/lib:/usr/lib/x86_64-linux-gnu/openmpi/lib:
 ../../../lib/libMetview.so.0.0.0 ../../../lib/libMvFTimeUtil.so.0.0.0 
../../../lib/libmarsclient.so.0.0.0 /usr/lib/x86_64-linux-gnu/libeccodes.so.0 
../../../lib/libmir.so.0.0.0 /usr/lib/x86_64-linux-gnu/libatlas_ecmwf.so.0.26 
/usr/lib/x86_64-linux-gnu/libeckit_mpi.so.0d 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so 
/usr/lib/gcc/x86_64-linux-gnu/10/libgomp.so 
/usr/lib/x86_64-linux-gnu/libpthread.so 
/usr/lib/x86_64-linux-gnu/libeckit_linalg.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit_geometry.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit_option.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit.so.0d 
/usr/lib/x86_64-linux-gnu/libeccodes.so.0 
/usr/lib/x86_64-linux-gnu/libemosR64.so 
/usr/lib/x86_64-linux-gnu/libeccodes.so.0 /usr/lib/x86_64-linux-gnu/libfftw3.so 
/usr/lib/x86_64-linux-gnu/libcurl.so -lterralib -lemosR64 -leccodes -leckit 
-leckit_option /usr/lib/x86_64-linux-gnu/libnetcdf.so 
/usr/lib/x86_64-linux-gnu/libodccore.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit_sql.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit.so.0d -lm /usr/lib/x86_64-linux-gnu/librt.so 
-lpthread -ldl 
| /usr/bin/ld: CMakeFiles/Eccharts.dir/Eccharts.cc.o: in function 
`MvMacroCallerService::registerCallbacks()':
| ./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:50: 
undefined reference to `add_progress_callback'
| /usr/bin/ld: 
./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:50: 
undefined reference to `add_progress_callback'
| /usr/bin/ld: 
./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:53: 
undefined reference to `add_reply_callback'
| /usr/bin/ld: CMakeFiles/Eccharts.dir/Eccharts.cc.o: in function 
`Eccharts::generateData(MvRequest const&, MvRequest&, 
std::__cxx11::basic_string, std::allocator > 
const&, std::__cxx11::basic_string, 
std::allocator > const&, bool)':
| ./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:364: 
undefined reference to `svc_connect'
| /usr/bin/ld: 
./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:365: 
undefined reference to `process_service'
| /usr/bin/ld: CMakeFiles/Eccharts.dir/Eccharts.cc.o: in function 
`MvMacroCallerService::registerCallbacks()':
| ./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:53: 
undefined reference to `add_reply_callback'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`get_svc_msg'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`create_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`exit_timeout'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`record_function'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`set_svc_err'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`wait_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_fetch'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`recording'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`call_function'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`get_svc_err'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`send_progress'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_link_objects'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`set_maximum'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`send_later'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`destroy_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_link'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`get_svc_ref'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_store'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`send_message'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`call_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`add_service_callback'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`keep_alive'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`re_dispatch'
| /usr/bin/ld: ../../../lib/l

Bug#992675: resynthesizer missing in bullseye

[Udo Richter]

Even more, the current 20200927 version claims in the changelog that
resynthesizer was ported to python3, but its missing entirely.

Bug#996014: transition: orocos-kdl

[Sebastian Ramacher]

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

On 2021-10-10 10:36:09 +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> I would like to transition orocos-kdl. The auto generated ben file looks
> fine and I've rebuild all reverse dependencies successfully.

Please go ahead

Cheers

> 
> Cheers Jochen
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#994391: Acknowledgement (vdirsyncer is unusable)

[gregor herrmann]

On Wed, 06 Oct 2021 20:17:35 +0200, Vincent-Xavier JUMEL wrote:

> I've upgraded click-threading to 0.5.0 and vdirsyncer works again.
> Should I fill a bugreport against python3-click-threading ?

I got the same error [0] today, after upgrading python3-click from
7.1.2-1 to 8.0.2-1 in unstable.

Reverting to the older version in testing helps.

(python3-click-threading is at 0.4.4-2 since forever.)

Cheers,
gregor

 
[0]
% /usr/bin/vdirsyncer -vdebug sync 
debug: Using 1 maximal workers.
error: Unknown error occurred: unmatched ')' (, line 1)
error: Use `-vdebug` to see the full traceback.
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
30, in inner
debug: f(*a, **kw)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
145, in sync
debug: with wq.join():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/utils.py", line 
364, in join
debug: with ui_worker.patch_click():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/__init__.py", 
line 144, in patch_click
debug: with patch_ui_functions(wrapper):
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/monkey.py", line 
50, in patch_ui_functions
debug: stub_f = eval('lambda {s}: {n}._real_click_fn({a})'

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Pat Metheny, B.B. King, Dave Brubeck: Pat Metheny & Heath Brothers /


signature.asc
Description: Digital Signature

Bug#994416: transition: urdfdom

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2021-10-05 00:27:53 +0200, Jose Luis Rivero wrote:
> On Sun, Sep 19, 2021 at 6:10 PM Sebastian Ramacher 
> wrote:
> 
> > The automatically generated tracker at
> > https://release.debian.org/transitions/html/auto-console-bridge.html
> > detects more reverse dependencies. Do those also build fine with the new
> > version of console-bridge?
> >
> 
> Thanks Sebastian for pointing that out. I've fixed ceres-solver in the
> testing server and now it builds many more packages, I think all the ones
> in the auto transition slot are ready:
> 
> 2021/10/04 22:25:04 Build results:
> 2021/10/04 22:25:04 PASSED: ros-rviz
> 2021/10/04 22:25:04 PASSED: ros-geometric-shapes
> 2021/10/04 22:25:04 PASSED: ros-opencv-apps
> 2021/10/04 22:25:04 PASSED: urdfdom
> 2021/10/04 22:25:04 PASSED: ros-resource-retriever
> 2021/10/04 22:25:04 PASSED: ros-navigation-msgs
> 2021/10/04 22:25:04 PASSED: ros-image-pipeline
> 2021/10/04 22:25:04 PASSED: ros-geometry
> 2021/10/04 22:25:04 PASSED: ros-common-msgs
> 2021/10/04 22:25:04 PASSED: ros-vision-opencv
> 2021/10/04 22:25:04 PASSED: ros-urdf
> 2021/10/04 22:25:04 PASSED: ros-roscpp-core
> 2021/10/04 22:25:04 PASSED: ros-image-common
> 2021/10/04 22:25:04 PASSED: ros-actionlib
> 2021/10/04 22:25:04 PASSED: ros-class-loader
> 2021/10/04 22:25:04 PASSED: ros-bond-core
> 2021/10/04 22:25:04 PASSED: ros-rosconsole-bridge
> 2021/10/04 22:25:04 PASSED: ros-pluginlib
> 2021/10/04 22:25:04 PASSED: ros-diagnostics
> 2021/10/04 22:25:04 PASSED: ros-interactive-markers
> 2021/10/04 22:25:04 PASSED: ros-perception-pcl
> 2021/10/04 22:25:04 PASSED: ros-rosconsole
> 2021/10/04 22:25:04 PASSED: mrpt
> 2021/10/04 22:25:04 PASSED: ros-pcl-msgs
> 2021/10/04 22:25:04 PASSED: ros-robot-state-publisher
> 2021/10/04 22:25:04 PASSED: ros-ros-comm
> 2021/10/04 22:25:04 PASSED: ros-laser-geometry
> 2021/10/04 22:25:04 PASSED: ros-dynamic-reconfigure
> 2021/10/04 22:25:04 PASSED: sdformat
> 2021/10/04 22:25:04 PASSED: ros-ros-comm-msgs
> 2021/10/04 22:25:04 PASSED: ros-nodelet-core
> 2021/10/04 22:25:04 PASSED: ros-geometry2
> 2021/10/04 22:25:04 PASSED: ros-collada-urdf
> 2021/10/04 22:25:04 PASSED: ros-kdl-parser
> 
> https://build.osrfoundation.org/job/debian-ratt-builder/110/console
> 
> Let me know if you see other problems.

Please go ahead

Cheers

> 
> 
> 
> >
> > Cheers
> >
> > >
> > > Ben file:
> > >
> > > title = "urdfdom";
> > > is_affected = .depends ~ "libconsole-bridge0.4" | .depends ~
> > "libconsole-bridge1.0";
> > > is_good = .depends ~ "libconsole-bridge1.0";
> > > is_bad = .depends ~ "libconsole-bridge0.4";
> > >
> > > Thanks!
> > >
> >
> > --
> > Sebastian Ramacher
> >

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996042: Missing sources for the html part

[Shengjing Zhu]

Package: ttyd
Version: 1.6.3+20210924-1
Severity: serious
X-Debbugs-Cc: z...@debian.org

+ src/html.h is not the preferred source format, it's generated by the source
  in html/ dir.

+ source in html/ dir is not completed, all devDependencies and dependencies
  listed in html/package.json is not provided.

Bug#992668: ricochet-im: does not start

[Sebastian Ramacher]

Control: reopen -1

On 2021-09-21 13:08:16 +0800, Paul Wise wrote:
> Control: fixed -1 + 1.1.4-3+b5
> 
> On Sat, 18 Sep 2021 13:06:25 +0800 Paul Wise wrote:
> 
> > I'll request the release team to rebuild it in bullseye/bookworm.
> 
> The rebuild has now happened for unstable/testing.

While I initially scheduled these binNMUs, I no longer think that this
was the correct "fix" for this bug. There is at least the issue that
ricochet-im links with ubsan which is potentially a security issue. See
https://www.openwall.com/lists/oss-security/2016/02/17/9 (thanks to
aurel32 for the link)

And then the question remains if libubsan broke its ABI or broken code
was generated before GCC 10 or …

Cheers

> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996044: dpkg: Print message about possible cause of local changes detected (changelog bump required)

[Samuel Henrique]

Package: dpkg
X-Debbugs-Cc: samuel...@debian.org
Severity: wishlist
Tags: patch

Multiple times I had to help newcomers when they were working with gbp
and importing a new upstream release, they would usually hit the
error:
"
dpkg-source: info: local changes detected, the modified files are:
...
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/...
E: Failed to package source directory ...
"

This happened due to them forgetting to update the version in
d/changelog after importing the new release.

It would be nice if among the errors there was a message suggesting
that the issue could have been caused by that, I believe this would
help many newcomers working with gbp.

The current message already states which version dpkg is trying to
build, so one ~could~ understand what's the issue when noticing that
the previous release is there, in reality I've seen so many people
miss that (myself included) that I think having this extra info
message will be worthy.

Path attached.

Thank you

--
Samuel Henrique 
From 4427ecc3cea40e2c3a407dbcb8a42dbe45a49d73 Mon Sep 17 00:00:00 2001
From: Samuel Henrique 
Date: Sun, 10 Oct 2021 20:43:18 +0100
Subject: [PATCH] Add info message about possible cause of local changes
 detected

 When working with gbp, this issue is usually caused by
 a new upstream release being imported while missing to
 bump the version in d/changelog.
---
 scripts/Dpkg/Source/Package/V2.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/Dpkg/Source/Package/V2.pm b/scripts/Dpkg/Source/Package/V2.pm
index 05dd3ba64..18f4a9d1c 100644
--- a/scripts/Dpkg/Source/Package/V2.pm
+++ b/scripts/Dpkg/Source/Package/V2.pm
@@ -559,6 +559,8 @@ sub do_build {
 unless (-z $tmpdiff or $self->{options}{auto_commit}) {
 info(g_('you can integrate the local changes with %s'),
  'dpkg-source --commit');
+info(g_('this could also have been caused by importing a new upstream ' .
+'release while forgetting to bump the version in d/changelog'));
 error(g_('aborting due to unexpected upstream changes, see %s'),
   $tmpdiff);
 }
-- 
2.33.0

Bug#982823: #982823 debian-faq: [INTL:pt] Partial Portuguese translation

[Holger Wansing]

Américo Monteiro  wrote (Date: Sun, 14 Feb 2021 22:12:02 
UTC):
> I was working on this translation when it was removed from po4a translation 
> requests... 
> 
> I don't know were this translation was moved to, but as I got half work done 
> here, you might want 
> to merge my strings (half work) into the package and somebody else can finish 
> it...
> 
> or you can put the package back in po4a so I can finish my work
> 
> Feel free to use this file.

There has been a conversion to split the different chapters into separate
po files, but po format is still the used translation format.

I have merged the file you provided into the numerous po files for Portuguese;
maybe you want to continue translation work this way?

https://salsa.debian.org/ddp-team/debian-faq/-/commit/bcf2d20623428390ee31b74b1ab3629e27aa7e6c


Holger



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

Bug#982823: #982823 debian-faq: [INTL:pt] Partial Portuguese translation

[Holger Wansing]

Control: tags -1 + pending

Pushed into git, tagging bug as pending


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

Bug#995934: python-gevent: diff for NMU version 20.9.0-2.1

[Sandro Tosi]

On Sun, Oct 10, 2021 at 7:26 AM László Böszörményi (GCS)  
wrote:
>
> On Sat, Oct 9, 2021 at 7:25 AM Sandro Tosi  wrote:
> > On Fri, Oct 8, 2021 at 3:12 PM László Böszörményi (GCS)  
> > wrote:
> > >  I can't devote enough time to this package. Feel free any of you
> > > taking this package to the Python Team and maintain it there.
> >
> > I can help maintain this package, just because I maintain one of its
> > rdeps. Do you have a git repo you're using to package python-gevent?
> > if so, we can migrate that under
> > https://salsa.debian.org/python-team/packages (if not, we're going to
> > create it from the source packages).
>  Long story short, I don't have one.

no worries, i've created a git repo from the debian snapshot history
at https://salsa.debian.org/python-team/packages/python-gevent and
will make and upload momentarily to fix the metadata and such

> > Do you still want to be in the Uploaders list?
>  It's up to your decision. I can't devote time to the package. You can
> put me there, but don't expect much work.

Sounds good, I think it's nice to maintain continuity; if in the long
run it's more noisy on your DDPO page or similar we can revisit

> > since we're talking about this, did you give it a thought if you want
> > to start maintaining your other python packages under the DPT
> > umbrella?
>  Will think about it and let you know soon, sending separate emails about 
> those.

Thanks even just for considering it

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

Bug#996045: gnome-shell-extension-arc-menu: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-arc-menu
Version: 49-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996046: gnome-shell-extension-autohidetopbar: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-autohidetopbar
Version: 20210525-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996047: gnome-shell-extension-bluetooth-quick-connect: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-bluetooth-quick-connect
Version: 23-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL

[Paul Gevers]

Source: postfix-mta-sts-resolver
Version: 1.0.0-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ca-certificates

[X-Debbugs-CC: debian...@lists.debian.org,
ca-certifica...@packages.debian.org]

Dear maintainer(s),

With a recent upload of ca-certificates the autopkgtest of
postfix-mta-sts-resolver fails in testing when that autopkgtest is run
with the binary packages of ca-certificates from unstable. It passes
when run with only packages from testing. In tabular form:

 passfail
ca-certificates  from testing20211004
postfix-mta-sts-resolver from testing1.0.0-4
all others   from testingfrom testing

I copied some of the output at the bottom of this report. The *warning*
seems to be innocent, but causes the test to fail because by default
autopkgtest considers output on stderr as fatal (without the
allow-stderr restriction).

Currently this regression is blocking the migration of ca-certificates
to testing [1]. Of course, ca-certificates shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in ca-certificates was intended and your package needs to update
to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from ca-certificates should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ca-certificates

https://ci.debian.net/data/autopkgtest/testing/amd64/p/postfix-mta-sts-resolver/15856707/log.gz

autopkgtest [19:39:52]: test run: [---
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain
exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
autopkgtest [19:40:04]: test run: ---]
autopkgtest [19:40:04]: test run:  - - - - - - - - - - results - - - - -
- - - - -
run  FAIL stderr: rehash: warning: skipping
ca-certificates.crt,it does not contain exactly one certificate or CRL



OpenPGP_signature
Description: OpenPGP digital signature