Bug#1068953: new upstream (10.0)

[Daniel Baumann]

Package: frr
Severity: wishlist

Hi David and Ondrej,

it would be nice if you could upload the newly released frr version. If 
you need/want help, I'm happy to do so, just let me know.


Regards,
Daniel

Bug#1067450: ttyd: does not start

[Daniel Baumann]

close 1067450
thanks

Hi,

On 3/21/24 18:03, Daniel wrote:

Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: 
lws_create_context: failed to load evlib_uv
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: 
libwebsockets context creation failed
Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Main process exited, 
code=exited, status=1/FAILURE
Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Failed with result 'exit-code'.


this is a stray issue because of the t64 migration when you haven't
fully updated your system. on a minimal, up2date sid ttyd works
reproducibly fine.

Regards,
Daniel

Bug#1068952: new upstream required for frr

[Daniel Baumann]

Package: libyang2
Severity: wishlist

Hi Ondrej,

it would be nice if you could upload libyang2 >= 2.1.128 as the new frr 
release requires that. If you need/want help, I'm happy to do so, just 
let me know.


Regards,
Daniel

Bug#1068951: new upstream (6.x)

[Daniel Baumann]

Package: knot-resolver
Severity: wishlist

Hi,

it would be nice if you could upload knot-resolver 6.x to experimental.

Regards,
Daniel

Bug#1068950: http_loadtime multiple target / escapeUri regression

[Josip Rodin]

Package: munin-plugins-core
Version: 2.0.73-1

Hi,

This used to work while there was support for only one target:

[http_loadtime]
env.target http://localhost/?munin_http_loadtime=foo-front-60

The RRD value was just a simple string and it didn't matter what the content
of the target URL was. With the multiple target feature, however, this
returns:

% sudo munin-run http_loadtime
http___localhost_?munin_http_loadtime=foo_front_60.value 0.0946937

Which in turn is broken in Munin - it would create the RRD file for it,
the value would always be critical, and munin-cgi-graph complains like
this:

2024/04/14 05:19:49 [RRD ERROR] Unable to graph 
/var/lib/munin/cgi-tmp/munin-cgi-graph/bar.baz.com/foo-front-1.bar.baz.com/http_loadtime-year.png
 : foo_front_60_warning is not a vname nor a number

It sounds like the non-alphabetic characters that are included in
the query string bother it, as they aren't escaped by:

escapeUri() {
echo "$1" | sed 's/[:/.-]/_/g'
}

Please fix it. TIA.

-- 
Josip Rodin

Bug#1068949: libfinance-quote-perl: Quotes failing in Gnucash

[Bill Wohler]

Package: libfinance-quote-perl
Version: 1.59-1
Severity: normal

Dear Maintainer,

I ran the Tools > Price Database command in Gnucash using the "Yahoo
as JSON" source and got the following response:

Unable to retrieve quotes for these items.

In the past, this error was resolved by editing
/usr/share/perl5/Finance/Quote/YahooJSON.pm. However, this time, I
could not find any solutions online. I tried upgrading from version
1.54 (bookworm) to 1.59 (trixie), but that did not resolve the issue
either.

I hope you can do a better job finding a valid URL for the Yahoo
quotes. Alternatively, if you could recommend another, more stable,
source for retrieving mutual fund quotes, that would be great too.
Thanks!

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

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

Versions of packages libfinance-quote-perl depends on:
ii  libcgi-pm-perl 4.55-1
ii  libdatetime-format-strptime-perl   1.7900-1
ii  libdatetime-perl   2:1.59-1
pn  libencode-perl 
ii  libhtml-parser-perl3.81-1
ii  libhtml-tableextract-perl  2.15-2
ii  libhtml-tokeparser-simple-perl 3.16-4
ii  libhtml-tree-perl  5.07-3
ii  libhtml-treebuilder-xpath-perl 0.14-1.1
ii  libhttp-cookiejar-perl 0.014-1
ii  libhttp-cookies-perl   6.10-1
ii  libhttp-message-perl   6.44-1
ii  libio-string-perl  1.08-4
ii  libjson-parse-perl 0.62-1+b1
ii  libjson-perl   4.1-1
ii  liblwp-protocol-https-perl 6.10-1
ii  libreadonly-perl   2.050-3
ii  libscalar-list-utils-perl  1:1.63-1+b1
ii  libspreadsheet-xlsx-perl   0.17-1
ii  libstring-util-perl1.34-2
ii  libtext-template-perl  1.61-1
ii  libtry-tiny-perl   0.31-2
ii  liburi-perl5.17-1
ii  libweb-scraper-perl0.38-2
ii  libwww-perl6.68-1
ii  libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1
ii  perl [libio-compress-perl] 5.36.0-7+deb12u1
ii  perl-base [libscalar-list-utils-perl]  5.36.0-7+deb12u1

libfinance-quote-perl recommends no packages.

libfinance-quote-perl suggests no packages.

-- no debconf information

Bug#981276: pexec FTCBFS: help2man

[Petter Reinholdtsen]

[Helmut Grohne 2021-01-28]
> pexec fails to cross build from source, because it uses help2man. Given
> that pexec has very little dependencies, we can add a native build pass
> for generating the manual page before performing the cross build. Please
> consider applying the attached patch.

I suspect a better fix is to convert the package to use 'dh' first.  I
tried the trivial conversion but it did not work because the configure
script do not understand --runstatedir=/run.

I just converted the packaging to git and made it available in
https://salsa.debian.org/debian/pexec > if you want to update the
package yourself.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1010965: db5.3: New upstream (comdb2's embedded copy)

[Andreas Metzler]

On 2022-05-14 Bastian Germann  wrote:
> Source: db5.3
> Severity: wishlist
> X-Debbugs-Cc: 987...@bugs.debian.org

> There is a Sleepycat-licensed fork of BerkeleyDB at
> https://github.com/bloomberg/comdb2/tree/master/berkdb.  Maybe this is
> a way forward as long as #987013 (removal) is not resolved and bugs
> like #928441 are lurking.

Hello,

Afaict from
#define DB_VERSION_MAJOR4
#define DB_VERSION_MINOR2
#define DB_VERSION_PATCH52
#define DB_VERSION_STRING   "Sleepycat Software: Berkeley DB 4.2.52: 
(December  3, 2003)"
that is fork of 4.2.52.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1066334: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])

[Andreas Tille]

Hi Jeremy,

Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden:
> 
> The one after this looks like a GTK problem, and that's the point at
> which I bow out.

Thanks a lot for your help so far.  Your patches are pushed to Git.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

[Sean Whitton]

Hello,

On Thu 11 Apr 2024 at 08:32am GMT, Holger Levsen wrote:

> On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote:
>> A single page html may be an additional option but there's already the
>> single page txt version and the PDF. That's sufficient and I see no
>> need in providing more formats of this manual.
>>
>> Therefore we can close this and I will close 877337.
>
> fwiw, I disagree with this conclusion. single page txt and pdf versions
> are no replacements for single page html.

I agree, and still think we should be publishing the single page version.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068948: ITP: hiredict -- minimalistic C client library for Redict

[Maytham Alsudany]

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

* Package name: hiredict
  Version : 1.3.1
  Upstream Contact: Drew DeVault 
* URL : https://codeberg.org/redict/hiredict
* License : LGPL-3.0-only
  Programming Lang: C
  Description : minimalistic C client library for Redict

 hiredict is a minimalistic C client library for the Redict database. It is
 minimalistic because it just adds minimal support for the protocol, but
 at the same time it uses an high level printf-alike API in order to make
 it much higher level than otherwise suggested by its minimal code base
 and the lack of explicit bindings for every Redict command.
 .
 Apart from supporting sending commands and receiving replies, it comes
 with a reply parser that is decoupled from the I/O layer. It is a stream
 parser designed for easy reusability, which can for instance be used in
 higher level language bindings for efficient reply parsing.
 .
 The library comes with multiple APIs. There is the synchronous API, the
 asynchronous API and the reply parsing API.

Replacement for hiredis, intended for use with new redict package.
Will be maintained within the redict-team.
Will need a sponsor.

--
Kind regards,
Maytham Alsudany


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

Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)

[陈 晟祺]

Control: tags -1 + pending

Hi,

> 2024年4月13日 01:29，陈 晟祺  写道：
> 
> I am now trying to run tests on 2 core and 4GB memory (and maybe less later).
> If the tester itself does not occupy too much RAM, the real requirement for 
> resources
> is now probably several gigabytes of disk space (currently it’s ~10GB).
> 
> I will give more feedback once new results come out.
> 

When using non-ramdisk tmpdir (/var/tmp) and some large tests skipped [1],
the tests would run with 2 core + 4GB memory + ~10GB disk space.
I also tried 2GB / 3GB, and both will be interrupted by OOM killer.

I would have aron to review & upload a new version, then we can test on
debci infra and see whether it solves the problem.

[1]: 
https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/cf8e8afe69a0a8f21768415a08b131f8aa9fdc6a

Thanks,
--
Shengqi Chen

Bug#1068947: bullseye-pu: package curl/7.74.0-1.3+deb11u12

[Guilherme Puida Moreira]

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: c...@packages.debian.org, guilhe...@puida.xyz
Control: affects -1 + src:curl
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
1. Fix CVE-2024-2398

> When an application tells libcurl it wants to allow HTTP/2 server
> push, and the amount of received headers for the push surpasses the
> maximum allowed limit (1000), libcurl aborts the server push. When
> aborting, libcurl inadvertently does not free all the previously
> allocated headers and instead leaks the memory. Further, this error
> condition fails silently and is therefore not easily detected by an
> application.

[ Impact ]
The vulnerability is present in bullseye's curl code and can be
exploited by malicious actors.

[ Tests ]
Upstream provides an extensive test suite, and there are no test
failures when building the package.

[ Risks ]
The patch is not very complex, but some amount of backporting was needed
to apply it to the version of curl in bullseye. There is a chance of
introducing bugs here, but the test suite should catch most of them.
samueloph also reviewed my changes.

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

[ Changes ]
1. Imported and backported the upstream patch that fixes CVE-2024-2398.
--puida
diff -Nru curl-7.74.0/debian/changelog curl-7.74.0/debian/changelog
--- curl-7.74.0/debian/changelog	2023-12-10 03:05:18.0 -0300
+++ curl-7.74.0/debian/changelog	2024-04-09 22:00:20.0 -0300
@@ -1,3 +1,12 @@
+curl (7.74.0-1.3+deb11u12) bullseye; urgency=medium
+
+  * Team upload.
+  * Import patch to fix CVE-2024-2398: Memory leak when HTTP/2 server push is
+aborted.
+  * d/p/CVE-2024-2398.patch: Backport patch.
+
+ -- Guilherme Puida Moreira   Tue, 09 Apr 2024 22:00:20 -0300
+
 curl (7.74.0-1.3+deb11u11) bullseye-security; urgency=high
 
   * Add patch to fix CVE-2023-46218
diff -Nru curl-7.74.0/debian/patches/CVE-2024-2398.patch curl-7.74.0/debian/patches/CVE-2024-2398.patch
--- curl-7.74.0/debian/patches/CVE-2024-2398.patch	1969-12-31 21:00:00.0 -0300
+++ curl-7.74.0/debian/patches/CVE-2024-2398.patch	2024-04-09 21:58:53.0 -0300
@@ -0,0 +1,88 @@
+From deca8039991886a559b67bcd6701db800a5cf764 Mon Sep 17 00:00:00 2001
+From: Stefan Eissing 
+Date: Wed, 6 Mar 2024 09:36:08 +0100
+Subject: [PATCH] http2: push headers better cleanup
+
+- provide common cleanup method for push headers
+
+Closes #13054
+
+Backported by: Guilherme Puida Moreira :
+  * Changed h2_stream_ctx to HTTP in free_push_headers.
+  * Dropped unnaplicable hunk in push_promise, since it changed some code
+that does not yet exist.
+---
+ lib/http2.c | 34 +++---
+ 1 file changed, 15 insertions(+), 19 deletions(-)
+
+Index: curl/lib/http2.c
+===
+--- curl.orig/lib/http2.c
 curl/lib/http2.c
