Bug#1068035: FTBFS: wrong --link-doc target

[Steve Langasek]

Package: mdbtools
Version: 1.0.0+dfsg-1.2
Followup-For: Bug #1068035
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Hi Jean-Michel,

I am unclear how there are binaries in the archive for mdbtools
1.0.0+dfsg-1.2, given this bug is present there and affects all
architectures.  Nevertheless, the fix for the problem is attached.  As this
is fallout from the time_t transition, I am uploading a 0-day NMU to correct
the issue.

Thanks,
-- 
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 mdbtools-1.0.0+dfsg/debian/rules mdbtools-1.0.0+dfsg/debian/rules
--- mdbtools-1.0.0+dfsg/debian/rules2023-04-03 05:46:44.0 -0700
+++ mdbtools-1.0.0+dfsg/debian/rules2024-04-22 22:55:55.0 -0700
@@ -8,5 +8,5 @@
dh_auto_configure -- --with-unixodbc=/usr
 
 override_dh_installdocs:
-   dh_installdocs --no-package=mdbtools-doc --link-doc=libmdb3
+   dh_installdocs --no-package=mdbtools-doc --link-doc=libmdb3t64
dh_installdocs --package=mdbtools-doc

Bug#1069920: libtimezonemap: fixed-up port to libsoup3

[Steve Langasek]

Package: libtimezonemap
Version: 0.4.6-6
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear maintainers,

Because webkit2gtk has now moved to libsoup3, and because we have
reverse-dependencies that require both libtimezonemap and webkit2gtk, I have
done the work in Ubuntu to fix up the port of libtimezonemap to libsoup3.

This has been confirmed to work in the timezone picker in oem-config as used
on our Ubuntu images for Raspberry Pi and has shipped in Ubuntu 24.04 LTS.

Please consider including this revised patch in Debian.

Thanks,
-- 
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 libtimezonemap-0.4.6/debian/control 
libtimezonemap-0.4.6/debian/control
--- libtimezonemap-0.4.6/debian/control 2024-03-30 19:18:27.0 -0700
+++ libtimezonemap-0.4.6/debian/control 2024-04-08 16:33:09.0 -0700
@@ -19,7 +19,7 @@
libgtk-3-dev (>= 3.1.4),
libcairo2-dev (>= 1.10),
libjson-glib-dev,
-   libsoup2.4-dev
+   libsoup-3.0-dev (>= 3.0.7)
 Standards-Version: 4.6.2
 Homepage: https://launchpad.net/timezonemap
 Vcs-Browser: https://salsa.debian.org/cinnamon-team/libtimezonemap
diff -Nru libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch 
libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch
--- libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch  2023-06-20 
23:54:22.0 -0700
+++ libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch  2024-04-08 
16:31:23.0 -0700
@@ -5,11 +5,11 @@
 Forwarded: not-yet
 Last-Update: 2022-08-06
 ---
-diff --git a/configure.ac b/configure.ac
-index 3f74dae..4e90e64 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -50,13 +50,13 @@ GDK_REQUIRED_VERSION=2.22
+Index: libtimezonemap/configure.ac
+===
+--- libtimezonemap.orig/configure.ac
 libtimezonemap/configure.ac
+@@ -50,13 +50,13 @@
  GLIB_REQUIRED_VERSION=2.26
  GTK3_REQUIRED_VERSION=3.1.4
  GIO_REQUIRED_VERSION=2.5.11
@@ -25,23 +25,24 @@
json-glib-1.0)
  LIBTIMEZONEMAP_LIBS="$LIBTIMEZONEMAP_LIBS $LIBM"
  
-diff --git a/src/timezone-completion.c b/src/timezone-completion.c
-index d310235..6971ae9 100644
 a/src/timezone-completion.c
-+++ b/src/timezone-completion.c
-@@ -271,8 +271,10 @@ geonames_data_ready (GObject *object, GAsyncResult *res, 
gpointer user_data)
+Index: libtimezonemap/src/timezone-completion.c
+===
+--- libtimezonemap.orig/src/timezone-completion.c
 libtimezonemap/src/timezone-completion.c
+@@ -270,9 +270,10 @@
+   CcTimezoneCompletionPrivate * priv = completion->priv;
GError * error = NULL;
GInputStream * stream;
-   SoupMessage *message;
+-  SoupMessage *message;
 +  const gchar * reason_phrase;
 +  SoupStatus status_code;
  
 -  stream = soup_request_send_finish (SOUP_REQUEST (object), res, );
