Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Steven Robbins]

On Tuesday, March 12, 2024 1:24:25 A.M. CDT Steve Langasek wrote:

> The quickest fix for this based on what we've done in Ubuntu is:
> 
> - unpack cargo and libstd-rust debs to the root via dpkg-deb -x
> - use equivs to mock up packages by these names with no dependencies and
>   install those
> - bootstrap
> - enjoy

Thanks!

I checked the build logs for cargo and noticed that most architectures have 
been built on the buildds.  All release arches except armel & armhf.  How is 
it that these two have build dep installability problems but others do not?

-Steve


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

Bug#1066146: RM: flask-basicauth -- ROM; RC buggy, dead upstream, leaf package

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: flask-basica...@packages.debian.org, mo...@debian.org
Control: affects -1 + src:flask-basicauth

src:flask-basicauth was packaged for debian only because it's a dependency of
src:locust, but the latter has migrated to flask-login in the 2.24.0 release,
just uploaded to unstable.

flask-basicauth is RC buggy and dead upstream, and once locust hits the archive
there will be no other package depending on it, so please remove it

Bug#1066144: python-pyproj: please remove obsolete python3-mock build-dependency

[Sebastiaan Couwenberg]

Control: tags -1 pending

Fixed in git.

Kind Regards,

Bas

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

Bug#1062777: RFP: cracktunes -- hassle-free, highly performant Discord music bot

[cycle.five]

Hello,

I am the author of this code, it is in active development. If there's interest 
in it, I'm more than happy to work with anyone to mold it to their specific 
needs.

Regards,
Lothrop

On Sat, 03 Feb 2024 16:31:19 +0800 Maytham Alsudany wrote: > Package: wnpp > 
Severity: wishlist > X-Debbugs-Cc: debian-r...@lists.debian.org > > -BEGIN 
PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name : cracktunes > 
Version : 0.2.16 > Upstream Contact: Cycle Five > * URL : 
https://git.sr.ht/~cycle-five/cracktunes > * License : Expat > Programming 
Lang: Rust > Description : hassle-free, highly performant Discord music bot > > 
Cracktunes is a hassle-free, highly performant, host-it-yourself, > cracking 
smoking Discord music bot. > > -BEGIN PGP SIGNATURE- > > 
iQJMBAEBCgA2FiEESl/RzRFQh8wD3DXB1ZeJcgbF8H8FAmW9+dQYHG1heXRoYTh0 > 
aGVkZXZAZ21haWwuY29tAAoJENWXiXIGxfB/M3cQAJDiqLwBPXX/GYmgkUP/4k1r > 
uunrAvl5kPamMAPmmUKFJixjCuCx8B5PuqdWTawIu5qtYAhQmO2xG+6z1cYrcVMt > 
YqDxNwrDrcTalOMyOu2yDQpm7jZtyWU2K8RTZRppRf3hnzKEX4a/f/BMK20G/O2e > 
1fSDEuim/Ku6BoKakGDNsZmy+J2oMvlqdvyS/jJOQBwuWobQao0m6CqBYYdgOnPn > 
pscRNR7n8m0OW8139n5qPq1TeOF7jtt/eSmqD4dV7cjdUuP3JRyOHZyC7r8sQGXm > 
+YHLbJd6zBnM5qaenzXn1oYTTkmWcmDmdmkNb2FSDqlpdH4ywbUpDZwpcYjTLSNr > 
CBuCcbppM6j8JI6cYLiUzo6MAE8faX/ia7ceMY7sLbahP125rTxUZ9AUXbai/eX5 > 
zobM284MhZNmtwDYlBDycwKYc7KcbcBzKbjeYLp+70njOzW5J/0KlKVF8eG5G2ui > 
l97LlmsDcNuS4NzbHGxKEq0bvHa93ccwxkQkI3p1Za++pa/d8/n+Zm4V0YCWpjUs > 
zQ87yYxv9WcG7ogRwPaacvnkBhBvZjcoeWrRaBSwTZO08TvjYRg8nrTw/h7BioeD > 
Wk8xX+ZGmIaN/2JrGxKyRxPxFe6rs8i2nx0Bs8HooQpFyVSzlfzaqlDLhmuCYVae > 
ItZ9IVBDFgR502SCMHUC > =DFmB > -END PGP SIGNATURE- > >


publickey - cycle.five@proton.me - 0x4A83D4B3.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#1066143: general/glibc(?): simple IPv6 test program fails on m68k

[Thorsten Glaser]

>The same program works on amd64.

I noticed another difference between the amd64 system
and the four m68k ones.

$ ip a show dev lo
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever

vs.

# ip a show dev lo
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever

/etc/network/interfaces just has…

auto lo
iface lo inet loopback

… on all systems, so something weird is going on.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#904233: Adoption of persp-projectile

[Xiyue Deng]

Sean Whitton  writes:

> Hello Xiyue,
>
> Do you still intend to adopt persp-projectile?
>
> Thanks.

Yes.  And it seems I forgot to close this ITA bug in the Changelog.  Can
we close this directly instead?

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#904233: Adoption of persp-projectile

[Sean Whitton]

Hello Xiyue,

Do you still intend to adopt persp-projectile?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1066145: debootstrap: fails with multiversion repositories, including Debian’s

[Thorsten Glaser]

Package: debootstrap
Version: 1.0.134
Severity: important

There exist multiversion Packages files, e.g. they can be created
by dpkg-scanpackages -m but dak also occasionally seems to create
them.

I just had multiple attempts at creating a buildd chroot fail.

One was with debootstrap --variant=buildd where perl-modules-5.38
failed the bootstrap because the Packages file contains two versions
of it (5.38.2-3.2 (the one we want) followed by 5.38.2-3). According
to cbmuser, the arch:all part of debian-ports Packages files is an
identical embedded copy of binaries-all/Packages from dak for sid,
so this is not just a debian-ports or mini-dak problem.

Then I tried --variant=minbase which failed the cowbuilder --create
as well but only after the debootstrap stage: debootstrap installed
libaudit-common 1:3.1.2-2 instead of 1:3.1.2-2.1 so the chroot had
libaudit1’s dependency on libaudit-common unfulfilled, which made a
later apt-get dist-upgrade fail without manually running an apt-get
-f install first (which I thankfully could do in a pbuilder hook
script).

This is a real problem affecting real-world scenarios (such as
buildd maintainers frantically trying to stay on top of t64), and
apparently at least arch:all packages can have multiple versions
show up in the Packages file in Debian sid.

The two failure modes are that debootstrap either results in a
chroot in which packages are installed that don’t meet each other’s
dependencies (which a real-world dpkg call would need --force-depends)
or that debootstrap itself even aborts.

The fix is of course to consider all versions of all packages,
though this will be very hard; apt seems to normally only consider
the latest version (unless another is installed or pinned), so
doing that would be another option, which while not being helpful
in situations of nōn-arch:all packages lagging would fix this bug
just as well.


-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k

Kernel: Linux 6.6.15-m68k
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.16.3-3

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.19-5
ii  mount   2.26.2-9

Versions of packages debootstrap suggests:
ii  binutils2.25.1-1
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.1.1alpha+20120614-2.1
pn  zstd

-- no debconf information

Bug#1059331: spip: XSS issue fixed in 4.1.13 upstream

[Santiago Ruano Rincón]

Control: fixed -1 4.1.9+dfsg-1+deb12u4

From 
https://sources.debian.org/src/spip/4.1.9%2Bdfsg-1%2Bdeb12u4/debian/changelog/

spip (4.1.9+dfsg-1+deb12u4) bookworm; urgency=medium

  * Backport security fix from 4.1.15
- fix XSS in uploaded files using bigup

 -- David Prévot   Fri, 12 Jan 2024 13:42:36 +0100

spip (4.1.9+dfsg-1+deb12u3) bookworm; urgency=medium

  * Backport security fix from 4.1.13
- fix XSS when calling some templates

 -- David Prévot   Thu, 21 Dec 2023 19:24:13 +0100

The 4.1.13 backport was part of 4.1.9+dfsg-1+deb12u3, but it seems it
was not uploaded.

On Fri, 22 Dec 2023 16:57:40 +0100 Salvatore Bonaccorso  
wrote:
> Source: spip
> Version: 4.1.12+dfsg-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: fixed -1 4.1.13+dfsg-1
> Control: found -1 4.1.9+dfsg-1+deb12u2
> Control: found -1 3.2.11-3+deb11u9
> 
> Filling a bug for tracking (as otherwise beeing a unspecified TEMP
> entry), as the issue has no CVE: 4.1.13 fixes an issue:
> 
>* fix: les modèles insérés dans un texte héritent automatiquement du
>  contexte, a l'insu des redacteurs. Securiser ce qui proviendrait de
>  variables envoyées par l'utilisateur
> 
> https://tracker.debian.org/news/1488834/accepted-spip-4113dfsg-1-source-into-unstable/
> 
> Regards,
> Salvatore


signature.asc
Description: PGP signature

Bug#1066144: python-pyproj: please remove obsolete python3-mock build-dependency

[Alexandre Detiste]

Source: python-pyproj
Version: 3.6.1-3
Severity: normal

Dear Maintainer,

"mock" has been absorbed by the Python standard library as "unittest.mock".

The standalone python3-mock package is deprecated
and slowly being removed from the distribution.

Please remove the stale line from debian/control.

Greetings,

Alexandre

tchet@brix /tmp/python-pyproj $ grep mock -r debian/
debian/changelog:  * Add python{,3}-{mock,pytest} to build dependencies.
debian/control:   python3-mock,

tchet@brix /tmp/python-pyproj $ grep mock -r | grep import
test/crs/test_crs.py:from unittest.mock import patch
test/test_cli.py:from unittest.mock import patch
test/test_datadir.py:from unittest.mock import patch
test/test_network.py:from unittest.mock import patch
test/test_proj.py:from unittest.mock import patch
test/test_sync.py:from unittest.mock import MagicMock, patch
test/test_transformer.py:from unittest.mock import call, patch
tchet@brix /tmp/python-pyproj $

Bug#1066143: general/glibc(?): simple IPv6 test program fails on m68k

[Thorsten Glaser]

Package: libc6
Version: 2.36-8
Severity: normal
Tags: ipv6
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org

This error occurred first during curl’s configure in a chroot with
libc6 2.37-15.1, but I could also reproduce it on a build host with
libc6 2.36-8 as well, and on an even older host with libc6 2.19-19
(all but the 2.36-8 one I’m reportbugging this from are running
linux 6.6.15-2).

Running a simple program that opens a TCP/IPv6 socket fails:

root@ara4:~ # gcc y.c
root@ara4:~ # ./a.out
a.out: socket(AF_INET6, SOCK_STREAM, 0): Address family not supported by 
protocol
1|root@ara4:~ # cat y.c
#include 
#include 
#include 

int main(void) {
int rv = socket(AF_INET6, SOCK_STREAM, 0) < 0;
err(1, "socket(AF_INET6, SOCK_STREAM, 0)");
}

(oops, should have been s/1/rv/ but doesn’t matter)

The same program works on amd64.

This is a reduced testcase that still shows the problem, plus
the call to err(3) added to show errno.

cbmuser said that another ports architecture also has unknown
trouble with IPv6, maybe this is the same issue?

If this is an issue with the kernel or something, please
reassign and inform the maintainers.

If this is a bug in the testcase, please reassign to src:curl.
The original testcase (plus confdefs) was:

 #include 
 #ifdef _WIN32
 #include 
 #include 
 #else
 #include 
 #include 
 #if defined (__TANDEM)
 # include 
 #endif
 #endif
 
 int main(void)
 {
  struct sockaddr_in6 s;
  (void)s;
  return socket(AF_INET6, SOCK_STREAM, 0) < 0;
 }

gcc -o conftest -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/tmp/buildd/curl-8.6.0=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -D_DEB_HOST_ARCH=\"m68k-linux-gnu\" 
-DCURL_PATCHSTAMP=\"8.6.0-3.2+b1\" -Werror-implicit-function-declaration 
-Wno-system-headers -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 
-Wdate-time -D_FORTIFY_SOURCE=2-specs=/usr/share/dpkg/pie-link.specs 
-Wl,-z,relro -Wl,-z,nowconftest.c -llber -lldap -llber -lzstd  -lbrotlidec  
-lz

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

Kernel: Linux 6.1.0-2-m68k (UP)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libc6 depends on:
ii  libgcc-s2  12.2.0-12

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.3-1+b1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.82
pn  glibc-doc  
ii  libc-l10n  2.36-8
pn  libnss-nis 
pn  libnss-nisplus 
pn  locales

-- debconf information:
* libraries/restart-without-asking: true
  glibc/kernel-too-old:
  glibc/kernel-not-supported:
  glibc/restart-services:
  glibc/upgrade: true
  glibc/restart-failed:
  glibc/disable-screensaver:

Bug#1066142: python-croniter: please drop obsolete python3-mock build dependency

[Alexandre Detiste]

Source: python-croniter
Version: 1.3.15-2
Severity: normal

This projects no longer uses the old "mock".

Greetings


tchet@brix /tmp/python-croniter $ grep mock -r
debian/control: python3-mock,
requirements/test.txt:mock>=2.0.0  # For Python 2
tchet@brix /tmp/python-croniter $

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Vincent Lefevre]

And on a 3rd machine, where I used

  aptitude --log-file=/tmp/aptitude.log --log-level=info


dpkg: dependency problems prevent removal of libb2-1:amd64:
 libqt6core6t64:amd64 depends on libb2-1 (>= 0.98.1).

dpkg: error processing package libb2-1:amd64 (--purge):
 dependency problems - not removing
(Reading database ... 795189 files and directories currently installed.)
Purging configuration files for libts0:amd64 (1.22-1+b1) ...
Errors were encountered while processing:
 libb2-1:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)


In the logs, this package libb2-1 appears only twice:

2024-03-13 01:33:14 [140549832112320] aptcache.cc:2323 INFO aptitude.apt.cache 
- aptitudeDepCache::sweep(): reinstating libb2-1:amd64

2024-03-13 01:34:48 [140549832112320] aptcache.cc:2323 INFO aptitude.apt.cache 
- aptitudeDepCache::sweep(): reinstating libb2-1:amd64

I've attached the compressed log file corresponding to this upgrade.

The packages that appear as REMOVE/INSTALL/UPGRADE in /var/log/aptitude:

[REMOVE, NOT USED] libatrildocument3:amd64 1.26.2-1
[REMOVE, NOT USED] libatrilview3:amd64 1.26.2-1
[REMOVE, NOT USED] libgxps2:amd64 0.3.2-3
[INSTALL, DEPENDENCIES] libatrildocument3t64:amd64 1.26.2-1.1+b1
[INSTALL, DEPENDENCIES] libatrilview3t64:amd64 1.26.2-1.1+b1
[INSTALL, DEPENDENCIES] libgxps2t64:amd64 0.3.2-4+b1
[INSTALL, DEPENDENCIES] libpoppler-cpp0t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler-glib8t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler-qt5-1t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler-qt6-3t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler126t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libqt6core6t64:amd64 6.4.2+dfsg-21.1+b1
[INSTALL, DEPENDENCIES] libqt6dbus6t64:amd64 6.4.2+dfsg-21.1+b1
[INSTALL, DEPENDENCIES] libqt6gui6t64:amd64 6.4.2+dfsg-21.1+b1
[INSTALL, DEPENDENCIES] libts0t64:amd64 1.22-1.1
[REMOVE, DEPENDENCIES] libpoppler-cpp0v5:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-glib8:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-glib8-dbgsym:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-qt5-1:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-qt6-3:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler126:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler126-dbgsym:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libqt6core6:amd64 6.4.2+dfsg-21
[REMOVE, DEPENDENCIES] libqt6dbus6:amd64 6.4.2+dfsg-21
[REMOVE, DEPENDENCIES] libqt6gui6:amd64 6.4.2+dfsg-21
[REMOVE, DEPENDENCIES] libts0:amd64 1.22-1+b1
[UPGRADE] atril:amd64 1.26.2-1 -> 1.26.2-1.1+b1
[UPGRADE] atril-common:amd64 1.26.2-1 -> 1.26.2-1.1
[UPGRADE] libpoppler-dev:amd64 22.12.0-2+b1 -> 22.12.0-2.2
[UPGRADE] libpoppler-private-dev:amd64 22.12.0-2+b1 -> 22.12.0-2.2
[UPGRADE] poppler-utils:amd64 22.12.0-2+b1 -> 22.12.0-2.2

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