+@@ -155,6 +155,15 @@ static CURLcode http2_disconnect(struct
+   return CURLE_OK;
+ }
+ 
++static void free_push_headers(struct HTTP *stream)
++{
++  size_t i;
++  for(i = 0; ipush_headers_used; i++)
++free(stream->push_headers[i]);
++  Curl_safefree(stream->push_headers);
++  stream->push_headers_used = 0;
++}
++
+ /*
+  * The server may send us data at any point (e.g. PING frames). Therefore,
+  * we cannot assume that an HTTP/2 socket is dead just because it is readable.
+@@ -525,7 +534,6 @@ static int push_promise(struct Curl_easy
+ struct curl_pushheaders heads;
+ CURLMcode rc;
+ struct http_conn *httpc;
+-size_t i;
+ /* clone the parent */
+ struct Curl_easy *newhandle = duphandle(data);
+ if(!newhandle) {
+@@ -560,11 +568,7 @@ static int push_promise(struct Curl_easy
+ Curl_set_in_callback(data, false);
+ 
+ /* free the headers again */
+-for(i = 0; ipush_headers_used; i++)
+-  free(stream->push_headers[i]);
+-free(stream->push_headers);
+-stream->push_headers = NULL;
+-stream->push_headers_used = 0;
++free_push_headers(stream);
+ 
+ if(rv) {
+   DEBUGASSERT((rv > CURL_PUSH_OK) && (rv <= CURL_PUSH_ERROROUT));
+@@ -1001,10 +1005,10 @@ static int on_header(nghttp2_session *se
+ stream->push_headers_alloc) {
+   char **headp;
+   stream->push_headers_alloc *= 2;
+-  headp = Curl_saferealloc(stream->push_headers,
+-   stream->push_headers_alloc * sizeof(char *));
++  headp = realloc(stream->push_headers,
++  stream->push_headers_alloc * sizeof(char *));
+   if(!headp) {
+-stream->push_headers = NULL;
++free_push_headers(stream);
+ return NGHTTP2_ERR_TEMPORAL_CALLBACK_FAILURE;
+   }
+   stream->push_headers = headp;
+@@ -1170,14 +1174,7 @@ void Curl_http2_done(struct Curl_easy *d
+  setup */
+   Curl_d

Bug#1068946: png23d: Package Homepage is a broken link, here's the correct one

[David Fries]

Package: png23d
Version: 1.10-1.3
Severity: minor

Dear Maintainer,

The package home page is listed as
http://kyllikki.github.com/png23d/
but that returns 404 Page not found error.

The following looks to me like the page to use at this point.
https://github.com/kyllikki/png23d

-- 
David Fries 

-- System Information:
Debian Release: 11.6
Architecture: amd64 (x86_64)

Versions of packages png23d depends on:
ii  libc62.31-13+deb11u5
ii  libpng16-16  1.6.37-3

png23d recommends no packages.

png23d suggests no packages.

Bug#1066310: dx: FTBFS: _compparse.c:51:17: error: implicit declaration of function ‘_dxfcclex’ [-Werror=implicit-function-declaration]

[Bo YU]

Hi,

On Sun, Apr 14, 2024 at 5:11 AM Graham Inggs  wrote:
>
> Hi Bo
>
> > I have attached one debdiff and it can be built with it. So could you
> > upload it with it?
>
> The attached patch just seems to be papering over the problem, so I
> would rather not.
I agree with that.

I should add some background on the original post:
https://trac.macports.org/ticket/61842. On this thread, the maintainer
prefers to fix it in a correct way as you said. But given upstream of
dx, maybe this is very thorny.

BR,
Bo
>
> Regards
> Graham

Bug#1063531: RFS: mplayer/2:1.5+svn38446-2 -- movie player for Unix-like systems

[Lorenzo]

Hi,

On Sat, 13 Apr 2024 12:54:19 +0200 Tobias Frost  wrote:
> Uploaded, thanks for your contribution.
Thanks :)

> 
> Some remark:
> - On the BTS are quite a number of open bugs. Should they be triaged
> to see if they still have merit, reported upstream or otherwise
> handled?

Yes, I'm *very slowly* processing old bugs (for example #418855,
#753991 or other recently fixed) while dealing with the stream
of new ones ; for many of those (old bugs) there is not much I can do
apart from tagging though..
Besides from fixing frequent FTBFS, top priority on my TODO list are
#1038513, maybe #967643 and the quilt patch for CVE-2016-4352 (it's
reported as fixed upstream in 2016 but it still apply??)

Cheers,
Lorenzo
 
> 
> Cheers,
> tobi
> 
> On Fri, Feb 09, 2024 at 02:28:51PM +0100, Lorenzo wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "mplayer":
> > 
> >  * Package name : mplayer
> >Version  : 2:1.5+svn38446-2
> >Upstream contact : [fill in name and email of upstream]
> >  * URL  : https://mplayerhq.hu
> >  * License  : LGPL-2.1+, Expat, ISC, public-domain-tom,
> > GPL-2+, BSD-2-Clause, other-2, other-1
> >  * Vcs  :
> > https://salsa.debian.org/multimedia-team/mplayer Section  :
> > video
> > 
> > The source builds the following binary packages:
> > 
> >   mplayer-gui - movie player for Unix-like systems (GUI variant)
> >   mencoder - MPlayer's Movie Encoder
> >   mplayer - movie player for Unix-like systems
> >   mplayer-doc - documentation for MPlayer
> > 
> > To access further information about this package, please visit the
> > following URL:
> > 
> >   https://mentors.debian.net/package/mplayer/
> > 
> > Alternatively, you can download the package with 'dget' using this
> > command:
> > 
> >   dget -x
> >   
> > https://mentors.debian.net/debian/pool/main/m/mplayer/mplayer_1.5+svn38446-2.dsc
> > 
> > Git repo:
> > 
> >   
> > https://salsa.debian.org/multimedia-team/mplayer/-/tree/next?ref_type=heads
> > 
> > Changes since the last upload:
> > 
> >  mplayer (2:1.5+svn38446-2) unstable; urgency=medium
> >  .
> >* build a noaltivec variant of mplayer for powerpc
> >* install alternatives for mplayer-altivec and
> >   mplayer-noaltivec on powerpc; the altivec
> >   variant has the highest priority (Closes: #410962)
> >* d/control: B-D:
> >- add dh-exec
> >- replace obsolete pkg-config with pkgconf
> > 

Bug#1066342: eterm: FTBFS: libscream.c:3231:16: error: implicit declaration of function ‘safe_print_string’ [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: eterm
Followup-For: Bug #1066342
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru eterm-0.9.6/debian/patches/no-implicit-declarations.patch 
eterm-0.9.6/debian/patches/no-implicit-declarations.patch
--- eterm-0.9.6/debian/patches/no-implicit-declarations.patch   1969-12-31 
16:00:00.0 -0800
+++ eterm-0.9.6/debian/patches/no-implicit-declarations.patch   2024-04-13 
16:46:57.0 -0700
@@ -0,0 +1,18 @@
+Description: add missing include
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066342
+Last-Update: 2024-04-13
+Forwarded: no
+
+Index: eterm-0.9.6/src/libscream.c
+===
+--- eterm-0.9.6.orig/src/libscream.c
 eterm-0.9.6/src/libscream.c
+@@ -44,6 +44,7 @@
+ 
+ #include "config.h"
+ #include "feature.h"
++#include "misc.h"
+ 
+ /* use libast if we have it */
+ #ifdef DEBUG_ESCREEN
diff -Nru eterm-0.9.6/debian/patches/series eterm-0.9.6/debian/patches/series
--- eterm-0.9.6/debian/patches/series   2023-03-10 12:03:30.0 -0800
+++ eterm-0.9.6/debian/patches/series   2024-04-13 16:45:35.0 -0700
@@ -6,3 +6,4 @@
 fix-esetroot-on-pseudocolor.patch
 CVE-2021-33477.patch
 fix-fail-to-build-with-imlib2.patch
+no-implicit-declarations.patch

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

[Jay Berkenbilt]

Sorry for the top-post. As it happens, I am upstream. I have rewritten the 
pargraph
as follows. I think this is clearer. What do you think? If you like it, I'll 
close this. My fix
is here: https://github.com/qpdf/qpdf/pull/1187

---
It is not generally practical to remove objects from QDF files without
messing up object numbering, but if you remove all indirect references
to an object (without removing the object itself), this will leave the
object unreferenced. Then you can run qpdf on the file (after running
:command:`fix-qdf`), and qpdf will omit the now-orphaned object.
---

On Sun, Apr 7, 2024, at 5:04 AM, Thorsten Glaser wrote:
> Jay Berkenbilt dixit:
> 
> >Can you tell me where in the docs it says what you're describing?
> >Here's a direct quote from the current qpdf documentation:
> >
> >It is not generally practical to remove objects from QDF files without
> >messing up object numbering, but if you remove all references to an
> >object, you can run qpdf on the file (after running fix-qdf), and qpdf
> >will omit the now-orphaned object.
> 
> Yes, I meant that. At least two people assumed that “remove all
> references” includes the object itself, but now that you point it
> out, it likely doesn’t, but we are no native speakers, so I don’t
> know which of the two interpretations is more likely to them or
> if even both are possible.
> 
> Maybe, if you have good connections to upstream, suggest to them
> to add “(but not the object itself)” to behind “all references to
> an object”, but the bug can then be closed.
> 
> Thanks for looking into it,
> //mirabilos
> -- 
> Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
> schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
> Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
> hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
> 

Bug#1066260: mrtdreader: FTBFS: mrtdreader.c:95:41: error: implicit declaration of function ‘isprint’ [-Werror=implicit-function-declaration]

[Michael Hudson-Doyle]

Package: mrtdreader
Followup-For: Bug #1066260
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:

  * Add #include of  to src/mrtdreader.c to fix build with
-Werror=implicit-function-declaration.

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-27-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 mrtdreader-0.1.6/debian/control mrtdreader-0.1.6/debian/control
--- mrtdreader-0.1.6/debian/control 2024-04-01 09:10:39.0 +1300
+++ mrtdreader-0.1.6/debian/control 2024-04-14 11:19:27.0 +1200
@@ -1,6 +1,5 @@
 Source: mrtdreader
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Ruben Undheim 
+Maintainer: Ruben Undheim 
 Section: utils
 Priority: optional
 Build-Depends: dpkg-dev (>= 1.22.5), debhelper (>= 11),
diff -Nru mrtdreader-0.1.6/debian/patches/missing-include.patch 
mrtdreader-0.1.6/debian/patches/missing-include.patch
--- mrtdreader-0.1.6/debian/patches/missing-include.patch   1970-01-01 
12:00:00.0 +1200
+++ mrtdreader-0.1.6/debian/patches/missing-include.patch   2024-04-14 
11:19:27.0 +1200
@@ -0,0 +1,10 @@
+--- a/src/mrtdreader.c
 b/src/mrtdreader.c
+@@ -19,6 +19,7 @@
+  */
+ 
+ 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru mrtdreader-0.1.6/debian/patches/series 
mrtdreader-0.1.6/debian/patches/series
--- mrtdreader-0.1.6/debian/patches/series  1970-01-01 12:00:00.0 
+1200
+++ mrtdreader-0.1.6/debian/patches/series  2024-04-14 11:18:28.0 
+1200
@@ -0,0 +1 @@
+missing-include.patch

Bug#1068945: ITP: rust-names -- generator for random names suitable for containers, projects, applications etc.

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rust-names
  Version : 0.14.0
  Upstream Contact: Fletcher Nichol 
* URL : https://crates.io/crates/names
* License : MIT
  Programming Lang: Rust
  Description : generator for random names suitable for containers, 
projects, applications etc.
   A random name generator with names suitable for use in container instances, 
project names,
   application instances, etc.

This is a dependency for zellij-utils, in turn a dependency that will be needed 
to package zellij.

Bug#1067126: RFS: lighttpd/1.4.76-1 -- light, fast, functional web server

[gs-bugs . debian . org]

lighttpd-1.4.76-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.76-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4


lighttpd (1.4.76-1) unstable; urgency=medium
  * New upstream version 1.4.76
  * Detect VU#421644 HTTP/2 CONTINUATION Flood
  * Avoid CVE-2024-3094 xz supply chain attack

Bug#1068065: RM: quorum [armhf i386 armel] -- ROM; cannot build on 32-bit archs due to missing builddeps

[Nilesh Patra]

retitle 1068065 RM: quorum [armhf i386 armel] -- ROM; cannot build on 32-bit 
archs due to missing builddeps
reassign 1068065 ftp.debian.org
user ftp.debian@packages.debian.org
usertags 1068065 remove
stop

Hi,

quorum builddeps on jellyfish which is not present on 32-bit archs any
longer[1].
There is already some concensus in -med team to prune 32-bit arch support for
end-user applications (like quorum) if it is not straightfwd to maintain the
support. It should make it to policy soonish.

[1]: 
https://tracker.debian.org/news/1513470/accepted-jellyfish-231-3-source-into-unstable/

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1066334: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])

[Jeremy Sowden]

On 2024-04-13, at 21:48:10 +0100, Jeremy Sowden wrote:
> On 2024-04-13, at 09:31:07 +0200, Andreas Tille wrote:
> > Control: tags -1 help
> > thanks
> > 
> > Hi,
> > 
> > while I was able to fix the origininal cause of the failure I'm now blocked 
> > by
> > some issue that cython seems to miss adding some
> >#include 
> > but I have no idea how to accomplish this.  The Salsa CI build log[1] says:
> > 
> > ...
> > y.tab.c: In function 'yyparse':
> > y.tab.c:1409:16: error: implicit declaration of function 'yylex' 
> > [-Werror=implicit-function-declaration]
> > y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you 
> > mean 'YYerror'? [-Werror=implicit-function-declaration]
> > In file included from aqlparse.y:335:
> > aqlparse.l: In function 'yylex':
> > ...
> > 
> > Any help would be welcome
> > Andreas.
> 
> You are missing declarations:
> 
>  * `yylex`   - this needs to be added to the yacc source
>  * `yyerror` - this is present but hidden by a CPP conditional
>  * `yywrap`  - this is not needed (grep for "YY_SKIP_YYWRAP") and can be
>disabled
> 
> Patch attached.

I attach a fix for the next error:

  gcc -g -Wall  -DACEDB4 `../w3rdparty/include-config glib-2.0 gtk+-2.0`  -I.. 
-I../wh -I../wstaden -DACEDB_GTK -DLINUX -c -o sigsubs.o sigsubs.c
  sigsubs.c: In function 'getSignalText':
  sigsubs.c:486:30: error: '_sys_siglist' undeclared (first use in this 
function)
486 |   char **signal_textlist = &(_sys_siglist[0]) ;
|  ^~~~
  sigsubs.c:486:30: note: each undeclared identifier is reported only once for 
each function it appears in

The one after this looks like a GTK problem, and that's the point at
which I bow out.

J.
diff --git a/w4/sigsubs.c b/w4/sigsubs.c
index 2fd0c6ce9155..9d2942df1642 100644
--- a/w4/sigsubs.c
+++ b/w4/sigsubs.c
@@ -467,6 +467,10 @@ static char *getSignalText(int sig_num)
 
   return "unknown";
 
+#elif defined(LINUX)
+
+  return strsignal(sig_num);
+
 #else
 
   char *sig_text = NULL ;
@@ -485,7 +489,7 @@ static char *getSignalText(int sig_num)
 
   char **signal_textlist = &(_sys_siglist[0]) ;
 
-#if defined(LINUX) || defined(OPTERON) || defined(HP)
+#if defined(OPTERON) || defined(HP)
   int   signal_max= _NSIG ;
 #else
   int   signal_max= _sys_nsig ;


signature.asc
Description: PGP signature

Bug#1067088: [Pkg-zfsonlinux-devel] Bug#1067088: zfs-linux: missing B-D: libtirpc-dev

[Sebastian Ramacher]

Hi Aron

On 2024-03-18 18:29:51 +0800, Aron Xu wrote:
> Control: tags -1 + pending
> 
> On Mon, Mar 18, 2024 at 5:31 PM Andreas Beckmann  wrote:
> >
> >
> > This could be fixed by adding an explicit Build-Depends on libtirpc-dev.
> > The glibc change will likely be reverted in the short term, but given
> > its a change we want to do for Trixie, this will only lower the severity
> > of the bug.
> >
> 
> This has been fixed in git and will be addressed in the next upload.
> 
> https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/f2ca97fdca7a35d63a3bae1af106bc3c238ca95f

The package is involved in the time_t transition. So please upload the
fix.

Cheers
-- 
Sebastian Ramacher

Bug#1065721: simage: FTBFS: error: conflicti ng types for ‘GifQuantizeBuffer’; have ‘int(unsigned int, unsigned int, int *, GifBy teType *, GifByteType *, GifByteType *, GifByteType *, GifColo

[Steven Robbins]

Control: severity -1 normal
thanks


On Sat, 9 Mar 2024 13:03:05 +0100 Sebastian Ramacher  
wrote:
> Source: simage
> Version: 1.8.3+ds-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the 
past)

The bug is fixed in unstable.  But the promotion to testing is held up by weird 
dependency issues.

I'm downgrading the bug to prevent removal from testing.  I see no reason to 
remove a package that does build properly in unstable.

-Steve


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

Bug#1068944: multipath-tools: hard-coded dependency on libaio1

[Sebastian Ramacher]

Package: multipath-tools
Version: 0.9.7-6
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

multipath-tools has a hard-coded depenency on libaio1 which is involved
in the time_t transition. Note that libaio1t64 is included in
${shlib:Depends} so the hard-coded dependency can be removed.

Cheers
-- 
Sebastian Ramacher

Bug#1066310: dx: FTBFS: _compparse.c:51:17: error: implicit declaration of function ‘_dxfcclex’ [-Werror=implicit-function-declaration]

[Graham Inggs]

Hi Bo

> I have attached one debdiff and it can be built with it. So could you
> upload it with it?

The attached patch just seems to be papering over the problem, so I
would rather not.

Regards
Graham

Bug#1068219: chatty: diff for NMU version 0.8.2-1.1

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for chatty (versioned as 0.8.2-1.1). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru chatty-0.8.2/debian/changelog chatty-0.8.2/debian/changelog
--- chatty-0.8.2/debian/changelog	2024-03-18 03:21:04.0 +0100
+++ chatty-0.8.2/debian/changelog	2024-04-13 23:05:24.0 +0200
@@ -1,3 +1,12 @@
+chatty (0.8.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Julian Andres Klode ]
+  * Bump local shlibs for libpurple0t64. (Closes: #1068219)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 23:05:24 +0200
+
 chatty (0.8.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru chatty-0.8.2/debian/shlibs.local chatty-0.8.2/debian/shlibs.local
--- chatty-0.8.2/debian/shlibs.local	2023-05-14 11:49:24.0 +0200
+++ chatty-0.8.2/debian/shlibs.local	2024-04-13 23:04:49.0 +0200
@@ -1 +1 @@
-libjabber 0 libpurple0
+libjabber 0 libpurple0t64

Bug#1068823: (No Subject)

[mYnDstrEAm]

> Personally, I don't think a machine that has that limited storage ought to be 
> upgraded using apt from one Debian stable release to another.

It's not the machine but the partition. One can set up Debian to use a separate 
partition for the home directory. When the root partition on a SSD has 20 GB 
(about the size I think all guides I found on this suggest or use in their 
example) which should be large enough and the upgrade claims it needs 5 GB and 
actually needs 7 GB that can obviously be a problem.

> it is not supported to arbitrarily break apt updates up like that

...which is why this an issue for a new functionality rather than already 
existing. It doesn't have to be arbitrary.

It's common sense to break up GB-sized downloads into several steps. Last 
upgrade failed due to disk space issues; this upgrade I had to clean caches 
during the upgrade as workaround; I'm sure many have this problem and even if 
it's rare it would be best to have upgrades run smoothly and reliably (such as 
checking remaining disk space throughout the upgrade and adjusting 
accordingly). Those are not several upgrade but one upgrade that downloads not 
once initially but several times and cleans up the caches after each step.

Bug#1062515: eb: diff for NMU version 4.4.3-14.2

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for eb (versioned as 4.4.3-14.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru eb-4.4.3/debian/changelog eb-4.4.3/debian/changelog
--- eb-4.4.3/debian/changelog	2024-02-28 03:41:16.0 +0100
+++ eb-4.4.3/debian/changelog	2024-04-13 22:34:19.0 +0200
@@ -1,3 +1,10 @@
+eb (4.4.3-14.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/shlibs.local: Removed, not needed. (Closes: #1062515)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 22:34:19 +0200
+
 eb (4.4.3-14.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru eb-4.4.3/debian/shlibs.local eb-4.4.3/debian/shlibs.local
--- eb-4.4.3/debian/shlibs.local	2022-04-28 15:40:06.0 +0200
+++ eb-4.4.3/debian/shlibs.local	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-libeb 16 libeb16

Bug#1068433: riseup-vpn: diff for NMU version 0.21.11+ds1-5.1

[Sebastian Ramacher]

Control: tags 1068433 + patch


Dear maintainer,

I've prepared an NMU for riseup-vpn (versioned as 0.21.11+ds1-5.1). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru riseup-vpn-0.21.11+ds1/debian/changelog riseup-vpn-0.21.11+ds1/debian/changelog
--- riseup-vpn-0.21.11+ds1/debian/changelog	2023-03-09 05:21:22.0 +0100
+++ riseup-vpn-0.21.11+ds1/debian/changelog	2024-04-13 22:46:43.0 +0200
@@ -1,3 +1,13 @@
+riseup-vpn (0.21.11+ds1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Matthias Klose ]
+  * Drop hard-coded dependencies on shared libraries, ${shlibs:Depends}
+is working these days. (Closes: #1068433)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 22:46:43 +0200
+
 riseup-vpn (0.21.11+ds1-5) unstable; urgency=medium
 
   * Add procps, iproute2 and iptables to Depends (Closes: #1031905)
diff -Nru riseup-vpn-0.21.11+ds1/debian/control riseup-vpn-0.21.11+ds1/debian/control
--- riseup-vpn-0.21.11+ds1/debian/control	2023-03-09 05:21:22.0 +0100
+++ riseup-vpn-0.21.11+ds1/debian/control	2024-04-13 22:46:39.0 +0200
@@ -57,10 +57,6 @@
  pkexec,
  procps,
  python3:any,
- libqt5core5a,
- libqt5gui5 | libqt5gui5-gles,
- libqt5qml5,
- libqt5widgets5,
  qml-module-qtquick2,
  qml-module-qtquick-controls2,
  qml-module-qtquick-controls,

Bug#1066334: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])

[Jeremy Sowden]

On 2024-04-13, at 09:31:07 +0200, Andreas Tille wrote:
> Control: tags -1 help
> thanks
> 
> Hi,
> 
> while I was able to fix the origininal cause of the failure I'm now blocked by
> some issue that cython seems to miss adding some
>#include 
> but I have no idea how to accomplish this.  The Salsa CI build log[1] says:
> 
> ...
> y.tab.c: In function 'yyparse':
> y.tab.c:1409:16: error: implicit declaration of function 'yylex' 
> [-Werror=implicit-function-declaration]
> y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you 
> mean 'YYerror'? [-Werror=implicit-function-declaration]
> In file included from aqlparse.y:335:
> aqlparse.l: In function 'yylex':
> ...
> 
> Any help would be welcome
> Andreas.

You are missing declarations:

 * `yylex`   - this needs to be added to the yacc source
 * `yyerror` - this is present but hidden by a CPP conditional
 * `yywrap`  - this is not needed (grep for "YY_SKIP_YYWRAP") and can be
   disabled

Patch attached.

You can find more info about all three in the flex and bison manuals.

J.
diff --git a/waql/aql_.h b/waql/aql_.h
index cde94a97896b..dd3b89116280 100644
--- a/waql/aql_.h
+++ b/waql/aql_.h
@@ -448,7 +448,7 @@ char* aqlNodeTypeName (AqlNodeType inType);
 char* aqlOpTypeName (AqlOpType inType);
 char* aqlLocSourceTypeName (AqlLocSourceType inType);
 
-#if defined(IBM)
+#if defined(IBM) || defined(LINUX)
 /* predeclare lex.yy.c fns */
 void yyerror (char *s);
 #endif
diff --git a/waql/aqlparse.l b/waql/aqlparse.l
index 313375027957..bc232e0a4c48 100644
--- a/waql/aqlparse.l
+++ b/waql/aqlparse.l
@@ -102,6 +102,8 @@
 
 %}
 
+%option			noyywrap
+
 letter			[A-Za-z]
 digit			[0-9]
 id			{letter}({letter}|{digit}|"_")*
diff --git a/waql/aqlparse.y b/waql/aqlparse.y
index 9989831a4838..975ae325c14c 100644
--- a/waql/aqlparse.y
+++ b/waql/aqlparse.y
@@ -77,6 +77,8 @@ static int tokPos[1024];
 
 /**/
 
+int yylex(void);
+
 %}
  
 %union  {


signature.asc
Description: PGP signature

Bug#1065790: libosmo-netif: FTBFS on arm{el,hf}: tests fail

[Steve Langasek]

Package: libosmo-netif
Followup-For: Bug #1065790
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Well, maybe a version of the patch without a stray character that breaks
compilation.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch 
libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch
--- libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch  1969-12-31 
16:00:00.0 -0800
+++ libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch  2024-04-13 
12:31:32.0 -0700
@@ -0,0 +1,136 @@
+Description: use a 64-bit safe format string for time_t.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1065790
+Last-Update: 2024-04-13
+Forwarded: no
+
+Index: libosmo-netif-1.2.0/examples/ipa-stream-client.c
+===
+--- libosmo-netif-1.2.0.orig/examples/ipa-stream-client.c
 libosmo-netif-1.2.0/examples/ipa-stream-client.c
+@@ -143,7 +143,8 @@
+   timersub(&tv, &found->tv, &diff);
+ 
+   LOGP(DLINP, LOGL_NOTICE, "message %d replied "
+-  "in %lu.%.6lu\n", num, diff.tv_sec, diff.tv_usec);
++  "in %lld.%.6lld\n", num, (long long int)diff.tv_sec,
++  (long long int)diff.tv_usec);
+   talloc_free(found);
+   } else {
+   LOGP(DLINP, LOGL_ERROR,
+Index: libosmo-netif-1.2.0/src/jibuf.c
+===
+--- libosmo-netif-1.2.0.orig/src/jibuf.c
 libosmo-netif-1.2.0/src/jibuf.c
+@@ -385,10 +385,10 @@
+   timeradd(&jb->last_enqueue_time, &delay_ts, &sched_ts);
+ 
+   LOGP(DLJIBUF, LOGL_DEBUG, "enqueuing packet seq=%"PRIu16" rel=%d 
delay=%d" \
+-  " skew=%d thres=%d {%lu.%06lu -> %lu.%06lu} %s\n",
++  " skew=%d thres=%d {%lld.%06lld -> %lld.%06lld} %s\n",
+   msg_get_sequence(msg), rel_delay, delay, jb->skew_us, 
jb->threshold_delay,
+-  jb->last_enqueue_time.tv_sec, jb->last_enqueue_time.tv_usec,
+-  sched_ts.tv_sec, sched_ts.tv_usec, msg_get_marker(msg)? "M" : 
"");
++  (long long int)jb->last_enqueue_time.tv_sec, (long long 
int)jb->last_enqueue_time.tv_usec,
++  (long long int)sched_ts.tv_sec, (long long 
int)sched_ts.tv_usec, msg_get_marker(msg)? "M" : "");
+ 
+   /* Add scheduled dequeue time in msg->cb so we can check it later */
+   unsigned long *old_cb = talloc_memdup(jb->talloc_ctx, msg->cb, 
sizeof(msg->cb));
+Index: libosmo-netif-1.2.0/tests/osmux/osmux_test.c
+===
+--- libosmo-netif-1.2.0.orig/tests/osmux/osmux_test.c
 libosmo-netif-1.2.0/tests/osmux/osmux_test.c
+@@ -69,8 +69,10 @@
+   struct timeval tv; \
+   osmo_clock_gettime(CLOCK_MONOTONIC, &ts); \
+   osmo_gettimeofday(&tv, NULL); \
+-  fprintf(stderr, "sys={%lu.%06lu}, mono={%lu.%06lu}: " fmt, \
+-  tv.tv_sec, tv.tv_usec, ts.tv_sec, ts.tv_nsec/1000, 
##args); \
++  fprintf(stderr, "sys={%lld.%06lld}, mono={%lld.%06lld}: " fmt, \
++  (long long int)tv.tv_sec, (long long int)tv.tv_usec, \
++  (long long int)ts.tv_sec, \
++  (long long int)ts.tv_nsec/1000, ##args); \
+   } while(0)
+ 
+ static void clock_override_enable(bool enable)
+Index: libosmo-netif-1.2.0/tests/stream/stream_test.c
+===
+--- libosmo-netif-1.2.0.orig/tests/stream/stream_test.c
 libosmo-netif-1.2.0/tests/stream/stream_test.c
+@@ -60,7 +60,7 @@
+ #define LOGCLI(cli, fmt, args...) do { \
+   struct timeval tv; \
+   osmo_gettimeofday(&tv, NULL); \
+-  printf("{%lu.%06lu} [%s] Client's %s(): " fmt, tv.tv_sec, 
tv.tv_usec, \
++  printf("{%lld.%06lld} [%s] Client's %s(): " fmt, (long long 
int)tv.tv_sec, (long long int)tv.tv_usec, \
+  osmo_stream_cli_get_data(cli) ? "OK" : "NA", __func__, 
##args); \
+   } while (0)
+ 
+@@ -235,7 +235,7 @@
+ #define LOGSRV(srv, fmt, args...) do { \
+   struct timeval tv; \
+   osmo_gettimeofday(&tv, NULL); \
+-  printf("{%lu.%06lu} [%s|%s] Server's %s(): " fmt,  tv.tv_sec, 
tv.tv_usec, \
++  printf("{%lld.%06lld} [%s|%s] Server's %s(): " fmt,  (long long 
int)tv.tv_sec, (long long int)tv.tv_usec, \
+  osmo_stream_srv_get_data(srv) ? "OK" : "NA", \
+  
osmo_stream_srv_link_get_data(osmo_stream_srv_get_ma

Bug#1068823: (No Subject)

[Jeremy Bícha]

Control: reassign -1 src:apt
Control: severity -1 wishlist

On Sat, Apr 13, 2024 at 1:00 PM mYnDstrEAm  wrote:
> Thanks guys, these are very useful methods and I'll mention these as 
> alternatives to disk cleanups recommended at 
> https://unix.stackexchange.com/q/774199/233262 (this would probably very 
> useful to have at places about upgrades failing due to disk space issues even 
> though people only look these up once the problems already occurred).
>
> However, the problem of the upgrade requiring more disk space than displayed 
> at first remains and the command by Zeimetz can't be used with a built-in 
> rememberable well-known command like sudo apt-get upgrade --stepwise

Personally, I don't think a machine that has that limited storage
ought to be upgraded using apt from one Debian stable release to
another. I suggest upgrading the storage first. If that's not
possible, I recommend replacing the OS with a new image of Debian
rather than trying to use apt to upgrade a few packages at a time. As
has already been mentioned, it is not supported to arbitrarily break
apt updates up like that to upgrade from say Debian 12 to the
not-yet-released Debian 13.

Thank you,
Jeremy Bícha

Bug#1067567: dhcp-probe: diff for NMU version 1.3.0-10.2

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for dhcp-probe (versioned as 1.3.0-10.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru dhcp-probe-1.3.0/debian/changelog dhcp-probe-1.3.0/debian/changelog
--- dhcp-probe-1.3.0/debian/changelog	2014-10-15 14:20:18.0 +0200
+++ dhcp-probe-1.3.0/debian/changelog	2024-04-13 22:39:00.0 +0200
@@ -1,3 +1,13 @@
+dhcp-probe (1.3.0-10.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Julian Andres Klode ]
+  * Remove hardcoded libpcap0.8, libnet1 dependencies; shlibs adds right ones
+(Closes: #1067567)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 22:39:00 +0200
+
 dhcp-probe (1.3.0-10.1) unstable; urgency=low
 
   * NMU
diff -Nru dhcp-probe-1.3.0/debian/control dhcp-probe-1.3.0/debian/control
--- dhcp-probe-1.3.0/debian/control	2014-10-15 14:21:32.0 +0200
+++ dhcp-probe-1.3.0/debian/control	2024-04-13 22:38:18.0 +0200
@@ -8,7 +8,7 @@
 
 Package: dhcp-probe
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, libpcap0.8 (>= 0.9), libnet1 (>= 1.1.2.1-3), net-tools
+Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, net-tools
 Description: network DHCP or BootP server discover
  dhcp_probe attempts to discover DHCP and BootP servers on a directly-attached
  Ethernet network. A network administrator can use this tool to locate un-

Bug#1068221: comet-ms: diff for NMU version 2019015+cleaned1-4.1

[Sebastian Ramacher]

Control: tags 1068221 + patch


Dear maintainer,

I've prepared an NMU for comet-ms (versioned as 2019015+cleaned1-4.1). The diff
is attached to this message.

Cheers

-- 
Sebastian Ramacher
diff -Nru comet-ms-2019015+cleaned1/debian/changelog comet-ms-2019015+cleaned1/debian/changelog
--- comet-ms-2019015+cleaned1/debian/changelog	2023-11-24 15:11:18.0 +0100
+++ comet-ms-2019015+cleaned1/debian/changelog	2024-04-13 22:27:15.0 +0200
@@ -1,3 +1,11 @@
+comet-ms (2019015+cleaned1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Remove hard-coded dependency on libmstoolkit82. (Closes:
+#1068221)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 22:27:15 +0200
+
 comet-ms (2019015+cleaned1-4) unstable; urgency=low
 
   * Fix the Bug#1043799: comet-ms: Fails to build source after successful
diff -Nru comet-ms-2019015+cleaned1/debian/control comet-ms-2019015+cleaned1/debian/control
--- comet-ms-2019015+cleaned1/debian/control	2023-11-24 15:11:18.0 +0100
+++ comet-ms-2019015+cleaned1/debian/control	2024-04-13 22:26:37.0 +0200
@@ -15,8 +15,7 @@
 
 Package: comet-ms
 Architecture: any
-Depends: libmstoolkit82 (>= 82),
- ${shlibs:Depends},
+Depends: ${shlibs:Depends},
  ${misc:Depends}
 Description: Tandem mass spectrometry (MS/MS) search engine
  Comet is an open source tandem mass spectrometry (MS/MS) sequence

Bug#1067174: cpupower-gui: diff for NMU version 0.7.2-2.2

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for cpupower-gui (versioned as 0.7.2-2.2). The diff
is attached to this message.

Cheer
-- 
Sebastian Ramacher
diff -Nru cpupower-gui-0.7.2/debian/changelog cpupower-gui-0.7.2/debian/changelog
--- cpupower-gui-0.7.2/debian/changelog	2023-08-04 22:43:45.0 +0200
+++ cpupower-gui-0.7.2/debian/changelog	2024-04-13 22:20:07.0 +0200
@@ -1,3 +1,11 @@
+cpupower-gui (0.7.2-2.2) unstable; urgency=medium
+
+  [ Julian Andres Klode ]
+  * Drop unnecessary libgtk-3-0 dependency, gir1.2-gtk-3.0 pulls it in.
+(Closes: #1067174)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 22:20:07 +0200
+
 cpupower-gui (0.7.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cpupower-gui-0.7.2/debian/control cpupower-gui-0.7.2/debian/control
--- cpupower-gui-0.7.2/debian/control	2019-11-29 23:40:57.0 +0100
+++ cpupower-gui-0.7.2/debian/control	2024-04-13 22:19:38.0 +0200
@@ -19,7 +19,7 @@
 
 Package: cpupower-gui
 Architecture: any
-Depends: libgtk-3-0, gir1.2-gtk-3.0, python3-gi, hicolor-icon-theme,
+Depends: gir1.2-gtk-3.0, python3-gi, hicolor-icon-theme,
  policykit-1, python3-dbus, ${misc:Depends}, ${python3:Depends}
 Suggests: policykit-1-gnome, lxqt-policykit, mate-polkit, lxsession
 Description: GUI utility to change the CPU frequency

Bug#1068942: src:oscar4: unsatisfied build dependency in testing: emboss-data

[Paul Gevers]

Source: oscar4
Version: 5.2.0+dfsg-2
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#921954: gnulib

[Jonas Smedegaard]

Hi Simon (and Boyuan),

Quoting Simon Josefsson (2024-04-13 19:38:06)
> You may have noticed I adopted gnulib and have made an upload to
> experimental.  I am happy to have this team maintained, so feel free to
> join the effort -- I added Boyuan to Uploaders: since you've been doing
> QA uploads for some time, but happy to add others too.
> 
> If you don't object, I will upload to unstable in a couple of days if
> nothing comes up.  Relevant reading material on the changes I did for
> this package:
> 
> https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/README.source
> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
> 
> What do you think?  I hope I'm not stepping on anyone's toes here.  The
> package was orphaned and is a critical component to be able to build
> source-only tarballs for other packages in Debian.

I am happy that gnulib is in good hands.

I've moved on to other challenges, and have no interest in working on
gnulib now.  That said, you are welcome to try nudge me if some concrete
task emerges where you image I might be of help.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1063157: mysql++: diff for NMU version 3.2.5-2.3

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for mysql++ (versioned as 3.2.5-2.3). The diff
is attached to this message.

Cheers

-- 
Sebastian Ramacher
diff -Nru mysql++-3.2.5/debian/changelog mysql++-3.2.5/debian/changelog
--- mysql++-3.2.5/debian/changelog	2024-02-28 22:42:21.0 +0100
+++ mysql++-3.2.5/debian/changelog	2024-04-13 22:06:14.0 +0200
@@ -1,3 +1,11 @@
+mysql++ (3.2.5-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Drop now obsolete dh_makeshlibs override producing wrong
+dependencies with renamed libraries. (Closes: #1063157)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 22:06:14 +0200
+
 mysql++ (3.2.5-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mysql++-3.2.5/debian/rules mysql++-3.2.5/debian/rules
--- mysql++-3.2.5/debian/rules	2020-04-23 03:37:47.0 +0200
+++ mysql++-3.2.5/debian/rules	2024-04-13 22:05:24.0 +0200
@@ -15,7 +15,3 @@
 override_dh_autoreconf:
 	# autoreconf fails unless aclocal is skipped
 	ACLOCAL=true dh_autoreconf
-
-override_dh_makeshlibs:
-	# For new symbols when compiled with GCC 7
-	dh_makeshlibs -V'libmysql++3v5 (>= 3.2.5-1~)'

Bug#1068941: src:mdevctl: unsatisfied build dependency in testing: librust-env-logger-0.10.0+default-dev

[Paul Gevers]

Source: mdevctl
Version: 1.3.0-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062881: mia: NMU diff for 64-bit time_t transition

[Adrian Bunk]

On Sat, Feb 03, 2024 at 09:20:05PM +, Graham Inggs wrote:
> Source: mia
> Version: 2.4.7-13
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>...

Was this forgotten to upload to unstable, or was there a reason why it 
was deemed unnecessary?

Thanks
Adrian

Bug#1068940: json-smart: please package the new upstream version

[Bastien Roucariès]

Source: json-smart
Version: 2.2-3
Severity: wishlist

Dear Maintainer,

Please package the new upstream version

I do not achieve to get maven compile it

Bastien

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

Bug#1068694: bullseye-pu: package json-smart/2.2-2+deb11u1

[Bastien Roucariès]

Le samedi 13 avril 2024, 14:01:24 UTC Bastien Roucariès a écrit :
> Le samedi 13 avril 2024, 14:00:00 UTC Moritz Mühlenhoff a écrit :
> Hi,
> 
> > Am Tue, Apr 09, 2024 at 10:01:11AM +0200 schrieb Andreas Beckmann:
> > > Package: release.debian.org
> > > Severity: normal
> > > Tags: bullseye
> > > User: release.debian@packages.debian.org
> > > Usertags: pu
> > > X-Debbugs-Cc: Bastien Roucariès 
> > > Control: affects -1 + src:json-smart
> > > Control: block 1039985 with -1
> > > Control: block 1033474 with -1
> > > 
> > > [ Reason ]
> > > Two CVEs were fixed in buster-lts, but not yet in bullseye or later,
> > > causing version skew on upgrades:
> > 
> > CVE-2023-1370 / #1033474 is unfixed in sid, and being fixed in unstable
> > is a pre condition for a point update.
> > 
> > Bastien, since you fixed it in buster-lts, can you please also take care
> > of addressing unstable?

Done
> 
> 
> Ok will do
> > 
> > Cheers,
> > Moritz
> > 
> 
> 



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

Bug#1065790: libosmo-netif: FTBFS on arm{el,hf}: tests fail

[Steve Langasek]

Package: libosmo-netif
Followup-For: Bug #1065790
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached an alternative solution to this which has been uploaded
to Ubuntu.  I found it easier to fix the portability issue than deal with
removing the reverse-dependency chain.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch 
libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch
--- libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch  1969-12-31 
16:00:00.0 -0800
+++ libosmo-netif-1.2.0/debian/patches/64-bit-time-t.patch  2024-04-13 
12:30:35.0 -0700
@@ -0,0 +1,142 @@
+Description: use a 64-bit safe format string for time_t.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1065790
+Last-Update: 2024-04-13
+Forwarded: no
+
+Index: libosmo-netif-1.2.0/examples/ipa-stream-client.c
+===
+--- libosmo-netif-1.2.0.orig/examples/ipa-stream-client.c
 libosmo-netif-1.2.0/examples/ipa-stream-client.c
+@@ -143,7 +143,8 @@
+   timersub(&tv, &found->tv, &diff);
+ 
+   LOGP(DLINP, LOGL_NOTICE, "message %d replied "
+-  "in %lu.%.6lu\n", num, diff.tv_sec, diff.tv_usec);
++  "in %lld.%.6lld\n", num, (long long int)diff.tv_sec,
++  (long long int)diff.tv_usec);
+   talloc_free(found);
+   } else {
+   LOGP(DLINP, LOGL_ERROR,
+Index: libosmo-netif-1.2.0/src/jibuf.c
+===
+--- libosmo-netif-1.2.0.orig/src/jibuf.c
 libosmo-netif-1.2.0/src/jibuf.c
+@@ -385,10 +385,10 @@
+   timeradd(&jb->last_enqueue_time, &delay_ts, &sched_ts);
+ 
+   LOGP(DLJIBUF, LOGL_DEBUG, "enqueuing packet seq=%"PRIu16" rel=%d 
delay=%d" \
+-  " skew=%d thres=%d {%lu.%06lu -> %lu.%06lu} %s\n",
++  " skew=%d thres=%d {%lld.%06lld -> %lld.%06lld} %s\n",
+   msg_get_sequence(msg), rel_delay, delay, jb->skew_us, 
jb->threshold_delay,
+-  jb->last_enqueue_time.tv_sec, jb->last_enqueue_time.tv_usec,
+-  sched_ts.tv_sec, sched_ts.tv_usec, msg_get_marker(msg)? "M" : 
"");
++  (long long int)jb->last_enqueue_time.tv_sec, (long long 
int)jb->last_enqueue_time.tv_usec,
++  (long long int)sched_ts.tv_sec, (long long 
int)sched_ts.tv_usec, msg_get_marker(msg)? "M" : "");
+ 
+   /* Add scheduled dequeue time in msg->cb so we can check it later */
+   unsigned long *old_cb = talloc_memdup(jb->talloc_ctx, msg->cb, 
sizeof(msg->cb));
+Index: libosmo-netif-1.2.0/tests/osmux/osmux_test.c
+===
+--- libosmo-netif-1.2.0.orig/tests/osmux/osmux_test.c
 libosmo-netif-1.2.0/tests/osmux/osmux_test.c
+@@ -1,4 +1,4 @@
+-/*
++y/*
+  * (C) 2013 by Pablo Neira Ayuso 
+  * (C) 2013 by On Waves ehf 
+  *
+@@ -69,8 +69,10 @@
+   struct timeval tv; \
+   osmo_clock_gettime(CLOCK_MONOTONIC, &ts); \
+   osmo_gettimeofday(&tv, NULL); \
+-  fprintf(stderr, "sys={%lu.%06lu}, mono={%lu.%06lu}: " fmt, \
+-  tv.tv_sec, tv.tv_usec, ts.tv_sec, ts.tv_nsec/1000, 
##args); \
++  fprintf(stderr, "sys={%lld.%06lld}, mono={%lld.%06lld}: " fmt, \
++  (long long int)tv.tv_sec, (long long int)tv.tv_usec, \
++  (long long int)ts.tv_sec, \
++  (long long int)ts.tv_nsec/1000, ##args); \
+   } while(0)
+ 
+ static void clock_override_enable(bool enable)
+Index: libosmo-netif-1.2.0/tests/stream/stream_test.c
+===
+--- libosmo-netif-1.2.0.orig/tests/stream/stream_test.c
 libosmo-netif-1.2.0/tests/stream/stream_test.c
+@@ -60,7 +60,7 @@
+ #define LOGCLI(cli, fmt, args...) do { \
+   struct timeval tv; \
+   osmo_gettimeofday(&tv, NULL); \
+-  printf("{%lu.%06lu} [%s] Client's %s(): " fmt, tv.tv_sec, 
tv.tv_usec, \
++  printf("{%lld.%06lld} [%s] Client's %s(): " fmt, (long long 
int)tv.tv_sec, (long long int)tv.tv_usec, \
+  osmo_stream_cli_get_data(cli) ? "OK" : "NA", __func__, 
##args); \
+   } while (0)
+ 
+@@ -235,7 +235,7 @@
+ #define LOGSRV(srv, fmt, args...) do { \
+   struct timeval tv; \
+   osmo_gettimeofday(&tv, NULL); \
+-  printf("{%lu.%06lu} [%s|%s] Server's %s(): " fmt,  tv.tv_sec, 
tv.tv_usec, \
++  printf("{%lld.%06lld} [%s|

Bug#1068939: openexr: CVE-2024-31047

[Salvatore Bonaccorso]

Source: openexr
Version: 3.1.5-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/AcademySoftwareFoundation/openexr/issues/1680
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for openexr.

CVE-2024-31047[0]:
| An issue in Academy Software Foundation openexr v.3.2.3 and before
| allows a local attacker to cause a denial of service (DoS) via the
| convert function of exrmultipart.cpp.


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-31047
https://www.cve.org/CVERecord?id=CVE-2024-31047
[1] https://github.com/AcademySoftwareFoundation/openexr/issues/1680
[2] https://github.com/AcademySoftwareFoundation/openexr/pull/1681
[3] 
https://github.com/AcademySoftwareFoundation/openexr/commit/7aa89e1d09b09d9f5dbb96976ee083a331ab9d71

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068938: less: CVE-2024-32487: with LESSOPEN mishandles \n in paths

[Salvatore Bonaccorso]

Source: less
Version: 590-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for less.

CVE-2024-32487[0]:
| less through 653 allows OS command execution via a newline character
| in the name of a file, because quoting is mishandled in filename.c.
| Exploitation typically requires use with attacker-controlled file
| names, such as the files extracted from an untrusted archive.
| Exploitation also requires the LESSOPEN environment variable, but
| this is set by default in many common cases.


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-32487
https://www.cve.org/CVERecord?id=CVE-2024-32487
[1] https://www.openwall.com/lists/oss-security/2024/04/12/5

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068937: python3-lxc: hard-coded dependency on liblcx1

[Sebastian Ramacher]

Package: python3-lxc
Version: 1:5.0.0-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

python3-lxc has an unneeded and hard-coded dependency on liblxc1 which
is involved in the time_t transition. Please remove it. shlibs:Depends
contains the correct dependency in this case.

Cheers
-- 
Sebastian Ramacher

Bug#1068936: libcanberra-gtk3-module: hard-coded dependency on libgtk-3-0

[Sebastian Ramacher]

Package: libcanberra-gtk3-module
Version: 0.30-12
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

This package has a hard-coded dependency on libgtk-3-0. Since libgtk-3-0
was renamed for the time_t transition, the dependency needs to be
updated or simply removed. Even oldstable has a recent enough version of
GTK 3.

Cheers
-- 
Sebastian Ramacher

Bug#1068935: debootstrap: Creating buildd chroots of trixie/sid from bookworm

[Santiago Vila]

Package: src:debootstrap
Version: 1.0.128+nmu2+deb12u1

Dear maintainer:

Please make debootstrap in bookworm to follow the same rules as debootstrap in 
trixie/sid
when creating a buildd chroot of trixie/sid (i.e. install only build-essential 
packages).

Rationale and full explanation here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060#134

Thanks.

Bug#1068934: perl: autopkgtest failure due to the t64 package rename

[Niko Tyni]

Source: perl
Version: 5.38.2-3.2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Steve Langasek 

perl is failing its own autopkgtest checks in sid because of the
libperl5.38 rename to libperl5.38t64.

  https://ci.debian.net/packages/p/perl/unstable/amd64/45047732/

autopkgtest [15:18:55]: test control: prove debian/t/control.t
autopkgtest [15:18:55]: test control: [---
control.t: warning: can't parse dependency ${t64:Provides}

#   Failed test 'Breaks for libfilter-perl in libperl5.38t64 implies 
Provides'
#   at debian/t/control.t line 267.

#   Failed test 'Breaks for libfilter-perl in libperl5.38t64 implies 
Replaces'
#   at debian/t/control.t line 269.
Use of uninitialized value $replaced_version in substitution (s///) at 
debian/t/control.t line 273.

[...]

The main issue is solved with just a

  sed -i 's/libperl5.38/&t64/' debian/t/control.t

but there's also the "can't parse dependency ${t64:Provides}" warning
coming from Dpkg::Deps which cannot handle unsubstituted substvars. We
already fix a similar ${perlapi:Provides} case, so that can be extended
to tackle this as well.

Patch attached. The test passes for me with this on amd64 at least.
-- 
Niko Tyni   nt...@debian.org
>From 81649053d3b4ecf857977c797100c024a25c04de Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 13 Apr 2024 20:51:17 +0300
Subject: [PATCH] Fix autopkgtest test after t64 changes

---
 debian/t/control.t | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/t/control.t b/debian/t/control.t
index 977338ee5..56608ea4e 100755
--- a/debian/t/control.t
+++ b/debian/t/control.t
@@ -77,7 +77,7 @@ my %known_epochs = (
 # Replaces+Provides
 my %triplet_check_skip = (
 	"perl-base" => [ "libfile-spec-perl" ],
-	"libperl5.38" => [ "libfilter-perl" ],
+	"libperl5.38t64" => [ "libfilter-perl" ],
 );
 
 # list special cases where the name of the Debian package does not
@@ -162,8 +162,8 @@ for my $perl_package_info ($control->get_packages) {
 	for my $deptype ($breaksname, "Replaces", "Provides") {
 		next if !exists $perl_package_info->{$deptype};
 
-		# Dpkg::Deps cannot parse unsubstituted substvars so remove this
-		$perl_package_info->{$deptype} =~ s/\$\{perlapi:Provides}//;
+		# Dpkg::Deps cannot parse unsubstituted substvars so remove those
+		$perl_package_info->{$deptype} =~ s/\$\{\w+:Provides}//;
 
 		my $parsed = deps_parse($perl_package_info->{$deptype});
 		next if !defined $parsed;
-- 
2.39.2

Bug#1068688: tpm2-initramfs-tool: diff for NMU version 0.2.2-2.1

[Sebastian Ramacher]

Control: tags 1068688 + patch
Control: tags 1068688 + pending


Dear maintainer,

I've prepared an NMU for tpm2-initramfs-tool (versioned as 0.2.2-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers

-- 
Sebastian Ramacher
diff -Nru tpm2-initramfs-tool-0.2.2/debian/changelog tpm2-initramfs-tool-0.2.2/debian/changelog
--- tpm2-initramfs-tool-0.2.2/debian/changelog	2020-12-28 08:26:11.0 +0100
+++ tpm2-initramfs-tool-0.2.2/debian/changelog	2024-04-13 19:49:00.0 +0200
@@ -1,3 +1,11 @@
+tpm2-initramfs-tool (0.2.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/control: Remove hard-coded dependency on libtss2-esys-3.0.0-0
+(Closes: #1068688)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 19:49:00 +0200
+
 tpm2-initramfs-tool (0.2.2-2) unstable; urgency=medium
 
   * Bump version and bump standards-version to 4.5.1.
diff -Nru tpm2-initramfs-tool-0.2.2/debian/control tpm2-initramfs-tool-0.2.2/debian/control
--- tpm2-initramfs-tool-0.2.2/debian/control	2020-12-28 08:26:11.0 +0100
+++ tpm2-initramfs-tool-0.2.2/debian/control	2024-04-13 19:48:43.0 +0200
@@ -22,7 +22,7 @@
 Architecture: linux-any
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libtss2-esys-3.0.2-0 (>= 3.0.3-1)
+ ${lib:Depends}
 Description: Tool used in initramfs to seal/unseal FDE key to the TPM
  This package provides the TPM tool used by the initramfs.
  Its purpose is to generate/seal/unseal the FDE encrypytion key into

Bug#1068217: atomes: diff for NMU version 1.1.14-1.1

[Sebastian Ramacher]

Control: tags 1068217 + patch
Control: tags 1068217 + pending

Dear maintainer,

I've prepared an NMU for atomes (versioned as 1.1.14-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru atomes-1.1.14/debian/changelog atomes-1.1.14/debian/changelog
--- atomes-1.1.14/debian/changelog	2024-03-20 15:40:00.0 +0100
+++ atomes-1.1.14/debian/changelog	2024-04-13 19:42:07.0 +0200
@@ -1,3 +1,11 @@
+atomes (1.1.14-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Removed hard-coded dependency on libgtk-3-0 (Closes:
+#1068217)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 19:42:07 +0200
+
 atomes (1.1.14-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru atomes-1.1.14/debian/control atomes-1.1.14/debian/control
--- atomes-1.1.14/debian/control	2024-03-20 15:40:00.0 +0100
+++ atomes-1.1.14/debian/control	2024-04-13 19:41:16.0 +0200
@@ -30,7 +30,6 @@
 Architecture: any
 Depends: atomes-data (= ${source:Version}),
  ${shlibs:Depends}, ${misc:Depends},
- libgtk-3-0,
  libglu1-mesa,
  bash-completion
 Description: atomic-scale 3D modeling toolbox

Bug#921954: gnulib

[Simon Josefsson]

Hi

You may have noticed I adopted gnulib and have made an upload to
experimental.  I am happy to have this team maintained, so feel free to
join the effort -- I added Boyuan to Uploaders: since you've been doing
QA uploads for some time, but happy to add others too.

If you don't object, I will upload to unstable in a couple of days if
nothing comes up.  Relevant reading material on the changes I did for
this package:

https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/README.source
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/

What do you think?  I hope I'm not stepping on anyone's toes here.  The
package was orphaned and is a critical component to be able to build
source-only tarballs for other packages in Debian.

/Simon

Simon Josefsson  writes:

> Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib
> and intend to adopt it in Debian, but I’m happy to co-maintain it. My
> plan is to keep it updated to latest upstream version, and see if we
> can offer some way for it to be used to bootstrap various projects
> that depend on vendored gnulib code.
>
> /Simon


signature.asc
Description: PGP signature

Bug#1057565: state of kalzium package, and metapackage dependencies on it.

[Peter Green]

kalzium needs to be rebuilt for the time64 transition, but it has had
a FTBFS bug with no maintainer response for 4 months. The only reverse
dependencies seem to be a number of metapackages.

In particular, the kdeedu package is a key package and has a hard
dependency on kalzium. This means that it can't be autoremoved from
testing, making it a blocker the time64 transition.

Is there someone who can step up and fix kalzium? or should
it be dropped from the metapackages so it can be removed from testing?

Metapackages built from the meta-kde source (key, hard dependencies)

* kdeedu

Metapackages built from the debian-edu source (key, but only reccomends):

* education-chemistry
* education-highschool
* education-primaryschool
* education-secondaryschool

Metapackages built from the debian-science source (not key, only reccomends):

* science-chemistry

Metapackages built from the debichem source (not key, only reccomends):

* debichem-visualisation

Bug#1068914: flactag: Disks cannot be tagged, information is retrieved but not displayed

[sok]

Dear Andy,

thank you very much (and once again) for flactag and also for your swift 
response. Sorry for not checking the GitHub repository right away. It 
would still be an exaggeration if I said that I very seldomly report 
bugs and so I assumed that any error fixed elsewhere would make it 
upstream into Debian relatively soon, especially when it affects the 
overall functionality of the package so much.


About your workaround that is exactly the same way I use with much 
simplier BASH and Python scripts when running into user agent issues 
myself. Getting your user agent registered would at best only be a waste 
of time.


I just put my even more seldomly used knowledge on building Debian 
packages to the test, reactivated the deb-src-entries, downloaded the 
Debian flactag source, "integrated" the patch you mentioned into the 
downloaded source code and have a working installation once more. 
Hopefully the patch will be integrated soon and become an additional 
reason to look forward on trixie.


Again: thank you very much for flactag. I really appreciate it a lot!


Best,
sok

Bug#1066551: ramond: FTBFS: src/main.c:164:17: error: implicit declaration of function ‘LOG’ [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: ramond
Followup-For: Bug #1066551
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ramond-0.5/debian/patches/0001-Daemonize-ramond-by-default.patch 
ramond-0.5/debian/patches/0001-Daemonize-ramond-by-default.patch
--- ramond-0.5/debian/patches/0001-Daemonize-ramond-by-default.patch
2020-09-09 13:09:14.0 -0700
+++ ramond-0.5/debian/patches/0001-Daemonize-ramond-by-default.patch
2024-04-13 09:50:06.0 -0700
@@ -8,10 +8,10 @@
  src/main.h |1 +
  2 files changed, 80 insertions(+), 2 deletions(-)
 
-diff --git a/src/main.c b/src/main.c
-index 0cb6e8a..3c4543d 100644
 a/src/main.c
-+++ b/src/main.c
+Index: ramond-0.5/src/main.c
+===
+--- ramond-0.5.orig/src/main.c
 ramond-0.5/src/main.c
 @@ -1,6 +1,5 @@
  #include "main.h"
  #include "log.h"
@@ -19,7 +19,7 @@
  apr_pool_t *masterPool;
  struct configuration *config;
  
-@@ -14,8 +13,9 @@ void listRules(void);
+@@ -14,8 +13,9 @@
  
  void usage(char *prog_name)
  {
@@ -30,7 +30,7 @@
fprintf(stderr, "   -c : path to config file.\n");
  }
  
-@@ -824,11 +824,74 @@ void rafixd_clearRoute(struct ra_info *data)
+@@ -824,11 +824,74 @@
pcap_close(fd);
  }
  
@@ -81,7 +81,7 @@
 +  pidfile = open("/var/run/ramond.pid", O_RDWR|O_CREAT, 0640);
 +  if(pidfile < 0)
 +  exit(EXIT_FAILURE);
-+  if(flock(pidfile, F_TLOCK, 0) < 0)
++  if(lockf(pidfile, F_TLOCK, 0) < 0)
 +  exit(EXIT_SUCCESS);
 +
 +  sprintf(pidstr, "%d\n", getpid());
@@ -105,7 +105,7 @@
if(argc > 6)
{
usage(argv[0]);
-@@ -842,6 +905,20 @@ int main(int argc, char *argv[])
+@@ -842,6 +905,20 @@
  
signal(SIGCHLD, sigchld_handler);
  
@@ -126,10 +126,10 @@
/* Find the config file */
if(!parseConfigFile(argc,argv))
{
-diff --git a/src/main.h b/src/main.h
-index 26de811..6552d5b 100644
 a/src/main.h
-+++ b/src/main.h
+Index: ramond-0.5/src/main.h
+===
+--- ramond-0.5.orig/src/main.h
 ramond-0.5/src/main.h
 @@ -1,5 +1,6 @@
  #include 
  #include 
diff -Nru ramond-0.5/debian/patches/no-implicit-declarations.patch 
ramond-0.5/debian/patches/no-implicit-declarations.patch
--- ramond-0.5/debian/patches/no-implicit-declarations.patch1969-12-31 
16:00:00.0 -0800
+++ ramond-0.5/debian/patches/no-implicit-declarations.patch2024-04-13 
09:50:06.0 -0700
@@ -0,0 +1,29 @@
+Description: fix missing function declarations.
+Author: Steve Langasek 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2061024
+Bug-Debian: https://bugs.debian.org/1066551
+Last-Update: 2024-04-13
+Forwarded: no
+
+Index: ramond-0.5/src/log.h
+===
+--- ramond-0.5.orig/src/log.h
 ramond-0.5/src/log.h
+@@ -25,4 +25,6 @@
+ 
+ FILE *log_file;
+ 
++void LOG(const char *fmt, ...);
++
+ #endif
+Index: ramond-0.5/src/main.c
+===
+--- ramond-0.5.orig/src/main.c
 ramond-0.5/src/main.c
+@@ -1,3 +1,6 @@
++#include 
++#include 
++
+ #include "main.h"
+ #include "log.h"
+ apr_pool_t *masterPool;
diff -Nru ramond-0.5/debian/patches/series ramond-0.5/debian/patches/series
--- ramond-0.5/debian/patches/series2022-04-20 16:48:49.0 -0700
+++ ramond-0.5/debian/patches/series2024-04-13 09:48:15.0 -0700
@@ -4,3 +4,4 @@
 0004-Honor-CFLAGS-CPPFLAGS-and-LDFLAGS.patch
 compiler.patch
 libxml2.patch
+no-implicit-declarations.patch

Bug#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ

[Timo Röhling]

* Cody Scott  [2024-04-12 09:35]:

* Package name: python3-pyzmq
 Version : 25.1.2
[...]
There doesn't appear to be any other Python bindings for ZeroMQ.

It seems like you missed
https://tracker.debian.org/pkg/pyzmq
but you are very welcome to contribute to the existing package! :)


Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1068823: (No Subject)

[mYnDstrEAm]

Thanks guys, these are very useful methods and I'll mention these as 
alternatives to disk cleanups recommended at 
https://unix.stackexchange.com/q/774199/233262 (this would probably very useful 
to have at places about upgrades failing due to disk space issues even though 
people only look these up once the problems already occurred).

However, the problem of the upgrade requiring more disk space than displayed at 
first remains and the command by Zeimetz can't be used with a built-in 
rememberable well-known command like sudo apt-get upgrade --stepwise

I don't think peripheral devices would be the common case for personal 
computers, rather one would simply specify a directory on a partition that is 
larger than the root partition.

Upgrading individual packages is not what this is about in case that wasn't 
clear. It's one upgrade but it's separated into several steps where one batch 
of packages are download and installed, the cache deleted, and then the next 
batch.
If the upgrade breaks in between due to disk space, because the user aborted 
it, a crash, or an error, then only some packages are upgraded...a stepwise 
upgrade could if anything be a way to *avoid* that (or at least interruptions 
due to disk space problems) and to make them less problematic.
The key thing is that it would be usable with a simple command (such as by 
adding --stepwise)...if that command only executes a few already existing 
commands with no apt changes required for the basic functionality of this, 
that's all the better.

Bug#1068774: (No Subject)

[mYnDstrEAm]

> And I tried to explain to you that many others believe in the exact opposite

Sure, I'm aware of that. Once again, this is about kept-back packages. When 
kept-back packages in specific are installed through apt-get install, then that 
is usually not because the user wanted to mark them as manually installed, 
something many don't even know exists at all or for years, but because they 
want to solve the problem shown when upgrading their packages. Those who 
actually want to mark it as manually installed *for kept-back packages* could 
still do so.
I'm not complaining, just pointing out an issue and that issue may not be clear 
to those who used Debian and apt-get for years/decades and for example assume 
that the users know everything they know or should be required to (and that 
right from the time of their first upgrade problems).
Another option would be to display a prompt like "The following packages have 
been kept back ... If you want to install them as if they were dependencies, 
run sudo apt-get install --fix-held-back ..." so that the user just runs that 
instead of the normal install command but I don't think it would be as good as 
the thing proposed here for example because such a command doesn't exist.

I think any issues you bring up that could, probably rarely, exist if the 
package is not marked as manually installed could be solved and they also exist 
for solutions like the top recommendation (--with-new-pkgs) in the top answers 
here 
https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it

> Your sysv-rc-conf is kinda an example: A normal upgrade doesn't do it because 
> it is deemed not a good idea to prefer this over 20 other
packages

I guess I just remove it. But why does require so many packages to be removed, 
seems like it would need to be upgraded properly so it doesn't require that?

> That is an explicit manual install request for some-pkg.

Fair point, but then please change it so that the process of resolving 
kept-back is different. That could be a prompt the user needs to confirm, a 
prompt displaying another command the user could run (or several options), or 
something else. Basically this issue is broadly about how kept-back packages 
are installed with the only best feasible solution I came up with being that 
the install command simply doesn't mark them manually installed by default 
(except if for example a parameter is used). Yes, having a choice there would 
be good but if you're referring to the other issue with that, this one is only 
about kept-back package installation (that is ways that treat these different 
from any other package installations such as running certain code if it 
detected it to be a kept-back package).

Bug#1068016: bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2

[Jérémy Lal]

Package: release.debian.org
Followup-For: Bug #1068016

node-babel7 needs node-undici 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4
(see release.d.o. #1068912).

Also, even with that, the current debdiff *will FTBFS*, see #1068933.

Please find attached another debdiff that addresses that issue.

Jérémy
(sorry for the very late reaction)
diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 
node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 2023-10-13 
16:02:05.0 +0200
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 2024-03-29 
17:29:05.0 +0100
@@ -1,3 +1,18 @@
+node-babel7 (7.20.15+ds1+~cs214.269.168-3+deb12u2) bookworm; urgency=medium
+
+  * Team upload
+  * Improve tsc-workaround patch, fixing compilation against
+nodejs 18.19.0+dfsg-6~deb12u1. Closes: #1068933.
+
+  [ Andreas Beckmann ]
+  * Backport Breaks+Replaces fixes from 7.20.15+ds1+~cs214.269.168-4.
+
+  [ Yadd ]
+  * Add missing Breaks+Replaces against all node-babel-* that were in Debian 10
+(Closes: #1037234)
+
+ -- Andreas Beckmann   Fri, 29 Mar 2024 17:29:05 +0100
+
 node-babel7 (7.20.15+ds1+~cs214.269.168-3+deb12u1) bookworm-security; 
urgency=medium
 
   * Team upload
diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/control 
node-babel7-7.20.15+ds1+~cs214.269.168/debian/control
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/control   2023-10-13 
16:02:05.0 +0200
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/control   2024-03-29 
17:29:05.0 +0100
@@ -120,8 +120,92 @@
 Suggests: node-babel-plugin-polyfill-es-shims
  , node-babel7-debug
 Breaks: node-babel-core (<< 6.26.0+repack-3~)
+ , node-babel-cli (<< 7)
  , node-babel-code-frame (<< 7)
-Replaces: node-babel-code-frame (<< 7)
+ , node-babel-generator (<< 7)
+ , node-babel-helper-bindify-decorators (<< 7)
+ , node-babel-helper-builder-binary-assignment-operator-visitor (<< 7)
+ , node-babel-helper-builder-react-jsx (<< 7)
+ , node-babel-helper-call-delegate (<< 7)
+ , node-babel-helper-explode-assignable-expression (<< 7)
+ , node-babel-helper-explode-class (<< 7)
+ , node-babel-helper-function-name (<< 7)
+ , node-babel-helper-hoist-variables (<< 7)
+ , node-babel-helper-optimise-call-expression (<< 7)
+ , node-babel-helper-remap-async-to-generator (<< 7)
+ , node-babel-helper-replace-supers (<< 7)
+ , node-babel-helpers (<< 7)
+ , node-babel-plugin-external-helpers (<< 7)
+ , node-babel-plugin-syntax-async-generators (<< 7)
+ , node-babel-plugin-syntax-class-properties (<< 7)
+ , node-babel-plugin-syntax-decorators (<< 7)
+ , node-babel-plugin-syntax-do-expressions (<< 7)
+ , node-babel-plugin-syntax-dynamic-import (<< 7)
+ , node-babel-plugin-syntax-flow (<< 7)
+ , node-babel-plugin-syntax-function-bind (<< 7)
+ , node-babel-plugin-syntax-jsx (<< 7)
+ , node-babel-plugin-syntax-object-rest-spread (<< 7)
+ , node-babel-plugin-transform-async-to-generator (<< 7)
+ , node-babel-plugin-transform-exponentiation-operator (<< 7)
+ , node-babel-plugin-transform-flow-strip-types (<< 7)
+ , node-babel-plugin-transform-jscript (<< 7)
+ , node-babel-plugin-transform-proto-to-assign (<< 7)
+ , node-babel-plugin-transform-react-display-name (<< 7)
+ , node-babel-plugin-transform-react-jsx (<< 7)
+ , node-babel-plugin-transform-react-jsx-self (<< 7)
+ , node-babel-plugin-transform-react-jsx-source (<< 7)
+ , node-babel-plugin-transform-regenerator (<< 7)
+ , node-babel-plugin-transform-runtime (<< 7)
+ , node-babel-plugin-transform-strict-mode (<< 7)
+ , node-babel-preset-env (<< 7)
+ , node-babel-preset-flow (<< 7)
+ , node-babel-preset-react (<< 7)
+ , node-babel-register (<< 7)
+ , node-babel-template (<< 7)
+ , node-babel-traverse (<< 7)
+Replaces: node-babel-cli (<< 7)
+ , node-babel-code-frame (<< 7)
+ , node-babel-generator (<< 7)
+ , node-babel-helper-bindify-decorators (<< 7)
+ , node-babel-helper-builder-binary-assignment-operator-visitor (<< 7)
+ , node-babel-helper-builder-react-jsx (<< 7)
+ , node-babel-helper-call-delegate (<< 7)
+ , node-babel-helper-explode-assignable-expression (<< 7)
+ , node-babel-helper-explode-class (<< 7)
+ , node-babel-helper-function-name (<< 7)
+ , node-babel-helper-hoist-variables (<< 7)
+ , node-babel-helper-optimise-call-expression (<< 7)
+ , node-babel-helper-remap-async-to-generator (<< 7)
+ , node-babel-helper-replace-supers (<< 7)
+ , node-babel-helpers (<< 7)
+ , node-babel-plugin-external-helpers (<< 7)
+ , node-babel-plugin-syntax-async-generators (<< 7)
+ , node-babel-plugin-syntax-class-properties (<< 7)
+ , node-babel-plugin-syntax-decorators (<< 7)
+ , node-babel-plugin-syntax-do-expressions (<< 7)
+ , node-babel-plugin-syntax-dynamic-import (<< 7)
+ , node-babel-plugin-syntax-flow (<< 7)
+ , node-babel-plugin-syntax-function-bind (<< 7)
+ , node-babel-plugin-syntax-jsx (<< 7)
+ , node-babel-plugin-syntax-object-rest-spread (<< 7)
+ , node-babel-plugin-transform-async-to-generator (<< 7)
+ , node-b

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

[Guilhem Moulin]

On Sat, 13 Apr 2024 at 10:06:32 -0400, Wesley Schwengle wrote:
> I had the same issue a while back, because of the t64 transitioning I chaulked
> it up to that. I fixed it as described in Ubuntu bug:
>
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594

libcryptsetup12 doesn't use libargon2 anymore, so that shouldn't be
needed.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1065538: bind9-libs hard-codes a dependency on libuv1

[Andreas Metzler]

On 2024-03-06 Ondřej Surý  wrote:
>> On 6. 3. 2024, at 12:45, Matthias Klose  wrote:
 
>> Package: bind9-libs
>> Version: 1:9.19.21-1
>> Severity: serious
>> Tags: sid trixie

>> bind9-libs hard-codes a dependency on libuv1, that should be
>> libuv1t64 now. But better derive it form the libuv1-dev dependency.

> The reason why we do so is that libuv has some changes between version
> that don’t propagate to ABI. I might be able to drop this in unstable
> though and just keep it for backports.

Hello,

does the reported issue actually exist?

I just cannot find the hardcoded dependency in the source package.

ametzler@argenau:/dev/shm//bind9-9.19.21$ dpkg-parsechangelog -SVersion
1:9.19.21-1
ametzler@argenau:/dev/shm//bind9-9.19.21$ grep -r libuv1 debian/
debian/changelog:  * Add libuv1-dev, libcmocka-dev, libedit-dev and zlib1g-dev 
to B-D
debian/control:   libuv1-dev,
(sid)ametzler@argenau:/dev/shm//bind9-9.19.21$ apt-cache show bind9-libs | 
grep -E '^Version|^Dep'
Version: 1:9.19.21-1+b1
Depends: libc6 (>= 2.34), libfstrm0 (>= 0.2.0), libgssapi-krb5-2 (>= 1.17), 
libjemalloc2 (>= 4.0.0), libjson-c5 (>= 0.15), libkrb5-3 (>= 1.6.dfsg.2), 
liblmdb0 (>= 0.9.7), libmaxminddb0 (>= 1.3.0), libnghttp2-14 (>= 1.12.0), 
libprotobuf-c1 (>= 1.0.1), libssl3t64 (>= 3.0.0), liburcu8t64 (>= 0.13.0), 
libuv1t64 (>= 1.38.0), libxml2 (>= 2.7.4), zlib1g (>= 1:1.1.4)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1068933: node-babel7: FTBFS in bookworm against nodejs 18.19.0+dfsg-6~deb12u1

[Jérémy Lal]

Package: node-babel7
Version: 7.20.15+ds1+~cs214.269.168-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source

This package FTBFS When rebuilding it in bookworm, against
nodejs 18.19.0+dfsg-6~deb12u1
node-undici 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4
(not yet uploaded)

The way to fix it is by improving upon the existing patch tsc-workaround.

Error log:

tsc -b .
packages/babel-helper-transform-fixture-test-runner/src/index.ts(131,7): error 
TS2345: Argument of type '{ filename: string; displayErrors: boolean; 
lineOffset: number; cachedData: Buffer; }' is not assignable to parameter of 
type 'string | ScriptOptions'.
  Object literal may only specify known properties, and 'displayErrors' does 
not exist in type 'ScriptOptions'.
packages/babel-helper-transform-fixture-test-runner/src/index.ts(139,7): error 
TS2345: Argument of type '{ filename: string; displayErrors: boolean; 
lineOffset: number; cachedData: Buffer; produceCachedData: true; }' is not 
assignable to parameter of type 'string | ScriptOptions'.
  Object literal may only specify known properties, and 'displayErrors' does 
not exist in type 'ScriptOptions'.
make[1]: *** [debian/rules:68: override_dh_auto_build] Error 1



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

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

Versions of packages node-babel7 depends on:
ii  node-ampproject-remapping   2.2.0+~cs5.15.37-1
ii  node-babel-plugin-add-module-exports1.0.4+dfsg1~cs5.8.0-4
ii  node-babel-plugin-polyfill-corejs2  0.3.3~0~20220913+ds1-1
ii  node-babel-plugin-polyfill-corejs3  0.6.0~0~20220913+ds1-1
ii  node-babel-plugin-polyfill-regenerator  0.4.1~0~20220913+ds1-1
ii  node-babel7-runtime 7.20.15+ds1+~cs214.269.168-6
ii  node-browserslist   4.22.1+~cs6.1.28-1
ii  node-chalk  5.3.0-1
ii  node-clone-deep 4.0.1+~cs7.0.2-1
ii  node-commander  9.4.1-1
ii  node-convert-source-map 1.9.0+~1.5.2-1
ii  node-core-js3.33.2-1
ii  node-core-js-compat 3.33.2-1
ii  node-core-js-pure   3.33.2-1
ii  node-debug  4.3.4+~cs4.1.7-1
ii  node-esutils2.0.3+~2.0.0-1
ii  node-find-cache-dir 3.3.2+~3.2.1-1
ii  node-fs-readdir-recursive   1.1.0+~1.1.0-1
ii  node-glob   8.1.0+~cs8.5.15-1
ii  node-globals13.23.0-1
ii  node-js-tokens  8.0.0-2
ii  node-jsesc  3.0.2+~3.0.1-1
ii  node-json5  2.2.3+dfsg-1
ii  node-lodash 4.17.21+dfsg+~cs8.31.198.20210220-9
ii  node-lodash-packages4.17.21+dfsg+~cs8.31.198.20210220-9
ii  node-make-dir   3.1.0-3
ii  node-quick-lru  6.1.1-4
ii  node-regenerator-transform  0.15.2+~0.10.8-1
ii  node-regexpu-core   5.2.2-3
ii  node-resolve1.22.8+~cs5.34.15-2
ii  node-semver 7.5.4+~7.5.0-2
ii  node-slash  4.0.0-3
ii  node-source-map 0.7.0++dfsg2+really.0.6.1-15
ii  node-source-map-support 0.5.21+ds+~0.5.4-1
ii  node-to-fast-properties 3.0.1-3
ii  node-v8flags3.2.0+~3.1.1-1
ii  nodejs  18.19.1+dfsg-3

node-babel7 recommends no packages.

Versions of packages node-babel7 suggests:
pn  node-babel-plugin-polyfill-es-shims  
pn  node-babel7-debug

-- no debconf information

Bug#1068774: (No Subject)

[David Kalnischkies]

On Sat, Apr 13, 2024 at 11:52:32AM +, mYnDstrEAm wrote:
> > So, which is it: You install random things you don't care about because 
> > their name appeared in the kept-back list or you explicitly install that 
> > package from the kept-back list because you care very deeply about it?
> 
> I and many others (this issue is not about me) install them like that because 
> their name appeared in the kept-back list. So it's the former and I never 
> said it wouldn't be that.

And I tried to explain to you that many others believe in the exact
opposite: That the package they asked to be installed is of course
important enough for them that it should be marked manual.

Just because you can find people who complain about the current
behaviour doesn't mean there aren't people who like it – they just
have no reason to complain.

If everyone would always listen to complains we would have blasted the
sun from orbit ages ago. All the glaring, sunburn and oh god, its so hot
some times… and I heard the sun is the main cause of global warming… 😉


> > that isn't how apt sees it. You might remember that in a previous request 
> > you made apt might have said that about a package, but apt has no such 
> > memory
> 
> Well then part of this would be to make it run a check if any of the packages 
> to be installed is currently kept-back. I never said it would have to keep 
> prior apt commands in mind, it just knows (can check) which packages are 
> kept-back. In the usual scenario the notice about a kept-package displays 
> during an apt-get upgrade/update command.

'update' doesn't display something about kept back because that makes no
sense. kept-back is a property of the specific request you just made:
Just like all the other packages listed as new, remove or upgrade.

A package might be phased (repository) or put on hold (user) and for
that reason appear in kept-back (or not, as said, phased is display
nowadays in another list), but that is still related to the request
as if you explicitly request that package name they are not considered
kept-back and while the kept-back-reason package-was-put-on-old-by-user
is checkable (and apt checks that and even prints a warning about that:
Changing held packages) most reasons for kept-back are not as if you
explicitly install a package the question if other packages can or
should fiddle with its state never arises. "Worse" it might lead to
other packages being kept-back like the other side of a transition that
was previously winning the tug of war.


Your sysv-rc-conf is kinda an example: A normal upgrade doesn't do it
because it is deemed not a good idea to prefer this over 20 other
packages. Removing the package serves no real purpose either through,
at least not if the user isn't asking for it – after all, who likes
packages being removed needlessly.

If you explicitly request the installation that is no longer the case:
Everything is okay for the benefit of respecting the user request, so 1,
20, or 2000 pkg to remove are not a problem even if it includes
systemd-sysv, the default init process and the only one many packages
are nowadays prepared to work with. Any package who looses the ability
working with anything else but systemd-sysv would in that scenario be
kept-back even through it happily upgrades if you don't ask for
sysv-rc-conf explicitly.


> > based on your explicit manual install request
> 
> This issue is not about installs that are explicitly manual and it shouldn't 
> be merged with other issues that are about something else.

You enter "apt install some-pkg". That is an explicit manual install
request for some-pkg. Just because you wish it to be something else
doesn't make it true.

The observable difference is if some-pkg was previously not installed
(in which case it is installed and tagged manual installed) or if
some-pkg is currently installed. For the later, two cases exist:
Either the candidate version is installed or it is not which both
want to ensure the same outcome: The candidate version is installed.

The only question that arises is: Should that ALSO, like the first
scenario set the package to manually installed given its installation
was manually requested.

The answer so far is yes – and you insist on it being changed to no,
while I keep telling you that there are usecases/scenarios for both,
so an acceptable compromise might be to implement both and offer
a choice…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1068932: bookworm-pu: package node-v8-compile-cache/2.3.0-3+deb12u1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: node-v8-compile-ca...@packages.debian.org, Debian Javascript 
Maintainers 
Control: affects -1 + src:node-v8-compile-cache
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
FTBFS because of test failures, see #1068921
These are regressions caused by nodejs 18.19.0+dfsg-6~deb12u1

[ Impact ]
Only FTBFS

[ Tests ]
The tests are fixed, not skipped, so they will pass with
nodejs 18.19.0+dfsg-6~deb12u1 and node-undici 
5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4

[ Risks ]
Close to none

[ 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 ]
One patch that fixes the tests, consists of two commits cherr-picked,
and a small rewrite to allow the test to pass with nodejs 18.13 and 18.19.
diff -Nru node-v8-compile-cache-2.3.0/debian/changelog 
node-v8-compile-cache-2.3.0/debian/changelog
--- node-v8-compile-cache-2.3.0/debian/changelog2022-11-22 
13:06:02.0 +0100
+++ node-v8-compile-cache-2.3.0/debian/changelog2024-04-13 
17:52:45.0 +0200
@@ -1,3 +1,11 @@
+node-v8-compile-cache (2.3.0-3+deb12u1) UNRELEASED; urgency=medium
+
+  * Upload to bookworm-p-u
+  * patch: NativeCompileCache-test for Node 18.13 and 18.19
+and fix test mock. Closes: #1068921
+
+ -- Jérémy Lal   Sat, 13 Apr 2024 17:52:45 +0200
+
 node-v8-compile-cache (2.3.0-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru node-v8-compile-cache-2.3.0/debian/gbp.conf 
node-v8-compile-cache-2.3.0/debian/gbp.conf
--- node-v8-compile-cache-2.3.0/debian/gbp.conf 2022-11-22 13:06:02.0 
+0100
+++ node-v8-compile-cache-2.3.0/debian/gbp.conf 2024-04-13 15:00:41.0 
+0200
@@ -1,4 +1,5 @@
 [DEFAULT]
+debian-branch = debian/bookworm
 pristine-tar = True
 
 [import-orig]
diff -Nru 
node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch 
node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch
--- node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch  
1970-01-01 01:00:00.0 +0100
+++ node-v8-compile-cache-2.3.0/debian/patches/native-compile-cache-test.patch  
2024-04-13 17:51:42.0 +0200
@@ -0,0 +1,42 @@
+Description: fix this test to pass on nodejs 18.13 and 18.19
+Author: Jérémy Lal 
+Last-Update: 2024-04-13
+Forwarded: https://github.com/zertosh/v8-compile-cache/pull/49
+Origin: 
https://github.com/zertosh/v8-compile-cache/commit/de822a607c9dbe7cfc826a44c67fc5f82b03c9ca
+--- a/test/NativeCompileCache-test.js
 b/test/NativeCompileCache-test.js
+@@ -85,12 +85,14 @@
+ tap.test('deletes previously cached code when the cache is an invalid file', 
t => {
+   fakeCacheStore.has = () => true;
+   fakeCacheStore.get = () => Buffer.from('an invalid cache');
+-  let deleteWasCalledWith = null;
+-  fakeCacheStore.delete = arg => { deleteWasCalledWith = arg; };
++  let wasCalledWith = null;
++  fakeCacheStore.set = arg => { wasCalledWith = arg; };
++  // older v8 still calls delete, though
++  fakeCacheStore.delete = arg => { wasCalledWith = arg; };
+ 
+   const fn3 = require('./fixtures/file-3');
+ 
+-  t.equal(deleteWasCalledWith, require.resolve('./fixtures/file-3'));
++  t.equal(wasCalledWith, require.resolve('./fixtures/file-3'));
+   t.equal(fn3(), 3);
+ 
+   t.end();
+--- a/test/FileSystemBlobStore-mock.js
 b/test/FileSystemBlobStore-mock.js
+@@ -20,7 +20,14 @@
+   }
+ 
+   set(key, invalidationKey, buffer) {
++const entry = this._cachedFiles.find(
++  file => file.key === key && file.invalidationKey === invalidationKey
++);
++if (entry == null) {
+ this._cachedFiles.push({key, invalidationKey, buffer});
++} else {
++  entry.buffer = buffer;
++}
+ return buffer;
+   }
+ 
diff -Nru node-v8-compile-cache-2.3.0/debian/patches/series 
node-v8-compile-cache-2.3.0/debian/patches/series
--- node-v8-compile-cache-2.3.0/debian/patches/series   2022-11-22 
13:06:02.0 +0100
+++ node-v8-compile-cache-2.3.0/debian/patches/series   2024-04-13 
15:00:41.0 +0200
@@ -1 +1,2 @@
 latest-tap.patch
+native-compile-cache-test.patch

Bug#1068931: libdom4j-java version numbering

[tsteven4]

Package: libdom4j-java

Version: 2.1.4-1

The package uses the source for 2.1.4, but the project/version element 
has value 2.1.1 in debian/pom.xml.

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Martin Steigerwald - 13.04.24, 15:05:41 CEST:
> No PATH defined.
> 
> The script defines it. See line 8 in my changed script. However it does
> not export it. Thus adding line 9 fixes the bug I reported:
> 
>   8 PATH=/sbin:/usr/sbin:/bin:/usr/bin
>   9 export PATH
> 
> The network is configured just fine after adding that line.

Since configuring networking works on physical machines – I know for sure 
with Devuan 5 aka Daedalus and Devuan Ceres which was at a similar state 
Devuan Excalibur is currently – regarding the right fix the question 
remains:

What is different with the PATH in both cases and why?

Why is it empty inside the (unprivileged) Incus managed LXC container? Is 
it empty on the physical machine? I doubt it. But where does the difference 
come from? And anyway the PATH is being set in both stage 1 and stage 2 
scripts, just not exported. So on a physical machine it appears that PATH 
is being exported before already. It might be exported before already on a 
container as well, albeit undefined / empty.

In both cases /bin/sh points to /bin/dash. Both the VM with Excalibur and 
the physical host with Daedalus are usrmerge'd.

-- 
Martin

Bug#1068930: Please update for event-listener 5.x

[Matthias Geiger]

Source: rust-async-channel
Version: 1.9.0-2
Severity: normal
Tags: patch
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas, please update async-channel for event-listener 5.x, too.
Attached patch builds and tests fine for me.

best,

werdahias



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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmYapQkVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1hyMQAKRtSRifqo1DoIqgGTRCTiQnxy7V
sVhDVHQuKdjB+Sjhk4mPmSzDQshjwOYaQkImetq0eHvuwlMXZAvSdGwhDyfi6Jge
pVgJk5b3/WaxAT5IIfux/0mVhtJ2UVgoKhGGAQxmmNBVzxj/cP7zAqqdzwekCjyB
EUQQojcRMh3PAO4InY/otP6xp8yLwqBbsPYTPHJ3exFIO4DwBvxK3EjzRUJJYtll
Jie5xJrsvnG0z7tNkLdw9m166MxQcAovzp34giL5JWqUwam4U5jATWyT3XAksv1U
HMgoyLGOvt2fqnr3NShp3qCfOlKNfPqbUjAJjaIVHxsosjA8rfj7erjwWQUvqfJv
z46sEO8X/ElnqgUocI4gRgcmtNFVKOrK8iAUMheB6H06CG1A3snxo/OBEvw1vcKo
D1DUYqtBBWG7c7AP11BHrajCUGwqEOqO/BgSja5OJOqnjbim0LlOD/Es5UBcSPhG
5i5l/IuSqvUZaNiNPwzd1Z5V8AmeluvHVLkOd6QHV4eMjZwyCDSk7CqzS8cny/Rx
OyNmfql4COldIV1hXokkUuJmLn2ZVgW+QbEb8bQCOYZgKFw4fZ505Vn1L8zqnwHt
uMV+TTAYI9UiYMfRe8g/EZfFm15t1SIPZSS811I4YtVLjyg3EzBrx5OMOEM4s5M9
lWOXmV+DY9wm7AHP
=Rj36
-END PGP SIGNATURE-
diff -Nru rust-async-channel-1.9.0/debian/changelog 
rust-async-channel-1.9.0/debian/changelog
--- rust-async-channel-1.9.0/debian/changelog   2023-08-14 12:40:20.0 
+0200
+++ rust-async-channel-1.9.0/debian/changelog   2024-04-13 15:58:06.0 
+0200
@@ -1,3 +1,10 @@
+rust-async-channel (1.9.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch for event-listener 5.x
+
+ -- Matthias Geiger   Sat, 13 Apr 2024 15:58:06 +0200
+
 rust-async-channel (1.9.0-2) unstable; urgency=medium
 
   * update dh-cargo fork;
diff -Nru rust-async-channel-1.9.0/debian/control 
rust-async-channel-1.9.0/debian/control
--- rust-async-channel-1.9.0/debian/control 2023-07-16 11:32:14.0 
+0200
+++ rust-async-channel-1.9.0/debian/control 2024-04-13 15:58:06.0 
+0200
@@ -6,7 +6,7 @@
  dh-cargo (>= 25),
  librust-concurrent-queue-2+default-dev ,
  librust-easy-parallel-3+default-dev ,
- librust-event-listener-2+default-dev ,
+ librust-event-listener-5+default-dev ,
  librust-futures-core-0.3+default-dev ,
  librust-futures-lite-1+default-dev ,
  libstring-shellquote-perl,
@@ -22,7 +22,7 @@
 Multi-Arch: foreign
 Depends:
  librust-concurrent-queue-2+default-dev,
- librust-event-listener-2+default-dev,
+ librust-event-listener-5+default-dev,
  librust-futures-core-0.3+default-dev,
  ${misc:Depends},
 Provides:
diff -Nru rust-async-channel-1.9.0/debian/patches/relax-event-listener.diff 
rust-async-channel-1.9.0/debian/patches/relax-event-listener.diff
--- rust-async-channel-1.9.0/debian/patches/relax-event-listener.diff   
1970-01-01 01:00:00.0 +0100
+++ rust-async-channel-1.9.0/debian/patches/relax-event-listener.diff   
2024-04-13 15:58:06.0 +0200
@@ -0,0 +1,23 @@
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -16,7 +16,7 @@
+ 
+ [dependencies]
+ concurrent-queue = "2"
+-event-listener = "2.4.0"
++event-listener = "5"
+ futures-core = "0.3.5"
+ 
+ [dev-dependencies]
+--- a/src/lib.rs
 b/src/lib.rs
+@@ -40,7 +40,7 @@
+ use std::usize;
+ 
+ use concurrent_queue::{ConcurrentQueue, PopError, PushError};
+-use event_listener::{Event, EventListener};
++use event_listener::{Event, EventListener, Listener};
+ use futures_core::stream::Stream;
+ 
+ struct Channel {
+
diff -Nru rust-async-channel-1.9.0/debian/patches/series 
rust-async-channel-1.9.0/debian/patches/series
--- rust-async-channel-1.9.0/debian/patches/series  1970-01-01 
01:00:00.0 +0100
+++ rust-async-channel-1.9.0/debian/patches/series  2024-04-13 
15:57:59.0 +0200
@@ -0,0 +1 @@
+relax-event-listener.diff

Bug#1068929: Please update for event-listener 5.x

[Matthias Geiger]

Source: rust-async-lock
Version: 2.8.0-1
Severity: normal
Tags: patch
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas,

please find following patch attached for updating async-lock to
event-listener 5.x, too.

best, werdahias



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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmYao7YVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1brYQAKMm7aXiHgQGhO4cyw2DdnUDA5ct
AyljSJILT4jvdFBmo7YVzHdrekynMt/a+U5CL+5TITiFAqds47HWdLjBo8Vwbjg+
eOXMZmjGgX+G/JgEXbxLgj0U6ggcXjZkJ1+HwfuI9E3+P0UMnTNnSUpa4DikOp7R
CTvpd225vA0ED6I6h7Ws1bTrok0xsb7sk3FCFHfuBUYlwPTvR5dpZ+ep6B1MPWN+
7O+rWJ6E0Fl7EB6ykD2NfUyfZeEVAW8ux/9Ytlg2RitLSShqEBTJyLD7CReN8EaY
R+e0LuXnxId7cI+cWC3anKYBiki1PUcqrmuFflw3/cUMFymrNJvLZwYDV1isYt9m
iZhzXQkd2AKe1riTWiD5iLBosoPsfCK4uhoIyonw0KCx/A0ZQLx4X4S6XUnFmDRO
IDiVsc0v6DkrQackSExrZ51TrlMhXvT8GBzupgsQugDJ7vN8VG3p50GEF4WzjwnZ
ZkayRVM9hg/QiAsmLm9Mx7BqQgR/PVROQkW9VZ394ebUtPyBG2eCOfGVY6Wv9YO5
359IL2W/XMCwpXIWnJHjM94kAdnb3795om2noeSGrQlJSv8Wxf6jA8UKSLPUd8OG
hzq3O1kfy3MzCm91KxdfWtF7uXBowIvc18Mp0DW25ppohTyGJRGohUO3LJwa6dX6
f2HoxONBpPBb41Am
=9Xgk
-END PGP SIGNATURE-
--- rust-async-lock-2.8.0/debian/changelog  2023-08-24 10:46:30.0 
+0200
+++ rust-async-lock-2.8.0/debian/changelog  2024-04-13 17:07:17.0 
+0200
@@ -1,3 +1,10 @@
+rust-async-lock (2.8.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch for eventlistener 5.x
+
+ -- Matthias Geiger   Sat, 13 Apr 2024 17:07:17 +0200
+
 rust-async-lock (2.8.0-1) unstable; urgency=medium
 
   * add patch 2001_fastrand
diff -Nru rust-async-lock-2.8.0/debian/control 
rust-async-lock-2.8.0/debian/control
--- rust-async-lock-2.8.0/debian/control2023-08-24 10:45:54.0 
+0200
+++ rust-async-lock-2.8.0/debian/control2024-04-13 17:07:17.0 
+0200
@@ -5,7 +5,7 @@
  debhelper-compat (= 13),
  dh-cargo (>= 25),
  librust-async-channel-1+default-dev,
- librust-event-listener-2+default-dev,
+ librust-event-listener-5+default-dev,
  librust-fastrand-1+default-dev,
  librust-futures-lite-1+default-dev,
  libstring-shellquote-perl,
@@ -20,7 +20,7 @@
 Architecture: all
 Multi-Arch: foreign
 Depends:
- librust-event-listener-2+default-dev,
+ librust-event-listener-5+default-dev,
  ${misc:Depends},
 Provides:
  librust-async-lock-2+default-dev (= ${binary:Version}),
diff -Nru rust-async-lock-2.8.0/debian/patches/relax-event-listener.diff 
rust-async-lock-2.8.0/debian/patches/relax-event-listener.diff
--- rust-async-lock-2.8.0/debian/patches/relax-event-listener.diff  
1970-01-01 01:00:00.0 +0100
+++ rust-async-lock-2.8.0/debian/patches/relax-event-listener.diff  
2024-04-13 17:07:17.0 +0200
@@ -0,0 +1,23 @@
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -15,7 +15,7 @@
+ exclude = ["/.*"]
+ 
+ [dependencies]
+-event-listener = "2.5.1"
++event-listener = "5"
+ 
+ [dev-dependencies]
+ async-channel = "1.5.0"
+--- a/src/once_cell.rs
 b/src/once_cell.rs
+@@ -7,7 +7,7 @@
+ use std::sync::atomic::{AtomicUsize, Ordering};
+ use std::task::{Context, Poll, RawWaker, RawWakerVTable, Waker};
+ 
+-use event_listener::{Event, EventListener};
++use event_listener::{Event, EventListener, Listener};
+ 
+ /// The current state of the `OnceCell`.
+ #[derive(Copy, Clone, PartialEq, Eq)]
+
diff -Nru rust-async-lock-2.8.0/debian/patches/series 
rust-async-lock-2.8.0/debian/patches/series
--- rust-async-lock-2.8.0/debian/patches/series 2023-08-24 10:41:50.0 
+0200
+++ rust-async-lock-2.8.0/debian/patches/series 2024-04-13 17:07:04.0 
+0200
@@ -1,2 +1,3 @@
+relax-event-listener.diff
 2001_fastrand.patch
 2001_wasm.patch

Bug#1067561: FTBFS: Error: symbol `open64' is already defined

[Peter Green]

Hi, thanks for the patch. It looks a bit strong though, undefining stuff like
that unconditionally. Do you have pointers to the Ubuntu bug or something?
I've looked at upstream commits and issues and couldn't see anything there.


My understanding of the issue.

In glibc _FILE_OFFSET_BITS=64 is used to substitute the standard file
handling types and functions with versions that use 64-bit file
offsets. Similarly _TIME_BITS=64 is used to susbstitute time handling
types and functions with versions that use 64-bit seconds counts.

All of this only applies to 32-bit architectures, on 64-bit
architectures the default types in glibc are 64-bit.

The "time64" transition was implemented by defining _TIME_BITS=64 and
_FILE_OFFSET_BITS=64 by default in both dpkg-buildflags and the compiler.

That's fine for normal code, but tests/src/libsystem.c is not normal
code, it's a file of "test mocks" that override functions in glibc
for testing purposes. If _FILE_OFFSET_BITS=64 is defined, it ends up
trying to override "open64" twice, rather than trying to override both
"open" and "open64"

If we undef _FILE_OFFSET_BITS then we must also undef _TIME_BITS,
otherwise the glibc headers will refuse to compile.

So the patch seems reasonable to me, and since this is only test
code, it appears to be pretty low risk. We would appreciate having
this fix in unstable so the time_t transition can move forward.

Bug#1052434: Acknowledgement (qttools-opensource-src: FTBFS on hppa - No rule to make target 'assistant.qch')

[John David Anglin]

This bug appears to have been introduced by the fix for #1045220.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'

[Diederik de Haas]

Control: forcemerge -1 1065184

On Saturday, 13 April 2024 16:32:04 CEST Andreas Metzler wrote:
> > If you agree, please merge these two bugs.
> > FTR: Bug #1065184 is already fixed in git.
> 
> FWIW I can cobnfirm that xwayland builds successfully if libtirpc-dev is
> installed.

Thanks, then I'm merging the bugs. Today a "release to sid" commit was made, 
so this bug will be closed/fixed real soon now.

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

Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"

[David Kalnischkies]

On Thu, Apr 11, 2024 at 04:46:03PM +, mYnDstrEAm wrote:
> With the two commands above one can already split it up into two steps but 
> especially the second command still requires a lot of disk space.

I am going to assume that your "a lot of disk space" stems from the
*.deb files that are downloaded. If so, you can e.g. attach an USB disk/
drive and mount it e.g. under /media/apt-archives

Tell apt to use that directory instead of /var/cache/apt/archives, e.g.:
apt upgrade -o dir::cache::archives=/media/apt-archives

(for some more free MBs you could 'apt clean' and then move dir::cache
 elsewhere, but for that you need to create some directories in the
 target location and the binary caches are not THAT large to make it
 really worthwhile in practice. Similar for other files like
 /var/lib/apt aka dir::state::lists)


Instead of an USB drive you could do the same with e.g. an SD card, drop
them into RAM (if your device has surprisingly more RAM than disk) or
even use a network share (NFS, sshfs, … you name it). The filesystem is
not usually a concern (as in: even fat32 should work given we encode
away the : in epochs).

Note that whoever has write access to the files on the storage (or in
case of unencrypted transfer, also everyone who can meddle with transfer
over the network) could use that to attack you as apt (well, apt will
casually check them first, but after that and dpkg, who actually
interacts with them the most) will assume that the files in
/var/cache/apt/archives (or where ever else you stored them and told apt
to use them) are valid & trusted.


Note also that apt uses for its space check statvfs(3) f_bavail, as in,
depending on how you configured your disk, it should have a couple of
additional free blocks in reserve (typically 5%, see tune2fs(8) -m).
If you know what you are doing, you could decrease that value.


Note that the value apt displays is only an estimate, powered by what
the individual packages claim (via dpkg), which is an estimate. Also, if
you happen to have a 2GB installed, the upgrade will roughly take an
additional 2GB as dpkg would first extract the new files along the old
ones and then replace them in one swoop – so for a bit, you have that
package installed two times. Multiple this by group size, divide by
unchanged files and sprinkle some salt over it for flavour.
Predictions are hard, especially about the future.


I would in general not recommend to try approaches like upgrading
individual packages as that easily leads unsuspecting users into
situations that nobody else has encountered before: aka bugs in
packages that nobody else will encounter as they are either hidden
by the involved set usually being upgraded together as intended™ or
– which tends to be even worse – the breakage is known but ignored
on purpose as the solution is far worse than the problem (at least for
everyone doing upgrades the normal way – example: usrmerge). Also, but
that is just an aside, people grossly overestimate how easy it is for
packages to be upgraded individually (compare: t64 testing migration).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1068926: Acknowledgement (plasma-discover: Plasma-Discover is crashing every time I open it)

[Giulio]

Solved in this way

giulio@q4os-pc:~$ ulimit -n
1024
giulio@q4os-pc:~$ ulimit -n 2048
giulio@q4os-pc:~$ ulimit -n
2048


On Sat, Apr 13, 2024 at 4:00 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1068926:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068926.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Qt/KDE Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 1068...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1068926: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068926
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'

[Andreas Metzler]

On 2024-03-23 Diederik de Haas  wrote:
[...]
> 2) near the end of your build log is the following message:
> "../os/meson.build:63:8: ERROR: Problem encountered: secure-rpc requested, 
> but 
> neither libtirpc or libc RPC support were found"
> And that matches the build issue mentioned in #1065184.

> If you agree, please merge these two bugs.
> FTR: Bug #1065184 is already fixed in git.

FWIW I can cobnfirm that xwayland builds successfully if libtirpc-dev is
installed.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1046444: virtualjaguar: Fails to build source after successful build

[John Paul Adrian Glaubitz]

Hi,

On Sun, 2023-08-13 at 21:21 +0200, Lucas Nussbaum wrote:
> Relevant part of the build log:
> > cd /<> && runuser -u user42 -- dpkg-buildpackage 
> > --sanitize-env -us -uc -rfakeroot -S
> > -
> > 
> > dpkg-buildpackage: info: source package virtualjaguar
> > dpkg-buildpackage: info: source version 2.1.3-2
> > dpkg-buildpackage: info: source distribution unstable
> > dpkg-buildpackage: info: source changed by John Paul Adrian Glaubitz 
> > 
> >  dpkg-source --before-build .
> >  fakeroot debian/rules clean
> > dh clean
> > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
> >dh_auto_clean
> > dh_auto_clean: warning: Compatibility levels before 10 are deprecated 
> > (level 9 in use)
> > make -j1 clean
> > make[1]: Entering directory '/<>'
> > -ne *** Cleaning out the garbage...
> > done!
> > make[1]: Leaving directory '/<>'
> >dh_clean
> > dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 
> > in use)
> >  dpkg-source -b .
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building virtualjaguar using existing 
> > ./virtualjaguar_2.1.3.orig.tar.bz2
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: warning: ignoring deletion of file src/m68000/m68kdasm.c.bak, 
> > use --include-removal to override
> > dpkg-source: info: local changes detected, the modified files are:
> >  virtualjaguar-2.1.3/.qmake.stash
> >  virtualjaguar-2.1.3/src/version.h
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/virtualjaguar_2.1.3-2.diff.v1VkyG
> > dpkg-source: info: Hint: make sure the version in debian/changelog matches 
> > the unpacked source tree
> > dpkg-source: info: you can integrate the local changes with dpkg-source 
> > --commit
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
> > 
> > E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage 
> > --sanitize-env -us -uc -rfakeroot -S' failed to run.

After close inspection of the build log and the original tarball, it turns out 
that the tarball
used is not identical to the one available from the upstream FTP server [1]:

glaubitz@z6:~/debian> wget -q 
http://icculus.org/virtualjaguar/tarballs/virtualjaguar-2.1.3.tar.bz2 -O 
virtualjaguar-upstream-2.1.3.tar.bz2
glaubitz@z6:~/debian> md5sum virtualjaguar-upstream-2.1.3.tar.bz2 
virtualjaguar_2.1.3.orig.tar.bz2 
17af87b3a7cfd9106e49afc56d4858e6  virtualjaguar-upstream-2.1.3.tar.bz2
0e3f30737c171c096ac2690a38f7029a  virtualjaguar_2.1.3.orig.tar.bz2
glaubitz@z6:~/debian>

Further inspection reveals that the file src/m68000/m68kdasm.c.bak that is 
deleted during build
and prevents a second successful build is not part of the original source:

glaubitz@z6:~/debian> tar tf virtualjaguar_2.1.3.orig.tar.bz2 |grep bak
linux-2.1.3/src/m68000/m68kdasm.c.bak
glaubitz@z6:~/debian> tar tf virtualjaguar-upstream-2.1.3.tar.bz2  |grep bak
glaubitz@z6:~/debian>

I don't really remember how I created the first upload of the 2.1.3 upstream 
version, but since
upstream development has ceased, I can upload a fixed version only with a 
forged upstream version
using "really" or similar since there won't be a new upstream release unless 
the upstream project
is forked.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1051232: bookworm-pu: package 7zip/23.01+dfsg-3~deb12u1

[yokota]

> I am not in a position to assess that for you. You're the maintainer, you
> need to be able to vouch for your proposed upload.

Upstream dose not have VCS and not provide fix patch, and just
releases new version 7-Zip 23.01 as fix.
So, I can't guarantee the bug was fixed except new upstream version 23.01.

I think we need some Debian Developer provide BPO package 7zip 23.01
to fix this issue.
Because I am a Debian Maintainer, I can't provide such BPO package.

--
YOKOTA Hiroshi

Bug#1068914: flactag: Disks cannot be tagged, information is retrieved but not displayed

[Andy Hawkins]

This is due to Amazon rejecting the request due to the user agent 
presented by flactag.


It was fixed in the following upstream commit (in a version yet to be 
released).


https://github.com/adhawkins/flactag/commit/570a80185bf6f02277585bc60091ddae06df9058

Any suggestions as to a better way to get around this are appreciated.

Andy


On 13/04/2024 10:53 am, sok wrote:

Package: flactag
Version: 2.0.4-6+b2
Severity: important

Dear Maintainer,

when using flactag on flac files, no matter if they are created with 
ripflac or
other means, or even if they were already tagged using flactag, the 
retrieved

disk information is neither shown nor processed. There are no releases to
select from, the normal window is displayed with no information on the 
upper
side and only skeleton information on the disk/song structure on the 
lower side.


As an "Exception: Fetch error: 403 Forbidden" is shown when running 
flactag I

used wireshark to get information on the network traffic and that looked
absolutely fine on the MusicBrainz part. There are two connections on which
information was retrieved. I checked those URL in the browser for closer
inspection and they were returning information as well. The 403 is caused
when trying to get the disk cover.

I am neither providing information on the disk images used to try 
tagging nor

on the network traffic as the error should be replicable easily with any
suitable flac file.

My assumption is that while the information can still be accessed 
successfully
the internal representation format must have changed so that it can no 
longer

be interpreted by flactag.


Best,
sok


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

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flactag depends on:
ii libc6 2.36-9+deb12u4
ii libdiscid0 0.6.2-3
ii libflac++10 1.4.2+ds-2
pn libflac12t64 
ii libgcc-s1 12.2.0-14
ii libjpeg62-turbo 1:2.1.5-2
ii libmusicbrainz5cc2v5 5.1.0+git20150707-10
ii libslang2 2.3.3-3
ii libstdc++6 12.2.0-14
ii libunac1 1.8.0-10

Versions of packages flactag recommends:
ii cdparanoia 3.10.2+debian-14
ii cdrdao 1:1.2.4-3
ii cuetools 1.4.1-0.2
ii flac 1.4.2+ds-2

flactag suggests no packages.

-- debconf-show failed

Bug#1068928: lammps : FTBFS on armhf (undefined symbol: pmix_value_load or error: subprocess-exited-with-error)

[Kentaro HAYASHI]

Source: lammps 
Severity: important
Tags: ftbfs
Control: found -1 20240207+dfsg-1.1
X-Debbugs-Cc: ken...@xdump.org

Dear Maintainer,

lammps fails to build on armhf.

FYI:

https://buildd.debian.org/status/fetch.php?pkg=lammps&arch=armhf&ver=20240207%2Bdfsg-1.1%2Bb1&stamp=1712551793&raw=0

Note that build error message was a bit different on armhf porterbox.
(attached logs)

Regards,


lammps.debuild.log.xz
Description: application/xz

Bug#1068927: ITP: rust-event-listener-strategy -- block or poll on event_listener easily

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-event-listener-strategy
  Version : 0.5.1
  Upstream Contact: John Nunley 
* URL : https://github.com/smol-rs/event-listener-strategy
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : block or poll on event_listener easily

 event-listener-strategy  provides a strategy
 for using the event-listener crate
 in both blocking and non-blocking contexts.
 .
 One of the stand-out features of the event-listener crate
 is the ability to use it in both asynchronous and synchronous contexts.
 However, sometimes using it like this
 causes a lot of boilerplate to be duplicated.
 This crate aims to reduce that boilerplate
 by providing an EventListenerFuture trait
 that implements both blocking and non-blocking functionality.

This package is needed for newer releases of src:rust-async-lock and
src:rust-async-channel.
It will be maintained in the collaborative Debian section of Salsa, at
https://salsa.debian.org/debian/rust-event-listener-strategy

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYaklcACgkQLHwxRsGg
ASHWLhAAoN2U3vUvMe6vng6U0BCHoImeJor7wGb0RsR8SagWtONeDyubBoK/kNgx
lWhvgwcLcgc4bTKPdqqfH44svsQ9qMAQFdYp9QZZXXuUJCKwPjlbrgwcEpUu0gy1
H3mVsZOzwWH2ldnlE6F71L+uQSJriaCyN5HbFXfkXIo25WELcE0trGJletqHuiVM
cONmMXGSFNjPc6DFNOfIAUrfyIt9qp1urCu4nzLWsvxBV3CgrUyPBZLlcezOa9wd
NfVv2A2FVwxDYqst5hwckmemgjr/82Y5jn8Wd644vhlxIHN7cNFq8awQ1wY3Bz8/
C9VuVyz7P0NCotqM0oWosYk+hZyDEGkiapFiGPQlQSbPTSbBdPRLoMd25W6ABSxk
wnW9mBPRhebNl30ZODCePM1PRlM8DhVygeIFkXs3kBScLSRjAMtHh3c4EWw3pcls
7e819qb/mHce4xcrHxeybCl5DB3k6pDpn6+0gHYemrbpAsCcr9aWLoRxTMbh9Uin
5vYugGlaROdD13Ojkinbm+HXmwEEWqTXu/y2M+dzNJNIRS45XsOSAq6nHZKot3jg
/LlwCresEdWv7UY8PO4Z21EoXUSrStA8pIqqJyzKx+hXvf/l1vIvV8iYLWDgGGmU
ht7rS5GLaoXx2HI0o1hFDeMFU51F0D5Vy6unvbKulJNzv7fLVyA=
=Cau5
-END PGP SIGNATURE-

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

[Wesley Schwengle]

Hi

On Fri, Apr 12, 2024 at 09:04:23AM +0200, Jan Katins wrote:
> Subject: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
> Package: cryptsetup
> Version: 2:2.7.2-1
> Severity: normal
> 
> After a recent apt upgrade, my system failed to unlock. After a
> ctrl-alt-del, I got to the console and there it showed an error about
> libgcc_s.so.1 not available and aborting.
> 
> Thankfully, I still had a other initrd around (I guess due to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065698, yay for
> bugs!).
> 
> I snooped around in the source code a bit and found that libgcc_s
> seems to be dlopened and is special cased:
> https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/hook-functions?ref_type=heads#L248-249
> (original bugreport:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254). So my guess
> is that nothing depends on libpthread either anymore, and this is the
> case: `lsinitramfs initrd.img-6.7.9-amd64 |grep thread` shows no
> libpthread (actually nothing). I fixed it now by installing a
> update-initramfs hook (thanks to
> https://groups.google.com/g/linux.debian.bugs.dist/c/4fi2HaOEC_M):

I had the same issue a while back, because of the t64 transitioning I chaulked
it up to that. I fixed it as described in Ubuntu bug:

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594

Cheers,
Wesley

Bug#1068694: bullseye-pu: package json-smart/2.2-2+deb11u1

[Bastien Roucariès]

Le samedi 13 avril 2024, 14:00:00 UTC Moritz Mühlenhoff a écrit :
Hi,

> Am Tue, Apr 09, 2024 at 10:01:11AM +0200 schrieb Andreas Beckmann:
> > Package: release.debian.org
> > Severity: normal
> > Tags: bullseye
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > X-Debbugs-Cc: Bastien Roucariès 
> > Control: affects -1 + src:json-smart
> > Control: block 1039985 with -1
> > Control: block 1033474 with -1
> > 
> > [ Reason ]
> > Two CVEs were fixed in buster-lts, but not yet in bullseye or later,
> > causing version skew on upgrades:
> 
> CVE-2023-1370 / #1033474 is unfixed in sid, and being fixed in unstable
> is a pre condition for a point update.
> 
> Bastien, since you fixed it in buster-lts, can you please also take care
> of addressing unstable?


Ok will do
> 
> Cheers,
> Moritz
> 



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

Bug#1068694: bullseye-pu: package json-smart/2.2-2+deb11u1

[Moritz Mühlenhoff]

Am Tue, Apr 09, 2024 at 10:01:11AM +0200 schrieb Andreas Beckmann:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: Bastien Roucariès 
> Control: affects -1 + src:json-smart
> Control: block 1039985 with -1
> Control: block 1033474 with -1
> 
> [ Reason ]
> Two CVEs were fixed in buster-lts, but not yet in bullseye or later,
> causing version skew on upgrades:

CVE-2023-1370 / #1033474 is unfixed in sid, and being fixed in unstable
is a pre condition for a point update.

Bastien, since you fixed it in buster-lts, can you please also take care
of addressing unstable?

Cheers,
Moritz

Bug#1068926: plasma-discover: Plasma-Discover is crashing every time I open it

[Giulio]

Package: plasma-discover
Version: 5.20.5-3+deb11u2
Severity: important

Dear Maintainer,

PlasmaDiscover app crashes every time I try to open it to look at the
updates
If I start it from the terminal I can see an error reported from the
console:

```
(process:10596): GLib-ERROR **: 14:54:23.125: Creating pipes for GWakeup:
Troppi file aperti
Rilevato trace/breakpoint
```

Thanks and regards
Giulio


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

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

Versions of packages plasma-discover depends on:
ii  appstream0.14.4-1
ii  apt-config-icons 0.14.4-1
ii  kio  5.78.0-5
ii  libappstreamqt2  0.14.4-1
ii  libc62.31-13+deb11u8
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-4
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5i18n5  5.78.0-2
ii  libkf5itemmodels55.78.0-2
ii  libkf5kiocore5   5.78.0-5
ii  libkf5kiogui55.78.0-5
ii  libkf5kiowidgets55.78.0-5
ii  libkf5notifications5 5.78.0-2
ii  libkf5quickaddons5   5.78.0-2
ii  libkf5service-bin5.78.0-2
ii  libkf5service5   5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libmarkdown2 2.2.6-1
ii  libpackagekitqt5-1   1.0.2-1
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5dbus5  5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5qml5   5.15.2+dfsg-6
ii  libqt5quick5 5.15.2+dfsg-6
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libqt5xml5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6
ii  packagekit   1.2.2-2
ii  plasma-discover-common   5.20.5-3+deb11u2
ii  qml-module-org-kde-kcoreaddons   5.78.0-2
ii  qml-module-org-kde-kirigami2 5.78.0-3
ii  qml-module-org-kde-kquickcontrols5.78.0-2
ii  qml-module-org-kde-kquickcontrolsaddons  5.78.0-2
ii  qml-module-org-kde-qqc2desktopstyle  5.78.0-2
ii  qml-module-qtquick-dialogs   5.15.2-2

Versions of packages plasma-discover recommends:
ii  apt-config-icons-hidpi0.14.4-1
ii  apt-config-icons-large0.14.4-1
ii  apt-config-icons-large-hidpi  0.14.4-1
ii  software-properties-kde   0.96.20.2-2.1

Versions of packages plasma-discover suggests:
ii  plasma-discover-backend-flatpak  5.20.5-3+deb11u2
pn  plasma-discover-backend-fwupd

-- no debconf information

Bug#1068925: macromoleculebuilder: FTBFS on armhf (error: inconsistent deduction for auto return type: 'long int' and then 'long long int')

[Kentaro HAYASHI]

Source:  macromoleculebuilder
Severity: important
Tags: ftbfs
Control: found -1  4.0.0+dfsg-3.1 
X-Debbugs-Cc: ken...@xdump.org

Dear Maintainer,

 macromoleculebuilder fails to build on armhf.

FYI:

https://buildd.debian.org/status/fetch.php?pkg=macromoleculebuilder&arch=armhf&ver=4.0.0%2Bdfsg-3.1&stamp=1710492689&raw=0

Currently, limited architecture succeeds to build (amd64,
arm64, and loong64)

Regards,

Bug#1068473: closed by Debian FTP Masters (reply to Bas Couwenberg ) (Bug#1068473: fixed in icinga2 2.13.6-2+deb12u1)

[Aurelien Jarno]

Hi Sebastiaan,

On 2024-04-09 16:51, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:icinga2 package:
> 
> #1068473: icinga2: crashes on startup on ppc64el
> 
> It has been closed by Debian FTP Masters  
> (reply to Bas Couwenberg ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Bas Couwenberg 
> ) by
> replying to this email.

Thanks a lot for promptly fixing this bug. The ppc64el hosts in the
debian infrastructure are now using the icinga2 packages from
bookworm-proposed-updates and all works fine.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#1057531: openjfx: diff for NMU version 11.0.11+1-3.2

[Sebastian Ramacher]

Control: tags 1057531 + patch

Dear maintainer,

I've prepared an NMU for openjfx (versioned as 11.0.11+1-3.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru openjfx-11.0.11+1/debian/changelog openjfx-11.0.11+1/debian/changelog
--- openjfx-11.0.11+1/debian/changelog	2023-07-16 05:30:26.0 +0200
+++ openjfx-11.0.11+1/debian/changelog	2024-04-13 13:01:57.0 +0200
@@ -1,3 +1,17 @@
+openjfx (11.0.11+1-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Steve Langasek ]
+  * debian/patches/64-bit-time-t.patch: don't unset _FILE_OFFSET_BITS.
+Closes: #1068159.
+
+  [ Pushkar Kulkarni ]
+  * d/patches: Patch to fix compiler errors with openjdk-21 (LP: #2053246)
+(Closes: #1057531)
+
+ -- Sebastian Ramacher   Sat, 13 Apr 2024 13:01:57 +0200
+
 openjfx (11.0.11+1-3.1) unstable; urgency=medium
 
   * Team upload.
diff -Nru openjfx-11.0.11+1/debian/patches/64-bit-time-t.patch openjfx-11.0.11+1/debian/patches/64-bit-time-t.patch
--- openjfx-11.0.11+1/debian/patches/64-bit-time-t.patch	1970-01-01 01:00:00.0 +0100
+++ openjfx-11.0.11+1/debian/patches/64-bit-time-t.patch	2024-04-13 07:04:41.0 +0200
@@ -0,0 +1,27 @@
+Description: don't unset _FILE_OFFSET_BITS
+ This is a prerequisite for 64-bit time_t.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1068159
+Last-Update: 2024-04-12
+Forwarded: no
+
+Index: openjfx-11.0.11+1/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h
+===
+--- openjfx-11.0.11+1.orig/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h
 openjfx-11.0.11+1/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h
+@@ -544,7 +544,7 @@
+ #endif
+ 
+ /* Number of bits in a file offset, on hosts where this is settable. */
+-#undef _FILE_OFFSET_BITS
++//#undef _FILE_OFFSET_BITS
+ 
+ /* Define to 1 to make fseeko visible on some hosts (e.g. glibc 2.2). */
+ #undef _LARGEFILE_SOURCE
+@@ -570,4 +570,4 @@
+ 
+ #ifdef GSTREAMER_LITE
+ #define DISABLE_ORC
+-#endif // GSTREAMER_LITE
+\ No newline at end of file
++#endif // GSTREAMER_LITE
diff -Nru openjfx-11.0.11+1/debian/patches/jdk-21-compilation.patch openjfx-11.0.11+1/debian/patches/jdk-21-compilation.patch
--- openjfx-11.0.11+1/debian/patches/jdk-21-compilation.patch	1970-01-01 01:00:00.0 +0100
+++ openjfx-11.0.11+1/debian/patches/jdk-21-compilation.patch	2024-02-18 20:23:28.0 +0100
@@ -0,0 +1,83 @@
+Description: Patch to enable compilation with openjdk-21
+ With openjdk-21, the code being patched make the compiler throw ambiguity errors.
+ We need not forward this patch upstream because the latter's latest repos are
+ updated to build with the latest versions of the JDK. 
+Author: Pushkar Kulkarni 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057531
+Forwarded: not-needed
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/modules/javafx.graphics/src/main/java/javafx/concurrent/Task.java
 b/modules/javafx.graphics/src/main/java/javafx/concurrent/Task.java
+@@ -690,14 +690,14 @@
+  */
+ protected abstract V call() throws Exception;
+ 
+-private ObjectProperty state = new SimpleObjectProperty<>(this, "state", State.READY);
+-final void setState(State value) { // package access for the Service
++private ObjectProperty state = new SimpleObjectProperty<>(this, "state", Worker.State.READY);
++final void setState(Worker.State value) { // package access for the Service
+ checkThread();
+-final State s = getState();
+-if (s != State.CANCELLED) {
++final Worker.State s = getState();
++if (s != Worker.State.CANCELLED) {
+ this.state.set(value);
+ // Make sure the running flag is set
+-setRunning(value == State.SCHEDULED || value == State.RUNNING);
++setRunning(value == Worker.State.SCHEDULED || value == Worker.State.RUNNING);
+ 
+ // Invoke the event handlers, and then call the protected methods.
+ switch (state.get()) {
+@@ -729,8 +729,8 @@
+ }
+ }
+ }
+-@Override public final State getState() { checkThread(); return state.get(); }
+-@Override public final ReadOnlyObjectProperty stateProperty() { checkThread(); return state; }
++@Override public final Worker.State getState() { checkThread(); return state.get(); }
++@Override public final ReadOnlyObjectProperty stateProperty() { checkThread(); return state; }
+ 
+ /**
+  * The onSchedule event handler is called whenever the Task state
+@@ -1024,9 +1024,9 @@
+ // state flag will not be readable immediately after this call. However,
+ // that would be the case anyway since these properties are not thread-safe.
+ if (isFxApplicationThread()) {

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Martin Steigerwald - 13.04.24, 14:32:16 CEST:
> Any idea how to find the cause of what is happening here?

I found the cause:

The container starts out with an almost empty environment. In
/etc/runit/1 I added lines 4 to 6:

  1 #!/bin/sh
  2 # system one time initialization tasks
  3 
  4 echo ">> environment" >> /tmp/rcS.log
  5 /usr/bin/env >> /tmp/rcS.log
  6 echo ">> end of environment" >> /tmp/rcS.log
  7 
  8 PATH=/sbin:/usr/sbin:/bin:/usr/bin

(For some reason using /tmp/rcS.log did not give me any output. Although
/tmp is not mounted elsewhere during the boot process.)

This gives me:

root@zdevuan:~# cat rcS.log 
>> environment
container=lxc
PWD=/
>> end of environment

No PATH defined.

The script defines it. See line 8 in my changed script. However it does not 
export it. Thus adding line 9 fixes the bug I reported:

  8 PATH=/sbin:/usr/sbin:/bin:/usr/bin
  9 export PATH

The network is configured just fine after adding that line.



Same goes for stage 2. In /etc/runit/2 I added:

 38 echo "$runsv_dir" 2>&1 >> /tmp/rc2.log
 39 echo ">> environment" >> /tmp/rc2.log
 40 env >> /tmp/rc2.log >>  /tmp/rc2.log
 41 echo ">> end of environment"
 42 ls -l /etc/runit/no.emulate.sysv 2>&1 >>/tmp/rc2.log
 43 if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/
no.emulate.sysv ]; then
 44 echo "run rc2.d scripts…" 2>&1 >>/tmp/rc2.log
 45 /lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d' 2>&1 >>/tmp/rc2.log
 46 fi

Which gives me:

>> environment
container=lxc
PWD=/
>> end of environment

Exporting the PATH there as well like

  1 #!/bin/sh
  2 
  3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
  4 export PATH
  5 SVDIR=/etc/service

fixes

root@zdevuan:~# cat /etc/boot.d/network
#!/usr/bin/env sh

/etc/init.d/networking restart

The network is configured even without the "export PATH" fix in
/etc/runit/1.

I just wonder why stage 2 contains /usr/local bin directories. I think
that should not be the case. Shall I report this as a different issue?



I am now undoing my debug output.

I think I could provide a merge request for the fixes at a later time.
For now I like to finish the Devuan template and actually use it.

That bootlogd does not seem to work inside a container is a different
issue I may report at another time.

I added empty "debug" and "verbose" files in /etc/runit but did not
find any debug output. Maybe those files needed to have some content.
Maybe it requires bootlogd.

But that is for another time :)

Best,
-- 
Martin

Bug#1068924: libembree-dev: Please build with ISPC enabled

[Francois Mazen]

Package: libembree-dev
Severity: wishlist
Tags: patch
X-Debbugs-Cc: franc...@mzf.fr

Dear Maintainer,

I'm working on packaging Intel OSPRay [1], and it needs ispc support of embree.

Attached a patch that enable ispc for libembree-dev.

Could you please enable ISPC support in Embree? I can NMU if you have no time
for this.

Best,

François

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039111


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/16 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 libembree-dev depends on:
ii  libembree3-3  3.13.5+dfsg-2
pn  libtbb-dev

libembree-dev recommends no packages.

Versions of packages libembree-dev suggests:
pn  embree-tools  
diff --git a/debian/control b/debian/control
index 924a8df..8ab7271 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
  cmake,
  debhelper-compat (= 13),
  freeglut3-dev,
+ ispc,
  libglfw3-dev,
  libjpeg-dev,
  libopenimageio-dev,
diff --git a/debian/rules b/debian/rules
index 5d933e2..8ccb71a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,7 +25,7 @@ override_dh_auto_configure:
dh_auto_configure -- \
-DCMAKE_SKIP_RPATH=ON \
-DEMBREE_BACKFACE_CULLING=OFF \
-   -DEMBREE_ISPC_SUPPORT=OFF \
+   -DEMBREE_ISPC_SUPPORT=ON \
-DEMBREE_RAY_MASK=ON \
-DEMBREE_ARM=$(EMBREE_ARM) \
-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF \

Bug#1068775: sbuild-qemu: fails to work, if piuparts is requested, but not installed on the host

[Francesco Poli]

Control: severity -1 wishlist


On Fri, 12 Apr 2024 19:57:23 +0200 Johannes Schauer Marin Rodrigues
wrote:

[...]
> Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51)
[...]
> > I can update the virtual machine (if I create a symlink, see bug 
> > [#1061816]):
> >
> >   $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img
> > 
> > [#1061816]: 
> 
> I think 1061816 was fixed with 0.85.7 and the changelog was just missing the
> "closes" entry:
> 
> https://tracker.debian.org/news/1518576/accepted-sbuild-0857-source-into-unstable/

Yes, I have just tested sbuild-qemu/0.85.7 from unstable, and I can
confirm that the symlink is no longer needed.
I have just sent a message to close bug report #1061816 ...

> 
> > But, when I try to build a package from withing the unpacked source
> > tree:
[...]
> > Error reading configuration: PIUPARTS binary 'piuparts' does not exist or 
> > is not executable at /usr/share/perl5/Sbuild/Conf.pm line 76.
> > 
> > Now, piuparts is indeed not installed on the host:
[...]
> > However, I thought that setting $run_piuparts = 1 in ~/.sbuildrc caused
> > piuparts to be run inside the virtual machine guest system, not on the
> > host system!
> 
> What made you think that? Is the error message above not clear enough? Do you
> think it should be improved to make things clearer? Do you have suggestions 
> for
> a message that would've better explained that piuparts needs to be installed 
> on
> the host system?

My point is not that the error message should be improved.
Actually, I think the error message clearness is basically OK.

> 
> > Hence, I thought that piuparts was going to be automatically installed
> > and executed on the guest system (actually on the throw-away overlay).
> > And I thought that the same was going to happen for $run_autopkgtest = 1
> > and for $run_lintian = 1 ...
> > 
> > Am I completely off-track?
> > What did I fail to understand?
> > 
> > Why does sbuild-qemu insist that piuparts be installed on the *host*
> > system?
> 
> Because it needs to be installed on the host. In the same way as autopkgtest
> needs to be on the host. What can sbuild improve?

My point is that sbuild{,-qemu} should install piuparts inside the build
environment (chroot or VM guest system) and run it from within the
build environment, if this is possible.

Does sbuild{,-qemu} do so for lintian? I think this is even more
important for lintian: if the host system runs Debian testing (or maybe
even Debian stable) and the package is being built for Debian unstable
(as upload target), then the package should be checked by the version
of lintian which is currently in Debian unstable. If it were checked by
the version of lintian from Debian testing (or even from Debian
stable), many undeserved "unknown Policy version" complaints could pop
up...

Do you agree with the reasoning?

Thanks for your time and patience!   :-)

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpli10LtTDY8.pgp
Description: PGP signature

Bug#1022726: New Dillo release 3.1.0-rc1

[Rodrigo Arias]

Hi,

I've been maintaining Dillo for some months to get the 3.1.0 release 
ready, so it can include some of the changes since 3.0.5 was released 
back in 2015. I'm trying to stick to the original goal, which is to keep 
the browser as simple as posible and support a wide range of systems.


I have created a new website for it, which contains the old website 
files too:


https://dillo-browser.github.io/

I explained what happened to the dillo dot org domain in a post, with a 
bit of background to understand why it happened:


https://dillo-browser.github.io/dillo.org.html

There have been no replies from Jorge, the lead developer of Dillo since 
2019. I have also contacted several developers via alternative emails 
from the commit logs and some of them replied and they have helped me to 
get a backup from the original server for the mailing list archives and 
the website.


The mailing list is now at  and we keep the old 
and new archives here:


https://lists.mailman3.com/postorius/lists/dillo-dev.mailman3.com/

We have made the 3.1.0-rc1 release candidate while we perform the final 
tests before the stable 3.1.0 is release. Please check the release 
notes:


https://dillo-browser.github.io/latest.html

While we build Dillo on Ubuntu and other systems on the GitHub CI, I 
would expect it to work without problems on Debian, but it would be nice 
to get it packaged and tested on a physical system.


If you want to see the details, check the issues/PR or the commit log:

https://github.com/dillo-browser/dillo/milestone/1?closed=1
https://github.com/dillo-browser/dillo/commits/master/

Dillo now allows building TLS support from OpenSSL 3, OpenSSL 1.1, Mbed 
TLS 2, Mbed TLS 3 or LibreSSL. By default, it searches first for 
OpenSSL.


Some of the bugs from your tracker have been fixed, others need a bit 
more time.


For this release, we are mostly fixing bugs. New features from other 
forks like DilloNG may be introduced later.


Thank you for keeping it on the repositories for all these years, 
hopefully we can get a new version soon.


Best regards,
Rodrigo.

Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"

[Bernd Zeimetz]

On Thu, 2024-04-11 at 16:46 +, mYnDstrEAm wrote:
> 
> For example, I think a good approach to this would be something like
> this (if the user is low on root partition disk space):
> 1. asking for *at least* 400MB to be available
> 2. if a parameter for stepwise is set or it detected low free disk
> space:
> 3. downloading the first 300 MB or so of packages
> 4. installing these
> 5. deleting the cached packages from /var/cache/apt/archives/
> 6. downloading the next batch up to the storage limit set at start
> 7. and so on (without exiting in-between)
> 

quick and dirty and not tested:

while apt -s upgrade | grep '^Inst' | head -1 | awk '{print $2}' |
xargs apt install; do apt clean; done

Use head -10 or whatever fits for more/less packages.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1068923: heat-cfntools: Remove from Debian?

[Jeremy Bícha]

Source: heat-cfntools
Version: 1.4.2-4
Severity: serious
Control: blocks 1058652 by -1

According to https://launchpad.net/bugs/2052437

"heat-cfntools has officially been retired in the upstream OpenStack
project so we should just RM it from the archive"

heat-cfntools was already removed from Testing because of
https://bugs.debian.org/1058242

Can we file a removal bug for heat-cfntools to allow for the removal
of python-boto?

Thank you,
Jeremy Bícha

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Package: runit-init
Version: 2.1.2-54
Severity: normal
X-Debbugs-Cc: mar...@lichtvoll.de

Dear Maintainer,

Hi!

I have Devuan Excalibur with Incus (forked from LXD) managed LXC
containers. reportbug said the package is unforked and thus I agreed
to send to Debian BTS instead.

All but one of them are Alpine Linux. In there I installed dhcpcd for
dual stack DHCP from Incus managed dnsmasq.

I am currently configuring myself a Devuan template starting from

incus launch images:devuan/daedalus zdevuan

I installed runit-init and socklog-run in there.

The containers comes up but dhcpcd is not running.

It should have been started by /etc/init.d/networking due to
/etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

And indeed it is:

root@zdevuan:~# /etc/init.d/networking start
Configuring network interfaces...dhcpcd-9.4.1 starting
[…]

However even with:

root@zdevuan:~# cat /etc/boot.d/network
#!/usr/bin/env sh

/etc/init.d/networking start

it does not work.



I looked up how runit stage 2 runs init scripts. It does so by:

root@zdevuan:/etc# grep -r "rc2.d"
runit/2:/lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d'

So I ran

/lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d'

manually and indeed it picks up /etc/boot.d/network:

root@zdevuan:~# /lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d'
dmesg: read kernel buffer failed: Operation not permitted
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
Configuring network interfaces...dhcpcd-9.4.1 starting
[…]

That last line is from /etc/boot.d/network.

Thus I tried to find out whether /etc/runit/2 actually runs those scripts
on boot:

 38 echo "$runsv_dir" 2>&1 >> /tmp/rc2.log
 39 ls -l /etc/runit/no.emulate.sysv 2>&1 >>/tmp/rc2.log
 40 if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/no.emulate.sysv ]; 
then
 41 echo "run rc2.d scripts…" 2>&1 >>/tmp/rc2.log
 42 /lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d' 2>&1 >>/tmp/rc2.log
 43 fi

This gives me:

root@zdevuan:~# cat /tmp/rc2.log 
default
run rc2.d scripts…
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
Configuring network interfaces...failed.

So indeed stage 2 runs the scripts. But it cannot configure the network
interface at this time. However running

/lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d'

later just works okay as shown above.

Also putting "/etc/init.d/networking restart" inside
"/etc/boot.d/network" does not work:

Running /etc/init.d/networking restart is deprecated because it may not 
re-enable some interfaces ... (warning).
Reconfiguring network interfaces...failed.

Not even putting

echo "ifdown eth0:"
ifdown eth0

echo "ifup eth0:"
ifup eth0

in there does work:

root@zdevuan:~# cat /tmp/rc2.log 
default
run rc2.d scripts…
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
ifdown eth0:
ifup eth0:

No output from "ifup eth0" which does not seem right.

However "ifdown eth0" and "ifup eth0" just works fine after booting. But
even if I insert a "sleep 10" before those, it still does not work.



I also looked for how rcS.d scripts are executed by Runit stage 0:

root@zdevuan:/etc# grep -r "rcS.d"
[…]
runit/1:for script in /etc/rcS.d/S* ; do


In there I added for debugging:

 11 for script in /etc/rcS.d/S* ; do
 12 path=$(realpath "$script")
 13 name=${path##*/}
 14 [ -e "/etc/runit/no.emulate.sysv.d/$name" ] && continue
[…]
 19 echo "run $script" >>/tmp/rcS.log
 20 "$script" start --force-sysv 2>&1 >>/tmp/rcS.log
 21 done

And indeed stage1 runs the scripts. But configuring network interfaces
fails there as well:

root@zdevuan:~# cat /tmp/rcS.log 
run /etc/rcS.d/S08mountall.sh
Mounting local filesystems...done.
Activating swapfile swap, if any...done.
run /etc/rcS.d/S09mountall-bootclean.sh
Cleaning up temporary files
run /etc/rcS.d/S10brightness
run /etc/rcS.d/S10procps
Starting Setting kernel variables: sysctl is already running.
run /etc/rcS.d/S10stop-bootlogd-single
run /etc/rcS.d/S10urandom
run /etc/rcS.d/S11networking
Configuring network interfaces...failed.
run /etc/rcS.d/S12mountnfs.sh
run /etc/rcS.d/S13mountnfs-bootclean.sh
Cleaning up temporary files
run /etc/rcS.d/S14bootmisc.sh


However as bootlogd is not being started and would not work inside
an LXC container anyway, I am not sure I can see any logging:

root@zdevuan:~# /etc/init.d/bootlogd start
Starting boot logger: bootlogdbootlogd: ioctl(/dev/pts/2, TIOCCONS): Operation 
not permitted


Any idea how to find the cause of what is happening here?

Best,
-- 
Martin

-- System Information:
Devuan Release: Exca

Bug#1068918: node-zx: FTBFS test suite failure

[Jérémy Lal]

Source: node-zx
Version: 7.1.1+~cs6.7.23-3
Followup-For: Bug #1068918
Control: tags -1 ftbfs

Failure:

make[1]: Leaving directory '/<>'
   dh_auto_test --buildsystem=nodejs
  ln -s ../. node_modules/zx
  /bin/sh -ex debian/tests/pkg-js/test
+ uvu -b -i extra.test.js|package.test.js test .*.test.js
^[[1m^[[4m^[[37mcli.test.js^[[22m^[[24m^[[39m
^[[47m^[[1m^[[30m cli ^[[39m^[[49m^[[22m ^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• 
^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• 
^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• 
^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• ^[[39m^[[90m• 
^[[39m^[[31m✘ ^[[39m^[[90m• ^[[39m^[[31m  (19 / 20)
^[[39m
  ^[[1m^[[41m FAIL ^[[22m^[[49m^[[31m^[[47m^[[1m cli ^[[49m^[[22m^[[39m 
^[[2m"^[[22m^[[31m^[[1margv works with zx and node^[[39m^[[22m^[[2m"^[[22m
Expected values to be strictly equal:^[[3m^[[2m  (is)^[[23m^[[22m

^[[31m^[[4m^[[2m^[[3mActual:^[[22m^[[23m^[[39m^[[24m
^[[31m--[^[[2m·^[[22m^[[32m'baz'^[[39m^[[31m^[[2m·^[[22m]^[[39m
^[[32m^[[4m^[[2m^[[3mExpected:^[[22m^[[23m^[[39m^[[24m
^[[32m++[^[[2m·^[[22m'baz'^[[2m·^[[22m]^[[39m
^[[90m
at assert (file:///usr/share/nodejs/uvu/assert/index.mjs:33:8)
at Module.is (file:///usr/share/nodejs/uvu/assert/index.mjs:41:2)
at Object.handler (file:///<>/test/cli.test.js:166:10)
at async Number.runner (file:///usr/share/nodejs/uvu/dist/index.mjs:78:5)
at async Module.exec (file:///usr/share/nodejs/uvu/dist/index.mjs:141:33)
at async Module.run (file:///usr/share/nodejs/uvu/run/index.mjs:12:2)
at async /usr/share/nodejs/uvu/bin.js:26:5^[[39m


Exiting early before testing is finished.
dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:9: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2



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

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

Bug#1068921: node-v8-compile-cache: FTBFS in bookworm, test suite fails

[Jérémy Lal]

Package: node-v8-compile-cache
Version: 2.4.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Even when built with node-undici 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4,
this package fails to build with:

not ok 2 - test/NativeCompileCache-test.js # time=149.066ms
  ---
  env: {}
  file: test/NativeCompileCache-test.js
  timeout: 3
  command: /usr/bin/node
  args:
- test/NativeCompileCache-test.js
  stdio:
- 0
- pipe
- 2
  cwd: /<>
  exitCode: 1
  ...



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

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

Versions of packages node-v8-compile-cache depends on:
ii  nodejs  18.19.1+dfsg-3

node-v8-compile-cache recommends no packages.

node-v8-compile-cache suggests no packages.

-- no debconf information

Bug#1054795: system-config-printer: FTBFS: dh_install: error: missing files, aborting

[Peter Green]

Since there was no apparent maintainer response (the only responses were from
me and from one of the people working on the time64 transition) I went ahead
and uploaded a NMU'd with Ubuntu's fix.

Debdiff is attatched.
diff -Nru system-config-printer-1.5.18/debian/changelog 
system-config-printer-1.5.18/debian/changelog
--- system-config-printer-1.5.18/debian/changelog   2022-12-12 
21:04:11.0 +
+++ system-config-printer-1.5.18/debian/changelog   2024-04-12 
23:24:56.0 +
@@ -1,3 +1,11 @@
+system-config-printer (1.5.18-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix installation of cupshelpers module with Python 3.12. Patch taken from
+Ubuntu 1.5.18-1ubuntu6 upload by Till Kamppeter (Closes: #1054795).
+
+ -- Peter Michael Green   Fri, 12 Apr 2024 23:24:56 +
+
 system-config-printer (1.5.18-1) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff -Nru 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
--- 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
  1970-01-01 00:00:00.0 +
+++ 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
  2024-04-12 23:03:53.0 +
@@ -0,0 +1,11 @@
+--- a/Makefile.am
 b/Makefile.am
+@@ -63,7 +63,7 @@
+ 
+ # Use distutils to install the module.
+ install-exec-local: .stamp-distutils-in-builddir
+-  $(PYTHON) setup.py install --prefix=$(DESTDIR)$(prefix)
++  $(PYTHON) setup.py install --root=$(DESTDIR) --prefix=$(prefix) 
--install-layout=deb
+ 
+ # Uninstall the module, crossing our fingers that we know enough
+ # about how distutils works to do this.  Unfortunately, distutils
diff -Nru system-config-printer-1.5.18/debian/patches/series 
system-config-printer-1.5.18/debian/patches/series
--- system-config-printer-1.5.18/debian/patches/series  2022-12-12 
21:04:11.0 +
+++ system-config-printer-1.5.18/debian/patches/series  2024-04-12 
23:05:12.0 +
@@ -3,3 +3,4 @@
 Allow-installing-packages-from-OpenPrinting.patch
 Do-not-autostart-the-applet-on-LXDE-or-Unity.patch
 Show-Printer-Settings-in-Unity-Control-Center.patch
+makefile-am-fix-setup-py-install.patch
diff -Nru system-config-printer-1.5.18/debian/python3-cupshelpers.install 
system-config-printer-1.5.18/debian/python3-cupshelpers.install
--- system-config-printer-1.5.18/debian/python3-cupshelpers.install 
2022-12-12 21:04:11.0 +
+++ system-config-printer-1.5.18/debian/python3-cupshelpers.install 
2024-04-12 23:03:53.0 +
@@ -1,5 +1,4 @@
 etc/cupshelpers/
-usr/lib/python3*/*-packages/cupshelpers
-usr/lib/python3*/*-packages/cupshelpers-1.0*.egg-info
+usr/lib/python3*/*-packages/cupshelpers*
 debug.py usr/lib/python3/dist-packages/cupshelpers/
 smburi.py usr/lib/python3/dist-packages/cupshelpers/

Bug#1068920: bookworm-pu: package node-zx/7.1.1+~cs6.7.23-2+deb12u1

[Jérémy Lal]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: node...@packages.debian.org, Debian Javascript Maintainers 

Control: affects -1 + src:node-zx
User: release.debian@packages.debian.org
Usertags: pu


[ Reason ]
Fix regression or just plain mistake.
node-zx currently FTBFS #1068918

[ Impact ]
None, it just fixes a test.

[ Tests ]
The test is run during build and autopkgtest:
"argv works with zx and node"

[ Risks ]
Very low risk, since it only affects a test.

[ 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 ]
* patch: fix flaky test (upstream commit)

[ Other info ]
This requires node-undici 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u4,
so should be part of the same bookworm-p-u

Bug#1068919: coreutils: join misconstrues empty fields as missing

[наб]

Package: coreutils
Version: 9.1-1
Version: 9.4-3
Severity: normal

Dear Maintainer,

Given
$ cat f1

b
row1f1  1
row1f1  11
urow1   f1  2
$ cat f2

a
row1f2  1
row1f2  11
urow2   f2  2
$ join f? -e sus -o 0,1.1,1.2,1.3,2.1,2.2,2.3 -t '  '
sus sus sus sus sus sus sus
sus sus sus sus sus a   sus
sus sus b   sus sus sus sus
sus sus b   sus sus a   sus
row1row1f1  1   row1f2  1
row1row1f1  1   row1f2  11
row1row1f1  11  row1f2  1
row1row1f1  11  row1f2  11

The first two rows of f? have an empty field 1.
The first row has no field 2, and the second row has field 2 of "a"/"b".

Compare FreeBSD join
$ join  -e sus -o 0,1.1,1.2,1.3,2.1,2.2,2.3 -t '' f?
sus sus sus sus
sus sus a   sus
b   sus sus sus
b   sus a   sus
row1row1f1  1   row1f2  1
row1row1f1  1   row1f2  11
row1row1f1  11  row1f2  1
row1row1f1  11  row1f2  11
which correctly distinguished the empty field from a missing one.

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9+deb12u4
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

b
row1f1  1
row1f1  11
urow1   f1  2

a
row1f2  1
row1f2  11
urow2   f2  2


signature.asc
Description: PGP signature