-+  stream = soup_session_send_finish (SOUP_SESSION (object), res, );
++  stream = soup_session_send_finish (priv->soup_session, res, );
if (stream == NULL)
  {
if (!g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
-@@ -283,8 +285,9 @@ geonames_data_ready (GObject *object, GAsyncResult *res, 
gpointer user_data)
+@@ -283,8 +284,9 @@
return;
  }
  
@@ -53,7 +54,7 @@
  {
JsonParser *parser;
  
-@@ -296,7 +299,7 @@ geonames_data_ready (GObject *object, GAsyncResult *res, 
gpointer user_data)
+@@ -296,10 +298,10 @@
else
  {
g_warning ("Unable to fetch geonames (server responded with: %u %s)",
@@ -61,8 +62,12 @@
 + status_code, reason_phrase);
  }
  
-   g_object_unref (message);
-@@ -362,7 +365,7 @@ static gboolean
+-  g_object_unref (message);
++  g_object_unref (object);
+   g_object_unref (stream);
+ }
+ 
+@@ -362,7 +364,7 @@
  request_zones (CcTimezoneCompletion * completion)
  {
CcTimezoneCompletionPrivate * priv = completion->priv;
@@ -71,28 +76,17 @@
GError *error = NULL;
  
priv->queued_request = 0;
-@@ -388,13 +391,14 @@ request_zones (CcTimezoneCompletion * completion)
-   gchar * version = get_version ();
-   gchar * locale = get_locale ();
-   gchar * url = g_strdup_printf (GEONAME_URL, escaped, version, locale);
-+  GAsyncResult * res;
+@@ -391,10 +393,11 @@
g_free (locale);
g_free (escaped);
  
 -  req = soup_session_request (priv->soup_session, url, );
-+  req = soup_message_new_from_uri (NULL, (GUri *) url);
++  req = soup_message_new (NULL, url);
if (req)
  {
 -  soup_request_send_async (req, priv->cancel, geonames_data_ready, 
completion);
-+  

Bug#1015476: libbpp-qt: ftbfs with LTO (link time optimization) enabled

[Steve Langasek]

Package: libbpp-qt
Version: 2.4.1-9.1
Followup-For: Bug #1015476
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear maintainers,

This build failure is reproducible in Ubuntu, where LTO is enabled by
default on amd64.  The attached patch was sufficient to fix the build
failure there, and I expect will be sufficient to fix it in Debian with LTO
enabled, as well.

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 libbpp-qt-2.4.1/debian/libbpp-qt2t64.symbols.amd64 
libbpp-qt-2.4.1/debian/libbpp-qt2t64.symbols.amd64
--- libbpp-qt-2.4.1/debian/libbpp-qt2t64.symbols.amd64  2024-02-29 
07:30:55.0 -0800
+++ libbpp-qt-2.4.1/debian/libbpp-qt2t64.symbols.amd64  2024-04-11 
22:54:36.0 -0700
@@ -264,7 +264,7 @@
  _ZN5QListI7QStringED2Ev@Base 2.4.1
  _ZN5QListIP13QGraphicsItemED1Ev@Base 2.4.1
  _ZN5QListIP13QGraphicsItemED2Ev@Base 2.4.1
- _ZN5QListIP15QAbstractButtonE6detachEv@Base 2.4.1
+ (optional)_ZN5QListIP15QAbstractButtonE6detachEv@Base 2.4.1
  _ZN5QListIP15QAbstractButtonED1Ev@Base 2.4.1
  _ZN5QListIP15QAbstractButtonED2Ev@Base 2.4.1
  _ZN5QListIP17QGraphicsTextItemE18detach_helper_growEii@Base 2.4.1
@@ -273,7 +273,7 @@
  _ZN7QStringC2EPKc@Base 2.4.1
  _ZN7QStringD1Ev@Base 2.4.1
  _ZN7QStringD2Ev@Base 2.4.1
- _ZN9QtPrivate8RefCount5derefEv@Base 2.4.1
+ (optional)_ZN9QtPrivate8RefCount5derefEv@Base 2.4.1
  _ZNK3bpp10TreeCanvas10metaObjectEv@Base 2.4.1
  _ZNK3bpp10TreeCanvas12drawingWidthEv@Base 2.4.1
  _ZNK3bpp10TreeCanvas13drawingHeightEv@Base 2.4.1

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Andres Salomon]

On Sun, 10 Mar 2024 15:27:21 + Scott Kitterman 
 wrote:



On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" 
 wrote:
>On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler  wrote:
>> * Christoph Biedl  [240302 17:02]:
>> > Chris Hofstaedtler wrote...
>> >
>> > > please remove deborphan. It is stuck, featurewise, in a very old time
>> > > and does not support many currently available dpkg features properly
>> > > (multi-arch, versioned provides, etc).
>> >
>> > FWIW, deborphan is part of my regular workflow, and while you claim
>> > it has defects, it works for me pretty well.
>>
>> It works "well" if you use it in very limited usecases, yes (like I
>> did). It doesn't seem to work well for a lot of people using more of
>> the "features" it has.
>
>Just because it doesn't work for everyone is not a remotely good
>enough reason to ask for its removal. It works for most people. don't
>break it for them.
>
>> The t64 transition will apparently make deborphan mostly useless in
>> trixie.
>>
>> > [..]
>> > So: What are the alternatives? How do they work? Are they a drop-in
>> > replacment or do they introduce new dependencies? Are there feature that
>> > will be no longer supported?
>>
>> release-notes recommends:
>> 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages
>
>Which has nothing to do with what was asked.
>
>> Some people seem to recommend debfoster.
>
>Which really doesn't provide similar functionality.
>
>> > Leaving users in the void about this is just bad style.
>
>I totally agree. Not wanting to maintain it is a shitty reason for
>asking for its removal. If you don't wanna maintain is, just orphan
>it.


It's really a maintainer call if that's appropriate.  So far no one has jumped 
up to ask if they can take over the package.



I'd take the package. I'm one of those who've been using deborphan for 
20+ years and was very surprised to find it gone. If it's truly too 
buggy to consider trustworthy, I'll change the code to spit out a 
warning to users about that. I suspect most deborphan users are grizzled 
oldsters who know better than to blindly trust its recommendations anyway.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069919: transition: kimageannotator

[Boyuan Yang]

Package: release.debian.org
Control: affects -1 + src:kimageannotator
X-Debbugs-Cc: kimageannota...@packages.debian.org couc...@debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: by...@debian.org
Severity: normal

I would like to initiate the following listed transitions together
since they are tightly bundled together:

* https://release.debian.org/transitions/html/auto-kimageannotator.html
* https://release.debian.org/transitions/html/auto-kcolorpicker.html

List of all affected packages:

Level 0:
* src:kcolorpicker
Level 1:
* src:kimageannotator
Level 2:
* src:ksnip
* src:gwenview

The basic rationale is the upstream renaming of shared libraries (for
dual Qt5/Qt6 support):

libkimageannotator0 => libkimageannotator-qt{5,6}-0
libkcolorpicker0 => libkcolorpicker-qt{5,6}-0

Since src:kcolorpicker, src:kimageannotator and src:ksnip have a
tight relationship, they will be updated in Sid together in this
transition. Rebuilds in Experimental for all involved packages were
prepared, performed and all passed.

Since I am the package maintainer (or team co-maintainer) of all four
packages, I will perform all-manual source-only uploads for all involved
packages (Experimental => Sid) bottom-up following the dependency chain
once the transition is approved.


Ben file:

(please reuse auto-kcolorpicker and auto-kimageannotator trackers.)


Thanks,
Boyuan Yang


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

Bug#1069918: npm: depedency issue prevent to install npm while neovim is installed

[Mathieu R.]

Package: npm
Version: 9.2.0~ds1-2
Severity: normal
X-Debbugs-Cc: report...@ecl.400iso.net

When trying to install npm on testing, it tries to pull libuv1t64, that appear 
to
be incompatible with libuv1, on wich neovim depends: 

Unsatisfied dependencies:
 libuv1t64 : Breaks: libuv1 (< 1.48.0-1.1)


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (450, 'unstable'), (400, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=fr_FR:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages npm depends on:
ii  ca-certificates20240203
pn  node-abbrev
pn  node-agent-base
pn  node-aproba
pn  node-archy 
pn  node-base64-js 
pn  node-binary-extensions 
pn  node-cacache   
pn  node-chalk 
pn  node-chownr
pn  node-ci-info   
pn  node-cli-table3
pn  node-colors
pn  node-columnify 
pn  node-cssesc
pn  node-debug 
pn  node-depd  
pn  node-diff  
pn  node-emoji-regex   
pn  node-encoding  
pn  node-events
pn  node-glob  
pn  node-got   
pn  node-graceful-fs   
pn  node-gyp   
pn  node-hosted-git-info   
pn  node-http-proxy-agent  
pn  node-https-proxy-agent 
pn  node-ieee754   
pn  node-ini   
pn  node-ip
pn  node-ip-regex  
pn  node-json-parse-better-errors  
pn  node-jsonparse 
pn  node-lru-cache 
pn  node-minimatch 
pn  node-minipass  
pn  node-mkdirp
pn  node-ms
pn  node-negotiator
pn  node-nopt  
pn  node-normalize-package-data
pn  node-npm-bundled   
pn  node-npm-normalize-package-bin 
pn  node-npm-package-arg   
pn  node-npmlog
pn  node-once  
pn  node-p-map 
pn  node-postcss-selector-parser   
pn  node-promise-retry 
pn  node-promzard  
pn  node-read  
pn  node-read-package-json 
pn  node-rimraf
pn  node-semver
pn  node-ssri  
pn  node-string-width  
pn  node-strip-ansi
pn  node-tar   
pn  node-text-table
pn  node-validate-npm-package-license  
pn  node-validate-npm-package-name 
pn  node-which 
pn  node-wrappy
pn  node-write-file-atomic 
pn  node-yallist   
ii  nodejs 18.19.1+dfsg-3

Versions of packages npm recommends:
ii  git   1:2.43.0-1+b1
pn  node-tap  

Versions of packages npm suggests:
pn  node-opener  

Bug#1062071: genometools: NMU diff for 64-bit time_t transition

[Steve Langasek]

Dear maintainers,

There was a hard-coded test dependency on libgenometools0 in
debian/tests/control which prevents this package from being able to migrate
to testing.

There is no need to hard-code a dependency on the runtime lib given that
there is already a test dependency on libgenometools-dev.

I am uploading a follow-up 0-day NMU to fix this outstanding issue from the
time_t transition.  Please find attached a comprehensive NMU debdiff.

On Wed, Feb 28, 2024 at 04:30:06PM +, Steve Langasek wrote:
> 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')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru genometools-1.6.5+ds/debian/changelog 
> genometools-1.6.5+ds/debian/changelog
> --- genometools-1.6.5+ds/debian/changelog 2023-10-25 22:08:09.0 
> +
> +++ genometools-1.6.5+ds/debian/changelog 2024-02-28 16:25:48.0 
> +
> @@ -1,3 +1,10 @@
> +genometools (1.6.5+ds-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.  Closes: #1062071
> +
> + -- Steve Langasek   Wed, 28 Feb 2024 16:25:48 +
> +
>  genometools (1.6.5+ds-2) unstable; urgency=medium
>  
>* Facilitate building twice from the same source directory.
> diff -Nru genometools-1.6.5+ds/debian/control 
> genometools-1.6.5+ds/debian/control
> --- genometools-1.6.5+ds/debian/control   2023-09-19 21:22:02.0 
> +
> +++ genometools-1.6.5+ds/debian/control   2024-02-28 16:25:48.0 
> +
> @@ -4,7 +4,7 @@
> Andreas Tille 
>  Section: science
>  Priority: optional
> -Build-Depends: debhelper (>= 13),
> +Build-Depends: dpkg-dev (>= 1.22.5), debhelper (>= 13),
> debhelper-compat (= 13),
> dh-python,
> liblua5.1-0-dev,
> @@ -70,7 +70,10 @@
>   transformations, style files, etc. required to use the GenomeTools
>   executable and/or library.
>  
> -Package: libgenometools0
> +Package: libgenometools0t64
> +Provides: ${t64:Provides}
> +Replaces: libgenometools0
> +Breaks: libgenometools0 (<< ${source:Version})
>  Architecture: any
>  Section: libs
>  Depends: ${shlibs:Depends},
> @@ -91,7 +94,7 @@
>  Section: libdevel
>  Depends: ${shlibs:Depends},
>   ${misc:Depends},
> - libgenometools0 (= ${binary:Version})
> + libgenometools0t64 (= ${binary:Version})
>  Description: development files for GenomeTools
>   This package contains the GenomeTools static library and necessary
>   header files.
> @@ -118,7 +121,7 @@
>  Depends: ${shlibs:Depends},
>   ${misc:Depends},
>   ${python3:Depends},
> - libgenometools0
> + libgenometools0t64
>  Description: Python3 bindings for genometools
>   Partial Python3 bindings for the GenomeTools library. Besides basic
>   bioinformatics data structures, the library contains components for sequence
> diff -Nru genometools-1.6.5+ds/debian/libgenometools0.install 
> genometools-1.6.5+ds/debian/libgenometools0.install
> --- genometools-1.6.5+ds/debian/libgenometools0.install   2023-09-19 
> 21:22:02.0 +
> +++ genometools-1.6.5+ds/debian/libgenometools0.install   1970-01-01 
> 00:00:00.0 +
> @@ -1 +0,0 @@
> -lib/libgenometools.so.0 usr/lib
> diff -Nru genometools-1.6.5+ds/debian/libgenometools0t64.install 
> genometools-1.6.5+ds/debian/libgenometools0t64.install
> --- genometools-1.6.5+ds/debian/libgenometools0t64.install1970-01-01 
> 00:00:00.0 +
> +++ genometools-1.6.5+ds/debian/libgenometools0t64.install2023-09-19 
> 21:22:02.0 +
> @@ -0,0 +1 @@
> +lib/libgenometools.so.0 usr/lib
> diff -Nru genometools-1.6.5+ds/debian/libgenometools0t64.lintian-overrides 
> genometools-1.6.5+ds/debian/libgenometools0t64.lintian-overrides
> --- genometools-1.6.5+ds/debian/libgenometools0t64.lintian-overrides  
> 1970-01-01 00:00:00.0 +
> +++ genometools-1.6.5+ds/debian/libgenometools0t64.lintian-overrides  
> 2024-02-28 16:15:24.0 +
> @@ -0,0 +1 @@
> +libgenometools0t64: package-name-doesnt-match-sonames libgenometools0


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

Bug#1069917: python-binary-memcached: please drop extraneous python3-mock build dependency

[Alexandre Detiste]

Source: python-binary-memcached
Version: 0.31.1+dfsg1-2
Severity: normal

Dear Maintainer,

This project will use unittest.mock on Python 3.

Greetings


tchet@quieter:/tmp/python-binary-memcached$ head test/test_errors.py -n 20
...
import six
...
if six.PY3:
from unittest import mock
else:
import mock

Bug#1069916: python-dogpile.cache: please drop the old python3-mock dependency

[Alexandre Detiste]

Source: python-dogpile.cache
Version: 1.1.8-3
Severity: normal

Dear Maintainer,

This project has switched to the newer unittest.mock
from the Python standard library.

Greetings

tchet@quieter:/tmp/python-dogpile.cache$ grep mock -r | grep -e import -e debian
debian/control: python3-mock,
tests/cache/plugins/test_mako_cache.py:from unittest import mock
tests/cache/test_memcached_backend.py:from unittest import mock
tests/cache/test_redis_backend.py:from unittest.mock import Mock
tests/cache/test_redis_backend.py:from unittest.mock import patch
tests/cache/test_region.py:from unittest import mock
tests/test_lock.py:from unittest import mock
tchet@quieter:/tmp/python-dogpile.cache$ 

Bug#1069915: file: wrong Breaks/Replaces in libmagic-mgc

[Steve Langasek]

Package: file
Version: 5.45-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch

Hi Christoph,

The time_t transition automation scripts incorrectly changed the versioned
Breaks/Replaces against old libmagic1 to point to libmagic1t64, which
clearly never had a package version (<< 1:5.28-4~).

The attached patch fixes this mistake, although since the version in
oldoldstable is 1:5.35-4+deb10u2, perhaps you would prefer to drop the
fields instead.

Regards,
-- 
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 file-5.45/debian/control file-5.45/debian/control
--- file-5.45/debian/control2024-03-01 09:30:02.0 -0800
+++ file-5.45/debian/control2024-03-22 11:54:36.0 -0700
@@ -50,9 +50,9 @@
 Architecture: any
 Depends: ${misc:Depends},
 Breaks:
-libmagic1t64 (<< 1:5.28-4~),
+libmagic1 (<< 1:5.28-4~),
 Replaces:
-libmagic1t64 (<< 1:5.28-4~),
+libmagic1 (<< 1:5.28-4~),
 Section: libs
 Priority: optional
 Multi-Arch: foreign

Bug#1069914: dfdatetime: please remove the extraneous dependency on python3-mock

[Alexandre Detiste]

Source: dfdatetime
Version: 20240220-1
Severity: normal

Dear Maintainer,

tchet@quieter:/tmp/dfdatetime$ grep mock -r
debian/control:   python3-mock,

Mock is not used anymore:

https://github.com/log2timeline/dfdatetime/pull/246

Greetings

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

On Sat, 2024-04-27 at 03:15 +0200, Guilhem Moulin wrote:
> Yup that'd make sense to me (and I see you did that already), thanks!

:-)

Unfortunately I doubt it will be possibly to do some fully generic
solution.

So best we'll get is probably either an unconditional inclusion or some
simpler copy_* function.


Thanks for your help with the hint on the 2.34 change... I had already
been at my wits end, why pthread didn't show up at ldd ^^

Best wishes,
Chris.

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

On Sat, 27 Apr 2024 at 02:07:21 +0200, Christoph Anton Mitterer wrote:
> So you say it's a glibc thingy, that this doesn't show up anymore?

Yup, that's what I wrote https://bugs.debian.org/1032235#97

| It was intentional, see the article
| 
https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread
 .
| Unfortunately that change broke initramfs-tools' fix for 
https://bugs.debian.org/950254
| which we (src:cryptsetup maintainers) relied on for cryptsetup-initramfs.
| Until last week src:argon2 had never been rebuilt with the newer glibc,
| so it's just unfortunate that we missed that at the time.

On the one hand it was unfortunate to find such a severe RC bug
(unbootable system with the default config) so late in the freeze, on
the other hand it would have been even worse if src:argon2 would have
been uploaded to bookworm-security or -pu after the stable release :-)

> $ ldd /usr/bin/argon2
>   linux-vdso.so.1 (0x7ffcc67d4000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a1ee48000)
>   /lib64/ld-linux-x86-64.so.2 (0x7f1a1f058000)
>
> I should use libc for determination?

Don't know if that's the best or most robust solution but that's what
I'd do as workaround at least.

> Would you recommend me to reassign #1069912 to initramfs-tools, asking
> for a more user-friendly solution?

Yup that'd make sense to me (and I see you did that already), thanks!

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1069913: dovecot-imapd: dovecot starts before home directories are available

[Peter Chubb]

Package: dovecot-imapd
Version: 1:2.3.21+dfsg1-3+b1
Severity: normal

Dear Maintainer,

   On my system, home directories are automounted using autofs over NFS.
   It appears that dovecot starts before the autofs daemon is completely
   ready. Thus, it seems to be looking at the (empty) mount point 
   and seeing no mailboxes in people's home directories.

   The workaround is to wait until the system is fully up, log in,
   and restart dovecot.

   It's taken me a while to work out what's going on; it seems to have come 
   when I started using systemd instead of sysV init.  I suspect it's an
   ordering issue, but it's not that obvious how to make dovecot delay
   starting until autofs is ready to mount directories.


-- Package-specific info:

dovecot configuration
-
# 2.3.21 (47349e2482): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.21 (f6cd4b8e)
# OS: Linux 6.7.12-amd64 x86_64 Debian trixie/sid 
# Hostname: wombat.chubb.wattle.id.au
first_valid_uid = 130
mail_access_groups = mail
mail_full_filesystem_access = yes
mail_location = mbox:~/Mail/:INBOX=/var/mail/%u:INDEX=/var/indices/%u
mail_nfs_storage = yes
mail_privileged_group = mail
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Spam {
special_use = \Junk
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
  separator = /
}
passdb {
  driver = pam
}
passdb {
  driver = pam
}
protocols = " imap"
ssl_cert = 

Versions of packages dovecot-imapd is related to:
ii  dovecot-core [dovecot-common]  1:2.3.21+dfsg1-3+b1
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.3.21+dfsg1-3+b1
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
pn  dovecot-sieve  
pn  dovecot-sqlite 

-- no debconf information

Bug#1069912: argon2 tool doesn't properly link against pthread

[Christoph Anton Mitterer]

Control: reassign -1 initramfs-tools
Control: severity -1 important
Control: retitle -1 copy_exec doesn't detect libgcc dependency anymore when 
pthread is used

Hey.


I think I found the root cause (thanks to Guilhem Moulin, who
pointed[0] me to it).

Apparently (which wasn't on my radar at all ^^), glibc since 2.34
dropped libpthread. So the whole check you do in hook-functions[2] will
probably never work anymore, which hit me with my argon2 (the tool not
the lib).

Now pthread apparently dlopen()s stuff from gcc, so in my case
pthread_exit fails.

Guilhem already remembered that you've been reluctant to
unconditionally include libgcc - which I can understand (I also want to
keep my initramfs as small as possible) - but this breaks stuff and
apart from ugly manual hacks I don't see an easy way around it.

Could you please either reconsider adding it unconditionally, or is
there some other way to find out whether a binary uses pthread stuff?

If not, would it be possible to provide at least some simpler to use
interface to copy_libgcc? Where e.g. I'd just say:
copy_libgcc /usr/bin/argon2 and it would automatically find the right
libdir for the right arch?

Thanks,
Chris.


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068849#89
[1] https://lists.gnu.org/archive/html/info-gnu/2021-08/msg1.html
[2] 
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/cf964bfb4362019fd7fba1e839e403ff950dca8e/hook-functions#L248-L249

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote:
> built using glibc ≥2.34.  AFAICT the “if the ldd output includes
> libpthread then run copy_libgcc()” logic from initramfs-tools is
> mostly moot
> now

Ah, I just realised glibc "merged" libpthread ^^

Therefore...

> but despite what I promised elbrus in
> https://bugs.debian.org/1032235#87 it
> looks like I didn't file a bug.

... I helped you fulfilling your promise and re-assigned my #1069912,
making it the bug that asks for some more generic solution :-)


Thanks,
Chris.

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

Hey Guilhem

On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote:
> Even it weren't, libpthread wouldn't show up since src:argon2 from
> bookworm
> and later is built using glibc ≥2.34.

When argon2 builds, it uses -pthread ... not really sure what that does
exactly, the manpage merely says it links against pthread, but
statically? Dynamically?

Anyway, when building it manually and even with -lpthread, it doesn't
show up - just as you say.

Tried now for an hour or so to make it show up (eventually gave up and
filed #1069912).

So you say it's a glibc thingy, that this doesn't show up anymore?


>   AFAICT the “if the ldd output includes
> libpthread then run copy_libgcc()” logic from initramfs-tools is
> mostly moot
> now, see https://bugs.debian.org/1032235#97 .

Shouldn't initramfstools then not simply generally include libgcc?



> We used the following workaround to manually call copy_libgcc()
> 
>    
> https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/4cade1eae57abd93e0d6491eebce5f5f163ef186#a630d04e2df57150e6a092fc23f955c6ea0ce412
>    
> https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/369cb651abad11a3844fa38ea86ece40f4f40078

As a workaround I've used now:
copy_libgcc /lib/x86_64-linux-gnu

with the libpath hardcoded... but I have no idea how I should get that
path properly.
As far as I can see from your commit, you simply used the path that
libargon2 was using?

But I don't have that since argon2 doesn't link against it ;-)
Any idea what would be the best solution in my case?


> for Bookworm, but removed it with 2:2.7.2-1 since src:cryptsetup no
> longer uses libargon.  There is no stability guaranty for transitive
> dependencies so I'd indeed argue the regression is not
> src:cryptsetup's
> fault :-)  Adapting the above workarounds to your custom hookfile
> should
> solve the issue, though.

Hmm yes, but I'm not sure if that would be a more proper solution than
mine (with the hardcoded path), cause:

In principle, my argon2 binary tool, might be from another arch as the
installed libargon2 (if it's installed at all, which isn't necessarily
the case).
So not sure, but maybe:

$ ldd /usr/bin/argon2
linux-vdso.so.1 (0x7ffcc67d4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a1ee48000)
/lib64/ld-linux-x86-64.so.2 (0x7f1a1f058000)

I should use libc for determination?

> 



> > Did anyone of your report this issue anywhere else?
> 
> Some years ago I asked the initramfs-tools maintainers to
> inconditionally copy
> libgcc_s to the initramfs image, but IIRC Ben argued it was too
> seldom used to
> justify the cost in size and impemented the libpthread detection
> logic +
> copy_libgcc() instead.
> 
> I don't know if the detection logic can be improved/fixed in
> initramfs-tools,
> but despite what I promised elbrus in
> https://bugs.debian.org/1032235#87 it
> looks like I didn't file a bug.

So... I assume the change in glibc is proper then... and a fix (if at
all) would rather need to go to initramfs-tools?
Would you recommend me to reassign #1069912 to initramfs-tools, asking
for a more user-friendly solution?


Thanks,
Chris.

Bug#1069912: argon2: argon2 tool doesn't properly link against pthread

[Christoph Anton Mitterer]

Package: argon2
Version: 0~20190702+dfsg-4+b1
Severity: wishlist


Hey.

I stumbled over some odd issue, originally described here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068849#84

In short:
I use the argon2 tool inside the initramfs, into which I copy it via
initramfs-tools’ copy_exec function (defined in
/usr/share/initramfs-tools/hook-functions).

Now that function uses ldd to find out whether a binary is linked
against libpthread and if so, also includes libgcc because of #950254
(in short: pthread seems to dlopen() libgcc).

Now argon2 somehow doesn't indicate it uses libpthread:
$ ldd /usr/bin/argon2
linux-vdso.so.1 (0x7ffedb996000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f90666bb000)
/lib64/ld-linux-x86-64.so.2 (0x7f90668cb000)

which I don't quite understand why.
Actually, even when building it manually, an explicitly -lpthread it never
shows up there.

No idea why... perhaps some linker optimisation that goes wrong?
I tried with -Wl,--no-as-needed, but that doesn't help either.
I can only force it to link if using
   gcc … -Wl,--no-as-needed /usr/lib/x86_64-linux-gnu/libpthread.so.0
i.e. the real path of the .so.


So in my case, pthread_exit() fails eventually (in the initramfs), with
an error that libgcc cannot be found.


Any ideas what to do?


Thanks,
Chris.

Bug#1017811: node-wikibase-cli: FTBFS without Internet access

[Santiago Vila]

I have commented out a pair of test cases which attempted network access in the 
upload of node-wikibase-cli 15.15.4-5. Could you please check whether FTBFS 
continues?


Hello. Yes, it continues to fail.

You can tell by looking at the reproducible-builds page for the package:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-wikibase-cli.html

because packages trying to use the network fail in reproducible-builds.

Another way to tell is by using the unshare backend of sbuild:

https://wiki.debian.org/sbuild#Using_unshare_with_mmdebstrap_.28no_root_needed.29

The unshare backend also makes packages like this to fail (this is how I arrived
at this report, I'm currently helping Jochen to build the whole archive using 
the unshare backend).

Thanks.

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

Hi,

On Sat, 27 Apr 2024 at 00:33:51 +0200, Christoph Anton Mitterer wrote:
> Now the problem is that argon2 is statically linked, so there's no
> libpthread showing up in its ldd, and thus copy_exec doesn't realise it
> needs to invoke copy_libgcc.

Even it weren't, libpthread wouldn't show up since src:argon2 from bookworm
and later is built using glibc ≥2.34.  AFAICT the “if the ldd output includes
libpthread then run copy_libgcc()” logic from initramfs-tools is mostly moot
now, see https://bugs.debian.org/1032235#97 .

We used the following workaround to manually call copy_libgcc()


https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/4cade1eae57abd93e0d6491eebce5f5f163ef186#a630d04e2df57150e6a092fc23f955c6ea0ce412

https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/369cb651abad11a3844fa38ea86ece40f4f40078

for Bookworm, but removed it with 2:2.7.2-1 since src:cryptsetup no
longer uses libargon.  There is no stability guaranty for transitive
dependencies so I'd indeed argue the regression is not src:cryptsetup's
fault :-)  Adapting the above workarounds to your custom hookfile should
solve the issue, though.

> Did anyone of your report this issue anywhere else?

Some years ago I asked the initramfs-tools maintainers to inconditionally copy
libgcc_s to the initramfs image, but IIRC Ben argued it was too seldom used to
justify the cost in size and impemented the libpthread detection logic +
copy_libgcc() instead.

I don't know if the detection logic can be improved/fixed in initramfs-tools,
but despite what I promised elbrus in https://bugs.debian.org/1032235#87 it
looks like I didn't file a bug.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x

[Dirk Lehmann]

26.04.2024 19:52:12 Andreas Beckmann :

> On 26/04/2024 18.54, Dirk Lehmann wrote:
>> Yes, thanks that works, I used
>> $> apt-get install libgnutls-dane0t64
>
> Does dist-upgrade work again now?
>

Yes, now it works fine with libgnutls30t64 3.8.5-2 :) ...

But can this issue occur in the future, when someone upgrade from the current 
Debian stable 'Bookworm' to the next stable 'Trixie'?

Testing users should assume that such issues occur. But a Debian stable upgrade 
should be run fluent.

Bug#1068849: [pkg-cryptsetup-devel] Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

Hey guys.

I kinda ran into a similar issue.

I use my own OpenPGP keyscript which is highly improved upon that
("decrypt_gnupg") shipped by the package.

One thing that I do is offer optionally feeding the entered passphrase
trough argon2 (the standalone tool from the package of the same name)
which I copy via copy_exec.

Now the problem is that argon2 is statically linked, so there's no
libpthread showing up in its ldd, and thus copy_exec doesn't realise it
needs to invoke copy_libgcc.


Did anyone of your report this issue anywhere else? I mean it's
obviously not crypsetup.
But I cannot really blame argon2 either, nor can I really blame update-
initramfs.


Cheers,
Chris.

Bug#1069911: texlive-base: Include manual page for simpdftex

[Hilmar Preusse]

Package: texlive-base
Version: 2022.20230122-3
Severity: wishlist
Tags: patch

Dear Maintainer,

I've created a manual page for simpdftex. Consider to include
it into our package.

Hilmar

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

lrwxrwxrwx 1 root root 31 Apr  9  2023 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Mar 17 22:43 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Apr  9  2023 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Apr  9  2023 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2738 Mar 17 22:45 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Apr  1  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Mar 17 22:43 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.6.28+rpt-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libpaper-utils 1.1.29
ii  sensible-utils 0.0.17+nmu1
ii  tex-common 6.18
ii  texlive-binaries   2022.20220321.62855-5.1+deb12u1
ii  ucf3.0043+nmu1
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
pn  lmodern  

Versions of packages texlive-base suggests:
ii  ghostscript [postscript-viewer]  10.0.0~dfsg-11+deb12u3
pn  perl-tk  
pn  xpdf | pdf-viewer
pn  xzdec

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.4

Versions of packages texlive-base is related to:
ii  tex-common6.18
ii  texlive-binaries  2022.20220321.62855-5.1+deb12u1

-- debconf information excluded
.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.3.
.TH SIMPDFTEX "1" "April 2024" "" ""
.SH NAME
simpdftex \- is a way to do pdf{e}{la}tex without having pdf{e}{la}tex
.SH SYNOPSIS
.B simpdftex
\fI\,formatname \/\fR[\fI\,--mode modestring\/\fR]
.SH DESCRIPTION
This is simpdftex, 20221012
.IP
[\-\-dvipsopts dvipsoptstring] [\-\-extradvipsopts dvipsoptstring] [\-\-pdf]
[\-\-default] [\-\-maxpk] [\-\-maxpfb] [\-\-extendedname] 
[\-\-no\-echo\-version]
[\-\-tex\-path dir] [\-\-keep\-psfile] [\-\-distiller\-path dir] [\-\-debug]
[\-\-distiller prog] [\-\-distiller\-filter prog] [\-\-distilleropts opts]
[\-\-help] [\-\-outdir dir] [\-\-extratexopts texoptsstring]
[\-\-dvipdfmopts dvipdfmoptstring] tex\-or\-dvi\-file
.PP
simpdftex is a way to do pdf{e}{la}tex without having pdf{e}{la}tex. It needs a
working TeX 