aptitude.log.xz
Description: Binary data

Bug#1066141: python-txaio: please remove python3-mock from build-dependencies

[Alexandre Detiste]

Source: python-txaio
Version: 23.1.1-3
Severity: normal

This project has switched to newer unittest.mock.

Greetings

/tmp/python-txaio $ grep mock -r
debian/control: python3-mock,
docs/releases.rst:- fix: eliminate redundant dep. on mock (#170)
test/_asyncio_test_utils.py:from unittest import mock
test/test_call_later.py:from unittest.mock import patch

Bug#1066140: afflib: strlcpy,strlcat in .symbols but not part of API; ftbfs with glibc >= 2.38

[Steve Langasek]

Package: afflib
Version: 3.7.20-1.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hi João,

afflib fails to build from source in Ubuntu because Ubuntu ships glibc 2.39
which now provides implementations of strlcat and strlcpy, which means other
packages no longer include their own implementations, resulting in a
mismatch with the libafflib0t64 symbols file.

The attached patch treats these symbols as optional, since they are not part
of the afflib API.

This change has been uploaded to Ubuntu.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru afflib-3.7.20/debian/libafflib0t64.symbols 
afflib-3.7.20/debian/libafflib0t64.symbols
--- afflib-3.7.20/debian/libafflib0t64.symbols  2024-02-27 16:12:21.0 
-0800
+++ afflib-3.7.20/debian/libafflib0t64.symbols  2024-03-12 17:10:21.0 
-0700
@@ -787,8 +787,8 @@
  s3_request_retry_count@Base 3.7.6
  s3_retry_max@Base 3.7.6
  split_raw_increment_fname@Base 3.7.6
- strlcat@Base 3.7.6
- strlcpy@Base 3.7.6
+ (optional)strlcat@Base 3.7.6
+ (optional)strlcpy@Base 3.7.6
  strstart@Base 3.7.6
  term_print_filename@Base 3.7.6
  term_printf@Base 3.7.6

Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Simon McVittie]

On Tue, 12 Mar 2024 at 22:30:01 +0100, Michael Biebl wrote:
> On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer  wrote:
> > My speculation is that this happened while satisfying dependencies for
> > a third party i386 application. That meant installing required 32 bit
> > libraries, and one of them must have come with a polkitd dependency,
> > and the i386 version was selected because I was installing an i386
> > package.
...
> Is there a valid use case where we need/want a foreign systemd/policykit-1?

The valid use-case for polkitd being Multi-Arch: foreign is the scenario
Bertram described: you install third-party, potentially binary-only
i386 software onto an amd64 system, and it depends on polkitd. We want
polkitd:amd64 to be able to satisfy that dependency.

That's also why we want systemd(-sysv) to be Multi-Arch: foreign:
for example the i386-only quake4-server needs systemd (in that case
it's actually a only Recommends, because you don't *need* to use the
systemd units, but it could in principle have been a Depends) and we
want systemd(-sysv):amd64 to satisfy that dependency.

I don't know of any valid use-case for polkitd and systemd(-sysv)
being of an architecture that is not the same as the system's primary
architecture, except for perhaps briefly during crossgrading, but that
isn't what Multi-Arch: foreign means anyway.

"The primary architecture" really just means "the same architecture
as dpkg", and I don't think there is any metadata that could be set on
polkitd or systemd to say that they must be of that same architecture.

smcv

Bug#1031802: Move fuse_new_31 to FUSE_3.13?

[Bernd Schubert]

Hi Andrea,

thanks for raising my attention and thanks for the detailed analysis.
Would it help to move that symbol to FUSE_3.13 in the version script
(for example in libfuse-3.17?)?


Thanks,
Bernd

Bug#1066131: Acknowledgement (RFS: streamlink/6.7.0-1 -- CLI for extracting video streams from various websites to a video player)

[Alexis Murzeau]

Hi,

I've re-uploaded the package to change how the tests are fixed.
Instead of patching upstream code, I've changed how pytest is called.

Upstream uses pytest tests' name ("nodeid") to order tests and they are
named relative to the "rootdir" [1].

By default, the rootdir used by pytest is where the pyproject.toml is,
so I need to change it to where the used `tests` directory is (that is
in /<>/.pybuild/cpython3_3.11/build/).
This way, the upstream configuration to properly order tests works and
there is no more test failures.


[1]: 
https://github.com/streamlink/streamlink/blob/251fe08f8da8214dafdf094afd80c543b8e2e0fe/tests/conftest.py#L16


See also https://github.com/streamlink/streamlink/pull/5888.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Bertram Felgenhauer]

Michael Biebl wrote:
> I've contemplated dropping the Multi-Arch: foreign notation in systemd and
> maybe also for policykit-1.
>
> Is there a valid use case where we need/want a foreign systemd/policykit-1?

Wouldn't that go in the wrong direction? I'd think that we want the
native systemd or policykit daemon to satisfy a foreign dependency,
and that's what `Multi-Arch: foreign` allows.

In fact https://wiki.ubuntu.com/MultiarchSpec#line-1-3 suggests that
the scenario I ended up in *should* not have happened; the installer
should've preferred the native (amd64 for me) version of the package.

So that's an argument in favor of leaving things as they are.

Bertram

Bug#1066077: usr-is-merged fails to install on a /usr-merged system

[David W]

On Tue, Mar 12, 2024, 06:04 Luca Boccassi  wrote:

> Why is /usr a symlink? How did you install your debian system?
>

It's something I set up manually 15 years ago or something, to deal with a
situation where /usr plus some other static directories needed to live on a
different hard drive. Different times...

Obviously not something any installer will ever do, but I don't think it's
against policy? Given that packages depend on usr-is-merged to signal
proper merged state, it shouldn't force you to undo that (especially given
that it's a very risky/tricky operation).

>

Bug#1066139: podman: Cannot create a network with dns_enabled

[Antoine Sirinelli]

Package: podman
Version: 4.9.3+ds1-1
Severity: normal

Dear Maintainer,

When I create a new custom network, the dns is not enabled:

$ podman network create test
test
$ podman network inspect test
[
 {
  "name": "test",
  "id": 
"9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
  "driver": "bridge",
  "network_interface": "cni-podman1",
  "created": "2024-03-13T00:11:16.769046605+01:00",
  "subnets": [
   {
"subnet": "10.89.0.0/24",
"gateway": "10.89.0.1"
   }
  ],
  "ipv6_enabled": false,
  "internal": false,
  "dns_enabled": false,
  "ipam_options": {
   "driver": "host-local"
  }
 }
]

The outcome should have "dns_enabled" to true.

Thank you,

Antoine

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, i386

Kernel: Linux 6.6.15-amd64 (SMP w/12 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages podman depends on:
ii  conmon   2.1.10+ds1-1
ii  golang-github-containers-common  0.57.4+ds1-2
ii  libc62.37-15
ii  libdevmapper1.02.1   2:1.02.196-1
ii  libgpgme11   1.18.0-4+b2
ii  libseccomp2  2.5.5-1
ii  libsqlite3-0 3.45.1-1
ii  libsubid41:4.13+dfsg1-4
ii  runc 1.1.12+ds1-1

Versions of packages podman recommends:
ii  buildah1.33.5+ds1-4
ii  catatonit  0.1.7-1+b1
ii  dbus-user-session  1.14.10-4
ii  passt  0.0~git20240220.1e6f92b-1
ii  slirp4netns1.2.1-1
ii  tini   0.19.0-1
ii  uidmap 1:4.13+dfsg1-4

Versions of packages podman suggests:
ii  containers-storage  1.51.0+ds1-2
ii  docker-compose  1.29.2-6
ii  iptables1.8.10-3

-- Configuration Files:
/etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission non accordée: 
'/etc/cni/net.d/87-podman-bridge.conflist'
/etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Permission non accordée: 
'/etc/cni/net.d/87-podman-ptp.conflist'

-- no debconf information

Bug#1066137: gnupg2: -Werror=implicit-function-declaration failure testing for ldap_open

[Thorsten Glaser]

clone 1066137 -1
reassign -1 gnupg1 1.4.23-1.1
retitle -1 gnupg1: fails to build gpgkeys_ldap, probably due to 
-Werror=implicit-function-declaration
thanks

Dixi quod…

>This matches the following failure mode at the end of the build:

Same for gnupg1 according to the buildd page:
https://buildd.debian.org/status/package.php?p=gnupg1

>Trying to binNMU gnupg2 to make it installable during t64 transition,

Please do also reduce the B-D as Helmut noted in #980768; specifically,
dropping ghostscript, imagemagick, libcurl4-gnutls-dev and transfig
from src:gnupg2 produces identical binary packages according to his
analysis. Perhaps some of that applies to gnupg1 as well. This will
help tremendously.

Thanks,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1066113: guix: CVE-2024-27297

[Vagrant Cascadian]

Control: found 1066113 1.4.0-3
Control: tags  1066113 pending

On 2024-03-12, Salvatore Bonaccorso wrote:
> The following vulnerability was published for guix.
>
> CVE-2024-27297[0]:
> | Nix is a package manager for Linux and other Unix systems. A fixed-
> | output derivations on Linux can send file descriptors to files in
> | the Nix store to another program running on the host (or another
> | fixed-output derivation) via Unix domain sockets in the abstract
> | namespace. This allows to modify the output of the derivation, after
> | Nix has registered the path as "valid" and immutable in the Nix
> | database. In particular, this allows the output of fixed-output
> | derivations to be modified from their expected content. This issue
> | has been addressed in versions 2.3.18 2.18.2 2.19.4 and 2.20.5.
> | Users are advised to upgrade. There are no known workarounds for
> | this vulnerability.

Technically, it was published for Nix (CCed the listed maintainer)! Guix
just happens to share some of the same code history. :)

Should the bug be cloned for nix, or a separate bug filed?


> 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-2024-27297
> https://www.cve.org/CVERecord?id=CVE-2024-27297
> [1] 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8f4ffb3fae133bb21d7991e97c2f19a7108b1143

> Please adjust the affected versions in the BTS as needed.

There was another followup fix committed in upstream guix, which I
already merged into the Debian packaging:

  
https://salsa.debian.org/debian/guix/-/commit/03eeedaddbdded880743461cbca0261b96737319

This commit can be trivially cherry-picked for bookworm (1.4.0-3) and
for bullseye (with some easily resolved conflicts in
debian/patches/series).

A summary from the guix perspective, including code to verify the issue
was posted:

  
https://guix.gnu.org/en/blog/2024/fixed-output-derivation-sandbox-bypass-cve-2024-27297/

I have not yet had a chance to actually verify the fix on locally built
Debian packages, but all three releases do successfully build with the
patches applied.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1066137: gnupg2: -Werror=implicit-function-declaration failure testing for ldap_open

[Thorsten Glaser]

Source: gnupg2
Version: 2.2.40-1.1
Severity: serious
Justification: ftbfs
X-Debbugs-Cc: t...@mirbsd.de

Trying to binNMU gnupg2 to make it installable during t64 transition,
I notice the following configury output:

[…]
checking for library containing dn_skipname... none required
checking whether the resolver is usable... yes
checking whether LDAP via "-lldap" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lldap -llber" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lldap -llber -lresolv" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lwldap32" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking for ber_free in -llber... yes
configure: WARNING:
***
*** Building without LDAP support.
*** No CRL access or X.509 certificate search available.
***
checking for sendmail... no
[…]

This matches the following failure mode at the end of the build:

19:50⎜ I can't build gnugpg2:
19:50⎜dh_install -a -O--builddirectory=build
19:50⎜ dh_install: warning: Cannot find (any matches for)
 ⎜"debian/tmp/usr/lib/gnupg/dirmngr_ldap" (tried in ., debian/tmp)
19:50⎜ dh_install: warning: dirmngr missing files:
 ⎜debian/tmp/usr/lib/gnupg/dirmngr_ldap
19:50⎜ dh_install: error: missing files, aborting

The cause in config.log:

configure:11580: checking whether LDAP via "-lldap" is present and sane
configure:11600: gcc -o conftest -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/tmp/buildd/gnupg2-2.2.40=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2  
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now conftest.c -lldap 
  >&5
conftest.c: In function 'main':
conftest.c:96:1: error: implicit declaration of function 'ldap_open'; did you 
mean 'ldap_turn'? [-Werror=implicit-function-declaration]
   96 | ldap_open("foobar",1234);
  | ^
  | ldap_turn
cc1: some warnings being treated as errors
configure:11600: $? = 1
configure: failed program was:
[…]
| /* end confdefs.h.  */
| 
| #ifdef _WIN32
| #include 
| #include 
| #else
| #include 
| #endif
| 
| int
| main (void)
| {
| ldap_open("foobar",1234);
|   ;
|   return 0;
| }
configure:11608: result: no


Prototypes are now mandatory, both for C23 and because the t64 transition
can only work if prototypes are properly used.

bye,
//mirabilos

Bug#1066136: python3-xapian-haystack: unusable on stable due to use of deprecated module django.utils.six

[Ole Peder Brandtzæg]

Package: python3-xapian-haystack
Version: 2.1.1-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Dear Maintainer,

I installed python3-xapian-haystack in order to employ Xapian as a
Haystack backend in mailman3-web on stable (bookworm).

