Bug#1067208: umockdev: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Thorsten Glaser]

Source: umockdev
Version: 0.18.0-1
Severity: serious
Justification: FTBFS on t64-affected archs
X-Debbugs-Cc: t...@mirbsd.de
Tags: ftbfs

cc -Ilibumockdev-preload.so.0.0.0.p -I. -I.. -fdiagnostics-color=always -Wall 
-Winvalid-pch -std=gnu11 -Werror=missing-prototypes -Werror=strict-prototypes 
-Werror=nested-externs -Werror=pointer-arith 
-Werror=implicit-function-declaration -Werror=implicit-int 
-Werror=int-conversion -Werror=old-style-definition -Werror=pointer-arith 
-Werror=init-self -Werror=format-security -Werror=format=2 -Werror=return-type 
-Werror=uninitialized -Wcast-align -Wno-error=pragmas 
-Wno-error=discarded-qualifiers -Wno-error=incompatible-pointer-types 
-Wno-error=pointer-sign -Wno-unused-but-set-variable -Wno-unused-function 
-Wno-unused-label -Wno-unused-value -Wno-unused-variable -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=default -MD 
-MQ libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o -MF 
libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o.d -o 
libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o -c 
../src/libumockdev-preload.c
In file included from /usr/include/features.h:393,
 from /usr/include/assert.h:35,
 from ../src/libumockdev-preload.c:31:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed 
only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
  | ^


I admit I don’t exactly see what’s going on here. Does it
maybe #unset _FILE_OFFSET_BITS or something?

Bug#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets

[Thorsten Glaser]

Source: mesa
Version: 24.0.3-1
Severity: important
Justification: FTBFS on d-ports arch
X-Debbugs-CC: t...@mirbsd.de, debian-...@lists.debian.org
Tags: ftbfs

mesa currently FTBFS on m68k with:

[…]
cc -Isrc/nouveau/headers/libnvidia_headers.a.p […] -o 
src/nouveau/headers/libnvidia_headers.a.p/meson-generated_.._nvk_cla097.c.o -c 
src/nouveau/headers/nvk_cla097.c
/tmp/ccrcAVyk.s: Assembler messages:
/tmp/ccrcAVyk.s:15766: Error: Adjusted signed .word (0x8002) overflows: 
`switch'-statement too large.
/tmp/ccrcAVyk.s:15766: Error: Adjusted signed .word (0x8008) overflows: 
`switch'-statement too large.
[…]

Not sure if it makes sense to exclude building this part of nouveau
on m68k (I do know someone who has added a PCI bus to his Atari and
runs a Radeon on it) or whether other files in this source package
also have huge jump tables.

Adding the -mlong-jump-table-offsets flag to CFLAGS on m68k should
unbreak this; bonus points if you add it to only the files where
it’s needed, if it’s only a few and not expected to change, for example.

Bug#1065436: cyrus-sasl2 accesses resources from the network during the build

[Thorsten Glaser]

Matthias Klose dixit:

> the Debian build log doesn't show this error message, so this sphinx
> inventory is fetched from the website during the build.

Huh? Does sbuild/buildd not unshare the network?

I added that to pbuilder some time ago and vaguely recall
that there was an expectation that the buildds do that as
well, and a bit of back and forth leading to the loopback
interface being initialised in the separate namespace but
nothing more.

bye,
//mirabilos
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

Bug#1067206: bookworm-pu: package amavisd-new/1:2.13.0-3+deb12u1

[Brian May]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: amavisd-...@packages.debian.org, b...@debian.org
Control: affects -1 + src:amavisd-new

[ Reason ]

* Fix race condition on initial install. Closes: #1064349.
* Fix CVE-2024-28054.

[ Impact ]

Without this path:

* Possible errors on initial installation.
* CVE-2024-28054 won't be fixed, and amavisd-new could potentially let through 
mallacious emails.

[ Tests ]

No tests.

[ Risks ]

Patch could break with risk that geniune emails get blocked.

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

As below.

[ Other info ]

I hope I am doing this right :-)


=== debdiff ===

root@08c7f517533c:/tmp/brian/tmp5u_5mq1q/build# debdiff 
old/amavisd-new_2.13.0-3.dsc  amd64/amavisd-new_2.13.0-3+deb12u1.dsc
diff -Nru amavisd-new-2.13.0/debian/amavisd-new.postinst 
amavisd-new-2.13.0/debian/amavisd-new.postinst
--- amavisd-new-2.13.0/debian/amavisd-new.postinst  2023-02-23 
04:59:36.0 +
+++ amavisd-new-2.13.0/debian/amavisd-new.postinst  2024-02-29 
22:56:51.0 +
@@ -95,6 +95,8 @@
fi
done
fi
+
+   deb-systemd-invoke start amavis amavis-mc amavisd-snmp-subagent
 ;;

 abort-upgrade|abort-remove|abort-deconfigure)
diff -Nru amavisd-new-2.13.0/debian/changelog 
amavisd-new-2.13.0/debian/changelog
--- amavisd-new-2.13.0/debian/changelog 2023-05-11 22:52:23.0 +
+++ amavisd-new-2.13.0/debian/changelog 2024-02-29 22:56:51.0 +
@@ -1,3 +1,11 @@
+amavisd-new (1:2.13.0-3+deb12u1) stable; urgency=medium
+
+  * Fix race condition in postinst. Closes: #1064349.
+  * CVE-2024-28054: Handle multiple boundary parameters that contain
+conflicting values.
+
+ -- Brian May   Fri, 01 Mar 2024 09:56:51 +1100
+
 amavisd-new (1:2.13.0-3) unstable; urgency=medium

   * Fix failure to purge without adduser. Closes: #1035841.
diff -Nru amavisd-new-2.13.0/debian/gbp.conf amavisd-new-2.13.0/debian/gbp.conf
--- amavisd-new-2.13.0/debian/gbp.conf  1970-01-01 00:00:00.0 +
+++ amavisd-new-2.13.0/debian/gbp.conf  2024-02-29 22:56:51.0 +
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/bookworm
diff -Nru 
amavisd-new-2.13.0/debian/patches/0010-Apply-fix-for-CVE-2024-28054.patch 
amavisd-new-2.13.0/debian/patches/0010-Apply-fix-for-CVE-2024-28054.patch
--- amavisd-new-2.13.0/debian/patches/0010-Apply-fix-for-CVE-2024-28054.patch   
1970-01-01 00:00:00.0 +
+++ amavisd-new-2.13.0/debian/patches/0010-Apply-fix-for-CVE-2024-28054.patch   
2024-02-29 22:56:51.0 +
@@ -0,0 +1,213 @@
+From: Brian May 
+Date: Tue, 12 Mar 2024 09:34:58 +1100
+Subject: Apply fix for CVE-2024-28054
+
+---
+ README_FILES/README.CVE-2024-28054 | 54 ++
+ conf/amavisd.conf  |  1 +
+ lib/Amavis.pm  |  8 +++---
+ lib/Amavis/Conf.pm |  2 ++
+ lib/Amavis/Unpackers.pm|  5 ++--
+ lib/Amavis/Unpackers/MIME.pm   | 19 ++
+ lib/Amavis/Unpackers/Part.pm   |  3 ++-
+ 7 files changed, 86 insertions(+), 6 deletions(-)
+ create mode 100644 README_FILES/README.CVE-2024-28054
+
+diff --git a/README_FILES/README.CVE-2024-28054 
b/README_FILES/README.CVE-2024-28054
+new file mode 100644
+index 000..757c5c1
+--- /dev/null
 b/README_FILES/README.CVE-2024-28054
+@@ -0,0 +1,54 @@
++# Problem description
++
++Emails which consist of multiple parts (`Content-Type: multipart/*`)
++incorporate boundary information stating at which point one part ends and the
++next part begins.
++
++A boundary is announced by an Content-Type header's `boundary` parameter. To
++our current knowledge, RFC2046 and RFC2045 do not explicitly specify how a
++parser should handle multiple boundary parameters that contain conflicting
++values. As a result, there is no canonical choice which of the values should 
or
++should not be used for mime part decomposition.
++
++It turns out that MIME::Parser from MIME-tools chooses the last `boundary`
++parameter of a Content-Type-header, while several mail user agents choose the
++first occuring one. As a consequence, Amavis will apply some of its routines 
to
++content that a receiving MUA will not see, and vice-versa will not apply them
++to content that the receiving MUA will see. Such routines are at least
++- the banned-files check, and
++- the virus check, unless
++  - Amavis feeds the whole email into the virus scanner, and
++  - the virus scanner implements its own email parsing that aligns with the
++receiving MUA's parser implementation.
++
++MIME::Parser does not provide a choice which of multiple `boundary` parameters
++shall be used for parsing, but it will give feedback in 

Bug#1066794:

[Michael Hudson-Doyle]

It's hard to see from the log but the failures that are causing issues are
the "path_info" gitweb tests such as

expecting success of 9500.70 'path_info: project': gitweb_run "" "/.git"
not ok 70 - path_info: project
# gitweb_run "" "/.git"

It's *impossible* to see from the log afaict but the reason this fails is
because something has caused gitweb.perl to emit warnings like

