Bug#1016069: ceph: CVE-2022-0670

[Thomas Goirand]

On 7/27/22 09:13, Thomas Goirand wrote:

On 7/26/22 13:16, Moritz Mühlenhoff wrote:

Source: ceph
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for ceph.

CVE-2022-0670[0]:
| A flaw was found in Openstack manilla owning a Ceph File system
| "share", which enables the owner to read/write any manilla share or
| entire file system. The vulnerability is due to a bug in the "volumes"
| plugin in Ceph Manager. This allows an attacker to compromise
| Confidentiality and Integrity of a file system. Fixed in RHCS 5.2 and
| Ceph 17.2.2.

https://ceph.io/en/news/blog/2022/v17-2-2-quincy-released/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0670
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0670

Please adjust the affected versions in the BTS as needed.



Hi Moritz,

If I'm not mistaking, this security hole is only in the 16.2.x series of 
Ceph, right? I'll upgrade to 16.2.10 immediately. Please let me know 
about Ceph in Bullseye.


Cheers,

Thomas Goirand (zigo)


Oh... now I have the problem that Ceph FTBFS with GCC 12... :/
I'll let you know when I can get this fixed.

Cheers,

Thomas Goirand (zigo)

Bug#986204: (no subject)

[Guilherme de Paula Xavier Segundo]

Hi Sakirnth,

I would like to know if you are still interested in packaging molecule
for Debian?

If not, I could pack it if you agree.

I think it would be really cool to have this package in the next
versions of Debian besides being used a lot.

Thank you and congratulations for the work,
Guilherme Xavier


signature.asc
Description: PGP signature

Bug#570623: reprepro: please add multiple version management

[Bastian Germann]

I am about to upload an experimental version with Benjamin's changes.
Please open new bugs for the issues that you may have with the new version even 
if they are already mentioned here.

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Mark Hindley]

Control: close -1

Ansgar,

On Mon, Jul 25, 2022 at 09:02:09PM +0200, Ansgar wrote:
> On Mon, 25 Jul 2022 13:05:02 +0100 Mark Hindley wrote:
> > It has been suggested that changing the dependency to
> > 
> >  systemd-standalone-tmpfiles | systemd-tmpfiles
> > 
> > would help the packaging system usually find the correct solution and 
> > reduce the
> > number of unexpected surprises users are reporting.
> 
> This change breaks debootstrap as expected:
> 
> +---
> | W: Failure while installing base packages.  This will be re-attempted up to 
> five times.
> | W: See /tmp/u/unstable/debootstrap/debootstrap.log for details (possibly 
> the package 
> /var/cache/apt/archives/systemd-standalone-tmpfiles_251.3-1_amd64.deb is at 
> fault)
> +---
> 
> I hope this addresses the question for "evidence and rationale of this
> concern" why I say this is problematic.

I assume this is the result of running debootstrap with --include
systemd-standalone-tmpfiles?

> > With this change, on a systemd installation the dependency would already be
> > satisfied and therefore noop for APT. For installations without systemd, be 
> > that
> > systems using other inits or in containers, APT would choose the standalone
> > implementation.
> 
> You state this as a fact, but it is sadly false. See prior discussions
> about systemd-shim which had similar problems and caused various
> problems even after removal from the archive (because conffiles). (I'm
> too lazy to look this up for another repeat of this argument, after all
> it is your claim; I already wasted too much time on the test above.)

I am sorry that my lack of experience and familiarity with the internals and
history of debootstrap causes such exasperation to you. Perhaps you could find a
way to disseminate your considerable knowledge and experience in a more graceful
way?

Thanks anyway. I withdraw my suggestion.

Best wishes.

Mark

Bug#1016098: live-build: Add support for building bookworm ISOs in Debian/Buster?

[Petter Reinholdtsen]

Package: live-build
Version: 1:20190311
Severity: wishlist

For historical reasons, it would be very useful for the LinuxCNC
community to be able to build recent live ISOs using Debian/Buster
machines.  It would be great if it was possible to build Debian/Bookworm
images on oldstable.  The two fixes required, as far as I can tell, is a
symlink in /usr/share/live/build/data/debian-cd/ from bookworm to
squeeze, and editing /usr/lib/live/build/installer_debian-installer to
drop lilo from DI_REQ_PACKAGES.

Would it be possible to get a fix for this into oldstable?  I guess LTS
is the most likely path for such fix.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1015898: ITP: FoxDot -- Live Coding with Python

[Igor Garcia]

As a FoxDot user I totally support this initiative and I'm willing to 
help out in whatever is needed!


Igor Garcia

Bug#1016107: RFS: dh-nss/1 [ITP] -- debhelper addon to inject NSS services into /etc/nsswitch.conf

[Gioele Barabucci]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-nss":

 * Package name: dh-nss
   Version : 1
   Upstream Author : Gioele Barabucci
 * URL : https://salsa.debian.org/gioele/dh-nss
 * License : ISC
 * Vcs : https://salsa.debian.org/gioele/dh-nss
   Section : devel
 * ITP : https://bugs.debian.org/1016100

The source builds the following binary packages:

  dh-nss - debhelper addon to inject NSS services into /etc/nsswitch.conf

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


  https://mentors.debian.net/package/dh-nss/

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

  dget -x https://mentors.debian.net/debian/pool/main/d/dh-nss/dh-nss_1.dsc