However, upon actually trying to use it, I got the following traceback:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
47, in inner
response = get_response(request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 181, 
in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3/dist-packages/hyperkitty/views/search.py", line 54, in 
search
results = EmptySearchQuerySet()
  File "/usr/lib/python3/dist-packages/haystack/query.py", line 25, in __init__
self._determine_backend()
  File "/usr/lib/python3/dist-packages/haystack/query.py", line 58, in 
_determine_backend
self.query = connections[backend_alias].get_query()
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 114, in 
__getitem__
self.thread_local.connections[key] = load_backend(
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 60, in 
load_backend
return import_class(full_backend_path)
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 22, in 
import_class
module_itself = importlib.import_module(module_path)
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1206, in _gcd_import

  File "", line 1178, in _find_and_load

  File "", line 1149, in _find_and_load_unlocked

  File "", line 690, in _load_unlocked

  File "", line 940, in exec_module

  File "", line 241, in _call_with_frames_removed

  File "/usr/lib/python3/dist-packages/xapian_backend.py", line 10, in 
from django.utils import six

Exception Type: ImportError at /hyperkitty/search
Exception Value: cannot import name 'six' from 'django.utils' 
(/usr/lib/python3/dist-packages/django/utils/__init__.py)

django.utils.six was removed in Django 3.0; the version of Django in
stable is 3.2. Hence python3-xapian-haystack is currently unusable in
stable, as it simply throws an ImportError upon loading.

Upstream fixed this issue when they dropped Python 2 support in [0].
However, I have a simpler patch that just removes the six import and
changes all occurences of `six.moves.range()` to the built-in `range()`,
which I've applied locally (hence the debsums complaint) and seems to do
the trick.

I would very much like a stable-update for this given that the package
simply does not work without the patch.

Many thanks,
Ole

[0]: 
https://github.com/notanumber/xapian-haystack/commit/0f9d94fb23ebf8cf194a3a88948a86f6dc69e786#diff-b4466d919fc4105c6306804abd396d6e0ba5e4630346928df34a5308c4700d97

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

Kernel: Linux 6.7.8 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_DK:en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-xapian-haystack depends on:
ii  python3  3.11.2-1+b1
ii  python3-django-haystack  3.2.1-1
ii  python3-xapian   1.4.22-1

python3-xapian-haystack recommends no packages.

python3-xapian-haystack suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/xapian_backend.py (from 
python3-xapian-haystack package)
--- xapian_backend.py   2017-05-18 08:50:23.0 +0200
+++ /usr/lib/python3/dist-packages/xapian_backend.py2024-03-12 
01:06:33.011301452 +0100
@@ -7,7 +7,6 @@
 import shutil
 import sys
 
-from django.utils import six
 from django.conf import settings
 from django.core.exceptions import ImproperlyConfigured
 from django.utils.encoding import force_text
@@ -346,7 +345,7 @@
 def _get_ngram_lengths(value):
 values = value.split()
 for item in values:
-for ngram_length in six.moves.range(NGRAM_MIN_LENGTH, 
NGRAM_MAX_LENGTH + 1):
+for ngram_length in range(NGRAM_MIN_LENGTH, 
NGRAM_MAX_LENGTH + 1):
 yield item, ngram_length
 
 for obj in iterable:
@@ -356,8 +355,8 @@
 def ngram_terms(value):
 for item, length in _get_ngram_lengths(value):
 item_length = len(item)
-for start in six.moves.range(0, item_length - length + 
1):
-for size in six.moves.range(length, length + 1):
+  

Bug#1066134: FTBFS due -Werror=implicit-function-declaration

[Christoph Biedl]

Source: ppp
Version: 2.4.9-1+1.1
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Hi Chris,

ppp no longer builds in unstable here, tested in a minimal chroot. A
build in a testing chroot passes.

sys-linux.c: In function ‘sys_cleanup’:
sys-linux.c:357:9: error: implicit declaration of function ‘sif6down’; did 
you mean ‘sifdown’? [-Werror=implicit-function-declaration]
  357 | sif6down(0);
  | ^~~~
  | sifdown

Comparing the build logs, this is obviously caused by adding
-Werror=implicit-function-declaration to the default build options.

But looking closer, it seems sif6down is declared only of INET6 is
defined, and while all other *6 invocations are guarded accordingly in
sys-linux.c, this one is not. I'm a little disturbed why the code can
even be linked then.

So, assuming this is the cause here, the fix is pretty simple:

--- a/pppd/sys-linux.c
+++ b/pppd/sys-linux.c
@@ -353,8 +353,10 @@
if_is_up = 0;
sifdown(0);
 }
+#ifdef INET6
 if (if6_is_up)
sif6down(0);
+#endif

 /*
  * Delete any routes through the device.

This matches what sys-solaris.c does. Also, pppd 2.5.0 in
experimental seems to do something like this (PPP_WITH_IPV6CP).
The build now passes, I haven't checked further.

All the best,

Christoph

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



signature.asc
Description: PGP signature

Bug#1066135: python-kafka: please remove extraneous python3-unittest2 build dependency

[Alexandre Detiste]

Source: python-kafka
Version: 2.0.2-5
Severity: normal

unittest2 is not used anymore.

Greetings

tchet@brix /tmp/unittest2/python-kafka.git $ grep unittest2 -r
debian/changelog:  * Added unittest2 and pytest as build-depends.
debian/control: python3-unittest2,
tchet@brix /tmp/unittest2/python-kafka.git $

Bug#1066133: python-novaclient: please remove obsolete python3-unittest2 build dependency

[Alexandre Detiste]

Source: python-novaclient
Version: 2:18.4.0-2
Severity: normal

The only remaning reference to it dates from 2012.

Greetings,

tchet@brix /tmp/unittest2/python-novaclient.git $ grep unittest2 -r
debian/CHANGELOG:Fixes bug 980504 by introducing unittest2 module into 
novaclient.
debian/control: python3-unittest2,
tchet@brix /tmp/unittest2/python-novaclient.git $

Bug#1066117: FTBFS: missing build-dep on libnsl-dev

[Preuße]

On 12.03.2024 21:59, Aurelien Jarno wrote:

Hi Aurelien,


Starting with glibc 2.31, support for NIS (libnsl library) has been
moved to a separate libnsl2 package. In order to allow a smooth
transition, a libnsl-dev has been added to the libc6-dev package.

This dependency has been temporarily dropped in the 2.37-15.1 NMU, as
part of the 64-bit time_t transition. This causes proftpd-dfsg to FTBFS in
sid with:


I've seen the issue, but I wasn't sure if I have to do something or if I
have just have to wait until the dep change has been reverted. Let me
know if I should upload a fixed package w/ the BD added.

Thanks,
  Hilmar
--
sigfault

Bug#1066132: python-oauth2client: please remove python3-unittest2 build dependency

[Alexandre Detiste]

Source: python-oauth2client
Version: 4.1.3-5
Severity: normal

As stated in the changelog, this package does not use unittest2 anymore.

Greetings


tchet@brix /tmp/unittest2/python-oauth2client.git $ grep unittest2 -r
CHANGELOG.md:* Drop unittest2 dependency (#610)
debian/control: python3-unittest2,
tchet@brix /tmp/unittest2/python-oauth2client.git $

Bug#1066131: RFS: streamlink/6.7.0-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.7.0.

  * Package name: streamlink
Version : 6.7.0-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from
various websites (documentation)
  streamlink - CLI for extracting video streams from various websites
to a video player


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.7.0-1.dsc



Changes since the last upload to unstable:
streamlink (6.7.0-1) unstable; urgency=medium

  * New upstream version 6.7.0
  * d/patches: fix tests by resetting the logger level on teardown

 -- Alexis Murzeau   Tue, 12 Mar 2024 23:03:17 +0100

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066130: keystone: please remove extraneous python3-unittest2 build dependency

[Alexandre Detiste]

Source: keystone
Version: 2:24.0.0-3
Severity: normal

This package uses the new "unittest" from the standard library.

Greetings

tchet@brix /tmp/unittest2/keystone.git $ grep unittest2 -r .
./debian/control: python3-unittest2,
tchet@brix /tmp/unittest2/keystone.git $

Bug#1066129: neutron: please remove extraneous python3-unittest2 build dependency

[Alexandre Detiste]

Source: neutron
Version: 2:23.0.0-2
Severity: normal

This package uses the new "unittest" from the standard library.

Greetings


tchet@brix /tmp/unittest2/neutron.git $ grep unittest2 -r .
./debian/control: python3-unittest2,
tchet@brix /tmp/unittest2/neutron.git $

Bug#1062911: solvespace: NMU diff for 64-bit time_t transition

[Rylie Pavlik]

On Thu, 29 Feb 2024 17:03:41 + Benjamin Drung  wrote:

Source: solvespace
Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


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

Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Thank you for the patch and NMU! I have imported the debdiff into the 
git repo on Salsa, so the NMU will be "acknowledged" in the next 
maintainer upload of SolveSpace.


Rylie Pavlik


OpenPGP_0x9045010AE5C2B9ED.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066094: squidguard: Squidguard does not work with default squid apparmor profile

[Joachim Wiedorn]

Hello Marco,

I think we need an apparmor config file for squidguard. I never have
written such a config, but perhaps you have an example of such a config
file? Otherwise I need some time for testing to resolve this problem.

Have a nice day.

Joachim (Germany)


pgp2TBPLjodSD.pgp
Description: Digitale Signatur von OpenPGP

Bug#1066128: connman: fails to take multiple search domains into account

[Francesco Poli (wintermute)]

Package: connman
Version: 1.42-5
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining this package in Debian!
I have used it for quite some time, and I can say that it works pretty
well for most cases.

However, I have recently encountered a case where connman could work
better...
The case is a network where the DHCP server sends two domains as
"search domains" (let's call them MYDOMAIN and OTHERDOMAIN). These
two search domains are sent by the DHCP server in the
domain search list (DHCP Option 119).

If I don't use connman and configure the Ethernet network with
ifupdown (through a stanza in /etc/network/interfaces ), the DHCP
client (dhcpcd-base) writes the two search domains to /etc/resolv.conf
and everything works as intended.

If instead I use connman to connect to the Ethernet (or Wireless) network,
/etc/resolv.conf is not overwritten, since connman implements an internal
name server. Hence, the dynamically generated resolv.conf is:

  $ cat /run/connman/resolv.conf
  # Generated by Connection Manager
  nameserver ::1
  nameserver 127.0.0.1

That would be OK as /etc/resolv.conf (which could be a symlink to
/run/connman/resolv.conf ), as long as connman is aware of the two
search domains. But connman does not seem to take the two search
domains into account. In the network-specific settings of the GUI,
I see MYDOMAIN as the only domain in the "Domains" tab. However,
if I try to use non-fully-qualified host names, they are not resolved
into IP addresses:

  $ ping -c 3 HOST
  ping: HOST: Name or service not known
  $ ping -c 3 HOST.MYDOMAIN
  PING HOST.MYDOMAIN (192.168.0.143) 56(84) bytes of data.
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=1 ttl=64 time=3.81 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=2 ttl=64 time=4.99 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=3 ttl=64 time=4.79 ms
  
  --- HOST.MYDOMAIN ping statistics ---
  3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.807/4.527/4.987/0.515 ms

Moreover, this network needs

  options single-request-reopen

in /etc/resolv.conf , in order to avoid slow name server replies
(see resolv.conf(5) for more details on this option).
How can I add this option with connman?
It would be great, if connman could be configured to use this option
(globally, or, even better, on a per-network basis).
Can this be done?

Currently, I have the following /etc/resolv.conf (not a symlink):

  $ cat /etc/resolv.conf
  # Generated by dhcpcd
  options single-request-reopen
  # /etc/resolv.conf.tail can replace this line

which was left by dhcpcd-base and has the needed option.
Using this together with connman seems to work (in the sense that
it avoids the slow name server reply), but, as I said, connman does
not take the two search domains into account.


I think connman should be improved, so that it can take the two search
domains into account and it can be configured to add options to the
dynamically generated /run/connman/resolv.conf .

Another strategy could be to delegate all the DHCP client stuff to
an external DHCP client (such as dhcpcd-base, which would manage
/etc/resolv.conf directly).
Is that already possible?


Am I misunderstanding anything?

Please clarify and/or enhance the connman Debian package and/or forward
my bug report upstream, as appropriate.

Thanks for your time and dedication!




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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.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 connman depends on:
ii  dbus 1.14.10-4
ii  init-system-helpers  1.66
ii  iptables 1.8.10-3
ii  libc62.37-15
ii  libdbus-1-3  1.14.10-4
ii  libglib2.0-0 2.78.4-1
ii  libgnutls30  3.8.3-1
ii  libreadline8 8.2-3+b1
ii  libxtables12 1.8.10-3

Versions of packages connman recommends:
ii  bluez  5.71-1
pn  ofono  
ii  wpasupplicant  2:2.10-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Holger Wansing]

Hi guys,

Stéphane Blondon  wrote (Mon, 4 Mar 2024 08:29:10 
+0100):
> Hello,
> 
> Le dim. 3 mars 2024 à 11:49, Holger Wansing  a écrit :
> > So, no problem with latest Sphinx version, it seems the integration in the
> > debian-policy package is the problem (aka debian/rules) ...
> 
> Thank you for the search.
> 
> I have two wild guesses based on broken symlink assumption:
> 
> 1. By dh_auto_install
> 
> buildd create symbolic links to the files (like theme.css) provided by
> python3-sphinx-rtd-theme:
> lrwxrwxrwx root/root 0 2024-02-24 12:39
> ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css ->
> ../../../../../sphinx_rtd_theme/static/css/theme.css
> (found in the log file)
> 
> Then the target dh_auto_install in debian/rules from debian_policy
> moves files (line 15):
> mv debian/tmp/* debian/debian-policy/
> 
> The symlink is relative so it could be broken.

It appears to me that the target for that symlink 
(../../../../../sphinx_rtd_theme/static/css/theme.css) is not existing
and therefore we get an empty file.

I did some testing with debuild, and changed debian/rules (line 4) like

-   dh $@ --with sphinxdoc
+   dh $@

and that way I get a valid html document with the new theme working !!!

(That is something of a revert of
https://salsa.debian.org/dbnpolicy/policy/-/commit/528ad4d79a76690eeb0504fd6c094a88ddb9739d
 )

Please note that I did not check for any other differences in the package
created that way compared to the latest version in the archive (debdiff).
An sbuild run was successful that way as well.

Seems there is something wrong in the debhelper / dh_sphinxdoc world 
(or at least an incompatibility with read-the-doc themes) ...

But that's out of my skills

Applying above change could at least be a temporary way to get the policy
back in shape on the website ...


Holger



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

Bug#1066126: RFA: rust-enum-unitary -- Trait and macro for unitary enums - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-enum-unit...@packages.debian.org, 
debian-r...@lists.debian.org, stephanlach...@debian.org
Control: affects -1 + src:rust-enum-unitary

I request an adopter for the rust-enum-unitary package. If you adopt this
package, please remove me from the uploaders list.

The package description is:
 This package contains the source for the Rust enum-unitary crate, packaged by
 debcargo for use with cargo and dh-cargo.

Bug#1066127: RFA: rust-kmon -- Interactive kernel monitor that combines dmesg and kmod

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-k...@packages.debian.org, debian-r...@lists.debian.org, 
stephanlach...@debian.org
Control: affects -1 + src:rust-kmon

I request an adopter for the rust-kmon package. If you adopt this package,
please remove me from the uploaders list.

The package description is:
 kmon is an interactive kernel monitor for the terminal. It can insepct and
load
 kernel modules, and it can monitor kernel activity. It basically combines
dmesg
 and kmod into one application. Note that is probably needs to run as root.

Bug#1066125: RFA: rust-enum-iterator-derive -- Procedural macro to iterate over the variants of a field-less enum - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-enum-iterator-der...@packages.debian.org, 
debian-r...@lists.debian.org, stephanlach...@debian.org
Control: affects -1 + src:rust-enum-iterator-derive

I request an adopter for the rust-enum-iterator-derive package. If you adopt
this package, please remove me from the uploaders list.

The package description is:
 This package contains the source for the Rust enum-iterator-derive crate,
 packaged by debcargo for use with cargo and dh-cargo.

Bug#1066124: RFA: rust-enum-iterator -- Tools to iterate over the variants of a field-less enum - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-enum-itera...@packages.debian.org, 
debian-r...@lists.debian.org, stephanlach...@debian.org
Control: affects -1 + src:rust-enum-iterator

I request an adopter for the rust-enum-iterator package. If you adopt this
package, please remove me from the uploaders list.

The package description is:
 This package contains the source for the Rust enum-iterator crate, packaged by
 debcargo for use with cargo and dh-cargo.

Bug#1066123: RFA: rust-colorsys -- Module for color conversion and mutation - Rust source code

[Stephan Lachnit]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rust-color...@packages.debian.org, debian-r...@lists.debian.org, 
stephanlach...@debian.org
Control: affects -1 + src:rust-colorsys

I request an adopter for the rust-colorsys package. If you adopt this package,
please remove me from the uploaders list.

The package description is:
 Works with RGB(a)( as hexadecimal too), HSL(a), CMYK color models and with
ANSI
 color codes
 .
 This package contains the source for the Rust colorsys crate, packaged by
 debcargo for use with cargo and dh-cargo.

Bug#1037277:

[James Addison]

severity -1 wishlist
thanks

Dear Maintainer,

Because Debian builds packages from a fixed build path, neither the 'reprotest'
utility in Salsa-CI, nor the Reproducible Builds team's package test
infrastructure for Debian[1] currently check for equivalent binary package
output from differing source package build paths.

This means that your package will pass current reproducibility tests; however
we believe that source code and/or build steps still embed the build path into
the binary package output, making it more difficult than necessary for
independent consumers to check the integrity of binary packages by recompiling
them themselves.

As a result, this bugreport will remain open and be re-assigned the 'wishlist'
severity[2].

For more information about build paths and how they can affect reproducibility,
please refer to: https://reproducible-builds.org/docs/build-path/

Thanks,
James

[1] - https://tests.reproducible-builds.org/debian/reproducible.html

[2] - https://www.debian.org/Bugs/Developer#severities

Bug#1066122: ionos3 configured twice

[Holger Levsen]

package: jenkins.debian.org

some cleanup needs to be done here, we dont need two hosts.

also twitter is dead, so maybe not even one.

though maybe we wanted a mastadon bot?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

I miss the old days were billionaires’ vanity projects were to build 1000 public
libraries or giant music venues.


signature.asc
Description: PGP signature

Bug#1066121: ionos 5/6/15/16 loosing network

[Holger Levsen]

package: jenkins.debian.org

(this has been ongoing for month already)

< h01ger> mapreri: i think we need to put restarting network into some sort of 
'cronjob' (probably only if network is down), ionos5 is been gone since several 
hours and thus half the amd64 builders are down now
< h01ger> not sure how to test if network is up, ping -c 1 8.8.8.8 ?
< mapreri> fwiw, testing the network is actually this very easy:
< mapreri> mattia@ionos5-amd64 ~ % ip -br a
< mapreri> lo   UNKNOWN127.0.0.1/8 ::1/128
< mapreri> eth0 UP fe80::1:5dff:fedf:3b89/64
< mapreri> mattia@ionos5-amd64 ~ % sudo service networking restart
< mapreri> mattia@ionos5-amd64 ~ % ip -br a
< mapreri> lo   UNKNOWN127.0.0.1/8 ::1/128
< mapreri> eth0 UP 85.184.249.130/32 
fe80::1:5dff:fedf:3b89/64
< mapreri> mattia@ionos5-amd64 ~ % 
< mapreri>  
< mapreri> but still, I'd really really prefer to figure out what's happening 
inside those 4 affected hosts :(
< h01ger> what are the 4 nodes?
< h01ger> all ionos/ffm datacenter?
< h01ger> (ffm=frankfurt/main)
< mapreri> yes
< mapreri> 5 6 15 16
 * | h01ger will file a bug using this irc log
< mapreri> today it seems to be only 5, for whatever reason.
< h01ger> i think i might have seen 2+12 loosing network too, but that might 
have been other i386 related failures. i dont think i've seen this with 1+11
< mapreri> (fwiw, `ip -br -4 a show dev eth0` is currently the shortest command 
I use to get a parsable ip4 address)
< h01ger> s#i dont think i've seen this with 1+11#i haven't seen this with 1+11#
< h01ger> those addresses are assigned by dhcp, arent they?
< mapreri> they are
< h01ger> hmm
< mapreri> but it doesn't happen with 3 7 10 that are also there
< mapreri> so I don't think we can blame ionos
< h01ger> in ffm you mean
< mapreri> yep
< h01ger> nods


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Manchmal kommt der Wind von Lee. (Konny)


signature.asc
Description: PGP signature

Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Michael Biebl]

On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer  wrote:

Luca Boccassi wrote:
[...]
> I don't think this is something we should facilitate by default or
> spend any energy on.
>
> You can correct me if I'm wrong, but I don't see any good reason why
> anybody would need to run a polkitd:i386 on an otherwise amd64 system.
> It's not what happens by default if you have i386 enabled and you type
> 'apt install polkitd' or so.

I agree that there isn't a good reason, and I'm not sure how I ended
up in that situation in the first place (the log files don't go back
far enough). One thing I do know is that polkitd:i386 was marked as
automatically installed, so I almost certainly did not make that
decision deliberately.

My speculation is that this happened while satisfying dependencies for
a third party i386 application. That meant installing required 32 bit
libraries, and one of them must have come with a polkitd dependency,
and the i386 version was selected because I was installing an i386
package.

Anyway, I reported this because I assumed that pinning packages to the
native architecture was easy, so it would be justified even for this
(hopefully!) rare scenario... apparently that's not the case.



As mentioned, unfortunately there is no way to express this dependency 
in a strait forward way.


I've contemplated dropping the Multi-Arch: foreign notation in systemd 
and maybe also for policykit-1.


Is there a valid use case where we need/want a foreign systemd/policykit-1?



Michael




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#709639: backup: root entry needed in /etc/aliases

[Charles Curley]

On Fri, 24 May 2013 10:13:15 -0600 Charles Curley
 wrote:
> Package: amanda-common
> Version: 1:2.6.1p2-3
> Severity: normal
> 
> I recently discovered by accident that amanda has been sending emails
> complaining of a minor problem. Unfortunately, since amanda runs as
> user backup, it sends them to the user backup. Currently, if you
> never log onto the user backup long enough to have the shell check
> for mail, or otherwise check /var/mail, you never learn of those
> emails.
> 
> Proposed solution: add an entry "backup: root" to /etc/aliases and run
> newaliases at installation time (assuming both are present).
> 
> I see this in Squeeze (amanda 1:2.6.1p2-3), but I believe it also
> applies to Wheezy (1:3.3.1-4)
> 

I am still seeing this in Bookworm, amanda-server 1:3.5.1-11+deb12u1,
amd64.

Proposed fix:

if [ -e /etc/aliases ]; then
if ! grep backup /etc/aliases > /dev/null ; then
echo "backup: root" >> /etc/aliases
newaliases
fi
fi


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Antonio Terceiro]

On Tue, Mar 12, 2024 at 09:13:09PM +0100, Sebastian Andrzej Siewior wrote:
> tried with 1.50+nmu2 which is in deferred for the next 11h. So tomorrow
> it should be all good.

Please make sure to commit the patch to the pristine-tar git repository
as well.


signature.asc
Description: PGP signature

Bug#1066120: 389-ds-base: CVE-2024-1062

[Salvatore Bonaccorso]

Source: 389-ds-base
Version: 2.4.4+dfsg1-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/389ds/389-ds-base/issues/5647
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2024-1062[0]:
| A heap overflow flaw was found in 389-ds-base. This issue leads to a
| denial of service when writing a value larger than 256 chars in
| log_entry_attr.


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-2024-1062
https://www.cve.org/CVERecord?id=CVE-2024-1062
[1] https://github.com/389ds/389-ds-base/issues/5647

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Jeremy Bícha]

On Tue, Mar 12, 2024 at 4:13 PM Sebastian Andrzej Siewior
 wrote:
>
> On 2024-03-12 09:26:32 [-0400], Jeremy Bícha wrote:
> > > Could someone check this, please?
> >
> > Did you try running autopkgtests on this version? The autopkgtests fail for 
> > me.
>
> autopkgtests were the first thing that pointed me here and they passed.
> If you say they fail for you then I may have used the wrong xz version…

I tried running the autopkgtests locally using a version of 1.50+nmu2
that I built using your patch and the autopkgtests failed.

None of the 3 test cases passed for me with that version or with 1.50+nmu1.

Thank you,
Jeremy Bícha

Bug#1066118: telegram-desktop: does not start under Debian sid

[Paul Martin]

Package: telegram-desktop
Version: 4.14.9+ds-1+b1
Severity: grave
Justification: renders package unusable

It depends on a symbol not present in the current libqt5quick5 
(automatically rebuilt as part of the time_t migration).

$ telegram-desktop
telegram-desktop: symbol lookup error: /lib/x86_64-linux-gnu/libQt5Quick.so.5: 
undefined symbol: 
_ZN18QTextureGlyphCache8populateEP11QFontEngineiPKjPK11QFixedPoint, version 
Qt_5_PRIVATE_API

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20220623t64   20220623.1-3.1
ii  libavcodec60 7:6.1.1-2
ii  libavfilter9 7:6.1.1-2
ii  libavformat607:6.1.1-2
ii  libavutil58  7:6.1.1-2
ii  libc62.37-15.1
ii  libgcc-s114-20240303-1
ii  libglib2.0-0t64  2.78.4-4
ii  libglibmm-2.68-1t64  2.78.1-2.2
ii  libhunspell-1.7-01.7.2+really1.7.2-10+b1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libkf5coreaddons55.107.0-1+b1
ii  liblz4-1 1.9.4-1+b2
ii  libminizip1t64   1:1.3.dfsg-3.1
ii  libopenal1   1:1.23.1-4+b1
ii  libopus0 1.4-1+b1
ii  libqrcodegencpp1 1.8.0-1.2+b1
ii  libqt5core5t64 [qtbase-abi-5-15-10]  5.15.10+dfsg-7.2+b1
ii  libqt5gui5t645.15.10+dfsg-7.2+b1
ii  libqt5network5t645.15.10+dfsg-7.2+b1
ii  libqt5qml5   5.15.10+dfsg-2+b1
ii  libqt5quick5 5.15.10+dfsg-2+b1
ii  libqt5quickwidgets5  5.15.10+dfsg-2+b1
ii  libqt5svg5   5.15.10-2+b1
ii  libqt5waylandcompositor5 5.15.10-2+b2
ii  libqt5widgets5t645.15.10+dfsg-7.2+b1
ii  librlottie0-10.1+dfsg-4+b2
ii  libsigc++-3.0-0  3.6.0-1
ii  libsrtp2-1   2.5.0-3
ii  libssl3t64   3.1.5-1.1
ii  libstdc++6   14-20240303-1
ii  libswresample4   7:6.1.1-2
ii  libswscale7  7:6.1.1-2
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-record0   1.15-1
ii  libxcb-screensaver0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  libxxhash0   0.8.2-2+b1
ii  libyuv0  0.0~git202401110.af6ac82-1
ii  qt5-image-formats-plugins5.15.10-2+b1
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-2
ii  libwebkit2gtk-4.0-37  2.42.5-1+b2
ii  libwebkit2gtk-4.1-0   2.42.5-1+b2

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.18.2-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.15.1-1

-- no debconf information
[2024.03.08 13:09:47] Launched version: 4015001, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2024.03.08 13:09:47] Executable dir: /tmp/Telegram/, name: Telegram
[2024.03.08 13:09:47] Initial working dir: /tmp/Telegram/
[2024.03.08 13:09:47] Working dir: /home/pm/.local/share/TelegramDesktop/
[2024.03.08 13:09:47] Command line: ./Telegram
[2024.03.08 13:09:47] Executable path before check: /tmp/Telegram/Telegram
[2024.03.08 13:09:47] Logs started
[2024.03.08 13:09:47] App ID: 
org.telegram.desktop._c898ff95bd08685f9e37429ed2c529f6
[2024.03.08 13:09:47] Connecting local socket to 
0f980833885dc97616380fc10e7837b3-TelegramDesktop...
[2024.03.08 13:09:47] Socket connect error 0, starting server and app...
[2024.03.08 13:09:47] Moved logging from 
'/home/pm/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/pm/.local/share/TelegramDesktop/log.txt'!
[2024.03.08 13:09:47] 

Bug#1066119: fastdds: CVE-2023-50716

[Salvatore Bonaccorso]

Source: fastdds
Version: 2.11.2+ds-6.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.11.2+ds-6

Hi,

The following vulnerability was published for fastdds.

CVE-2023-50716[0]:
| eProsima Fast DDS (formerly Fast RTPS) is a C++ implementation of
| the Data Distribution Service standard of the Object Management
| Group. Prior to versions 2.13.0, 2.12.2, 2.11.3, 2.10.3, and 2.6.7,
| an invalid DATA_FRAG Submessage causes a bad-free error, and the
| Fast-DDS process can be remotely terminated. If an invalid Data_Frag
| packet is sent, the `Inline_qos, SerializedPayload` member of object
| `ch` will attempt to release memory without initialization,
| resulting in a 'bad-free' error. Versions 2.13.0, 2.12.2, 2.11.3,
| 2.10.2, and 2.6.7 fix this issue.


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-2023-50716
https://www.cve.org/CVERecord?id=CVE-2023-50716
[1] https://github.com/eProsima/Fast-DDS/security/advisories/GHSA-5m2f-hvj2-cx2h

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Dylan Aïssi]

Hello,

Le mar. 12 mars 2024 à 20:45, Carlos Henrique Lima Melara
 a écrit :
>
> Taking this into consideration and the outcome of Init systems and
> systemd GR [3], I'd like to check with you the possibility of enabling the
> support for libseat launcher in stable via a proposed-updates upload to
> bookworm.

I'm not against that, but we will have to convince the release team that
it won't introduce new bugs. That means we have to fill a bug report
against the pseudo-package "release.debian.org".

If we are going to touch the package in Bookworm, I would like to try
pushing the last bugfix release of the serie 10.0. It was a private
request from upstream but I didn't realized that there were very few
changes in the bugfix releases, it's worth a try. What do you think?

I can try this week to prepare an updated package in a dedicated branch
in salsa, so you can test it. Then, if everything is okay, we could fill
the request to the release team.

> I did rebuild bookworm's version with the option enabled and tested it a
> bit in my notebook. I've also used abi-compliance-checker to check if
> this could have caused any ABI change in libweston and it didn't. I'll
> provide the debdiff output for you to check.
>
> Also, should you answer positively, I can do a more exhaustive testing
> and check if we don't introduce any errors when running with elogind and
> systemd-logind.

This will be very useful to convince the release team.

Best regards,
Dylan

Bug#1065841: Taking over datalad to either Debian Med or Debian Science team

[Andreas Tille]

Hi Yaroslav,

Am Tue, Mar 12, 2024 at 03:50:22PM -0400 schrieb Yaroslav Halchenko:
> Let's keep DataLad under our (NeuroDebian) umbrella for now, since we
> are also upstream there and project is active.  We are also
> working with Vasyl (CCed) to experiment with some semi-automation for
> package updates/backports (for neurodebian) and datalad (and some of its
> ecosystem) packages are the target.  Packaging will be on salsa.  We
> might move them under larger Med or Science teams, but not just yet.

That's perfectly fine and all I would like to see.  No presure.
 
> Re #1065841 specifically -- while trying to build updated package I
> experienced some odd side-effect (pip started to try to install
> tqdm) and didn't see immediate reason.I will see how well it goes on
> debian infra after source only upload (did now).

I perfectly trust you to maintain this package properly.  I simply
was querying this type of bug and thought datalad would nicely fit
into Debian Science scope.

Kind regards
Andreas. 

-- 
http://fam-tille.de

Bug#1065759: Retitle libbio-samtools-perl: FTBFS on arm{el,hf}: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-fu

[Niko Tyni]

Control: tag -1 patch

On Tue, Mar 12, 2024 at 06:31:20PM +0100, Andreas Tille wrote:
 
> I can confirm that this bug also occures on amd64 thus removing the
> arm-restriction from the title.  Unfortunately I have no idea how to fix
> this (except by possibly suppressing the -Werror=implicit-function-declaration
> option).  Thus tagging 'help'

Looks like bam_view1() and bam_sort_core() don't have prototypes in
any header file in libbam-dev. Copying them from the actual .c files
in samtools-legacy seems to work.

Patch attached, this builds and passes the test suite for me.
-- 
Niko
>From 3ddc905c9ceb635c6c876de1d372eedaa45de425 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Tue, 12 Mar 2024 20:53:33 +
Subject: [PATCH] Lift prototypes of bam_view1 and bam_sort_core from bam.c in
 samtools-legacy

This fixes builds with gcc -Werror=implicit-function-declaration .

Bug-Debian: https://bugs.debian.org/1065759
---
 lib/Bio/DB/Sam.xs | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/Bio/DB/Sam.xs b/lib/Bio/DB/Sam.xs
index 023f655..2231477 100644
--- a/lib/Bio/DB/Sam.xs
+++ b/lib/Bio/DB/Sam.xs
@@ -32,6 +32,11 @@
 /* stolen from bam_aux.c */
 #define MAX_REGION 1<<29
 
+/* stolen from bam.c */
+extern void bam_view1(const bam_header_t *header, const bam1_t *b);
+/* stolen from bam_sort.c */
+extern void bam_sort_core(int is_by_qname, const char *fn, const char *prefix, size_t max_mem);
+
 typedef tamFile Bio__DB__Tam;
 typedef faidx_t*Bio__DB__Sam__Fai;
 typedef bamFile Bio__DB__Bam;
-- 
2.43.0

Bug#1066117: FTBFS: missing build-dep on libnsl-dev

[Aurelien Jarno]

Source: proftpd-dfsg
Version: 1.3.8.b+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libnsl-dev

Dear maintainer,

Starting with glibc 2.31, support for NIS (libnsl library) has been
moved to a separate libnsl2 package. In order to allow a smooth
transition, a libnsl-dev has been added to the libc6-dev package.

This dependency has been temporarily dropped in the 2.37-15.1 NMU, as
part of the 64-bit time_t transition. This causes proftpd-dfsg to FTBFS in
sid with:

| /bin/bash ../libtool --mode=compile --tag=CC gcc -Wdate-time 
-D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H  -DLINUX  -I.. -I../include -I../include 
-I/usr/include/mariadb/mysql -I/usr/include/mariadb -I/usr/include/postgresql 
-I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/usr/include/postgresql 
-Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-fno-omit-frame-pointer -fno-strict-aliasing 
-Werror=implicit-function-declaration -g -O2 
-ffile-prefix-map=/<>/modules=. -fstack-protector-strong -Wformat 
-Werror=format-security -DPR_SHARED_MODULE -c ../modules/mod_wrap2_file.c
| libtool: compile:  gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H 
-DLINUX -I.. -I../include -I../include -I/usr/include/mariadb/mysql 
-I/usr/include/mariadb -I/usr/include/postgresql -I/usr/include/mariadb 
-I/usr/include/mariadb/mysql -I/usr/include/postgresql -Wdate-time 
-D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-fno-omit-frame-pointer -fno-strict-aliasing 
-Werror=implicit-function-declaration -g -O2 
-ffile-prefix-map=/<>/modules=. -fstack-protector-strong -Wformat 
-Werror=format-security -DPR_SHARED_MODULE -c ../modules/mod_wrap2_file.c  
-fPIC -DPIC -o .libs/mod_wrap2_file.o
| gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H  -DLINUX  -I.. 
-I../include -I../include -I/usr/include/mariadb/mysql -I/usr/include/mariadb 
-I/usr/include/postgresql -I/usr/include/mariadb -I/usr/include/mariadb/mysql 
-I/usr/include/postgresql -Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing 
-Werror=implicit-function-declaration -g -O2 
-ffile-prefix-map=/<>/src=. -fstack-protector-strong -Wformat 
-Werror=format-security -c trace.c
| /bin/bash ../libtool --mode=link --tag=CC gcc -o mod_wrap.la -rpath 
/usr/lib/proftpd -Wl,-L../lib,-L../lib -Wl,-z,relro -Wl,-z,now -rdynamic  
-L/usr/lib/i386-linux-gnu/ -L/usr/lib/i386-linux-gnu -Wl,-z,relro -Wl,-z,now 
-avoid-version -export-dynamic -module -lidn2 -lsodium mod_wrap.lo `cat 
../modules/mod_wrap.c | grep '$Libraries:' | sed -e 's/^.*\$Libraries: 
\(.*\)\\$/\1/'`
| libtool: link: gcc -shared  .libs/mod_wrap.o   -L/usr/lib/i386-linux-gnu/ 
-L/usr/lib/i386-linux-gnu -lidn2 -lsodium -lwrap -lnsl  -Wl,-L../lib 
-Wl,-L../lib -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now   
-Wl,-soname -Wl,mod_wrap.so -o .libs/mod_wrap.so
| /usr/bin/ld: cannot find -lnsl: No such file or directory
| collect2: error: ld returned 1 exit status
| make[3]: *** [Makefile:34: mod_wrap.la] Error 1
| make[3]: *** Waiting for unfinished jobs

The full build log can be found here:
https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg=i386=1.3.8.b%2Bdfsg-1%2Bb2=1710157209=0

This can be fixed by adding an explicit Build-Depends on libnsl-dev.

Regards
Aurelien

Bug#1066116: libssl3: 3.1.4-2 NEWS entry seems incorrect

[Calum McConnell]

Package: libssl3
Version: 3.1.5-1
Severity: minor

The news entry for 3.1.4-2 says, "TLSv1.0, TLSv1.1 and DTLS 1.0 work only at 
security level 0 (it was
  previously allowed at security level 0)"

By my reading, this is saying that 3.1.4-2 changes legacy TLS to work only at 
security level zero,
from the previous state of... them working only at security level zero.  In 
other words, that there
is no change.

I couldn't find the commit that changed this, so I can't say what the 
parenthetical should contain;
please consider either dropping the "it was previously allowed..." section, or 
changing it to
"allowed at security level 2" or whatever the correct answer is.


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

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

Versions of packages libssl3 depends on:
ii  libc6  2.37-15

libssl3 recommends no packages.

libssl3 suggests no packages.

-- no debconf information

Bug#1065841: Taking over datalad to either Debian Med or Debian Science team

[Yaroslav Halchenko]

Hi Andreas,

Let's keep DataLad under our (NeuroDebian) umbrella for now, since we
are also upstream there and project is active.  We are also
working with Vasyl (CCed) to experiment with some semi-automation for
package updates/backports (for neurodebian) and datalad (and some of its
ecosystem) packages are the target.  Packaging will be on salsa.  We
might move them under larger Med or Science teams, but not just yet.

Re #1065841 specifically -- while trying to build updated package I
experienced some odd side-effect (pip started to try to install
tqdm) and didn't see immediate reason.I will see how well it goes on
debian infra after source only upload (did now).

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#1066115: mpg123: FTBFS: error: implicit declaration of function ‘mpg321_alsa_get_volume’ [-Werror=implicit-function-declaration]

[Sebastian Ramacher]

Source: mpg321
Version: 0.3.2-3.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=mpg321=armel=0.3.2-3.1%2Bb1=1710256758=0

gcc -DHAVE_CONFIG_H -I. -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -Wall -Wunused 
-Wno-error=format-security -fcommon  -I/usr/include -DHAVE_ALSA -MT mpg321.o 
-MD -MP -MF .deps/mpg321.Tpo -c -o mpg321.o mpg321.c
mpg321.c:102:8: warning: type defaults to ‘int’ in declaration of 
‘http_file_length’ [-Wimplicit-int]
  102 | extern http_file_length;
  |^~~~
mpg321.c: In function ‘read_keyb’:
mpg321.c:132:27: error: implicit declaration of function 
‘mpg321_alsa_get_volume’ [-Werror=implicit-function-declaration]
  132 | bvolume = mpg321_alsa_get_volume();
  |   ^~
mpg321.c:173:33: error: implicit declaration of function 
‘mpg321_alsa_set_volume’ [-Werror=implicit-function-declaration]
  173 | mpg321_alsa_set_volume(bvolume);
  | ^~
mpg321.c:186:75: warning: format ‘%ld’ expects argument of type ‘long int’, but 
argument 3 has type ‘int’ [-Wformat=]
  186 | fprintf(stderr,"Volume: 
%ld%%  \r",volume);
  | 
~~^~~
  | 
  ||
  | 
  long int int
  | 
%d
mpg321.c:236:75: warning: format ‘%ld’ expects argument of type ‘long int’, but 
argument 3 has type ‘int’ [-Wformat=]
  236 | fprintf(stderr,"Volume: 
%ld%%  \r",volume);
  | 
~~^~~
  | 
  ||
  | 
  long int int
  | 
%d
mpg321.c: In function ‘show_id3’:
mpg321.c:450:24: warning: format not a string literal and no format arguments 
[-Wformat-security]
  450 | printf(emptystring);
  |^~~
mpg321.c:468:34: warning: format not a string literal and no format arguments 
[-Wformat-security]
  468 | fprintf (stderr, emptystring);
  |  ^~~
mpg321.c: In function ‘main’:
mpg321.c:688:17: error: implicit declaration of function 
‘init_alsa_volume_control’ [-Werror=implicit-function-declaration]
  688 | init_alsa_volume_control("default"); /* For the moment 
use "default", it works on most of the systems. Tested in 
Debian,Fedora,Ubuntu,RedHat,CentOS,Gentoo */
  | ^~~~
mpg321.c:882:13: error: implicit declaration of function ‘calc_http_length’; 
did you mean ‘calc_length’? [-Werror=implicit-function-declaration]
  882 | calc_http_length();
  | ^~~~
  | calc_length
mpg321.c: In function ‘id3_get_tag’:
mpg321.c:1237:31: warning: pointer targets in passing argument 1 of ‘strlen’ 
differ in signedness [-Wpointer-sign]
 1237 | if (!latin1 || strlen(latin1) == 0) return (NULL);
  |   ^~
  |   |
  |   id3_latin1_t * {aka unsigned char *}
In file included from mpg321.c:35:
/usr/include/string.h:407:35: note: expected ‘const char *’ but argument is of 
type ‘id3_latin1_t *’ {aka ‘unsigned char *’}
  407 | extern size_t strlen (const char *__s)
  |   ^~~
mpg321.c:1238:22: warning: pointer targets in passing argument 1 of ‘strlen’ 
differ in signedness [-Wpointer-sign]
 1238 | len = strlen(latin1);
  |  ^~
  |  |
  |  id3_latin1_t * {aka unsigned char *}
/usr/include/string.h:407:35: note: expected ‘const char *’ but argument is of 
type ‘id3_latin1_t *’ {aka ‘unsigned char *’}
  407 | extern size_t strlen (const char *__s)
  |   ^~~
mpg321.c:1245:29: warning: pointer targets in passing argument 2 of ‘strncat’ 
differ in signedness [-Wpointer-sign]
 1245 | strncat (printable, latin1, tocopy);
  | ^~
  | |
  | 

Bug#1066114: libzookeeper-java missing PrometheusMetricsProvider

[Sven Dewit]

Package: libzookeeper-java
Version: 3.8.0-11+deb12u1

Zookeeper comes with a new metrics systems since 3.6.0, enabling users
to monitor several aspects of the service. This new metrics system also
supports Prometheus monitoring, see
https://zookeeper.apache.org/doc/current/zookeeperMonitor.html#Prometheus.
Unfortunately, Debian's libzookeeper-java does not seem to build and
bundle the necessary class PrometheusMetricsProvider.

The assumption was that it is possible to monitor Zookeeper on Debian
using Prometheus.

The system used is Debian bookworm with Java 11/17 and latest Zookeeper
packages.

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Sebastian Andrzej Siewior]

On 2024-03-12 09:26:32 [-0400], Jeremy Bícha wrote:
> > Could someone check this, please?
> 
> Did you try running autopkgtests on this version? The autopkgtests fail for 
> me.

autopkgtests were the first thing that pointed me here and they passed.
If you say they fail for you then I may have used the wrong xz version…

> I assume that the largest use of pristine-tar in Debian is with
> git-buildpackage. The 1.50+nmu1 upload **caused** pristine-tar to
> break in many cases for me. If I revert back to 1.50, I no longer get
> mismatched tarballs errors. Here are some test cases to demonstrate:
> 
> Test Case 1
> ==
> gbp clone --add-upstream-vcs https://salsa.debian.org/jbicha/pangomm2.48
> 
> cd pangomm2.48
> 
> gbp import-orig --uscan
> 
> gbp buildpackage
> 
> What happens
> --
> The exact hashes will probably vary but I get an error like this:
> 
> gbp:error: Pristine-tar couldn't verify
> "pangomm2.48_2.50.2.orig.tar.xz": pristine-tar:
> /home/jeremy/build-area/pangomm2.48_2.50.2.orig.tar.xz does not match
> stored hash (expected
> e99b6a9c89e9c284bf44f5ae8125c06515d6ab8f8577d75d2887726dacb5a372, got
> 826ad52f53ac8e15c9ceba4dc6e616efddae5e089f36bf4e60081c177d80d4b6)

| (sid)bigeasy@debbuildd:~/pristine$ gbp clone --add-upstream-vcs 
https://salsa.debian.org/jbicha/pangomm2.48
| gbp:info: Cloning from 'https://salsa.debian.org/jbicha/pangomm2.48'
| gbp:info: Adding upstream vcs at https://gitlab.gnome.org/GNOME/pangomm.git 
as additional remote
| (sid)bigeasy@debbuildd:~/pristine$ cd pangomm2.48
| (sid)bigeasy@debbuildd:~/pristine/pangomm2.48$ gbp import-orig --uscan
| gbp:info: Launching uscan...
| Newest version of pangomm2.48 on remote site is 2.50.2, local version is 
2.50.1
|  => Newer package available from:
| => 
https://download.gnome.org/sources/pangomm/2.50/pangomm-2.50.2.tar.xz
| Successfully repacked ../pangomm-2.50.2.tar.xz as 
../pangomm2.48_2.50.2.orig.tar.xz, deleting 416 files from it.
| gbp:info: Using uscan downloaded tarball ../pangomm2.48_2.50.2.orig.tar.xz
| What is the upstream version? [2.50.2]
| gbp:info: Importing '../pangomm2.48_2.50.2.orig.tar.xz' to branch 
'upstream/latest'...
| gbp:info: Source package is pangomm2.48
| gbp:info: Upstream version is 2.50.2
| gbp:info: Replacing upstream source on 'debian/latest'
| gbp:info: Running Postimport hook
| dch warning: neither DEBEMAIL nor EMAIL environment variable is set
| dch warning: building email address from username and FQDN
| dch: Did you see those 2 warnings?  Press RETURN to continue...
|
| git commit -m 'New upstream release'
| [debian/latest f5c4f6d14a78] New upstream release
|  1 file changed, 5 insertions(+), 2 deletions(-)
| gbp:info: Successfully imported version 2.50.2 of 
../pangomm2.48_2.50.2.orig.tar.xz

passed.

> Other info
> -
> pangomm2.48 uses Files-Excluded in debian/copyright so uscan will
> rebuild a tarball and its hash will vary depending on the time it was
> created. (Perhaps the hash should be reproducible but that's not
> relevant to this bug.)
> 
> Test Case 2
> =
> gbp clone https://salsa.debian.org/gnome-team/gtk4
> cd gtk4
> gbp buildpackage
> 
> What happens
> 
> gbp:error: Pristine-tar couldn't verify "gtk4_4.12.5+ds.orig.tar.xz":
> pristine-tar: 
> /home/jeremy/devel/pkg-gnome/temp/build-area/gtk4_4.12.5+ds.orig.tar.xz
> does not match stored hash (expected
> 3338a691d774ae031af65299e9a1c6207f543f13b256539717a1970f752358cb, got
> 70ac33e0f37dc1b657d6560f1b8a40b3f4b67e956936633ced495d8b880d3fb0)

| (sid)bigeasy@debbuildd:~/pristine$ gbp clone 
https://salsa.debian.org/gnome-team/gtk4
| gbp:info: Cloning from 'https://salsa.debian.org/gnome-team/gtk4'
| (sid)bigeasy@debbuildd:~/pristine$ cd gtk4
| (sid)bigeasy@debbuildd:~/pristine/gtk4$ gbp buildpackage  

 
| gbp:info: Creating /home/bigeasy/pristine/gtk4_4.12.5+ds.orig.tar.xz
| gbp:info: Performing the build
|  dpkg-buildpackage -us -uc -ui -i -I
| dpkg-buildpackage: info: source package gtk4
| dpkg-buildpackage: info: source version 4.12.5+ds-4

passed.

> Other info
> 
> This pristine-tar tarball was committed January 19 so it did not use
> either the new xz-utils or pristine-tar.
> 
> Test Case 3
> =
> gbp clone https://salsa.debian.org/gnome-team/pango
> cd pango
> gbp buildpackage
> 
> What happens
> ---
> gbp:error: Pristine-tar couldn't verify
> "pango1.0_1.52.1+ds.orig.tar.xz": pristine-tar:
> /home/jeremy/devel/pkg-gnome/temp/build-area/pango1.0_1.52.1+ds.orig.tar.xz
> does not match stored hash (expected
> 12d67d8182cbb2ae427406df9bab5ce2ff5619102bf2a0fc6331d80a9914b139, got
> a641d29d2d7df7843e44762a0733987dc8220d238b697b382dd96fafe5fc890a)

| (sid)bigeasy@debbuildd:~/pristine$ gbp clone 
https://salsa.debian.org/gnome-team/pango
| gbp:info: Cloning from 'https://salsa.debian.org/gnome-team/pango'
| 

Bug#1066113: guix: CVE-2024-27297

[Salvatore Bonaccorso]

Source: guix
Version: 1.4.0-5
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.2.0-4+deb11u1


Hi,

Vagrant, knowing that you are awaere already, but filling for having a
Debian bug tracking reference.

The following vulnerability was published for guix.

CVE-2024-27297[0]:
| Nix is a package manager for Linux and other Unix systems. A fixed-
| output derivations on Linux can send file descriptors to files in
| the Nix store to another program running on the host (or another
| fixed-output derivation) via Unix domain sockets in the abstract
| namespace. This allows to modify the output of the derivation, after
| Nix has registered the path as "valid" and immutable in the Nix
| database. In particular, this allows the output of fixed-output
| derivations to be modified from their expected content. This issue
| has been addressed in versions 2.3.18 2.18.2 2.19.4 and 2.20.5.
| Users are advised to upgrade. There are no known workarounds for
| this vulnerability.


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-2024-27297
https://www.cve.org/CVERecord?id=CVE-2024-27297
[1] 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8f4ffb3fae133bb21d7991e97c2f19a7108b1143

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1060318: Could be related to LLVM rather than PoCL: works with LLVM-15

[PICCA Frederic-Emmanuel]

bravo !!!

This is team works. :))