Bug#1069910: ecl: FTBFS with LTO

[Steve Langasek]

Package: ecl
Version: 21.2.1+ds-4.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch

Dear maintainers,

ecl fails to build when LTO is enabled, basically hanging indefinitely until
hitting a timeout and being killed.

  https://launchpad.net/ubuntu/+source/ecl/21.2.1+ds-4.1/+build/27828342

LTO is enabled by default in Ubuntu, so we have worked around this there by
disabling LTO as in the attached patch.

LTO is not enabled by default in Debian, however there have been discussions
about doing so.  Therefore you may want to consider applying the attached
patch in Debian as well, to future-proof the package against toolchain
changes.

Thanks,
-- 
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 ecl-21.2.1+ds/debian/rules ecl-21.2.1+ds/debian/rules
--- ecl-21.2.1+ds/debian/rules  2021-12-04 11:51:55.0 -0800
+++ ecl-21.2.1+ds/debian/rules  2024-03-27 22:26:54.0 -0700
@@ -3,6 +3,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
+
 %:
dh $@
 

Bug#1069909: dcraw: FTBFS due to conflicting memmem prototype

[Steve Langasek]

Package: dcraw
Version: 9.28-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hi Filip,

In Ubuntu, dcraw was failing to build because of a local implementation of
memmem() whose prototype conflicts with the glibc prototype:

[...]
gcc -DPACKAGE_NAME=\"dcraw\" -DPACKAGE_TARNAME=\"dcraw\" 
-DPACKAGE_VERSION=\"9.28\" -DPACKAGE_STRING=\"dcraw\ 9.28\" 
-DPACKAGE_BUGREPORT=\"hr...@physics.muni.cz\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"dcraw\" -DVERSION=\"9.28\" -DHAVE_LIBM=1 -DHAVE_STDIO_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 
-DSTDC_HEADERS=1 -DHAVE_JPEGLIB_H=1 -DHAVE_LIBJPEG=1 -DHAVE_LCMS2_H=1 
-DHAVE_LIBLCMS2=1 -I.   -Wdate-time -D_FORTIFY_SOURCE=3  -g -O2 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/dcraw-9.28-5build1 -O4 -c -o 
parse.o parse.c
[...]
parse.c:1216:7: error: conflicting types for ‘memmem’; have ‘char *(char *, 
size_t,  char *, size_t)’ {aka ‘char *(char *, long unsigned int,  char *, long 
unsigned int)’}
 1216 | char *memmem (char *haystack, size_t haystacklen,
  |   ^~
In file included from parse.c:13:
/usr/include/string.h:389:14: note: previous declaration of ‘memmem’ with type 
‘void *(const void *, size_t,  const void *, size_t)’ {aka ‘void *(const void 
*, long unsigned int,  const void *, long unsigned int)’}
  389 | extern void *memmem (const void *__haystack, size_t __haystacklen,
  |  ^~
[...]

  (https://launchpad.net/ubuntu/+source/dcraw/9.28-5build1/+build/28000832)

This is not currently a build failure in Debian, but that is strictly a
question of compiler behavior, and this may start to FTBFS in Debian at some
later point.

And anyway, there's no reason to reimplement memmem() here, it's probably
less performant than the version provided by glibc.

We have applied the attached patch in Ubuntu to fix the build failure.  I
think it would be a good idea to apply it in Debian as well.

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 dcraw-9.28/debian/patches/remove-duplicate-memmem.patch 
dcraw-9.28/debian/patches/remove-duplicate-memmem.patch
--- dcraw-9.28/debian/patches/remove-duplicate-memmem.patch 1969-12-31 
16:00:00.0 -0800
+++ dcraw-9.28/debian/patches/remove-duplicate-memmem.patch 2024-04-09 
16:49:27.0 -0700
@@ -0,0 +1,28 @@
+Description: don't reimplement memmem()
+ memmem() is implemented in glibc, don't have a redundant duplicate
+ implementation with a different prototype.
+Author: Steve Langasek 
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: dcraw-9.28/parse.c
+===
+--- dcraw-9.28.orig/parse.c
 dcraw-9.28/parse.c
+@@ -1213,16 +1213,6 @@
+   }
+ }
+ 
+-char *memmem (char *haystack, size_t haystacklen,
+-  char *needle, size_t needlelen)
+-{
+-  char *c;
+-  for (c = haystack; c <= haystack + haystacklen - needlelen; c++)
+-if (!memcmp (c, needle, needlelen))
+-  return c;
+-  return NULL;
+-}
+-
+ /*
+Identify which camera created this file, and set global variables
+accordingly.Return nonzero if the file cannot be decoded.
diff -Nru dcraw-9.28/debian/patches/series dcraw-9.28/debian/patches/series
--- dcraw-9.28/debian/patches/series2024-03-26 02:42:04.0 -0700
+++ dcraw-9.28/debian/patches/series2024-04-09 16:48:07.0 -0700
@@ -8,3 +8,4 @@
 iowrap.diff
 0009-missing_headers.patch
 0010-Fuji-headers.patch
+remove-duplicate-memmem.patch

Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries

[Daniel Kahn Gillmor]

Package: elpa-debian-el
Version: 37.11
Severity: normal
X-Debbugs-Cc: none, d...@fifthhorseman.net, Daniel Kahn Gillmor 


When i do "M-x debian-bug P elpa-debian-el RET" i get the template you
see here.

Weirdly, X-Debbugs-Cc is pre-populated in this way.

There are at least two things wrong with X-Debbugs-Cc here:

 - the string "none" shouldn't be present.  This smells like a bug,
   where the empty string is somehow being misinterpreted as the string
   "none", but i odn't know where it's happening.


 - the two additional addresses are duplicative. Even if there is code
   that tries to re-add a duplicate address, it should notice that the
   e-mail address parts are identical, and coalesce them into a single
   address.

I don't understand the codebase well enough to be able to see how these
things are happening, but if you want me to test some changes, or report
on any other config, please let me know.

   --dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 elpa-debian-el depends on:
ii  bzip2   1.0.8-5.1
ii  dh-elpa-helper  2.0.17
ii  emacsen-common  3.0.5
ii  reportbug   13.0.1
ii  xz-utils5.6.1+really5.4.5-1

Versions of packages elpa-debian-el recommends:
ii  emacs   1:29.2+1-2
ii  emacs-pgtk [emacs]  1:29.2+1-2
ii  wget1.21.4-1+b1

elpa-debian-el suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1065203: regression: TypeError: find_username() missing 1 required positional argument: 'ssh_conf'

[Ben Hutchings]

Control: tag -1 patch

I've opened an MR to fix this at:
https://salsa.debian.org/debian/dput-ng/-/merge_requests/36

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
  - Albert Einstein



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

Bug#1069895: [debian-mysql] Bug#1069895: mariadb-server: InnoDB to hang on systems with very intensive write loads when running out of I/O slots. This problem is fixed with MariaDB Server 10.11.7. Can

[Otto Kekäläinen]

We can put 10.11.7 in Stable until it yas been accepted in Testing first.
It is on the way though.

Bug#1069545: [Pkg-erlang-devel] Bug#1069545: erlang: FTBFS on armel: make[4]: *** [/<>/make/arm-unknown-linux-gnueabi/otp.mk:325: ../pdf/wx-2.2.2.1.pdf] Error 1

[Sergei Golovan]

notfound 1069545 1:25.3.2.11+dfsg-1
thanks

Hi Lucas,

Java throwing an out-of-memory exception on armel doesn't count as a
bug, I reckon.

On the other hand, my previous thought about sufficient memory size on
builds is irrelevant because builds build only architecture dependent
packages, and erlang-doc is architecture independent.

On Tue, Apr 23, 2024 at 10:02 AM Sergei Golovan  wrote:
>
> Version: 1:25.3.2.11+dfsg-1
>
> Hi Lukas,
>
> On Sat, Apr 20, 2024 at 4:27 PM Lucas Nussbaum  wrote:
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on armel.
>
> > > [INFO] FOUserAgent - Rendered page #871.
> > > Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>
> It's an intermittent out-of-memory error. It never occurs on buildds
> (I guess they just have more memory available then in the setup you're
> using for the archive rebuild). Therefore, I'm closing this bugreport.
>
> Cheers!
> --
> Sergei Golovan



-- 
Sergei Golovan

Bug#1069907: dh_apache2: please output reproducible module package pre/post scripts.

[James Addison]

Package: apache2-dev
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
Control: affects -1 mod-mono

Dear Maintainer,

I'm an occasional volunteer contributor to the Reproducible Builds[1] project,
and noticed recently that an Apache webserver module, mod-mono, that depends[2]
on the dh_apache2 debhelper utility from apache2-dev at build-time, failed an
automated Debian reproducibility test[3].

The problem appears to be related to the substitution of a NAMES variable
that appears in the templated pre/post scripts evaluated by dh_apache2; the
templates[4][5][6] are found in the 'apache2' source package.

I don't yet know exactly how the non-deterministic ordering of entries in the
NAMES variable occurs; however the replacement parameters[7] in the
dh_apache2.in script seem relevant, and tracing the creation of those may help.

Producing a value for the NAMES variable deterministically should I believe
allow the mod-mono package -- and any other Debian Apache module packages that
contain more than one named module -- to build reproducibily, in turn enabling
consumers of Debian to reliably rebuild a bit-for-bit identical .deb package
from source.

Regards,
James

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

[2] - https://sources.debian.org/src/mod-mono/3.8-3/debian/control/#L9

[3] - 
https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/mod-mono.html

[4] - 
https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/postinst-apache2/

[5] - 
https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/postrm-apache2/

[6] - 
https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/prerm-apache2/

[7] - 
https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/dh_apache2.in/#L551

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

[Joachim Zobel]

Package: sponsorship-requests  
Severity: normal

Dear mentors,

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

* Package name : vzlogger  
Version  : 0.8.5-1  
Upstream contact : Joachim Zobel   
* URL  : http://wiki.volkszaehler.org/software/controller/vzlogger  
* License  : GPL-3.0-or-later 
* Vcs  : https://github.com/volkszaehler/vzlogger/tree/debian  
Section  : net

The source builds the following binary packages:

vzlogger - program for logging measurements of smart meters

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

http://www.heute-morgen.de/debian/repo/unstable/main/source/net/

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

dget -x http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc

Changes since the last upload:

  * Fixed logrotate conf user name
  * Fixed passing of hardening flags to cmake 

Regards,  
--  
Joachim Zobel

Bug#1069874: E: Problem parsing Provides line of perccli:all=007.2616.0000.0000

[David Kalnischkies]

On Fri, Apr 26, 2024 at 08:30:42AM +0200, Harald Dunkel wrote:
> If I put Dell's current debian package for perccli into my local
> reprepro, then "apt update" complains

Oh boy, that is some heavy package… and that not only because it claims
to be 7GB large… I think the producer of that package meant 7 MB, but
didn't realize that Installed-Size is in KiB, not Bytes.

Anyway, this control file is not produced by dpkg-gencontrol; that
wouldn't include bogus empty lines, too. Maybe you can get them to fix
their package and in that process also clean it up… if they insist on
producing it by hand.


> E: Problem parsing Provides line of perccli:all=007.2616..
> E: Error occurred while processing perccli (NewVersion2)
> E: Problem with MergeList 
> /var/lib/apt/lists/debian.ac.aixigo.de_debian_dists_bookworm-experimental_main_binary-amd64_Packages
> E: The package lists or status file could not be parsed or opened.

Seems like this was simple enough to "fix" in libapt code…
https://salsa.debian.org/apt-team/apt/-/commit/c98bcdf00e5366fec101dd17094d36be21872a02

I would still advice to fix the package as this is somewhat unlikely
to reach users 'soon' (with trixie of course, but I doubt that gets
backports into oblivion).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1069905: debian-keyring: missing OpenPGP certificates for Debian archive processing software (ftpmas...@ftp-master.debian.org, ftpmas...@debian.org)

[Daniel Kahn Gillmor]

Package: debian-keyring
Version: 2024.03.24
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor , 
ftpmas...@ftp-master.debian.org, ftpmas...@debian.org

I receive e-mail messages from the debian FTP archive-processing
software are signed with F38AA24EB85F09F9923CA4949BF6A82061CCB921, and
labeled as From: ftpmas...@ftp-master.debian.org, but the associated
OpenPGP certificate is not found in /usr/share/keyrings/.

I expected to find it in /usr/share/keyrings/debian-role-keys.gpg, but
it wasn't there.

It also wasn't published on any of the common OpenPGP keyservers, that i
could find.  And it's not published via WKD or DANE in the places i'd
expect it to be for the mail addresses in the in the certificate's user
IDs (ftpmas...@ftp-master.debian.org and ftpmas...@debian.org).

It can be found (with no third-party certifications) in the "Upload
Processing Keys" section of https://ftp-master.debian.org/keys.html.

If these role keys are legitimate, then:

- they should be certified by at least a few Debian Developer's
  certificates, hopefully some folks from the FTP team who would know
  which certificate is the right one.

- they should probably be distributed in the debian-keyring package,
  perhaps as part of the debian-role-keys.gpg file.

I note that the User IDs in those keys contain a parenthesized comment
(2022).

User ID comments are generally a bad idea [0], and this is no exception.

[0] 
https://dkg.fifthhorseman.net/blog/openpgp-user-id-comments-considered-harmful.html

If you want to communicate a date range about when these keys should be
acceptable, the right way to do that is explicitly in the metadata
fields associated with the certificates (e.g. key creation time, key
expiration time).  Reasonable OpenPGP tooling should adequately report
and handle that metdata in a standardized way.

I recommend for OpenPGP certificates like this, to start off with a
2-year expiration window, and when there is 1 year left to go, if you
think the signing secret key is still valid and will be for longer,
renew the expiration to another year out.  Those moments of certificate
update are also good moments to publish the certs via hkps at
https://keyring.debian.org/ as well.

Regards,

--dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)

debian-keyring depends on no packages.

Versions of packages debian-keyring recommends:
ii  gnupg  2.2.40-1.1

debian-keyring suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1068515: Also fails to boot for BIOS

[Roland Clobus]

Hello kernel maintainers,

with the release of 6.7.12-1, also the boot variant of BIOS fails to 
boot properly.


With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[RL]

The following message is a courtesy copy of an article
that has been posted to 
gmane.linux.debian.devel.general,gmane.linux.debian.devel.release as well.

Chris Hofstaedtler  writes:

> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data formats to 64bit
> times. One such instance is the set of utmp/wtmp and lastlog files.
>
> Thorsten Kukuk and others have been working on replacements for the
> existing file formats and interfaces [1]; these are called wtmpdb
> and lastlog2.
>
> Some parties have requested that we do something in Debian [2]. If
> we use Thorsten's work (and why not?)

> Thorsten's code introduces new PAM modules to manage the new files,
> so it should transparently work with most packages. Later, the
> old interfaces can probably be turned off.

> On the wiki [0] I have summarized what I know; a list of initial
> work items; and some open questions mostly concerned with upgrading.
>
> I invite you to read the wiki page and the background info, to
> identify gaps

the chkrootkit package provides several utilities for examining some of
these files: chkutmp chkwtmp and check_wtmpx and chklastlog [a] -- it does
not use pam but reads the files in /var/log

How would I test these against the new files - i assume the new versions
are compatable but might need bigger variables in those utilities? (any
assistance with that review is welcome - C is not my thing!)

[a] You can read these here ---
https://salsa.debian.org/pkg-security-team/chkrootkit but nb that there
are many patches in debian/patches that touch these (use gbp pq import
to see the patched versions)


> [0] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb
> [1] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
> [2] https://bugs.debian.org/1068017

Richard

Bug#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 04.12.2023 14:43, Jeremy Bícha wrote:

Hi Jeremy,


As the maintainer of Debian's poppler source package, I would like to
drop poppler's Qt6 packages on i386.

I filed Bug#1068672 and you probably should be able to drop poppler-qt6 
on i386. My package will turn either into "not-installable" or 
"BD-Uninstallable" for i386. I suggest to go ahead on your side, so we 
can close that bug. I intend to upload texworks 0.6.9, once you dropped 
poppler-qt6 for i386 .


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

[Joey Hess]

I was implementing another gitremote-helper today and ran into what I
think is the same problem. Since I've worked around the problem in my
gitremote-helper successfully, I wanted to share what I've learned in
case it can help git-remote-gcrypt.

When git push is run, for a non-forced push, it asks the
gitremote-helper program for "list for-push". It then sends a "push" to
it. And only after that does it go compare the list of refs it got with
the list of refs it has asked to be pushed, and notice if the push would
overwrite a ref. At that point, git pull will complain that refs were
not able to be pushed. But actually nothing stopped the gitremote-helper
from doing a push that overwrote a ref, effectively a force push.

I think this is a bug in git. I can't imagine why it behaves this way.
It requires that every gitremote-helper program effectively replicate
git's own detection of a disallowed push, in order to reject the
"push" with "error $ref"

It is certainly possible for a gitremote-helper program to do that
though. What I did is, when git runs "list for-push", I remember the
refs that are on the remote. Then when git runs "push $src:$dst",
(but not when it's a "+$src" forced push), I compare the sha of $src
with the old ref I saw on the remote. If the shas are different, I 
check `git log --oneline $old..$src` -- if this outputs nothing, then
history is not advancing and it refuses to push that ref, and 
reports the error to git.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1069904: Autopkgtests failed

[Andrey Rakhmatullin]

Package: python3-gnupg
Version: 0.5.2-1
Severity: serious

https://ci.debian.net/packages/p/python-gnupg/unstable/amd64/45884087/

277s + python3.11 test_gnupg.py
493s ...F...
493s ==
493s FAIL: test_search_keys (__main__.GPGTestCase.test_search_keys)
493s Test that searching for keys works
493s --
493s Traceback (most recent call last):
493s   File "/tmp/autopkgtest-
lxc.s9943af9/downtmp/build.Ev1/src/test_gnupg.py", line 1252, in
test_search_keys
493s self.assertEqual(0, r.returncode, 'Non-zero return code')
493s AssertionError: 0 != 2 : Non-zero return code


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

Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 python3-gnupg depends on:
ii  gnupg2.2.40-3
ii  python3  3.11.8-1

python3-gnupg recommends no packages.

python3-gnupg suggests no packages.

Bug#642504: bash: file number exhaustion on certain redirections in loop: "Too many open files"

[Antoine Beaupré]

I saw a similar crash here, where bash would start failing around about
500 iterations in such a loop:

```
export GIT_ASKPASS=echo

grep -v '^#' ../gitolite2gitlab.txt |while read gitolite_path gitlab_path; do
gitolite_url=/srv/git.torproject.org/repositories/$gitolite_path.git 
gitlab_url=https://gitlab.torproject.org/$gitlab_path.git 
echo "diff -u $gitolite_url $gitlab_url"
diff -u <(git ls-remote $gitolite_url) <(git ls-remote $gitlab_url)
done | tee final-remote-diff.patch
```

~500 is not a random number. it's about half of 1024, which i suspect is
the fd limit i'm hitting. i'm betting the shell is just not closing
those file descriptor at all after the pipeline completes.

normally, i would expect the FD to close after the `diff -u` command
returns there, but it seems that's just not happening.

Bug#1069898: mariadb-server: Command History is shared for all users

[Otto Kekäläinen]

Hi!

Can you share more details what you mean? Perhaps steps to reproduce?

Bug#1069903: gssproxy: directory /tmp/gssproxy/clients not available at service start

[Tobias Rupf]

Package: gssproxy
Version: 0.9.1-1+b1
Severity: important
Tags: patch

Dear Maintainer,

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

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

*** End of the template - remove these template lines ***
I'm using gssproxy at my client for automatically getting a kerberos ticket for
a service, without user intervention. I installed and startet the service but
it  was not working until i figured, that I need to create this directory as it
is references in the default config file 99-nfs-client.config. And it has to be
recreated after each restart of my client as files in /tmp do not survive a
reboot.
So I have added an override to /etc/systemd/system/gssproxy.service.d:

[Service]
ExecStartPre=/bin/mkdir -p /tmp/gssproxy/clients
PrivateTmp=true

To actually be used by rpc-gssd.service a second overriide is neccessary for
this service:

[Service]
Environment=GSS_USE_PROXY=yes

Without these two additions gssproxy was not working on my client, so I think
they should be included in the package - or at least be mentioned in the docs
and may be as a comment in the configuration file.


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

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

Versions of packages gssproxy depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u4
ii  libgssapi-krb5-2 1.20.1-2+deb12u1
ii  libgssrpc4   1.20.1-2+deb12u1
ii  libini-config5   0.6.2-1
ii  libk5crypto3 1.20.1-2+deb12u1
ii  libkrb5-31.20.1-2+deb12u1
ii  libpopt0 1.19+dfsg-1
ii  libref-array10.6.2-1
ii  libselinux1  3.4-1+b6
ii  libverto10.3.1-1

gssproxy recommends no packages.

gssproxy suggests no packages.

-- Configuration Files:
/etc/gssproxy/gssproxy.conf changed [not included]

-- no debconf information
[Service]
ExecStartPre=/bin/mkdir -p /tmp/gssproxy/clients
ProtectHome=true
PrivateTmp=true
ProtectSystem=full
ProtectClock=true
ProtectControlGroups=true
ProtectKernelLogs=true
RestrictRealtime=true

Bug#1069902: gropdf generates invalid CreationDate and ModDate

[Christof Meerwald]

Package: groff
Version: 1.23.0-2

$ echo "" | groff -T pdf | grep -F -a Date
5 0 obj << /CreationDate (D:20240426202138+01'+00')
/ModDate (D:20240426202138+01'+00')
$ echo "" | groff -T pdf | grep -F -a Date
5 0 obj << /CreationDate (D:20240426202145+01'+00')
/ModDate (D:20240426202145+01'+00')
$ echo "" | groff -T pdf | grep -F -a Date
5 0 obj << /CreationDate (D:20240426202150+02'+00')
/ModDate (D:20240426202150+02'+00')

Note the '+00' instead of '00' at the end of the date string. Also
note that the first two attempts resulted in a timezone offset of
+01:00, but the last one had a timezone offset of +02:00 (the last one
is correct).

A non-Debian groff 1.23 does not exhibit those issues:

~> echo "" | groff -Tpdf | grep -F -a Date
5 0 obj << /CreationDate (D:20240426202132+02'00')
/ModDate (D:20240426202132+02'00')
~> echo "" | groff -Tpdf | grep -F -a Date
5 0 obj << /CreationDate (D:20240426202142+02'00')
/ModDate (D:20240426202142+02'00')
~> echo "" | groff -Tpdf | grep -F -a Date
5 0 obj << /CreationDate (D:20240426202151+02'00')
/ModDate (D:20240426202151+02'00')


see also
https://lists.gnu.org/archive/html/groff/2024-04/msg00026.html for a
possible patch

Bug#1062074: clanlib FTBFS

[Steve Langasek]

Control: tags 1069385 patch

Please find attached a comprehensive NMU patch for both the time_t
conversion and the FTBFS errors.

I am uploading this now as a 0-day NMU.

-- 
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 clanlib-1.0~svn3827/debian/changelog 
clanlib-1.0~svn3827/debian/changelog
--- clanlib-1.0~svn3827/debian/changelog2023-09-15 13:49:45.0 
-0700
+++ clanlib-1.0~svn3827/debian/changelog2024-04-25 14:29:44.0 
-0700
@@ -1,3 +1,20 @@
+clanlib (1.0~svn3827-11.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix dep from -dev package to point to current runtime lib name.
+Closes: #1069385.
+  * debian/patches/64-bit-time-t-compat.patch: compatibility with 64-bit
+time_t.  Closes: #1067616.
+
+ -- Steve Langasek   Thu, 25 Apr 2024 21:29:44 +
+
+clanlib (1.0~svn3827-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1062074
+
+ -- Steve Langasek   Wed, 28 Feb 2024 15:52:37 +
+
 clanlib (1.0~svn3827-11) unstable; urgency=medium
 
   * Team upload.
diff -Nru clanlib-1.0~svn3827/debian/control clanlib-1.0~svn3827/debian/control
--- clanlib-1.0~svn3827/debian/control  2023-09-15 13:49:45.0 -0700
+++ clanlib-1.0~svn3827/debian/control  2024-04-25 14:29:44.0 -0700
@@ -4,7 +4,7 @@
  Barry deFreese 
 Section: libs
 Priority: optional
-Build-Depends:
+Build-Depends: dpkg-dev (>= 1.22.5),
  bzip2,
  debhelper-compat (= 12),
  libasound2-dev [linux-any],
@@ -28,14 +28,17 @@
 Vcs-Git: https://salsa.debian.org/games-team/clanlib.git
 Homepage: https://github.com/sphair/ClanLib
 
-Package: libclanapp-1.0v5
+Package: libclanapp-1.0t64
+Provides: ${t64:Provides}
+X-Time64-Compat: libclanapp-1.0v5
+Breaks: libclanapp-1.0v5 (<< ${source:Version})
 Architecture: any
 Depends:
  ${misc:Depends},
  ${shlibs:Depends}
 Conflicts:
  libclanapp-1.0
-Replaces:
+Replaces:libclanapp-1.0v5, 
  libclanapp-1.0
 Multi-Arch: same
 Description: ClanLib game SDK runtime
@@ -60,7 +63,7 @@
 Architecture: any
 Section: libdevel
 Depends:
- libclanapp-1.0v5 (= ${binary:Version}),
+ libclanapp-1.0t64 (= ${binary:Version}),
  ${misc:Depends}
 Recommends:
  libfreetype-dev,
diff -Nru clanlib-1.0~svn3827/debian/libclanapp-1.0t64.install 
clanlib-1.0~svn3827/debian/libclanapp-1.0t64.install
--- clanlib-1.0~svn3827/debian/libclanapp-1.0t64.install1969-12-31 
16:00:00.0 -0800
+++ clanlib-1.0~svn3827/debian/libclanapp-1.0t64.install2023-09-15 
13:49:45.0 -0700
@@ -0,0 +1,11 @@
+usr/lib/*/libclanApp*.so.*
+usr/lib/*/libclanCore*.so.*
+usr/lib/*/libclanDisplay*.so.*
+usr/lib/*/libclanGL*.so.*
+usr/lib/*/libclanGUI*.so.*
+usr/lib/*/libclanGUIStyleSilver*.so.*
+usr/lib/*/libclanMikMod*.so.*
+usr/lib/*/libclanNetwork*.so.*
+usr/lib/*/libclanSignals*.so.*
+usr/lib/*/libclanSound*.so.*
+usr/lib/*/libclanVorbis*.so.*
diff -Nru clanlib-1.0~svn3827/debian/libclanapp-1.0t64.lintian-overrides 
clanlib-1.0~svn3827/debian/libclanapp-1.0t64.lintian-overrides
--- clanlib-1.0~svn3827/debian/libclanapp-1.0t64.lintian-overrides  
1969-12-31 16:00:00.0 -0800
+++ clanlib-1.0~svn3827/debian/libclanapp-1.0t64.lintian-overrides  
2024-02-28 07:52:20.0 -0800
@@ -0,0 +1 @@
+libclanapp-1.0t64: package-name-doesnt-match-sonames libclanapp-1.0v5
diff -Nru clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install 
clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install
--- clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install 2023-09-15 
13:49:45.0 -0700
+++ clanlib-1.0~svn3827/debian/libclanapp-1.0v5.install 1969-12-31 
16:00:00.0 -0800
@@ -1,11 +0,0 @@
-usr/lib/*/libclanApp*.so.*
-usr/lib/*/libclanCore*.so.*
-usr/lib/*/libclanDisplay*.so.*
-usr/lib/*/libclanGL*.so.*
-usr/lib/*/libclanGUI*.so.*
-usr/lib/*/libclanGUIStyleSilver*.so.*
-usr/lib/*/libclanMikMod*.so.*
-usr/lib/*/libclanNetwork*.so.*
-usr/lib/*/libclanSignals*.so.*
-usr/lib/*/libclanSound*.so.*
-usr/lib/*/libclanVorbis*.so.*
diff -Nru clanlib-1.0~svn3827/debian/patches/64-bit-time-t-compat.patch 
clanlib-1.0~svn3827/debian/patches/64-bit-time-t-compat.patch
--- clanlib-1.0~svn3827/debian/patches/64-bit-time-t-compat.patch   
1969-12-31 16:00:00.0 -0800
+++ clanlib-1.0~svn3827/debian/patches/64-bit-time-t-compat.patch   
2024-04-25 14:29:44.0 -0700
@@ -0,0 +1,53 @@
+Description: compatibility with 64-bit time_t
+ linux/input.h uses a different structure when time_t is 64-bit, so
+ patch around this.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1067616
+Last-Update: 2024-04-25
+Forwarded: no
+
+Index: clanlib-1.0~svn3827/Sources/GL/GLX/input_device_linuxevent.cpp

Bug#1069901: libchardet: Broken Vcs-* fields

[Boyuan Yang]

Source: libchardet
Version: 1.0.4-1.1
X-Debbugs-CC: infini...@debian.org

Dear Debian libchardet package maintainer,

The Vcs-* fields still points to the old Alioth website.
Please update the information in a new upload.

Thanks,
Boyuan Yang


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

Bug#1069900: libchardet: Please package new upstream release

[Boyuan Yang]

Source: libchardet
Version: 1.0.4-1.1
X-Debbugs-CC: infini...@debian.org

Dear Debian libchardet package maintainer,

A new release of package libchardet (v1.0.6) is available. Please
package the new version with a new upload.

Thanks,
Boyuan Yang


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

Bug#979617: tcplay: VeraCrypt support

[Daniel Kahn Gillmor]

Hi László--

Thanks for sorting out the 3.3-1 upload for tcplay, multiarch-ifying
library along the way, and updating the packaging history in Salsa, too!

With much appreciation,

 --dkg


signature.asc
Description: PGP signature

Bug#1067474: gxr-openvr: package Build-Depends on libgxr-0.15-0 whic is no longer built

[Andreas Beckmann]

Followup-For: Bug #1067474
Control: tag -1 pending

Hi,

I've just uploaded a NMU (diff attached) to DELAYED/2 fixing this issue,
a followup issue (from Ubuntu) and cleaning up some cruft.
Please let me know if I should delay it longer.

Andreas

PS: the Vcs-* variables point to the repository of a different package.
You probably need to append '-b debian/master-openvr' (if that is the
correct branch) to Vcs-Git.
diff -Nru gxr-openvr-0.15.1/debian/changelog gxr-openvr-0.15.1/debian/changelog
--- gxr-openvr-0.15.1/debian/changelog  2020-08-08 07:22:29.0 +0200
+++ gxr-openvr-0.15.1/debian/changelog  2024-04-26 20:00:15.0 +0200
@@ -1,3 +1,19 @@
+gxr-openvr (0.15.1-2.1) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Fix building twice in a row.
+  * Switch B-D from pkg-config to pkgconf.
+
+  [ Michael Hudson-Doyle ]
+  * s/libgxr-0.15-0/libgxr-dev/ in Build-Depends.  (Closes: #1067474)
+
+  [ Julian Andres Klode ]
+  * Remove libgxr-0.15-0, libsdl-2.0-0 depends. They are taken care of by
+shlibs and break time_t.
+
+ -- Andreas Beckmann   Fri, 26 Apr 2024 20:00:15 +0200
+
 gxr-openvr (0.15.1-2) unstable; urgency=medium
 
   * Source only upload.
diff -Nru gxr-openvr-0.15.1/debian/clean gxr-openvr-0.15.1/debian/clean
--- gxr-openvr-0.15.1/debian/clean  1970-01-01 01:00:00.0 +0100
+++ gxr-openvr-0.15.1/debian/clean  2024-04-26 19:36:45.0 +0200
@@ -0,0 +1,2 @@
+build/
+examples/cube/shaders/*.spv
diff -Nru gxr-openvr-0.15.1/debian/control gxr-openvr-0.15.1/debian/control
--- gxr-openvr-0.15.1/debian/control2020-08-08 07:22:12.0 +0200
+++ gxr-openvr-0.15.1/debian/control2024-04-26 19:58:51.0 +0200
@@ -11,25 +11,22 @@
  gtk-doc-tools,
  libgtk-3-dev (>= 3.22),
  libgulkan-dev (>= 0.15.0),
- libgxr-0.15-0,
+ libgxr-dev,
  libjson-glib-dev,
  libopenvr-dev,
  mesa-common-dev,
  meson (>= 0.45.1),
- pkg-config,
+ pkgconf,
 Standards-Version: 4.5.0
 Homepage: https://gitlab.freedesktop.org/xrdesktop/gxr
 Vcs-Browser: https://salsa.debian.org/xrdesktop-team/gxr
 Vcs-Git: https://salsa.debian.org/xrdesktop-team/gxr.git
 
 Package: libgxr-openvr-0.15-0
-Section: contrib/libs
 Architecture: linux-any
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
- libgxr-0.15-0,
- libsdl2-2.0-0,
 Breaks: libgxr-0.14-0 (<< 0.15)
 Replaces: libgxr-0.14-0 (<< 0.15)
 Description: gxr backend for nonfree OpenVR libraries
diff -Nru gxr-openvr-0.15.1/debian/rules gxr-openvr-0.15.1/debian/rules
--- gxr-openvr-0.15.1/debian/rules  2020-08-08 07:22:12.0 +0200
+++ gxr-openvr-0.15.1/debian/rules  2024-04-26 19:55:16.0 +0200
@@ -25,4 +25,3 @@
env $(test_env) meson build
env $(test_env) ninja -C build
env $(test_env) meson test -C build/ --no-suite gxr:xr --no-suite 
post-install
-

Bug#1069756: readability: build time test error: lxml.html.clean module is now a separate project lxml_html_clean

[Étienne Mollier]

Hi Colin,

Colin Watson, on 2024-04-26:
> Based on https://github.com/buriy/python-readability/issues/179, it
> looks as though upstream intends to switch to bleach; I think we can
> just patch setup.py in Debian in the meantime though.  I'll do that.

Looks good to me, thanks for tackling this!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Saga - Give 'Em The Money


signature.asc
Description: PGP signature

Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x

[Andreas Beckmann]

On 26/04/2024 18.54, Dirk Lehmann wrote:

No, I am currently don't have `gnutls-bin` installed. Just `gnutls-bin` and the 
sources are versioned to 3.8.5-2.


That was the most plausible package depending on libgnutls-dane0 ...


In sid and testing the binary packages `libgnutls30` and `libgnutls-dane0` are 
consistent versioned to 3.8.3-1 here.

Can you confirm that the binaries of the libs are versioned to `3.8.5-2` on 
your side?


Yes. sid may have some cruft 3.8.3-1 packages (with the old library package 
names)
sitting around until everything depending on them is gone from sid. But such
packages should have been removed from testing already (except armel/armhf,
where this will happen soon)

$ rmadison -s sid,testing libgnutls-dane0 libgnutls-dane0t64 libgnutls30 
libgnutls30t64
libgnutls-dane0| 3.8.3-1   | testing| armel, armhf
libgnutls-dane0| 3.8.3-1   | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, riscv64, s390x
libgnutls-dane0t64 | 3.8.5-2   | testing| amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, s390x
libgnutls-dane0t64 | 3.8.5-2   | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, riscv64, s390x
libgnutls30| 3.8.3-1   | testing| armel, armhf
libgnutls30| 3.8.3-1   | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, riscv64, s390x
libgnutls30t64 | 3.8.5-2   | testing| amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, s390x
libgnutls30t64 | 3.8.5-2   | unstable   | amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, riscv64, s390x


Yes, thanks that works, I used
$> apt-get install libgnutls-dane0t64


Does dist-upgrade work again now?

Andreas

Bug#1069899: lvm2: do not copy SELinux contexts in initramfs hook

[Christian Göttsche]

Package: lvm2
Version: 2.03.22-1
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux
Tags: patch

Dear Maintainer,

when copying files into the temporary initramfs working directory the
SELinux security contexts are copied verbatim.
This can lead to issue when the original context is not allowed on the
destination filesystem and the process needs elevated access to the
original context.

See 
https://salsa.debian.org/debian/plymouth/-/commit/3edb1985b586b8362ef206c894ba6926f96e2e5f
for a similar situation in plymouth.
See https://salsa.debian.org/lvm-team/lvm2/-/merge_requests/3 for a
salsa merge request.

Regards,
   Christian Göttsche

diff --git a/debian/initramfs-tools/lvm2/hooks/lvm2
b/debian/initramfs-tools/lvm2/hooks/lvm2
index b28901a01..46a01b615 100755
--- a/debian/initramfs-tools/lvm2/hooks/lvm2
+++ b/debian/initramfs-tools/lvm2/hooks/lvm2
@@ -16,7 +16,7 @@ esac

. /usr/share/initramfs-tools/hook-functions

-cp -a /etc/lvm/ ${DESTDIR}/etc/lvm/
+cp -dRp /etc/lvm/ ${DESTDIR}/etc/lvm/

mkdir -p $DESTDIR/lib/udev/rules.d/
for rules in 56-lvm.rules 69-lvm.rules; do

Bug#1069898: mariadb-server: Command History is shared for all users

[Thomas Schlegel]

Package: mariadb-server
Version: 1:10.11.6-0+deb12u1
Severity: important
X-Debbugs-Cc: thomas.schle...@posteo.de

Dear Maintainer,

on a link via socket between Client and Server there is only one history of 
Commands.

Especially the root history is seen by normal user.

Thomas Schlegel

Bug#747303: openssh-server: Please move pam_selinux open call higher in the session PAM stack

[Christian Göttsche]

Kindly ping.

Anything missing or unclear?

Regards,
   Christian Göttsche

Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels

[Samuel Thibault]

Control: forcemerge -1 816111

Hello,

T. Joseph Carter, le mer. 24 avril 2024 13:25:22 -0700, a ecrit:
> Linux kernel 6.9+ will support larger font sizes for HiDPI screens. This
> is probably aimed at "more than 4k" monitors, but for accessibility
> reasons it would be really useful to have larger sizes available sooner
> for those of us already have 4k sorts of screens.

Yes, that was the points in adding the support in the kernel :)

> Perhaps this might best be done by putting those huge-sized fonts in an
> appropriately named -huge fonts package? I'll leave the implementation
> details to you, this is just a request for the fonts to be created.

We already had the request in #816111, also #595696 was about possibly
generalizing to using rasterized fonts.

I gave a try at converting terminus.ttf to bdf with otf2bdf:

otf2bdf -c C -p 32 -r 72 
/usr/share/fonts/truetype/terminus/TerminusTTF-4.46.0.ttf > /tmp/terminus.bdf
bdf2psf --fb  /tmp/terminus.bdf /usr/share/bdf2psf/standard.equivalents 
ascii.set 256   /tmp/terminus.psf /tmp/terminus.sfm

but the baseline is not coherent. Using DejaVuSansMono seems to be
working better:

otf2bdf -c C -p 32 -r 100 /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf > 
/tmp/DejaVuSansMono.bdf
bdf2psf --fb --width 32 /tmp/DejaVuSansMono.bdf 
/usr/share/bdf2psf/standard.equivalents ascii.set 256 /tmp/DejaVuSansMono.psf 
/tmp/DejaVuSansMono.sfm

(I'm adding a new --width parameter to bdf2psf to specify the expected
width since AVERAGE_WIDTH as set by otf2bdf doesn't really tell)

Samuel

Bug#1021924: networking-mlnx: FTBFS test failures: sqlalchemy.exc.InvalidRequestError: A transaction is already begun on this Session.

[Santiago Vila]

El 17/10/22 a las 14:04, Michael Biebl escribió:

Source: networking-mlnx
Version: 1:16.0.0-3
Severity: serious
Tags: ftbfs

networking-mlnx FTBFS in unstable

It appears to be trigger lots of test suite failures and is killed
eventually


I think it's even worse than that: The test suite seems to enter an endless 
loop,
producing a bigger and bigger build log, and the build needs to be killed by 
hand
because otherwise the build log would take all available disk space.

The last log I got grew to 6 GB until I decided to kill it:

-rw-r--r-- 1 master master 6002644863 abr 26 14:40 
networking-mlnx_16.0.0-3.1_amd64-20240426T144020.998Z

No surprise that the state of this package in Reproducible Builds is "banned":

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/networking-mlnx.html

For such reason, I believe this package should be removed from unstable and
uploaded to experimental instead, at the very minimum.

Cc:ing all relevant parties.

Thanks.

Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x

[Dirk Lehmann]

26.04.2024 17:51:42 Andreas Beckmann :

> On 26/04/2024 16.51, Dirk Lehmann wrote:
>> The following packages have unmet dependencies:
>>  libgnutls-dane0 : Depends: libgnutls30 (= 3.8.3-1)
>> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused 
>> by held packages.
>
> Do you have any packages on "hold" (apt-mark showhold)?
>
> What does
>
>     apt-cache policy gnutls-bin
>
> report?
> If that reports something older than
>
>     Candidate: 3.8.5-2
>
> your mirror is not up-to-date.
>
> Otherwise upgrading to that package
>
> Package: gnutls-bin
> Version: 3.8.5-2
> ...
> Depends: libc6 (>= 2.34), libgnutls-dane0t64 (>= 3.7.0), libgnutls30t64 (>= 
> 3.8.4-0+private+1), libtasn1-6 (>= 4.14)
> ...
>

No, I am currently don't have `gnutls-bin` installed. Just `gnutls-bin` and the 
sources are versioned to 3.8.5-2.

In sid and testing the binary packages `libgnutls30` and `libgnutls-dane0` are 
consistent versioned to 3.8.3-1 here.

Can you confirm that the binaries of the libs are versioned to `3.8.5-2` on 
your side?

> should replace libgnutls-dane0, libgnutls30 with their t64 successors.
>

Yes, thanks that works, I used

```
$> apt-get install libgnutls-dane0t64
```

Bug#1064528: fish: loss of rendering (color) difference between valid and broken symbolic links

[Patrice Duroux]

Control: close 1064528

I found that this is the `ls --color=auto` default behavior without any
LS_COLORS value.
There is a default .bashrc (see /etc/skel/.bashrc) that sets and exports
LS_COLORS so it confused me during tests then fish was a sub-shell or a login
shell.


 

Bug#1069835: needs a fix in KIO as well

[Rene Engelhard]

Hi,

Am 26.04.24 um 10:02 schrieb Sune Stolborg Vuorela:

https://invent.kde.org/frameworks/kio/-/commit/
45b306dc0653fa42672e8a49afe8f42d24585ed4

is also needed for it to work.


Thanks for mentioning this.


As talked about on IRC this morning, that commit is only for kf6s kio.

So unless that one is backported to kf5 we'd get the fix then if we 
shipped libreoffice-kf6 and KF6/Plasma6 is what is used.


(According to IRC it isn't sure whether this will be backported to kf5. 
Let's see)



Regards,


Rene

Bug#1068174: Debian FPGA toolchain update and testing

[Philipp Klaus Krause]

Am 25.04.24 um 13:14 schrieb Daniel Gröber:

On Tue, Apr 23, 2024 at 01:40:48PM +0200, Philipp Klaus Krause wrote:

I have done a quick test of the latest upstream release, yosys 0.40 on
my Debian GNU/Linux (mixture of testing and unstable) amd64 system.


All sounds good. I'll be at mini DebConf Berlin in a couple of weeks and
I'll be working on this stuff there. Would be good if you have some time
while that's going on (14-21th May) to do testing.


So far, it looks like I can do that.

Philipp

P.S.: I now did a quick test of yosys on amd64 (looks good) and ppc64
(looks bad - https://github.com/YosysHQ/yosys/issues/4358
https://github.com/YosysHQ/yosys/issues/2645).

Bug#1069844: More debug info

[Alex Bennée]

On Fri, 26 Apr 2024 at 16:48, Julian Andres Klode <
julian.kl...@canonical.com> wrote:

> On Thu, Apr 25, 2024 at 09:10:08PM +0100, Alex Bennée wrote:
> > Alex Bennée  writes:
> >
> > > Julian Andres Klode  writes:
> > >
> > >> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
> > >>>
> > >>> Continuing to debug on QEMU it seems there is an incompatibility with
> > >>> the images and the peloader (which overrides the normal efi loader):
> > >>>
> > 
> > >
> > >> In the error case you can see though, that one of the section
> > >> addresses in the Xen binary to be relocated points into the (PE)
> > >> header of the binary, which obviously seems wrong.
> > >>
> > >> So go check your PE sections and check which one is wrong?
> > >
> > > Is there any tooling for examining PE sections?
> >
> > Nothing really jumps out from objdump:
> >
> > 1:08:50 [root@debian-arm64:~] # objdump -h /boot/xen
> >
> >   /boot/xen: file format pei-aarch64-little
> >
> >   Sections:
> >   Idx Name  Size  VMA   LMA   File
> off  Algn
> > 0 .reloc    
>   2**0
> > ALLOC, LOAD, READONLY, DATA
>
>
> This looks suspicious. Yes it's 0 size but it's address is 0 which
> clearly points into the header, and we don't skip 0 size sections when
> loading the PE binary for later relocation, and we don't use any .reloc
> section.
>

It does get skipped in the reloc code:

  if (!info->reloc || !(info->reloc->size))
{
  grub_dprintf ("linux", "no relocations\n");
  return GRUB_EFI_SUCCESS;
}

Although the x86_64 build of Xen uses reloc sections (which Xen itself
deals with) we don't actually need them for Arm. However the way the PE
binary is built is a little funky:

make

  UPD include/xen/compile.h


 Xen 4.19-unstable

make[1]: Nothing to be done for 'include'.

make[1]: 'arch/arm/include/asm/asm-offsets.h' is up to date.

  CC  common/version.o

  LD  common/built_in.o

  CC  arch/arm/acpi/domain_build.o

  INIT_O  arch/arm/acpi/domain_build.init.o


  LD  arch/arm/acpi/built_in.o

  CC  arch/arm/domain_build.o

  INIT_O  arch/arm/domain_build.init.o

  CC  arch/arm/efi/boot.o

  INIT_O  arch/arm/efi/boot.init.o

  LD  arch/arm/efi/built_in.o

  CC  arch/arm/setup.o


  LD  arch/arm/built_in.o

  LD  prelink.o

ld-EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o \

./common/symbols-dummy.o -o ./.xen-syms.0

nm -pa --format=sysv ./.xen-syms.0 \

| ./tools/symbols  --sysv --sort \

> ./.xen-syms.0.S

make -f ./Rules.mk obj=. ./.xen-syms.0.o

  CC  .xen-syms.0.o

ld-EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o \
./.xen-syms.0.o -o ./.xen-syms.1

nm -pa --format=sysv ./.xen-syms.1 \

| ./tools/symbols  --sysv --sort \


> ./.xen-syms.1.S

make -f ./Rules.mk obj=. ./.xen-syms.1.o


  CC  .xen-syms.1.o

ld-EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o --build-id=sha1 \
./.xen-syms.1.o -o xen-syms

nm -pa --format=sysv xen-syms \

| ./tools/symbols --all-symbols --xensyms --sysv --sort \

> xen-syms.map

rm -f ./.xen-syms.[0-9]*

objcopy -O binary -S xen-syms xen

ln -sf xen xen.efi

I can't work out how to build without the reloc section and trying to
remove the .reloc section after the fact results in something where the
file-offset is ahead of the VMA position:

➜  objcopy --remove-section=.reloc -O binary -S xen-syms xen-test

17:03:23 alex@gwenyn:xen.git/xen  on  testing/new-attempt:new-attempt
[!?]
➜  objdump -h xen-test




xen-test: file format pei-aarch64-little



Sections:


Idx Name  Size  VMA   LMA   File off
 Algn
  0 .reloc      
 2**0

  ALLOC, LOAD, READONLY, DATA

  1 .text 00127ea8  0160  0160  0160
 2**4

  CONTENTS, ALLOC, LOAD, CODE

17:03:25 alex@gwenyn:xen.git/xen  on  testing/new-attempt:new-attempt
[!?]
➜  objcopy --remove-section=.reloc xen-test


17:03:37 alex@gwenyn:xen.git/xen  on  testing/new-attempt:new-attempt
[!?]
➜  objdump -h xen-test



xen-test: file format pei-aarch64-little



Sections:

Idx Name  Size  VMA   LMA   File off
 Algn

  0 .text 00127ea8  0160  0160  01b0
 2**2
  CONTENTS, ALLOC, LOAD, CODE



>
> > 1 .text 00107ea8  0160  0160
> 0160  2**4
> > CONTENTS, ALLOC, LOAD, CODE
> >   21:08:53 [root@debian-arm64:~] # objdump -h /boot/vmlinuz
>
>
> I suppose the header is smaller than 0x160 bytes and this is ok.
>
> My colleague Heinrich has written a nice PE analyser tool too:
>
> 

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Russ Allbery]

Lukas Grässlin  writes:

> It's ldapsearch in all cases with libsasl2-modules-gssapi-mit:amd64
> 2.1.28+dfsg-10 on Debian and cyrus-sasl-gssapi-2.1.27-6.el8_5.x86_64 on
> the RHEL machine.

I suspect you are being bitten by:

https://web.mit.edu/Kerberos/krb5-devel/doc/admin/princ_dns.html#openldap-ldapsearch-etc

(at the bottom of the page), which is not under the control of the
Kerberos libraries.  It's a very long-standing issue in Cyrus SASL that
some of us used to patch locally.

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

Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x

[Andreas Beckmann]

On 26/04/2024 16.51, Dirk Lehmann wrote:

The following packages have unmet dependencies:
  libgnutls-dane0 : Depends: libgnutls30 (= 3.8.3-1)
E: Error, pkgProblemResolver::Resolve generated breaks, this may be 
caused by held packages.


Do you have any packages on "hold" (apt-mark showhold)?

What does

apt-cache policy gnutls-bin

report?
If that reports something older than

Candidate: 3.8.5-2

your mirror is not up-to-date.

Otherwise upgrading to that package

Package: gnutls-bin
Version: 3.8.5-2
...
Depends: libc6 (>= 2.34), libgnutls-dane0t64 (>= 3.7.0), libgnutls30t64 
(>= 3.8.4-0+private+1), libtasn1-6 (>= 4.14)

...

should replace libgnutls-dane0, libgnutls30 with their t64 successors.

Andreas

Bug#1069844: More debug info

[Julian Andres Klode]

On Thu, Apr 25, 2024 at 09:10:08PM +0100, Alex Bennée wrote:
> Alex Bennée  writes:
> 
> > Julian Andres Klode  writes:
> >
> >> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
> >>> 
> >>> Continuing to debug on QEMU it seems there is an incompatibility with
> >>> the images and the peloader (which overrides the normal efi loader):
> >>> 
> 
> >
> >> In the error case you can see though, that one of the section
> >> addresses in the Xen binary to be relocated points into the (PE)
> >> header of the binary, which obviously seems wrong.
> >>
> >> So go check your PE sections and check which one is wrong?
> >
> > Is there any tooling for examining PE sections?
> 
> Nothing really jumps out from objdump:
> 
> 1:08:50 [root@debian-arm64:~] # objdump -h /boot/xen
> 
>   /boot/xen: file format pei-aarch64-little
> 
>   Sections:
>   Idx Name  Size  VMA   LMA   File off  
> Algn
> 0 .reloc        
> 2**0
> ALLOC, LOAD, READONLY, DATA


This looks suspicious. Yes it's 0 size but it's address is 0 which
clearly points into the header, and we don't skip 0 size sections when
loading the PE binary for later relocation, and we don't use any .reloc
section.


> 1 .text 00107ea8  0160  0160  0160  
> 2**4
> CONTENTS, ALLOC, LOAD, CODE
>   21:08:53 [root@debian-arm64:~] # objdump -h /boot/vmlinuz


I suppose the header is smaller than 0x160 bytes and this is ok.

My colleague Heinrich has written a nice PE analyser tool too:

https://github.com/xypron/efi_analyzer


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1069897: Netcfg to get search domain

[Frédéric Guyot]

Package: netcfg
Version: 1.187

As explained in this thread:
https://lists.debian.org/debian-boot/2024/04/msg00061.html , netcfg
doesn't read the search domain property sent by dhcp to make it
available to udhcpc and fill /etc/resolv.conf + lease file properly.
This setup doesn't work in an environment where you have multiple
search domains and it's getting even more complicated if your network
mirror is on one of those search domains that is different from
$domain.

A commit as already been made for the udhcpc script here:
https://salsa.debian.org/installer-team/busybox/-/commit/bd0d90574a4e39b39d38b664ad15ac0c2ca1bbad
We now just need to update netcfg package to make $search available to udhcpc.

A proposed solution would be to update this line
(https://salsa.debian.org/installer-team/netcfg/-/blob/master/dhcp.c#L38)
as follow:

const char* dhclient_request_options_udhcpc[] = { "subnet",
"broadcast", "router", "domain", "hostname", "dns", "search",
"ntpsrv", /* extra */ NULL };