Changes for the initial release:

 dh-nss (1) unstable; urgency=medium
 .
   * Initial release (Closes: #1016100)

Regards,

--
Gioele Barabucci

Bug#1008369: scikit-learn testing migration

[Andreas Tille]

Control: tags -1 unreproducible
Control: tags -1 moreinfo
Control: severity -1 important

Hi,

BTW, there is another bug in scikit-learn, but I can't reproduce it and
have set tags accordingly.  Could someone else please give it a try?

Kind regards

 Andreas.

Am Wed, Jul 20, 2022 at 09:23:28PM +0200 schrieb Andreas Tille:
> Hi Nilesh,
> 
> Am Wed, Jul 20, 2022 at 06:21:19PM +0530 schrieb Nilesh Patra:
> > On 7/20/22 4:50 PM, Andreas Tille wrote:
> > > Before we stop progress in Debian for many other architectures since we
> > > cant't solve this on our own or otherwise are burning patience of
> > > upstream I'd alternatively consider droping armel as supported
> > > architecture.
> > 
> > I am definitely +1 for this, however scikit-learn is a key package and 
> > dropping
> > it from armel would mean dropping several revdeps as well.
> > I am a bit unsure if that is fine or not.
> 
> Its not fine at all and I would not be happy about it.  However, the other
> side of a key package is, that lots of package have testing removal warnings
> on architectures which are widely used and we have real trouble because of
> this.
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#1012096: RFS: tractor/3.13-1 [ITP] -- Setup an onion routing proxy

[دانیال بهزادی]

I changed the Description and fixed Depends, pushed it to Salsa and 
uploded the new package to Mentors.

Danial Behzadi

Bug#1016099: python3-pudb: Missing urwid_readline package

[Michael Fladischer]

Package: python3-pudb
Version: 2022.1.2-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

version 2022.1.2 introduced a new dependency on urwid_readline[0] which has not
been packaged for Debian:

Traceback (most recent call last):
  File "/usr/bin/pudb3", line 33, in 
sys.exit(load_entry_point('pudb==2022.1.2', 'console_scripts', 
'pudb3')())
  File "/usr/lib/python3/dist-packages/pudb/run.py", line 65, in main
runscript(mainpyfile, **options_kwargs)
  File "/usr/lib/python3/dist-packages/pudb/__init__.py", line 109, in 
runscript
dbg = _get_debugger(steal_output=steal_output)
  File "/usr/lib/python3/dist-packages/pudb/__init__.py", line 85, in 
_get_debugger
dbg = Debugger(**kwargs)
  File "/usr/lib/python3/dist-packages/pudb/debugger.py", line 194, in 
__init__
self.ui = DebuggerUI(self, stdin=stdin, stdout=stdout, 
term_size=term_size)
  File "/usr/lib/python3/dist-packages/pudb/debugger.py", line 830, in 
__init__
import urwid_readline
ModuleNotFoundError: No module named 'urwid_readline'


Regards,
Michael



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

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

Versions of packages python3-pudb depends on:
ii  dpkg   1.21.9
ii  python33.10.5-3
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-pygments   2.12.0+dfsg-2
ii  python3-urwid  2.1.2-2+b2

python3-pudb recommends no packages.

Versions of packages python3-pudb suggests:
ii  ipython3  7.31.1-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmLg/KwRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrVLwf9HvFBN0+LUFo/Zlj4GhiqZwyaDCZh2ABo
A6eEvQcteWJl+XiJ+UI8YB6H93CppaGx87Y10q3RxnjYOvycwXtYn7AYkHA6oMwW
egINJPrs8yqd4tqZpwPLsb3w3AuI4BIGH8Pu/XQdTYMeP0R79Qvwgn6FyosbPMQz
VcYwwYaDj1WdXF0JsRLWjR9NS1pNFt6em1Ss68H8xIfTPSU8rygey7P1Vuzt8ble
o0zrRV8JpyKOjun99/6UJhtMILItB31k06llcJY7i57ZSWY3ePpuqykwekLKDPRA
XE1IFobKnRT9jlMyCzDMpXrKwaU9zjLBCogtiQrqxZKnc1QSKQRkuQ==
=kCV9
-END PGP SIGNATURE-

Bug#1016100: ITP: dh-nss -- debhelper addon to inject NSS services into /etc/nsswitch.conf

[Gioele Barabucci]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debhel...@packages.debian.org

* Package name: dh-nss
  Version : 1
  Upstream Author : Gioele Barabucci
* URL : https://salsa.debian.org/gioele/dh-nss
* License : ISC
  Description : debhelper addon to inject NSS services into 
/etc/nsswitch.conf


The creation of this package has been suggested in 
https://salsa.debian.org/debian/debhelper/-/merge_requests/73


The package will Provide `dh-sequence-installnss` until `dh_installnss` 
is deemed stable enough to be added to debhelper.


From the README:

The` dh_installnss` debhelper provides a declarative way for NSS-related 
packages to express how the NSS services they supply should be installed 
and in which order.


--
Gioele Barabucci

Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

[Peter Blackman]

Package: duma
Tags: hurd, ftbfs, confirmed, help
Usertags: debian-h...@lists.debian.org
X-Debbugs-Cc: debian-h...@lists.debian.org


duma compiles & links on Hurd, but self tests fail.
https://buildd.debian.org/status/package.php?p=duma


Testing via KVM, shows that all tests except for thread-test,
fail with output 'Killed'.

Back trace on dumatest shows an endless loop. Repeats every ten steps.


=

Starting program: /home/demo/duma-2.5.21/dumatest

Thread 4 received signal ?, Unknown signal.
0x010b9415 in ?? () from /lib/i386-gnu/libc.so.0.3
#0  0x010b9415 in ?? () from /lib/i386-gnu/libc.so.0.3
#1  0x010b812a in dcgettext () from /lib/i386-gnu/libc.so.0.3
#2  0x010b7452 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#3  0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#4  0x08036095 in lock () at sem_inc.c:135
#5  0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#6  0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
    fillByte=255, protectAllocList=1, allocator=EFA_MALLOC, #49 0x01103ce5 in 
?? () from /lib/i386-gnu/libc.so.0.3
#7  0x080353b6 in _duma_malloc (size=100,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1970
#8  0x08035c8b in malloc (size=100) at duma.c:2424
#9  0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#10 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#11 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#12 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#13 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#14 0x08036095 in lock () at sem_inc.c:135
#15 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#16 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
    fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
    fail=DUMA_FAIL_ENV,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1386
#17 0x080353b6 in _duma_malloc (size=100,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1970
#18 0x08035c8b in malloc (size=100) at duma.c:2424
#19 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#20 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#21 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#22 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#23 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#24 0x08036095 in lock () at sem_inc.c:135
#25 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#26 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
    fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
    fail=DUMA_FAIL_ENV,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1386
#27 0x080353b6 in _duma_malloc (size=100,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1970
#28 0x08035c8b in malloc (size=100) at duma.c:2424
#29 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#30 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#31 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#32 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#33 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#34 0x08036095 in lock () at sem_inc.c:135
#35 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#36 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
    fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
    fail=DUMA_FAIL_ENV,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1386
#37 0x080353b6 in _duma_malloc (size=100,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1970
#38 0x08035c8b in malloc (size=100) at duma.c:2424
#39 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#40 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#41 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#42 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#43 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#44 0x08036095 in lock () at sem_inc.c:135
#45 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#46 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
    fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
    fail=DUMA_FAIL_ENV,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1386
#47 0x080353b6 in _duma_malloc (size=100,
    filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:1970
#48 0x08035c8b in malloc (size=100) at duma.c:2424

===


I'm curious about the step   pthread_self ()  -->  __assert_fail ()

The man page for pthread_self (Linux)
https://man7.org/linux/man-pages/man3/pthread_self.3.html

states that the function always succeeds. Unlikely if it throws an assert.


Also raised upstream

Bug#1016108: RFP: minuimus -- file optimiser utility script

[Lev Lamberov]

Package: wnpp
Severity: wishlist

* Package name: minuimus
  Version : 3.5.1
  Upstream Author : Codebird aka CorvusRidiculissimus 

* URL : https://birds-are-nice.me/software/minuimus.html
* License : GPL-3
  Programming Lang: C, Perl
  Description : file optimiser utility script

Minuimus is a file optimiser utility script: You point it at a file,
and it makes the file smaller without compromising the file contents.
File optimisers are able to do this using a variety of file-specfic
optimisations, most of which involve decompressing data within a
compressed file and recompressing it in a more efficient manner. The
process could be compared directly to extracting a ZIP file, then
recompressing it at the most demanding setting. It uses many of the
same techniques used by other optimisers such as Papa's Best
Optimizer.

The exact space saving achieved by this level of file optimisation is
highly dependent upon the file being optimised. As is expected for any
file optimiser, even after extensive testing, the results are too
inconsistent to easily quantify. A collection of PDF files sampled
from the-eye.eu was reduced in size to 90% of the input, while a
half-terabyte sample taken from the archive.org 'computermagazine'
collection was reduced with greater success to 78% of the input size.
A collection of epub files from Project Gutenberg was reduced to a
mere 95%, as these files are light on images, and ZIP files with no
files inside which can be recursively optimised are reduced only very
slightly, typically to around 97%.

Bug#1016109: new upstream (2.2.0)

[Daniel Baumann]

Package: isc-kea

Hi,

kea 2.2.0 was released a couple of days ago, it would be nice if you
could upgrade the package in experimental.

Regards,
Daniel

Bug#1016101: stem/prereq.py:142: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead

[Paul Wise]

Package: python3-stem
Version: 1.8.0-3.1
Severity: minor
File: /usr/lib/python3/dist-packages/stem/prereq.py
Usertags: warnings

When using onionprobe to check the planet.d.o onion service, stem
causes the cryptography Python module to emit a deprecation warning
about int_from_bytes being replaced by int.from_bytes. Currently this
doesn't seem to have any effect with python3-cryptography 3.4.8-2 but
when Debian switches to the Rust based versions it might cause errors.

$ onionprobe -e 3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion
2022-07-27 17:55:05,987 INFO: Starting Onionprobe version 1.0.0...
2022-07-27 17:55:05,988 INFO: Initializing Tor process...
2022-07-27 17:55:24,249 INFO: Onionprobe is initialized. Hit Ctrl-C to 
interrupt it.
2022-07-27 17:55:24,249 INFO: Processing 
3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion...
2022-07-27 17:55:24,249 INFO: Trying to get descriptor for 
3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion (attempt 1)...
/usr/lib/python3/dist-packages/stem/prereq.py:142: 
CryptographyDeprecationWarning: int_from_bytes is deprecated, use 
int.from_bytes instead
  from cryptography.utils import int_from_bytes, int_to_bytes
2022-07-27 17:55:28,826 INFO: Elapsed time: 0:00:04.577173
2022-07-27 17:55:28,827 INFO: Trying to connect to 
http://3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion:80/ 
(attempt 1)...
2022-07-27 17:55:44,421 INFO: Trying to connect to 
http://3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion:80/ 
(attempt 2)...
2022-07-27 17:55:51,158 INFO: Trying to connect to 
http://3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion:80/ 
(attempt 3)...
2022-07-27 17:55:56,799 INFO: Trying to connect to 
http://3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion:80/ 
(attempt 4)...
2022-07-27 17:56:00,176 ERROR: Error querying 
3cbzkrvakrpetjjppdwzbzqrlkmzatjs7jbyazap5gwutj32gcltjpqd.onion
2022-07-27 17:56:00,177 INFO: Error while receiving a control message 
(SocketClosed): received exception "read of closed file"

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python3-stem depends on:
ii  python3  3.10.5-3

python3-stem recommends no packages.

python3-stem suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1015913: /usr/share/perl5/Config/Model/models/Dpkg/Control.pl: failure applying Dpkg::Control fixes when current directory is single character

[Dominique Dumont]

On Monday, 25 July 2022 10:19:18 CEST you wrote:
> I guess I can tweak the formula
> l30  to return undef when the match regex (L35) cannot be satisfied.

Which uncovered a bug in libconfig-model-perl. Fixing this bug will also 
require libconfig-model-perl 2.151

All the best

Bug#1016102: rsync: The --remove-source-files destroys data when source & destination are the same (data loss!)

[anonymous coward]

Package: rsync
Version: 3.2.3-4+deb11u1
Severity: critical
Justification: causes serious data loss
X-Debbugs-Cc: debbug.rs...@sideload.33mail.com

I accidentally ran:

  $ rsync -va --progress --remove-source-files "$dir_with_many_files" 
"$dir_with_many_files"

Due to a typo when using bash history substitution, the source and
destination were both directories and they both named the same
directory.

The expectation is that rsync should detect movement from A to A and
do nothing apart from warning the user that there is nothing to do.
Instead, because of the “--remove-source-files” option, rsync DESTROYS
all the files in "$dir_with_many_files" irrevokably.

There needs to be a safeguard that prevents --remove-source-files from
having effect if:

 * Files are not copied to the destination (for any reason)
 * The source and destination are the same

I suffered data loss because of this.  At the very least, if it’s
really intended for “rsync --remove-source-files $A $A” to effectively
behave like “rm -rf $A/*”, there AT LEAST needs to be a very loud
warning prompting the user for confirmation. But I conjecture that there
never is a legit scenario where “rsync --remove-source-files” simply
destroys files without safely ensuring they exist somewhere in the
end.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages rsync depends on:
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-10
ii  libc62.31-13+deb11u3
ii  liblz4-1 1.9.3-2
ii  libpopt0 1.18-2
ii  libssl1.11.1.1n-0+deb11u3
ii  libxxhash0   0.8.0-2
ii  libzstd1 1.4.8+dfsg-2.1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:8.4p1-5+deb11u1
ii  openssh-server  1:8.4p1-5+deb11u1
ii  python3 3.9.2-3

-- no debconf information

Bug#1016104: /usr/bin/wireplumber: wireplumber: crashes at logon

[Mihai]

Package: wireplumber
Version: 0.4.11-1
Severity: normal
File: /usr/bin/wireplumber
X-Debbugs-Cc: quake2i...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Updated current Bookwork installation

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

   * What was the outcome of this action?
wireplumber crahes at logon, is reproducible on two very different systems.

   * What outcome did you expect instead?
No crash.

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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.64
ii  libc6 2.33-8
ii  libglib2.0-0  2.72.3-1
ii  libpipewire-0.3-0 0.3.56-1
ii  libwireplumber-0.4-0  0.4.11-1
ii  pipewire  0.3.56-1

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.56-1

Versions of packages wireplumber suggests:
pn  libspa-0.2-bluetooth  

-- no debconf information

Please let me know if you require something different from the crash.

#0  0x7f3d50790e55 in on_got_bus (obj=, res=0x7f3d44003c00, 
data=data@entry=0x560c5c61cf30) at ../lib/wp/dbus.c:65
Download failed: Invalid argument.  Continuing without source file 
./obj-x86_64-linux-gnu/../lib/wp/dbus.c.
65  ../lib/wp/dbus.c: No such file or directory.
[Current thread is 1 (Thread 0x7f3d4fd7d580 (LWP 2371))]
(gdb) bt full
#0  0x7f3d50790e55 in on_got_bus (obj=, res=0x7f3d44003c00, 
data=data@entry=0x560c5c61cf30) at ../lib/wp/dbus.c:65
transition = 0x560c5c61cf30
self = 0x0
error = 0x0
__func__ = "on_got_bus"
#1  0x7f3d501e1fa9 in g_task_return_now (task=task@entry=0x7f3d44003c00) at 
../../../gio/gtask.c:1230
No locals.
#2  0x7f3d501e1fe9 in complete_in_idle_cb (task=0x7f3d44003c00) at 
../../../gio/gtask.c:1244
No locals.
#3  0x7f3d50630eb4 in g_main_dispatch (context=0x560c5c5d6470) at 
../../../glib/gmain.c:3417
dispatch = 0x7f3d5062d240 
prev_source = 0x0
begin_time_nsec = 0
was_in_call = 0
user_data = 0x7f3d44003c00
callback = 0x7f3d501e1fe0 
cb_funcs = 
cb_data = 
need_destroy = 
source = 0x7f3d40001d70
current = 0x560c5c606e60
i = 0
__func__ = "g_main_dispatch"
#4  g_main_context_dispatch (context=context@entry=0x560c5c5d6470) at 
../../../glib/gmain.c:4135
No locals.
#5  0x7f3d50631258 in g_main_context_iterate (context=0x560c5c5d6470, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4211
max_priority = 2147483647
timeout = -1
some_ready = 1
nfds = 
allocated_nfds = 
fds = 0x560c5c69aac0
begin_time_nsec = 0
#6  0x7f3d50631543 in g_main_loop_run (loop=0x560c5c5d6590) at 
../../../glib/gmain.c:4411
self = 
__func__ = "g_main_loop_run"
#7  0x560c5add469e in main (argc=, argv=) at 
../src/main.c:468
d = {core = 0x560c5c5d9010, loop = 0x560c5c5d6590, exit_code = 0}
context = 0x560c5c5d4150
error = 0x0
properties = 0x0
config_file_path = 0x560c5c5d6380 
"/usr/share/wireplumber/wireplumber.conf"

Bug#1016087: dpkg: errors about cannot verify signature fpr assorted packages

[Guillem Jover]

Control: reassign -1 dpkg-dev 1.21.9
Control: tag -1 moreinfo

Hi!

On Tue, 2022-07-26 at 14:24:41 -0500, Tim McConnell wrote:
> Package: dpkg
> Version: 1.21.9
> Severity: normal
> X-Debbugs-Cc: tmcconnell...@gmail.com

> What led up to the situation? Normal upgrading of system
> 
> What exactly did you do (or not do) that was effective (or ineffective)? 
> Unsure
> these messages started appearing.
> 
> What was the outcome of this action? I now receive multiple lines of: gpgv:
> Signature made Fri 24 Oct 2014 06:23:17 PM CDT
> gpgv:using RSA key F664D256B4691A7D
> gpgv: Can't check signature: No public key
> dpkg-source: warning: cannot verify signature
> /var/cache/apt/sources/libtrio_1.16+dfsg1-3.dsc
> gpgv: Signature made Tue 03 May 2022 09:04:38 PM CDT
> gpgv:using RSA key A1489FE2AB99A21A
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
> quantreg_5.93-1.dsc
> gpgv: Signature made Wed 20 Jul 2022 05:25:03 AM CDT
> gpgv:using RSA key A1489FE2AB99A21A
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
> quantreg_5.94-1.dsc
> apt-listdifferences: removing old src:r-cran-quantreg 5.93-1
> gpgv: Signature made Fri 27 May 2022 04:42:52 AM CDT
> gpgv:using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature
> /var/cache/apt/sources/kconfig_5.94.0-3.dsc
> gpgv: Signature made Sat 23 Jul 2022 05:20:34 AM CDT
> gpgv:using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature
> /var/cache/apt/sources/kconfig_5.94.0-4.dsc
> 
> When running this command `apt-get dist-upgrade -y -m`

I assume you have something installed that downloads source packages
(and perhaps builds them) as part of the upgrade? Otherwise that seems
uncommon. In any case…

> What outcome did you expect instead? To be sure I'm getting packages from an
> uncompromised repo.

… assuming you are getting the source packages from a Debian
repository, those should have the repository mataindices signed by the
archive keys, which get rotated and updated when necessary, in contrast
to the source package signatures which are created by the person uploading
the source package (and never updated anymore). As such those latter
signatures (when later verified after the archive did the initial
verification on upload) can very easily come from now revoked or expired
keys or from keys for people that are no longer members of the project
and are thus not present in the keyrings, the signatures can be expired
themselves, they might come from keys or signatures which are now
considered weak, which is what happens to be the case here. These
signatures use SHA1 as a hashing algorithm which is no longer considered
secure and get rejected.

For the above reasons apt passes --no-check to dpkg-source, and
dpkg-source does not default to erroring out (unless passing to it
--require-valid-signature), as can be seen from the warnings (not
errors) shown above. So I see no dpkg bug here, perhaps whatever is
calling dpkg-source should also be passing --no-check (if it can
guarantee the source came from a verified repo). Otherwise I'll be
closing this in a bit.

Thanks,
Guillem

Bug#1015898: ITP: FoxDot -- Live Coding with Python

[Joenio Marques da Costa]

Great idea Paul,

I've created a Issue on Github about it.

https://github.com/Qirky/FoxDot/issues/255

Thanks,

Le 27/07/2022 à 05:14, Paul Wise a écrit :

On Sat, 23 Jul 2022 15:22:11 +0200 Josue Ortega wrote:


* Package name: foxdot
* URL : https://foxdot.org/


I note that the GitHub repo suggests that FoxDot is unmaintained:

https://github.com/Qirky/FoxDot

I am no longer actively developing FoxDot and will only be making minor
changes to the code in response to issues / pull requests in this time.

So you might want to talk to upstream about the situation. Maybe they
should create a LiveCoding GitHub organisation, invite other people and
projects and move maintenance of FoxDot to the new organisation.



--
Joenio Marques da Costa
Research Software Engineer
http://umr-lisis.fr/membre/joenio
GPG: 9B2D 64BF 843D 6DC1 D8C1  752C 2E31 D3FD E6D0 8FF4

Bug#1015839: dpkg: Back-port ARC support in stable version

[Guillem Jover]

Hi!

On Fri, 2022-07-22 at 12:27:01 +0200, Alexey Brodkin wrote:
> Package: dpkg
> Version: 1.20.11
> Severity: normal

> The problem is even uploads of other packages in "unstable"
> fail to build if they expect the build system system to know about ARC.
> 
> Apparently newly uploaded packages are being built in a "stable"
> environment, and so we need dpkg of that "stable" system to be
> aware of ARC as well.

I think this is more about the archive tools and surrounding tooling
than any build infrastructure. But in any case, yes, it's
inconvenient.

> Thus I'm asking to back-port [2] to 1.20.x branch and add it to the
> "stable" upload of dpkg sometime soon. That will really unblock
> normal package building and uploading for ARC as well.

Yes, I'll queue this for the next stable update. Note that even once
this gets uploaded and ACCEPTed by the SRMs it will still not be
available at least until the next stable point release is actually
released, and the servers running that tooling upgraded.

Thanks,
Guillem

Bug#1015889: [Pkg-utopia-maintainers] Bug#1015889: Bug#1015889: high CPU load for avahi-daemon on Bullseye

[Michael Biebl]

Am 26.07.22 um 12:20 schrieb Harald Dunkel:

On 2022-07-24 14:23:45, Michael Biebl wrote:

Am 24.07.22 um 06:15 schrieb Harald Dunkel:

0.8-6 builds fine on Bullse


More importantly: Does it fix the high CPU load in your case?


I haven't seen the high CPU load anymore using the backported
avahi-daemon.



Thanks for the confirmation

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013940: New version of nfft breaks its autopkgtest (Was: nfft breaks pynfft autopkgtest on i386: Segmentation fault

[Andreas Tille]

Hi,

I was tempted to upload the patch suggested by Bernhard which I applied to
the commit of Ileana with the new upstream version.  Unfortunately the new
upstream version fails the autopkgtest[1] (which was the same when I tried
version 3.5.2 which prevented me from uploading).

Does anybody have a clue how to fix this?

Kind regards

  Andreas.


[1] https://salsa.debian.org/science-team/nfft/-/jobs/3041717

-- 
http://fam-tille.de

Bug#1015123: latex-cjk-chinese-arphic: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[韓達耐]

Some observations:

Going back to fontforge version 20201107~dfsg-4 and its dependencies, I
notice the following warning message:

21900/1114292:
  Add extrema...
  Simplifying outlines...
NaN value in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creationNaN value in spline creationNaN value in spline
creationNaN value in spline creationNaN value in spline creationNaN value
in spline creation22000/1114292:

  Add extrema...
  Simplifying outlines...

A more recent version of Fontforge will just let the application hang.

I will have to contact upstream to figure out what is causing this.

-- 
Danai


On Sun, 17 Jul 2022 at 16:15, Danai SAE-HAN (韓達耐) 
wrote:

> Very interesting; font bkai gets stuck during the fontforge compilation at
> 21900/1114292 and stays at 100% CPU usage.  Other fonts seem fine.
> This requires a bit more investigating.  My gut tells me the recent
> fontforge upload has a regression somewhere.
>
> --
> Danai
>
> On Sat, 16 Jul 2022 at 22:42, Danai SAE-HAN (韓達耐) 
> wrote:
>
>> Thanks Lucas, I'll look at it tonight.
>>
>> On Sat, 16 Jul 2022, 22:04 Lucas Nussbaum,  wrote:
>>
>>> Source: latex-cjk-chinese-arphic
>>> Version: 1.24
>>> Severity: serious
>>> Justification: FTBFS
>>> Tags: bookworm sid ftbfs
>>> User: lu...@debian.org
>>> Usertags: ftbfs-20220716 ftbfs-bookworm
>>>
>>> Hi,
>>>
>>> During a rebuild of all packages in sid, your package failed to build
>>> on amd64.
>>>
>>>
>>> Relevant part (hopefully):
>>> > Reading subfont definition file
>>> `/usr/share/texlive/texmf-dist/fonts/sfd/ttf2pk/Unicode.sfd'...
>>> > Writing extended font definition file `c70bsmi.fdx'...
>>> >
>>> > # Remove the *.enc files; they're not used.
>>> > ( cd build/bsmi00lp && rm -f *.enc )
>>> >
>>> > # Create a Type1 font map.
>>> >
>>> > # Create entries for the font definition file
>>> > # `c00bsmi.fd' (which uses UBig5 encoding).
>>> >
>>> > # Create entries for the font definition file
>>> > # `c70bsmi.fd' (which uses Unicode encoding).
>>> >
>>> > touch build-stamp.bsmi
>>> > E: Build killed with signal TERM after 150 minutes of inactivity
>>>
>>>
>>> The full build log is available from:
>>>
>>> http://qa-logs.debian.net/2022/07/16/latex-cjk-chinese-arphic_1.24_unstable.log
>>>
>>> All bugs filed during this archive rebuild are listed at:
>>>
>>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220716;users=lu...@debian.org
>>> or:
>>>
>>> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220716=lu...@debian.org=1=1=1=1#results
>>>
>>> A list of current common problems and possible solutions is available at
>>> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
>>> contribute!
>>>
>>> If you reassign this bug to another package, please marking it as
>>> 'affects'-ing
>>> this package. See https://www.debian.org/Bugs/server-control#affects
>>>
>>> If you fail to reproduce this, please provide a build log and diff it
>>> with mine
>>> so that we can identify if something relevant changed in the meantime.
>>>
>>>

Bug#1016105: systemctl complains about smtpd at start time

[Harald Dunkel]

Package: snmptt
Version: 1.4.2-1

There were several complains about snmptt at boot time. Would
you mind to check, esp. the PID issue?

I am using snmptt to write traps to a log file for monitoring
via Zabbix, but if snmptt is not running the traps are lost and
the log file is silently not updated anymore. I have to rely upon
systemd here.


# systemctl status snmptt
* snmptt.service - SNMP trap translator
 Loaded: loaded (/lib/systemd/system/snmptt.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Wed 2022-07-27 12:18:51 CEST; 8s ago
Process: 3215961 ExecStart=/usr/sbin/snmptt $DAEMON_ARGS (code=exited, 
status=0/SUCCESS)
   Main PID: 3215964 (snmptt)
CPU: 94ms
 CGroup: /system.slice/snmptt.service
 |-3215963 /usr/bin/perl /usr/sbin/snmptt --daemon
 `-3215964 /usr/bin/perl /usr/sbin/snmptt --daemon

Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt[3215961]: Smartmatch is 
experimental at /usr/sbin/snmptt line 859.
Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt[3215961]: Redundant argument in 
sprintf at /usr/lib/x86_64-linux-gnu/perl/5.32/Sys/Syslog.pm line 454.
Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt-sys[3215961]: SNMPTT v1.4.2 
started
Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt[3215961]: Redundant argument in 
sprintf at /usr/lib/x86_64-linux-gnu/perl/5.32/Sys/Syslog.pm line 454.
Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt-sys[3215961]: Loading 
/etc/snmp/snmptt.conf
Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt[3215961]: Redundant argument in 
sprintf at /usr/lib/x86_64-linux-gnu/perl/5.32/Sys/Syslog.pm line 454, 
 line 64.
Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt-sys[3215961]: Finished loading 
64 lines from /etc/snmp/snmptt.conf
Jul 27 12:18:51 dex06.hosting2.aixigo.de snmptt-sys[3215964]: Changing to UID: 
snmptt (116), GID: snmptt (121)
Jul 27 12:18:51 dex06.hosting2.aixigo.de systemd[1]: snmptt.service: 
Supervising process 3215964 which is not our child. We'll most likely not 
notice when it exits.
Jul 27 12:18:51 dex06.hosting2.aixigo.de systemd[1]: Started SNMP trap 
translator.


Regards
Harri

Bug#1016069: ceph: CVE-2022-0670

[Thomas Goirand]

On 7/26/22 13:16, Moritz Mühlenhoff wrote:

Source: ceph
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for ceph.

CVE-2022-0670[0]:
| A flaw was found in Openstack manilla owning a Ceph File system
| "share", which enables the owner to read/write any manilla share or
| entire file system. The vulnerability is due to a bug in the "volumes"
| plugin in Ceph Manager. This allows an attacker to compromise
| Confidentiality and Integrity of a file system. Fixed in RHCS 5.2 and
| Ceph 17.2.2.

https://ceph.io/en/news/blog/2022/v17-2-2-quincy-released/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0670
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0670

Please adjust the affected versions in the BTS as needed.



Hi Moritz,

If I'm not mistaking, this security hole is only in the 16.2.x series of 
Ceph, right? I'll upgrade to 16.2.10 immediately. Please let me know 
about Ceph in Bullseye.


Cheers,

Thomas Goirand (zigo)

Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server

[Stephen Dennis]

Reproduce this by adding 'sleep 100' into the libmux.so: part of the
Makefile. It reproduces in the initial submission. It does not reproduce in
the second. So, I am confident it has been fixed.

On Tue, Jul 26, 2022 at 8:03 PM Adam Borowski  wrote:

> On Tue, Jul 26, 2022 at 03:29:03PM -0600, Stephen Dennis wrote:
> >  * Package name: tinymux
> >Version : 2.12.0.10-1
>
> >  tinymux (2.12.0.10-1) unstable; urgency=medium
> >  .
> >* New upstream release
> >  + fixes ftbfs with GCC-12. (Closes: #1013053)
> >* Update Standards-Version in debian/control from 4.0.1 to 4.6.1.
> >  + Removed build date and number for reproducible build.
> >(Closes: #866945)
>
> Alas, it fails to build:
> g++ -std=c++14 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -g -O
>  -DSTUB_SLAVE   -o stubslave stubslave.o -L. -lm -lcrypt   -lmux
> /usr/bin/ld: cannot find -lmux: No such file or directory
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
> ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
> ⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...
>

Bug#986030:

[Sujat Ali]

Yas

Bug#1006424: mirror submission for mirror.informatik.tu-freiberg.de

[Schubert Christian]

Hey there,

 

it has been a while now. Is there anything new about the entry yet?

 

Best regards,

 

Christian

 


TU Bergakademie Freiberg

Christian Schubert, B.Sc.
Institut fuer Informatik
Bernhard-von-Cotta Straße 2 / Zimmer 104
D-09596 Freiberg
Telefon: +49 3731 39 3342


 



smime.p7s
Description: S/MIME cryptographic signature

Bug#988337: XDG_RUNTIME_DIR can be set in ~/.profile

[Christopher Huhn]

Setting the $XDG_RUNTIME_DIR environment variable in ~/.profile or 
~/.bash_profile fixes this error.

The Gentoo wiki has an example: https://wiki.gentoo.org/wiki/Weston#Usage

XDG_RUNTIME_DIR is normally defined in 
/etc/X11/Xsession.d/20dbus_xdg-runtime.

I assume Xsession* is only for X and not for Weston/Wayland?

Best

Christopher

Bug#1006694: debianutils: update-shells --root default and merged-/usr support

[Johannes Schauer Marin Rodrigues]

Hi,

On Wed, 02 Mar 2022 15:49:46 +0100 Johannes Schauer Marin Rodrigues 
 wrote:
> I'm filing this as a tracking bug with usertags for the following two MR I
> filed on salsa:
> 
> https://salsa.debian.org/debian/debianutils/-/merge_requests/21
> https://salsa.debian.org/debian/debianutils/-/merge_requests/22
> 
> I think MR !22 is optional and only useful if you agree that it would
> make sense to have the same defaults for the --root argument as
> update-alternatives and dpkg-divert.

I just did an NMU with a delay of 10 days to unstable with the attached
debdiff, applying both of above merge requests and thus fixing this bug.

I hope that's okay. If not, feel free to cancel.

Thanks!

cheers, joschdiff -Nru debianutils-5.7/debian/changelog debianutils-5.7/debian/changelog
--- debianutils-5.7/debian/changelog	2022-05-01 18:47:00.0 +0200
+++ debianutils-5.7/debian/changelog	2022-07-27 08:20:06.0 +0200
@@ -1,3 +1,11 @@
+debianutils (5.7-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * update-shells: workaround for merged-/usr (closes: #1006694)
+  * update-shells: set the default for ROOT to $DPKG_ROOT
+
+ -- Johannes Schauer Marin Rodrigues   Wed, 27 Jul 2022 08:20:06 +0200
+
 debianutils (5.7-0.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru debianutils-5.7/debian/patches/dpkg-root debianutils-5.7/debian/patches/dpkg-root
--- debianutils-5.7/debian/patches/dpkg-root	1970-01-01 01:00:00.0 +0100
+++ debianutils-5.7/debian/patches/dpkg-root	2022-07-27 08:17:42.0 +0200
@@ -0,0 +1,31 @@
+--- a/update-shells
 b/update-shells
+@@ -23,7 +23,7 @@ log() {
+ 	fi
+ }
+ 
+-ROOT=
++ROOT=${DPKG_ROOT:-}
+ VERBOSE=0
+ NOACT=0
+ 
+@@ -79,7 +79,7 @@ for f in "$PKG_DIR/"*; do
+ 	while IFS='#' read -r line _; do
+ 		[ -n "$line" ] || continue
+ 		PKG_SHELLS="$PKG_SHELLS$line#"
+-		realshell=$(dpkg-realpath --root "$ROOT" "$line")
++		realshell=$(dirname "$(dpkg-realpath --root "$ROOT" "$line")")/$(basename "$line")
+ 		if [ "$line" != "$realshell" ]; then
+ 			PKG_SHELLS="$PKG_SHELLS$realshell#"
+ 		fi
+--- a/update-shells.8
 b/update-shells.8
+@@ -24,6 +24,8 @@ Do not actually perform the changes to
+ 
+ Operate on a chroot at
+ .I ROOT .
++Defaults to the value of the environment variable
++.I DPKG_ROOT .
+ .TP
+ .B \-\-verbose
+ Print the shells that are being added or removed.
diff -Nru debianutils-5.7/debian/patches/series debianutils-5.7/debian/patches/series
--- debianutils-5.7/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ debianutils-5.7/debian/patches/series	2022-07-27 08:17:42.0 +0200
@@ -0,0 +1 @@
+dpkg-root
diff -Nru debianutils-5.7/debian/postinst debianutils-5.7/debian/postinst
--- debianutils-5.7/debian/postinst	2022-05-01 18:43:27.0 +0200
+++ debianutils-5.7/debian/postinst	2022-07-27 08:17:42.0 +0200
@@ -19,11 +19,11 @@
 
 case "$1" in
 (configure)
-	update-shells --root "${DPKG_ROOT:-}"
+	update-shells
 	ua
 ;;
 (triggered)
-	update-shells --root "${DPKG_ROOT:-}"
+	update-shells
 ;;
 
 (abort-upgrade|abort-remove|abort-deconfigure)


signature.asc
Description: signature

Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

[Samuel Thibault]

Hello,

Peter Blackman, le mer. 27 juil. 2022 12:22:17 +0100, a ecrit:
> Back trace on dumatest shows an endless loop. Repeats every ten steps.

Could you manage to get the top of the stack?

> #35 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
> #36 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
>     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
>     fail=DUMA_FAIL_ENV,
>     filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1386
> #37 0x080353b6 in _duma_malloc (size=100,
>     filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1970
> #38 0x08035c8b in malloc (size=100) at duma.c:2424
> #39 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
> #40 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
> #41 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
> #42 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
> #43 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
> #44 0x08036095 in lock () at sem_inc.c:135
> #45 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
> #46 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
>     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
>     fail=DUMA_FAIL_ENV,
>     filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1386
> #47 0x080353b6 in _duma_malloc (size=100,
>     filename=0x8037060  "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1970
> #48 0x08035c8b in malloc (size=100) at duma.c:2424

So the loop is because the assertion failure uses printf, which uses an
allocation, which triggers the assertion again etc.

> I'm curious about the step   pthread_self ()  -->  __assert_fail ()
> 
> The man page for pthread_self (Linux)
> https://man7.org/linux/man-pages/man3/pthread_self.3.html
> 
> states that the function always succeeds. Unlikely if it throws an assert.

Yes, that's why it's an assert and not an error: something very wrong is
happening.

Do you have the libc0.3-dbg package installed? That'd help to know
exactly why assertion fails.

> Also raised upstream
> https://github.com/johnsonjh/duma/issues/172
> 
> but the question really is.
> 
> Is this a bug in Hurd, or something that can be fixed in duma?

Most probably what happens (the top of the stack would tell) is that
pthread_self is called very early, before libpthread is initialized, and
it's assert (__pthread_threads); which fails because of that.

Samuel

Bug#1014925: hw-detect: Fails to install open-vm-tools if fuse is already installed

[Arnaud Rebillout]

On Thu, 14 Jul 2022 20:14:15 +0200 Ben Hutchings  
wrote:

>
> You should find out why that is, before proposing to override it. What
> if something in KDE really does need FUSE 2?

I don't think that it can happen. A package might need FUSE3 (in such 
case it depends on fuse3), or it might need FUSE (any implementation) 
(in such case it depends on fuse, and it's either fuse or fuse3 that 
will be installed, as fuse3 Provides fuse). But it cannot really ask for 
FUSE2, as far as I understand (there's no fuse2 package).


In the case I described above, if fuse gets installed, it's not because 
a package needs FUSE2, it's because no package needs FUSE3. So apt picks 
fuse rather than fuse3.


> (Since you found that removing fuse doesn't remove anything else, this
> implies that the relationship is only a Recommends and not a Depends.
> But that doesn't mean that removal won't break anything.)

I believe that if replacing fuse by fuse3 doesn't remove anything, it's 
because fuse3 Provides fuse.


In any case: in Kali we solved that by recommending fuse3 in 
kali-desktop-core, a metapackage that is always installed with every 
Kali desktop. Therefore we're sure to have fuse3 (we don't let apt 
guess), and we're sure that open-vm-tools will be installed if needed. 
It's a better solution than modifying hw-detect as I suggested here.


Therefore I'll close this bug, as I don't think it affects Debian anyway.

Thanks for your feedback, and sorry for the noise.

Arnaud

Bug#1015930: debian-livecoding list

[Igor Garcia]

I support the creation of this mailing list.

During Debconf22 I had nice chats with Joenio and also with other people 
regarding this subject and I believe it's time for us to have a proper 
place to have discussions focused on Music and Art in Debian.


Igor Garcia

Bug#1008082: How to --lock an account

[Marc Haber]

On Wed, Jul 27, 2022 at 09:12:50AM -0400, Jason Franklin wrote:
> On Wed, Jul 27, 2022 at 12:09:27PM +0200, Marc Haber wrote:
> > > > > I think Jason was working on this?
> > > > > 1008082/1008084/390457 --system --lock functionality
> > > > 
> > > > I hope so, that should be the next important big step, maybe a team
> > > > effort? Can this be sensibly split into work units to distribute?
> > > 
> > > Happy to help if I can (divisible work units would help).
> > 
> > Jason, that's your call then.
> 
> I am currently working on the "--homeless" option, which I own in the
> BTS listing.

Nice. Good!

> Before I start, I want to make sure we agree on what should be done.
> 
> I asserted that two things were sufficient:
>   1. Put a '!' in front of the user's password in /etc/shadow
>   2. Expire the account
> 
> This makes it trivial to unlock an account with all of its attributes
> intact, including login shell.

I think that having nologin as a shell has the advantage of giving a
clear error message IF somebody manages to log in to the expired account
with an invalid password.

I am not sure whether we actually need to save the login shell, the
intended usage is a maintainer script, to have the account locked on
purge. The use case for re-activation here is reinstallation of the
package, with the normal postinst running as if the account didn't
exist, so the package maintainer is either fine with getting the default
login shell or has one specified in their adduser call. So, for a system
account, we can overwrite the login shell without causing harm.

For a normal user account, I am undecided whether:

- leave login shell intact, leaving a possible security hole
- set login shell back to the default when the account gets reenabled
- save login shell somewhere to reinstate if on reenabling.

I'd say, do it as you see fit, changing that at a later time would be a
rather isolated change so I'm fine with going ahead either way here,
while still having a personal preference for the third possibility, but
I am not the one who decides that.

> Not sure if we reached agreement here. See discussion..
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008082
> 
> Just let me know. Thanks!

Cc.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1016115: fortunes-it: states Benjamin Franklin was a President

[Anthony Foglia]

Package: fortunes-it
Version: 1.99-4.1
Severity: minor

The package includes the fortune:

> Un uomo benevolo dovrebbe permettersi qualche difetto, per non far fare
> brutta figura ai propri amici.
>   -- Benjamin Franklin, Presidente USA

Benjamin Franklin was not a US President.

This fortune is in the file /usr/share/games/fortunes/it/paoltedeschi

Bug#1016109: new upstream (2.2.0)

[Daniel Baumann]

Hi Paride

On 7/27/22 16:05, Paride Legovini wrote:
> 2.2.0 is a stable release

I'm aware - I just didn't wanted to "impose" on you for "needing" to
upload to unstable. If it were up to me, I would have uploaded it to
unstable. :)

Regards,
Daniel

Bug#772513: intel-microcode: dracut support for wheezy-backports

[Jérémy Lal]

Package: intel-microcode
Version: 3.20220510.1
Followup-For: Bug #772513

Hi,

do the abilities of dracut have improved enough to fix this ?




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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 intel-microcode depends on:
ii  iucode-tool  2.3.1-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.142

intel-microcode suggests no packages.

-- no debconf information

Bug#1016120: kmscube does not quit on its own and inhibits switching to other TTYs, making computer unusable

[Nils Dagsson Moskopp]

Package: kmscube
Version: 0.0.0~git20210103-1
Severity: important
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

I started kmscube to test out whether kernel mode-setting would work on my 
hardware.
I saw a rotating textured cube (so KMS works), but there was no way to exit 
kmscube.

Among other things, I tried ESC, SPC and CTRL + C, but none of those exited 
kmscube.

I then tried to switch to another TTY to log in and kill kmscube. This did not 
work.
It seems that all keyboard inputs i tried were deferred until after kmscube 
exits.

I expected shortcuts like CTRL + ALT + F2 to always get me to TTY2 immediately.
I also expected kmscube to exit upon a keypress, mouse click, or after a time.

To reproduce this issue:

1. Execute ”timeout 10 kmscube” in TTY1.
2. Press CTRL + ALT + F2 as soon as you see a rotating cube.
3. Wait 10 seconds.
4. Verify that the display only switches to TTY2 after kmscube exits.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages kmscube depends on:
ii  libc6   2.31-13+deb11u3
ii  libdrm2 2.4.104-1
ii  libegl1 1.3.2-1
ii  libgbm1 20.3.5-1
ii  libgles21.3.2-1
ii  libglib2.0-02.66.8-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libpng16-16 1.6.37-3

kmscube recommends no packages.

kmscube suggests no packages.

-- no debconf information

Bug#1006471: ruby3.0: reproducible builds: embeds path to various binaries

[Antonio Terceiro]

Control: clone -1 -2
Control: reassign -2 src:ruby3.1
Control: retitle -2 ruby3.1: reproducible builds: embeds path to various 
binaries

Hi,

On Sun, Jul 17, 2022 at 12:04:45PM +0100, Simon McVittie wrote:
> Control: severity -1 serious
> 
> On Fri, 25 Feb 2022 at 15:26:51 -0800, Vagrant Cascadian wrote:
> > The paths to various binaries, which differs on a usrmerge
> > vs. non-usrmerge system, are embedded in rbconfig.rb:
> > 
> >   
> > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/ruby3.0.html
> > 
> >   /usr/lib/x86_64-linux-gnu/ruby/3.0.0/rbconfig.rb
> > 
> >   CONFIG["EGREP"]·=·"/bin/grep·-E"
> >   vs.
> >   CONFIG["EGREP"]·=·"/usr/bin/grep·-E"
> 
> If these CONFIG variables are used for something at runtime, then this
> will become a practical problem as soon as Debian starts using merged-/usr
> buildds. The problem scenario is:
> 
> - ruby3.0 is built on a merged-/usr buildd
> - /usr/bin/grep is recorded in rbconfig.rb
> - this build of ruby3.0 is installed on a non-merged-/usr system during
>   the upgrade from Debian 11 to Debian 12
> - whatever feature uses CONFIG["EGREP"] will not work, because
>   non-merged-/usr systems only have /bin/grep
> 
> Technical Committee resolution
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
> that this class of bug is treated as release-critical, so I'm raising the
> severity of this bug report.
> 
> If none of the affected CONFIG variables are actually used for anything
> on installed systems, then the severity of this bug can be downgraded
> to non-RC (but it would be better to fix it anyway, because reproducible
> builds are a useful goal for other reasons).

Those variables are read from config.status during the builds. Maybe
this should be fixed centrally in autoconf instead?

> > Patch attached which passes variables to configure to use the
> > non-usrmerge locations, as usrmerge installations typically have
> > compatibility symlinks, but not vice-versa.
> 
> To clarify: in Debian, merged-/usr installations are *guaranteed* to
> have these compatibility symlinks. The patch looks appropriate to me,
> although I have not tested it.

Sure.


signature.asc
Description: PGP signature

Bug#1013940: New version of nfft breaks its autopkgtest (Was: nfft breaks pynfft autopkgtest on i386: Segmentation fault

[Aaron M. Ucko]

Andreas Tille  writes:

> [1] https://salsa.debian.org/science-team/nfft/-/jobs/3041717

| + gcc -Wall -DNFFT_PRECISION_SINGLE -lnfft3f -lfftw3f -o simple_test 
simple_test.c
| /usr/bin/ld: /tmp/ccaUJ49M.o: in function `simple_test_nfft_1d':
| simple_test.c:(.text+0x2c): undefined reference to `nfftf_init_1d'
[...]

Please try listing simple_test.c ahead of the libraries, which the
linker otherwise discards as apparently unneeded.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1016109: new upstream (2.2.0)

[Daniel Baumann]

tag 1016109 + patch
thanks

Hi,

I've updated the package for 2.2.0 and built+tested the result in
production (both on current sid and current bullseye), feel free to merge:

https://git.progress-linux.org/users/daniel.baumann/debian/bts/isc-kea/

  * branch upstream has the upstream release commited on top of your
last commit in your upstream branch

  * branch pristine-tar has the pristine-tar data commited on top of
your last commit in your pristine-tar branch

  * branch bts-1016109 has the required commits on top of your
debian/experimental branch.

Regards,
Daniel

Bug#1016112: transition: phodav 3.0 & friends

[Jeremy Bicha]

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

I am filing this bug for the phodav transition. Affected packages are:
phodav
spice-gtk
libosinfo
virt-viewer
remmina
gnome-boxes
There was no soname bump for most of this transition and I don't have
a ben file for it.

All of these packages require sourceful uploads. I am a team uploader
for all these packages except for Remmina.

I am filing this bug as moreinfo since I want coordination from the
Remmina maintainer before starting this transition in Unstable.

Perhaps too much detail:
https://discourse.gnome.org/t/phodav-transition-notes/10483

I successfully completed this transition recently in Ubuntu 22.10.

This transition allows completing a small part of the big GNOME 43
libsoup transition without entangling as many packages.

Thank you,
Jeremy Bicha

Bug#1006471: ruby3.0: reproducible builds: embeds path to various binaries

[Simon McVittie]

On Wed, 27 Jul 2022 at 08:49:27 -0300, Antonio Terceiro wrote:
> > On Fri, 25 Feb 2022 at 15:26:51 -0800, Vagrant Cascadian wrote:
> > > The paths to various binaries, which differs on a usrmerge
> > > vs. non-usrmerge system, are embedded in rbconfig.rb:
> > > 
> > >   /usr/lib/x86_64-linux-gnu/ruby/3.0.0/rbconfig.rb
> > > 
> > >   CONFIG["EGREP"]·=·"/bin/grep·-E"
> > >   vs.
> > >   CONFIG["EGREP"]·=·"/usr/bin/grep·-E"
> > 
> > If these CONFIG variables are used for something at runtime, then this
> > will become a practical problem as soon as Debian starts using merged-/usr
> > buildds.
> 
> Those variables are read from config.status during the builds. Maybe
> this should be fixed centrally in autoconf instead?

autoconf is designed to support arbitrarily bad host OSs, including those
that are non-POSIX or otherwise defective, where the only fully-functional
grep might be /opt/sw/addons/misc/gnu/grep or something; so it has a
tendency to discover a known-good absolute path and save that.

This is great if you're building Ruby on an awful 1990s Unix machine
and the result of AC_PROG_EGREP will only be used during build, or if
it is used at runtime but you only plan to run the resulting Ruby binaries
on that same machine, but it goes wrong when facts about the build system
start to diverge from facts about the host system.
In this case, the fact that is different is the merged-/usr status
of the build system and the host system, but it could be almost anything.

The macros that Ruby uses to find these commands are probably AC_PROG_GREP,
AC_PROG_EGREP, etc., which are not explicitly documented to output an
absolute path (the documentation just says "whatever is chosen"), but
looking at their implementation, it seems they do: they are like
AC_PATH_PROG rather than AC_CHECK_PROG.

It's entirely possible that Ruby is not doing this deliberately, those
macros might well be a dependency for something else.

Is the Ruby build intentionally putting EGREP into rbconfig.rb for use by
some other component, or is it just populating that file with everything
that Autoconf happens to have discovered, on the off chance that it
might become necessary at some point? If the latter, then that seems
like it will cause unpredictable action-at-a-distance if Autoconf stops
needing to discover some particular thing (for instance if Autoconf's
maintainers decide that they are only going to support systems where
the first grep in PATH is POSIX.1-2001 compliant, and stop checking for a
possibly-better-quality grep elsewhere).

smcv

Bug#1016116: libpam-ldap: Please drop package: abandoned upstream since 2010

[Gioele Barabucci]

Package: libpam-ldap
Version: 186-4

Dear maintainer of libpam-ldap,

could you please remove the package libpam-ldap?

Upstream development has ceased in 2010, with the current alternative 
being libpam-ldapd.


The Debian package is also in need of updates:

* it fails to build reproducibly,
* it has not been updated since old-old-stable (Debian 9, 2017),
* there are 56 open bugs against it in the Debian bug tracker.

Regards,

--
Gioele Barabucci

Bug#1016109: new upstream (2.2.0)

[Paride Legovini]

Daniel Baumann wrote on 27/07/2022:
> kea 2.2.0 was released a couple of days ago, it would be nice if you
> could upgrade the package in experimental.

Hi Daniel,

According to the version scheme and release notes [1] Kea 2.2.0 is a 
stable release, even if it hasn't been announced as such yet [2].
Is there any reason why you suggest uploading to experimental instead
of unstable (perhaps with urgency=low)?

Thanks,

Paride

[1] https://ftp.isc.org/isc/kea/2.2.0/Kea-2.2.0-ReleaseNotes.txt
[2] https://www.isc.org/categories/kea/

Bug#1016119: firefox: Coredump on startup but starts anyway

[Nicolas Patrois]

Package: firefox
Version: 103.0-1
Severity: minor
Tags: upstream

Dear Maintainer,

When I start Firefox, I see these lines in the logs:

juil. 27 16:18:02 nicolas.home kernel: firefox[30259]: segfault at 80 ip
b69d4744 sp bfa4813c error 4 in libX11.so.6.4.0[b69be000+8f000]
juil. 27 16:18:02 nicolas.home kernel: Code: 26 00 00 00 00 90 8b 44 24 04 8b
40 14 c3 8d b4 26 00 00 00 00 90 8b 44 24 04 8b 40 4c c3 8d b4 26 00 00 00 00
90 8b 44 24 04 <8b> 80 80 00 00 00 c3 8d 74 26 00 90 8b 44 24 08 8b 54 24 04 8d
04
juil. 27 16:18:02 nicolas.home systemd[1]: Started Process Core Dump (PID
30261/UID 0).
juil. 27 16:18:22 nicolas.home systemd-coredump[30262]: [] Process 30259
(firefox) of user 1000 dumped core.

Module linux-gate.so.1
with build-id 736115d629192882c4f8e4133d73f90761621c2e
Module libGLX.so.0 with
build-id 8d9fd6147977b2c8d49a6fc8d286a079d1f4c25b
Module
libGLdispatch.so.0 with build-id e85ecf95e7e91d86650b7d5ac7bf7d673371f7ae
Module libvdpau.so.1
with build-id 4c282b6fc893593c0b8439424c0211a9334969bf
Module libGL.so.1 with
build-id f65cd1973d3add479c9c4b6b15539e4fa870f138
Module
nvidia_drv_video.so with build-id b066f36fd0efc7600be513f90f23f5fdb1256bb9
Module libdrm.so.2 with
build-id 252d0713a55d4aa1d17f511723395ff32d7fdf18
Module libva.so.2 with
build-id 9b4d0f14f333030b5b7bcba2e88248b9fb6cf136
Module libva-drm.so.2
with build-id 114dc9849dc2f80d1268b0534dfef77bff61c0fa
Module libnvidia-
eglcore.so.390.151 without build-id.
Module libnvidia-
glsi.so.390.151 without build-id.
Module libplds4.so with
build-id 4e523529aeb5d51f10960ae064962fa1fb96d8fa
Module libX11-xcb.so.1
with build-id 6b40bb4b2f03c661fff67cdeb2024b61e900d673
Module libdbus-
glib-1.so.2 with build-id 96a1744671fa31618aa943d3ffded57181fd0072
Module libvpx.so.7 with
build-id ae765cd1353e8008fb5c8b5252c5d1a8a9d33b15
Module
libevent-2.1.so.7 with build-id 7c09aab98ac20a03cde70191776c83e421bb32f8
Module libssl3.so with
build-id 493f5fa5e42d50c2a08af87e781cd930e91accbc
Module libsmime3.so
with build-id b3a82459d13a74b1da37520aba829a43ee5d0b76
Module libnssutil3.so
with build-id c67c43f83fc6c53a50be2fa3ada761e99e9ead8c
Module libnss3.so with
build-id 063e6edbc57853765e97eb42d2585393ae4024b7
Module libplc4.so with
build-id 7e5da6d9b16d5f3a1d30d1f4181928d8f1519a6d
Module libXtst.so.6
with build-id 8c792ab8d9802ac771051c265db05002644cbf8d
Module libasound.so.2
with build-id ff45568acf24ecd462a9f121ae1499d9a822ca9c
Module libxul.so with
build-id d74fcc9752354cd1dcb99bc814fb3fc94696def7
Module libmozwayland.so
with build-id fb590422c9e87c9e52cf5a784e8a051ab214bcde
Module libgpg-
error.so.0 with build-id 88d3d9b1c11d9f59e2951b42aafe3cdc7b2f06af
Module libmd.so.0 with
build-id 34c82b021325f32a59331e0c1a94dd15906777ca
Module liblz4.so.1 with
build-id 7ccef3390a7a41278e860f86aae9ef9bfa68d5a9
Module libzstd.so.1
with build-id c356a14591a988e31fe745baebe531ef1c303d1a
Module liblzma.so.5
with build-id 857aa893262b8865177d52583e3475fea13d863f
Module libgcrypt.so.20
with build-id d78ffea1658e953b994c09ed8e528e653ee869b1
Module libcap.so.2 with
build-id dd3588996222b97eb95fbcf60452215fe44ae0c5
Module
libbrotlicommon.so.1 with build-id 

Bug#1016124: volumeicon-alsa: give a way to set configuration at startup

[eingousef]

Package: volumeicon-alsa
Version: 0.5.1+git20170117-1+b2
Severity: normal
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

Here's my use case :

I have 2 channels I'd like to know the status of : The 'Master' output channel 
and the 'Internal Mic Boost' output channel. `volumeicon` allows me to have 2 
instances launched at startup and visible in my systray. I set one of them on 
'Master' channel and the other one on 'Internal Mic Boost' channel. Problem : I 
have to do this by hand, using the Preferences config wizard.

It would be nice if, when launching multiple instances of `volumeicon`, you 
could specify the configuration at startup, either by providing the various 
config options directly on the command line, or by providing an alternative 
config file instead of the default.

Regards,

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages volumeicon-alsa depends on:
ii  libasound2   1.2.7.1-1
ii  libc62.33-8
ii  libcairo21.16.0-6
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.3-1
ii  libgtk-3-0   3.24.34-1
ii  libnotify4   0.8.1-1
ii  libx11-6 2:1.7.5-1

volumeicon-alsa recommends no packages.

Versions of packages volumeicon-alsa suggests:
ii  alsamixergui  0.9.0rc2-1-10.1
ii  dunst [notification-daemon]   1.8.1-1
ii  lxqt-notificationd [notification-daemon]  0.16.0-1
ii  notification-daemon   3.20.0-4+b1
ii  notify-osd [notification-daemon]  0.9.35+15.04.20150126-1+b2
ii  xfce4-notifyd [notification-daemon]   0.6.3-1

-- no debconf information

Bug#1008369: scikit-learn testing migration

[M. Zhou]

The previous segfault on armel becomes Bus Error on armel and armhf.
I can build it on Power9, but it seems that the test fails on power8 (our 
buildd).

On Wed, 2022-07-27 at 09:56 +0200, Andreas Tille wrote:
> Control: tags -1 unreproducible
> Control: tags -1 moreinfo
> Control: severity -1 important
> 
> Hi,
> 
> BTW, there is another bug in scikit-learn, but I can't reproduce it and
> have set tags accordingly.  Could someone else please give it a try?
> 
> Kind regards
> 
>  Andreas.
> 
> Am Wed, Jul 20, 2022 at 09:23:28PM +0200 schrieb Andreas Tille:
> > Hi Nilesh,
> > 
> > Am Wed, Jul 20, 2022 at 06:21:19PM +0530 schrieb Nilesh Patra:
> > > On 7/20/22 4:50 PM, Andreas Tille wrote:
> > > > Before we stop progress in Debian for many other architectures since we
> > > > cant't solve this on our own or otherwise are burning patience of
> > > > upstream I'd alternatively consider droping armel as supported
> > > > architecture.
> > > 
> > > I am definitely +1 for this, however scikit-learn is a key package and 
> > > dropping
> > > it from armel would mean dropping several revdeps as well.
> > > I am a bit unsure if that is fine or not.
> > 
> > Its not fine at all and I would not be happy about it.  However, the other
> > side of a key package is, that lots of package have testing removal warnings
> > on architectures which are widely used and we have real trouble because of
> > this.
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 
> 

Bug#1016111: reprepro: FTBFS with 3 tests failing on big endian architectures

[Bastian Germann]

Package: reprepro
Version: 5.4.0-1
Severity: important

Three of the new unit tests by Benjamin Drung fail on big endian architectures 
in experimental.
Make them pass for unstable.

Bug#1016113: RFP: simplemonitor -- simplemonitor monitors hosts and network connectivity. It is designed to be quick and easy to set up

[Carles Pina i Estany]

Package: wnpp
Severity: wishlist

* Package name: simplemonitor
  Version : 1.11.0
  Upstream Author : James M Seward
* URL : https://github.com/jamesoff/simplemonitor
* License : BSD-3-Clause license
  Programming Lang: Python
  Description : simplemonitor monitors hosts and network connectivity. It 
is designed to be quick and easy to set up

SimpleMonitor is a Python script which monitors hosts and network connectivity 
and status. It is designed to be quick and easy to set up and lacks complex 
features that can make things like Nagios, OpenNMS and Zenoss overkill for a 
small business or home network. Remote monitor instances can send their results 
back to a central location.

I've been using SimpleMonitor for many years (at least since 2017) with
great success. The upstream author has been responsive when I had issues
or feedback.

At that time (2017), I spent time checking Debian-packaged software but
none offered me the options and simplicity of simplemonitor. I've
checked every now and then and not found any suitable Debian-packaged
alternatives for my situation.

SimpleMonitor is simple in terms of not needing a database / much setup
but has enough loggers, alerters and monitors to make it really useful
in many situations. I've used it in very different environments and I
think that it would be a good addition for Debian.

Bug#1016114: remmina: stop using libsoup2 version of spice-gtk

[Jeremy Bicha]

Source: remmina
Severity: important
Version: 1.4.27+dfsg-1
Tags: patch
Control: blocks 1016112 by -1
Forwarded: https://gitlab.com/Remmina/Remmina/-/issues/2754

I want to complete the phodav/spice-gtk transition to libsoup3.

Remmina won't run if it tries to use libsoup2.4 and libsoup3 in the
same process. The easiest temporary fix is to stop building
remmina-plugin-spice (along with a Breaks from the spice-gtk library
on that plugin). I have proposed this at
https://salsa.debian.org/debian-remote-team/remmina/-/merge_requests/3

Alternatively, Remmina could be updated to not use libsoup2 any more.
This is more complicated upstream since Remmina needs to support older
distros that don't have libsoup3 available.

Thank you,
Jeremy Bicha

Bug#1015886: [Pkg-utopia-maintainers] Bug#1015886: Bug: kodi-data conflicts firewalld on file kodi-eventserver.xml

[Eric Garver]

On Sun, Jul 24, 2022 at 02:22:24PM +0200, Michael Biebl wrote:
> Control: reopen -1
> Control: severity -1 important
> Control: clone -1 -2
> Control: reassign -2 kodi
> Control: retitle -2 please ship firewalld service files
> Control: block -1 by -2
> 
> Am 24.07.22 um 08:12 schrieb Christian Marillat:
> > But why firewalld install services for packages not installed ?
> >
> > firewalld services must be managed as systemd does.
> 
> firewalld uses a hybrid approach.
> As you can see, it provides a lot of service definitions in
> /usr/lib/firewalld/services out of the box.
> 
> But individual packages can those ship service definitions as well. I think
> firewalld upstream actually prefers if those service definitions are shipped
> by the respective packages themselves.

I (firewalld maintainer) have no preference. I really think it's up to
the packages to make that decision. There are advantages to both.

The situation is very similar to SELinux policies.

Anyways, the firewalld change was reverted. Kodi itself will provide
these definitions.

https://github.com/firewalld/firewalld/pull/1002

Bug#1016118: pass: diff.gpg git options set onyl when using init

[eingousef]

Package: pass
Version: 1.7.4-5
Severity: normal
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

In case of a pass repo shared on a git server, a user who clones the repo won't 
see the plain text passwords when running `pass git log -p`, only the binary 
diffs.

This is because pass only sets the `diff.gpg.*` git options when running the 
`pass git init` command, see 
https://sources.debian.org/src/password-store/1.7.4-5/src/password-store.sh/#L661

For a user who never runs `pass git init` in his local repo, these options are 
not set automatically, and the doc doesn't mention they should be set manually. 
A user who clones a shared pass repo should expect it to behave on his machine 
exactly like it does on the repo creator's machine.

Maybe `pass` could automatically set the `diff.gpg.*` options when it's called 
with a git subcommand for the first time ?

Regards,

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages pass depends on:
ii  gnupg  2.2.35-3
ii  tree   2.0.2-1

Versions of packages pass recommends:
ii  git   1:2.35.1-1
pn  qrencode  
ii  xclip 0.13-2

Versions of packages pass suggests:
ii  libxml-simple-perl  2.25-1
ii  perl5.34.0-5
ii  python-is-python2 [python]  2.7.18-9
ii  python3 3.10.5-3
ii  ruby1:3.0+1

-- no debconf information

Bug#1016121: RM: kcm-fcitx5 -- ROM; Superceded by fcitx5-configtool

[Boyuan Yang]

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

Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/1016032 , src:fcitx5-configtool now
provides all binary packages of src:kcm-fcitx5. Now src:kcm-fcitx5 is
useless. 

As a result, please only remove source package src:kcm-fcitx5/5.0.14-1 from
Debian unstable. I believe no binary package removal is needed.

Thanks,
Boyuan Yang


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

Bug#1016122: dh_strip: will not strip shared library under a debug/ directory

[Antonio Terceiro]

Package: debhelper
Version: 13.8
Severity: normal
File: /usr/bin/dh_strip

Dear Maintainer,

While running lintian against a ruby3.1 build, I was presented with an
error tag from lintian:

E: libruby3.1: unstripped-binary-or-object 
[usr/lib/ruby/gems/3.1.0/extensions/x86_64-linux/3.1.0/debug-1.4.0/debug/debug.so]
N:
N:   The package installs an unstripped binary or object file.
N:
N:   Please note, that shared libraries have to be stripped with the 
--strip-unneeded option.
N:
N:   Please refer to Binaries (Section 10.1) in the Debian Policy Manual and 
Libraries (Section 10.2) in
N:   the Debian Policy Manual for details.
N:
N:   Visibility: error
N:   Show-Always: no
N:   Check: binaries/debug-symbols

In dh_strip, I could find this:

# Is it a debug library in a debug subdir?
return if $fn=~m{debug/.*\.so};
return if $fn=~m{/guile/.*\.go$};

So, this is an heuristic for excluding debug libraries, but in this case
the shared library in question is a debugger extension for Ruby, and it
could be stripped just fine.

I understand this is a corner case, but it would be nice if I could pass
some option to ensure this checks could be avoided and the file in
question could be stripped, i.e. the reverse of the -X option.

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.9
ii  dpkg-dev 1.21.9
ii  dwz  0.14-1
ii  file 1:5.41-4
ii  libdebhelper-perl13.8
ii  libdpkg-perl 1.21.9
ii  man-db   2.10.2-1
ii  perl 5.34.0-5
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202202

-- no debconf information


signature.asc
Description: PGP signature

Bug#1016123: tilda: fullscreen tilda ignores the dock when it's redimensioned after changing the output in xrandr

[eingousef]

Package: tilda
Version: 1.5.4-1
Severity: normal
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

Here is my use case :

I'm using tilda as a "terminal wallpaper", as described here : 
https://wiki.archlinux.org/title/terminal_as_a_transparent_wallpaper . 
Basically, tilda is launched automatically at my DE's startup, started visible, 
with a fullscreen configuration, visible on every desktop, with some degree of 
transparency, and set as a desktop window. I start a dock/taskbar program at 
DE's startup before launching tilda (basically I've configured openbox to start 
tint2, waint 3 seconds, and then start tilda), so tilda doesn't use the whole 
screen, only the part that is not occupied by the dock and those two don't 
overlap each other.

Everytime I plug a secondary monitor to the computer and do something like 
`xrandr --output DP-1 --auto`, the screen is refreshed and tilda tries to fill 
it, but tilda pops up 1 second or so before the dock, thus ignoring the space 
reserved for the dock. I have to go to tilda's preferences, in the Appearance 
tab, and click on the '-' and '+' buttons to bring it back to its original 
"fullscreen minus the dock space" size. Same thing when unplugging the 
secondary monitor and doing `xrandr --output DP-1 --off`.

If you don't have a secondary monitor you can simulate this behavior with 
something like `xrandr --output LVDS-1 --mode 1368x768 ; xrandr --output LVDS-1 
--auto` (change your monitor name and your non-default mode accordingly).

I suspect it would not be possible to make tilda somehow detect the dock before 
it's up when the screen refreshes, and that adding an option within tilda to 
delay the moment it appears on the screen would be a dirty hack. But I think it 
would be nice if you could somehow force the exact size of tilda on the screen 
by giving its width and height in pixels on the command line or within the 
configuration file. There are fields in the config wizard and the config file 
to give the width and height, but with my "terminal wallpaper" configuration, 
they are somehow ignored.

Regards,

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages tilda depends on:
ii  libc62.33-8
ii  libconfuse2  3.3-2
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.3-1
ii  libgtk-3-0   3.24.34-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  libvte-2.91-00.68.0-1+b1
ii  libx11-6 2:1.7.5-1

tilda recommends no packages.

tilda suggests no packages.

-- no debconf information

Bug#1012940: forwarded upstream

[Sophie Brun]

Control: forwarded -1 https://github.com/dl1ksv/gr-funcube/issues/7

I have forwarded the bug report to upstream.

Sophie

Bug#1016127: src:guestfs-tools: fails to migrate to testing for too long: FTBFS on i386 and ppc64el

[Paul Gevers]

Source: guestfs-tools
Version: 1.48.1-1
Severity: serious
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:guestfs-tools has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package failed to 
build from source on i386 and ppc64el while it built there successfully 
in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=guestfs-tools



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

[Peter B]

Hi Samuel,

Thanks for the suggestions. I've installed libc0.3-dbg, and also ended up with 
a much smaller backtrace.

Regarding
    "/../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory/"
Does this suggest a missing dependency?


Complete backtrace for a failing test.


Starting program: /home/demo/duma-2.5.21/dumatest

Thread 4 received signal ?, Unknown signal.
0x0104d996 in __pthread_mutex_lock (mtxp=0x8) at 
../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
30    ../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory.
#0  0x0104d996 in __pthread_mutex_lock (mtxp=0x8)
    at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
#1  0x01052af4 in __pthread_enable_asynccancel () at cancellation.c:28
#2  0x01198991 in __GI___libc_write (fd=2, buf=0x1038a2c, nbytes=235)
    at ../sysdeps/mach/hurd/write.c:25
#3  0x0803d7ee in DUMA_Print (
    pattern=0x803df60  "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington 
\nCopyright (C) 2002-2009 Hayati Ayguen , Procitec GmbH\nCopyright (C) 
1987-199"...) at print.c:331

#4  0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
    at duma.c:905
#5  0x0803aec9 in duma_init () at duma.c:943
#6  0x0803b2a2 in _duma_init () at duma.c:1138
#7  0x0803c436 in _duma_free (baseAdr=0x0,
    filename=0x803e060  "UNKNOWN (use #include \"duma.h\")",
    lineno=0) at duma.c:2003
#8  0x0803ccdd in free (address=0x0) at duma.c:2436
#9  0x010bf07b in __dcigettext (
    domainname=0x1267ac0 <_libc_intl_domainname> "libc",
    msgid1=, msgid2=, plural=,
    n=0, category=) at dcigettext.c:833
#10 0x010bdc9a in __GI___dcgettext (
    domainname=0x1267ac0 <_libc_intl_domainname> "libc",
    msgid=0x1267ae0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", category=5) at 
dcgettext.c:47
#11 0x010bcff2 in __GI___assert_fail (assertion=0x10538b5 "self != NULL", file=0x10538ab "pt-self.c", line=28, 
function=0x10538c4 <__PRETTY_FUNCTION__.1> "__pthread_self") at assert.c:101

#12 0x0104d33f in __pthread_self () at pt-self.c:28
#13 __pthread_self () at pt-self.c:25
#14 0x0803d0c7 in lock () at sem_inc.c:145
#15 0x0803d1d6 in DUMA_get_sem () at sem_inc.c:230
#16 0x0803afcc in _duma_init () at duma.c:1034
#17 0x0803c386 in _duma_malloc (size=716, filename=0x803e060  "UNKNOWN (use #include \"duma.h\")", 
lineno=0) at duma.c:1966

#18 0x0803cc8b in malloc (size=716) at duma.c:2424
#19 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124
#20 0x0104c773 in __pthread_create_internal (thread=0x1039d78, attr=0x1039d7c, start_routine=0x0, arg=0x0) at 
pt-create.c:120

#21 0x0105146b in _init_routine (stack=) at 
../sysdeps/mach/hurd/htl/pt-sysdep.c:66
#22 0x0001164b in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74
#23 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, l=) at dl-init.c:37
#24 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at 
dl-init.c:88
#25 0x2052 in _dl_start_user () from /lib/ld.so



Cheers,
Peter B

Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

[Peter B]

Attaching back trace logStarting program: /home/demo/duma-2.5.21/dumatest 

Thread 4 received signal ?, Unknown signal.
0x0104d996 in __pthread_mutex_lock (mtxp=0x8) at 
../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
30  ../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory.
#0  0x0104d996 in __pthread_mutex_lock (mtxp=0x8)
at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
#1  0x01052af4 in __pthread_enable_asynccancel () at cancellation.c:28
#2  0x01198991 in __GI___libc_write (fd=2, buf=0x1038a2c, nbytes=235)
at ../sysdeps/mach/hurd/write.c:25
#3  0x0803d7ee in DUMA_Print (
pattern=0x803df60  "DUMA, built 11/05/21 20:00:00 (static 
library)\nCopyright (C) 2006 Michael Eddington 
\nCopyright (C) 2002-2009 Hayati Ayguen 
, Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331
#4  0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
at duma.c:905
#5  0x0803aec9 in duma_init () at duma.c:943
#6  0x0803b2a2 in _duma_init () at duma.c:1138
#7  0x0803c436 in _duma_free (baseAdr=0x0, 
filename=0x803e060  "UNKNOWN (use #include \"duma.h\")", 
lineno=0) at duma.c:2003
#8  0x0803ccdd in free (address=0x0) at duma.c:2436
#9  0x010bf07b in __dcigettext (
domainname=0x1267ac0 <_libc_intl_domainname> "libc", 
msgid1=, msgid2=, plural=, 
n=0, category=) at dcigettext.c:833
#10 0x010bdc9a in __GI___dcgettext (
domainname=0x1267ac0 <_libc_intl_domainname> "libc", 
msgid=0x1267ae0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", category=5) at 
dcgettext.c:47
#11 0x010bcff2 in __GI___assert_fail (assertion=0x10538b5 "self != NULL", 
file=0x10538ab "pt-self.c", line=28, function=0x10538c4 <__PRETTY_FUNCTION__.1> 
"__pthread_self") at assert.c:101
#12 0x0104d33f in __pthread_self () at pt-self.c:28
#13 __pthread_self () at pt-self.c:25
#14 0x0803d0c7 in lock () at sem_inc.c:145
#15 0x0803d1d6 in DUMA_get_sem () at sem_inc.c:230
#16 0x0803afcc in _duma_init () at duma.c:1034
#17 0x0803c386 in _duma_malloc (size=716, filename=0x803e060  
"UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966
#18 0x0803cc8b in malloc (size=716) at duma.c:2424
#19 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124
#20 0x0104c773 in __pthread_create_internal (thread=0x1039d78, attr=0x1039d7c, 
start_routine=0x0, arg=0x0) at pt-create.c:120
#21 0x0105146b in _init_routine (stack=) at 
../sysdeps/mach/hurd/htl/pt-sysdep.c:66
#22 0x0001164b in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74
#23 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, 
l=) at dl-init.c:37
#24 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at 
dl-init.c:88
#25 0x2052 in _dl_start_user () from /lib/ld.so

Bug#1016130: ITP: asdf -- multiple language runtime version manager

[matt]

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

* Package name: asdf
  Version : 0.10.2
  Upstream Author : Akash Manohar J
* URL : https://asdf-vm.org
* License : MIT
  Programming Lang: Bash
  Description : multiple language runtime version manager

asdf is a CLI tool that can manage multiple language runtime
versions on a per-project basis. It is like gvm, nvm, rbenv
and pyenv (and more) all in one! Simply install your language's
plugin!

Bug#1012674: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[vollant.g]

Hello
There is no licence on this code, it is juste free!!

Regards
Gilles Vollant
-Message d'origine-
De : Bastian Germann  
Envoyé : samedi 11 juin 2022 16:32
À : sub...@bugs.debian.org
Objet : Bug#1012674: zlib: contrib/testzlib included (lintian: 
source-ships-excluded-file)

Source: zlib
Version: 1:1.2.11.dfsg-4
Severity: serious
Justification: non-free source in main
X-Debbugs-Cc: i...@winimage.com

Hi!

The contrib/testzlib files by Gilles Vollant  are rightfully 
marked to be excluded from Debian by d/copyright because they are unlicensed 
and thus non-free.

While 1:1.2.8.dfsg-5 still excluded the files, they have since reappeared.
Please fix this with a new orig tarball. There is even a new upstream version 
1.2.12 available which you could import and fix this without even changing the 
dfsg suffix!

I have copied the original author who might shine a light on the supposed 
license.
The zlib FAQ says that the contrib/ files have their own license but there is 
none for testzlib.

Thanks,
Bastian

Bug#1016132: perlindex: autopkgtest regression: Failed test 1 in t/basic.t at line 48

[Paul Gevers]

Source: perlindex
Version: 1.606-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
perlindex  from testing1.606-2
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=perlindex

https://ci.debian.net/data/autopkgtest/testing/amd64/p/perlindex/23178942/log.gz

t/basic.t .. 1..2
# Running under perl version 5.034000 for linux
# Current time local: Wed Jun 29 09:45:34 2022
# Current time GMT:   Wed Jun 29 09:45:34 2022
# Using Test.pm version 1.31
not ok 1
# Failed test 1 in t/basic.t at line 48
not ok 2
# Failed test 2 in t/basic.t at line 54
Failed 2/2 subtests
Test Summary Report
---
t/basic.t (Wstat: 0 Tests: 2 Failed: 2)
  Failed tests:  1-2
Files=1, Tests=2,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.03 cusr 
0.00 csys =  0.06 CPU)

Result: FAIL
autopkgtest [09:45:34]: test autodep8-perl-build-deps



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011716: Fwd: libbluray: FTBFS in bullseye: error: BDFileSystemImpl is not abstract and does not override abstract method isInvalid(File) in FileSystem

[Santiago Vila]

reopen 1011716
found 1011716 1:1.2.1-4+deb11u1
fixed 1011716 1:1.3.1-2
thanks

Hi. Since packages in stable must build in stable and this happens in
bullseye as well, please consider an upload for bullseye (or tell me how
I can help to have this fixed in bullseye).

Thanks.

Bug#1016131: libapache2-mod-jk: Apache does not start after upgrade (JkWorkersFile only allowed once)

[Thorsten Glaser]

Package: libapache2-mod-jk
Version: 1:1.2.48-1
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: t...@mirbsd.de

After upgrading from buster to bullseye, apache2 does not start any more
if libapache2-mod-jk was installed and active prior to the upgrading:

$ sudo cleanenv / /etc/init.d/apache2 start
Starting Apache httpd web server: apache2 failed!
The apache2 configtest failed. ... (warning).
Output of config test was:
AH00526: Syntax error on line 23 of /etc/apache2/mods-available/httpd-jk.conf:
JkWorkersFile only allowed once
Action 'configtest' failed.
The Apache error log may have more information.

This is caused by:

$ sudo fgrep -ri JkWorkersFile /etc/
/etc/apache2/mods-available/jk.conf:JkWorkersFile 
/etc/libapache2-mod-jk/workers.properties
/etc/apache2/mods-available/httpd-jk.conf:JkWorkersFile 
/etc/libapache2-mod-jk/workers.properties

Both files exist…

$ ll /etc/apache2/mods-available/jk.conf 
/etc/apache2/mods-available/httpd-jk.conf
-rw-r--r-- 1 root root 4802 Oct 14  2018 
/etc/apache2/mods-available/httpd-jk.conf
-rw-r--r-- 1 root root 4802 Jun  4  2020 /etc/apache2/mods-available/jk.conf

… and belong to the same package(!):

$ dpkg -S /etc/apache2/mods-available/jk.conf 
/etc/apache2/mods-available/httpd-jk.conf
libapache2-mod-jk: /etc/apache2/mods-available/jk.conf
libapache2-mod-jk: /etc/apache2/mods-available/httpd-jk.conf


My best guess is that the conffile was renamed but the renaming
process was done improperly / violating Policy.

As both files are identical…

$ md5sum /etc/apache2/mods-available/jk.conf 
/etc/apache2/mods-available/httpd-jk.conf
f6ebd56d10bf0dcb17d79b2133cb9f5c  /etc/apache2/mods-available/jk.conf
f6ebd56d10bf0dcb17d79b2133cb9f5c  /etc/apache2/mods-available/httpd-jk.conf

… I guess I can manually deactivate and remove one. Looking at
https://packages.debian.org/bullseye/libapache2-mod-jk and
https://packages.debian.org/bullseye/amd64/libapache2-mod-jk/filelist
httpd-jk.conf seems to be the one that has to go (this is a hint for
other people running into this issue).


The root cause of this is that applications using mod_jk in buster
had to do a workaround to load httpd-jk.conf due to #928813 so…

# work around Debian #928813

# either /etc/apache2/conf-available/httpd-jk.conf with a2enconf 
httpd-jk
# *or*   /etc/apache2/mods-available/jk.conf   with a2enmod jk
# would be correct, but here we are
Include /etc/apache2/mods-available/httpd-jk.conf


… ends up loading this twice because the old file was not removed
during the upgrade.

$ sudo rm /etc/apache2/mods-available/httpd-jk.conf
$ sudo cleanenv / /etc/init.d/apache2 start
Starting Apache httpd web server: apache2 ..

This helped, indeed.



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

Kernel: Linux 4.19.0-21-amd64 (SMP w/3 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libapache2-mod-jk depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.54-1~deb11u1
ii  libc6   2.31-13+deb11u3

libapache2-mod-jk recommends no packages.

Versions of packages libapache2-mod-jk suggests:
pn  libapache-mod-jk-doc  
ii  tomcat9   9.0.64-1wtf1

-- no debconf information

Bug#1012674: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Wed, Jul 27, 2022 at 09:00:09PM +0200, vollan...@gmail.com wrote:

> There is no licence on this code, it is juste free!!

If that's the goal they should have a clear statement that they're in
the public domain, without an explicit license grant of some kind the
default is that things are copyrighted and all rights reserved.


signature.asc
Description: PGP signature

Bug#1016129: [fgont/ipv6toolkit] Cannot send packets in one direction (other works) (Issue #78)

[Thorsten Glaser]

Cc libpcap maintainers; context is #1016129 on debbugs.

From diffing around between a buster and a bullseye system, I could
track this bug down:

libpcap0.8:
 1.10.0-2 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
 1.10.0-2~bpo10+1 100
100 http://deb.debian.org/debian buster-backports/main amd64 Packages
 1.8.1-6+deb10u1 500
500 http://deb.debian.org/debian buster/main amd64 Packages

Installing 1.10.0-2~bpo10+1 on buster breaks ipv6toolkit.

Installing 1.10.0-2~bpo10+1 on bullseye does not fix ipv6toolkit,
installing 1.8.1-6+deb10u1 on bullseye (which temporarily breaks
tcpdump) does fix ipv6toolkit.

So there’s either something in the newer libpcap that breaks
ipv6toolkit, or something in ipv6toolkit that’s not yet compatible
with newer libpcap.

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec

Bug#1016125: libgnupg-interface-perl as invoked via caff fails to detect gpg version

[Guido Günther]

Package: libgnupg-interface-perl
Version: 1.02-1
Severity: normal

When using caff fails to detect the gpg version and aborts:

$ caff -S -m no  < dc22_fprs.txt 
[NOTICE] Importing GnuPG options from /path/to/gnupg
[NOTICE] no-emit-version
[NOTICE] no-comments
[NOTICE] personal-digest-preferences SHA256
[NOTICE] cert-digest-algo SHA256
[NOTICE] keyserver keyserver.ubuntu.com
[NOTICE] Reading gpgparticipants formatted input on STDIN
[NOTICE] Found SHA256 checksum (marked as verified, assumed good)
[NOTICE] Found RIPEMD160 checksum (marked as verified, assumed good)
[INFO] Ignoring fingerprint F2FAAC0D44C32D8B98539B9297A0FA0FC8F2DE45
[INFO] Ignoring fingerprint 31D80509460EFB31DF4B9629FB0E132DDB0AA5B1
...
[INFO] Adding fingerprint C0FE9DAC51E5CAF10DBE7DFC5E62533F19765111
[INFO] Ignoring fingerprint 16A1100AB78A62494F912A7812580AC9CE1FA236
[INFO] Ignoring fingerprint 140F202C78F643A57CE8B8F449C3BF8927553D2E
...
[INFO] Ignoring fingerprint 29CBDA84E741069F3ECD903B3C204B27F7BA6EE3
gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr'
gpg-connect-agent: waiting for the dirmngr to come up ... (5s)
gpg-connect-agent: connection to dirmngr established
error determining fileno for STDIN: Illegal seek at (eval 235) line 55.
Use of uninitialized value $line in pattern match (m//) at 
/usr/share/perl5/GnuPG/Interface.pm line 827.
Use of uninitialized value $a in split at /usr/share/perl5/GnuPG/Interface.pm 
line 841.
Use of uninitialized value $a in split at /usr/share/perl5/GnuPG/Interface.pm 
line 841.
GnuPG Version 1.4 or 2.2+ required at (eval 235) line 55.

Though gpg is installed:

$ gpg --version
gpg (GnuPG) 2.2.35
libgcrypt 1.10.1
Copyright (C) 2022 g10 Code GmbH
License GNU GPL-3.0-or-later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/agx/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

I've filed this against libgnupg-interface-perl as this seems to be the
bit that has issues to get the version. Please reassing if I got this
wrong.

Cheers,
 -- Guido


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

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

Versions of packages signing-party depends on:
ii  gnupg  2.2.35-3
ii  libc6  2.33-8
ii  libclass-methodmaker-perl  2.24-2+b2
ii  libgnupg-interface-perl1.02-1
ii  libmailtools-perl  2.21-1
ii  libmd0 1.0.4-2
ii  libmime-tools-perl 5.510-1
ii  libnet-idn-encode-perl 2.500-2+b1
ii  libterm-readkey-perl   2.38-1+b3
ii  libtext-template-perl  1.61-1
ii  perl   5.34.0-5
ii  python33.10.5-3
ii  qprint 1.1.dfsg.2-2.1

Versions of packages signing-party recommends:
pn  default-mta | mail-transport-agent  
ii  dialog  1.3-20211214-1
ii  libgd-perl [libgd-gd2-perl] 2.76-2+b1
ii  libpaper-utils  1.1.28+b1
ii  whiptail0.52.21-5+b2

Versions of packages signing-party suggests:
pn  fonts-noto-cjk   
ii  fonts-noto-mono  20201225-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b2
hi  mutt 2.2.3-1
ii  qrencode 4.1.1-1
pn  texlive-font-utils   
ii  texlive-latex-extra  2022.20220605-1
ii  texlive-latex-recommended2022.20220605-1
ii  texlive-xetex2022.20220605-1
ii  wipe 0.24-9

-- no debconf information

Bug#900849: allowing alternative country lists on a Debian host/installer

[Steve McIntyre]

Hey folks,

I've not seen any followup on Ian's excellent proposals here - how do
make some progress on this please?

On Wed, Jun 06, 2018 at 03:31:33PM +0100, Ian Jackson wrote:
>
>I conclude that:
>
> * The description of the list should be changed from "countries" to
>   "regions and countries".
>
> * An entry should be provided in this list (specifically, a region
>   should be broken out from any possible parent(s)) when any of the
>   following are true:
>  (i) The region wants to have different configuration or
>  different defaults;
>  (ii) Users may not recognise the parent region name(s) as
>  applicable to them
>   This also applies when the region is not strictly speaking bounded
>   geographically.  For example, it applies when considering different
>   different political alignments (or, perhaps cultural, religious or
>   or ethnic groups) of people within a single geogrpahic region.
>
> * If there would otherwise be a large number of entries for a
>   particular region or country, use of a submenu is appropriate.
>
> * Names should be primarily chosen so that users know what entry to
>   pick in the menu; but it is reasonable to try to avoid giving
>   offence.
>
>Some worked examples:
>
> * Kosovo obviously needs to have its own entry.
>
> * Taiwan and the PRC need to be different entries.  The Taiwan one
>   should probably be labelled "Taiwan (ROC)", and the PRC one "China
>   (PRC)" because those will be recognised by more people and give
>   less offence.
>
> * In principle, there should be an entry for Uyghurs in Xinjiang who
>   wish to use the region's unofficial timezone (which is more suited
>   to local solar time than official PRC time), and the Uyghur
>   language.  But in practice actually selecting such an option in
>   one's computer configuration is likely to be very dangerous[1]
>   so we might be doing Uyghur users a disservice by offering them
>   this option.  This is a difficult case.
>
> * I think it will be necessary to have separate options in Bosnia
>   for the Federation of Bosnia and Herzegovina on the one hand,
>   and for the Republika Srpska on the other.
>
> * Belgium needs two entries.  AIUI the keyboards as well as the
>   languages are different.
>
> * AIUI it would not be necessary to provide any entries for Kashmir;
>   the user can select India or Pakistan as appropriate.
>
>I could be wrong about the details above.
>
>Ian.
>
>[1] see eg
>  
> https://www.economist.com/briefing/2018/05/31/china-has-turned-xinjiang-into-a-police-state-like-no-other
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#1016087: dpkg: errors about cannot verify signature for assorted packages

[tmcconnell168]

Hi Guillem, 
>I assume you have something installed that downloads source packages
> (and perhaps builds them) as part of the upgrade?
Gnome Software and I left sources.list pretty much as it came from the
net install CD. 
So I'm getting this because some packages no longer have a maintainer,
that sucks, hope you guys get some more maintainers for those projects.
Either way, thanks for the clear explanation of why it's happening and
where the warnings are coming from. 
If it's not really a bug I guess it's okay to close it and sorry for
wasting your time. 
Have a great day! 
 
-- 
 


On Wed, 2022-07-27 at 12:25 +0200, Guillem Jover wrote:
> Control: reassign -1 dpkg-dev 1.21.9
> Control: tag -1 moreinfo
> 
> Hi!
> 
> On Tue, 2022-07-26 at 14:24:41 -0500, Tim McConnell wrote:
> > Package: dpkg
> > Version: 1.21.9
> > Severity: normal
> > X-Debbugs-Cc: tmcconnell...@gmail.com
> 
> > What led up to the situation? Normal upgrading of system
> > 
> > What exactly did you do (or not do) that was effective (or
> > ineffective)? Unsure
> > these messages started appearing.
> > 
> > What was the outcome of this action? I now receive multiple lines
> > of: gpgv:
> > Signature made Fri 24 Oct 2014 06:23:17 PM CDT
> > gpgv:    using RSA key F664D256B4691A7D
> > gpgv: Can't check signature: No public key
> > dpkg-source: warning: cannot verify signature
> > /var/cache/apt/sources/libtrio_1.16+dfsg1-3.dsc
> > gpgv: Signature made Tue 03 May 2022 09:04:38 PM CDT
> > gpgv:    using RSA key A1489FE2AB99A21A
> > gpgv: Note: signatures using the SHA1 algorithm are rejected
> > gpgv: Can't check signature: Bad public key
> > dpkg-source: warning: cannot verify signature
> > /var/cache/apt/sources/r-cran-
> > quantreg_5.93-1.dsc
> > gpgv: Signature made Wed 20 Jul 2022 05:25:03 AM CDT
> > gpgv:    using RSA key A1489FE2AB99A21A
> > gpgv: Note: signatures using the SHA1 algorithm are rejected
> > gpgv: Can't check signature: Bad public key
> > dpkg-source: warning: cannot verify signature
> > /var/cache/apt/sources/r-cran-
> > quantreg_5.94-1.dsc
> > apt-listdifferences: removing old src:r-cran-quantreg 5.93-1
> > gpgv: Signature made Fri 27 May 2022 04:42:52 AM CDT
> > gpgv:    using RSA key
> > 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
> > gpgv: Note: signatures using the SHA1 algorithm are rejected
> > gpgv: Can't check signature: Bad public key
> > dpkg-source: warning: cannot verify signature
> > /var/cache/apt/sources/kconfig_5.94.0-3.dsc
> > gpgv: Signature made Sat 23 Jul 2022 05:20:34 AM CDT
> > gpgv:    using RSA key
> > 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
> > gpgv: Note: signatures using the SHA1 algorithm are rejected
> > gpgv: Can't check signature: Bad public key
> > dpkg-source: warning: cannot verify signature
> > /var/cache/apt/sources/kconfig_5.94.0-4.dsc
> > 
> > When running this command `apt-get dist-upgrade -y -m`
> 
> I assume you have something installed that downloads source packages
> (and perhaps builds them) as part of the upgrade? Otherwise that
> seems
> uncommon. In any case…
> 
> > What outcome did you expect instead? To be sure I'm getting
> > packages from an
> > uncompromised repo.
> 
> … assuming you are getting the source packages from a Debian
> repository, those should have the repository mataindices signed by
> the
> archive keys, which get rotated and updated when necessary, in
> contrast
> to the source package signatures which are created by the person
> uploading
> the source package (and never updated anymore). As such those latter
> signatures (when later verified after the archive did the initial
> verification on upload) can very easily come from now revoked or
> expired
> keys or from keys for people that are no longer members of the
> project
> and are thus not present in the keyrings, the signatures can be
> expired
> themselves, they might come from keys or signatures which are now
> considered weak, which is what happens to be the case here. These
> signatures use SHA1 as a hashing algorithm which is no longer
> considered
> secure and get rejected.
> 
> For the above reasons apt passes --no-check to dpkg-source, and
> dpkg-source does not default to erroring out (unless passing to it
> --require-valid-signature), as can be seen from the warnings (not
> errors) shown above. So I see no dpkg bug here, perhaps whatever is
> calling dpkg-source should also be passing --no-check (if it can
> guarantee the source came from a verified repo). Otherwise I'll be
> closing this in a bit.
> 
> Thanks,
> Guillem

Bug#917541: Whoops, I packaged this

[Wouter Verhelst]

Hi,

I uploaded a version of python-xxhash to NEW the other day:

https://ftp-master.debian.org/new/python-xxhash_3.0.0-1.html

I had somehow missed this ITP bug, and so completely ignored the
packaging work that had already been done.

I have no particular interest in this package, other than "mycroft
requires it", and I am working on getting that into Debian (see
#893788); so if someone who had been working on the package wants to
take it off my hands, just go ahead. I won't be upset, promise!

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#1016126: freeipa-server required libndr.so.1 and it's present only on Debian stable version

[Lucas Castro]

Package: freeipa-server
Version: 4.9.8-1+exp1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: lu...@gnuabordo.com.br

Dear Maintainer,

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

   * What led up to the situation?

I tried to install freeipa-server just for testing environment.
The environment is Debian fresh installation in lxc container.

Installation ends up with an error when it try to create the REALM 
kdb5_util: Unable to load requested database module 'ipadb.so': plugin symbol 
'kdb_function_table' not found while creating database 
'/var/lib/krb5kdc/principal'

So I investigated the library required by ipadb.so 
ldd /usr/lib/x86_64-linux-gnu/krb5/plugins/kdb/ipadb.so
 it's noticed libndr.so.1 is required and not present. 
 The required library is present by samba-libs on Debian bullseye, the
 stable version by now. 

 Unstable and Sid version install libndr.so.2 in turn. 


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


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

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

Versions of packages freeipa-server depends on:
ii  389-ds-base 2.0.15-1+b1
ii  acl 2.3.1-1
ii  adduser 3.123
ii  apache2 2.4.54-2
ii  certmonger  0.79.15-1+b2
ii  chrony  4.2-2
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  fonts-open-sans 1.11-2
ii  freeipa-client  4.9.8-1+exp1
ii  freeipa-common  4.9.8-1+exp1
ii  gssproxy0.8.4-2
ii  krb5-admin-server   1.20-1
ii  krb5-kdc1.20-1
ii  krb5-kdc-ldap   1.20-1
ii  krb5-otp1.20-1
ii  krb5-pkinit 1.20-1
ii  ldap-utils  2.5.12+dfsg-2
ii  libapache2-mod-auth-gssapi  1.6.3-1+b1
ii  libapache2-mod-lookup-identity  1.0.0-1
ii  libapache2-mod-wsgi-py3 4.9.0-1+b1
ii  libc6   2.33-8
ii  libgssapi-krb5-21.20-1
ii  libjs-dojo-core 1.15.4+dfsg1-1
ii  libjs-jquery3.6.0+dfsg+~3.5.13-1
ii  libjs-scriptaculous 1.9.0-2.1
ii  libk5crypto31.20-1
ii  libkrad01.20-1
ii  libkrb5-3   1.20-1
ii  libldap-2.4-2   2.4.59+dfsg-1+b1
ii  libnss3-tools   2:3.81-1
ii  libpopt01.18-3
ii  libpwquality1   1.4.4-1+b1
ii  libsasl2-modules-gssapi-mit 2.1.28+dfsg-6
ii  libssl1.1   1.1.1o-1
ii  libsss-certmap0 2.7.3-1
ii  libsss-nss-idmap0   2.7.3-1
ii  libtalloc2  2.3.3-4
ii  libunistring2   1.0-1
ii  libuuid12.38-5
ii  libverto1   0.3.1-1
ii  libwbclient02:4.16.3+dfsg-1
ii  oddjob  0.34.7-1
ii  p11-kit 0.24.1-1
ii  pki-ca  11.0.3-4
ii  pki-kra 11.0.3-4
ii  python3 3.10.5-3
ii  python3-dateutil2.8.1-6
ii  python3-gssapi  1.6.12-2+b1
ii  python3-ipaserver   4.9.8-1+exp1
ii  python3-ldap3.4.0-2+b1
ii  python3-systemd 234-4+b1
ii  samba-libs  2:4.16.3+dfsg-1
ii  slapi-nis   0.56.7-1
ii  ssl-cert1.1.2
ii  sssd-dbus   2.7.3-1
ii  systemd-sysv251.3-1

Versions of packages freeipa-server recommends:
ii  freeipa-server-dns  4.9.8-1+exp1

freeipa-server suggests no packages.

-- no debconf information

Bug#1013662: core-async-clojure: FTBFS randomly in bullseye

[Santiago Vila]

reopen 1013662
retitle 1013662 core-async-clojure: FTBFS randomly in bullseye
found 1013662 1.3.610-4
fixed 1013662 1.3.610-6
thanks

Hi. Since packages in stable must build in stable and this happens in 
bullseye as well, please consider an upload for bullseye (or tell me how 
I can help to have this fixed in bullseye).


The package not only fails 100% of the time on single-CPU systems (which 
is already annoying enough), the build appears to be extremely 
unreliable on multi-core systems (it fails randomly around 50% of the 
time on my own autobuilders having 2 CPUs).


Thanks.

Bug#1016087: dpkg: errors about cannot verify signature for assorted packages

[Guillem Jover]

On Wed, 2022-07-27 at 11:10:13 -0500, tmcconnell...@gmail.com wrote:
> >I assume you have something installed that downloads source packages
> > (and perhaps builds them) as part of the upgrade?

> Gnome Software and I left sources.list pretty much as it came from the
> net install CD. 

Hmm, I've checked gnome-software and I don't see anything obvious there
that would cause sources to be downloaded. After looking for something
using the /var/cache/apt/sources/ pathname, I've found
apt-listdifferences which seems like a matching culprit. Do you happen
to have that installed? If so, the problem is that it calls debdiff,
which always verifies signatures, even though apt-listdifferences
downloaded it from the archive, so there should be no need for that.
Then I'd reassign to apt-listdifferences which would need a new option
in debdiff to be able to request passing --no-check to dpkg-source.

> So I'm getting this because some packages no longer have a maintainer,
> that sucks, hope you guys get some more maintainers for those projects.

Not necessarily, it might well be that these packages did not get
uploaded after these maintainers updated their OpenPGP keys, and have
remained with weak signatures. We should probably add some QA check
(if there's none yet in place), to catch that, I'll check that out
too.

Thanks,
Guillem

Bug#1016133: fpga-icestorm: autopkgtest regression: new test can't be run on s390x due to missing yosys

[Paul Gevers]

Source: fpga-icestorm
Version: 0~20220603git2bc5417-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
fpga-icestorm  from testing0~20220603git2bc5417-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems to 
need to mark your new test to be not executed on s390x. You can do so by 
adding an "Architecture: !s390x" line to the new test definition in 
d/t/control.


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=fpga-icestorm

https://ci.debian.net/data/autopkgtest/testing/s390x/f/fpga-icestorm/24083107/log.gz

Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) autopkgtest-satdep:s390x < 0 @iU K Nb Ib >
Broken autopkgtest-satdep:s390x Depends on yosys:s390x < none @un H >
  Removing autopkgtest-satdep:s390x because I can't find yosys:s390x
Done


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016087: apt-listdifferences: Indirectly calls dpkg-source w/o --no-check

[Guillem Jover]

Control: tag -1 - moreinfo
Control: reassign -1 apt-listdifferences
Control: retitle -1 apt-listdifferences: Indirectly calls dpkg-source w/o 
--no-check

[ Replying to the initial report for some context. ]

Hi!

On Tue, 2022-07-26 at 14:24:41 -0500, Tim McConnell wrote:
> Package: dpkg
> Version: 1.21.9
> Severity: normal
> X-Debbugs-Cc: tmcconnell...@gmail.com

> What led up to the situation? Normal upgrading of system
> 
> What exactly did you do (or not do) that was effective (or ineffective)? 
> Unsure
> these messages started appearing.
> 
> What was the outcome of this action? I now receive multiple lines of: gpgv:
> Signature made Fri 24 Oct 2014 06:23:17 PM CDT
> gpgv:using RSA key F664D256B4691A7D
> gpgv: Can't check signature: No public key
> dpkg-source: warning: cannot verify signature
> /var/cache/apt/sources/libtrio_1.16+dfsg1-3.dsc
> gpgv: Signature made Tue 03 May 2022 09:04:38 PM CDT
> gpgv:using RSA key A1489FE2AB99A21A
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
> quantreg_5.93-1.dsc
> gpgv: Signature made Wed 20 Jul 2022 05:25:03 AM CDT
> gpgv:using RSA key A1489FE2AB99A21A
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
> quantreg_5.94-1.dsc
> apt-listdifferences: removing old src:r-cran-quantreg 5.93-1
> gpgv: Signature made Fri 27 May 2022 04:42:52 AM CDT
> gpgv:using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature
> /var/cache/apt/sources/kconfig_5.94.0-3.dsc
> gpgv: Signature made Sat 23 Jul 2022 05:20:34 AM CDT
> gpgv:using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
> gpgv: Note: signatures using the SHA1 algorithm are rejected
> gpgv: Can't check signature: Bad public key
> dpkg-source: warning: cannot verify signature
> /var/cache/apt/sources/kconfig_5.94.0-4.dsc
> 
> When running this command `apt-get dist-upgrade -y -m`
> 
> What outcome did you expect instead? To be sure I'm getting packages from an
> uncompromised repo.

The problem here in the end was (confirmed off-BTS) that
apt-listdifferences is installed on the system, which downloads the
source packages for binary packages being upgraded to debdiff them.
But those source packages had been signed with a weak algorithm, which
is rejected by dpkg-source (even though that command defaults to
warning only).

Because when downloading the source packages from the archive, they
have switched their trust anchor from the uploader to the archive,
which takes care of key (re)signing, expiration and rotation, checking
the signatures in the .dsc can be more confusing than helpful. (This
would be a different matter if the .dsc reached the system through
some other means such as scp or sneaker net or whatever).

So, ideally apt-listdifferences would call debdiff and request for it
to pass --no-check to dpkg-source. But there is currently no such
option. I'll file another report, and block this one with that other
one.

Thanks,
Guillem

Bug#1015902: choqok: Choqok doesn't start and uses 100% CPU

[Lisandro Damián Nicanor Pérez Meyer]

tag 1015902 unreproducible moreinfo
thanks

Hi!

On Sat, 23 Jul 2022 at 12:03, Brad Rogers  wrote:
>
> Package: choqok
> Version: 1.7.0-1
> Severity: important
> X-Debbugs-Cc: b...@fineby.me.uk
>
> Dear Maintainer,
>
>
> Start Choqok as normal (click on menu item), program starts, but never 
> completes initialising and continues
> to display startup banner. I discovered the error-
> kf.config.core: "\"repeatedDateTime\" - conversion of \"0,0,0,-1,-1,-1.001\" 
> to QDateTime failed"
> is continuously emitted to .xsession-errors
> Only way to quit was to kill Choqok.
>
> Although I only noticed this bevauiour for the first time today, I don't know 
> what/when the problem really started as I only
> rebott my system infrequently.  Last reboot, prior to today, was probably two 
> weeks ago.

I definitely can't reproduce the issue. Sounds like your system might
have been upgraded and you keep your session opened. Please try at
very least restarting your X session, but rebooting my be a good
thing. If it does not works please try with a new user.

Bug#1016129: ipv6toolkit: Error while performing Neighbor Discovery for the Destination Address

[Thorsten Glaser]

Package: ipv6toolkit
Version: 2.0+ds.1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: t...@mirbsd.de
Control: forwarded -1 https://github.com/fgont/ipv6toolkit/issues/78

$ sudo tcp6 -i eth1 -d fec0::1 -y 500 -a 13 -P 600
Error while performing Neighbor Discovery for the Destination Address
Error while learning Souce Address and Next Hop
$ sudo udp6 -i eth1 -d fe80::5054:ff:fe76:ba6 -y 500 -a 13 -P 600 -s 
fe80::5054:ff:feb7:47b9
Error while performing Neighbor Discovery for the Destination Address
Error while learning Souce Address and Next Hop

Background info:

$ ip a show dev eth1
3: eth1:  mtu 1500 qdisc jhtb state UP group 
default qlen 1000
link/ether 52:54:00:b7:47:b9 brd ff:ff:ff:ff:ff:ff
altname enp0s7
altname ens7
inet 10.82.222.130/25 brd 10.82.222.255 scope global eth1
   valid_lft forever preferred_lft forever
inet6 fec0::2/64 scope site 
   valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:feb7:47b9/64 scope link 
   valid_lft forever preferred_lft forever
$ ping6 fec0::1
PING fec0::1(fec0::1) 56 data bytes
64 bytes from fec0::1: icmp_seq=1 ttl=64 time=0.477 ms
64 bytes from fec0::1: icmp_seq=2 ttl=64 time=0.353 ms
^C
--- fec0::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.353/0.415/0.477/0.062 ms


I suspect that this broke with the upgrade from buster to bullseye
because it worked in one direction (fec0::2→1) before whereas the
other didn’t (fec0::1 already ran bullseye).

Downgrading just the ipv6toolkit package did not help.


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

Kernel: Linux 5.10.0-16-amd64 (SMP w/3 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages ipv6toolkit depends on:
ii  ieee-data   20210605.1
ii  libc6   2.31-13+deb11u3
ii  libpcap0.8  1.10.0-2

ipv6toolkit recommends no packages.

ipv6toolkit suggests no packages.

-- no debconf information

Bug#1013578: golang-github-prometheus-exporter-toolkit: FTBFS in bullseye

[Santiago Vila]

found 1013578 0.5.1-2
thanks

This also happens in stable.

Bug#802612: fakeroot fails in user namespaces (EINVAL / Invalid argument)

[Parke]

For posterity...

As of 2022 and fakeroot 1.29 (and maybe earlier, too), it appears
there is an udocumented environment variable that can be set to
prevent fakeroot from ever calling chown().

Try:
export  FAKEROOTDONTTRYCHOWN='1'

Then run fakeroot.

Source (in fakeroot version 1.29):
https://salsa.debian.org/clint/fakeroot/-/blob/debian/1.29-1/libfakeroot.c#L646
https://salsa.debian.org/clint/fakeroot/-/blob/debian/1.29-1/libfakeroot.c#L865

Bug#961834: clearlooks-phenix-theme

[Jeremy Bicha]

On Fri, Jul 22, 2022 at 10:30 AM David Daynard  wrote:
> This package is unmaintained upstream since 2016. There is a maintained fork 
> at https://github.com/jsane-h8ms/clearlooks-phenix which adds support for 
> using the theme under Mate as well as removing the many GTK deprecation 
> warnings this theme currently creates.
>
> This should fix most of the other open bugs against this package as well.

Could you ask the fork maintainer if they'd be willing to tag a new release?

Thank you,
Jeremy Bicha

Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

[Samuel Thibault]

Re,

Samuel Thibault, le mer. 27 juil. 2022 23:35:46 +0200, a ecrit:
> Peter B, le mer. 27 juil. 2022 18:02:53 +0100, a ecrit:
> > #11 0x010bcff2 in __GI___assert_fail (assertion=0x10538b5 "self != NULL",
> > file=0x10538ab "pt-self.c", line=28, function=0x10538c4
> > <__PRETTY_FUNCTION__.1> "__pthread_self") at assert.c:101
> > #12 0x0104d33f in __pthread_self () at pt-self.c:28
> > #13 __pthread_self () at pt-self.c:25
> > #14 0x0803d0c7 in lock () at sem_inc.c:145
> > #15 0x0803d1d6 in DUMA_get_sem () at sem_inc.c:230
> > #16 0x0803afcc in _duma_init () at duma.c:1034
> > #17 0x0803c386 in _duma_malloc (size=716, filename=0x803e060 
> > "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966
> > #18 0x0803cc8b in malloc (size=716) at duma.c:2424
> > #19 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124
> > #20 0x0104c773 in __pthread_create_internal (thread=0x1039d78,
> > attr=0x1039d7c, start_routine=0x0, arg=0x0) at pt-create.c:120
> > #21 0x0105146b in _init_routine (stack=) at 
> > ../sysdeps/mach/hurd/htl/pt-sysdep.c:66
> > #22 0x0001164b in call_init (l=, argc=argc@entry=1, 
> > argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74
> > #23 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, 
> > l=) at dl-init.c:37
> > #24 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at 
> > dl-init.c:88
> > #25 0x2052 in _dl_start_user () from /lib/ld.so
> 
> Ok, that confirms what I was guessing: libpthread is initializing
> itself, and for that uses a dynamic allocation, during which duma calls
> pthread_self, which cannot work yet.
> 
> Ideally libpthread would not need to allocate anything for its
> initialization, but that's really tricky. Possibly we can trick
> pthread_self into being callable very early.

Could you try with the libc from 

https://people.debian.org/~sthibault/tmp/hurd-i386/

Samuel

Bug#1014682: FTBFS with fmtlib 9.0.0

[Shengjing Zhu]

On Sun, Jul 10, 2022 at 4:57 PM Shengjing Zhu  wrote:
>
> Source: bear
> Version: 3.0.19-1
> Severity: important
> Tags: ftbfs
> Forwarded: https://github.com/rizsotto/Bear/issues/471
> X-Debbugs-Cc: z...@debian.org
>
> I have uploaded fmtlib 9.0.0 to experimental. During rebuild the reverse
> dependencies, your package FTBFS.

New version release, which addresses build failure with fmt-9.0.0.
Please package the new version.

https://github.com/rizsotto/Bear/releases/tag/3.0.20

-- 
Shengjing Zhu

Bug#1015902: choqok: Choqok doesn't start and uses 100% CPU

[Brad Rogers]

On Wed, 27 Jul 2022 14:59:50 -0300
Lisandro Damián Nicanor Pérez Meyer  wrote:

Hello Lisandro,

>I definitely can't reproduce the issue. Sounds like your system might
>have been upgraded and you keep your session opened. Please try at

That might have been part of the problem, yes.  Although it's never been
an issue before.

>very least restarting your X session, but rebooting my be a good
>thing. If it does not works please try with a new user.

Yes, this also occurred after a reboot.  Sorry, I forgot to mention it.
However, everything works okay as another user.
Inspired by that, I moved everything Choqok related out of ~/.cache,
~/.config and ~/.local.  Normal behaviour has been resumed.

Sorry for the noise.

Bug#1015930: lists.debian.org: Please create debian-livecoding

[Daniel Lenharo]

I support the creation of this list!

Joenio brought up this topic at DC22 and a lot of people seem to be 
interested in it.



Best Regards

--
Daniel Lenharo
Curitiba - Brazil
www.sombra.eti.br
31D8 0509 460E FB31 DF4B
9629 FB0E 132D DB0A A5B1



OpenPGP_0xFB0E132DDB0AA5B1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

[Samuel Thibault]

Hello,

Peter B, le mer. 27 juil. 2022 18:02:53 +0100, a ecrit:
> Regarding
>     "/../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory/"
> Does this suggest a missing dependency?

No it's just that you don't have the glibc source code in your current
directory :)

> #11 0x010bcff2 in __GI___assert_fail (assertion=0x10538b5 "self != NULL",
> file=0x10538ab "pt-self.c", line=28, function=0x10538c4
> <__PRETTY_FUNCTION__.1> "__pthread_self") at assert.c:101
> #12 0x0104d33f in __pthread_self () at pt-self.c:28
> #13 __pthread_self () at pt-self.c:25
> #14 0x0803d0c7 in lock () at sem_inc.c:145
> #15 0x0803d1d6 in DUMA_get_sem () at sem_inc.c:230
> #16 0x0803afcc in _duma_init () at duma.c:1034
> #17 0x0803c386 in _duma_malloc (size=716, filename=0x803e060 
> "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966
> #18 0x0803cc8b in malloc (size=716) at duma.c:2424
> #19 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124
> #20 0x0104c773 in __pthread_create_internal (thread=0x1039d78,
> attr=0x1039d7c, start_routine=0x0, arg=0x0) at pt-create.c:120
> #21 0x0105146b in _init_routine (stack=) at 
> ../sysdeps/mach/hurd/htl/pt-sysdep.c:66
> #22 0x0001164b in call_init (l=, argc=argc@entry=1, 
> argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74
> #23 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, 
> l=) at dl-init.c:37
> #24 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at 
> dl-init.c:88
> #25 0x2052 in _dl_start_user () from /lib/ld.so

Ok, that confirms what I was guessing: libpthread is initializing
itself, and for that uses a dynamic allocation, during which duma calls
pthread_self, which cannot work yet.

Ideally libpthread would not need to allocate anything for its
initialization, but that's really tricky. Possibly we can trick
pthread_self into being callable very early.

(this is probably working on Linux only by luck)

Samuel

Bug#1008082: How to --lock an account

[Matt Barry]

On Wed, 2022-07-27 at 15:21 +0200, Marc Haber wrote:
> On Wed, Jul 27, 2022 at 09:12:50AM -0400, Jason Franklin wrote:
> For a normal user account, I am undecided whether:
> 
> - leave login shell intact, leaving a possible security hole
> - set login shell back to the default when the account gets reenabled
> - save login shell somewhere to reinstate if on reenabling.

Maybe have adduser prompt when using --unlock (and without -s) whether
to reset the shell to the default?  (just #2, but more explicit)

Then again a single colon-separated file to check *before* selecting
the default isn't a ton of added complexity.  

Contrary to the behavior of usermod(8), I personally think adding the
additional barrier to access is a feature.

> I'd say, do it as you see fit

Me too :)

mb


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

Bug#1016144: codequery: Exuberant Ctags dependency should be optional

[Oliver Schode]

Package: codequery
Version: 0.24.0+dfsg1-1
Severity: minor

Hi!


exuberant-ctags was superseded by universal-ctags that's been in Debian
for a couple of years now. Codequery's website explicitly states both
are supported and I can confirm as much. Please add universal-ctags as
an alternative, thanks.

Oliver

Bug#1016143: dpkg --audit could report more errors, especially those reported elsewhere already

[Thorsten Glaser]

Package: dpkg
Version: 1.20.11
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I had a filesystem corruption (had to run e2fsck -D for some reason, the
filesystem was otherwise intact, fresh install) that resulted in…

dpkg: unrecoverable fatal error, aborting:
 files list file for package 'libv4l-0:amd64' is missing final newline

… during an apt-get --purge dist-upgrade (which only updated firefox
and linux) or rather preventing it.

This was not spotted by dpkg --audit, which I had run after the fsck.
It probably can easily be added there?


-- Package-specific info:

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

Kernel: Linux 5.10.0-14-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u3
ii  liblzma5 5.2.5-2.1~deb11u1
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information

Bug#1008369: scikit-learn testing migration

[Andreas Tille]

Am Wed, Jul 27, 2022 at 08:57:09AM -0700 schrieb M. Zhou:
> The previous segfault on armel becomes Bus Error on armel and armhf.

Which does not make it much better as long as no-one is investigating
the issue in a timely manner.  So my suggestion to remove arm 32 bit
architectures (at least until the issue is fixed) remains.

> I can build it on Power9, but it seems that the test fails on power8 (our 
> buildd).

Hmmm, can we talk to buildd admins about this?

Kind regards

   Andreas.

> On Wed, 2022-07-27 at 09:56 +0200, Andreas Tille wrote:
> > Control: tags -1 unreproducible
> > Control: tags -1 moreinfo
> > Control: severity -1 important
> > 
> > Hi,
> > 
> > BTW, there is another bug in scikit-learn, but I can't reproduce it and
> > have set tags accordingly.  Could someone else please give it a try?
> > 
> > Kind regards
> > 
> >  Andreas.
> > 
> > Am Wed, Jul 20, 2022 at 09:23:28PM +0200 schrieb Andreas Tille:
> > > Hi Nilesh,
> > > 
> > > Am Wed, Jul 20, 2022 at 06:21:19PM +0530 schrieb Nilesh Patra:
> > > > On 7/20/22 4:50 PM, Andreas Tille wrote:
> > > > > Before we stop progress in Debian for many other architectures since 
> > > > > we
> > > > > cant't solve this on our own or otherwise are burning patience of
> > > > > upstream I'd alternatively consider droping armel as supported
> > > > > architecture.
> > > > 
> > > > I am definitely +1 for this, however scikit-learn is a key package and 
> > > > dropping
> > > > it from armel would mean dropping several revdeps as well.
> > > > I am a bit unsure if that is fine or not.
> > > 
> > > Its not fine at all and I would not be happy about it.  However, the other
> > > side of a key package is, that lots of package have testing removal 
> > > warnings
> > > on architectures which are widely used and we have real trouble because of
> > > this.
> > > 
> > > Kind regards
> > > 
> > >   Andreas.
> > > 
> > > -- 
> > > http://fam-tille.de
> > > 
> > > 
> > 
> 
> 

-- 
http://fam-tille.de

Bug#1016138: gitlab-ci-multi-runner: CVE-2021-39947

[Moritz Mühlenhoff]

Source: gitlab-ci-multi-runner
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for gitlab-ci-multi-runner.

CVE-2021-39947[0]:
| In specific circumstances, trace file buffers in GitLab Runner
| versions up to 14.3.4, 14.4 to 14.4.2, and 14.5 to 14.5.2 would re-use
| the file descriptor 0 for multiple traces and mix the output of
| several jobs

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39947
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39947

Please adjust the affected versions in the BTS as needed.

Bug#1016139: net-snmp: CVE-2022-24810 CVE-2022-24809 CVE-2022-24808 CVE-2022-24807 CVE-2022-24806 CVE-2022-24805

[Moritz Mühlenhoff]

Source: net-snmp
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for net-snmp.

5.9.3 fixes the following issues:

- These two CVEs can be exploited by a user with read-only credentials:
- CVE-2022-24805 A buffer overflow in the handling of the INDEX of
  NET-SNMP-VACM-MIB can cause an out-of-bounds memory access.
- CVE-2022-24809 A malformed OID in a GET-NEXT to the nsVacmAccessTable
  can cause a NULL pointer dereference.
- These CVEs can be exploited by a user with read-write credentials:
- CVE-2022-24806 Improper Input Validation when SETing malformed
  OIDs in master agent and subagent simultaneously
- CVE-2022-24807 A malformed OID in a SET request to
  SNMP-VIEW-BASED-ACM-MIB::vacmAccessTable can cause an
  out-of-bounds memory access.
- CVE-2022-24808 A malformed OID in a SET request to
  NET-SNMP-AGENT-MIB::nsLogTable can cause a NULL pointer dereference
- CVE-2022-24810 A malformed OID in a SET to the nsVacmAccessTable
  can cause a NULL pointer dereference.
   - To avoid these flaws, use strong SNMPv3 credentials and do not share them.
 If you must use SNMPv1 or SNMPv2c, use a complex community string
 and enhance the protection by restricting access to a given IP address 
range.
   - Thanks are due to Yu Zhang of VARAS@IIE and Nanyu Zhong of VARAS@IIE for
 reporting the following CVEs that have been fixed in this release, and
 to Arista Networks for providing fixes.

Please adjust the affected versions in the BTS as needed.

Bug#1016140: rails: CVE-2022-32224

[Moritz Mühlenhoff]

Source: rails
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for rails.

CVE-2022-32224[0]:
https://github.com/advisories/GHSA-3hhc-qp5v-9p2j

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-32224
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32224

Please adjust the affected versions in the BTS as needed.

Bug#1016142: gpac: CVE-2022-2549

[Moritz Mühlenhoff]

Source: gpac
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for gpac.

CVE-2022-2549[0]:
| NULL Pointer Dereference in GitHub repository gpac/gpac prior to
| v2.1.0-DEV.

https://huntr.dev/bounties/c93083dc-177c-4ba0-ba83-9d7fb29a5537
https://github.com/gpac/gpac/commit/0102c5d4db7fdbf08b5b591b2a6264de33867a07

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2549
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2549

Please adjust the affected versions in the BTS as needed.

Bug#1016141: segfault in ghc-pkg on hppa architecture

[Helge Deller]

Package: ghc
Version: 9.0.2-3
Tags: hppa

When running this command:
/usr/lib/ghc/bin/ghc-pkg --global-package-db /usr/lib/ghc/package.conf.d list
I face a segfault on the hppa architecture.

Example:
(sid_hppa)root@phantom:/# /usr/lib/ghc/bin/ghc-pkg --global-package-db 
/usr/lib/ghc/package.conf.d list
/usr/lib/ghc/package.conf.d
Cabal-3.4.1.0
array-0.5.4.0
base-4.15.1.0
binary-0.8.8.0
[ many more...]
unix-2.7.2.2
xhtml-3000.2.2.1
Segmentation fault

strace shows:
poll([{fd=1, events=POLLOUT}], 1, 0)= 1 ([{fd=1, revents=POLLOUT}])
write(1, "terminfo-0.4.1.5\n", 21terminfo-0.4.1.5
)  = 21
poll([{fd=1, events=POLLOUT}], 1, 0)= 1 ([{fd=1, revents=POLLOUT}])
write(1, "text-1.2.5.0\n", 17text-1.2.5.0
)  = 17
poll([{fd=1, events=POLLOUT}], 1, 0)= 1 ([{fd=1, revents=POLLOUT}])
write(1, "time-1.9.3\n", 15time-1.9.3
)= 15
poll([{fd=1, events=POLLOUT}], 1, 0)= 1 ([{fd=1, revents=POLLOUT}])
write(1, "transformers-0.5.6.2\n", 25transformers-0.5.6.2
) = 25
poll([{fd=1, events=POLLOUT}], 1, 0)= 1 ([{fd=1, revents=POLLOUT}])
write(1, "unix-2.7.2.2\n", 17unix-2.7.2.2
)  = 17
poll([{fd=1, events=POLLOUT}], 1, 0)= 1 ([{fd=1, revents=POLLOUT}])
write(1, "xhtml-3000.2.2.1\n", 21xhtml-3000.2.2.1
)  = 21
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, 
si_overrun=10, si_value={int=0, ptr=NULL}} ---
rt_sigreturn({mask=[]}) = 4175667210
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x9d92c8} ---
+++ killed by SIGSEGV +++
Segmentation fault

Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2

[Chris Hofstaedtler]

Control: reassign -1 glibc

Dear glibc Maintainers,

this bug appears to be an upgrade issue where (old versions?) of
libc6 might have done something wrong. Maybe you can decide what to
do with/about this bug.

It does not look like openssh-server would be the right place to fix
anything about it.

Chris

Bug#1002231: golang-github-pkg-term: FTBFS in bullseye

[Santiago Vila]

reopen 1002231
found 1002231 1.1.0-3
fixed 1002231 1.1.0-4
thanks

Hi. Since packages in stable must build in stable and this happens in
bullseye as well, please consider an upload for bullseye (or tell me how
I can help to have this fixed in bullseye).

Thanks.

Bug#1016134: mu4e: /usr/share/doc/mu4e/changelog.gz is not useful

[Dima Kogan]

Package: mu4e
Version: 1.8.6-1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. With the latest mu4e package I see this:

  $ zcat /usr/share/doc/mu4e/changelog.gz

  See NEWS.org

But NEWS.org isn't shipped in the documentation. It should be shipped in
the docs instead of the changelog file. The related "maildir-utils"
package has the same problem.

Thanks!


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mu4e depends on:
ii  emacsen-common  3.0.4
ii  maildir-utils   1.8.6-1

mu4e recommends no packages.

mu4e suggests no packages.

-- no debconf information

Bug#1016135: devscripts: debdiff: Please add option to pass --no-check to dpkg-source

[Guillem Jover]

Package: devscripts
Version: 2.22.2
Severity: wishlist
Control: block 1016087 by -1

Hi!

The debdiff command can compare a couple of Debian source packages
(.dsc), but it needs to unpack them first with dpkg-source. That
command will check the checksums and the signatures.

The problem is that letting dpkg-source verify the signatures can be
confusing for users when we are sure the provenance of the .dsc is from
a signed and verified Debian repository, as the signatures or the keys
that made them might have expired, or been revoked, the keys might be
using weak algorithms, or the keys might not even be present in the
keyrings if the holders are no longer project members.

In the context of a signed repository their primary purpose is to
transfer the trust anchor from the uploader to the archive software,
which can then handle metaindices resigning, key rotation, expiration,
etc, which do not suffer from the problems with a one-time static
signature.

It would then be helpful to have an option that can be used to request
passing --no-check (f.ex.) to dpkg-source so that it avoids doing such
checks (when we can guarantee the safe provenance of the .dsc), in a
similar way how apt passes it too on «apt source».

This is a blocker to be able to fix #1016087 in apt-listdifferences.

Thanks,
Guillem