Cheers

Frederic

Bug#1060318: Could be related to LLVM rather than PoCL: works with LLVM-15

[Andreas Beckmann]

Control: reassign -1 src:pocl 5.0-1 .
Control: affects -1 src:silx
Control: tag -1 upstream

On Mon, 11 Mar 2024 13:54:08 +0100 Jerome Kieffer 
 wrote:

I managed to get the test pass on PoCL v3, v4 and v5 using the same LLVM 15 (on 
a basis of silx development branch ... on a debian stable base)
I suspect the regression is in the version of LLVM more than in PoCL or silx. 


This is a PoCL regression, reproducible with PoCL 5.0 built in sid with 
LLVM 14,15,16 (no others tried).
For a bisected commit where it started (unfortunately not a minimal 
commit) and a minimized reproducer please see the PoCL upstream bug.


Once upstream finds a solution I'll cherry-pick that into PoCL.


Andreas

Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)

[Jeremy Bícha]

On Tue, Mar 12, 2024 at 3:32 PM Santiago Vila  wrote:
> This is a violation of a *must* directive in Policy, because
> Debian policy says this:
>
> If build-time dependencies are specified, it must be possible to build the 
> package and produce working binaries on a system with only essential and 
> build-essential packages installed and also those required to satisfy the 
> build-time relationships (including any implied relationships).