Thanks

Bug#1069896: python3-tqdm: internal version is wrongly reported as 0.0.0

[Michael R. Crusoe]

Package: python3-tqdm
Version: 4.66.2-1
Severity: normal
Tags: patch
X-Debbugs-Cc: cru...@debian.org

Dear Maintainer,

I noticed that your package doesn't know its own version number, due to 
upstream using setuptools-scm:

> /usr/lib/python3.12/dist-packages/tqdm-0.0.0.dist-info/INSTALLER
> /usr/lib/python3.12/dist-packages/tqdm-0.0.0.dist-info/top_level.txt

https://packages.debian.org/trixie/all/python3-tqdm/filelist

Attached is a patch to fix this.
commit 57f42a5693cb8fd1c0f80a0f605396d18ae24a0c
Author: Michael R. Crusoe 
Date:   Fri Apr 26 17:35:10 2024 +0200

d/watch: switch to PyPI to grab the _version file. Fixes "0.0.0" version reporting.

diff --git a/debian/control b/debian/control
index 8738979..24c5b98 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,7 @@ Build-Depends:
  python3-pytest-timeout ,
  python3-rich ,
  python3-setuptools,
+ python3-setuptools-scm,
  python3-tk ,
 Rules-Requires-Root: no
 Standards-Version: 4.7.0


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069895: mariadb-server: InnoDB to hang on systems with very intensive write loads when running out of I/O slots. This problem is fixed with MariaDB Server 10.11.7. Can it be put in stable?

[Ben Bewick]

Package: mariadb-server
Version: 1:10.11.6-0+deb12u1
Severity: important
Tags: upstream
X-Debbugs-Cc: deb...@viperfang.net, t...@security.debian.org

Dear Maintainer,

   * What led up to the situation?
Running nextcloud plugin that imports a country database for reverse geocoding 
(Memories app)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Waited for it to complete, but php reports the server has gone away, journalctl 
shows its crashing.
   * What was the outcome of this action?
MariaDB Crashed
   * What outcome did you expect instead?
MariaDB to not crash.

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

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