[Wed Mar 20 02:04:51 2024] gitweb.perl: Use of uninitialized value $my_url
in substitution (s///) at /build/git-VGz7d1/git-2.43.0/gitweb/gitweb.perl
line 70.

This might be because of a new version of libcgi-pm-perl, but downgrading
that package does not make every failure go, leaving warnings like

[Wed Mar 20 02:07:53 2024] gitweb.perl: Use of uninitialized value $base in
open at /build/git-VGz7d1/git-2.43.0/gitweb/gitweb.perl line 2886.

Which still cause a failure. Has perl itself changed in behaviour here?

Bug#1065429: dpkg -s: spurious error "dpkg-query: error: --status needs a valid package name"

[Guillem Jover]

Hi!

On Thu, 2024-03-07 at 04:25:03 +0100, Vincent Lefevre wrote:
> On 2024-03-07 03:34:08 +0100, Guillem Jover wrote:
> > > "apt-cache show libc6-dev" also lists this package.
> > 
> > apt behaves differently, this has been also a known discrepancy, but
> > then they operate in general differently when it comes to their CLI
> > arguments anyway.
> 
> The difference is bad for the user, making simple copy-paste
> impossible, and usage more difficult: the user doesn't know
> in advance whether the package name given by apt needs to be
> completed for dpkg (systematically adding the main architecture
> does not work for "Architecture: all" packages).

That's why dpkg is and has always been internally consistent, and
always arch-qualifies Multi-Arch:any packages (and more recently also
foreign arch:any packages), so that its output can always be used as
its input, even during a cross-upgrade of dpkg itself. As mentioned
above, it's unfortunate that apt implemented a different interface.

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

JFYI, I released dupload 2.11.0 with support for the mentioned
transitions check hook. Have not received any complaints (yet? :).

On Sun, 2024-01-14 at 22:06:46 +0100, Guillem Jover wrote:
> On Sun, 2024-01-14 at 19:35:40 +0100, Guillem Jover wrote:
> > Perfect, thanks. I've force pushed the new changes to the previous
> > branch. How about then the following output?
> > 
> > ,---
> > Warning: Source package barnowl is part of ongoing transitions:
> > 
> >   auto-perl perl-5.38
> > 
> 
> Was wondering now whether it would be better to linkify the list of
> transitions, such as:
> 
> ,---
> Warning: Source package barnowl is part of ongoing transitions:
> 
>   
>   
> 
> […]
> `---
> 
> Although that seems a bit more noisy, but provides more context. I'm
> not sure though how stable those URLs should be considered to be.

In the end went with full URLs, like above.

> > If the upload does not solve issues caused by these transitions, then it
> > might disrupt them by adding delays or entangling them. For more 
> > information,
> > please read:
> > 
> >   
> > 
> > Note: If you are aware of this and do not want to be warned, you can disable
> > this hook from the config file, set the one-off environment variable
> > DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
> > following prompt.
> 
> (I think I'll be adding some generic way to skip specific hooks,
> because this is a common pattern among them, something like
> --skip-hooks=a,b and DUPLOAD_SKIP_HOOKS=a,b.)

I implemented this too.

Thanks,
Guillem

Bug#1064772: pymupdf: FTBFS: fitz.i.c:3343:5: error: conflicting types for ‘fz_pixmap_size’; have ‘int(fz_context *, fz_pixmap *)’

[Michael Hudson-Doyle]

Package: pymupdf
Followup-For: Bug #1064772
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove prototype that now clashes with version in mupdf's headers.

Thanks for considering the patch.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pymupdf-1.23.7+ds1/debian/patches/fz_pixmap_size 
pymupdf-1.23.7+ds1/debian/patches/fz_pixmap_size
--- pymupdf-1.23.7+ds1/debian/patches/fz_pixmap_size1970-01-01 
12:00:00.0 +1200
+++ pymupdf-1.23.7+ds1/debian/patches/fz_pixmap_size2024-03-20 
14:23:27.0 +1300
@@ -0,0 +1,17 @@
+Description: Remove incorrect prototype for function now declared in mupdf's 
headers.
+Author: Michael Hudson-Doyle 
+Origin: vendor
+Forwarded: no
+Last-Update: 2024-03-20
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/fitz/fitz.i
 b/fitz/fitz.i
+@@ -155,7 +155,6 @@
+ // additional headers --
+ pdf_obj *pdf_lookup_page_loc(fz_context *ctx, pdf_document *doc, int needle, 
pdf_obj **parentp, int *indexp);
+ fz_pixmap *fz_scale_pixmap(fz_context *ctx, fz_pixmap *src, float x, float y, 
float w, float h, const fz_irect *clip);
+-int fz_pixmap_size(fz_context *ctx, fz_pixmap *src);
+ void fz_subsample_pixmap(fz_context *ctx, fz_pixmap *tile, int factor);
+ void fz_copy_pixmap_rect(fz_context *ctx, fz_pixmap *dest, fz_pixmap *src, 
fz_irect b, const fz_default_colorspaces *default_cs);
+ static const float JM_font_ascender(fz_context *ctx, fz_font *font);
diff -Nru pymupdf-1.23.7+ds1/debian/patches/series 
pymupdf-1.23.7+ds1/debian/patches/series
--- pymupdf-1.23.7+ds1/debian/patches/series2023-12-17 03:32:08.0 
+1300
+++ pymupdf-1.23.7+ds1/debian/patches/series2024-03-20 14:22:54.0 
+1300
@@ -1,2 +1,3 @@
 docs
 fiximport
+fz_pixmap_size

Bug#1051139: fix doas for sxmo

[Philip J Freeman]

I'm working on a fix for this bug here:

https://salsa.debian.org/DebianOnMobile-team/sxmo-utils/-/merge_requests/2

I'm not sure I like installing Sxmo's doas.conf as /etc/doas.conf.
Looking into alternatives, but it seems that Debian's doas doesn't
support a doas.d/ directory, as pointed out by Jochen Sprickerhof.

This patch (as submitted in the MR on salsa) is currently working for me
on my pinephonepro.

Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest

[Sean Whitton]

Hello,

On Tue 19 Mar 2024 at 04:04pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> Hello,
>>
>> On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote:
>>
>>> Control: tags -1 pending
>>>
>>> I have prepared a fixed version and uploaded to mentors[1] with RFS[2].
>>
>> Thanks for looking at this, but I'm not sure the fix is valid.
>>
>> The idea behind autopkgtest_keep is to ensure we test the installed
>> package, not the files in the source tree.  But if you just include them
>> all, don't the files in the source tree get tested?
>
> After some testing this turns out to be an issue with buttercup: if the
> required module is not immediately in the current loading path it will
> get stuck.  I've tested with `-L` and directly `--eval "(load-library
> 'clojure-mode)"` and while the load-library succeeded it will still get
> stuck.
>
> Meanwhile I have tested locally that with a newer buttercup version 1.34
> this won't be an issue anymore.  However it fails some other tests which
> we'll have to deal with later.
>
> So this is a workaround of the buttercup issue in 1.31.  An alternative
> is to disable autopkgtest as it's doing basically the same thing as the
> test during building.
>
> Wdyt?

Looks like buttercup 1.34 is now in unstable, so perhaps worth making an
attempt at fixing those failing tests, before considering disabling?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1065792: libspf2: FTBFS on arm{el,hf}: spf_utils.c:207:9: error: implicit declaration of function ‘memset’ [-Werror=implicit-function-declaration]

[Michael Hudson-Doyle]

Package: libspf2
Followup-For: Bug #1065792
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com
Control: tags -1 patch

Dear Maintainer,


In Ubuntu, I just uploaded the following rather than try to be in any
way clever:


  * d/patches/fix-include.patch: Include string.h in spf_utils.c to get a
declaration for memset(). (Closes: #1065792, #1066276)


Thanks for considering the patch.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libspf2-1.2.10/debian/patches/fix-include.patch 
libspf2-1.2.10/debian/patches/fix-include.patch
--- libspf2-1.2.10/debian/patches/fix-include.patch 1970-01-01 
12:00:00.0 +1200
+++ libspf2-1.2.10/debian/patches/fix-include.patch 2024-03-20 
13:27:19.0 +1300
@@ -0,0 +1,10 @@
+--- a/src/libspf2/spf_utils.c
 b/src/libspf2/spf_utils.c
+@@ -19,6 +19,7 @@
+ #ifdef STDC_HEADERS
+ # include  /* malloc / free */
+ # include/* isupper / tolower */
++# include/* memset */
+ #endif
+ 
+ #ifdef HAVE_MEMORY_H
diff -Nru libspf2-1.2.10/debian/patches/series 
libspf2-1.2.10/debian/patches/series
--- libspf2-1.2.10/debian/patches/series2023-10-23 05:33:14.0 
+1300
+++ libspf2-1.2.10/debian/patches/series2024-03-20 13:27:01.0 
+1300
@@ -7,3 +7,4 @@
 Fixed-reverse-macro-modifier.patch
 no-libreplace.patch
 spf_compile.c-more-correct-size-of-ds_avail.patch
+fix-include.patch

Bug#1067205: ITS: tkcvs

[Boyuan Yang]

Source: tkcvs
Version: 8.2.3-1.2
Severity: important
X-Debbugs-CC: t...@chiark.greenend.org.uk

Dear package tkcvs maintainer in Debian,

After looking into the package you maintain (tkcvs, 
https://tracker.debian.org/pkg/tkcvs), I found that this package
received no maintainer updates in the past 12 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to refresh packaging and orphan it in order to allow
external contributions, as discussed in https://bugs.debian.org/1039577 .

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Apr 09, 2024) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest

[Xiyue Deng]

Xiyue Deng  writes:

> Sean Whitton  writes:
>
>> Hello,
>>
>> On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote:
>>
>>> Control: tags -1 pending
>>>
>>> I have prepared a fixed version and uploaded to mentors[1] with RFS[2].
>>
>> Thanks for looking at this, but I'm not sure the fix is valid.
>>
>> The idea behind autopkgtest_keep is to ensure we test the installed
>> package, not the files in the source tree.  But if you just include them
>> all, don't the files in the source tree get tested?
>
> After some testing this turns out to be an issue with buttercup: if the
> required module is not immediately in the current loading path it will
> get stuck.  I've tested with `-L` and directly `--eval "(load-library
> 'clojure-mode)"` and while the load-library succeeded it will still get
> stuck.
>
> Meanwhile I have tested locally that with a newer buttercup version 1.34
> this won't be an issue anymore.  However it fails some other tests which
> we'll have to deal with later.
>
> So this is a workaround of the buttercup issue in 1.31.  An alternative
> is to disable autopkgtest as it's doing basically the same thing as the
> test during building.
>
> Wdyt?

As Jeremy just uploaded buttercup 1.34, I'll probably wait a little and
deal with the failed tests I mentioned then.  Will update later with
more info.

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1067204: libspf2-dev depends on both libspf2-2t64 and libspf2-2

[Michael Hudson-Doyle]

Package: libspf2
Version: 1.2.10-8.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com

Dear Maintainer,

This prevents installation on a system that has been affected by the t64
transition.

In Ubuntu, the attached patch was applied to achieve the following:


  * d/rules: Update LIB_PACKAGE to libspf2-2t64.


Thanks for considering the patch.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libspf2-1.2.10/debian/rules libspf2-1.2.10/debian/rules
--- libspf2-1.2.10/debian/rules 2023-10-23 05:33:14.0 +1300
+++ libspf2-1.2.10/debian/rules 2024-03-20 13:02:44.0 +1300
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 SOURCE_PACKAGE = libspf2
-LIB_PACKAGE = libspf2-2
+LIB_PACKAGE = libspf2-2t64
 
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

Bug#1067197: xserver-xorg-video-nouveau ftbfs

[Helge Deller]

On 3/19/24 23:46, Helge Deller wrote:

The problem is that the hppa and powerpc buildds have an outdated
version of dpkg-dev installed, although a newer one has been available
for over a week.


Oh... yes.
Luckily I just updated the chroots a few hours ago.
Giving-back packet again to try.


You were right. Using newer dpkg-dev solved this issue.
This bug can be closed.
Thanks!
Helge

Bug#1066957: dependency not satisfiable in bookworm-backports

[debianbugs . document346]

Same problem!

At the moment, is not possible to update to the stable-backports version of 
Grub2 for amd64 (2.12-1~bpo12+1), because APT would require removing 
grub-efi-amd64-signed (1+2.06+13+deb12u1), which would then make the system 
unbootable with Secure Boot enabled.
I suppose a backport of grub-efi-amd64-signed (1+2.12+1) from Trixie might 
solve this...

Bug#1067203: user-session-migration: fix ftbfs on architectures affected by t64 transition

[Michael Hudson-Doyle]

Package: user-session-migration
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Do not use "%ld" specifier to print time_t timestamp.

This fixes a test failure (and misbehaviour) on systems where time_t is
64-bit and long is 32-bit.

Thanks for considering the patch.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru user-session-migration-0.4.1ubuntu1/src/user-session-migration.c 
user-session-migration-0.4.1ubuntu2/src/user-session-migration.c
--- user-session-migration-0.4.1ubuntu1/src/user-session-migration.c
2023-04-10 06:06:15.0 +1200
+++ user-session-migration-0.4.1ubuntu2/src/user-session-migration.c
2024-03-20 12:29:27.0 +1300
@@ -277,7 +277,7 @@
   filename = get_migration_filename();
   keyfile = g_key_file_new ();
 
-  str = g_strdup_printf ("%ld", time (NULL));
+  str = g_strdup_printf ("%lld", (long long)time (NULL));
   g_key_file_set_string (keyfile,
  "State", "timestamp", str);
   g_free (str);

Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest

[Xiyue Deng]

Sean Whitton  writes:

> Hello,
>
> On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote:
>
>> Control: tags -1 pending
>>
>> I have prepared a fixed version and uploaded to mentors[1] with RFS[2].
>
> Thanks for looking at this, but I'm not sure the fix is valid.
>
> The idea behind autopkgtest_keep is to ensure we test the installed
> package, not the files in the source tree.  But if you just include them
> all, don't the files in the source tree get tested?

After some testing this turns out to be an issue with buttercup: if the
required module is not immediately in the current loading path it will
get stuck.  I've tested with `-L` and directly `--eval "(load-library
'clojure-mode)"` and while the load-library succeeded it will still get
stuck.

Meanwhile I have tested locally that with a newer buttercup version 1.34
this won't be an issue anymore.  However it fails some other tests which
we'll have to deal with later.

So this is a workaround of the buttercup issue in 1.31.  An alternative
is to disable autopkgtest as it's doing basically the same thing as the
test during building.

Wdyt?

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1066811: cyrus-sasl2: assumes time_t fits into long for printf and scanf(!), will break on big endian

[Bastian Germann]

Control: forwarded -1 https://github.com/cyrusimap/cyrus-sasl/issues/484

Bug#1067202: linux-image-6.7.9-amd64: ACPI errors

[Kamila Szewczyk]

Package: src:linux
Version: 6.7.9-2
Severity: important
X-Debbugs-Cc: kspalaiolo...@gmail.com

Dear Maintainer,

I am struggling with ACPI issues on my laptop. As of recent, my laptop refuses 
to charge while turned on and booted into the Linux kernel specifically.
The battery starts charging for a second, then starts discharging (thinking 
that the charging cable has been removed) repeatedly regardless of the position 
of the cable.
When the computer is turned off/not booted into the Linux kernel, the charging 
light turns on and stays on, meaning that the charging process is otherwise 
uninterrupted.
I have started experiencing this issue since upgrading from kernel version 
"linux-image-6.6.15" to "6.7.9-2". Since the upgrade I do not observe some 
problems with ACPI
that I had before (primarily waking up from S3 sleep and resetting the status 
of mute/mic mute keys, etc), but this new issue is preventing me from using my 
computer.

-- Package-specific info:
** Version:
Linux version 6.7.9-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-18) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.9-2 (2024-03-13)

** Command line:
BOOT_IMAGE=/vmlinuz-6.7.9-amd64 root=/dev/mapper/laplace--vg-root ro quiet

** Not tainted

** Kernel log:
[ 1685.874076] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1685.874097] ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1685.874118] ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q4F due to 
previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 1685.909762] ACPI Error: No handler for Region [ECSI] (ebf69c05) 
[EmbeddedControl] (20230628/evregion-130)
[ 1685.909784] ACPI Error: Region EmbeddedControl (ID=3) has no handler 
(20230628/exfldio-261)
[ 1685.909798] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1685.909819] ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1685.909835] ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q4F due to 
previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 1686.625710] ACPI Error: No handler for Region [ECSI] (ebf69c05) 
[EmbeddedControl] (20230628/evregion-130)
[ 1686.625730] ACPI Error: Region EmbeddedControl (ID=3) has no handler 
(20230628/exfldio-261)
[ 1686.625742] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1686.625760] ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1686.625777] ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q4F due to 
previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 1686.661710] ACPI Error: No handler for Region [ECSI] (ebf69c05) 
[EmbeddedControl] (20230628/evregion-130)
[ 1686.661725] ACPI Error: Region EmbeddedControl (ID=3) has no handler 
(20230628/exfldio-261)
[ 1686.661736] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1686.661753] ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1686.661767] ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q4F due to 
previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 1688.625944] ACPI Error: No handler for Region [ECSI] (ebf69c05) 
[EmbeddedControl] (20230628/evregion-130)
[ 1688.625967] ACPI Error: Region EmbeddedControl (ID=3) has no handler 
(20230628/exfldio-261)
[ 1688.625980] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1688.626001] ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1688.626022] ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q4F due to 
previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 1688.661941] ACPI Error: No handler for Region [ECSI] (ebf69c05) 
[EmbeddedControl] (20230628/evregion-130)
[ 1688.661963] ACPI Error: Region EmbeddedControl (ID=3) has no handler 
(20230628/exfldio-261)
[ 1688.661977] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1688.661997] ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1688.662013] ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q4F due to 
previous error (AE_NOT_EXIST) (20230628/psparse-529)
[ 1689.190075] ACPI Error: No handler for Region [ECSI] (ebf69c05) 
[EmbeddedControl] (20230628/evregion-130)
[ 1689.190097] ACPI Error: Region EmbeddedControl (ID=3) has no handler 
(20230628/exfldio-261)
[ 1689.190110] ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error 
(AE_NOT_EXIST) (20230628/psparse-529)
[ 1689.190130] ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error 

Bug#1067201: apt: Improved bash-completion for 'apt edit-sources'

[Peter Samuelson]

Package: apt
Version: 2.7.13
Severity: minor
Tags: patch

Attached are minor improvements to 'apt edit-sources' bash completion:

- Generate accurate '*.list' list of files, and omit '.list'
  suffixes. (I _would_ also list '*.sources', but current 'apt
  edit-sources' does not support this newer file format.)

- Quote filenames as needed

- Honor $APT_CONFIG by calling 'apt-config' instead of hardcoding
  /etc/apt/sources.list.d. (For efficiency, this is only in the
  'edit-sources' codepath.)

Quoting filenames seems like overkill, but _could_ matter for users
who maintain a separate non-default config under $HOME. (I do this in
order to make many additional 'deb-src' available, with corresponding
trusted keys, without encumbering the systemwide 'apt update'.)

Thanks,
Peter
--- a/completions/bash/apt
+++ b/completions/bash/apt
@@ -2,7 +2,6 @@
 
 _apt()
 {
-local sourcesdir="/etc/apt/sources.list.d"
 local cur prev words cword
 _init_completion || return
 
@@ -211,8 +210,13 @@
 return 0
 ;;
 edit-sources)
-COMPREPLY=( $( compgen -W '$( command ls $sourcesdir )' \
--- "$cur" ) )
+   mapfile -t COMPREPLY < <(
+eval $(apt-config shell root Dir etcapt Dir::Etc 
sourcesdir Dir::Etc::sourceparts)
+[[ $etcapt == /* ]] || etcapt=$root/$etcapt
+[[ $sourcesdir == /* ]] || sourcesdir=$etcapt/$sourcesdir
+IFS='
+' compgen -W "$(shopt -s nullglob; basename -s.list 
"$sourcesdir"/*.list)" -- "$cur")
+compopt -o filenames
 return 0
 ;;
 moo)

Bug#1067197: xserver-xorg-video-nouveau ftbfs

[Helge Deller]

The problem is that the hppa and powerpc buildds have an outdated
version of dpkg-dev installed, although a newer one has been available
for over a week.


Oh... yes.
Luckily I just updated the chroots a few hours ago.
Giving-back packet again to try.

Thanks!
Helge

Bug#1066136: NMU pending for #1066136

[Steinar H. Gunderson]

Control: tags 1066136 + pending

Hi,

I've prepared an NMU for python-xapian-haystack (versioned as
2.1.1-1+deb12u0.1) and uploaded it to DELAYED/14-day. (The unusually
long delay is since this is a stable upload.)

NMU diff is attached.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
diff -Nru python-xapian-haystack-2.1.1/debian/changelog python-xapian-haystack-2.1.1/debian/changelog
--- python-xapian-haystack-2.1.1/debian/changelog	2021-10-19 22:10:20.0 +0200
+++ python-xapian-haystack-2.1.1/debian/changelog	2024-03-19 23:35:19.0 +0100
@@ -1,3 +1,12 @@
+python-xapian-haystack (2.1.1-1+deb12u0.1) bookworm; urgency=medium
+
+  * Non-maintainer upload, to stable.
+  * Remove dependency on the django.utils.six module, which no longer exists,
+causing the package to be completely broken. Patch by Ole Peder Brandtzæg,
+based on reducing a patch from upstream. (Closes: #1066136)
+
+ -- Steinar H. Gunderson   Tue, 19 Mar 2024 23:35:19 +0100
+
 python-xapian-haystack (2.1.1-1) unstable; urgency=low
 
   [ Debian Janitor ]
diff -Nru python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch
--- python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch	1970-01-01 01:00:00.0 +0100
+++ python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch	2024-03-19 23:35:19.0 +0100
@@ -0,0 +1,32 @@
+Index: python-xapian-haystack-2.1.1/xapian_backend.py
+===
+--- python-xapian-haystack-2.1.1.orig/xapian_backend.py
 python-xapian-haystack-2.1.1/xapian_backend.py
+@@ -7,7 +7,6 @@ import re
+ import shutil
+ import sys
+ 
+-from django.utils import six
+ from django.conf import settings
+ from django.core.exceptions import ImproperlyConfigured
+ from django.utils.encoding import force_text
+@@ -346,7 +345,7 @@ class XapianSearchBackend(BaseSearchBack
+ def _get_ngram_lengths(value):
+ values = value.split()
+ for item in values:
+-for ngram_length in six.moves.range(NGRAM_MIN_LENGTH, NGRAM_MAX_LENGTH + 1):
++for ngram_length in range(NGRAM_MIN_LENGTH, NGRAM_MAX_LENGTH + 1):
+ yield item, ngram_length
+ 
+ for obj in iterable:
+@@ -356,8 +355,8 @@ class XapianSearchBackend(BaseSearchBack
+ def ngram_terms(value):
+ for item, length in _get_ngram_lengths(value):
+ item_length = len(item)
+-for start in six.moves.range(0, item_length - length + 1):
+-for size in six.moves.range(length, length + 1):
++for start in range(0, item_length - length + 1):
++for size in range(length, length + 1):
+ end = start + size
+ if end > item_length:
+ continue
diff -Nru python-xapian-haystack-2.1.1/debian/patches/series python-xapian-haystack-2.1.1/debian/patches/series
--- python-xapian-haystack-2.1.1/debian/patches/series	2021-10-19 22:10:20.0 +0200
+++ python-xapian-haystack-2.1.1/debian/patches/series	2024-03-19 23:35:19.0 +0100
@@ -1 +1,2 @@
 0001-Use-io.open-to-read-UTF-8-encoded-README-file.patch
+0002-Remove-dependency-on-six.patch

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

On Tue, 19 Mar 2024 at 22:55:31 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie :
> > Yes, the library is renamed on all architectures. (On architectures where
> > the ABI didn't actually break, like amd64, it Provides the old name.)
>
> So, in that case the most straightforward way to fix this would just
> be to rename the dependency to libgtk-3-0t64?

Yes, that'll be the simplest approach.

smcv

Bug#1067144: [3dprinter-general] Bug#1067144: uranium: missing depend on python3-all for autopkgtest

[Gregor Riepl]

Hi Timo,


your package has an autopkgtest regression due to changes in NumPy.
The python3-numpy package no longer depends on all supported Python
versions. You need to depend on python3-all if you want to run your
tests against all supported Python releases.


Can you elaborate why this dependency is needed in the first place?

It's the first time I heard that a python3 module package needs such an 
explicit dependency outside the Build-Depends.


I also don't think it makes sense to always install python3-all on every 
system that installs python3-uranium, just because autopkgtest needs it.
Shouldn't autopkgtest figure out by itself that this package is needed 
to run tests against all python versions?


(and if this is about Build-Depends - src:uranium has depended on 
python3-all since it existed)


Regards,
Gregor

Bug#1067200: RM: cython-legacy -- ROM; Legacy transition package no longer needed

[Julian Gilbey]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-pyt...@lists.debian.org

cython-legacy was introduced as a transitional measure until cython
version 3.x was supported by all source packages using cython.

There are now no source packages in unstable or testing (main)
depending on cython3-legacy and no binary packages either, so this
legacy package can be removed.  (It also has an RC bug against it, and
doesn't really work with Python 3.12.)

Best wishes,

   Julian

Bug#1053458: openstreetmap-carto-common: Configure step failed with FATAL: role "root" does not exist

[mx]

Package: openstreetmap-carto
Version: 5.7.0-1
Followup-For: Bug #1053458
X-Debbugs-Cc: mx...@hotmail.com

Dear Maintainer,

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

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

Versions of packages openstreetmap-carto depends on:
ii  debconf [debconf-2.0]   1.5.82
ii  dpkg1.21.22
ih  openstreetmap-carto-common  5.7.0-1

openstreetmap-carto recommends no packages.

openstreetmap-carto suggests no packages.

-- debconf information:
* openstreetmap-carto/database-name: gis

on the very first try to install this package i got a pop-up screen asking if i 
wanted to download the world data and plug 
it into postgres I mistakenly hit yes then aborted with ctrl-c (i already have 
the data from openstreetmap and did not want 
to wait 
days to redo it )

upon trying to dpkg-reconfigure openstreetmap-carto i get the error 
psycopg2.OperationalError: connection to server on 
socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "root" does not 
exist

which is understandable and proper .. i.e.  i am not postgres the trouble is 
*** there is no going back to that initial 
screen "asking if i wanted to download the world map into postgres " *** 

to make a short story long .. even after deleting/purging wiping out everything 
in /var/lib/dpkg/info/openstreetmap*
and trying to install again i never get that initial screen to bypass the 
download process ( which i think is the only real 
bug ) so a couple of thoughts

1- the package needs to start from the very beginning on a reconfigure i.e the 
user needs to be able choose to by-pass the 
download and database import (which SHOULD get rid of the role error which i 
assume you sudo into user postgres to 
accomplish or somesuch) 

2- the package needs to clean up whatever flag/files is uses to show that 
initial screen in apt/dpkg because once you use 
it, it never comes back even after a (near apparently) total wipe of the 
package apt-get remove apt-get purge, etc.. do not 
get it back ...

any help on actually getting back to the initial screen would be appreciated i 
have no clue why apt is by-passing that very 
first step shown to the user but at this point i have a broken package. Going 
to try find some stuff in ~ see if i can get 
back to the basics ...   

Bug#1067197: xserver-xorg-video-nouveau ftbfs

[Sven Joachim]

Control: severity -1 normal

Am 19.03.2024 um 22:15 schrieb Helge Deller:

> Source: xserver-xorg-video-nouveau
> Version: 1:1.0.17-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: del...@debian.org
>
> Failure can be seen on hppa architecture, but I assume it will show up on 
> armel too:

I don't think so, it has already been built on armhf.

> https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-nouveau=hppa=1%3A1.0.17-3=1710537593=0
>
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src
> -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
> -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/xorg
> -fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri
> -I/usr/include/libdrm -I/usr/include/libdrm
> -I/usr/include/libdrm/nouveau -I/usr/include/libdrm -g -O2
> -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -Wformat -Werror=format-security
> -Wall -I/usr/include/xorg -fvisibility=hidden -I/usr/include/pixman-1
> -I/usr/include/X11/dri -I/usr/include/libdrm -c ../../src/nv_shadow.c
> -fPIC -DPIC -o .libs/nv_shadow.o
> ../../src/nv_driver.c: In function ‘NVScreenInit’:
> ../../src/nv_driver.c:1451:23: error: implicit declaration of function
> ‘wfbScreenInit’; did you mean ‘fbScreenInit’?
> [-Werror=implicit-function-declaration]
>  1451 | ret = wfbScreenInit(pScreen, FBStart, pScrn->virtualX,
>   |   ^
>   |   fbScreenInit
> cc1: some warnings being treated as errors
> make[3]: *** [Makefile:674: nv_driver.lo] Error 1

The problem is that the hppa and powerpc buildds have an outdated
version of dpkg-dev installed, although a newer one has been available
for over a week.  I could and maybe should add dpkg-dev (>= 1.22.6) to
Build-Depends, but that is one more thing that needs to be reverted when
#1066968 gets fixed.

Cheers,
   Sven

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Matthias Klumpp]

Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie :
>
> On Tue, 19 Mar 2024 at 22:14:12 +0100, Matthias Klumpp wrote:
> > Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> > > libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> > > to be replaced by libgtk-3-0t64 after checking that the functions that
> > > interact with time_t (methods of GtkRecentInfo) are handled correctly.
> >
> > Will this be the new name on all platforms?
>
> Yes, the library is renamed on all architectures. (On architectures where
> the ABI didn't actually break, like amd64, it Provides the old name.)
>
> The same is true for essentially all of the libraries involved in this
> transition: there are hundreds of them.
>
> > Annoyingly, libgtkd does not depend on
> > libgtk properly on its own via linking it, and instead will dlopen it
> > at runtime.
>
> One way I've sometimes seen this handled is by making a list of the
> SONAMEs that will be dlopen'd, linking them into a dummy C executable
> with -Wl,--no-as-needed, and letting dpkg-shlibdeps inspect that executable
> and generate dependencies.

So, in that case the most straightforward way to fix this would just
be to rename the dependency to libgtk-3-0t64?
(making a mock library is possible, but I'd prefer the easiest way in
this case, as it's just one library...)

Bug#1064863: u-boot for riscv64 as included does not work in qemu

[Vagrant Cascadian]

Control: tags 1064863 - patch

On 2024-02-26, Martin Cracauer wrote:
> Package: u-boot-qemu
> Version: 2021.01+dfsg-5
> Severity: important
> Tags: patch

No patch was included, removing from tags.

> /usr/lib/u-boot/qemu-riscv64/u-boot.bin as included in this debian
> release does not work for booting in qemu for RISCV64, when combined
> with /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf (also from
> this debian version).  See below for qemu command line.
...
> Example qemu line showing the problem and solution.  Just exchange the
> two u-boot.bin's.  Note that the FreeBSD image is irrelevant here, the
> booting never reaches it.  I run this on Debian/amd64.
>
> qemu-system-riscv64 \
>   -M virt \
>   -smp 8 \
>   -m 32G \
>   -nographic \
>   -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
>   -kernel u-boot.bin \
>   -drive file=FreeBSD-14.0-RELEASE-riscv-riscv64.raw,format=raw,id=hd0 \
>   -device virtio-blk-device,drive=hd0 \
>   -nographic \
>   -netdev user,id=net0,ipv6=off,hostfwd=tcp::3234-:22 \
>   -device virtio-net-device,netdev=net0 \
>   -device virtio-rng-pci

Does this work with current versions of u-boot in Debian, e.g. u-boot
2023.01+dfsg-2 from debian bookworm/stable or 2024.01+dfsg-1 from debian
trixie/testing?

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1067098: mpl-sphinx-theme: please make the build reproducible

[Vagrant Cascadian]

On 2024-03-18, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed that
> mpl-sphinx-theme could not be built reproducibly.
>
> This is because it embedded the build date in the documentation:
...
> --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0 
> +0100
> --- b/debian/patches/reproducible-build.patch 2024-03-18 12:59:19.650123651 
> +
> @@ -0,0 +1,28 @@
> +Description: Make the build reproducible
> +Author: Chris Lamb 
> +Last-Update: 2024-03-18
> +
> +--- mpl-sphinx-theme-3.5.0.orig/docs/conf.py
>  mpl-sphinx-theme-3.5.0/docs/conf.py
> +@@ -1,5 +1,12 @@
> ++import os
> ++import time
> + import datetime
> + 
> ++build_date = datetime.datetime.fromtimestamp(
> ++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
> ++tz=datetime.timezone.utc,
> ++)
> ++
> + # Configuration file for the Sphinx documentation builder for
> + # matplotlib projects.
> + 
> +@@ -10,7 +17,7 @@ is_release_build = tags.has('release')
> + 
> + project = "Matplotlib Sphinx Theme"
> + copyright = (
> +-f"2012 - {datetime.datetime.now().year} The Matplotlib development team"
> ++f"2012 - {build_date.year} The Matplotlib development team"
> + )
> + author = "Matplotlib Developers"
> + 
> --- a/debian/patches/series   1970-01-01 01:00:00.0 +0100
> --- b/debian/patches/series   2024-03-18 12:59:16.218124536 +
> @@ -0,0 +1 @@
> +reproducible-build.patch

FWIW, I uploaded an NMU fixing this based on your earlier patch, but it
was reverted when the maintainer attempted to orphan the package without
incorporating the NMU...

  https://bugs.debian.org/1005826
  https://bugs.debian.org/1065042

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1063097: /usr/bin/mkimage: opens image and device trees (-d, -b) O_RDONLY, then O_RDWR, and fails if they're read-only (it doesn't write to them)

[Vagrant Cascadian]

On 2024-02-05, наб wrote:
> From a strace:
>   1390  openat(AT_FDCWD, "/tmp/tmp.j2DX6x1MgV/Image-6.6.11.lz4", O_RDONLY) = 3
>   1390  newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12611929, ...}, 
> AT_EMPTY_PATH) = 0
>   1390  close(3)  = 0
>   1390  openat(AT_FDCWD, "mt8173-elm-hana-6.6.11.dtb", O_RDONLY) = 3
>   1390  newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=43853, ...}, 
> AT_EMPTY_PATH) = 0
>   1390  close(3)  = 0
>   1390  mmap(NULL, 12660736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
> -1, 0) = 0xafecd000
>   1390  openat(AT_FDCWD, "/tmp/tmp.j2DX6x1MgV/Image-6.6.11.lz4", O_RDWR) = 3
>   1390  newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12611929, ...}, 
> AT_EMPTY_PATH) = 0
>   1390  read(3, "\4\"M\30dp\271\361K!\0\225\37 \3\325'\360X\24\0\1\0 
> \243\1\6\0/\n\0\1"..., 12611929) = 12611929
>   1390  close(3)  = 0
>   1390  openat(AT_FDCWD, "mt8173-elm-hana-6.6.11.dtb", O_RDWR) = -1 EACCES 
> (Permission denied)
>   1390  write(2, "mkimage: Can't open mt8173-elm-h"..., 66) = 66
>   1390  write(2, "mkimage: Failed to build FIT ima"..., 35) = 35
>   1390  munmap(0xafecd000, 12660736)  = 0
> here, the dtb is unwritable.
>
> An analogous error happens if the Image is unwritable,
> but as we can see here, it doesn't write to it anyway.
> (Nor should it, given this is an input file.)
>
> Please turn this into an O_RDONLY.

It would be helpful to list the exact command you are running, although
best to take this upstream.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1067199: RFS: bleachbit/4.6.0-3 [ITA] [RC] -- delete unnecessary files from the system

[Fabio Fantoni]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : bleachbit
   Version  : 4.6.0-3
   Upstream contact : Andrew Ziem 
 * URL  : https://www.bleachbit.org/
 * License  : CC0-1.0, GPL-3+
 * Vcs  : 
https://salsa.debian.org/python-team/packages/bleachbit

   Section  : admin

The source builds the following binary packages:

  bleachbit - delete unnecessary files from the system

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bleachbit/bleachbit_4.6.0-3.dsc


Changes since the last upload:

 bleachbit (4.6.0-3) unstable; urgency=medium
 .
   * Return to Debian Python Team and add myself to uploaders (Closes: 
#1065808)

   * Remove libgtk-3-0 from depends (Closes: #1067171)

Regards,
--
  Fabio Fantoni

Bug#1067198: libgts-0.7-5t64: emits shlib dependencies on libgts-0.7-5

[Thorsten Glaser]

Package: libgts-0.7-5t64
Version: 0.7.6+darcs121130-5.1
Severity: grave
Justification: uninstallable
X-Debbugs-Cc: t...@mirbsd.de, vor...@debian.org
Control: affects -1 src:graphviz libgvc6

When building against libgts-0.7-5t64, the generated packages
get a shlib:Depends of 'libgts-0.7-5 (>= 0.7.6)' instead of
the expected libgts-0.7-5t64.

This is probably because the shlibs…

| libgts-0.7 5 libgts-0.7-5t64 (>= 0.7.6+darcs121130)

… and symbols…

| libgts-0.7.so.5 libgts-0.7-5 #MINVER#
|  gts_allow_floating_edges@Base 0.7.6
[…]

… control files disagree.

This is a t64 transition showstopper (vala B-D graphviz).

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

On Tue, 19 Mar 2024 at 22:14:12 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> > libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> > to be replaced by libgtk-3-0t64 after checking that the functions that
> > interact with time_t (methods of GtkRecentInfo) are handled correctly.
> 
> Will this be the new name on all platforms?

Yes, the library is renamed on all architectures. (On architectures where
the ABI didn't actually break, like amd64, it Provides the old name.)

The same is true for essentially all of the libraries involved in this
transition: there are hundreds of them.

> Annoyingly, libgtkd does not depend on
> libgtk properly on its own via linking it, and instead will dlopen it
> at runtime.

One way I've sometimes seen this handled is by making a list of the
SONAMEs that will be dlopen'd, linking them into a dummy C executable
with -Wl,--no-as-needed, and letting dpkg-shlibdeps inspect that executable
and generate dependencies.

smcv

Bug#1067028: RFS: emacs-buttercup/1.34-1 [Team] -- behaviour-driven testing for Emacs Lisp packages

[Jeremy Sowden]

On 2024-03-16, at 23:38:58 -0700, Xiyue Deng wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "emacs-buttercup":
> 
>  * Package name : emacs-buttercup
>Version  : 1.34-1
>Upstream contact : [fill in name and email of upstream]
>  * URL  : https://github.com/jorgenschaefer/emacs-buttercup/
>  * License  : GFDL-1.2+ or CC-BY-SA-3.0, GPL-3+
>  * Vcs  : https://salsa.debian.org/emacsen-team/emacs-buttercup
>Section  : lisp
> 
> The source builds the following binary packages:
> 
>   elpa-buttercup - behaviour-driven testing for Emacs Lisp packages
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/emacs-buttercup/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.34-1.dsc
> 
> Changes since the last upload:
> 
>  emacs-buttercup (1.34-1) unstable; urgency=medium
>  .
>* Team upload
>* New upstream release
>* Migrate to debhelper-compat version 13

LGTM.  Will upload shortly.

J.


signature.asc
Description: PGP signature

Bug#1067197: xserver-xorg-video-nouveau ftbfs

[Helge Deller]

Source: xserver-xorg-video-nouveau
Version: 1:1.0.17-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: del...@debian.org

Failure can be seen on hppa architecture, but I assume it will show up on armel 
too:

https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-nouveau=hppa=1%3A1.0.17-3=1710537593=0

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/xorg 
-fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri -I/usr/include/libdrm 
-I/usr/include/libdrm -I/usr/include/libdrm/nouveau -I/usr/include/libdrm -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-Wformat -Werror=format-security -Wall -I/usr/include/xorg -fvisibility=hidden 
-I/usr/include/pixman-1 -I/usr/include/X11/dri -I/usr/include/libdrm -c 
../../src/nv_shadow.c  -fPIC -DPIC -o .libs/nv_shadow.o
../../src/nv_driver.c: In function ‘NVScreenInit’:
../../src/nv_driver.c:1451:23: error: implicit declaration of function 
‘wfbScreenInit’; did you mean ‘fbScreenInit’? 
[-Werror=implicit-function-declaration]
 1451 | ret = wfbScreenInit(pScreen, FBStart, pScrn->virtualX,
  |   ^
  |   fbScreenInit
cc1: some warnings being treated as errors
make[3]: *** [Makefile:674: nv_driver.lo] Error 1

Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects

[Thorsten Glaser]

Package: qpdf
Version: 10.1.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de, n...@naturalnet.de

The qpdf documentation states that it is possible to remove an object
then run fix-qdf and it should renumber the remaining objects.

In an exemplary PDF, I did this:

- qpdf --qdf dings.pdf dings.qdf
- $EDITOR dings.qdf
- remove object '38 0' and the one reference to it
- fix-qdf dings.qdf >dings2.qdf

It complained about the missing object:

dings.qdf:20254: expected object 38

Line 20254 here is exactly the beginning of object '39 0'
after the end of object '37 0'.

──┤ Workaround ├

Just removing all the references and letting qpdf clean up the
now-unreferenced object seems to have worked here.

But this does still not work as documented…


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

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

Versions of packages qpdf depends on:
ii  libc6   2.31-13+deb11u8
ii  libgcc-s1   10.2.1-6
ii  libqpdf28   10.1.0-1
ii  libstdc++6  10.2.1-6

qpdf recommends no packages.

qpdf suggests no packages.

-- no debconf information

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Matthias Klumpp]

Hi Simon!

Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> to be replaced by libgtk-3-0t64 after checking that the functions that
> interact with time_t (methods of GtkRecentInfo) are handled correctly.

Will this be the new name on all platforms? If not, can we detect the
name automatically somehow? Annoyingly, libgtkd does not depend on
libgtk properly on its own via linking it, and instead will dlopen it
at runtime. So that dependency has to be added manually for the Debian
package.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1067195: fzf: Please package 0.48.x

[Kai Weber]

Package: fzf
Version: 0.44.1-1
Severity: wishlist

Dear Maintainers,

please consider packaging and releasing 0.48.x which was released some days ago.
This version introduces an easy way to integrate and configure fzf:

# in .bashrc
eval $(fzf --bash)

This will make it easier to configure cross-platform dotfiles and Debian
no longer has to ship the configuration files cause it is build into the
binary.

Regards, Kai

Bug#1064967: fontforge DSA (was: Re: Bug#1064967: fontforge: diff for NMU version 1:20230101~dfsg-1.1)

[Salvatore Bonaccorso]

Hi Adrian,

On Sat, Mar 16, 2024 at 12:12:01AM +0200, Adrian Bunk wrote:
> On Wed, Mar 13, 2024 at 08:39:47PM +0100, Salvatore Bonaccorso wrote:
> > Hi Adrian,
> 
> Hi Salvatore,
> 
> > On Fri, Mar 08, 2024 at 02:03:55AM +0200, Adrian Bunk wrote:
> > > Control: tags 1064967 + patch
> > > Control: tags 1064967 + pending
> > > 
> > > Dear maintainer,
> > > 
> > > I've prepared an NMU for fontforge (versioned as 1:20230101~dfsg-1.1) and
> > > uploaded it to DELAYED/2. Please feel free to tell me if I should cancel 
> > > it.
> > > 
> > > @Security team:
> > > If wanted, I could afterwards also prepare (pu or DSA) updates for 
> > > bookworm and bullseye.
> > 
> > We came to the conclusion that it warrants a DSA. Could you prepare
> > debdiffs for bookworm-security and bulseye-security?
> 
> the debdiffs are attached.
> 
> Tested on both releases with the PoCs from [1] and that opening a normal 
> compressed font still works.

DSA for your work released.

Thanks for your contribution!

Regards,
Salvatore

Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Tue, 19 Mar 2024 at 21:37, Bastian Germann  wrote:

>
> As nobody has provided any patch yet and I do not have an idea how to use
> gnulib properly generally and in Debian
> context, I came up with this. I have actually tried to use Debian's gnulib
> but could not get the thing to work.
>

Fair enough. From my point of view, I don't think your patch should
introduce any functional problem.

I think this will end up in syntax errors but you can try. The obvious fix
> for me would be putting the quotation marks
> around each of the three format strings that the quoted strings are
> inserted in.
>

Ah, you're quite right as the arguments to quote() are variables. Your fix
works for me. The result is just a minor cosmetic deficiency compared to
upstream.

-- 
https://rrt.sc3d.org

Bug#1067194: ITP: ansible-creator -- fastest way to generate all your ansible content

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com

* Package name: ansible-creator
  Version : 24.2.0
  Upstream Contact: Ansible by Red Hat 
* URL : https://github.com/ansible/ansible-creator
* License : Apache 2.0
  Programming Lang: Python
  Description : fastest way to generate all your ansible content

 CLI tool for scaffolding all your Ansible Content. This package
 is a Command-Line Interface (CLI) tool designed for effortless scaffolding
 all your Ansible content. Used to initializing an Ansible collection or
 creating a framework for specific plugins, this tool streamlines the process
 with efficiency, standard and precision based on your requirements.

Bug#1065951: vde: FTBFS on arm{el,hf}: /tmp/ccwOo5J4.s:341: Error: symbol `open64' is already defined

[Michael Hudson-Doyle]

Package: vde2
Version: 2.3.2+r586-9.1
Followup-For: Bug #1065951
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Undefine _FILE_OFFSET_BITS and _TIME_BITS in libvdetap.c so the library's
interposition of open/open64 still works.


Thanks for considering the patch.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru vde2-2.3.2+r586/debian/patches/interposition-vs-lfs.patch 
vde2-2.3.2+r586/debian/patches/interposition-vs-lfs.patch
--- vde2-2.3.2+r586/debian/patches/interposition-vs-lfs.patch   1970-01-01 
12:00:00.0 +1200
+++ vde2-2.3.2+r586/debian/patches/interposition-vs-lfs.patch   2024-03-20 
09:33:55.0 +1300
@@ -0,0 +1,22 @@
+Description: Undo lfs/time64 defines in libvdetap.c
+ Building with these macros defines interferes with this files attempt to
+ interpose both open and open64
+Author: Michael Hudson-Doyle 
+Forwarded: no
+Last-Update: 2024-03-20
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/vdetaplib/libvdetap.c
 b/src/vdetaplib/libvdetap.c
+@@ -1,6 +1,11 @@
+ /* Copyright 2004 Renzo Davoli
+  * Reseased under the GPLv2 */
+ 
++/* Building with these macros defines interferes with this files attempt to
++   interpose both open and open64 */
++#undef _FILE_OFFSET_BITS
++#undef _TIME_BITS
++
+ #define _GNU_SOURCE
+ #include 
+ #include 
diff -Nru vde2-2.3.2+r586/debian/patches/series 
vde2-2.3.2+r586/debian/patches/series
--- vde2-2.3.2+r586/debian/patches/series   2020-01-31 00:43:23.0 
+1300
+++ vde2-2.3.2+r586/debian/patches/series   2024-03-20 09:33:55.0 
+1300
@@ -5,3 +5,4 @@
 vdeterm_terminal_reset.patch
 fix_qtime_hash_gc_race_condition.patch
 vde_cryptcab-compile-against-openssl-1.1.0.patch
+interposition-vs-lfs.patch

Bug#1067193: meld: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: meld
Version: 3.22.1-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

meld is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtksource-4 and gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0, and replace it
with gir1.2-gtk-3.0 if appropriate. For Python code that uses GTK via
GObject-Introspection, it is sufficient to depend on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1065122: hydrapaper: Please package new version 3.3.2

[Francisco M Neto]

Thank you for notifying me. 

I'll work on updating the package.

Thanks
Francisco

On Thu, 2024-02-29 at 17:28 -0500, Boyuan Yang wrote:
> Source: hydrapaper
> X-Debbugs-Cc: by...@debian.org
> Version: 3.3.1-2
> Severity: normal
> 
> Dear Debian hydrapaper package Maintainer,
> 
> A new upstream release of hydrapaper is available at
> https://gitlab.com/gabmus/HydraPaper/-/tags/3.3.2 .
> Please consider packaging it. Thanks!
> 
> Best,
> Boyuan Yang



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

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Source: gtk-d
Version: 3.10.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
to be replaced by libgtk-3-0t64 after checking that the functions that
interact with time_t (methods of GtkRecentInfo) are handled correctly.

There might be other library dependencies in a similar situation: I suggest
using this bug report to represent all of them, rather than having multiple
bugs to track this.

More information about this transition is available on
.

Thanks,
smcv

Bug#727656: Status of libpaper fork

[Bastian Germann]

Am 19.03.24 um 00:20 schrieb Reuben Thomas:

On Mon, 18 Mar 2024 at 23:33, Bastian Germann mailto:b...@debian.org>> wrote:

Hi,

I have updated the salsa repo to build without gnulib.


Fantastic, thanks for doing this!

I am a little puzzled, I thought that the idea was to build with Debian gnulib? 
I think that could be a simpler patch.


As nobody has provided any patch yet and I do not have an idea how to use gnulib properly generally and in Debian 
context, I came up with this. I have actually tried to use Debian's gnulib but could not get the thing to work.


Looking at the patches, nothing seems really a problem though, except that `quote(q)` should put single quotation marks 
around its argument. You could use ASCII apostrophe for this:


#define quote(q) "'" q "'"


I think this will end up in syntax errors but you can try. The obvious fix for me would be putting the quotation marks 
around each of the three format strings that the quoted strings are inserted in.

Bug#1067191: gnome-subtitles: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: gnome-subtitles
Version: 1.8-1
Severity: serious
Justification: 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t

gnome-subtitles has a hard-coded dependency on libgtk-3-0, which needs to
be replaced with libgtk-3-0t64 as part of the 64-bit time_t transition.
When doing this, please check that it doesn't call any functions from
GTK that take a time_t argument or return a time_t (the affected methods
all involve GtkRecentInfo, please see
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-26T12%3A07%3A00/compat_reports/libgtk-3-dev/lfs_to_time_t/compat_report.html
for full details).

This is mostly a theoretical concern because gnome-subtitles is already
excluded from testing as a result of an unrelated RC bug #1053529.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067190: timekpr-next: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: timekpr-next
Version: 0.5.4-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

timekpr-next is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067189: syncthing-gtk: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: syncthing-gtk
Version: 0.9.4.4+ds+git20221205+12a9702d29ab-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

syncthing-gtk is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067188: gdb-mingw-w64: FTBFS in trixie

[Santiago Vila]

Package: src:gdb-mingw-w64
Version: 13.1
Severity: serious
Tags: ftbfs

Dear maintainer:

This package FTBFS in trixie with internal compiler error, and that
has been the case for several months now.

https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/gdb-mingw-w64.html

Naturally, the bug is probably in one of the build-dependencies, maybe 
gcc-mingw-w64
but I'm not 100% sure.

So, this bug needs a reassign, please use "affects  src:gdb-mingw-w64" after
reassign, as the purpose of this report is to make sure that the bug appears 
here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gdb-mingw-w64

(That way, anybody doing QA work in trixie will know that the fact that this
package ftbfs in trixie is already known)

Thanks.

Bug#1067187: ITP: golang-github-lmittmann-tint -- slog.Handler that writes tinted (colorized) logs

[Daniel Swarbrick]

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

* Package name: golang-github-lmittmann-tint
  Version : 1.0.4
  Upstream Contact: lmittmann 
* URL : https://github.com/lmittmann/tint
* License : Expat
  Programming Lang: Go
  Description : slog.Handler that writes tinted (colorized) logs

tint implements a zero-dependency slog.Handler that writes tinted
(colorized) logs. Its output format is inspired by the
zerolog.ConsoleWriter and slog.TextHandler.

I am packaging this primarily for my own selfish reasons, however I can
see it being useful to other Go packages which may wish to import it in
future. I will maintain it as a member of the Debian Go Packaging team.

Bug#1067186: Fwd: [Podman] Podman v5.0.0 Released

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Matt Heon 
Date: Tue, Mar 19, 2024, 19:13
Subject: [Podman] Podman v5.0.0 Released
To: , Podman List 


Hi all,

Podman v5.0.0 has just been released. This is our first major version bump
in two years, and comes with a large number of new features and swapped
defaults, including a complete rewrite of `podman machine` to improve
stability and performance. Full details are available in the release notes
[1].

We've been working on 5.0 for months now and are excited to get it out into
people's hands. Try it out and let us know what you think!

Thanks,
Matt Heon

[1] https://github.com/containers/podman/releases/tag/v5.0.0
___
Podman mailing list -- pod...@lists.podman.io
To unsubscribe send an email to podman-le...@lists.podman.io

Bug#1067185: ticcutils: Cannot upload to experimental

[Bastian Germann]

Package: ftp.debian.org

Hi,

In the last weeks I have tried several times to upload a new ticcutils release 
to experimental.
The uploads included both the package source and binaries signed by my usual 
OpenPGP key.

This is the package revision that I have tried to upload:
https://salsa.debian.org/science-team/libticcutils/-/tree/debian/0.34-1

I have never received any emails that my upload was accepted and have not seen 
any hint why the uploads are ignored.
Can you please tell me what the problem is?

Thanks,
Bastian

Bug#1067184: ITP: krecorder -- recorder application

[Salvo Tomaselli]

Package: wnpp
Severity: wishlist
Owner: Salvo Tomaselli 
X-Debbugs-Cc: debian-de...@lists.debian.org, ltw...@debian.org

* Package name: krecorder
  Version : 24.02.0
  Upstream Contact: Devin Lin 
* URL : https://apps.kde.org/it/krecorder/
* License : GPL
  Programming Lang: C++
  Description : recorder application
kirigami based audio recorder for plasma.
It can be used on small touchscreens or on desktop

Bug#1064028: libpython3.12-dev: non-C90 headerfile code breaks -Werror=declaration-after-statement

[James Addison]

Followup-For: Bug #1064028
Control: tags -1 fixed-upstream
Control: forwarded -1 https://github.com/python/cpython/issues/116869 
https://github.com/python/cpython/pull/117011

Bug#1067183: ITP: skladnik -- formerly known as ksokoban, a sokoban game

[Salvo Tomaselli]

Package: wnpp
Severity: wishlist
Owner: Salvo Tomaselli 
X-Debbugs-Cc: debian-de...@lists.debian.org, ltw...@debian.org

* Package name: skladnik
  Version : 0.5.2
  Upstream Contact:  Łukasz Kalamłacki 
* URL : https://apps.kde.org/it/skladnik/
* License : GPL
  Programming Lang: C++
  Description : formerly known as ksokoban, a sokoban game
The usual sokoban game, about pushing things on a destination
inside a maze.

Bug#1067182: node-with: Typo in package description

[Thomas Vincent]

Package: node-with
Severity: minor

Dear Maintainer,

The second paragraph of node-with description contains a typo.
I believe it should be 'The `with` statement' instead of 'The `width` 
statement' (notice the d).

Thanks for maintaining node-with!
Thomas


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

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

Versions of packages node-with depends on:
pn  node-babel7  

node-with recommends no packages.

node-with suggests no packages.

Bug#1067161: nftables: BUG: invalid mapping expression variable

[Jeremy Sowden]

On 2024-03-19, at 16:00:28 +0100, Daniel Gröber wrote:
> Package: nftables
> Version: 1.0.6-2+deb12u2
> Severity: normal
> 
> Dear Maintainer,
> 
> The nftables config below triggers a BUG.
> 
> $ nft -f /etc/nftables.conf
> BUG: invalid mapping expression variable
> nft: evaluate.c:1797: expr_evaluate_map: Assertion `0' failed.
> Aborted
> 
> Refactoring to using $srvaddr_map instead of having the anonymous map
> inline made the bug trigger.

That assertion has since been replaced upstream by a normal
error-message:

  /space/azazel/tmp/ruleset.1067161.nft:6:58-69: Error: invalid mapping 
expression variable
ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map 
$srvaddr_map
~~ 


> -- Configuration Files:
> /etc/nftables.conf changed:
> flush ruleset
> define iid_mask6 = :::::
> define srvaddr_map = { ::8384 : 8384 }
> table inet filter {
>   chain input {
>   type filter hook input priority filter;
>   }
>   chain prerouting {
>   type nat hook prerouting priority dstnat;
>   ip6 nexthdr tcp  redirect to ip6 daddr & $iid_mask6 map 
> $srvaddr_map # s/ map.*/{ ::8384 : 8384 }/  works
>   }
>   chain forward {
>   type filter hook forward priority filter;
>   }
>   chain output {
>   type filter hook output priority filter;
>   }
> }

Because of the way parsing works in nftables, one can't use a symbolic
variable in that context.  This, however, will work:

  define iid_mask6 = :::::
  define srvaddr_map = { ::8384 : 8384 }
  table inet filter {
map srvaddr_map {
  typeof ip6 daddr : tcp dport;
  elements = $srvaddr_map
}
chain prerouting {
  type nat hook prerouting priority dstnat;
  ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map @srvaddr_map
}
  }

or more concisely:

  define iid_mask6 = :::::
  table inet filter {
map srvaddr_map {
  typeof ip6 daddr : tcp dport;
  elements = srvaddr_map = { ::8384 : 8384 }
}
chain prerouting {
  type nat hook prerouting priority dstnat;
  ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map @srvaddr_map
}
  }

J.


signature.asc
Description: PGP signature

Bug#1066889: netplan.io 1.0 package build requires newer mason than in build deps

[Lukas Märdian]

On Thu, 14 Mar 2024 16:37:40 -0700 tessa  wrote:
> Package: netplan.io
> Version: 1.0-1
> Severity: normal
>
> I discovered this minor packaging issue while attempting to backport the
1.0-1 package to bookworm.
> It appears as if the build deps list meson >= 0.61.0, but in actuality
the build requires features from
> 1.3.0, and the build itself calls this out:
>
> WARNING: Project specifies a minimum meson_version '>= 0.61.0' but uses
features which were added in newer versions:
>  * 1.3.0: {'limited_api arg in python.extension_module'}
>
> probably just needs a build-dep update.

Thanks for the report!

This will be addressed with the next upload.
https://salsa.debian.org/debian/netplan.io/-/commit/a1c5beda96880d8d2009e82c44e5d2423841c0fd

Cheers,
  Lukas

Bug#1067180: fastdds: CVE-2024-26369

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for fastdds.

CVE-2024-26369[0]:
| An issue in the HistoryQosPolicy component of FastDDS v2.12.x,
| v2.11.x, v2.10.x, and v2.6.x leads to a SIGABRT (signal abort) upon
| receiving DataWriter's data.

https://github.com/eProsima/Fast-DDS/issues/4365
https://github.com/eProsima/Fast-DDS/pull/4375

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1067179: ldap-account-manager: CVE-2024-23333

[Moritz Mühlenhoff]

Source: ldap-account-manager
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for ldap-account-manager.

CVE-2024-2[0]:
| LDAP Account Manager (LAM) is a webfrontend for managing entries
| stored in an LDAP directory. LAM's log configuration allows to
| specify arbitrary paths for log files. Prior to version 8.7, an
| attacker could exploit this by creating a PHP file and cause LAM to
| log some PHP code to this file. When the file is then accessed via
| web the code would be executed. The issue is mitigated by the
| following: An attacker needs to know LAM's master configuration
| password to be able to change the main settings; and the webserver
| needs write access to a directory that is accessible via web. LAM
| itself does not provide any such directories. The issue has been
| fixed in 8.7. As a workaround, limit access to LAM configuration
| pages to authorized users.

https://github.com/LDAPAccountManager/lam/security/advisories/GHSA-fm9w-7m7v-wxqv


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1067178: clickhouse: CVE-2024-22412

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for clickhouse.

CVE-2024-22412[0]:
| ClickHouse is an open-source column-oriented database management
| system. A bug exists in the cloud ClickHouse offering prior to
| version 24.0.2.54535 and in github.com/clickhouse/clickhouse version
| 23.1. Query caching bypasses the role based access controls and the
| policies being enforced on roles. In affected versions, the query
| cache only respects separate users, however this is not documented
| and not expected behavior. People relying on ClickHouse roles can
| have their access control lists bypassed if they are using query
| caching. Attackers who have control of a role could guess queries
| and see data they shouldn't have access to. Version 24.1 of
| ClickHouse and version 24.0.2.54535 of ClickHouse Cloud contain a
| patch for this issue. Based on the documentation, role based access
| control should be enforced regardless if query caching is enabled or
| not.

https://github.com/ClickHouse/ClickHouse/security/advisories/GHSA-45h5-f7g3-gr8r
https://github.com/ClickHouse/ClickHouse/pull/58611


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1067177: black: CVE-2024-21503

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for black.

CVE-2024-21503[0]:
| Versions of the package black before 24.3.0 are vulnerable to
| Regular Expression Denial of Service (ReDoS) via the
| lines_with_leading_tabs_expanded function in the strings.py file. An
| attacker could exploit this vulnerability by crafting a malicious
| input that causes a denial of service.  Exploiting this
| vulnerability is possible when running Black on untrusted input, or
| if you habitually put thousands of leading tab characters in your
| docstrings.

https://security.snyk.io/vuln/SNYK-PYTHON-BLACK-6256273
https://github.com/psf/black/releases/tag/24.3.0
https://github.com/psf/black/commit/f00093672628d212b8965a8993cee8bedf5fe9b8


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1066794: git: FTBFS: tests failed

[Andrey Rakhmatullin]

Not sure which tests actually failed (it's really hard to understand the
output) but also I cannot reproduce this locally in sbuild, with -j1 or
-j4 and with or without --no-arch-any.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1067176: protobuf: diff for NMU version 3.21.12-8.2

[Andrey Rakhmatullin]

Package: protobuf
Version: 3.21.12-8.1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for protobuf (versioned as 3.21.12-8.2) and
uploaded it to unstable.

Regards.


-- 
WBR, wRAR
diff -Nru protobuf-3.21.12/debian/changelog protobuf-3.21.12/debian/changelog
--- protobuf-3.21.12/debian/changelog	2024-03-01 02:15:00.0 +0500
+++ protobuf-3.21.12/debian/changelog	2024-03-19 22:24:42.0 +0500
@@ -1,3 +1,11 @@
+protobuf (3.21.12-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move dh-elpa and pkg-php-tools to B-D-Indep (Closes: #1062840, #1062847).
+  * Fix /usr/share/doc/{libprotoc,libprotobuf}-dev symlinks.
+
+ -- Andrey Rakhmatullin   Tue, 19 Mar 2024 22:24:42 +0500
+
 protobuf (3.21.12-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru protobuf-3.21.12/debian/control protobuf-3.21.12/debian/control
--- protobuf-3.21.12/debian/control	2024-03-01 02:15:00.0 +0500
+++ protobuf-3.21.12/debian/control	2024-03-19 21:32:54.0 +0500
@@ -5,7 +5,6 @@
 Build-Depends: dpkg-dev (>= 1.22.5),
 # Debian build system
debhelper-compat (= 13)
- , dh-elpa [amd64 arm64 armel armhf i386 loong64 mips64el mipsel ppc64el s390x hppa ppc64 riscv64 sh4 sparc64 x32]
 # C/C++
  , zlib1g-dev
  , libgmock-dev 
@@ -23,16 +22,17 @@
 # Ruby
  , rake-compiler 
  , gem2deb 
-# PHP
- , pkg-php-tools (>= 1.7~)
 Build-Depends-Indep:
+   dh-sequence-elpa
 # Java
-   ant
+ , ant
  , default-jdk
  , javahelper
  , maven-repo-helper
  , libguava-java
  , libgoogle-gson-java
+# PHP
+ , pkg-php-tools (>= 1.7~)
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://github.com/google/protobuf/
diff -Nru protobuf-3.21.12/debian/rules protobuf-3.21.12/debian/rules
--- protobuf-3.21.12/debian/rules	2023-11-08 21:59:09.0 +0500
+++ protobuf-3.21.12/debian/rules	2024-03-19 22:23:42.0 +0500
@@ -19,11 +19,7 @@
 API_VERSION=$(SONAME)-0
 
 %:
-ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 loong64 mips64el mipsel ppc64el s390x hppa ppc64 riscv64 sh4 sparc64 x32))
-	dh $@ --with autoreconf,elpa
-else
-	dh $@ --with autoreconf -Nelpa-protobuf-mode
-endif
+	dh $@
 
 ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
 override_dh_auto_configure:
@@ -162,9 +158,9 @@
 
 	# Convert doc dir to symlink for the -dev packages
 	$(RM) -r $(CURDIR)/debian/libprotobuf-dev/usr/share/doc/libprotobuf-dev
-	ln -s libprotobuf$(SONAME) $(CURDIR)/debian/libprotobuf-dev/usr/share/doc/libprotobuf-dev
+	ln -s libprotobuf$(SONAME)t64 $(CURDIR)/debian/libprotobuf-dev/usr/share/doc/libprotobuf-dev
 	$(RM) -r $(CURDIR)/debian/libprotoc-dev/usr/share/doc/libprotoc-dev
-	ln -s libprotoc$(SONAME) $(CURDIR)/debian/libprotoc-dev/usr/share/doc/libprotoc-dev
+	ln -s libprotoc$(SONAME)t64 $(CURDIR)/debian/libprotoc-dev/usr/share/doc/libprotoc-dev
 
 	# Remove compiler headers from libprotobuf-dev
 	$(RM) -r $(CURDIR)/debian/libprotobuf-dev/usr/include/google/protobuf/compiler


signature.asc
Description: PGP signature

Bug#848194: Want way to get Release (or InRelease) file from cache

[Julian Andres Klode]

On Tue, Mar 19, 2024 at 04:51:35PM +, Colin Watson wrote:
> Hi,
> 
> I don't know if it helps or hinders this bug since I have rather
> different reasons from Ian, but I found myself looking at this bug today
> because I also wanted a way to get hold of an [In]Release file.  The
> difference is that I'm not trying to get hold of it for a particular
> package, but for (roughly) a sources.list entry; but all my other
> requirements seem basically the same as Ian's.  My use case is as
> follows, and you can tell me if it's too different to include in the
> same report:
> 
>  * In order to be able to implement an "import the contents of this
>repository into our database" task in debusine
>(https://freexian-team.pages.debian.net/debusine/), I want to
>discover which architectures are supported by a given suite in a
>repository, assuming that it has at least a Release file.  And of
>course then I want to be able to fetch all the files, but at least
>that part isn't so hard.
> 
>  * If you already know which architectures you want, then this is easy.
>But if you want to ask the repository which architectures it
>supports, as far as I know the only sensible way is to consult the
>Release file.
> 
>  * Acquiring and verifying Release files correctly is, as I'm sure you
>know, challenging.  I would like to avoid writing my own code to call
>gpgv in just the right way (again).  I've been here before with
>#918304.
> 
>  * I'd hoped to use python-debian, but its GPG verification support is
>currently not as good as it should be (#710923) and in any case what
>you get from its Release file handling is not very helpful
>(#1067160).
> 
>  * So I looked at apt/python-apt.  I know how to instantiate a temporary
>apt cache with its own configuration (in the manner of chdist(1), for
>instance), and if I could discover the available architectures after
>an initial fetch then I could call "apt-get update" a second time
>with APT::Architectures set and then I'd have everything.  However,
>given a cache, I seem to be able to access basically everything
>_except_ for the Release file in documented ways.  As mentioned in
>this bug, "apt-get indextargets" omits the Release file

Sorry I'm afraid this is not exposed in the apt code. There is only a
function to check which architectures are supported but you can't get
a list.

Meanwhile apt-get indextargets omits release files by design as they
are not indextargets, but uh metaindex targets.

python-apt omits bindings for ReleaseFile, there really should be
a Cache.release_files list of release file objects. You'd still need
to parse them yourself because we don't have the data in the cache
but that will get you most of the way there.

You may also for now rely on the file matching *Release in the lists
dir.

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

Bug#1067163: mapnik: Fails to build with Python 3.12

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 3/19/24 5:04 PM, Sebastiaan Couwenberg wrote:

On 3/19/24 4:52 PM, Benjamin Drung wrote:

mapnik fails to build on Ubuntu with Python 3.12 due to the Scons
version in the package. I applied the attached patch to Ubuntu to use
the scons Debian package.


We moved away from the scons package because that was broken (#936017).

Better to patch what's included in mapnik.


This is fixed in git by cherry-picking the upstream changes switching 
from imp to importlib.


Kind Regards,

Bas

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

Bug#1067175: exaile: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: exaile
Version: 4.1.3+dfsg-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

exaile is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067174: cpupower-gui: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: cpupower-gui
Version: 0.7.2-2.1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t

cpupower-gui is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

(This is mostly a theoretical concern because cpupower-gui is already
excluded from testing as a result of an unrelated RC bug #102.)

More information about this transition is available on
.

Thanks,
smcv

Bug#1042842: network interface names wrong in domU (>10 interfaces)

[Valentin Kleibel]

Hello,

I'm currently in the process of cleaning up and i noticed this bug i 
reported is still open.


Based on what we know now i think the bug can be closed.

To summarize:
* the ordering of network interfaces (and therefore the ethn names) was 
never meant to be stable and changed with Xen 4.17
* domUs starting with bookworm use enXn by default and their order 
matches the config
* bullseye domUs on a bookworm dom0 with more than 10 network interfaces 
need a workaround:

  * use udev from bullseye-backports and enXn naming scheme
  * use custom udev rules to get fixed interface names

Thanks for your help with this issue,
Valentin

Bug#1067172: ruff: E999 SyntaxError: Got unexpected unicode

[Jakub Wilk]

Package: ruff
Version: 0.0.291+dfsg1-3
Tags: fixed-upstream

ruff can't parse some \N{} sequences correctly, e.g.:

   $ cat stx.py
   print(ascii('\N{STX}'))

   $ python3 stx.py
   '\x02'

   $ ruff check stx.py
   error: Failed to parse stx.py:1:17: Got unexpected unicode
   stx.py:1:17: E999 SyntaxError: Got unexpected unicode
   Found 1 error.

As far as I can see, it's already fixed upstream; I can't reproduce it 
with upstream ruff 0.3.3.



-- System Information:
Architecture: amd64

Versions of packages ruff depends on:
ii  libc6  2.36-9+deb12u4
ii  libgcc-s1  12.2.0-14

--
Jakub Wilk
print(ascii('\N{STX}'))

Bug#1067173: clearlooks-phenix-theme: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: clearlooks-phenix-theme
Version: 7.0.1-3
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t

clearlooks-phenix-theme is an Architecture: all package, but has a
direct (versioned) dependency on libgtk-3-0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is going to become an impossible dependency,
because libgtk-3-0 and libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0, or swap it for
libgtk-3-0t64. Perhaps it could become a Recommends: libgtk-3-0t64,
Breaks: libgtk-3-0 (<< 3.20)?

(This is mainly a theoretical concern because clearlooks-phenix-theme
was removed from testing as a result of an unrelated RC bug.)

Thanks,
smcv

Bug#1067171: bleachbit: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: bleachbit
Version: 4.6.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

bleachbit is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067170: 0install: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: 0install
Version: 2.18-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

Versions of 0install that have been rebuilt for the 64-bit time_t
transition (for example on amd64) have dependencies on both libgtk-3-0
and libgtk-3-0t64. On the architectures where the ABI transition took
place (for example armel and armhf) this will be an impossible dependency.

It looks as though 0install is correctly picking up a dependency on GTK
from ${shlibs:Depends}, so please remove the explicit dependency on
libgtk-3-0.

Thanks,
smcv

Bug#1067169: gnome-control-center: Disable location services?

[Jeremy Bícha]

Source: gnome-control-center
Version: 1:46~beta-2
Severity: important
X-Debbugs-CC: debian-mob...@lists.debian.org

Mozilla has announced that it will be disabling third party access to
the Mozilla Location Service June 12. This is used via geoclue-2.0 to
provide a variety of services across Debian desktops, in particular in
gnome-control-center.

GNOME has recently proposed a build option [1] to hide the
location-related settings in gnome-control-center. I'm told that
geoclue can also work with GPS so the settings might be useful for
people using Debian on mobile devices. However, I think we need to do
what's best for the vast majority of our users. I'm filing this issue
for awareness in case anyone wants to contribute alternate ways of
handling this situation upstream to GNOME.

[1] https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2383

Thank you,
Jeremy Bícha

Bug#848194: Want way to get Release (or InRelease) file from cache

[Colin Watson]

Hi,

I don't know if it helps or hinders this bug since I have rather
different reasons from Ian, but I found myself looking at this bug today
because I also wanted a way to get hold of an [In]Release file.  The
difference is that I'm not trying to get hold of it for a particular
package, but for (roughly) a sources.list entry; but all my other
requirements seem basically the same as Ian's.  My use case is as
follows, and you can tell me if it's too different to include in the
same report:

 * In order to be able to implement an "import the contents of this
   repository into our database" task in debusine
   (https://freexian-team.pages.debian.net/debusine/), I want to
   discover which architectures are supported by a given suite in a
   repository, assuming that it has at least a Release file.  And of
   course then I want to be able to fetch all the files, but at least
   that part isn't so hard.

 * If you already know which architectures you want, then this is easy.
   But if you want to ask the repository which architectures it
   supports, as far as I know the only sensible way is to consult the
   Release file.

 * Acquiring and verifying Release files correctly is, as I'm sure you
   know, challenging.  I would like to avoid writing my own code to call
   gpgv in just the right way (again).  I've been here before with
   #918304.

 * I'd hoped to use python-debian, but its GPG verification support is
   currently not as good as it should be (#710923) and in any case what
   you get from its Release file handling is not very helpful
   (#1067160).

 * So I looked at apt/python-apt.  I know how to instantiate a temporary
   apt cache with its own configuration (in the manner of chdist(1), for
   instance), and if I could discover the available architectures after
   an initial fetch then I could call "apt-get update" a second time
   with APT::Architectures set and then I'd have everything.  However,
   given a cache, I seem to be able to access basically everything
   _except_ for the Release file in documented ways.  As mentioned in
   this bug, "apt-get indextargets" omits the Release file.

For now, I'll probably dodge the problem by requiring the user to
specify which architectures they want, and then I don't need the Release
file.  But I feel like I'm missing something.

Thanks,

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

Bug#1067168: urwid raises when rendering an empty Pile or Columns as a flow widget

[Olivier Gayot]

Package: urwid
Version: 2.6.4-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

With the version of urwid 2.6.4-1 currently in trixie, the following
code fails with an exception:

```python
 from urwid import Pile
 
 Pile([
 ("pack", Pile([])),
 ]).render((10,))
 ```

  File "/usr/lib/python3/dist-packages/urwid/widget/widget.py", line 112, in 
cached_render
canv = fn(self, size, focus=focus)
   ^^^
  File "/usr/lib/python3/dist-packages/urwid/widget/pile.py", line 822, in 
render
_widths, heights, size_args = self.get_rows_sizes(size, focus)
  
  File "/usr/lib/python3/dist-packages/urwid/widget/pile.py", line 730, in 
get_rows_sizes
heights.append(w.pack(w_h_arg, item_focus)[1])
   ^^^
  File "/usr/lib/python3/dist-packages/urwid/widget/pile.py", line 744, in pack
return super().pack(size, focus)
   ^
  File "/usr/lib/python3/dist-packages/urwid/widget/widget.py", line 401, in 
pack
raise WidgetError(f"Cannot pack (maxcol,) size, this is not a flow widget: 
{self!r}")
urwid.widget.widget.WidgetError: Cannot pack (maxcol,) size, this is not a flow 
widget: 

The same code used to work with urwid 2.1.2-4 in bookworm.

I applied a fix from upstream [1] that was included in urwid 2.6.5. I
think the proper way forward would be to take a more recent upstream
version of urwid. That said, we are in feature freeze downstream in
Ubuntu so I skipped the refactoring bits.

In Ubuntu, the attached patch was applied to achieve the following:

  * Apply upstream patch to fix a crash when rendering an empty Pile or an
empty Columns as a flow widget. (LP: #2058388)
+ d/patches/fix-crash-empty-pile.patch


Thanks for considering the patch.


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

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

[1] 
https://github.com/urwid/urwid/commit/83c278b53de431a9b41d7ddadf5f318914246593
diff -Nru urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch 
urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch
--- urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch   1970-01-01 
01:00:00.0 +0100
+++ urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch   2024-03-19 
14:23:31.0 +0100
@@ -0,0 +1,158 @@
+Description: Fix crash when rendering empty Pile or Columns as a flow widget
+ Special case: in case of `Columns`/`Pile` empty - use fallback sizing (#843)
+ .
+ * Extend `repr` to provide brief info about contents
+ .
+Author: Aleksei Stepanov 
+Origin: upstream, 
https://github.com/urwid/urwid/commit/83c278b53de431a9b41d7ddadf5f318914246593
+Bug-Ubuntu: https://launchpad.net/bugs/2058388
+Last-Update: 2024-03-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/urwid/widget/columns.py b/urwid/widget/columns.py
+index e3fa134..5a3421f 100644
+--- a/urwid/widget/columns.py
 b/urwid/widget/columns.py
+@@ -66,40 +66,47 @@ class Columns(Widget, WidgetContainerMixin, 
WidgetContainerListContentsMixin):
+ 
+ # BOX-only widget
+ >>> Columns((SolidFill("#"),))
+-
++
+ 
+ # BOX-only widget with "get height from max"
+ >>> Columns((SolidFill("#"),), box_columns=(0,))
+-
++
+ 
+ # FLOW-only
+ >>> Columns((Edit(),))
+-
++
+ 
+ # FLOW allowed by "box_columns"
+ >>> Columns((Edit(), SolidFill("#")), box_columns=(1,))
+-
++
+ 
+ # FLOW/FIXED
+ >>> Columns((Text("T"),))
+-
++
+ 
+ # GIVEN BOX only -> BOX only
+ >>> Columns(((5, SolidFill("#")),), box_columns=(0,))
+-
++
+ 
+ # No FLOW - BOX only
+ >>> Columns(((5, SolidFill("#")), SolidFill("*")), box_columns=(0, 1))
+-
++
+ 
+ # FIXED only -> FIXED
+ >>> Columns(((WHSettings.PACK, BigText("1", font)),))
+-
++
+ 
+ # Invalid sizing combination -> use fallback settings (and produce 
warning)
+ >>> Columns(((WHSettings.PACK, SolidFill("#")),))
+-
++
++
++# Special case: empty columns widget sizing is impossible to calculate
++>>> Columns(())
++
+ """
++if not self.contents:
++return frozenset((urwid.BOX, urwid.FLOW))
++
+ strict_box = False
+ has_flow = False
+ 
+@@ -280,6 +287,13 @@ class 

Bug#1067167: open-iscsi: iscsiadm --target iqn.foo --login doesn't

[Jakob Bohm]

Package: open-iscsi
Version: 2.1.8-1
Severity: normal


When trying to connect to an additional iSCSI target/server with the widely
reported command
  iscsiadm -m node --target iqn.foo --login
iscsiadm on at least some networks will fail with incorrect error messages:
  Logging in to [iface: ifBar_0, target: iqn.foo, portal: 10.x.x.x,3260]
  iscsiadm: Could not login to [iface: ifBar_0, target: iqn.foo, 
portal: 10.x.x.x,3260].
  iscsiadm: initiator reported error (19 - encountered non-retryable 
iSCSI login failure)

  iscsiadm: Could not log into all portals

However running a simultaneous tcpdump and analyzing it with WireShark 
reveals

that iscsiadm does a succesful login, then generates a TCP RST ending the
attempt for no apparent reason.

Because whatever failed was something local on the client, the error message
must say so and be much more actionable instead of sending the sysadmin on
a wild goose chase through the authentication settings and target 
configuration.


P.S.
This was run against another bookworm machine running targetcli-fb, no 
exotic

hardware needed.  All firewalls that I could find on the path are off.

P.P.S.
As stated in the first line of the report, this happens for an additional
iSCSI connection while the client already has iSCSI connections to other
disc boxes (in this case on other network interfaces).





-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (100, 'bookworm-fasttrack')

Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u4
ii  libisns0   0.101-0.2+b1
ii  libkmod2   30+20221128-1
ii  libmount1  2.38.1-5+b1
ii  libopeniscsiusr2.1.8-1
ii  libssl33.0.11-1~deb12u2
ii  libsystemd0252.22-1~deb12u1
ii  udev   254.5-1~bpo12+3

Versions of packages open-iscsi recommends:
ii  busybox-static [busybox]  1:1.35.0-4+b3
pn  finalrd   

open-iscsi suggests no packages.

-- Configuration Files:
/etc/default/open-iscsi changed:
LVMGROUPS=""
HANDLE_NETDEV=1

/etc/init.d/open-iscsi changed:
PATH=/sbin:/bin
DAEMON=/sbin/iscsid
ADM=/sbin/iscsiadm
PIDFILE=/run/iscsid.pid
NAMEFILE=/etc/iscsi/initiatorname.iscsi
CONFIGFILE=/etc/iscsi/iscsid.conf
OMITDIR=/run/sendsigs.omit.d
[ -x "$DAEMON" ] || exit 0
. /lib/lsb/init-functions
if [ -f /etc/default/open-iscsi ]; then
. /etc/default/open-iscsi
fi
pause() {
# echo
# echo "$0 $*: Press enter to continue"
# read dummy
# unset dummy
echo
echo -n "$0 $*: Sleeping 5 seconds..."
sleep 5
echo "Slept"
}
pause "$@"
if [ ! -d /sys/class/ ]; then
  log_failure_msg "iSCSI requires a mounted sysfs, not started."
  pause nosysfs
  exit 0
fi
RETVAL=0
start() {
if ! [ -s $PIDFILE ] || ! kill -0 `sed -n 1p $PIDFILE` >/dev/null ; then
		log_failure_msg "iSCSI initiator daemon not started: not logging in to 
default targets"

exit 1
fi
starttargets
# activate LVM, mount filesystems, etc.
/lib/open-iscsi/activate-storage.sh
}
starttargets() {
pause starttargets
log_daemon_msg "Setting up iSCSI targets"
echo
$ADM -m node --loginall=automatic
pause startcomplete
log_end_msg 0
}
stoptargets() {
log_daemon_msg "Disconnecting iSCSI targets"
sync
# only logout if daemon is running, iscsiadm hangs otherwise
if [ -s $PIDFILE ] && kill -0 `sed -n 1p $PIDFILE` >/dev/null ; 
then

/lib/open-iscsi/logout-all.sh
fi
log_end_msg 0
}
stop() {
# Call umountiscsi.sh to unmount iSCSI devices first (always do
# that, regardless of whether root is on iSCSI, umountiscsi.sh
# will exclude it - and even if that shouldn't work, the mount
# point will be busy)
log_daemon_msg "Umounting iSCSI filesystems"
/lib/open-iscsi/umountiscsi.sh
umount_exit_status=$?
log_end_msg $umount_exit_status
if [ $umount_exit_status -ne 0 ]; then
		log_failure_msg "Couldn't unmount all iSCSI devices. not logging out 
from any target."

exit 1
fi
stoptargets
}
restart() {
stop
start
}
restarttargets() {
stoptargets
starttargets
}
status() {
echo Current active iSCSI sessions:
$ADM -m session
}
case "$1" in
start|starttargets|stop|stoptargets|restart|restarttargets|status)
$1
;;
force-reload)
restart
 

Bug#1067026: graphviz patch for ports architectures..

[Helge Deller]

On 3/19/24 16:35, Helge Deller wrote:

+ librsvg2-dev [!alpha !hppa !hurd-amd64 !hurd-i386 ia64 !m68k !sh4],


Argh... the line above is missing a "!" in front of ia64.

And, debian/libgvc6-plugins-gtk.install lists the lubrsvg shared object
which would need to be removed from that file too..

With those two changes graphviz built at least...

Helge

Bug#1067163: mapnik: Fails to build with Python 3.12

[Sebastiaan Couwenberg]

On 3/19/24 4:52 PM, Benjamin Drung wrote:

mapnik fails to build on Ubuntu with Python 3.12 due to the Scons
version in the package. I applied the attached patch to Ubuntu to use
the scons Debian package.


We moved away from the scons package because that was broken (#936017).

Better to patch what's included in mapnik.

Kind Regards,

Bas

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

Bug#1067166: RM: jellyfish [armel armhf hppa i386] -- ROM; scientific software & upstream doesn't suppport 32-bit systems

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: jellyf...@packages.debian.org, cru...@debian.org
Control: affects -1 + src:jellyfish
Control: block -1 1067165
Control: block -1 1067164
Control: tag -1 moreinfo

In general it isn't worth our time to support 32-bit architectures for 
scientific computing software.

The Jellyfish upstream has specifically stated that they do not want to support 
32-bit architectures, and I agree with them:

https://github.com/gmarcais/Jellyfish/pull/202#issuecomment-2007544485

--
Michael R. Crusoe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067165: RM: crac [i386 armel armhf] -- ROM; scientific software & upstream dependency doesn't suppport 32-bit systems

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: c...@packages.debian.org, cru...@debian.org
Control: affects -1 + src:crac

In general it isn't worth our time to support 32-bit architectures for 
scientific computing software.

This specific request is in support of removing the 32-bit builds of 
"jellyfish", as upstream does not want to support those architectures.

--
Michael R. Crusoe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067164: RM: centrifuge [i386 armel armhf hppa] -- ROM; scientific software & upstream dependency doesn't suppport 32-bit systems

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: centrif...@packages.debian.org, cru...@debian.org
Control: affects -1 + src:centrifuge

In general it isn't worth our time to support 32-bit architectures for 
scientific computing software.

This specific request is in support of removing the 32-bit builds of 
"jellyfish", as upstream does not want to support those architectures.

--
Michael R. Crusoe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067141: kcemu: FTBFS with -Werror=implicit-function-declaration

[Bo YU]

Package: kcemu
Version: 0.5.2+dfsg-1
Followup-For: Bug #1067141
Tags: patch

Hi, 

I just test the patch and it seems it works.


-- 
Regards,
--
  Bo YU

diff -Nru kcemu-0.5.2+dfsg/debian/changelog kcemu-0.5.2+dfsg/debian/changelog
--- kcemu-0.5.2+dfsg/debian/changelog   2022-11-30 05:53:48.0 -0500
+++ kcemu-0.5.2+dfsg/debian/changelog   2024-03-19 11:32:12.0 -0400
@@ -1,3 +1,10 @@
+kcemu (0.5.2+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix implicit-function-declaration issue. (Closes: #1067141) 
+
+ -- a   Tue, 19 Mar 2024 11:32:12 -0400
+
 kcemu (0.5.2+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
kcemu-0.5.2+dfsg/debian/patches/fix-error-implicit-function-declaration.patch 
kcemu-0.5.2+dfsg/debian/patches/fix-error-implicit-function-declaration.patch
--- 
kcemu-0.5.2+dfsg/debian/patches/fix-error-implicit-function-declaration.patch   
1969-12-31 19:00:00.0 -0500
+++ 
kcemu-0.5.2+dfsg/debian/patches/fix-error-implicit-function-declaration.patch   
2024-03-19 11:32:02.0 -0400
@@ -0,0 +1,28 @@
+Description: fix implicit-function-declaration error
+Author: Bo YU 
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067141
+Forwarded: https://github.com/t-paul/kcemu/issues/6
+Last-Update: 2024-03-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/sys/mingw/sys_socket_create.c
 b/src/sys/mingw/sys_socket_create.c
+@@ -18,6 +18,7 @@
+  */
+ 
+ #include 
++#include 
+ 
+ #include "kc/config.h"
+ #include "sys/sysdep.h"
+--- a/src/sys/unix/sys_socket_create.c
 b/src/sys/unix/sys_socket_create.c
+@@ -23,6 +23,8 @@
+ #include 
+ #include 
+ #include 
++#include 
++
+ 
+ #include "kc/config.h"
+ #include "sys/sysdep.h"
diff -Nru kcemu-0.5.2+dfsg/debian/patches/series 
kcemu-0.5.2+dfsg/debian/patches/series
--- kcemu-0.5.2+dfsg/debian/patches/series  1969-12-31 19:00:00.0 
-0500
+++ kcemu-0.5.2+dfsg/debian/patches/series  2024-03-19 05:37:35.0 
-0400
@@ -0,0 +1 @@
+fix-error-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#1067163: mapnik: Fails to build with Python 3.12

[Benjamin Drung]

Source: mapnik
Version: 3.1.0+ds-7
Severity: normal
Tags: patch
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

mapnik fails to build on Ubuntu with Python 3.12 due to the Scons
version in the package. I applied the attached patch to Ubuntu to use
the scons Debian package.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru mapnik-3.1.0+ds/debian/changelog mapnik-3.1.0+ds/debian/changelog
--- mapnik-3.1.0+ds/debian/changelog2024-03-02 13:14:12.0 +0100
+++ mapnik-3.1.0+ds/debian/changelog2024-03-19 16:40:34.0 +0100
@@ -1,3 +1,10 @@
+mapnik (3.1.0+ds-7ubuntu1) noble; urgency=medium
+
+  * Use scons from the Debian package (for Python 3.12 support)
+  * Cherry-pick SConstruct upstream changes for Scons >= 4.1.0
+
+ -- Benjamin Drung   Tue, 19 Mar 2024 16:40:34 +0100
+
 mapnik (3.1.0+ds-7) unstable; urgency=medium
 
   * Add dpkg-dev (>= 1.22.5) to build dependencies for t64 changes.
diff -Nru mapnik-3.1.0+ds/debian/control mapnik-3.1.0+ds/debian/control
--- mapnik-3.1.0+ds/debian/control  2024-03-02 13:14:02.0 +0100
+++ mapnik-3.1.0+ds/debian/control  2024-03-19 16:39:54.0 +0100
@@ -31,6 +31,7 @@
libxml2-dev,
pkgconf,
python3,
+   scons,
zlib1g-dev
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/debian-gis-team/mapnik
diff -Nru mapnik-3.1.0+ds/debian/patches/series 
mapnik-3.1.0+ds/debian/patches/series
--- mapnik-3.1.0+ds/debian/patches/series   2023-11-16 19:00:05.0 
+0100
+++ mapnik-3.1.0+ds/debian/patches/series   2024-03-19 16:40:34.0 
+0100
@@ -1,7 +1,7 @@
 libxml2.patch
-Stop-using-custom-OrderedDict.patch
 proj.patch
 gcc-13.patch
 boost-1.81.patch
 boost-1.83-1.patch
 boost-1.83-2.patch
+Upgrade-to-Scons-4.1.0.patch
diff -Nru mapnik-3.1.0+ds/debian/patches/Stop-using-custom-OrderedDict.patch 
mapnik-3.1.0+ds/debian/patches/Stop-using-custom-OrderedDict.patch
--- mapnik-3.1.0+ds/debian/patches/Stop-using-custom-OrderedDict.patch  
2022-02-08 15:30:11.0 +0100
+++ mapnik-3.1.0+ds/debian/patches/Stop-using-custom-OrderedDict.patch  
1970-01-01 01:00:00.0 +0100
@@ -1,156 +0,0 @@
-Description: Stop using custom OrderedDict
- OrdredDict is in the standard library for all supported Python versions
- (2.7 and 3.5+) and has improvements over the ActiveState recipe version
- of OrderedDict we have been using. Switch to importing from collections
- instead of getting it from SCons.Util (tests already did this).
- .
- At the same time, reorganize the Util.py imports - import Iterable
- from collections.abc if possible (it is deprecated to import
- it from collections, will stop working in 3.8); try getting the
- User{Dict,List,String} from collections if possible - that is, try the
- 3.x way first.
-Author: Mats Wichmann 
-Origin: https://github.com/SCons/scons/commit/3fa7141ec7b39
-Forwarded: https://github.com/mapnik/mapnik/pull/4294
-Applied-Upstream: 
https://github.com/mapnik/mapnik/commit/7da9009e7b0b9429890f6f13fee837ac320f
-
 a/scons/scons-local-3.0.1/SCons/Action.py
-+++ b/scons/scons-local-3.0.1/SCons/Action.py
-@@ -107,6 +107,7 @@ import sys
- import subprocess
- import itertools
- import inspect
-+from collections import OrderedDict
- 
- import SCons.Debug
- from SCons.Debug import logInstanceCreation
-@@ -1289,7 +1290,7 @@ class ListAction(ActionBase):
- return result
- 
- def get_varlist(self, target, source, env, executor=None):
--result = SCons.Util.OrderedDict()
-+result = OrderedDict()
- for act in self.list:
- for var in act.get_varlist(target, source, env, executor):
- result[var] = True
 a/scons/scons-local-3.0.1/SCons/Tool/javac.py
-+++ b/scons/scons-local-3.0.1/SCons/Tool/javac.py
-@@ -34,6 +34,7 @@ __revision__ = "src/engine/SCons/Tool/ja
- 
- import os
- import os.path
-+from collections import OrderedDict
- 
- import SCons.Action
- import SCons.Builder
-@@ -70,7 +71,7 @@ def emit_java_classes(target, source, en
- if isinstance(entry, SCons.Node.FS.File):
- slist.append(entry)
- elif isinstance(entry, SCons.Node.FS.Dir):
--result = SCons.Util.OrderedDict()
-+result = OrderedDict()
- dirnode = entry.rdir()
- def find_java_files(arg, dirpath, filenames):
- java_files = sorted([n for n in filenames
 a/scons/scons-local-3.0.1/SCons/Util.py
-+++ b/scons/scons-local-3.0.1/SCons/Util.py
-@@ -37,21 +37,18 @@ import pprint
- PY3 = sys.version_info[0] == 3
- 
- try:
-+from collections import UserDict, UserList, UserString
-+except ImportError:
- from UserDict import UserDict
--except ImportError as e:
--from collections import UserDict
--
--try:
- from UserList import UserList
--except ImportError as e:
--from collections import UserList
--
--from collections import Iterable
-+from UserString import UserString
- 
- try:

Bug#1067026: graphviz patch for ports architectures..

[Helge Deller]

It seems this change in debian/control is sufficient?

--- debian/control  2024-03-19 15:27:01.567243176 +
+++ debian/control.org  2024-03-19 15:23:54.838549231 +
@@ -37,7 +37,7 @@
  libgtk2.0-dev,
  libgts-dev,
  libann-dev,
- librsvg2-dev,
+ librsvg2-dev [!alpha !hppa !hurd-amd64 !hurd-i386 ia64 !m68k !sh4],
  libwebp-dev
 Build-Conflicts: tcl8.3, tcl8.4, tcl8.5
 Homepage: https://www.graphviz.org/

Bug#1065682: RFS: c-evo-dh/1.11-1 -- Empire Building Game (data files), C-evo: Distant Horizon

[Peter Blackman]

Control: tags -1 -moreinfo


Hi Tobi,

On 17/03/2024 10:25, Tobias Frost wrote:

Some review
- source packages do not have a Description: field, only binary
   packages.
I was trying to fix the issue of no description appearing in the package 
tracker [1]

This seems to happen when a source package builds multiple binaries.
I've reverted the change now.


- note that changing previous d/changelog entries should be only done in
   rare circumtances, for example annotating CVEs to earlier uploads,
   not known then.
   I don't see the necassity for that history rewriting here, so
   please don't do that.
   Additional confusion can arise, if you change the timestamp
   of historical changelog entries. Don't do that either.
   Please revert those changes.
I updated the changelog, because the last time, you complained of 
missing items [2]

And it then got uploaded before I had corrected it.

I've reverted the uploaded version of the changelog entry for 1.10-1
and included the missing items in the section for 1.11-1,
indicating that they refer to the previous version.


[1] https://tracker.debian.org/pkg/c-evo-dh
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056273


Cheers,
Peter

Bug#1052138: (no subject)

[Rowell]

Do you get my last mail

Bug#1067151: xen-utils-common: vif-openvswitch ignores MTU

[Hans van Kranenburg]

Hi Aleksi,

Thanks for the report. I actually ran into the same situation recently,
wanting to set up a PPPoE connection from within a Xen domU, also using
openvswitch as bridge.

On 19/03/2024 12:21, Aleksi Suhonen wrote:
> Package: src:xen
> Version: 4.17.3+10-g091466ba55-1~deb12u1
> Severity: wishlist
> 
> I wasn't sure if this script comes from Debian or Xen or somewhere else, 
> so I thought it safest to report it here.

These scripts/vif-* files are located in tools/hotplug/Linux in the Xen
source tree, we ship them as such in the Debian package. So, yes,
changes to them should first go upstream. However, it's perfectly fine
to have a discussion here, so we can figure out what the right changes
should be.

> /etc/xen/scripts/vif-bridge handles MTU settings in the vif, but the 
> otherwise similar /etc/xen/scripts/vif-openvswitch does not. I added it 
> in, here's the diff-c and the full fixed file is also attached.
> 
> *** vif-openvswitch.orig2024-03-19 11:53:13.0 +0200
> --- vif-openvswitch 2024-03-19 11:56:17.0 +0200
> ***
> *** 89,94 
> --- 89,95 
>add|online)
>check_tools
>setup_virtual_bridge_port $dev
> + set_mtu "$bridge" "$dev" "$type_if"
>add_to_openvswitch $dev
>;;

Ah, interesting. I had some difficulties getting it to work back then.
But, when putting the set_mtu line back like this, it also gives me the
desired outcome now!

My use case is about setting up a PPPoE connection from a Xen domU over
vlan 6. I want an mtu of 1500 for the traffic inside the PPPoE
connection, so I need mtu 1508 for the connection between the PPPoE
client in the domU -> openvswitch in the dom0 -> physical interface ->
switchports -> ISP NTU device.

For some reason I had troubles to get the vifX.Y interface, as seen
inside dom0 set to mtu 1508. It seemed not to have any effect (using ip
link set mtu  dev ), or, openvswitch kept resetting it back to
1500 all the time. When I would use ovs-vsctl set interface 
mtu_request= instead, it actually sticked. That's what I remember.

I just did some more testing, and I cannot really reproduce that
situation... :| I can also just use ip link in the dom0 now.

Interesting, but good, since it would mean that we can indeed just
(re)use that set_mtu function! :) I'm still curious what the problem was
when I tried earlier... Maybe anyone else reading this knows more?

Are you familiar with the process of sending patches upstream? Otherwise
we (Debian Xen team) can assist with that.

Regards,
Hans

Bug#1067162: h2o: FTBFS with Ruby 3.2 due to exists? alias

[Lukas Märdian]

Package: h2o
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix FTBFS with Ruby 3.2

Thanks for considering the patch.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-proposed'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-26-generic (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru h2o-2.2.5+dfsg2/debian/patches/ruby3.2-compat.patch 
h2o-2.2.5+dfsg2/debian/patches/ruby3.2-compat.patch
--- h2o-2.2.5+dfsg2/debian/patches/ruby3.2-compat.patch 1970-01-01 
01:00:00.0 +0100
+++ h2o-2.2.5+dfsg2/debian/patches/ruby3.2-compat.patch 2024-03-19 
16:14:54.0 +0100
@@ -0,0 +1,37 @@
+Description: Starting in Ruby 3.2.0 the exists? (pluralized) alias for exist? 
seems to have been removed
+Author: Lukas Märdian 
+
+Origin: vendor, Ubuntu
+Last-Update: 2024-03-19
+
+--- h2o-2.2.5+dfsg2.orig/deps/mruby-onig-regexp/mrbgem.rake
 h2o-2.2.5+dfsg2/deps/mruby-onig-regexp/mrbgem.rake
+@@ -66,7 +66,7 @@ MRuby::Gem::Specification.new('mruby-oni
+   end
+ 
+   _pp 'autotools', oniguruma_dir
+-  run_command e, './autogen.sh' if File.exists? 'autogen.sh'
++  run_command e, './autogen.sh' if File.exist? 'autogen.sh'
+   run_command e, "./configure --disable-shared --enable-static 
#{host}"
+   run_command e, 'make'
+ else
+@@ -94,7 +94,7 @@ MRuby::Gem::Specification.new('mruby-oni
+   file libmruby_a => Dir.glob("#{libonig_objs_dir}/*#{objext}")
+ end
+ 
+-file libmruby_a => Dir.glob("#{libonig_objs_dir}/*#{objext}") if 
File.exists? oniguruma_lib
++file libmruby_a => Dir.glob("#{libonig_objs_dir}/*#{objext}") if 
File.exist? oniguruma_lib
+ 
+ file "#{dir}/src/mruby_onig_regexp.c" => oniguruma_lib
+ cc.include_paths << oniguruma_dir
+--- h2o-2.2.5+dfsg2.orig/deps/mruby/minirake
 h2o-2.2.5+dfsg2/deps/mruby/minirake
+@@ -261,7 +261,7 @@ module MiniRake
+ dir = args.is_a?(Hash) ? args.keys.first : args
+ (dir.split(File::SEPARATOR) + ['']).inject do |acc, part|
+   (acc + File::SEPARATOR).tap do |d|
+-Dir.mkdir(d) unless File.exists? d
++Dir.mkdir(d) unless File.exist? d
+   end + part
+ end
+   end
diff -Nru h2o-2.2.5+dfsg2/debian/patches/series 
h2o-2.2.5+dfsg2/debian/patches/series
--- h2o-2.2.5+dfsg2/debian/patches/series   2023-10-20 06:06:22.0 
+0200
+++ h2o-2.2.5+dfsg2/debian/patches/series   2024-03-19 15:59:44.0 
+0100
@@ -7,3 +7,4 @@
 mruby_fileutils_no_verbose.patch
 picohttpparser-vcstags.patch
 CVE-2023-44487.patch
+ruby3.2-compat.patch

Bug#1062847: protobuf: Use dh-sequence-elpa in Build-Depends-Indep

[Simon McVittie]

Control: block 1036884 by -1
Control: block -1 by 1062840

On Sat, 03 Feb 2024 at 15:14:57 -0500, Jeremy Bícha wrote:
> dh-elpa is only used to build an Architecture: all package. Therefore,
> it is more correct to use Build-Depends-Indep instead of specifying
> specific architectures.
> 
> We can Build-Depend on dh-sequence-elpa (dh-elpa Provides it) to
> automatically run --with elpa.

protobuf is currently part of various dependency chains blocking packages'
transition to 64-bit time_t, like this one:

..., gtk+3.0, ..., mesa, llvm-toolchain-17, grpc, protobuf, dh-elpa, emacs-nox, 
git, #1066794

I've confirmed that Jeremy's patches from #1062840 and #1062847 make it
buildable on at least armel and armhf. The changes proposed there look
harmless (indeed, beneficial) to me: they are cutting off
Architecture: all packages that can be built on any architecture, and in
practice get built on amd64.

The Emacs and PHP ecosystems are relatively large and it seems
advantageous to take them out of the critical path, particularly when
it's this easy.

Please consider applying those changes in a maintainer upload, or in
a NMU by someone with more knowledge of this package. (Sorry, I am not
intending to NMU this myself, since I have no experience with protobuf
or knowledge of how to smoke-test it.)

For your convenience, I attach the patches I used (which have longer
commit messages than the ones Jeremy provided, and include the bug number).

smcv
>From 2b3e4e1fe7d63abda065e77eed2d0f7a6626a25a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jeremy=20B=C3=ADcha?= 
Date: Sat, 3 Feb 2024 14:44:34 -0500
Subject: [PATCH 1/2] Move pkg-php-tools to Build-Depends-Indep

It is used to build php-google-protobuf, which is Architecture: all.

Closes: #1062840
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index d23dddf..5ba0021 100644
--- a/debian/control
+++ b/debian/control
@@ -23,8 +23,6 @@ Build-Depends: dpkg-dev (>= 1.22.5),
 # Ruby
  , rake-compiler 
  , gem2deb 
-# PHP
- , pkg-php-tools (>= 1.7~)
 Build-Depends-Indep:
 # Java
ant
@@ -33,6 +31,8 @@ Build-Depends-Indep:
  , maven-repo-helper
  , libguava-java
  , libgoogle-gson-java
+# PHP
+ , pkg-php-tools (>= 1.7~)
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://github.com/google/protobuf/
-- 
2.43.0

>From 0f475e747531308f75c72a10a6bd30487226d56e Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sat, 3 Feb 2024 15:10:23 -0500
Subject: [PATCH 2/2] Use dh-sequence-elpa in Build-Depends-Indep

dh-elpa is only used to build an Architecture: all package. Therefore,
it is more correct to use Build-Depends-Indep instead of specifying
specific architectures.

We can Build-Depend on dh-sequence-elpa (dh-elpa Provides it) to
automatically run --with elpa.

Finally, dh-autoreconf has been run by default since debhelper compat 10.

Closes: #1062847
---
 debian/control | 4 ++--
 debian/rules   | 6 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/debian/control b/debian/control
index 5ba0021..b9c0291 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,6 @@ Maintainer: Laszlo Boszormenyi (GCS) 
 Build-Depends: dpkg-dev (>= 1.22.5),
 # Debian build system
debhelper-compat (= 13)
- , dh-elpa [amd64 arm64 armel armhf i386 loong64 mips64el mipsel ppc64el s390x hppa ppc64 riscv64 sh4 sparc64 x32]
 # C/C++
  , zlib1g-dev
  , libgmock-dev 
@@ -24,8 +23,9 @@ Build-Depends: dpkg-dev (>= 1.22.5),
  , rake-compiler 
  , gem2deb 
 Build-Depends-Indep:
+   dh-sequence-elpa
 # Java
-   ant
+ , ant
  , default-jdk
  , javahelper
  , maven-repo-helper
diff --git a/debian/rules b/debian/rules
index ee54fe3..c3d897a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,11 +19,7 @@ SONAME=32
 API_VERSION=$(SONAME)-0
 
 %:
-ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 loong64 mips64el mipsel ppc64el s390x hppa ppc64 riscv64 sh4 sparc64 x32))
-	dh $@ --with autoreconf,elpa
-else
-	dh $@ --with autoreconf -Nelpa-protobuf-mode
-endif
+	dh $@
 
 ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
 override_dh_auto_configure:
-- 
2.43.0

Bug#1067161: nftables: BUG: invalid mapping expression variable

[Daniel Gröber]

Package: nftables
Version: 1.0.6-2+deb12u2
Severity: normal

Dear Maintainer,

The nftables config below triggers a BUG.

$ nft -f /etc/nftables.conf
BUG: invalid mapping expression variable
nft: evaluate.c:1797: expr_evaluate_map: Assertion `0' failed.
Aborted

Refactoring to using $srvaddr_map instead of having the anonymous map
inline made the bug trigger.

Thanks,
--Daniel

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/1 CPU thread; PREEMPT)
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 nftables depends on:
ii  libc6 2.36-9+deb12u4
ii  libedit2  3.1-20221030-2
ii  libnftables1  1.0.6-2+deb12u2

Versions of packages nftables recommends:
ii  netbase  6.4

Versions of packages nftables suggests:
pn  firewalld  

-- Configuration Files:
/etc/nftables.conf changed:
flush ruleset
define iid_mask6 = :::::
define srvaddr_map = { ::8384 : 8384 }
table inet filter {
chain input {
type filter hook input priority filter;
}
chain prerouting {
type nat hook prerouting priority dstnat;
ip6 nexthdr tcp  redirect to ip6 daddr & $iid_mask6 map 
$srvaddr_map # s/ map.*/{ ::8384 : 8384 }/  works
}
chain forward {
type filter hook forward priority filter;
}
chain output {
type filter hook output priority filter;
}
}


-- no debconf information

Bug#628815: coreutils: pinky makes crazy DNS queries

[Michael Stone]

On Tue, Mar 19, 2024 at 03:27:52PM +0100, you wrote:

/etc/acpi/lid.sh calls getXuser, that's defined in
/usr/share/acpi-support/power-funcs
which has on line 36
   plist=$(pinky -fw) || pwf_error "pinky lost"


I'd suggest a wishlist bug on acpi-support-base to use "who -us" in 
place of "pinky -fw". who is a posix standard command, pinky is an 
oddball that was hacked up from who years ago because someone liked the 
finger command output and wanted something that would add the full name, 
.plan, .project, etc., to the regular who output (none of which is used 
by acpi). Basically, pinky is simply not the right tool for the task at 
hand and it makes more sense IMO to use the right tool than to try to 
add functionality to a 30 year old special-purpose tool intended to 
replicate the functionality of an information program from another era.

Bug#1018261: confmodule should be distributed separately from debconf

[Faidon Liambotis]

On Sun, Aug 28, 2022 at 08:56:18AM +0200, Gioele Barabucci wrote:
> could you please ship `/usr/share/debconf/confmodule{,.sh}` in a separate
> package, for example debconf-common?

In the same spirit, I think Debconf::Client::ConfModule should also be
split into its own package, as it seems entirely distinct from debconf
itself, and similar to e.g. python3-debconf in that sense.

Per established Perl conventions, perhaps something like
libdebconf-client-confmodule-perl?

The dependency transition is going to be an interesting challenge. I see
Giole has resorted to (Pre-)Depends, for the Shell part, which makes
sense given its size, and could work for Perl as well.
Debconf::Client::ConfModule is used by a tiny minority of packages
though, so perhaps something more creative can be used in the long-term,
like perhaps dh_installdebconf getting taught to add the appropriate
dependencies if necessary.

Faidon

Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Andreas Tille]

Hi Emanuele.

Am Tue, Mar 19, 2024 at 12:16:16PM +0100 schrieb Emanuele Rocca:
> I've uploaded a NMU to DELAYED/2: https://bugs.debian.org/1067147

Thanks a lot for your attempt to help.  In principle we have a team wide
low threshold NMU - so undelayed NMUs are fine.  The kind of race
condition in uploads might imply that some ping in advance might be
helpful to avoid duplicated work.
 
> With those changes dcmtk builds fine on both armel and armhf. I've
> dropped the graphviz build-depend on those arches too, it can of course
> be reintroduced once graphviz become installable again.

Meanwhile your patch is imported and was uploaded by Michael - thanks to
all who helped solving this.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1067160: python3-debian: Difficult to iterate over next-level index files from Release

[Colin Watson]

Package: python3-debian
Version: 0.1.49
Severity: wishlist

I've trying to figure out how to build a specialized repository
mirroring tool as part of debusine
(https://freexian-team.pages.debian.net/debusine/), and I started by
looking at python-debian.  First I ran into
https://bugs.debian.org/710923, which would be an issue - past
experience with https://bugs.debian.org/918304 suggests that that's much
harder to get right than it seems.  But, assuming that that could be
solved somehow, I then started thinking about what would be needed next.

After verifying the Release file, a mirroring tool needs to fetch the
next level of index files (typically Packages and Sources).
python-debian offers very little help with this - you get a parsed
version of the various checksums fields, but that's about it - and there
are some non-trivial complications here.  For instance,
https://deb.debian.org/debian/dists/unstable/InRelease lists checksums
for main/binary-amd64/Packages, but those are the checksums you get
after fetching a compressed version of the file and uncompressing it;
the uncompressed version isn't actually on the mirror, and you have to
fetch
https://deb.debian.org/debian/dists/unstable/main/binary-amd64/Packages.xz
or similar instead.  While I have a rough idea of how to implement this
and could borrow code from apt, I don't really want to have to write
more versions of this than necessary.

Ideally (for me), Release would have some way to list the next-level
index files, and provide a way to fetch checksum-verified versions of
them given a base URL, parsed into Packages/Sources instances as
appropriate, and abstracting over all the details of compression
algorithms and such.

I think I may end up using apt or python-apt for now, but python-apt is
always a slightly awkward dependency in a Python codebase due to its
tight coupling with apt, and python-debian is much more convenient in
those terms.

Thanks,

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

Bug#1066899: wiki.debian.org: Missing definition (link) about "git-dpm project"

[Boyuan Yang]

Hi,

在 2024-03-15星期五的 07:44 +，Christian Buhtz写道：
> Package: wiki.debian.org
> Severity: normal
> 
> Dear Maintainer,
> 
> This report is about
> 
> 
> 
> Its first paragraph tells me about "git-dpm project".
> 
> Problem description:
> The term is not defined or explained on the whole page. The page also miss a
> link to a definition of that term.
> 
> Suggested solution:
> Use a hyperlink on the string "git-dpm project" to point the correct 
> definition
> page in the debian wiki.

I don't think there is such a definition. According to my understanding, the
"git-dpm project" solely means "a git-based deb package packaging repository
that utilizes git-dpm to maintain its history". Please feel free to rephrase it,
edit the Wiki page as needed, and close this bug report once you consider it 
solved.
See https://www.debian.org/Bugs/Developer#closing on how to close a bug report.

Thanks,
Boyuan Yang


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

Bug#628815: coreutils: pinky makes crazy DNS queries

[debbug]

/etc/acpi/lid.sh calls getXuser, that's defined in
/usr/share/acpi-support/power-funcs 
which has on line 36
plist=$(pinky -fw) || pwf_error "pinky lost"


On Tue, Mar 19, 2024 at 08:50:59AM -0400, Michael Stone wrote:
> On Tue, Mar 19, 2024 at 11:54:30AM +0100, you wrote:
> > For example on a debian system with acpi-support, /etc/acpi/lid.sh will
> > make many requests to find the host $WAYLAND_DISPLAY every time the lid
> > is opened.
> 
> I don't see anything in lid.sh that calls pinky.