I disagree with your interpretation of Debian Policy. It is clearly
possible to build gcr and gcr4 on a system with only essential and
build-essential installed. See
https://buildd.debian.org/status/package.php?p=gcr4

Debian Policy does not say that it is a severity: serious bug because
you are unable to compile gcr4 on your particular AWS instance. I
understand that this bug appears serious to you. I also agree that
there is a real bug in gcr. Perhaps the bug is a race condition.
Fixing the issue that causes gcr build tests to fail 100% in your test
case may also fix the flakiness issue seen on the official buildds.

One problem with your insistence on declaring this bug serious was
that it put epiphany-browser on the auto-removal list. It was not that
critical. (That issue is obsolete since key packages are now using
gcr4.)

Unfortunately, the Debian GNOME team is too small for the amount of
work to be done and the number of open bugs. This bug is not so severe
that it requires my immediate attention compared to everything else
nor is it easy enough that I can fix it in a few minutes. Instead of
complaining about the severity the maintainer has assigned to the bug,
I guess you could try fixing it?

Thank you,
Jeremy Bícha

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Carlos Henrique Lima Melara]

Source: weston
Version: 10.0.1-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: carlos.mel...@toradex.com

Dear Maintainers, hi.

First of all, thanks for maintaining weston in Debian.

Weston 10 is using the default build options set by upstream plus
screenshare and systemd features enabled via a debian/rules override of
dh_auto_configure. This basically covers the major cases for PCs and
servers, but for embedded systems and people not wanting to use systemd
(and logind), this is a problem.