Versions of packages mariadb-server depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  galera-4   26.4.13-1
ii  gawk   1:5.2.1-2
ii  iproute2   6.1.0-3
ii  libc6  2.36-9+deb12u6
ii  libdbi-perl1.643-4
ii  libpam0g   1.5.2-6+deb12u1
ii  libssl33.0.11-1~deb12u2
ii  libstdc++6 12.2.0-14
ii  lsof   4.95.0-1
ii  mariadb-client 1:10.11.6-0+deb12u1
ii  mariadb-common 1:10.11.6-0+deb12u1
ii  mariadb-server-core1:10.11.6-0+deb12u1
ii  passwd 1:4.13+dfsg1-1+b1
ii  perl   5.36.0-7+deb12u1
ii  procps 2:4.0.2-3
ii  psmisc 23.6-1
ii  rsync  3.2.7-1
ii  socat  1.7.4.4-2
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages mariadb-server recommends:
ii  libhtml-template-perl   2.97-2
ii  mariadb-plugin-provider-bzip2   1:10.11.6-0+deb12u1
ii  mariadb-plugin-provider-lz4 1:10.11.6-0+deb12u1
ii  mariadb-plugin-provider-lzma1:10.11.6-0+deb12u1
ii  mariadb-plugin-provider-lzo 1:10.11.6-0+deb12u1
ii  mariadb-plugin-provider-snappy  1:10.11.6-0+deb12u1
ii  pv  1.6.20-1

Versions of packages mariadb-server suggests:
pn  mailx   
pn  mariadb-test
pn  netcat-openbsd  

-- debconf information:
  mariadb-server/nis_warning:
  mariadb-server/old_data_directory_saved:
  mariadb-server/postrm_remove_databases: false

Bug#1069756: readability: build time test error: lxml.html.clean module is now a separate project lxml_html_clean

[Colin Watson]

On Wed, Apr 24, 2024 at 11:16:17AM +0200, Étienne Mollier wrote:
> As far as I could witness, replacing the python3-lxml build
> dependency by python3-lxml-html-clean resolved the issue at
> least for the bulid time test.  The package is subject to
> autodep8 python3 test, which raises that the binary package will
> also need it dependencies adjusted; this suggests the setup.py
> would probably need patching so this is addressed appropriately
> at a larger scale than Debian's.

Based on https://github.com/buriy/python-readability/issues/179, it
looks as though upstream intends to switch to bleach; I think we can
just patch setup.py in Debian in the meantime though.  I'll do that.

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

Bug#1065810: Correction: New appointments for the Debian Technical Committee: csmall

[Andreas Tille]

Dear fellow developers,

sorry, the list of CTTE members in my last mail contained
   Simon McVittie 
but his term has ended already.  Thanks to Simon for his previous work
and here comes the corrected text (with no change but the correct list
of members).

As defined by our constitution (§6.2.2), the Debian Technical Committee
has recommended the appointment to the committee of:

  * Craig Small 

I agree with their recommendation, and hereby appoint Craig as member of
the Technical Committee, effective immediately.

For reference, the nominations and votes are recorded at:

https://bugs.debian.org/1065810

The Technical Committee now consists of:

  * Sean Whitton  (chair)
  * Christoph Berg 
  * Helmut Grohne 
  * Matthew Vernon 
  * Matthew Garrett 
  * Stefano Rivera 
  * Timo Röhling 
  * Craig Small 

Task Description:

The Technical Committee is established by the Debian Constitution,
section 6. It is the body which makes the final decision on technical
disputes in the Debian project.

More info about the Technical Committee, including recent decisions,
discussion and advice, may be found at:

https://www.debian.org/devel/tech-ctte

The previous CTTE Appointment mail can be found at:

https://lists.debian.org/debian-devel-announce/2023/07/msg0.html

Thanks to everyone on the committee who dedicate their time and skills
towards Debian as well as good luck for Craig for the new position!

  Andreas, Debian Project Leader



signature.asc
Description: PGP signature

Bug#1066357: ldapvi: diff for NMU version 1.7-11

[Boyuan Yang]

Control: tags 1066357 + patch
Control: tags 1066357 + pending

Dear maintainer,

I've prepared an NMU for ldapvi (versioned as 1.7-11) and
uploaded it to DELAYED/0. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ldapvi-1.7/debian/changelog ldapvi-1.7/debian/changelog
--- ldapvi-1.7/debian/changelog 2016-01-12 16:14:50.0 -0500
+++ ldapvi-1.7/debian/changelog 2024-04-26 11:15:30.0 -0400
@@ -1,3 +1,13 @@
+ldapvi (1.7-11) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Avoid using transitional package names.
+  * debian/control: Add missing dependency sensible-utils (lintian).
+  * debian/patches/07,08: Add patch to fix FTBFS caused by
+Werror=implicit-function-declaration. (Closes: #1066357)
+
+ -- Boyuan Yang   Fri, 26 Apr 2024 11:15:30 -0400
+
 ldapvi (1.7-10) unstable; urgency=medium
 
   * Update my name/email address.
diff -Nru ldapvi-1.7/debian/control ldapvi-1.7/debian/control
--- ldapvi-1.7/debian/control   2016-01-12 10:36:14.0 -0500
+++ ldapvi-1.7/debian/control   2024-04-26 11:15:15.0 -0400
@@ -2,13 +2,13 @@
 Section: text
 Priority: optional
 Maintainer: Rhonda D'Vine 
-Build-Depends: debhelper (>= 9~), libldap2-dev, libglib2.0-dev, libpopt-
dev, libncurses5-dev, libsasl2-dev, libreadline-dev, xsltproc
+Build-Depends: debhelper (>= 9~), libldap-dev, libglib2.0-dev, libpopt-
dev, libncurses-dev, libsasl2-dev, libreadline-dev, xsltproc
 Standards-Version: 3.9.6
 Homepage: http://www.lichteblau.com/ldapvi/
 
 Package: ldapvi
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, sensible-utils
 Description: perform an LDAP search and update results using a text
editor
  From a first glance ldapvi looks like ldapsearch: You search for
entries in
  the ldap database. But the results get opened in your preferred editor,
and
diff -Nru ldapvi-1.7/debian/patches/07_diff.c-Use-public-interface-
ldap_bv2dn-instead-of-ld.patch ldapvi-1.7/debian/patches/07_diff.c-Use-
public-interface-ldap_bv2dn-instead-of-ld.patch
--- ldapvi-1.7/debian/patches/07_diff.c-Use-public-interface-ldap_bv2dn-
instead-of-ld.patch 1969-12-31 19:00:00.0 -0500
+++ ldapvi-1.7/debian/patches/07_diff.c-Use-public-interface-ldap_bv2dn-
instead-of-ld.patch 2024-04-26 11:13:02.0 -0400
@@ -0,0 +1,28 @@
+From: Boyuan Yang 
+Date: Fri, 26 Apr 2024 10:41:33 -0400
+Subject: diff.c: Use public interface ldap_bv2dn instead of ldap_bv2dn_x
+
+The current openldap ldap_bv2dn_x() function is a private
implementation.
+The public interface ldap_bv2dn() share almost the same function
parameters
+except for the context. As a result, it is safe to use the public
interface
+as a replacement. This solves the FTBFS caused by
+-Werror=implicit-function-declaration.
+
+Bug-Debian: https://bugs.debian.org/1066357
+---
+ diff.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/diff.c b/diff.c
+index bb000fc..4596662 100644
+--- a/diff.c
 b/diff.c
+@@ -215,7 +215,7 @@ safe_str2dn(char *str, LDAPDN *out, int flags)
+ struct berval bv;
+ bv.bv_val = str;
+ bv.bv_len = strlen(str);
+-ldap_bv2dn_x(, out, flags);
++ldap_bv2dn(, out, flags);
+ }
+ #else
+ #error oops
diff -Nru ldapvi-1.7/debian/patches/08_ftbfs-implicit-function-
declaration.patch ldapvi-1.7/debian/patches/08_ftbfs-implicit-function-
declaration.patch
--- ldapvi-1.7/debian/patches/08_ftbfs-implicit-function-
declaration.patch   1969-12-31 19:00:00.0 -0500
+++ ldapvi-1.7/debian/patches/08_ftbfs-implicit-function-
declaration.patch   2024-04-26 11:15:30.0 -0400
@@ -0,0 +1,70 @@
+From: Boyuan Yang 
+Date: Fri, 26 Apr 2024 10:51:32 -0400
+Subject: Fix ftbfs implicit function declaration
+
+Also include common.h for error.c for definition of error.c. Needed
+for deprecated LDAP function of ldap_perror.
+
+Bug-Debian: https://bugs.debian.org/1066357
+---
+ common.h| 1 +
+ error.c | 3 +++
+ parse.c | 3 +++
+ parseldif.c | 2 ++
+ 4 files changed, 9 insertions(+)
+
+diff --git a/common.h b/common.h
+index f731e62..714b112 100644
+--- a/common.h
 b/common.h
+@@ -282,6 +282,7 @@ int adjoin_str(GPtrArray *, char *);
+ int adjoin_ptr(GPtrArray *, void *);
+ void init_dialog(tdialog *, enum dialog_mode, char *, char *);
+ void dialog(char *header, tdialog *, int, int);
++void fdcp(int fdsrc, int fddst);
+ 
+ /*
+  * schema.c
+diff --git a/error.c b/error.c
+index 5924868..345a2bf 100644
+--- a/error.c
 b/error.c
+@@ -14,6 +14,9 @@
+  * along with this program; if not, write to the Free Software
+  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
USA
+  */
++
++#include "common.h"
++
+ #include 
+ #include 
+ #include 
+diff --git a/parse.c b/parse.c
+index e171f53..0c6b0ec 100644
+--- a/parse.c
 b/parse.c
+@@ -16,7 +16,10 @@
+  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
USA
+  */
+ 

Bug#1069882: Acknowledgement (testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x)

[Dirk Lehmann]

Okay doing the following that fix current testing installations:

```
apt-get install libgnutls-dane0t64
Reading package lists... Done
Building dependency tree... Done
The following additional packages will be installed:
  libgnutls30t64 libhogweed6t64 libnettle8t64
Suggested packages:
  dns-root-data gnutls-bin
The following packages will be REMOVED:
  libgnutls-dane0 libgnutls30 libhogweed6 libnettle8
The following NEW packages will be installed:
  libgnutls-dane0t64 libgnutls30t64 libhogweed6t64 libnettle8t64
0 upgraded, 4 newly installed, 4 to remove and 93 not upgraded.
Need to get 2,495 kB of archives.
After this operation, 48.1 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://deb.debian.org/debian testing/main amd64 libnettle8t64 
amd64 3.9.1-2.2 [296 kB]
Get:2 https://deb.debian.org/debian testing/main amd64 libhogweed6t64 
amd64 3.9.1-2.2 [328 kB]
Get:3 https://deb.debian.org/debian testing/main amd64 
libgnutls-dane0t64 amd64 3.8.5-2 [435 kB]
Get:4 https://deb.debian.org/debian testing/main amd64 libgnutls30t64 
amd64 3.8.5-2 [1,437 kB]

Fetched 2,495 kB in 2s (1,577 kB/s)
dpkg: libhogweed6:amd64: dependency problems, but removing anyway as you 
requested:

 qemu-system-x86 depends on libhogweed6.
 qemu-system-common depends on libhogweed6.
 librtmp1:amd64 depends on libhogweed6.
 libgnutls30:amd64 depends on libhogweed6 (>= 3.6).

(Reading database ... 237486 files and directories currently installed.)
Removing libhogweed6:amd64 (3.9.1-2+b1) ...
dpkg: libnettle8:amd64: dependency problems, but removing anyway as you 
requested:

 wget depends on libnettle8.
 qemu-system-x86 depends on libnettle8.
 qemu-system-common depends on libnettle8.
 libsrt1.5-gnutls:amd64 depends on libnettle8.
 librtmp1:amd64 depends on libnettle8.
 libgnutls30:amd64 depends on libnettle8 (>= 3.9~).
 libcurl3-gnutls:amd64 depends on libnettle8.
 libarchive13:amd64 depends on libnettle8.

Removing libnettle8:amd64 (3.9.1-2+b1) ...
Selecting previously unselected package libnettle8t64:amd64.
(Reading database ... 237470 files and directories currently installed.)
Preparing to unpack .../libnettle8t64_3.9.1-2.2_amd64.deb ...
Unpacking libnettle8t64:amd64 (3.9.1-2.2) ...
Selecting previously unselected package libhogweed6t64:amd64.
Preparing to unpack .../libhogweed6t64_3.9.1-2.2_amd64.deb ...
Unpacking libhogweed6t64:amd64 (3.9.1-2.2) ...
dpkg: libgnutls-dane0:amd64: dependency problems, but removing anyway as 
you requested:

 exim4-daemon-light depends on libgnutls-dane0 (>= 3.7.0).

(Reading database ... 237486 files and directories currently installed.)
Removing libgnutls-dane0:amd64 (3.8.3-1) ...
Selecting previously unselected package libgnutls-dane0t64:amd64.
(Reading database ... 237480 files and directories currently installed.)
Preparing to unpack .../libgnutls-dane0t64_3.8.5-2_amd64.deb ...
Unpacking libgnutls-dane0t64:amd64 (3.8.5-2) ...
dpkg: libgnutls30:amd64: dependency problems, but removing anyway as you 
requested:

 xfce4-mailwatch-plugin depends on libgnutls30 (>= 3.8.1).
 wget depends on libgnutls30 (>= 3.8.1).
 sane-airscan depends on libgnutls30 (>= 3.7.5).
 qemu-system-x86 depends on libgnutls30 (>= 3.8.2).
 qemu-system-common depends on libgnutls30 (>= 3.8.2).
 ntfs-3g depends on libgnutls30 (>= 3.7.2).
 network-manager depends on libgnutls30 (>= 3.7.2).
 lynx depends on libgnutls30 (>= 3.8.2).
 libvte-2.91-0:amd64 depends on libgnutls30 (>= 3.7.2).
 libsrt1.5-gnutls:amd64 depends on libgnutls30 (>= 3.7.0).
 librtmp1:amd64 depends on libgnutls30 (>= 3.6.14).
 libqpdf29:amd64 depends on libgnutls30 (>= 3.8.2).
 libnm0:amd64 depends on libgnutls30 (>= 3.7.2).
 libldap-2.5-0:amd64 depends on libgnutls30 (>= 3.8.2).
 libcurl3-gnutls:amd64 depends on libgnutls30 (>= 3.8.2).
 libcups2:amd64 depends on libgnutls30 (>= 3.8.1).
 libcamera0.2:amd64 depends on libgnutls30 (>= 3.7.3).
 libavformat60:amd64 depends on libgnutls30 (>= 3.8.1).
 glib-networking:amd64 depends on libgnutls30 (>= 3.8.1).
 exim4-daemon-light depends on libgnutls30 (>= 3.8.2).
 emacs-gtk depends on libgnutls30 (>= 3.8.2).
 dirmngr depends on libgnutls30 (>= 3.8.1).
 apt depends on libgnutls30 (>= 3.8.1).

(Reading database ... 237487 files and directories currently installed.)
Removing libgnutls30:amd64 (3.8.3-1) ...
Selecting previously unselected package libgnutls30t64:amd64.
(Reading database ... 237459 files and directories currently installed.)
Preparing to unpack .../libgnutls30t64_3.8.5-2_amd64.deb ...
Unpacking libgnutls30t64:amd64 (3.8.5-2) ...
Setting up libnettle8t64:amd64 (3.9.1-2.2) ...
Setting up libhogweed6t64:amd64 (3.9.1-2.2) ...
Setting up libgnutls30t64:amd64 (3.8.5-2) ...
Setting up libgnutls-dane0t64:amd64 (3.8.5-2) ...
Processing triggers for libc-bin (2.37-18) ...
```

A Meta-package would be a better solution.  I am out of here.

Sorry for my excitement in the last reply,
Dirk.


On 4/26/24 12:41, Dirk Lehmann wrote:
> Package: libgnutls30
> Version: 3.8.3-1
> Severity: 

Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml

[Dmitry Smirnov]

On Friday, 26 April 2024 10:33:55 PM AEST Andrey Rakhmatullin wrote:
> If the file is normally not shipped in the package then I'm fine,

Let me assure you that is exactly the case. None of my uploads have
that file. By the way, I've just uploaded new Gnucash release!  ;)


> I only
> wanted to make sure that it's easy to do NMUs for the package.

I see... Thank you for your attention and care.

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

While it is relatively easy to see that government is a bully, a thief, and
a killer, the most baneful effect of government has always been
psychological. Government convinced man that it was an absolute necessity
for human survival. ‘No matter how bad a government may be, it is better
than no government.’ No other church had a more convincing argument.
 -- Robert LeFevre, "A Way to Be Free: The Autobiography of Robert LeFevre, 
Volume I" (1999)


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

Bug#1069894: RFS: gpscorrelate/2.1-1 -- correlates digital photos with GPS data filling EXIF fields (command line)

[Shriram Ravindranathan]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : gpscorrelate
   Version  : 2.1-1
   Upstream contact : Dan Fandrich 
 * URL  : https://dfandrich.github.io/gpscorrelate/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/gpscorrelate
   Section  : graphics

The source builds the following binary packages:

  gpscorrelate - correlates digital photos with GPS data filling EXIF fields 
(command line)
  gpscorrelate-gui - correlates digital photos with GPS data filling EXIF 
fields (GUI)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gpscorrelate/gpscorrelate_2.1-1.dsc