Weston has support for using libseat for seat management/launching
weston via the launcher-libseat option (it's turned off by default in
meson_options.txt), but weston 11 libseat launcher became the default [1]
and recently (weston 12) the libseat launcher has become the one and
only official launcher supported by upstream weston [2].

Taking this into consideration and the outcome of Init systems and
systemd GR [3], I'd like to check with you the possibility of enabling the
support for libseat launcher in stable via a proposed-updates upload to
bookworm.

I did rebuild bookworm's version with the option enabled and tested it a
bit in my notebook. I've also used abi-compliance-checker to check if
this could have caused any ABI change in libweston and it didn't. I'll
provide the debdiff output for you to check.

Also, should you answer positively, I can do a more exhaustive testing
and check if we don't introduce any errors when running with elogind and
systemd-logind.

Cheers,
Charles

[1] 
https://www.collabora.com/news-and-blog/news-and-events/weston-11-whats-new-whats-next.html
[2] 
https://www.collabora.com/news-and-blog/news-and-events/weston-12-highlights-and-changes.html
[3] https://www.debian.org/vote/2019/vote_002

P.S. I don't think this system info is going to help since I've built in
bookworm chroot.

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

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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
diff -u weston-10.0.1/debian/changelog weston-10.0.1/debian/changelog
--- weston-10.0.1/debian/changelog
+++ weston-10.0.1/debian/changelog
@@ -1,3 +1,11 @@
+weston (10.0.1-1+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * debian/control: add libseat-dev to Build-Depends.
+  * debian/rules: enable libseat support. (Closes: #)
+
+ -- Carlos Henrique Lima Melara   Tue, 12 Mar 2024 
12:54:10 -0300
+
 weston (10.0.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -u weston-10.0.1/debian/control weston-10.0.1/debian/control
--- weston-10.0.1/debian/control
+++ weston-10.0.1/debian/control
@@ -26,6 +26,7 @@
libpixman-1-dev (>= 0.25.2),
libpipewire-0.3-dev,
libpng-dev,
+   libseat-dev,
libsystemd-dev,
libudev-dev (>= 136),
libva-dev,
diff -u weston-10.0.1/debian/rules weston-10.0.1/debian/rules
--- weston-10.0.1/debian/rules
+++ weston-10.0.1/debian/rules
@@ -2,7 +2,8 @@
 
 override_dh_auto_configure:
dh_auto_configure -- -Dscreenshare=true \
-   -Dsystemd=true
+   -Dsystemd=true \
+   -Dlauncher-libseat=true
 
 override_dh_auto_test:
mkdir -p $(CURDIR)/debian/tmp/tmp/xdgruntimedir

Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)

[Santiago Vila]

El 3/3/24 a las 17:38, Jeremy Bícha escribió:

Control: severity -1 important
Control: affects -1 src:gcr

On Fri, Mar 1, 2024 at 6:36 AM Santiago Vila  wrote:

Ignore build test failures on s390x (Closes: #1057562)


This is wrong for several reasons.

- The bug report did not say anything about s390x.


s390x is the only architecture where the flakiness of the gcr:gck /
object build test is severe enough to unreasonably interfere with
timely building of gcr & gcr4.


You keep misrepresenting the bug I reported.

The bug report was not about a flaky test in a generic sense.

And it was not about the effect of such flaky test in the official buildds 
either.

What the bug report said is that whenever I try to build the package
on several virtual machines from AWS of different types, the build fails.

ALWAYS.

So, this is not about an occasional failure. This is about a permanent failure.

Here is my build history:

Status: failed  gcr4_4.1.0-2_amd64-20230322T215308.971Z
Status: failed  gcr4_4.1.0-2_amd64-20230322T215447.211Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202053.367Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202058.856Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202121.876Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202342.316Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202518.944Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202604.013Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202834.489Z
Status: failed  gcr4_4.1.0-2_amd64-20230922T202921.776Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T214526.762Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T215238.884Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T215413.813Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T215359.115Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T215627.137Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T215937.574Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T221515.395Z
Status: failed  gcr4_4.1.0-2_amd64-20230930T221739.810Z
Status: failed  gcr4_4.1.0-2_amd64-20231130T041100.202Z
Status: failed  gcr4_4.1.0-2_amd64-20231205T160411.736Z
Status: failed  gcr4_4.1.0-2_amd64-20231213T155044.129Z
Status: failed  gcr4_4.1.0-2_amd64-20231213T160911.601Z
Status: failed  gcr4_4.1.0-2_amd64-20240129T170626.580Z
Status: failed  gcr4_4.1.0-2_amd64-20240129T170930.627Z
Status: failed  gcr4_4.1.0-2_amd64-20240129T171059.244Z
Status: failed  gcr4_4.1.0-2_amd64-20240129T171811.347Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110606.957Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110607.721Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110608.780Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110608.127Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110609.765Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110718.547Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110719.934Z
Status: failed  gcr4_4.2.0-3_amd64-20240301T110721.878Z

This is a violation of a *must* directive in Policy, because
Debian policy says this:

If build-time dependencies are specified, it must be possible to build the 
package and produce working binaries on a system with only essential and 
build-essential packages installed and also those required to satisfy the 
build-time relationships (including any implied relationships).


Debian is full of packages where the build tests and autopkgtests are
flaky enough to be disruptive to someone expecting 100% pass rates.


This is a strawman. I'm *not* expecting a 100% pass rate.

A pass rate of 100% would correspond to a failure rate of 0%.

I do not expect a failure rate of 0%.

I just expect a failure rate which is *not* 100%.


There is currently no one on the Debian GNOME team with the time to
investigate and properly fix these issues.


In such case the failing test is completely useless and even harmful.

When we have unit tests, they are enabled with the aim of
"doing something" when they fail. If we do nothing when they
fail, we are wasting the time of everybody involved.


The occasional failure is enough to remind us of this issue.


If this is really about "reminding", I can put a cron job to
email you a reminder weekly or monthly. Even a postit note in your
monitor would be better than this.

But not this.


I don't
think it's helpful to just disable the test since it may disguise a
real problem that someone can work on once they get sufficiently
annoyed by the issue.


Well, but this is *already* a real problem: The package does not
build in some systems. Not an occasional failure, but not at all.


Also, it may be important to recognize if the
failure rate for this test on official buildds increases
significantly. The failure rate did increase on s390x but we don't
really treat s390x as a supported Desktop architecture and don't have
capacity to spend much time dealing with s390x.


And you keep mentioning s390x when the original bug report did not
mention s390x at all.

In fact, 

Bug#1059808: [Debian-ha-maintainers] Bug#1059808: ocfs2-tools: isolation-machine autopkgtest fails: Internal logic failure while mounting /dev/loop0 on /mnt

[Valentin Vidic]

On Mon, Jan 01, 2024 at 07:57:38PM +0100, Paul Gevers wrote:
>  47s === mount ===
>  47s mount.ocfs2: Internal logic failure while mounting /dev/loop0 on /mnt.
> Check 'dmesg' for more information on this error 22.
>  47s umount: /mnt: not mounted.

Thanks for the report, I'm seeing the same problem on a local KVM
instance. The test still works with older kernel versions and show be
fixed for new kernels once they have these two patches:

Alexander Aring [PATCH 1/2] dlm: fix user space lkb refcounting
Alexander Aring [PATCH 2/2] dlm: fix off-by-one waiters refcount handling  

-- 
Valentin

Bug#1066111: libssh2: mark openssh-server with

[Sebastian Ramacher]

Source: libssh2
Version: 1.11.0-4
Severity: wishlist
X-Debbugs-Cc: sramac...@debian.org

libssh2 is build depending on openssh-server for its tests. To help with
bootstrapping, it would be helpful to mark the dependency with
 so that a build without running the testsuite can help with
rebootstrapping armel and armhf for the time_t transition.

Cheers
-- 
Sebastian Ramacher

Bug#1066110: tracker-extract: regular crash

[Patrice Duroux]

Package: tracker-extract
Version: 3.7~rc-3
Severity: minor

Dear Maintainer,

Don't know if:

1. it is a duplicate to #1064196 but seems not,
2. due to the ongoing t_time transition,
3. somehow involve also a trouble in libfontconfig,

but here is a coredumpctl output:

   PID: 33307 (tracker-extract)
   UID: 1001 (patrice)
   GID: 1001 (patrice)
Signal: 31 (SYS)
 Timestamp: Tue 2024-03-12 19:29:44 CET (8min ago)
  Command Line: /usr/libexec/tracker-extract-3 --socket-fd 3
Executable: /usr/libexec/tracker-extract-3
 Control Group:
/user.slice/user-1001.slice/user@1001.service/background.slice/tracker-miner-
fs-3.service
  Unit: user@1001.service
 User Unit: tracker-miner-fs-3.service
 Slice: user-1001.slice
 Owner UID: 1001 (patrice)
   Boot ID: d3355804fb3a455cb193c8c5c0ddd63b
Machine ID: be351e757dc049ffa300ddbaf0f4856a
  Hostname: kos-moceratops
   Storage: /var/lib/systemd/coredump/core.tracker-
extract.1001.d3355804fb3a455cb193c8c5c0ddd63b.33307.171026818400.zst
(present)
  Size on Disk: 15.4M
   Message: Process 33307 (tracker-extract) of user 1001 dumped core.

Module libsystemd.so.0 from deb systemd-255.4-1+b1.amd64
Module libudev.so.1 from deb systemd-255.4-1+b1.amd64
Module libarchive.so.13 from deb libarchive-3.7.2-1.1.amd64
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Stack trace of thread 33311:
#0  0x7ff0c8c0c207 __tgkill (libc.so.6 + 0x10a207)
#1  0x7ff0c8b3e510 __restore_rt (libc.so.6 + 0x3c510)
#2  0x7ff0c8bf95a7 __GI___chmod (libc.so.6 + 0xf75a7)
#3  0x7ff0c54f1d68 n/a (libfontconfig.so.1 + 0xbd68)
#4  0x7ff0c54fc00b n/a (libfontconfig.so.1 + 0x1600b)
#5  0x7ff0c54fc283 FcDirCacheRead (libfontconfig.so.1 +
0x16283)
#6  0x7ff0c54f67f1 n/a (libfontconfig.so.1 + 0x107f1)
#7  0x7ff0c54f68c4 FcConfigBuildFonts (libfontconfig.so.1 +
0x108c4)
#8  0x7ff0c5502d8c FcInitLoadConfigAndFonts
(libfontconfig.so.1 + 0x1cd8c)
#9  0x7ff0c54f2f26 n/a (libfontconfig.so.1 + 0xcf26)
#10 0x7ff0c54f2f8d n/a (libfontconfig.so.1 + 0xcf8d)
#11 0x7ff0bc39e415 n/a (libpangoft2-1.0.so.0 + 0xc415)
#12 0x7ff0c9161ab1 n/a (libglib-2.0.so.0 + 0x87ab1)
#13 0x7ff0c8b8a45c start_thread (libc.so.6 + 0x8845c)
#14 0x7ff0c8c0abbc __clone3 (libc.so.6 + 0x108bbc)

Stack trace of thread 33307:
#0  0x7ff0c8b54810 __GI___isoc99_sscanf (libc.so.6 +
0x52810)
#1  0x7ff0be501002 n/a (libgstreamer-1.0.so.0 + 0xe7002)
#2  0x7ff0be4ffd3c n/a (libgstreamer-1.0.so.0 + 0xe5d3c)
#3  0x7ff0be50015b n/a (libgstreamer-1.0.so.0 + 0xe615b)
#4  0x7ff0be4d5d2e n/a (libgstreamer-1.0.so.0 + 0xbbd2e)
#5  0x7ff0be474623 gst_caps_from_string
(libgstreamer-1.0.so.0 + 0x5a623)
#6  0x7ff0a32604a6 n/a (libgstvideosignal.so + 0x14a6)
#7  0x7ff0c8ec33be g_type_class_ref (libgobject-2.0.so.0 +
0x373be)
#8  0x7ff0be48af12 gst_element_register
(libgstreamer-1.0.so.0 + 0x70f12)
#9  0x7ff0a3260352 n/a (libgstvideosignal.so + 0x1352)
#10 0x7ff0be4b7212 n/a (libgstreamer-1.0.so.0 + 0x9d212)
#11 0x7ff0be4b95ed n/a (libgstreamer-1.0.so.0 + 0x9f5ed)
#12 0x7ff0be4c592d n/a (libgstreamer-1.0.so.0 + 0xab92d)
#13 0x7ff0be4c69ef n/a (libgstreamer-1.0.so.0 + 0xac9ef)
#14 0x7ff0be4c6d6e n/a (libgstreamer-1.0.so.0 + 0xacd6e)
#15 0x7ff0be4c8f26 gst_update_registry
(libgstreamer-1.0.so.0 + 0xaef26)
#16 0x7ff0be456e4a n/a (libgstreamer-1.0.so.0 + 0x3ce4a)
#17 0x7ff0be456f95 n/a (libgstreamer-1.0.so.0 + 0x3cf95)
#18 0x7ff0c9143e99 g_option_context_parse (libglib-2.0.so.0
+ 0x69e99)
#19 0x7ff0be457937 gst_init_check (libgstreamer-1.0.so.0 +
0x3d937)
#20 0x7ff0be4579c8 gst_init (libgstreamer-1.0.so.0 +
0x3d9c8)
#21 0x7ff0beb0f8d2 tracker_extract_module_init (libextract-
gstreamer.so + 0x98d2)
#22 0x7ff0c9228abc n/a (libtracker-extract.so + 0x8abc)
#23 0x7ff0c92296c0 tracker_module_manager_load_modules
(libtracker-extract.so + 0x96c0)
#24 0x55e8434d2be8 main (tracker-extract-3 + 0xbbe8)
#25 0x7ff0c8b296ca __libc_start_call_main (libc.so.6 +
0x276ca)
#26 0x7ff0c8b29785 __libc_start_main_impl (libc.so.6 +
0x27785)
#27 0x55e8434d2fd1 _start 

Bug#1066100: Acknowledgement (freeciv: new cities unmanageable in a long game)

[Marko Lindqvist]

On Tue, 12 Mar 2024 at 18:42, Giacomo Mulas  wrote:

> Please find attached a saved game on which the bug can be seen.
> Just load the saved game with freeciv and look for the cities of
> Oberhausen or Bischweiler, and try e.g. to change the production in any of
> them, it will not be possible (or at least it is impossible here!).
>
> Bye, thanks in advance
> Giacomo
>

 Reproduced in upstream 3.1 branch, and opened a ticket about other, but
likely related, error messages I saw in the process:
https://redmine.freeciv.org/issues/304


 - ML

Bug#1066055: re: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic

[Mike Gerow]

On Tue, 12 Mar 2024 17:55:42 + Peter Green  wrote:
> 2. Is it worth expending effort on getting symphonia available on
> i386? to me that depends on what software is using or planning
> to use it. For a port in it's twilight years, keeping existing
> software working seems more important than making new software
> available.
Speaking as a user, if this package simply doesn't support i386 I'd be
ok with that outcome.

The main reason I noticed this is because I work on a project that
does clean internal rebuilds of Debian packages, and if this packages
simply shouldn't support i386 any more that resolves it from my
perspective.

Bug#1066109: sudo: pam-script env variables not populated because of sudo change

[Andy Roulin]

Package: sudo
Version: 1.9.13p3-1+deb12u1
Severity: important
Tags: patch
X-Debbugs-Cc: arou...@nvidia.com

Dear Maintainer,

>From sudo version 1.9.4 to version 1.9.14, there is a bug breaking pam-script
environment variables: https://github.com/sudo-project/sudo/issues/318

Because of this bug, pam-script called through a sudo command are not getting
called with the necessary filled PAM_* environment variables for the pam scripts
to perform their checks.

For example, if the command executed is "sudo ls", then a pam-script should get
the PAM_SERVICE populated to be "sudo". That is not the case with debian 12
sudo package where PAM_SERVICE, in this sudo scenario, is simply empty.

Would it be possible to backport the upstream fix or update sudo to 1.9.15 in
the Debian 12 repositories? We are experiencing the same issue described in
the Github link.

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

Kernel: Linux 6.1.0-cl-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sudo depends on:
ii  init-system-helpers  1.65.2
ii  libaudit11:3.0.9-1
ii  libc62.36-9+deb12u4
ii  libpam-modules   1.5.2-6+deb12u1
ii  libpam0g 1.5.2-6+deb12u1
ii  libselinux1  3.4-1+b6
ii  zlib1g   1:1.2.13.dfsg-1

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission denied: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README'

-- no debconf information

Bug#1036884: transition: time64_t

[Fabian Grünbichler]

On Tue, Mar 12, 2024 at 05:55:59PM +0100, Emanuele Rocca wrote:
> [ debian-rust added to CC ]
> 
> Hi,
> 
> On 2024-03-12 11:03, Simon McVittie wrote:
> > In the medium term, cargo needs re-bootstrapping on the affected
> > architectures (armel and armhf, plus a bunch of -ports architectures
> > where as far as I can see cargo was never available in the past) -
> > that's #1065787, and Steve already replied to that bug describing how
> > Ubuntu did this.
> 
> I don't think Ubuntu actually fixed cargo yet, at least if the data in
> UDD is reliable -- and if I'm looking in the right place. :-)
>
> udd=> select source,version,date from ubuntu_upload_history where 
> source='cargo' order by date desc limit 2;
>  source |  version   |  date  
> ++
>  cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2 | 2023-07-05 09:36:28+00
>  cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.22.04.2 | 2023-07-05 09:36:27+00
> (2 rows)
> 
> Maybe when Steve mentioned the work done in Ubuntu on
> https://bugs.debian.org/1065787#22 he meant other packages?

possibly the "Ubuntu did this" was referring to post-cargo/rustc-merge?

we've planned that as well, and it's about 75% prepared, but I didn't
manage to finish in Debian in time for t64 to kick off so I held off
finalizing it until the dust settles. in hindsight, that might have been
a mistake - src:rustc (the target of the source package merge) comes
with builtin (re)bootstrap support from upstream statically linked
stage0 ;)

> > Is there a porter who can take responsibility for that?
> 
> I did manage to get cargo to build in a armhf chroot by manually
> installing the various deps, see the build artifacts at
> https://people.debian.org/~ema/cargo/. I can work on armel next. The
> tests are green but maybe there's some more meaningful validation we can
> do before uploading? Anyone from debian-rust has ideas or comments?

if the tests are green, you could try a rebuild of rustc and/or cargo
with the built cargo next? I don't think anything else that is packaged
exercises anywhere near that amount of the functionality of cargo ;)

thanks for taking care of this! don't hesitate to holler here or in
#debian-rust/dev/release (ping me for the latter two, I don't read the
full backlog there).

Fabian

Bug#1066055: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic

[Peter Green]

rust-symphonia-core appears to FTBFS from an i386 sbuild chroot with a
test 'units::tests::verify_timebase' panicking

 units::tests::verify_timebase stdout 
thread 'units::tests::verify_timebase' panicked at 'assertion failed:  
`(left == right)`

   left: `4503599627370496`,
  right: `4503599627370497`', src/units.rs:257:9


The code in question is.

>assert_eq!(
>tb1.calc_timestamp(Time::new(14_073_748_835_532, 0.803125)),
>0x10___0001
>);

Given the appearance of a floating point number in the test, this is
almost certainly caused by a difference in floating point rounding
behaviour on x87 (which is used by the Debian i386 port) compared
to modern FPUs.

On modern FPUs, values are rounded to their "storage format" after
every operation. On x87 this is not the case, floating point
values have more precision when stored in registers than when
stored in memory. Usually this just results in calculations
being slightly more accurate than they would be on a modern
FPU, but it can become a problem if repeatability is more
important than accuracy, or if algorithms are carefully designed
to take account of rounding and then the rounding they expect
does not happen.

The questions this leaves are as follows.

1. Does this (and any other similar test failures) represent a
   significant behavioural difference that would render symphonia
   unwise to use on Debian i386? or does it just represent an
   overzealous test? This is something that should ideally be
   discussed with upstream, though I don't know if their response
   will be positive.
2. Is it worth expending effort on getting symphonia available on
   i386? to me that depends on what software is using or planning
   to use it. For a port in it's twilight years, keeping existing
   software working seems more important than making new software
   available.

Bug#1065767: libopendbx: FTBFS on arm{el,hf}: mssql_basic.c:324:21: error: implicit declaration of function ‘dbpoll’ [-Werror=implicit-function-declaration]

[Andrey Rakhmatullin]