Changes since the last upload:

 gpscorrelate (2.1-1) unstable; urgency=medium
 .
   * New upstream version 2.1
   * d/p/*:
 - Drop upstream_Adapt-to-API-type-changes-in-exiv2-0.28.0.patch:
   applied upstream
 - Add 0001-Remove-remote-image-links-from-documentation.patch
   * d/copyright:
 - Update copyright years
 - Simplify file list using wildcards
 - Remove deleted files from copyright
 - Add Upstream-Contact information
 - Add new maintainer to copyright
   * d/control:
 - Replace deprecated build-dep pkg-config with pkgconf
 - Bump Standards-Version to 4.7.0
 - Update maintainer name

Regards,
--
  Shriram Ravindranathan



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x

[Dirk Lehmann]

On 4/26/24 15:51, Andreas Beckmann wrote:

Control: reassign -1 src:gnutls28 3.8.3-1
Control: severity -1 normal
Control: tag -1 moreinfo

On Fri, 26 Apr 2024 12:41:45 +0200 Dirk Lehmann  wrote:

Package: libgnutls30
Version: 3.8.3-1



since yesterday the .deb files for the architectures
  * amd64 arm64 i386 mips64el ppc64el riscv64 s390x
on the Debian Apt mirrors are not listed/available anymore:


since they have been superseded by libgnutls30t64 for the 64-bit time_t 
transition.


In a minimal up-to-date testing chroot:

# apt-get install exim4-daemon-light
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
   cron cron-daemon-common dmsetup exim4-base exim4-config libapparmor1 
libargon2-1 libcryptsetup12 libdevmapper1.02.1 libevent-2.1-7t64 
libfdisk1 libgnutls-dane0t64 libidn12 libjson-c5 libkmod2 
libsystemd-shared libunbound8 netbase systemd systemd-dev

Suggested packages:
   anacron logrotate checksecurity supercat bat exim4-doc-html | 
exim4-doc-info eximon4 file mail-reader spf-tools-perl swaks 
dns-root-data systemd-container systemd-homed systemd-userdbd 
systemd-boot systemd-resolved libfido2-1 libip4tc2 libqrencode4
   libtss2-esys-3.0.2-0 libtss2-mu-4.0.1-0 libtss2-rc0 
libtss2-tcti-device0 polkitd

Recommended packages:
   bsd-mailx | mailx psmisc default-dbus-system-bus | dbus-system-bus 
systemd-timesyncd | time-daemon

The following NEW packages will be installed:
   cron cron-daemon-common dmsetup exim4-base exim4-config 
exim4-daemon-light libapparmor1 libargon2-1 libcryptsetup12 
libdevmapper1.02.1 libevent-2.1-7t64 libfdisk1 libgnutls-dane0t64 
libidn12 libjson-c5 libkmod2 libsystemd-shared libunbound8 netbase

   systemd systemd-dev
0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 86.0 kB/9704 kB of archives.
After this operation, 27.8 MB of additional disk space will be used.
Do you want to continue? [Y/n]

which looks fine, therefore downgrading the severity.

The t64 transition has started migrating packages to testing
  a few days ago, so maybe you experienced the failure at an unfortunate 
moment.


My current Apt output ! You have broken the whole Debian testing 
distribution!


```
$> apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgnutls-dane0 : Depends: libgnutls30 (= 3.8.3-1)
E: Error, pkgProblemResolver::Resolve generated breaks, this may be 
caused by held packages.

```

Best regards,
Dirk.

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Luca Boccassi]

On Fri, 26 Apr 2024 at 12:30, Chris Hofstaedtler  wrote:
>
> Fellow Developers,
>
> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data formats to 64bit
> times. One such instance is the set of utmp/wtmp and lastlog files.
>
> Thorsten Kukuk and others have been working on replacements for the
> existing file formats and interfaces [1]; these are called wtmpdb
> and lastlog2.
>
> Some parties have requested that we do something in Debian [2]. If
> we use Thorsten's work (and why not?), this likely means introducing
> new packages into the Priority: standard set, and changes to a few
> other packages, esp. those that handle user sessions.
>
> Thorsten's code introduces new PAM modules to manage the new files,
> so it should transparently work with most packages. Later, the
> old interfaces can probably be turned off. This seems like a good
> idea as a migration strategy to me.
> A bonus seems to be that installs not wanting these features can
> remove them - whereas today they are baked into everything.
>
>
> On the wiki [0] I have summarized what I know; a list of initial
> work items; and some open questions mostly concerned with upgrading.
>
> I invite you to read the wiki page and the background info, to
> identify gaps, to provide insights on feasability and further
> related comments.
> I'm hoping that we can build consensus on this plan.
>
> Please keep #1068017 in CC: when discussing substantial matters
> about this plan but drop it for only vaguely related sub-threads.
>
> Chris
>
>
> [0] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb
> [1] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/
> [2] https://bugs.debian.org/1068017

Would be nice to drop things that are not used, but otherwise, option
A looks good and broadly similar to what other distros are doing, so
should be pretty safe. Thanks for taking care of this.

Bug#1069892: qemu: FTBFS on riscv64: error: macro "KVM_RISCV_GET_TIMER" requires 4 arguments, but only 3 given

[Aurelien Jarno]

Source: qemu
Version: 1:8.2.3+ds-1
Severity: important
Tags: upstream patch ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

qemu version 1:8.2.3+ds-1 fails to build from source on riscv64:

| FAILED: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o 
| cc -Ilibqemu-riscv64-softmmu.fa.p -I. -I../.. -Itarget/riscv 
-I../../target/riscv -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 
-I/usr/include/capstone -I/usr/include/glib-2.0 
-I/usr/lib/riscv64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall 
-Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wundef 
-Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls 
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 
-Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 
-Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value 
-Wno-psabi -Wshadow=local -isystem /<>/linux-headers -isystem 
linux-headers -iquote . -iquote /<> -iquote 
/<>/include -iquote /<>/host/include/generic -iquote 
/<>/tcg/riscv -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-ffile-prefix-map=../../= -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE 
-isystem../../linux-headers -isystemlinux-headers -DNEED_CPU_H 
'-DCONFIG_TARGET="riscv64-softmmu-config-target.h"' 
'-DCONFIG_DEVICES="riscv64-softmmu-config-devices.h"' -MD -MQ 
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o -MF 
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o.d -o 
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o -c 
../../target/riscv/kvm/kvm-cpu.c
| ../../target/riscv/kvm/kvm-cpu.c: In function 
‘kvm_riscv_get_timebase_frequency’:
| ../../target/riscv/kvm/kvm-cpu.c:691:43: error: macro "KVM_RISCV_GET_TIMER" 
requires 4 arguments, but only 3 given
|   691 | KVM_RISCV_GET_TIMER(cs, frequency, reg);
|   |   ^
| ../../target/riscv/kvm/kvm-cpu.c:104: note: macro "KVM_RISCV_GET_TIMER" 
defined here
|   104 | #define KVM_RISCV_GET_TIMER(cs, env, name, reg) \
|   | 
| ../../target/riscv/kvm/kvm-cpu.c:691:5: error: ‘KVM_RISCV_GET_TIMER’ 
undeclared (first use in this function); did you mean ‘KVM_RISCV_SBI_EXT_TIME’?
|   691 | KVM_RISCV_GET_TIMER(cs, frequency, reg);
|   | ^~~
|   | KVM_RISCV_SBI_EXT_TIME
| ../../target/riscv/kvm/kvm-cpu.c:691:5: note: each undeclared identifier is 
reported only once for each function it appears in
| ninja: build stopped: subcommand failed.
| make: *** [debian/rules:229: b/qemu/built] Error 1
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=qemu=riscv64=1%3A8.2.3%2Bds-1=1714044943=0

After investigation it appears to be an upstream issue, caused by a
patch backported to the 8.2 stable branch, which does not work as this
branch misses some refactoring commits:

| commit 1e4ec0958ec734ed6a194475e699c917ba950cb2
| Author: Yong-Xuan Wang 
| Date:   Thu Mar 14 14:15:09 2024 +0800
| 
| target/riscv/kvm: fix timebase-frequency when using KVM acceleration
| 
| The timebase-frequency of guest OS should be the same with host
| machine. The timebase-frequency value in DTS should be got from
| hypervisor when using KVM acceleration.
| 
| Signed-off-by: Yong-Xuan Wang 
| Message-ID: <20240314061510.9800-1-yongxuan.w...@sifive.com>
| Reviewed-by: Andrew Jones 
| Reviewed-by: Philippe Mathieu-Daudé 
| Reviewed-by: Alistair Francis 
| Signed-off-by: Alistair Francis 
| (cherry picked from commit 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe)
| Signed-off-by: Michael Tokarev 
| (Mjt: context fix due to missing other changes in this area in 8.2.x)

One way to fix that is to identify and backport the missing commits. I
know that 10f86d1b845087d14b58d65dd2a6e3411d1b6529 is one of them, but
is not enough. However the risk to break more things by backporting more
commits is important.

An alternative is to just fix the build issue with the following patch:

diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index c1675158fe..f15a540f61 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -687,8 +687,9 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
 uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs)
 {
 uint64_t reg;
+CPURISCVState *env = _CPU(cs)->env;
 
-KVM_RISCV_GET_TIMER(cs, frequency, reg);
+KVM_RISCV_GET_TIMER(cs, env, frequency, reg);
 
 return reg;
 }

I will let you, as the maintainer, 

Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x

[Andreas Beckmann]

Control: reassign -1 src:gnutls28 3.8.3-1
Control: severity -1 normal
Control: tag -1 moreinfo

On Fri, 26 Apr 2024 12:41:45 +0200 Dirk Lehmann  wrote:

Package: libgnutls30
Version: 3.8.3-1



since yesterday the .deb files for the architectures
  * amd64 arm64 i386 mips64el ppc64el riscv64 s390x
on the Debian Apt mirrors are not listed/available anymore:


since they have been superseded by libgnutls30t64 for the 64-bit time_t 
transition.


In a minimal up-to-date testing chroot:

# apt-get install exim4-daemon-light
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  cron cron-daemon-common dmsetup exim4-base exim4-config libapparmor1 
libargon2-1 libcryptsetup12 libdevmapper1.02.1 libevent-2.1-7t64 
libfdisk1 libgnutls-dane0t64 libidn12 libjson-c5 libkmod2 
libsystemd-shared libunbound8 netbase systemd systemd-dev

Suggested packages:
  anacron logrotate checksecurity supercat bat exim4-doc-html | 
exim4-doc-info eximon4 file mail-reader spf-tools-perl swaks 
dns-root-data systemd-container systemd-homed systemd-userdbd 
systemd-boot systemd-resolved libfido2-1 libip4tc2 libqrencode4
  libtss2-esys-3.0.2-0 libtss2-mu-4.0.1-0 libtss2-rc0 
libtss2-tcti-device0 polkitd

Recommended packages:
  bsd-mailx | mailx psmisc default-dbus-system-bus | dbus-system-bus 
systemd-timesyncd | time-daemon

The following NEW packages will be installed:
  cron cron-daemon-common dmsetup exim4-base exim4-config 
exim4-daemon-light libapparmor1 libargon2-1 libcryptsetup12 
libdevmapper1.02.1 libevent-2.1-7t64 libfdisk1 libgnutls-dane0t64 
libidn12 libjson-c5 libkmod2 libsystemd-shared libunbound8 netbase

  systemd systemd-dev
0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 86.0 kB/9704 kB of archives.
After this operation, 27.8 MB of additional disk space will be used.
Do you want to continue? [Y/n]

which looks fine, therefore downgrading the severity.

The t64 transition has started migrating packages to testing
 a few days ago, so maybe you experienced the failure at an unfortunate 
moment.


Andreas

Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Lee Garrett]

On Fri, 26 Apr 2024 15:05:00 +0200 Lee Garrett  wrote:

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ansi...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:ansible

Hi,

I'm requesting to bump the version of the ansible package ("ansible-community
collection") to the last minor semantic version of the v7 series in bookworm.
This version has previously spent ~10 months in testing/unstable, so I'm fairly
confident that any potential regressions would have been caught (so far none).

[ Reason ]
This incorporates the latest bugfixes from the v7 series, which update all
modules in the collection. These contain updates to handle:
- distro releases that have been released since
- web API changes that ansible can run against
- various bugfixes
- deprecation warnings that will be useful for users before they upgrade to
  bookworm + 1

Most importantly due to semantic versioning, there is no user-visible change.
Any previous playbooks will continue to work without changes.

I intend to use the 7.7.0 release as a basis for security support until bookworm
LTS EOL.

[ Impact ]
(What is the impact for the user if the update isn't approved?)
If the update is not approved, users will likely report errors that have already
been fixed in the latest minor release, and I'd have to cherrypick those
changes, add roundtrip time to the process.

[ Tests ]
autopkgtests have been widely expanded from the previous 7.3.0 release, covering
more unit tests than before.

[ Risks ]
There is a small risk of regressions, but I believe the risk to be minimal as no
such regressions have been reported in the 10 months in testing/unstable.

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

[ Changes ]
- upstream update to 7.7.0


Forgot to add the link with the high-level upstream changes:
https://salsa.debian.org/debian/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst


- fixes to the libvirt connection plugin that bit me
- updates to the package metadata
- widely expanded autopkgtests for more coverage

[ Other info ]
This is my first s-p-u process, let me know what I can do better for any
following s-p-u.

Bug#1057463: marked as pending in supertuxkart

[Reiner Herrmann]

Hi Vincent,

On Fri, Apr 26, 2024 at 06:03:51AM -0700, Vincent Cheng wrote:
> Hi Reiner,
> 
> On Sat, Jan 6, 2024 at 1:03 PM Reiner Herrmann  
> wrote:
> > 
> > Use system shaderc instead of embedded copy
> >
> > Closes: #1057463, #1031387
> > 
> 
> Just wanted to sanity check before uploading, is it ok for me to
> upload what's currently in salsa to close out #1057463 (and #995771),
> or are there other blockers / were you waiting on something else?
> Either way, thanks for fixing these bugs in supertuxkart!

at the time when I fixed it, there were still some strange linking
errors. But I just did another test build and it was successful.
The reason is probably the new version of shaderc (which mentions
linking fixes in the changelog).
So I don't see any blocker, please upload it. Thanks!

Kind regards,
  Reiner

Bug#1069195: librust-prost-build-dev: FTBFS

[Peter Green]

Unsatisfiable build-dependency on librust-heck-0.5+default-dev



There seems to be an error here. the version of librust-prost-dev in sid
(build-)depends on librust-heck-0.4+default-dev.

The version in experimental does depend on librust-heck-0.5+default-dev
as it's first choice, but that's fine because version 0.5 of rust-heck
is available in experimental.

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Sam Hartman]

> "Chris" == Chris Hofstaedtler  writes:

Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog files.

Chris> Thorsten Kukuk and others have been working on replacements for the
Chris> existing file formats and interfaces [1]; these are called wtmpdb
Chris> and lastlog2.

Relatedly, PAM upstream and apparently at least some aspects of Fedora
have been moving to logind to handle utmp functionality.
You will start to see the  first impacts of that in pam unstable.

--Sam

Bug#1065810: New appointments for the Debian Technical Committee: csmall

[Sean Whitton]

Hello,

On Fri 26 Apr 2024 at 03:08pm +02, Timo Röhling wrote:

> * Andreas Tille  [2024-04-26 14:22]:
>>The Technical Committee now consists of:
>>
>>  * Sean Whitton  (chair)
>>  * Simon McVittie 
>>  * Christoph Berg 
>>  * Helmut Grohne 
>>  * Matthew Vernon 
>>  * Matthew Garrett 
>>  * Stefano Rivera 
>>  * Timo Röhling 
>>  * Craig Small 
>>
> Correct me if I'm wrong, but I think Simon McVitie's term has ended already.

It has.  Possibly a follow-up correction should be sent.

Anyway, thanks for handling it, Andreas.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065810: New appointments for the Debian Technical Committee: csmall

[Timo Röhling]

* Andreas Tille  [2024-04-26 14:22]:

The Technical Committee now consists of:

 * Sean Whitton  (chair)
 * Simon McVittie 
 * Christoph Berg 
 * Helmut Grohne 
 * Matthew Vernon 
 * Matthew Garrett 
 * Stefano Rivera 
 * Timo Röhling 
 * Craig Small 

Correct me if I'm wrong, but I think Simon McVitie's term has ended 
already.



Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1069890: Resignation & call for votes to elect the Chair

[Sean Whitton]

Package: tech-ctte

Dear committee members,

As the membership of the committee has changed, in accordance with
convention I hereby resign as Chair, effective one week from now, and
call for votes to elect the Chair of the Technical Committee.
Per the Debian Constitution, the vote runs until all members have voted,
or until my resignation takes effect.

I am happy to continue to volunteer for the role, if the committee agrees.

The ballot:

===BEGIN

A: Christoph Berg 
B: Matthew Garrett 
C: Helmut Grohne 
D: Stefano Rivera 
E: Timo Röhling 
F: Craig Small 
G: Matthew Vernon 
H: Sean Whitton 

===END

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1057463: marked as pending in supertuxkart

[Vincent Cheng]

Hi Reiner,

On Sat, Jan 6, 2024 at 1:03 PM Reiner Herrmann  wrote:
>
> Control: tag -1 pending
>
> Hello,
>
> Bug #1057463 in supertuxkart reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/games-team/supertuxkart/-/commit/68a3bec7900d9921cb7f0428123db0eda945742a
>
> 
> Use system shaderc instead of embedded copy
>
> Closes: #1057463, #1031387
> 
>
> (this message was generated automatically)
> --
> Greetings
>
> https://bugs.debian.org/1057463

Just wanted to sanity check before uploading, is it ok for me to
upload what's currently in salsa to close out #1057463 (and #995771),
or are there other blockers / were you waiting on something else?
Either way, thanks for fixing these bugs in supertuxkart!

Regards,
Vincent

Bug#1069889: gpg-sq-dbgsym: missing auto-load script

[Daniel Kahn Gillmor]

Package: gpg-sq-dbgsym
Version: 0.8.0-4
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I am trying to debug a performance issue with gpg-sq upstream
(https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/72) and
i attached gdb to a running gpg-sq process.

As soon as it was attached, gdb emits this warning:

warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts of 
file /usr/bin/gpg-sq.

I'm not sure exactly what this means, or how it should be fixed, but
here it is in context:


```
0 dkg@alice:~$ gdb -p $(pidof gpg)
GNU gdb (Debian 13.2-1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 898919
[New LWP 898945]
[New LWP 898946]
[New LWP 898947]
[New LWP 898948]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fb3417e0872 in __gmpn_addmul_2 () from /lib/x86_64-linux-gnu/libgmp.so.10
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /usr/bin/gpg-sq.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb)
```

As you investigate, feel free to reassign this report to gdb (if it's a
spurious warning), or to cargo (if it's a build issue), dh-cargo (if
it's a packaging issue), or anywhere else that makes sense.

Thanks for maintaining gpg-sq in debian!

--dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 gpg-sq-dbgsym depends on:
ii  gpg-sq  0.8.0-4

gpg-sq-dbgsym recommends no packages.

gpg-sq-dbgsym suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Cyril Brulebois]

Marco d'Itri  (2024-04-26):
> On Apr 26, Michael Tokarev  wrote:
> 
> > So, should I disable module utils in busybox-udeb now?
> I think so.

I haven't gotten any requests / seen any reasons to keep it; so, yes,
please feel free to remove it whenever is convenient for you.

> > Is kmod udeb ready and used in d-i already, or does it need some
> > prep first?
> AFAIK it works.

Absolutely, that's been working since the small xz-utils tweak (the udeb
addition, not the backdoor thing).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1069888: node-bunyan: FTBFS: failing tests

[Santiago Vila]

Package: src:node-bunyan
Version: 2.0.5+~cs4.4.3-2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
Link node_modules/exeunt -> ../exeunt
Link node_modules/mv -> ../mv
Link node_modules/safe-json-stringify -> ../safejsonstringify
   dh_auto_build --buildsystem=nodejs
No build command found, searching known files
No build command found, searching known files
No build command found, searching known files
No build command found, searching known files
   dh_auto_test --buildsystem=nodejs
ln -s ../. node_modules/bunyan
/bin/sh -ex debian/tests/pkg-js/test
+ tap -R tap -J --no-cov test/add-stream.test.js test/buffer.test.js 
test/child-behaviour.test.js test/cli-client-req.test.js test/cli-res.test.js 
test/cli.test.js test/ctor.test.js test/cycles.test.js test/error-event.test.js 
test/level.test.js test/log.test.js test/other-api.test.js 
test/process-exit.test.js test/raw-stream.test.js test/ringbuffer.test.js 
test/safe-json-stringify.test.js test/serializers.test.js test/src.test.js 
test/stream-levels.test.js
TAP version 13
# Subtest: test/add-stream.test.js
# Subtest: non-writables passed as stream
ok 1 - "stream" stream is not writable
ok 2 - "stream" stream is not writable
1..2
ok 1 - non-writables passed as stream # time=18.713ms

# Subtest: proper stream

ok 1 - expect truthy value
1..1
ok 2 - proper stream # time=4.908ms

1..2

# time=46.964ms
ok 1 - test/add-stream.test.js # time=46.964ms

# Subtest: test/buffer.test.js
# Subtest: log.info(BUFFER)
ok 1 - log.trace msg is inspect(BUFFER)
ok 2 - no "0" array index key in record: undefined
ok 3 - no "parent" array index key in record: undefined
ok 4 - log.trace(BUFFER, "bar") msg is inspect(BUFFER) + " bar"
ok 5 - log.debug msg is inspect(BUFFER)
ok 6 - no "0" array index key in record: undefined
ok 7 - no "parent" array index key in record: undefined
ok 8 - log.debug(BUFFER, "bar") msg is inspect(BUFFER) + " bar"
ok 9 - log.info msg is inspect(BUFFER)
ok 10 - no "0" array index key in record: undefined
ok 11 - no "parent" array index key in record: undefined
ok 12 - log.info(BUFFER, "bar") msg is inspect(BUFFER) + " bar"
ok 13 - log.warn msg is inspect(BUFFER)
ok 14 - no "0" array index key in record: undefined
ok 15 - no "parent" array index key in record: undefined
ok 16 - log.warn(BUFFER, "bar") msg is inspect(BUFFER) + " bar"
ok 17 - log.error msg is inspect(BUFFER)
ok 18 - no "0" array index key in record: undefined
ok 19 - no "parent" array index key in record: undefined
ok 20 - log.error(BUFFER, "bar") msg is inspect(BUFFER) + " bar"
ok 21 - log.fatal msg is inspect(BUFFER)
ok 22 - no "0" array index key in record: undefined
ok 23 - no "parent" array index key in record: undefined
ok 24 - log.fatal(BUFFER, "bar") msg is inspect(BUFFER) + " bar"
1..24
ok 1 - log.info(BUFFER) # time=15.595ms

1..1

# time=36.998ms
ok 2 - test/buffer.test.js # time=36.998ms

# Subtest: test/child-behaviour.test.js
# Subtest: child can add stream
ok 1 - should be equal
ok 2 - should be equal
ok 3 - should be equal
ok 4 - should be equal
1..4
ok 1 - child can add stream # time=8.798ms

# Subtest: child can set level of inherited streams

ok 1 - should be equal
ok 2 - should be equal
ok 3 - should be equal
1..3
ok 2 - child can set level of inherited streams # time=2.496ms

# Subtest: child can set level of inherited streams and add streams

ok 1 - should be equal
ok 2 - should be equal
ok 3 - should be equal
ok 4 - should be equal
ok 5 - should be equal
ok 6 - should be equal
1..6
ok 3 - child can set level of inherited streams and add streams # 
time=5.594ms

# Subtest: child should not lose parent "hostname"

ok 1 - should be equal
ok 2 - should be equal
ok 3 - should be equal
ok 4 - should be equal
1..4
ok 4 - child should not lose parent "hostname" # time=1.888ms

1..4

# time=43.011ms
ok 3 - test/child-behaviour.test.js # time=43.011ms

(node:558561) DeprecationWarning: ifError() is deprecated, use error() instead
(Use `node --trace-deprecation ...` to show where the warning was created)
# Subtest: test/cli-client-req.test.js
# Subtest: client_req extra newlines, client_res={} (pull \#252)
ok 1 - should not error
ok 2 - should be equal

Bug#985854: dwm: open calibre gui prevents switching focus to other windows

[Matteo Bini]

Hi florine,
could you please try if that's always the case?

I can't reproduce your issue. I've installed calibre, but I can switch
between its window and others, with Mod1-J and Mod1-K.

I'll wait for a couple of weeks, then I'll close the bug for inactivity
and I'll mark it as solved.

--
Matteo Bini

Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml

[Andrey Rakhmatullin]

On Fri, Apr 26, 2024 at 09:27:30PM +1000, Dmitry Smirnov wrote:
> On Friday, 26 April 2024 12:16:39 AM AEST Andrey Rakhmatullin wrote:
> > > Obviously '.gitlab-ci.yml' is a repository-specific file with
> > > configuration of Gitlab CI on Salsa. There is no reason to ship it with
> > > source package
> > 
> > Yet you are shipping it, maybe you should reconsider that?
> > 
> > $ tar tvf gnucash_5.5-1.2.debian.tar.xz debian/.gitlab-ci.yml
> > -rw-rw-r-- 0/0 759 2024-02-23 22:55 debian/.gitlab-ci.yml
> 
> I'm not shipping it. NMU uploader must have built the package differently
> to preserve the file. Oh, wait, that was you who last uploaded Ghucash.
> (Thank you for your help with NMU. Much appreciated.)
And I shipped it because the previous upload shipped it and I noticed in
the debdiff that it gets removed.
Now I see that the previous upload was also a NMU and no final debdiff has
been sent (I think), so it's possible that this file was only included
there.

> I don't mind shipping the file (it is harmless) but I've made an explicit
> change to "debian/clean" to remove it. 
> 
> Leave this matter alone please. Frankly it does not worth your time and I'd
> rather not play that bug reopen ping-pong. 
> What change you expect me to make?? Everything already works as intended.
If the file is normally not shipped in the package then I'm fine, I only
wanted to make sure that it's easy to do NMUs for the package.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1069887: quickfix: FTBFS: add support for loongarch64

[zhangdandan]

Source: quickfix
Version: 1.15.1+dfsg-4.1
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the quickfix failed for loong64 in the Debian Package 
Auto-Building environment.

The error log is as follows,
```
In file included from ./double-conversion/diy-fp.h:31,
 from double-conversion/diy-fp.cc:29,
 from FieldConvertors.cpp:37:
./double-conversion/utils.h:84:2: error: #error Target architecture was 
not detected as supported by Double-Conversion.
   84 | #error Target architecture was not detected as supported by 
Double-Conversion.

  |  ^
..
```

The Full log can be found at 
https://buildd.debian.org/status/logs.php?pkg=quickfix=1.15.1%2Bdfsg-4.1=loong64.


I have added support for loongarch in quickfix package and built 
successfully on my local ENV.

Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

Description: Add support for loongarch64 
Last-Update: 2024-04-26

--- quickfix-1.15.1+dfsg.orig/src/C++/double-conversion/utils.h
+++ quickfix-1.15.1+dfsg/src/C++/double-conversion/utils.h
@@ -69,7 +69,7 @@
 defined(__sparc__) || defined(__sparc) || defined(__s390__) || \
 defined(__SH4__) || defined(__alpha__) || \
 defined(_MIPS_ARCH_MIPS32R2) || \
-defined(__AARCH64EL__) || defined(__aarch64__)
+defined(__AARCH64EL__) || defined(__aarch64__) || defined(__loongarch64)
 #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1
 #elif defined(__mc68000__)
 #undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS

Bug#1066100: upstream 3.1.1 released, fixing this bug

[Giacomo Mulas]

Hi.

Just a "heads up" email to draw the attention of the maintainer(s) of the
debian freeciv packages to the release of the new 3.1.1 version of freeciv,
a bugfix release fixing, among others, the one reported here.

Any idea on if/when this new release will be packaged for debian, hence
possibly closing this bug?

Thanks, best regards
Giacomo Mulas

--
_

Giacomo Mulas 
_

INAF - Osservatorio Astronomico di Cagliari
via della scienza 5 - 09047 Selargius (CA)

tel.   +39 070 71180255
mob. : +39 329  6603810
_

"every year keeps getting shorter, never seem to find the time
 plans that either come to naught, or half a page of scribbled lines
 the time is gone, the song is over, thought I'd something more to say"
 (Pink Floyd)
_

Bug#1065810: New appointments for the Debian Technical Committee: csmall

[Andreas Tille]

Dear fellow developers,

As defined by our constitution (§6.2.2), the Debian Technical Committee
has recommended the appointment to the committee of:

  * Craig Small 

I agree with their recommendation, and hereby appoint Craig as member of
the Technical Committee, effective immediately.

For reference, the nominations and votes are recorded at:

https://bugs.debian.org/1065810

The Technical Committee now consists of:

  * Sean Whitton  (chair)
  * Simon McVittie 
  * Christoph Berg 
  * Helmut Grohne 
  * Matthew Vernon 
  * Matthew Garrett 
  * Stefano Rivera 
  * Timo Röhling 
  * Craig Small 

Task Description:

The Technical Committee is established by the Debian Constitution,
section 6. It is the body which makes the final decision on technical
disputes in the Debian project.

More info about the Technical Committee, including recent decisions,
discussion and advice, may be found at:

https://www.debian.org/devel/tech-ctte

The previous CTTE Appointment mail can be found at:

https://lists.debian.org/debian-devel-announce/2023/07/msg0.html

Thanks to everyone on the committee who dedicate their time and skills
towards Debian as well as good luck for Craig for the new position!

  Andreas, Debian Project Leader



signature.asc
Description: PGP signature

Bug#1069820: [Android-tools-devel] Bug#1069820: android-sdk-meta: Split udev rules in separate package

[Fab Stz]

Hello,

I like the idea. It would also be useful for those using google-android-*-
installer packages.

May I suggest using this line in Build-Depends instead of only systemd-dev?

systemd-dev (>= 253-3~) | udev (<< 253-3~),

It would permit to build your package also on bookworm and previous releases.

Regards
Fab

Le jeudi 25 avril 2024, 12:39:30 CEST Andrea Pappacoda via Android-tools-devel 
a écrit :
> Source: android-sdk-meta
> Version: 28.0.2+10
> Severity: wishlist
> Tags: patch

Bug#1069885: glueviz: please drop obsolete python3-mock build dependency

[Alexandre Detiste]

Source: glueviz
Version: 1.17.1+dfsg-1
Severity: normal

Dear Maintainer,

glueviz is using the newer unittest.mock from the standard library instead.

Greetings

tchet@quieter:/tmp/glue$ grep mock -r | grep -e import -e debian
debian/control:   python3-mock,
glue/core/data_factories/tests/test_data_factories.py:from unittest.mock import 
MagicMock
glue/core/tests/test_application_base.py:from unittest.mock import MagicMock
glue/core/tests/test_command.py:from unittest.mock import MagicMock
glue/core/tests/test_component.py:from unittest.mock import MagicMock
glue/core/tests/test_data.py:from unittest.mock import MagicMock
glue/core/tests/test_data_collection.py:from unittest.mock import MagicMock
glue/core/tests/test_data_combo_helper.py:from unittest.mock import MagicMock
glue/core/tests/test_fitters.py:from unittest.mock import MagicMock
glue/core/tests/test_hub.py:from unittest.mock import MagicMock
glue/core/tests/test_pandas.py:from unittest.mock import MagicMock
glue/core/tests/test_parse.py:from unittest.mock import MagicMock, patch
glue/core/tests/test_roi.py:from unittest.mock import MagicMock
glue/core/tests/test_subset.py:from unittest.mock import MagicMock
glue/core/tests/test_subset_group.py:from unittest.mock import MagicMock, patch
glue/core/tests/util.py:from unittest.mock import MagicMock
glue/io/tests/test_subset_mask.py:from unittest.mock import MagicMock
glue/tests/test_settings_helpers.py:from unittest.mock import patch
glue/viewers/image/tests/test_composite_array.py:from unittest.mock import 
MagicMock
glue/viewers/matplotlib/tests/test_mouse_mode.py:from unittest.mock import 
MagicMock

Bug#1069886: piuparts fails when unrelated hardware events happen on the host machine

[Lee Garrett]

Package: piuparts
Version: 1.1.7
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I'm running piuparts in a schroot as part of my packaging workflow. However,
when I plug in hardware on my host machine, or enable/disable things like
bluetooth/LTE modem/etc, during a piuparts run it will inadvertently fail:

[...]
2m51.1s ERROR: FAIL: After purging files have disappeared:
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bEndpointAddress
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bInterval
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bLength
not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bmAttributes
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/direction
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/interval
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/
 not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/async
not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/autosuspend_delay_ms
 not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/control
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_active_kids
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_active_time
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_enabled
  not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_status
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_suspended_time
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_usage
not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/type
   not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/uevent
 not owned
  
/sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/wMaxPacketSize
 not owned

2m51.1s ERROR: FAIL: Installation, upgrade and purging tests.
2m51.5s DEBUG: Terminate schroot session 
'/var/run/schroot/mount/bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts'
2m51.5s DEBUG: Starting command: ['schroot', '--end-session', '--chroot', 
'session:bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts']
2m51.6s DEBUG: Command ok: ['schroot', '--end-session', '--chroot', 
'session:bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts']
2m51.6s ERROR: piuparts run ends.

E: Piuparts run failed.

Since it's not immediately clear if it failed for those reasons alone, it makes
piuparts less useful. It would be nice if piuparts could ignore /sys, /dev,
/proc as they're not on-disk file systems anyway.

Greets,
Lee


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

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 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_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages piuparts depends on:
ii  debootstrap  1.0.128+nmu2+deb12u1
ii  debsums  3.0.2.1
ii  libjs-sphinxdoc  5.3.0-4
ii  lsb-release  12.0-1
ii  lsof 4.95.0-1
ii  mount2.38.1-5+deb12u1
ii  

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

Hello,

On Fri 26 Apr 2024 at 12:38pm +02, Andreas Tille wrote:

> Hi Sean,
>
> Am Fri, Apr 26, 2024 at 10:53:41AM +0100 schrieb Sean Whitton:
>> > Possibly I need to send some delegation mail like this[1]?
>>
>> It's an appointment, not a delegation, but yes something like that mail.
>
> So something I could copy-n-paste from
>
>https://lists.debian.org/debian-devel-announce/2023/07/msg0.html
>
> adding
>
>Craig Small 
>
> on top?

Yes, though you'd also need to update each of the https:// links.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#854160: [minor] dwm: recommend xserver-xorg-legacy

[Matteo Bini]

Hi lumin,
I've installed xserver-xorg-legacy, but I can't xinit dwm anyway. I get a
connection error to X server. It's true that, if I run xinit as root it
works, but as a normal user it doesn't.

$ xinit dwm
It doesn't work.

$ xinit
It doesn't work with `exec dwm` in .xinitrc as well.

# xinit dwm
It does work.

# xinit
It does work with `exec dwm` in .xinitrc.

However startx works as expected, if you run that as a normal user. Both
with .xinitrc or .xsession, which is the "correct"/Debian way to
customise an X session [1].

I hope I've been of some help. I'll wait for a couple of weeks, then
I'll close the bug for inactivity and I'll mark it as solved.

--
Matteo Bini


[1] https://wiki.debian.org/Xsession#User_configuration

Bug#1069884: Document acronym "ITA" on https://www.debian.org/devel/wnpp/

[Lee Garrett]

Package: www.debian.org
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

it would be nice to document "ITA" on https://www.debian.org/devel/wnpp/ along
with the other acronyms like O/RFA/RFH/ITP/RFP. I'm guessing it means "intent to
adopt"? It's mentioned in the removing tables entries, but that's not helpful to
see which tags are available.

Greets,
Lee

Bug#1069883: most: copyright - mark the ftp:// address not available (N/A)

[Jari Aalto]

Package: most
Version: 5.2.0-1+b1
Severity: minor

https://metadata.ftp-master.debian.org/changelogs//main/m/most/most_5.2.0-1_copyright

Suggest to add a note[1], that the sources are no longer available
at the location:

This package was put together by Chris Fearnley ,
from the GNU sources, which I obtained from
  ftp://space.mit.edu/pub/davis/most/

=> 

This package was put together by Chris Fearnley ,
from the GNU sources, which I obtained from
  ftp://space.mit.edu/pub/davis/most/
As of 2024-04-26 the sources are no longer avilable

[1]
lftp ftp://space.mit.edu/pub/davis/most/
cd: Access failed: 550 No such directory. (/pub/davis/most)

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

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

Versions of packages most depends on:
ii  libc6  2.37-15
ii  libslang2  2.3.3-3+b1

most recommends no packages.

most suggests no packages.

-- no debconf information

Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml

[Dmitry Smirnov]

On Friday, 26 April 2024 12:16:39 AM AEST Andrey Rakhmatullin wrote:
> > Obviously '.gitlab-ci.yml' is a repository-specific file with
> > configuration of Gitlab CI on Salsa. There is no reason to ship it with
> > source package
> 
> Yet you are shipping it, maybe you should reconsider that?
> 
> $ tar tvf gnucash_5.5-1.2.debian.tar.xz debian/.gitlab-ci.yml
> -rw-rw-r-- 0/0 759 2024-02-23 22:55 debian/.gitlab-ci.yml

I'm not shipping it. NMU uploader must have built the package differently
to preserve the file. Oh, wait, that was you who last uploaded Ghucash.
(Thank you for your help with NMU. Much appreciated.)

I don't mind shipping the file (it is harmless) but I've made an explicit
change to "debian/clean" to remove it. 

Leave this matter alone please. Frankly it does not worth your time and I'd
rather not play that bug reopen ping-pong. 
What change you expect me to make?? Everything already works as intended.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

If you have a government of good laws and bad men, you will have a bad
government. For bad men will not be bound by good laws.
 -- Robert LeFevre


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

Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates

[Andrius Merkys]

Control: severity -1 important
Control: tags -1 - ftbfs

Hi,

On 2024-04-25 19:12, Santiago Vila wrote:

I noticed that chemicaltagger currently FTBFS and I believe it is because
of this problem, so to avoid duplicate reports, I'm raising this one to 
serious.


A build log for chemicaltagger is available here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chemicaltagger.html


I have just fixed the FTBFS bug in chemicaltagger/1.6.2-4, it was a 
separate issue, unrelated to antlr4-maven-plugin.


Best,
Andrius