On Sat, Mar 09, 2024 at 09:26:38PM +0100, Sebastian Ramacher wrote:
> mssql_basic.c: In function ‘mssql_odbx_result’:
> mssql_basic.c:324:21: error: implicit declaration of function ‘dbpoll’ 
> [-Werror=implicit-function-declaration]
>   324 | if( dbpoll( dbproc, ms, ,  ) == FAIL ) 
> { return -ODBX_ERR_BACKEND; }
>   | ^~
dbpoll() is unimplemented: 
https://github.com/FreeTDS/freetds/blob/4a6356010ef1e841bcdf3d26f8bbacbf2262d525/src/dblib/dblib.c#L7211
Thus its prototype is only available under #ifdef DBLIB_UNIMPLEMENTED,
whatever semantics does that have (I couldn't find docs for that).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1065759: Retitle libbio-samtools-perl: FTBFS on arm{el,hf}: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-fun

[Andreas Tille]

Control: retitle -1 libbio-samtools-perl: FTBFS: lib/Bio/DB/Sam.xs:324:4: 
error: implicit declaration of function ‘bam_sort_core’; did you mean 
‘bam_format1_core’? [-Werror=implicit-function-declaration]
Control: tags -1 help
thanks

I can confirm that this bug also occures on amd64 thus removing the
arm-restriction from the title.  Unfortunately I have no idea how to fix
this (except by possibly suppressing the -Werror=implicit-function-declaration
option).  Thus tagging 'help'

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1066108: intel-microcode: CVE-2023-43490 CVE-2023-39368 CVE-2023-38575 CVE-2023-22655 CVE-2023-28746

[Salvatore Bonaccorso]

Source: intel-microcode
Version: 3.20231114.1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20231114.1~deb12u1
Control: found -1 3.20231114.1~deb11u1

Hi,

The following vulnerabilities were published for intel-microcode.

CVE-2023-43490[0], CVE-2023-39368[1], CVE-2023-38575[2],
CVE-2023-22655[3] and CVE-2023-28746[4].


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-43490
https://www.cve.org/CVERecord?id=CVE-2023-43490

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01045.html
[1] https://security-tracker.debian.org/tracker/CVE-2023-39368
https://www.cve.org/CVERecord?id=CVE-2023-39368

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00972.html
[2] https://security-tracker.debian.org/tracker/CVE-2023-38575
https://www.cve.org/CVERecord?id=CVE-2023-38575

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00982.html
[3] https://security-tracker.debian.org/tracker/CVE-2023-22655
https://www.cve.org/CVERecord?id=CVE-2023-22655

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00960.html
[4] https://security-tracker.debian.org/tracker/CVE-2023-28746
https://www.cve.org/CVERecord?id=CVE-2023-28746

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00898.html

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html

I think we should do a classical top-down approach here, let it first
go through unstable. We can decide if we want to postpone it trough
the point release afterwards or go via a point release.

Regards,
Salvatore

Bug#1066102: icingaweb2-module-nagvis: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-nagvis
Version: 1.1.1-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-nagvis
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

Bug#1065806: pam: recent upgrade changes previous default umask

[Antoine Le Gonidec]

The change of behaviour can have an unexpected and quite nasty
side-effect, by applying a misconfiguration that was ignored until this
update.

A setting of "UMASK 077" in /etc/login.defs was ignored before this
update, and is now applied (as it should) leading to unreadable files
if the user is not expecting it.

In my case this was a misconfiguration, as I thought it was a setting
applied only to the $HOME directory itself (I should have used
"HOME_MODE 0700" instead). But since it had no effect until the recent
update, I got taken by surprise with files generated with rw-rw
permissions when I was expecting the regular rw-r--r--.

I am not bumping the severity of this bug report because the new
behaviour is the correct one, but it should be kept in mind that other
people might get unexpected effects from this update.

Bug#1065611: Additional support for SolidRun HoneyComb

[Diederik de Haas]

Hi Josua,

On Tuesday, 12 March 2024 16:28:06 CET Josua Mayer wrote:
> I believe I found the answer:
> EDAC_MPC85XX is for power-pc only,
> EDAC_LAYERSCAPE is for arm (see drivers/edac/layerscape_edac.c).

You're right. In the commit I referenced earlier (ea2eb9a8b6207ee4),
I misinterpreted the commit message.
That commit also created ``drivers/edac/fsl_ddr_edac.c`` which got the arch 
independent (or at least dual arch) parts. Its header has this:
```
 * Support Power-based SoCs including MPC85xx, MPC86xx, MPC83xx and
 * ARM-based Layerscape SoCs including LS2xxx. Originally split
 * out from mpc85xx_edac EDAC driver.
```

> Am 12.03.24 um 16:13 schrieb Josua Mayer:
> >
> > Thank you for taking care of this!
> > First the additional changes you found seem reasonable.

Excellent, then I'll make a MR for them (except EDAC_MPC85XX):
- drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and
   SENSORS_LTC2978 as modules
- drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module
- drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module
- drivers/soc/fsl: Enable FSL_RCPM

> > Regarding edac - I checked NXPs reference BSP for LX2160,
> > and their linux fork has the same status, driver can not be enabled on
> > arm64.
> > However I also agree it should be enabled if it were possible.
> > The driver appears to setup ecc bit error interrupts so that hey can be
> > reported by Linux.
> > ...
> > I may have access to an lx2160a system with ecc memory within the coming
> > week, so I could test (on vendor kernel based on 5.10 only) whether any
> > problems show up. If not, perhaps a patch to the kernel is advisable.

As EDAC_LAYERSCAPE got enabled in 5.5.17-1 via bug 948576 (with a patch from 
you), ECC support should already work with the Stable 6.1 kernel (or newer).

> > Am 07.03.24 um 13:34 schrieb Diederik de Haas:
> >> On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote:
> >> 
> >>> LX2160 SoC early silicon revisions have a pci-e generation 4
> >>> controller.
> >>> It requires a different driver from newer gen-3 silicon.
> >>>
> >>> This affects the SolidRun Honeycomb Workstation which
> >>> is otherwise fully supported in Debian.
> >> 
> >> I cloned bug report #1061116 into #1065611 to discuss some additional
> >> support for the SolidRun HoneyComb.
> >>
> >> I analyzed the HoneyComb dts file and the following included .dtsi
> >> files:
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi

If my MR gets merged, then there's truly full support in Debian :)

Cheers,
  Diederik

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

Bug#1063376: Create bugs against ftp.debian.org to enable removal of 32bit architectures for all r-bioc-rhtslib rdepends

[Andreas Tille]

clone 1063379 -1
block 1063376 by -1
retitle -1 RM: r-bioc-ballgown [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -1 + src:r-bioc-ballgown

clone 1063379 -2
block 1063376 by -2
retitle -2 RM: r-bioc-cner [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -2 + src:r-bioc-cner

clone 1063379 -3
block 1063376 by -3
retitle -3 RM: r-bioc-biovizbase [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -3 + src:r-bioc-biovizbase

clone 1063379 -4
block 1063376 by -4
retitle -4 RM: r-bioc-bsseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -4 + src:r-bioc-bsseq

clone 1063379 -5
block 1063376 by -5
retitle -5 RM: r-bioc-cummerbund [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -5 + src:r-bioc-cummerbund

clone 1063379 -6
block 1063376 by -6
retitle -6 RM: r-bioc-dada2 [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -6 + src:r-bioc-dada2

clone 1063379 -7
block 1063376 by -7
retitle -7 RM: r-bioc-dss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -7 + src:r-bioc-dss

clone 1063379 -8
block 1063376 by -8
retitle -8 RM: r-bioc-dexseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -8 + src:r-bioc-dexseq

clone 1063379 -9
block 1063376 by -9
retitle -9 RM: r-bioc-degnorm [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -9 + src:r-bioc-degnorm

clone 1063379 -10
block 1063376 by -10
retitle -10 RM: r-bioc-demixt [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -10 + src:r-bioc-demixt

clone 1063379 -11
block 1063376 by -11
retitle -11 RM: r-bioc-genomicfiles [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -11 + src:r-bioc-genomicfiles

clone 1063379 -12
block 1063376 by -12
retitle -12 RM: r-bioc-genelendatabase [armel armhf i386 hppa m68k powerpc sh4] 
-- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -12 + src:r-bioc-genelendatabase

clone 1063379 -13
block 1063376 by -13
retitle -13 RM: r-bioc-goseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -13 + src:r-bioc-goseq

clone 1063379 -14
block 1063376 by -14
retitle -14 RM: r-bioc-genomicfeatures [armel armhf i386 hppa m68k powerpc sh4] 
-- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -14 + src:r-bioc-genomicfeatures

clone 1063379 -15
block 1063376 by -15
retitle -15 RM: r-bioc-edaseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -15 + src:r-bioc-edaseq

clone 1063379 -16
block 1063376 by -16
retitle -16 RM: r-bioc-genomicalignments [armel armhf i386 hppa m68k powerpc 
sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -16 + src:r-bioc-genomicalignments

clone 1063379 -17
block 1063376 by -17
retitle -17 RM: r-bioc-ioniser [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -17 + src:r-bioc-ioniser

clone 1063379 -18
block 1063376 by -18
retitle -18 RM: r-bioc-grohmm [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -18 + src:r-bioc-grohmm

clone 1063379 -19
block 1063376 by -19
retitle -19 RM: r-bioc-isoformswitchanalyzer [armel armhf i386 hppa m68k 
powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures 
any more
affects -19 + src:r-bioc-isoformswitchanalyzer

clone 1063379 -20
block 1063376 by -20
retitle -20 RM: r-bioc-gviz [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 
r-bioc-rhtslib does not support of 32 bit architectures any more
affects -20 + src:r-bioc-gviz

clone 1063379 -21
block 1063376 by -21
retitle -21 RM: r-bioc-organismdbi [armel armhf i386 hppa m68k powerpc sh4] -- 
ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -21 + src:r-bioc-organismdbi

clone 1063379 -22
block 1063376 by -22
retitle -22 RM: r-bioc-mutationalpatterns [armel armhf i386 hppa m68k powerpc 
sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
affects -22 + src:r-bioc-mutationalpatterns

clone 1063379 -23
block 1063376 by -23
retitle -23 RM: r-bioc-rgsepd [armel armhf i386 hppa m68k powerpc sh4] -- ROM; 

Bug#1066107: icingaweb2-module-pnp: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-pnp
Version: 1.1.0-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for icingaweb2-module-pnp
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

icingaweb2-module-pnp_1.1.0-4_templates.pot.bz2
Description: application/bzip

Bug#1066106: icingaweb2-module-nagvis: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-nagvis
Version: 1.1.1-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-nagvis
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers


icingaweb2-module-nagvis_1.1.1-4_templates.pot.bz2
Description: application/bzip

Bug#1066105: icingaweb2-module-cube: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-cube
Version: 1.3.2-1
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-cube
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers


icingaweb2-module-cube_1.3.2-1_templates.pot.bz2
Description: application/bzip

Bug#1066104: icingaweb2-module-graphite: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-graphite

Version: 1.2.2-3

Severity: wishlist

Tags: patch l10n



Please find the updated German po file translation for
icingaweb2-module-graphite

attached.



If you update your template, please use

'msgfmt --statistics '

to check the po-files for fuzzy or untranslated strings.



If there are such strings, please contact me so I can update the

German translation.



Yours

Hermann-Josef Beckers





icingaweb2-module-graphite_1.2.2-3_templates.pot.bz2
Description: application/bzip

Bug#1066103: icingaweb2-module-cube: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-cube
Version: 1.3.2-1
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-cube
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

Bug#1036884: transition: time64_t

[Emanuele Rocca]

[ debian-rust added to CC ]

Hi,

On 2024-03-12 11:03, Simon McVittie wrote:
> In the medium term, cargo needs re-bootstrapping on the affected
> architectures (armel and armhf, plus a bunch of -ports architectures
> where as far as I can see cargo was never available in the past) -
> that's #1065787, and Steve already replied to that bug describing how
> Ubuntu did this.

I don't think Ubuntu actually fixed cargo yet, at least if the data in
UDD is reliable -- and if I'm looking in the right place. :-)

udd=> select source,version,date from ubuntu_upload_history where 
source='cargo' order by date desc limit 2;
 source |  version   |  date  
++
 cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2 | 2023-07-05 09:36:28+00
 cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.22.04.2 | 2023-07-05 09:36:27+00
(2 rows)

Maybe when Steve mentioned the work done in Ubuntu on
https://bugs.debian.org/1065787#22 he meant other packages?

> Is there a porter who can take responsibility for that?

I did manage to get cargo to build in a armhf chroot by manually
installing the various deps, see the build artifacts at
https://people.debian.org/~ema/cargo/. I can work on armel next. The
tests are green but maybe there's some more meaningful validation we can
do before uploading? Anyone from debian-rust has ideas or comments?

Bug#1066101: icingaweb2-module-pnp: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-pnp
Version: 1.1.0-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for icingaweb2-module-pnp
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)

[Paride Legovini]

On 2024-03-12 00:33, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> On Wed, 6 Mar 2024 11:04:01 +0100 Paride Legovini  wrote:
>> On Sun, 03 Mar 2024 16:26:41 +0100 Benjamin Drung  wrote:
>>> Time to join this discussion. The current default was the preference of
>>> the author 14 years ago. My taste has change a bit since then. I am open
>>> to change the default. --trailing-comma for wrapped lines is a good
>>> idea, --short-indent is okay. I don't like --wrap-always in case there
>>> are only two or three entries.
>>>
>>> The new default should not only based on the preference, but also on
>>> what is used the most. Can someone collect the information: which teams
>>> use which options, how many packages use what?
>>
>> I did some unscientific research on codesearch looking for d/changelog 
>> entries
>> mentioning `wrap-and-sort -` (i.e. wrap-and-sort with some options). This is
>> the query:
>>
>> https://codesearch.debian.net/search?q=path%3Adebian%2Fchangelog+wrap-and-sort+-=1
>>
>> Apparently -a is the single most used option, very often used together with
>> -s and -t. I found similar results by searching GitHub:
>>
>> https://github.com/search?q=path%3Adebian%2Fchangelog+%22wrap-and-sort+-%22=code
>>
>> Looks like salsa (GitLab Free) doesn't allow to do instance-wide code 
>> searches.
> 
> I disagree that the new default should be what is used the most. For example
> debhelper versions do not become the default only after they are used the 
> most.
> The thing that makes switching defaults easier for debhelper is the explicit
> opt-in for a new debhelper compat version which we don't have for 
> wrap-and-sort
> and I think it would very much be over-engineering to add such a feature for
> something that is, in my opinion, of very little consequence. Furthermore, I
> would not be surprised if many people using wrap-and-sort use the default
> expecting that this is what is most well-liked by the project (because why 
> else
> would it be the default?). The question was asked in this email sub-thread:
> 
> https://lists.debian.org/161289428547.4135738.4002254931040787...@auryn.jones.dk
> 
> In that thread, same as in this bug, -ast was proposed as the default and
> unless I missed something, there were no objections on debian-devel. Some even
> argued, to make -b the default as well. So instead of asking "what is used
> most" I'd like to ask, are there users of wrap-and-sort without -ast who would
> be strongly against having to pass -AST to overwrite a potential new default?
> 
> That being said, I downloaded all debian/control files for all 36832 source
> packages in Debian and ran the following shell script on them to figure out 
> how
> many source packages comply with which wrap-and-sort set of options:
> 
> for p in control/*; do
>   rm -f debian/control;
>   ln -s "../$p" debian/control;
>   for opt in "" -a -as -ast -astb -at -atb -ab -s -st -stb -sb -t -tb -b; 
> do
>   wrap-and-sort --dry-run --file=debian/control $opt \
>   | grep --quiet debian/control \
>   || echo $p >> w-a-s$opt;
>   done
> done
> 
> It's of course still not possible to say whether a control file adheres to a
> certain wrap-and-sort formatting style by accident or intentionally. Also,
> packages can easily fall in multiple categories at the same time, for example
> packages with only a single binary package which comply with -ast will
> automatically also comply with -astb. There are also packages which comply 
> with
> -ast as well as with no options at all simply because they have no
> Build-Depends nor Depends fields in debian/control. Here is the result sorted
> by popularity in ascending order:
> 
> 96 wrap-and-sort -st
> 96 wrap-and-sort -stb
>434 wrap-and-sort -as
>465 wrap-and-sort -tb
>489 wrap-and-sort -t
>579 wrap-and-sort -atb
>641 wrap-and-sort -at
>   1341 wrap-and-sort -sb
>   1405 wrap-and-sort -s
>   2381 wrap-and-sort -astb
>   2705 wrap-and-sort -ast
>   2732 wrap-and-sort -b
>   3020 wrap-and-sort
>   3950 wrap-and-sort -ab
>   4089 wrap-and-sort -a
> 
> So, wrap-and-sort -ast is very popular but it is not as popular as the current
> default.

Hi josch and thanks for this analysis. I'll try to recap where we are at this
point, focusing only on -ast (I'll ignore -bk here).

1. This bug (#895570) requests -ast to be the default. The proposal received
mostly positive feedback, however bdrung doesn't like -a in case there are
only two or three entries. He also thinks we should consider what is already
popular.

--> Looks like everybody likes (or is ok with) having -st by default.

2. Using codesearch I looked for what options are the most popular when
w-a-s is mentioned with options in d/changelog. Looks like the most
popular option is -a (often together with others).

3. josch checked how many src packages in the archive are already compliant
with a w-a-s option set, and found results which agree with 

Bug#1065764: libstb: diff for NMU version 0.0~git20230129.5736b15+ds-1.2

[Andrey Rakhmatullin]

Control: tags 1065764 + patch
Control: tags 1065764 + pending

Dear maintainer,

I've prepared an NMU for libstb (versioned as 0.0~git20230129.5736b15+ds-1.2) 
and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru libstb-0.0~git20230129.5736b15+ds/debian/changelog libstb-0.0~git20230129.5736b15+ds/debian/changelog
--- libstb-0.0~git20230129.5736b15+ds/debian/changelog	2024-02-29 00:04:59.0 +0500
+++ libstb-0.0~git20230129.5736b15+ds/debian/changelog	2024-03-12 21:40:23.0 +0500
@@ -1,3 +1,10 @@
+libstb (0.0~git20230129.5736b15+ds-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1065764).
+
+ -- Andrey Rakhmatullin   Tue, 12 Mar 2024 21:40:23 +0500
+
 libstb (0.0~git20230129.5736b15+ds-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch
--- libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ libstb-0.0~git20230129.5736b15+ds/debian/patches/fix-implicit-function-declaration.patch	2024-03-12 21:40:23.0 +0500
@@ -0,0 +1,29 @@
+Description: Add missing header includes.
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1065764
+Last-Update: 2024-03-12
+Index: libstb-0.0~git20230129.5736b15+ds/stb_divide.h
+===
+--- libstb-0.0~git20230129.5736b15+ds.orig/stb_divide.h
 libstb-0.0~git20230129.5736b15+ds/stb_divide.h
+@@ -102,6 +102,8 @@ extern int stb_mod_eucl (int value_to_be
+ }
+ #endif
+ 
++#include 
++
+ #ifdef STB_DIVIDE_IMPLEMENTATION
+ 
+ #if defined(__STDC_VERSION) && __STDC_VERSION__ >= 19901
+Index: libstb-0.0~git20230129.5736b15+ds/stb_dxt.h
+===
+--- libstb-0.0~git20230129.5736b15+ds.orig/stb_dxt.h
 libstb-0.0~git20230129.5736b15+ds/stb_dxt.h
+@@ -83,6 +83,7 @@ STBDDEF void stb_compress_bc5_block(unsi
+ // #define STB_DXT_USE_ROUNDING_BIAS
+ 
+ #include 
++#include 
+ 
+ #if !defined(STBD_FABS)
+ #include 
diff -Nru libstb-0.0~git20230129.5736b15+ds/debian/patches/series libstb-0.0~git20230129.5736b15+ds/debian/patches/series
--- libstb-0.0~git20230129.5736b15+ds/debian/patches/series	2023-02-08 08:28:47.0 +0500
+++ libstb-0.0~git20230129.5736b15+ds/debian/patches/series	2024-03-12 21:40:23.0 +0500
@@ -6,3 +6,4 @@
 0006-tests-Makefile-refactor.patch
 0007-tests-image_test.c-use-library.patch
 0008-tests-image_write_test.c-use-library.patch
+fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec

[Richard Laager]

(Replying via mobile, so non-Debian address.)

It should be reasonably possible to convert this to .d style. I will have to 
dig into this to fully consider all the implications, especially around 
handling upgrades. I think part of the issue here is that ntpd logs there by 
default. That is, you don’t turn on logging. I’m not sure if there is a way to 
turn off logging. But I have to check.

I want to maintain the same posture we have now:

- No logs by default. Most people don’t use them, so this is pointless I/O.
- People can enable logs reasonably easily.
- Installing ntpviz automatically enables logs.

For upgrades, I can use the presence or absence of the directory for most of 
the handling. I do need to think through what happens / what to do if someone 
has customized any of the other log settings.

-- 
Richard

Bug#1059331: spip: XSS issue fixed in 4.1.13 upstream

[Santiago Ruano Rincón]

Control: fixed -1 3.2.11-3+deb11u10

https://tracker.debian.org/news/1500839/accepted-spip-3211-3deb11u10-source-into-oldstable-proposed-updates/

On Fri, 22 Dec 2023 16:57:40 +0100 Salvatore Bonaccorso  
wrote:
> Source: spip
> Version: 4.1.12+dfsg-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: fixed -1 4.1.13+dfsg-1
> Control: found -1 4.1.9+dfsg-1+deb12u2
> Control: found -1 3.2.11-3+deb11u9
> 
> Filling a bug for tracking (as otherwise beeing a unspecified TEMP
> entry), as the issue has no CVE: 4.1.13 fixes an issue:
> 
>* fix: les modèles insérés dans un texte héritent automatiquement du
>  contexte, a l'insu des redacteurs. Securiser ce qui proviendrait de
>  variables envoyées par l'utilisateur
> 
> https://tracker.debian.org/news/1488834/accepted-spip-4113dfsg-1-source-into-unstable/
> 
> Regards,
> Salvatore


signature.asc
Description: PGP signature

Bug#1066100: freeciv: new cities unmanageable in a long game

[Giacomo Mulas]

Package: freeciv
Version: 3.1.0+ds-1
Severity: normal

Dear Maintainer,

in a long game with a huge map, I hit a weird bug. 
New cities are unmanageable, i.e. I cannot:
- change their production
- set them as "home" for any unit
- add settlers to them
etc.

I will send a saved game that shows this in an additional subsequent message to 
this bug report.

Bye, thanks in advance
Giacomo

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages freeciv depends on:
ii  freeciv-client-gtk3  3.1.0+ds-1
ii  freeciv-data 3.1.0+ds-1

freeciv recommends no packages.

freeciv suggests no packages.

-- no debconf information

Bug#1066099: icingaweb2-module-map: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-map
Version: 1.1.0-4
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for icingaweb2-module-map
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers

icingaweb2-module-map_1.1.0-4_templates.pot.bz2
Description: application/bzip

Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec

[MOESSBAUER, Felix]

On Tue, 2024-03-12 at 11:15 -0500, Richard Laager wrote:
> Control: reopen -1
> 
> On 2024-03-12 11:10, MOESSBAUER, Felix wrote:
> > On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote:
> > > This is intentional. The logging is optional and whether the
> > > directory
> > > exists controls this.
> > 
> > Hi Richard,
> > 
> > that's a quite uncommon interface. Is this at least documented
> > somewhere?
> 
> ntp.conf

Okayy... I was just looking at the manpage.

> 
> > Also the "error" should be downgraded to a "warning" at
> > least.
> 
> Didn't I do that?

Right. I re-tested on a bookworm system where this issue first popped
up. Anyways, thanks for the pointer.

Felix
> > 

-- 
Siemens AG, Technology
Linux Expert Center

Bug#987124: console-setup not work properly with plymouth

[Vladimir K]

If plymouth password prompt is used during boot (i.e. root volume decryption 
from initramfs), just the patch above will not work, also need to add 
plymouth-quit.service to 'After' property in console-setup.service

Bug#1053565: RFS: openvpn3-client/21+dfsg-1 [ITP] -- virtual private network daemon (version 3)

[Andrew Lee]

Package: sponsorship-requests
Followup-For: Bug #1053565
X-Debbugs-Cc: ajq...@debian.org

Hi Marc,

Thank you for your efforts in packaging this package into Debian.
I noticed that you conducted a thorough license check and
re-uploaded the package into mentors.

However, there are still some lintian warnings/errors present in
the `debian/copyright` file. Please ensure to check this on the
webpage after uploading, or preferably, run a local lintian check
before uploading or committing.

Additionally, Tobi suggested that the Python component might be
better suited in a dedicated Python module package. What are your
thoughts on this?

Best regards,
-Andrew

Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec

[Richard Laager]

Control: reopen -1

On 2024-03-12 11:10, MOESSBAUER, Felix wrote:

On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote:

This is intentional. The logging is optional and whether the
directory
exists controls this.


Hi Richard,

that's a quite uncommon interface. Is this at least documented
somewhere?


ntp.conf


Also the "error" should be downgraded to a "warning" at
least.


Didn't I do that?

commit b06f1d8177a9b0a2593947a2ebefcb43e94ac281
Author: Santiago Vila 
Date:   Sun Dec 24 15:36:25 2023 -0600

Downgrade missing stats dir log severity

The Debian package does not create /var/log/ntpsec by default.  The
admin  is directed (by a comment in ntp.conf) to create it if and only
if they want logging.  However, upstream ntpsec logs an error message
if the log directory does not exist.

Closes: 1049424
Signed-off-by: Richard Laager 
[The commit message / patch description is my wording.]



One advantage of that is the ntpsec-ntpviz package can create that
directory to enable logging, which is required for ntpviz to be
useful.
Otherwise, it would have to edit the config file, which is riskier.


Well... for that conf.d style configs are usually used.


Yeah. ntpsec supports those _now_. (I don't know that it did at the 
time.) So maybe that's a better answer.


--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065913: opm-common: Please drop dependencies on python3-distutils

[Markus Blatt]

Hi,

the dependency is alread gone  version 2023.10+ds-2 and later (unstable). We
just need to wait for their migration to testing.

Best,

Markus