Bug#1056383: effect of patch of pulseaudio

[Chris Vogel]

I've been running the patched version of pulseaudio for a few days now.

Open memfd for the software I'm using are staying a lot lower except for 
gnome-shell:

`lsof | grep 'memfd:pulseaudio (deleted)' | cut -c1-16 | sort | uniq -c | sort 
-n`

gives me

```
  3 callaudio 47850
 10 gsd-media 47461
 25 dino-im   51472
 27 nheko 49733
123 firefox-b 47974
167 thunderbi 34794
188 thunderbi 50508
208 firefox-b 48541
500 firefox-b 48996
   1681 gnome-she 47208
```

The numbers above accumulated during 7 days uptime. Applications have not been 
restarted. The open memfds for gnome-shell look like this:

`gnome-she 47208   user   81u  REG
0,167108864 180957 /memfd:pulseaudio (deleted)`

Bug#1057371: bash completion for fscrypt

[Max Nikulin]

Package: fscrypt
Version: 0.3.3-1+b6
Severity: wishlist

Please, add the bash completion file to the fscrypt package.
It is available in the package sources, see
https://sources.debian.org/src/fscrypt/0.3.3-1/cmd/fscrypt/fscrypt_bash_completion/
it should be installed to
/usr/share/bash-completion/completions/fscrypt

As a workaround users may put it to
~/.local/share/bash-completion/completions/fscrypt
for a while.

Bug#1057370: lxqt: mouse not working properly

[Jeroen Diederen]

Package: lxqt-core
Version: 32
Severity: important
File: lxqt
X-Debbugs-Cc: jjhdiede...@zonnet.nl




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

Kernel: Linux 6.5.0-5-powerpc64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxqt-core depends on:
ii  desktop-file-utils  0.27-1
ii  lxqt-config 1.3.0-1
ii  lxqt-globalkeys 1.3.0-1
ii  lxqt-notificationd  1.3.0-1
ii  lxqt-panel  1.3.0-1
ii  lxqt-policykit  1.3.0-1
ii  lxqt-qtplugin   1.3.0-2
ii  lxqt-runner 1.3.0-1
ii  lxqt-session1.3.0-1
ii  lxqt-system-theme   1.3.0-1
ii  lxqt-theme-debian [lxqt-theme]  0.14.0.4
ii  lxqt-themes [lxqt-theme]1.3.0-1
ii  pcmanfm-qt  1.3.0-3
ii  qterminal   1.3.0-1

Versions of packages lxqt-core recommends:
ii  featherpad1.4.1-1
ii  lximage-qt1.3.0-3
ii  lxqt-about1.3.0-2
ii  lxqt-branding-debian [lxqt-branding]  0.14.0.4
ii  lxqt-powermanagement  1.3.0-1
ii  lxqt-sudo 1.3.0-2
ii  pavucontrol   5.0-2
ii  qlipper   1:5.1.2-2
ii  qps   2.7.0-1
ii  qttranslations5-l10n  5.15.10-2
ii  xarchiver 1:0.5.4.21-2
ii  xscreensaver  6.06+dfsg1-3

Versions of packages lxqt-core suggests:
pn  feathernotes  
pn  lxqt  
pn  lxqt-openssh-askpass  
ii  lynx [www-browser]2.9.0dev.12-1
ii  preload   0.6.4-5
ii  w3m [www-browser] 0.5.3+git20230121-2

-- no debconf information
I am using LXQt on an iMac G5 with Debian sid ppc64 as system. The mouse does 
not work properly in the menu. One can click the menu but can then not browse 
through either by following the links or by clicking.
The same problem is encountered in the panel. Only with the arrow keys and 
enter key choices can be made. The only way to exit these windows is by using 
the ESC key. It is making this DE a no go for PowerPC users.

Regards,
Jeroen Diederen

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Martin-Éric Racine]

On Sat, Dec 2, 2023 at 8:20 PM Francesco Poli  wrote:
>
> On Mon, 27 Nov 2023 11:12:45 +0200 Martin-Éric Racine wrote:
>
> > On Sat, 25 Nov 2023 00:38:25 +0100 Francesco Poli
> >  wrote:
> > > On Thu, 23 Nov 2023 14:00:12 +0200 Martin-Éric Racine wrote:
> [...]
> > > > You might wanna check whether Rocky Linux has patched their DHCP
> > > > clients or altered their default dhcpcd.conf to make this succeed. If
> > > > that's the case, please point me to the relevant changes.
> > >
> > > AFAICT, the Rocky Linux machine has the ISC DHCP client
> > > and /etc/resolv.conf is written by a script /usr/sbin/dhclient-script,
> > > which obtains data from the ISC DHCP client.
> >
> > That's not what I asked.
>
> I am sorry, if I misunderstood your request.
> I thought you were asking to be pointed to changes relevant to dhcpcd.

To dhcpcd, not ISC dhclient.

> What I am sure is that dhcpcd (but also isc-dhcp-client) in Debian
> failed to get the two search domains provided by the DHCP server in the
> domain search list (DHCP option 119), while a Rocky Linux ISC DHCP
> client and a Windows client correctly got the two search domains.

That was already understood.

> As far as I understand, isc-dhcp-client is EOL and will be removed from
> Debian in the near future.

Which is completely irrelevant to this bug.

Martin-Éric

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Andreas Tille]

Hi,

Am Sun, Dec 03, 2023 at 09:51:38PM +0100 schrieb Paul Gevers:
> 
> And it also means that r-bioc-biocgenerics is now blocked on the haskell
> transition. Lovely. Good thing that pandoc is supposed to be the last piece
> in that several months long transition.

... which on the other hand shows, that new packages have never been the
main blocker in r-bioc-* transitions (even if I confirm I'm happy that
you convinced us to get rid of this reason).

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1053086: Additional information

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this
issue?

  Note: I would like to upgrade WEKA to the latest stable, but it will
require some effort due to the dependencies.

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/weka/-/merge_requests/2

Bug#1057369: otpclient is producing incorrect codes

[Alex Margolis]

Package: otpclient
Version: 3.2.1-1.1
Severity: important
X-Debbugs-Cc: alexmargo...@yahoo.co.uk

Hi,

OTPclient seems to be producing incorrect codes due to the update of libcotp to 
2.1.0-1. See https://github.com/paolostivanin/OTPClient/issues/325.  The debian 
package needs to be rebuilt against this newer version.

Best,
Alex

Bug#1049493: ssvnc: Fails to build binary packages again after successful build

[Vladimir Petko]

Dear Maintainer,

 Would it be possible to consider the attached debiff as the solution for
this bug?

Best Regards,
 Vladimir.


ssvnc_1.0.29-6_to_1.0.29-7.debdiff
Description: Binary data

Bug#1053079: slashtime: FTBFS with default Java 21

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this
issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/slashtime/-/merge_requests/1

Bug#1000044: ccze: depends on obsolete pcre3 library

[Axel Beckert]

Control: tag -1 - pending

Hi Yavor,

Yavor Doganov wrote:
> Please find a patch attached (I was not able to test all plugins).

Thanks again for that huge patch. I've pushed it and several other
changes to Salsa.

A local test on my /var/log/syslog immediately ran into a segfault,
though, so I guess, that's one of the plugins you couldn't test.

Culprit is this line, actually the first line in my current /var/log/syslog:

  Dec  3 06:38:28 c6 syslog-ng[26651]: Configuration reload request received, 
reloading configuration;

Example for a minimal reproducer:

  $ echo 'Dec  3 06:38:28 c6 syslog-ng[26651]: Configuration reload request 
received, reloading configuration;' | ccze -A
  free(): invalid pointer
  [1]17679 done   echo  |
 17680 IOT instruction (core dumped)  ccze -A

A backtrace of the core dump gave the following output:

  #0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
  #1  0x77d1c15f in __pthread_kill_internal (signo=6, 
threadid=) at ./nptl/pthread_kill.c:78
  #2  0x77cce472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
  #3  0x77cb84b2 in __GI_abort () at ./stdlib/abort.c:79
  #4  0x77cb91ed in __libc_message (fmt=fmt@entry=0x77e2b78c 
"%s\n") at ../sysdeps/posix/libc_fatal.c:150
  #5  0x77d25a75 in malloc_printerr (str=str@entry=0x77e2922c 
"free(): invalid pointer") at ./malloc/malloc.c:5658
  #6  0x77d277f4 in _int_free (av=, p=, 
have_lock=have_lock@entry=0) at ./malloc/malloc.c:4432
  #7  0x77d2a16f in __GI___libc_free (mem=mem@entry=0x55566c08) at 
./malloc/malloc.c:3367
  #8  0x77c7b393 in ccze_syslog_process (offsets=0x5556e170) at 
./src/mod_syslog.c:63
  #9  ccze_syslog_handle (str=, length=, 
rest=0x7fffd9a8) at ./src/mod_syslog.c:126
  #10 0xaa1f in ccze_plugin_run 
(pluginset=pluginset@entry=0x5556ad30, subject=subject@entry=0x555609c0 
"Dec  3 06:38:28 c6 syslog-ng[26651]: Configuration reload request received, 
reloading configuration;", subjlen=100, rest=rest@entry=0x7fffd9a8, 
type=type@entry=CCZE_PLUGIN_TYPE_FULL, 
  handled=handled@entry=0x7fffd984, status=0x7fffd988) at 
./src/ccze-plugin.c:327
  #11 0x8696 in ccze_main () at ./src/ccze.c:706
  #12 main (argc=, argv=) at ./src/ccze.c:753

Seems to be the "free(process)" in line 63 of src/mod_syslog.c. But
neither commenting it out (which might have caused a memory leak) nor
replacing it with "pcre2_substring_free(process)" (as present
elsewhere shortly afterwards is this file) did fix the segfault. It
just started to look different, so the latter might be part of the
fix, but in that case it's is not the complete fix .

I currently assume that any line starting with a date and then a
process name with process id in brackets will trigger this as it's the
parsing of the process id inside the brackets where the crash happens.

So in case you have an idea how to fix this, I'd be happy.

(As mentioned elsewhere already, this migration is a huge PCRE
upstream mess and I'm glad about any help as this is not my only
package affected.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1043334: urlview is insecure: URL visible to everyone with commands like ps

[наб]

Control: tags -1 + fixed-upstream

On Wed, Aug 09, 2023 at 11:18:31AM +0200, Vincent Lefevre wrote:
> Package: urlview
> 
> So it should provide a way to pass the URL via a pipe. For instance,
> this can be useful with xclip (the user can then paste the URL to the
> web browser).
Agree, this would be quite useful in general.

> Moreover, when the URL is to be passed as an arguemnt, a warning
> should be displayed by default about this issue.
Disagree an additional warning is needed, urlview already writes
"Executing: www-browser 'URL'...", so this is blatantly obvious.
But, sure, this can warrant a note in the manual.

https://git.sr.ht/~nabijaczleweli/urlview-ng/commit/88a54e2ca0e86cce1fc62e264a822a5cb7d528ae
adds a VIA config option;
what you describe can be done by setting
"VIA pipe" and "COMMAND xclip"
   (or "COMMAND xclip -selection clipboard", or whatever).

Best,
наб


signature.asc
Description: PGP signature

Bug#1034398: ccze: Project homepage on github no longer exists / abandoned upstream?

[Axel Beckert]

Control: tag -1 + pending

Hi Nika,

Michael Prokop wrote:
> https://github.com/madhouse/ccze throws a 404,

Yeah, I know. I think this was a reaction on Microsoft buying Github.

> maybe https://git.madhouse-project.org/archive/ccze
> is the proper place to refer to nowadays,

Thanks for that link! I knew it was on
https://git.madhouse-project.org/algernon/ccze before and then
suddenly vanished there, too, which was very weird …

> but it looks like the project was abandoned / is unmaintained from
> upstream?

… because when I took over the package from Gergely (upstream and
previous package maintainer), he promised me to still fix severe
issues like security issues. Completely removing the source code repo
did not fit into that statement. So it's just another case showing
that changing URLs for repos is a really bad idea. But I guess Forgejo
doesn't have a repo flag "archived" so Gergely helped himself that
way.

Wanted to contact him for the PCRE2 migration (and my motivation on
this was rather low as that whole PCRE2 "migration" was a real mess at
PCRE upstream), but Yavor was quicker with sending in a patch.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1057368: git-delta - updates for new rust-libgit2-sys and rust-bat

[Peter Michael Green]

Package: git-delta
Version: 0.16.5-3

Due to the recent upload of libgit2, I have just uploaded
new versions of rust-libgit2-sys, rust-git2 and a number
of their reverse dependencies.

We enforce a version match (at the major.minor level)
between the rust libgit2 bindings and the libgit2
libraries because we have seen mismatches cause
runtime misbehaviour in the past.

Your package build-depends on two packages which
have bumped semver as part of this update, rust-git2
and rust-bat. The upstream changelogs don't look too
scary and your package built succesfully with the
dependencies bumped. I have attatched a debdiff.

Sorry for the lack of prior warning on this one, we should
have engaged with the libgit2 maintainer earlier, but
noone got around to it and the libgit2 maintainer
and release team eventually went ahead without
waiting for us.
diff -Nru git-delta-0.16.5/debian/changelog git-delta-0.16.5/debian/changelog
--- git-delta-0.16.5/debian/changelog   2023-08-09 08:27:30.0 +
+++ git-delta-0.16.5/debian/changelog   2023-12-03 13:41:55.0 +
@@ -1,3 +1,10 @@
+git-delta (0.16.5-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump git2 to 0.18 and bat to 0.24.
+
+ -- Peter Michael Green   Sun, 03 Dec 2023 13:41:55 +
+
 git-delta (0.16.5-3) unstable; urgency=medium
 
   * mention unrelated but similarly named package and binary executable
diff -Nru git-delta-0.16.5/debian/control git-delta-0.16.5/debian/control
--- git-delta-0.16.5/debian/control 2023-08-09 07:25:59.0 +
+++ git-delta-0.16.5/debian/control 2023-12-03 13:41:55.0 +
@@ -12,7 +12,7 @@
  librust-ansi-term-0.12+default-dev,
  librust-anyhow-1+default-dev,
  librust-atty-0.2+default-dev,
- librust-bat-0.23+regex-onig-dev,
+ librust-bat-0.24+regex-onig-dev,
  librust-bitflags-2+default-dev,
  librust-box-drawing-0.1+default-dev,
  librust-bytelines-2+default-dev,
@@ -27,7 +27,7 @@
  librust-console-0.15+default-dev,
  librust-ctrlc-3+default-dev,
  librust-dirs-5+default-dev,
- librust-git2-0.16-dev,
+ librust-git2-0.18-dev,
  librust-grep-cli-0.1+default-dev,
  librust-itertools-0.10+default-dev,
  librust-lazy-static-1+default-dev,
diff -Nru git-delta-0.16.5/debian/patches/1001_deps.patch 
git-delta-0.16.5/debian/patches/1001_deps.patch
--- git-delta-0.16.5/debian/patches/1001_deps.patch 2023-08-07 
16:17:37.0 +
+++ git-delta-0.16.5/debian/patches/1001_deps.patch 2023-12-03 
13:41:55.0 +
@@ -10,7 +10,7 @@
  
  [dependencies]
 -bat = { version = "0.22.1", default-features = false, features = 
["regex-onig"] }
-+bat = { version = ">= 0.22.1, < 0.24", default-features = false, features = 
["regex-onig"] }
++bat = { version = ">= 0.22.1, < 0.25", default-features = false, features = 
["regex-onig"] }
  chrono = "0.4.23"
  chrono-humanize = "0.2.2"
 -ansi_colours = "1.2.1"
@@ -49,7 +49,7 @@
  
  [dependencies.git2]
 -version = "0.16.1"
-+version = "0.16"
++version = "0.18"
  default-features = false
  features = []
  

Bug#1056897: [3dprinter-general] Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files?=()=?UTF-8?Q?’ is ambiguous

[Gregor Riepl]

Gah, looks like some arch-dependent glitch. Which explains why it didn't 
happen to either of us (we probably both used amd64 machines, I 
definitely did) and then the failure did happen upon publishing.


Thanks for your help, I'll try to help get the next fix in once it's ready.


Ok, so I have a preliminary status report.

I debugged the issue on i386 first, because that's the easiest to do 
with standard PC hardware.
In contrast with the other architectures, the value reported by the 
failed unit test is off by several orders of magnitude on i386, while it 
seems to be "only" a sign issue on other architectures.


I've isolated the issue to make debugging easier, and that revealed 
incomplete initialization of the Slic3r::arr2::GravityKernel object - 
this object is allocated on the stack by the unit test, and while the 
constructors of all fields are called, the field active_sink remains 
uninitialized.


This is apparently by design, as stated in the Eigen documentation (the 
LA library used by Slicer):

https://eigen.tuxfamily.org/dox/group__TutorialMatrixClass.html

> A default constructor is always available, never performs any dynamic 
memory allocation, and **never initializes the matrix coefficients**.


So, this is most definitely a bug in PrusaSlicer, because it doesn't 
explicitly assign an initial value to 
Slic3r::arr2::GravityKernel.active_sink - but uses it later anyway.


I don't know why this only causes issues on i386, but it's certainly 
dangerous on all architectures.


The fix quite easy, though.
Modify line 20 and 21 in 
src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp as follows:


-GravityKernel(Vec2crd gravity_center) : sink{gravity_center} {}
-GravityKernel() = default;
+GravityKernel(Vec2crd gravity_center) : sink{gravity_center}, 
active_sink{0, 0} {}

+GravityKernel() : active_sink{0, 0} {};

I'll file separate bug report + corresponding upstream report later.

Now, I don't know if this will fix the issues on the other 
architectures, but I'll try to reproduce them on an arm64 device at 
least. It's very likely that the issue is the same everywhere.

Bug#1000035: RC: ezquake: depends on obsolete pcre3 library

[Alexandre Detiste]

control: tag -1 +fixed-upstream

I've import 3.6.4 on Salsa

Bug#1055624: viking: Segmentation fault when quitting viking

[Vincent Lefevre]

Control: tags -1 upstream fixed-upstream patch

On 2023-11-09 08:49:50 +0100, Paul Gevers wrote:
> Control: forwarded -1 https://github.com/viking-gps/viking/issues/202
> 
> Hi,
> 
> Thanks. I have forwarded the issue upstream.

I've attached a patch. This is the upstream patch by Rob Norris

  https://github.com/viking-gps/viking/commit/21ecac2

which I ported for viking 1.10 in Debian 12:

* 2 hunks were rejected in src/vikmapslayer.c due to changes in
  reindented code (I just had to re-add the "if").

* the compilation was failing due to undefined variable dr,
  so I just had to take the current code at this point, giving
  this simple change in src/vikmapslayer.c:

+DownloadResult_t dr = DOWNLOAD_NOT_REQUIRED;
 if (need_download) {
-  DownloadResult_t dr = vik_map_source_download( 
MAPS_LAYER_NTH_TYPE(mdi->maptype), &(mdi->mapcoord), mdi->filename_buf, handle);
+  dr = vik_map_source_download( MAPS_LAYER_NTH_TYPE(mdi->maptype), 
&(mdi->mapcoord), mdi->filename_buf, handle);

I've done several tests, and everything is now fine on my machine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: avoid segmentation fault on map download when quitting
Bug-Debian: https://bugs.debian.org/1055624
Forwarded: https://github.com/viking-gps/viking/issues/202

Index: viking-1.10/src/curl_download.c
===
--- viking-1.10.orig/src/curl_download.c
+++ viking-1.10/src/curl_download.c
@@ -249,6 +249,8 @@ CURL_download_t curl_download_uri ( cons
   g_warning("%s: http response: %ld for uri %s", __FUNCTION__, response, 
uri);
   res = CURL_DOWNLOAD_ERROR;
 }
+  } else if (res == CURLE_ABORTED_BY_CALLBACK) {
+res = CURL_DOWNLOAD_ABORTED;
   } else {
 g_warning ( "%s: curl error: %d for uri %s", __FUNCTION__, res, uri );
 res = CURL_DOWNLOAD_ERROR;
Index: viking-1.10/src/curl_download.h
===
--- viking-1.10.orig/src/curl_download.h
+++ viking-1.10/src/curl_download.h
@@ -32,7 +32,8 @@ G_BEGIN_DECLS
 typedef enum {
   CURL_DOWNLOAD_NO_ERROR = 0,
   CURL_DOWNLOAD_NO_NEWER_FILE,
-  CURL_DOWNLOAD_ERROR
+  CURL_DOWNLOAD_ERROR,
+  CURL_DOWNLOAD_ABORTED
 } CURL_download_t;
 
 typedef struct {
Index: viking-1.10/src/download.c
===
--- viking-1.10.orig/src/download.c
+++ viking-1.10/src/download.c
@@ -401,7 +401,11 @@ static DownloadResult_t download( const
 
   DownloadResult_t result = DOWNLOAD_SUCCESS;
 
-  if (ret != CURL_DOWNLOAD_NO_ERROR && ret != CURL_DOWNLOAD_NO_NEWER_FILE) {
+  if (ret == CURL_DOWNLOAD_ABORTED) {
+g_debug("%s: download aborted: curl_download_get_url=%d", __FUNCTION__, 
ret);
+failure = TRUE;
+result = DOWNLOAD_USER_ABORTED;
+  } else if (ret == CURL_DOWNLOAD_ERROR) {
 g_debug("%s: download failed: curl_download_get_url=%d", __FUNCTION__, 
ret);
 failure = TRUE;
 result = DOWNLOAD_HTTP_ERROR;
Index: viking-1.10/src/download.h
===
--- viking-1.10.orig/src/download.h
+++ viking-1.10/src/download.h
@@ -107,6 +107,7 @@ typedef enum {
   DOWNLOAD_CONTENT_ERROR = -1,
   DOWNLOAD_SUCCESS = 0,
   DOWNLOAD_NOT_REQUIRED = 1, // Also 'successful'. e.g. Because file already 
exists and no time checks used
+  DOWNLOAD_USER_ABORTED = 2, // Not an error, but not really successful either 
- no actual download completed
 } DownloadResult_t;
 
 /* TODO: convert to Glib */
Index: viking-1.10/src/vikdemlayer.c
===
--- viking-1.10.orig/src/vikdemlayer.c
+++ viking-1.10/src/vikdemlayer.c
@@ -1348,6 +1348,7 @@ static void srtm_dem_download_thread ( D
 }
 case DOWNLOAD_SUCCESS:
 case DOWNLOAD_NOT_REQUIRED:
+case DOWNLOAD_USER_ABORTED:
 default:
   break;
   }
Index: viking-1.10/src/vikmapslayer.c
===
--- viking-1.10.orig/src/vikmapslayer.c
+++ viking-1.10/src/vikmapslayer.c
@@ -359,6 +359,7 @@ void maps_layer_uninit ()
 {
   vik_mutex_free ( rq_mutex );
   g_hash_table_destroy ( requests );
+  rq_mutex = NULL;
 }
 
 //
@@ -447,10 +448,15 @@ gboolean req_hash_remove_id  (gpointer k
 
 static void requests_clear ( guint maptype )
 {
-  guint id = vik_map_source_get_uniq_id ( MAPS_LAYER_NTH_TYPE(maptype) );
-  g_mutex_lock ( rq_mutex );
-  g_hash_table_foreach_remove ( requests, req_hash_remove_id, 
GUINT_TO_POINTER(id) );
-  g_mutex_unlock ( rq_mutex );
+  // Ensure mutex (and therefore hash) is available
+  //  as can become unavailable on program exit
+  //  yet this function may still be called from existing threads
+  if ( rq_mutex ) {
+guint id = 

Bug#1057367: ITP: cc-cedict -- Chinese-English dictionary for the dict server/client

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: cc-cedict
  Version : 0.0.20231203
  Upstream Contact: https://www.mdbg.net/chinese/dictionary?page=contact
* URL : https://www.mdbg.net/chinese/dictionary?page=cedict
* License : CC-BY-SA 4.0
  Description : Chinese-English dictionary for the dict server/client
  This is Chinese-English dictionary from the CC-CEDICT project. It contains
  around 122247 headwords. It can be either used with dictd server and
  a dict client or with GoldenDict.




OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057366: ITP: wfx -- A lightweight, general-purpose workflow executor

[Nobuhiro Iwamatsu]

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

* Package name: wfx
  Version : 0.1.0
  Upstream Contact: Michael Adler 
* URL : https://github.com/siemens/wfx
* License : Apache 2.0
  Programming Lang: Go
  Description : A lightweight, general-purpose workflow executor

  Wfx provides lightweight servers and clients to manage workflows.
  Workflows are modeled as finite-state machines and are instantiated as
  jobs through which the wfx and a client progress in lock-step to
  perform a task. Such a task could be software updating the client,
  progressing a work item through Kanban, in essence anything requiring
  cooperation and coordination.

Bug#1057365: unicode-cldr-core: Please update to version 44

[Jeremy Bícha]

Source: unicode-cldr-core
Version: 41-0.1
Severity: wishlist
X-Debbugs-CC: b...@debian.org

Please update unicode-cldr-core to version 44 which corresponds with
Unicode 15.1.

ibus has an emoji chooser feature but Debian's ibus package needs
unicode-cldr-core to be updated first before ibus can be rebuilt to
include the latest emoji.

Thank you,
Jeremy Bícha

Bug#1057360: python-pyscss: PCRE support missing due to incomplete migration

[Stefano Rivera]

Hi Boyuan (2023.12.03_23:15:02_+)
> The packaged python-pyscss/1.4.0-3 claimed to migrate from PCRE to PCRE2. 
> However,
> the project has not supported PCRE2 yet [1]. The current migration [2] 
> effectively
> disabled the PCRE support as shown in build logs.
> 
> As a result, we should not claim to have migrated from old PCRE to PCRE2, and 
> we
> should enable PCRE2 support in the future once upstream has made the switch.

It's not clear to me what the next steps you're asking for entail.

Can you provide patches?

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1057313: racket: Please build and install Zuo

[David Bremner]

G. Weinholt  writes:


> I mean, I could easily package Zuo separately. I could do the first
> upload and put the Scheme team as maintainer so anyone who needs to can
> update it. I'm guessing you would still use the copy that comes as part
> of Racket to build Racket, though.
>

Sure, don't let me stand in the way. Maybe when things stabilize we can
eliminate the duplication / embedding.

d

Bug#1057364: mate-panel: weather report broken in clock/weather applet in bookworm

[mike]

Package: mate-panel
Version: 1.27.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,

like the title says.

It would be nice to backport the fix.

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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgtk-layer-shell0  0.8.0-1
ii  libice6  2:1.0.10-1
ii  libmate-desktop-2-17 1.26.0-2
ii  libmate-menu21.26.0-3
ii  libmate-panel-applet-4-1 1.27.0-1
ii  libmateweather1  1.26.0-1.1
ii  libpango-1.0-0   1.50.12+ds-1
ii  librda0  0.0.5-1.1
ii  libsm6   2:1.2.3-1
ii  libwayland-client0   1.21.0-1
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxrandr2   2:1.5.2-2+b1
ii  mate-desktop 1.26.0-2
ii  mate-menus   1.26.0-3
ii  mate-panel-common1.27.0-1
ii  mate-polkit  1.26.1-3

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#1057363: RM: twitterwatch -- RoQA; Upstream Dead; Useless with Twitter API Changes

[Boyuan Yang]

Package: ftp.debian.org
Control: affects -1 + src:twitterwatch
X-Debbugs-Cc: twitterwa...@packages.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: by...@debian.org cha...@debian.org nomad...@debian.org
Severity: normal

Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/1056613 , package twitterwatch makes use
of Twitter API, which is gone since 2023. Its upstream shows no activity for 7 
years,
and the Debian package received no maintainer updates since 2016. As a result, I
believe we should have package twitterwatch removed from Debian archive.

Thanks,
Boyuan Yang


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

Bug#1057362: lives: depends on libavutil56 which is not available in stable or unstable anymore

[Alban Browaeys]

Package: lives
Version: 3.0.2-1.2
Severity: grave
Justification: renders package unusable

Dear Maintainer,
I cannot install lives on a bookworm system as it depends on libvutil56
which is not anymore in Debian stable or unstable repositories.

Cheers,
Alban

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

Kernel: Linux 6.7.0-rc2+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 lives depends on:
ii  imagemagick   8:6.9.12.98+dfsg1-4
ii  imagemagick-6.q16 [imagemagick]   8:6.9.12.98+dfsg1-4
ii  libasound21.2.10-1
ii  libatk1.0-0   2.50.0-1
ii  libavc1394-0  0.5.4-5
ii  libavutil56   7:4.3.6-0+deb11u1
ii  libc6 2.37-12
ii  libcairo-gobject2 1.18.0-1
ii  libcairo2 1.18.0-1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3
ii  libgdk-pixbuf2.0-02.40.2-3
ii  libglib2.0-0  2.78.1-4
ii  libgtk-3-03.24.38-6
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  libmjpegutils-2.1-0   1:2.1.0+debian-8
ii  libpango-1.0-01.51.0+ds-3
ii  libpangocairo-1.0-0   1.51.0+ds-3
ii  libpng16-16   1.6.40-2
ii  libpulse0 16.1+dfsg1-2+b1
ii  libraw1394-11 2.1.2-2
ii  libswscale5   7:4.3.6-0+deb11u1
pn  libunicap2
pn  libweed0  
ii  libx11-6  2:1.8.7-1
pn  lives-data
pn  lives-plugins 
ii  mplayer   2:1.5+svn38423-2+b1
ii  mpv   0.36.0-1+b1
pn  ogmtools  
ii  perl  5.36.0-10
ii  procps2:4.0.4-2
ii  sox   14.4.2+git20190427-4
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages lives recommends:
ii  dvgrab  3.5+git20160707.1.e46042e-1+b1
ii  ffmpeg  7:6.1-3
ii  frei0r-plugins  1.8.0-1+b1
pn  icedax  
pn  libtheora-bin   
ii  mencoder2:1.5+svn38423-2+b1
ii  mkvtoolnix  80.0-1
pn  pulseaudio  
ii  x11-utils   7.7+6
pn  youtube-dl  

Versions of packages lives suggests:
pn  libdv-bin   
pn  mjpegtools  

Bug#1057361: ITP: pickle-secure -- wrapper around pickle that creates encrypted pickles

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
Control: blocks 1019277 by -1

Package Name: pickle-secure
Version: 0.99.9
Upstream Author: Stephanos Kuma 
License: LGPL-3
Programming Lang: Python 3

Description: wrapper around pickle that creates encrypted pickles
 pickle-secure offers a similar API as the built-in pickle.

This is a (build) dependency for Slidge.

Bug#906725: urlview: please lower sensible-utils dependency to Recommends, as just needed in the default config

[наб]

Control: tags -1 + fixed-upstream

On Mon, Aug 20, 2018 at 10:23:59AM +0200, Vincent Lefevre wrote:
> Package: urlview
> 
> The dependency on sensible-utils is too strong, as sensible-browser is
> just used by /etc/urlview/url_handler.sh, which is a config file; the
> handler can also be changed in /etc/urlview/system.urlview (COMMAND).
Agree with your assessment
(plus, even in the default config,
 sensible-browser is part of a fallback group).

> Thus is should just be a Recommends.
Applied in
  
https://git.sr.ht/~nabijaczleweli/urlview.deb/commit/ab7c83ebf2a4f023866b689278c565f620d9e7bb

Best,
наб


signature.asc
Description: PGP signature

Bug#1054268: mate-applets: same in stable bookworm

[mike]

Package: mate-applets
Version: 1.26.1-1
Followup-For: Bug #1054268
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,

There's the same problem in bookworm. Can you please backport the fix?

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

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

Versions of packages mate-applets depends on:
ii  gsettings-desktop-schemas  43.0-1
ii  gvfs   1.50.3-1
ii  libatk1.0-02.46.0-5
ii  libc6  2.36-9+deb12u3
ii  libcairo2  1.16.0-7
ii  libcpupower1   6.1.55-1
ii  libdbus-glib-1-2   0.112-3
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libgtksourceview-3.0-1 3.24.11-2+b1
ii  libgtop-2.0-11 2.40.0-2
ii  libgucharmap-2-90-71:15.0.2-1
ii  libmate-panel-applet-4-1   1.27.0-1
ii  libmateweather11.26.0-1.1
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1
ii  libnotify4 0.8.1-1
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpangocairo-1.0-01.50.12+ds-1
ii  libpolkit-gobject-1-0  122-3
ii  libupower-glib30.99.20-2
ii  libwnck-3-043.0-3
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  mate-applets-common1.26.1-1
ii  mate-panel 1.27.0-1
ii  sgml-base  1.31

Versions of packages mate-applets recommends:
ii  mate-media   1.26.0-2
ii  mate-polkit  1.26.1-3
ii  mate-system-monitor  1.26.0-1

mate-applets suggests no packages.

-- no debconf information

Bug#1057155: vonsh REJECT on amd64

[Bastian Germann]

I am uploading a NMU in order to fix this.
The debdiff is attached.diff -Nru vonsh-1.0/debian/changelog vonsh-1.0+ds/debian/changelog
--- vonsh-1.0/debian/changelog  2023-10-23 00:25:29.0 +0200
+++ vonsh-1.0+ds/debian/changelog   2023-12-03 22:34:55.0 +0100
@@ -1,3 +1,13 @@
+vonsh (1.0+ds-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary version constraints for Build-Dependencies.
+  * debian/copyright: Align license names with Debian requirements.
+  * Add version suffix +ds to make the version greater than bookworm's.
+(Closes: #1057155)
+
+ -- Bastian Germann   Sun, 03 Dec 2023 22:34:55 +0100
+
 vonsh (1.0-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru vonsh-1.0/debian/control vonsh-1.0+ds/debian/control
--- vonsh-1.0/debian/control2023-10-23 00:25:26.0 +0200
+++ vonsh-1.0+ds/debian/control 2023-12-03 22:34:41.0 +0100
@@ -2,7 +2,7 @@
 Section: games
 Priority: optional
 Maintainer: Andrzej Urbaniak 
-Build-Depends: debhelper (>= 12), libsdl2-dev (>=2.0.9), libsdl2-image-dev 
(>=2.0.4), libsdl2-mixer-dev (>=2.0.4)
+Build-Depends: debhelper (>= 12), libsdl2-dev, libsdl2-image-dev, 
libsdl2-mixer-dev
 Standards-Version: 4.3.0
 Homepage: https://github.com/aurb/vonsh/
 
diff -Nru vonsh-1.0/debian/copyright vonsh-1.0+ds/debian/copyright
--- vonsh-1.0/debian/copyright  2019-08-25 10:40:07.0 +0200
+++ vonsh-1.0+ds/debian/copyright   2023-12-03 22:34:55.0 +0100
@@ -5,7 +5,7 @@
 
 Files: *
 Copyright: 2019 Andrzej Urbaniak
-License: MIT
+License: Expat
  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to deal
  in the Software without restriction, including without limitation the rights
@@ -26,7 +26,7 @@
 
 Files: inc/pcg_basic.h src/pcg_basic.c
 Copyright: 2014 Melissa O'Neill 
-License: Apache-License-Version-2.0
+License: Apache-2.0
  /usr/share/common-licenses/Apache-2.0
 
 Files: usr/share/games/vonsh/board_tiles.png

Bug#1013554: Fixing in bullseye

[Santiago Vila]

Version: 0.0~git20210309.652d3b4-2

Hello.

For a long time, I was doing archive rebuilds using an absolutely
minimal /etc/hosts file with only two lines: one for localhost
and another one for the hostname.

After I added the IPv6 lines that debian-installer creates
by default, several packages which mysteriously FTBFS for me
for unknown reasons (like this one) suddenly started to build ok.

This allowed me to remove those packages from my "list of packages
which FTBFS", without even reporting the problem as a bug and of course
without making any upload.

I think this is the optimal thing to do in this particular case,
so I no longer see the need to make any upload for bullseye.

The package effectively builds ok in bullseye for me, and I believe
it would also build ok in the setup used by Lucas these days.

Thanks.

Bug#1057360: python-pyscss: PCRE support missing due to incomplete migration

[Boyuan Yang]

Source: python-pyscss
Version: 1.4.0-3
Tags: sid
X-Debbugs-CC: z...@debian.org stefa...@debian.org

Hi,

The packaged python-pyscss/1.4.0-3 claimed to migrate from PCRE to PCRE2. 
However,
the project has not supported PCRE2 yet [1]. The current migration [2] 
effectively
disabled the PCRE support as shown in build logs.

As a result, we should not claim to have migrated from old PCRE to PCRE2, and we
should enable PCRE2 support in the future once upstream has made the switch.

Thanks,
Boyuan Yang


[1] https://github.com/Kronuz/pyScss/issues/429
[2] 
https://salsa.debian.org/python-team/packages/python-pyscss/-/commit/d6c61232d3e33097f73889ed6a3245d35bea17a2


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

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli]

On Sun, 3 Dec 2023 08:06:52 +0200 Martin-Éric Racine wrote:

[...]
> This is the dhcpcd package. Looking for Rocky changes to ISC is irrelevant.

That's exactly what I thought: that is why I initially hadn't pointed
you to any ISC patches... But then you said "That's not what I asked"...

Anyway.

> 
> If you experience issue with dhclient, reassign this bug to isc-dhcp-client.

Please re-read the bug log: I am experiencing an issue on Debian with
both isc-dhcp-client and dhcpcd-base.

Since isc-dhcp-client is EOL and will be removed from Debian in the
near future, I don't think there's any point in investing time on
fixing it.

On the other hand, dhcpcd-base is declared to be a "substitute for ISC
DHCP Client": I would really like to see it fixed and capable of
correctly managing DHCP option 119.
Please forward my bug report upstream, if you think this is an upstream
issue.

Thanks for your time.
Bye.


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


pgpskbyzUeo8z.pgp
Description: PGP signature

Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6

[Alexandre Detiste]

Package: debhelper
Version: 13.11.8
Severity: normal
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org

Hi,

While packaging "xaos" I found out Qt6 integration in debhelper
is not yet quite ready.

The debian/rules is absolute barebones:

> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> export QT_SELECT=qt6
> 
> %:
>dh $@

Yet it fails, when patching qmake.pm by adding a single "6",
it justs works.

Could qmake.pm be made to use "qmake6" when QT_SELECT=qt6 ?

Greetings,


--- /tmp/qmake.pm   2023-12-03 23:45:47.649530519 +0100
+++ /usr/share/perl5/Debian/Debhelper/Buildsystem/qmake.pm  2023-12-03 
23:44:10.180965057 +0100
@@ -97,7 +97,7 @@
if (is_cross_compiling()) {
return dpkg_architecture_value("DEB_HOST_GNU_TYPE") . 
"-qmake";
}
-   return 'qmake';
+   return 'qmake6';
 }

 1

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.1-1
ii  dpkg 1.22.1
ii  dpkg-dev 1.22.1
ii  dwz  0.15-1
ii  file 1:5.45-2
ii  libdebhelper-perl13.11.8
ii  libdpkg-perl 1.22.1
ii  man-db   2.12.0-1
ii  perl 5.36.0-10
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#1057357: qtremoteobjects-everywhere-src: FTBFS in bullseye and bookworm because of expired SSL certificates, will also FTBFS in trixie/sid eventually

[Santiago Vila]

Package: src:qtremoteobjects-everywhere-src
Version: 5.15.2-2
Severity: serious
Tags: ftbfs patch bullseye bookworm upstream

Dear maintainer:

During an archive rebuild of all packages in bookworm,
this package failed to build:

make[4]: Entering directory 
'/<>/tests/auto/external_IODevice/tst_client'
/<>/tests/auto/external_IODevice/tst_client/target_wrapper.sh  
./tst_external_IODevice
* Start testing of tst_clientSSL *
Config: Using QtTest library 5.15.8, Qt 5.15.8 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 12.2.0), debian 12
PASS   : tst_clientSSL::initTestCase()
FAIL!  : tst_clientSSL::testRun() 'socketClient->waitForEncrypted(-1)' returned 
FALSE. ()
   Loc: [tst_client.cpp(77)]
QWARN  : tst_clientSSL::testRun() QProcess: Destroyed while process 
("/<>/tests/auto/external_IODevice/sslTestServer/sslTestServer") 
is still running.
PASS   : tst_clientSSL::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 267ms
* Finished testing of tst_clientSSL *
make[4]: *** [Makefile:356: check] Error 1
make[4]: Leaving directory 
'/<>/tests/auto/external_IODevice/tst_client'
make[3]: *** [Makefile:431: sub-tst_client-check_ordered] Error 2
make[3]: Leaving directory '/<>/tests/auto/external_IODevice'
make[2]: *** [Makefile:1329: sub-external_IODevice-check] Error 2
make[2]: Leaving directory '/<>/tests/auto'
dh_auto_test: error: make -j1 check -Ctests/auto LD_LIBRARY_PATH=/<>/lib 
QML2_IMPORT_PATH=/<>/test_root/usr/lib/x86_64-linux-gnu/qt5/qml returned exit 
code 2
make[1]: *** [debian/rules:31: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:11: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

You can get a full build log from reproducible builds:

https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/qtremoteobjects-everywhere-src.html

This happens because the SSL certificates in the tests have expired.
This can be checked by doing this:

cd tests/auto/external_IODevice/cert
for a in *; do openssl x509 -noout -enddate -in $a; done

The output from bookworm contains this:

notAfter=May 30 11:33:55 2023 GMT
notAfter=Jun 10 11:33:55 2023 GMT
notAfter=May 30 11:33:55 2023 GMT

and the output for bullseye (where it also fails) contains this:

notAfter=Jul  2 09:32:51 2023 GMT
notAfter=Jul  2 09:32:50 2023 GMT
notAfter=Jul  2 09:32:51 2023 GMT

I'm attaching two patches to fix this.

The first one modifies the script tests/auto/external_IODevice/cert/generate.sh
so that certificates expire in ten years.

The second patch is merely the result of running the script.

Note: The patches are relative to the version in trixie/sid,
where this problem should be fixed first.

Thanks.commit 6699c65d1b7a891d16cab082e4e0c7d083568f34
Author: Santiago Vila 
Date:   Sun Dec 3 22:36:00 2023 +0100

generate.sh: Create SSL certificates with a more realistic expiration date.

Ten years will cover the lifetime of this release as stable, oldstable,
LTS, and some additional extra time (there is really no need for the tests
to fail just the day after LTS ends).

diff --git a/tests/auto/external_IODevice/cert/generate.sh b/tests/auto/external_IODevice/cert/generate.sh
index b79c862..2de1651 100644
--- a/tests/auto/external_IODevice/cert/generate.sh
+++ b/tests/auto/external_IODevice/cert/generate.sh
@@ -30,7 +30,7 @@
 # Generate the CA key
 openssl genrsa -out rootCA.key 2048
 # Generate the CA cert
-openssl req -x509 -key rootCA.key -out rootCA.pem -sha256 -nodes -subj "/CN=QtRO CA" -days 836
+openssl req -x509 -key rootCA.key -out rootCA.pem -sha256 -nodes -subj "/CN=QtRO CA" -days 3651
 
 # genFiles stem [extra args to signing]
 genFiles () {
@@ -42,7 +42,7 @@ genFiles () {
 openssl req -new -key $stem.key -out $stem.csr -subj "/CN=127.0.0.1"
 # Generate and sign the certificate
 openssl x509 -req -in $stem.csr -out $stem.crt \
- -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -days 825 -sha256 "$@"
+ -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -days 3650 -sha256 "$@"
 # Delete the signing request, no longer needed
 rm $stem.csr
 }
commit d9da85818f9bf50a72a371eb1453979432902065
Author: Santiago Vila 
Date:   Sun Dec 3 22:44:00 2023 +0100

Regenerate SSL certificates using the updated generate.sh script.

diff --git a/examples/remoteobjects/ssl/sslserver/cert/client.crt b/examples/remoteobjects/ssl/sslserver/cert/client.crt
index ec85263..4622c5d 100644
--- a/examples/remoteobjects/ssl/sslserver/cert/client.crt
+++ b/examples/remoteobjects/ssl/sslserver/cert/client.crt
@@ -1,17 +1,17 @@
 -BEGIN CERTIFICATE-
-MIICrTCCAZUCFHOQggvUf1o8c5i3yNyiGLNcLC4tMA0GCSqGSIb3DQEBCwUAMBIx
-EDAOBgNVBAMMB1F0Uk8gQ0EwHhcNMjMxMjAzMjAwMTQ5WhcNMjYwMzA3MjAwMTQ5
+MIICrTCCAZUCFHOQggvUf1o8c5i3yNyiGLNcLC4vMA0GCSqGSIb3DQEBCwUAMBIx

Bug#1057358: libnfc: needs DEP17 P7 M10 mitigation for moving udev rules to /usr

[Chris Hofstaedtler]

Source: libnfc
Version: 1.8.0-2
User: helm...@debian.org
Usertags: dep17m2
X-Debbugs-CC: Utkarsh Gupta 

Hi,

thanks for fixing the DEP17 P7 problem in experimental (1.8.0-3).
Please make sure the fix also reaches unstable.

Best,
Chris

Bug#1053800: transition: libgit2

[Peter Green]

The Rust Team did not react.


Too bad. Please raise the bug to RC.


Apologies for not engaging with this sooner, I had mentally
filed it as "deal with this once the cargo update is done"
but the cargo update has been taking a lot longer than hoped.

I've uploaded a new version of the rust bindings, this also
involved updating a bunch of other rust packages for the
new version of the rust bindings.

Going through the packages on the transition tracker.
that currently show red x's on architectures other than
mips64el and that have something to do with rust.

git-delta (sid only):
Maintained by Jonas. Will need a sourcefull upload for
semver bumps, I will file a bug once the packages it
depends on are built.

rust-bat:
I've uploaded a fixed package.

rust-cargo-c:
Uses the rust git bindings indirectly, a binnmu should
suffice here.

rust-cargo-outdated:
Doesn't enforce an upper limit on the version of the
git bindings, a binnmu should suffice here.

rust-debcargo:
I've uploaded a fixed package.

rust-exa:
I've Uploaded a fixed package.

rust-ripasso-cursive:
Suffers from unrelated FTBFS issue.

cargo:
f_g has uploaded a fix.

Bug#1040144: Bisect ongoing

[Jérôme]

Issue still present in kernel 6.6 from experimental.

Is there anything I can do to help with this?

-- 
Jérôme

Bug#1038028: astromenace: Depends on SDL 1.2

[Alexandre Detiste]

control: tag -1 +fixed-upstream

Please package v1.4.2 which uses SDL2.

https://github.com/viewizard/astromenace/blob/master/CHANGELOG.md

--

PS: I don't understand now why what's happening in
/var/lib/dpkg/info/astromenace.postinst
cannot be move into astromenace-data debian/rules.
Is it platform dependent?

Bug#1057356: pyjunitxml: FTBFS with Python 3.12

[Bastian Germann]

Source: pyjunitxml
Version: 0.7-2
Severity: serious
X-Debbugs-Cc: rosesecurityresea...@proton.me

The unit tests fail with Python 3.12:

test_xml_output (junitxml.tests.test_runner.TestXMLTestRunner.test_xml_output)
Tests that runner properly gives XML output. ... FAIL

==
FAIL: test_console_output_fail 
(junitxml.tests.test_runner.TestXMLTestRunner.test_console_output_fail)
Tests that failure is reported properly on stderr.
--
Traceback (most recent call last):
  File ".pybuild/cpython3_3.12/build/junitxml/tests/test_runner.py", line 89, in 
test_console_output_fail

self.assertTrue('Ran %d tests in ' % (num_tests,) in value,
AssertionError: False is not true : Output was:
Ran 5 tests in 0.002s

FAILED (failures=1, errors=1, skipped=1, expected failures=1, unexpected 
successes=1)


==
FAIL: test_xml_output 
(junitxml.tests.test_runner.TestXMLTestRunner.test_xml_output)
Tests that runner properly gives XML output.
--
Traceback (most recent call last):
  File ".pybuild/cpython3_3.12/build/junitxml/tests/test_runner.py", line 75, 
in test_xml_output
self.assertEqual(document.documentElement.getAttribute('tests'),
AssertionError: '5' != '6'
- 5
+ 6

Bug#985184: reminiscence: New upstream version available with SDL2 support

[Alexandre Detiste]

Hi,

It also look like this game-engine should be moved to contrib/
because it's only useful with one specific non-free dataset.

The missing data part would be handled by game-data-packager.
(I can handle this part if licensing problem get resolved)

Greetings

>About:
>--
>
>REminiscence is a re-implementation of the engine used in the game Flashback
>made by Delphine Software and released in 1992. More informations about the
>game can be found at [1], [2] and [3].
>
>Data Files:
>---
>
>You will need the original files of the PC (DOS or CD), Amiga or Macintosh
>release. Support for Amiga and Macintosh is still experimental.

Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1

[Adrian Bunk]

On Sun, Dec 03, 2023 at 10:59:44AM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2023-10-23 at 13:19 +0200, Jan Wagner wrote:
> > As reported in #1033791, check_running_kernel fails to find version
> > on bookworm/(arm64|armhf).
> 
> Please go ahead.

Architecture: source amd64

Should this be binNMU'ed on amd64 before the release?
Maintainer-built binaries are not supposed to be in main.

There are other packages with the same issue in bookworm,
but these either involve binary-all packages and/or were
in previous point releases.

It might be useful if SRM tooling catches this issue,
similar to what britney does for testing.

> Regards,
> 
> Adam

cu
Adrian

BTW: The "contrib" in nagios-plugins-contrib does not refer
 to our archive section, the packages are in main.

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Adrian Bunk]

On Sun, Dec 03, 2023 at 09:51:38PM +0100, Paul Gevers wrote:
>...
> And it also means that r-bioc-biocgenerics is now blocked on the haskell
> transition. Lovely. Good thing that pandoc is supposed to be the last piece
> in that several months long transition.

It's only blocked by the pandoc part of the Haskell transition, 
it shouldn't be blocked by the other remaining parts of the
transition or by getting the transition into testing.

> Paul

cu
Adrian

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Adrian Bunk]

On Sun, Dec 03, 2023 at 09:46:31AM -0100, Graham Inggs wrote:
>...
> This is probably a good example for why new packages should be
> uploaded to experimental first, instead of directly to unstable.
>...

Not really.

It is rare that a new source package takes over a binary package from 
another binary package, and in this case the same might have happened
during an upgrade of the pandoc packages not involving NEW at all.

> Regards
> Graham
>...

cu
Adrian

Bug#1057355: libmpfr6: major formatted output function bugs with %c and the value 0

[Vincent Lefevre]

Package: libmpfr6
Version: 4.2.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://sympa.inria.fr/sympa/arc/mpfr/2023-12/msg0.html
X-Debbugs-Cc: Debian Security Team 

I've reported the following bug in the MPFR mailing-list. I think
I've fixed the issues on the MPFR side in master, but MPFR is still
affected by the bug on the GMP side (gmp_vasprintf):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057344

The vasprintf.c code (for the formatted output functions) does not
handle null characters correctly. These characters can occur by
using %c with the value 0.

This is shown by the check_null tsprintf.c test:

  
https://gitlab.inria.fr/mpfr/mpfr/-/commit/78e72e6538fabc1b720d97e862ec45354e5c9c3f

The possible consequences are:
  - possible memory corruption with custom memory allocators that
do not ignore the size parameter of the "free" function;
  - a part of the buffer fails to be overwritten (with possible
security issues if the buffer contains sensitive data that
were expected to be overwritten);
  - an assertion failure when GNU MPFR has been configured with
assertion checking (--enable-assert).

Note that some of these issues partly come from a bug in gmp_vasprintf
(such as the incorrect return value), which I've reported here:

  https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html

I think that I have fixed these issues on the MPFR side with

  
https://gitlab.inria.fr/mpfr/mpfr/-/commit/390e51ef8570da4e338e9806ecaf2d022210d951

but the first two consequences remain due to the gmp_vasprintf bug.

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

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

Versions of packages libmpfr6 depends on:
ii  libc6 2.36-9+deb12u3
ii  libgmp10  2:6.2.1+dfsg1-1.1

libmpfr6 recommends no packages.

libmpfr6 suggests no packages.

-- no debconf information

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

Bug#1057354: src:r-cran-dbplyr: fails to migrate to testing for too long: triggers autopkgtest regression

[Paul Gevers]

Source: r-cran-dbplyr
Version: 2.3.4+dfsg-1
Severity: serious
Control: close -1 2.4.0+dfsg-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:r-cran-dbplyr has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
triggers autopkgtest failures in src:r-bioc-biocfilecache.


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


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


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=r-cran-dbplyr



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057353: src:unyt: fails to migrate to testing for too long: triggers autopkgtest failures

[Paul Gevers]

Source: unyt
Version: 2.9.5-1
Severity: serious
Control: close -1 3.0.1-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:unyt has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable triggers 
autopkgtest failure in src:yt.


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


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


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=unyt



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057352: src:vonsh: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: vonsh
Version: 1.0
Severity: serious
Control: close -1 1.0-0.1
X-Debbugs-CC: b...@debian.org
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1057155

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:vonsh has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable is 
blocked by RC bug 1057155.


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


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


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=vonsh



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057351: src:hypercorn: fails to migrate to testing for too long: new Dependency not in testing

[Paul Gevers]

Source: hypercorn
Version: 0.14.4-1
Severity: serious
Control: close -1 0.15.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:hypercorn has been trying to migrate for 
33 days [2]. Hence, I am filing this bug. The version in unstable has a 
Depends on an RC buggy package: node-mermaid.


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


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


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=hypercorn



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1014887: ir-ctl: increase the size of the buffer used to read raw files

[Gregor Jasny]

Hello Joe,

thanks for your bug report. I looked through the current code base of 
ir-ctl and saw that Sean committed the following change to increase the 
limit from 1k to 8k:



https://git.linuxtv.org/v4l-utils.git/commit/utils/ir-ctl/ir-ctl.c?id=1874b2d0dfbb8a38b0c8b75a23a4b9a60e52fd6a


Maybe that's already large enough for your use case, too?

But replacing fgets with getline should be a straight-forward fix to get 
rid of the limit once and for all.


Sean, what do you think about that replacement and do you have time to 
work on the change?


Thanks,
Gregor

Bug#1057350: src:secsipidx: fails to migrate to testing for too long: FTBFS on 32 bit archs

[Paul Gevers]

Source: secsipidx
Version: 1.2.0-2
Severity: serious
Control: close -1 1.3.2-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:secsipidx has been trying to migrate for 
33 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on armel, armhf and i386.


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


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


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=secsipidx



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057349: src:gdcm: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: gdcm
Version: 3.0.21-2
Severity: serious
Control: close -1 3.0.22-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:gdcm has been trying to migrate for 34 
days [2]. Hence, I am filing this bug. The version in unstable has an 
unresolved RC bug (#1056953).


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


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


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=gdcm



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057348: src:takari-polyglot-maven: fails to migrate to testing for too long: unresolved RC bug and B-D not ready to migrate

[Paul Gevers]

Source: takari-polyglot-maven
Version: 0.4.11-1
Severity: serious
Control: close -1 0.4.11-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:takari-polyglot-maven has been trying to 
migrate for 36 days [2]. Hence, I am filing this bug. The version in 
unstable has an unresolved RC bug. On top of that it Build-Depends on 
several jruby* packages which aren't in testing.


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


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


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=takari-polyglot-maven



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056974: [pkg-php-pear] Bug#1056974: php-dompdf: providing .ufm files

[Robin Gustafsson]

Control: tags -1 patch

Hi,

On 12/2/23 12:10, William Desportes wrote:

Control: tags -1 wontfix

Hello,

Only "DejaVu*" fonts have ufm files.

But I had to exclude the DejaVu fonts for licensing reasons: 
https://sources.debian.org/src/php-dompdf/2.0.3%2Bdfsg-3/debian/copyright/#L7

[...]


I think we can fix this issue by building .ufm files from the DejaVu 
.ttf files that are symlinked from the fonts-dejavu package.


I've submitted a merge request on Salsa with a proposed patch.
https://salsa.debian.org/php-team/pear/php-dompdf/-/merge_requests/2

--
Regards,
Robin

GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Paul Gevers]

Hi,

On 03-12-2023 11:46, Graham Inggs wrote:

This seems to be due to the restructuring of src:pandoc [1].
src:haskell-pandoc [2] recently cleared NEW into unstable, and the
updated src:pandoc has not been uploaded yet.

This is probably a good example for why new packages should be
uploaded to experimental first, instead of directly to unstable.


And it also means that r-bioc-biocgenerics is now blocked on the haskell 
transition. Lovely. Good thing that pandoc is supposed to be the last 
piece in that several months long transition.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1040245: wget-style scroll bars in syslog after Debian 11->12 upgrade

[Jonny Grant]

Hi
Also seeing this issue in  1.9.5 in ubuntu

https://github.com/fwupd/fwupd/discussions/6485

Bug#1057272: Enable SENSORS_IIO_HWMON support

[Andrey Melnikov]

сб, 2 дек. 2023 г. в 19:32, Vincent Blut :
>
> Control: tags -1 moreinfo
>
> Hi Andrey,
>
> Le 2023-12-02 16:40, Andrey Melnikov a écrit :
> > Package: src:linux
> > Version: 6.5.13-1
> > Severity: wishlist
> >
> > Please, enable SENSORS_IIO_HWMON support. Without it I'm unable to
> > fetch the AXP209 internal temperature sensor.
>
> The definition of the AXP209 PMU seems to confirm that the internal 
> temperature
> sensor is hooked to the iio-hwmon driver:
>
> pmic-temp {
> compatible = "iio-hwmon";
> io-channels = <_adc 4>; /* Internal temperature */
> };
>
> One thing, though. Does it make sense to enable SENSORS_IIO_HWMON outside of
> armhf?
Yes. IIO device may be connected via i2c, or integrated into the
baseboard.Some old intel atom chipset have IIO, and iio_hwmon.ko size
~ 13k - not a big deal for x86/arm/mips devices.

Bug#1057347: vips: increase the timeout further and make it unconditional

[Adrian Bunk]

Source: vips
Version: 8.14.1-1
Severity: serious
Tags: ftbfs patch

1. Make the timeout much larger

The current timeout is not sufficient on all MIPS buildds:
https://buildd.debian.org/status/package.php?p=vips

A generous timeout is cheap, since it only has any negative
effect in the rare case where the test actually hangs.

For passing tests and even for test failures a timeout has no effect.


2. Make the timeout unconditional

As noted above a more generous timeout is cheap,
an unconditional increase is less hassle than manually
tracking buildd speed for every architecture
(e.g. Alpha also has slow qemu buildds where the tests
currently time out).


--- vips-8.15.0/debian/rules.old2023-12-03 20:32:41.049820544 +
+++ vips-8.15.0/debian/rules2023-12-03 20:05:30.918121415 +
@@ -12,11 +12,7 @@
 DESTDIR = $(CURDIR)/debian/tmp
 
 override_dh_auto_test:
-ifeq (, $(filter hppa hurd-i386 mips64el mipsel sparc64, $(DEB_BUILD_ARCH)))
-   LD_LIBRARY_PATH=$(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE)/libvips dh_auto_test
-else
-   LD_LIBRARY_PATH=$(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE)/libvips 
dh_auto_test -- --timeout-multiplier=3
-endif
+   LD_LIBRARY_PATH=$(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE)/libvips 
dh_auto_test -- --timeout-multiplier=10
 
 override_dh_auto_configure:
dh_auto_configure -- \

Bug#1054747: ruby-octokit: FTBFS: ERROR: Test "ruby3.1" failed: Failure/Error: require 'pry-byebug'

[Miguel Landaeta]

On Fri, Oct 27, 2023 at 09:20:42PM +0200, Lucas Nussbaum wrote:
> Source: ruby-octokit
> Version: 4.20.0-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > Failure/Error: require 'pry-byebug'
> > 
> > Gem::MissingSpecError:
> >   Could not find 'pry' (~> 0.13.0) among 122 total gem(s)


A possible fix for this issue could be to just update pry-byebug package to a
more recent release.

https://github.com/deivid-rodriguez/pry-byebug/commit/a915f21fc63aa94473bbe7cb752c0fabacc3e567

pry-byebug 3.10.1 depends on a pry version that's in the archive.

https://packages.debian.org/source/unstable/pry

Bug#1057346: qt6-base-dev-tools is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

Package: qt6-base-dev-tools
User: debian-cr...@lists.debian.org
Severity: important
Usertags: ftcbfs
Control: affects -1 + src:kuserfeedback
X-Debbugs-Cc: debian-cr...@lists.debian.org

Hi Qt maintainers and cross people,

I think I've found one of those innocent looking cross build failures
that turn into something big. src:kuserfeedback actually cross builds
successfully, but what comes out is broken:

qml6-module-org-kde-userfeedback_1.3.0-3_arm64.deb contains
./usr/lib/x86_64-linux-gnu/qt6/qml/org/kde/userfeedback/libKUserFeedbackQmlQt6.so

qt6-kuserfeedback-dev_1.3.0-3_arm64.deb contains
./usr/lib/x86_64-linux-gnu/qt6/mkspecs/modules/qt_KUserFeedbackCoreQt6.pri
and
./usr/lib/x86_64-linux-gnu/qt6/mkspecs/modules/qt_KUserFeedbackWidgetsQt6.pri

Evidently, something inserts build architecture multiarch libdirs
somehow and that's bad. Digging into kuserfeedback, I think the origin
of the earlier one is KDE_INSTALL_QMLDIR (see
src/provider/qml/CMakeLists.txt). Looking beyond, I think this is set
from extra-cmake-modules. It's not exactly clear to me how this comes
about to be. If you know please tell.

So I looked into how extra-cmake-modules constructs such paths and found
kde-modules/KDEInstallDirs6.cmake which looks related. I cannot really
draw the connection and assume there is one. Is that still convincing
enough? Is someone able to fill this gap?

Assuming we're still on track, I think stuff comes out of ecm_query_qt,
which is defined in modules/ECMQueryQt.cmake. This works differently for
Qt5 and Qt6. For Qt5, it invokes Qt5::qmake -query. This is something we
redirected to point at ${DEB_HOST_GNU_TYPE}-qmake and this generally
gives the right variables. Getting there was a longer journey, but this
now works neatly. What we're looking at here though is the Qt6 case and
there we use Qt6::qtpaths. As far as I understand it, this is new in
Qt6. While we did add a ${DEB_HOST_GNU_TYPE}-qmake6 wrapper script, I am
not aware of any qtpaths6 wrapper. Running it like qtpaths6 --query
QT_INSTALL_QML gives /usr/lib/x86_64-linux-gnu/qt6/qml here and that
very plausibly explains the original failure.

It also tells us that qtpaths6 definitely is not something that is
appropriate for shipping in a Multi-Arch: foreign package as is.
qt6-base-dev-tools is that package and it is currently marked
Multi-Arch: foreign. Just removing the marking is not the solution here.
We really want the qtpaths6 executable to reside in a Multi-Arch:
foreign package. Otherwise, we cannot run it. What we need here is a
wrapper script ${DEB_HOST_GNU_TYPE}-qtpaths6 for qtpaths6 that sets
architecture-dependent properties in matching ways. This probably
belongs to some Multi-Arch: same package. Then Qt6::qtpaths needs to be
redefined to point at the triplet-prefixed one. It is not clear to me
how packages have to be reorganized. That package containing
${DEB_HOST_GNU_TYPE}-qtpaths6 somehow needs to be pulled into the build
for kuserfeedback. The most obvious option is to rename
qt6-base-dev-tools to qt6-base-dev-tools-bin and use the previous name
for the Multi-Arch: same package. That may not be the best of solutions
though. Possibly, there already is a suitable Multi-Arch: same package
that is required anyway, which can hold these wrappers.

This is as far as I got. Does that make sense to you? Is that actionable
to Qt maintainers?

Helmut

Bug#1055737: gpodder don't start , claim abandon

[Thomas Perl]

Hi,

Looking at your logs, It looks like the kernel has decided that it can’t fulfil 
a memory (RAM) allocation request.

There are some sysctl values that affect how the kernel handles overcommitment 
and other things (e.g. reserved RAM for the admin user).

Can you check the output of “sysctl -a” for anything that’s out of the ordinary?

Some things to look at:

vm.overcommit_memory
vm.admin_reserve_kbytes

Also, if you have a big tmpfs that might reduce available memory.

Some more notes about this here:
https://github.com/lorenzo-stoakes/linux-vm-notes/blob/master/sections/oom.md

The “bug” could of course also be that gPodder tries to allocate too much 
memory, and the memory allocation failing is just a symptom of that.


Thanks,
Thomas

> On 28.11.2023, at 12:34, Grand T  wrote:
> 
> Hello
> I Give another try with the two versions available, below what I found in logs
> 
> journalctl -xb | grep gpodder
> nov. 28 12:20:05 debian sudo[6011]:  guy : TTY=pts/0 ; PWD=/home/guy ; 
> USER=root ; COMMAND=/usr/bin/apt install gpodder
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:20:56 debian kernel: __vm_enough_memory: pid: 6721, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:21:22 debian sudo[6743]:  guy : TTY=pts/0 ; PWD=/home/guy ; 
> USER=root ; COMMAND=/usr/bin/apt purge gpodder
> nov. 28 12:21:55 debian sudo[7708]:  guy : TTY=pts/0 ; PWD=/home/guy ; 
> USER=root ; COMMAND=/usr/bin/apt install gpodder/stable
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:31 debian kernel: __vm_enough_memory: pid: 8403, comm: gpodder, 
> no enough memory for the allocation
> nov. 28 12:22:37 debian sudo[8424]:  guy : TTY=pts/0 ; PWD=/home/guy ; 
> USER=root ; COMMAND=/usr/bin/apt purge gpodder
> 
> 
> it remains 1,5 G in my home:
> 
> df -hT
> Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
> udev devtmpfs   1,8G   0  1,8G   0% /dev
> tmpfstmpfs  366M2,1M  364M   1% /run
> /dev/sda1ext419G 15G  3,3G  82% /
> tmpfstmpfs  1,8G 75M  1,8G   5% /dev/shm
> tmpfstmpfs  5,0M8,0K  5,0M   1% /run/lock
> tmpfstmpfs  1,1G 57M  1,1G   6% /tmp
> /dev/sda6ext4   268G253G  1,5G 100% /home
> tmpfstmpfs  366M 84K  366M   1% /run/user/1001
> 
> free -mht
>total   utilisé  libre partagé tamp/cache   
> disponible
> Mem:   3,6Gi   1,8Gi   493Mi   145Mi   1,6Gi   
> 1,7Gi
> Échange:   7,7Gi   256Ki   7,7Gi
> Total:  11Gi   1,8Gi   8,2Gi
> 
> 
> 
> 
> By the way everything else is working on this Pc

Bug#1053509: shasta: autopkgtest regression on arm64: is memory suddenly not enough?

[Paul Gevers]

Hi Étienne,

On 03-12-2023 18:34, Étienne Mollier wrote:

1) why does it now suddenly start to (nearly always) fail across the
board on arm64 (in Debian, Ubuntu still seems fine), without changes to
the infrastructure that I know of?


I'm afraid I'm not sure what is up with shasta eating up more
memory on arm64 hosts of CI infrastructure.  What I can see from
my end is that the test roughly requires 8GiB of anonymous
memory to map for doing its job.


8GiB... that's not little, considering that that's what these hosts have 
as RAM (https://wiki.debian.org/ContinuousIntegration/WorkerSpecs).



Except that, this is already
the case for shasta in bookworm running on bookworm kernel, so
that doesn't look to be a regression per se.


Weird.


Per chance, could you double check the memory settings on the CI
hosts, just in case, to make sure that the swap didn't drop off
the machine?


  ci-worker-arm64-04: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-02: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-06: -rw--- 1 root root 3.9G May 26  2022 /swap
  ci-worker-arm64-03: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-05: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-11: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-07: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-08: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-09: -rw--- 1 root root 3.9G May 27  2022 /swap
  ci-worker-arm64-10: -rw--- 1 root root 3.9G May 27  2022 /swap


Or maybe check for memory overcommit settings
inconsistencies?


It's kbytes, memory, ratio == 0, 0, 50 across all our hosts.


Currently readable test logs suggest that:

   * ci-worker-arm64-10 met memory requirements in November,
   * ci-worker-arm64-07 did not meet requirements in October,
   * ci-worker-arm64-08 did not meet requirements in October,
   * ci-worker-arm64-03 did not meet requirements in October.


Those hosts should be equivalent. Be aware though that tests don't run 
in isolation. At the same time, on our arm64 hosts, one more test might 
be running. So what's *available* might not be constant in time.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057345: python-etcd3gw: Autopkgtest needs to depend on python3-all

[Aaron Rainbolt]

Package: python-etcd3gw
Severity: normal
X-Debbugs-Cc: arraybo...@ubuntu.com

Building python-etcd3gw from source on Debian Sid results in a Lintian
warning,
runtime-test-file-uses-supported-python-versions-without-python-all-build-depends.
This is the result of the package python3-all not being present as a test
prerequisite in debian/tests/control. Please add it as a Depends of the
unittests test.


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

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

Bug#1055797: Git history for directory debian/

[Sebastian Pipping]

PS: This view should help with quickly identifying all changes to 
kdbg_2.5.5-3 packaging for 3.1.0-1 that are known needed:


https://github.com/j6t/kdbg/commits/master/debian

Bug#1000044: ccze: depends on obsolete pcre3 library

[Axel Beckert]

Hi Yavor,

Yavor Doganov wrote:
> Please find a patch attached

Thanks a lot!

> (I was not able to test all plugins).

Better than nothing.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1055797: KDbg 3.1.0 released

[Sebastian Pipping]

Quick update: KDbg 3.1.0 has been released [1] upstream today.  That 
should now allow packaging of KDbg with a downstream patch count of zero 
in Debian.



[1] https://github.com/j6t/kdbg/releases/tag/kdbg-3.1.0

Bug#1057344: libgmp10: major formatted output function bug with %c and the value 0

[Vincent Lefevre]

Package: libgmp10
Version: 2:6.2.1+dfsg1-1.1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html
X-Debbugs-Cc: Debian Security Team 

I've reported the following bug upstream. Debian/stable is affected
(at least on the testcase below, but the various issues are probably
related).

With GMP 6.3.0, the formatted output functions do not handle %c
with the value 0 correctly. For gmp_sprintf, the return value is
incorrect. For gmp_asprintf and gmp_vasprintf, this is either a
buffer overflow (according to the GMP manual: "The block will be
the size of the string and null-terminator.") or, in case this
is an error in the GMP manual, possible memory corruption when
freeing the allocated memory, if the custom memory allocation
function cares about the size parameter.

Testcase for gmp_sprintf:


#include 
#include 

static void test (int flag)
{
  char s[3] = { 1, 1, 1 };
  int r;

  r = (flag ? sprintf : gmp_sprintf) (s, "%c", 0);
  printf ("%4s: r = %d, s = { %d %d %d }\n",
  flag ? "libc" : "gmp", r, s[0], s[1], s[2]);
}

int main (void)
{
  test (0);
  test (1);
  return 0;
}


which currently gives:

 gmp: r = 0, s = { 0 0 1 }
libc: r = 1, s = { 0 0 1 }

MPFR has various issues concerning %c with the value 0, but an
attempt to fix them fails due to

  length = gmp_vasprintf (...);
[...]
  mpfr_free_str (s);

which is similar to GMP's tests/misc/t-printf.c file, which contains

  got_len = gmp_vasprintf (, fmt, ap);
[...]
  (*__gmp_free_func) (got, strlen(got)+1);

But replacing

  mpfr_free_str (s);

by

  mpfr_free_func (s, length + 1);

i.e. using the return value length instead of strlen(s), also fails.
I suppose that this is related to the incorrect return value.

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

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

Versions of packages libgmp10 depends on:
ii  libc6  2.36-9+deb12u3

libgmp10 recommends no packages.

libgmp10 suggests no packages.

-- no debconf information

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

Bug#1057205: systemtap: version 5.0-1 FTBFS on i386, ppc64el, riscv64

[Emanuele Rocca]

Control: retitle -1 systemtap: FTBFS with g++-13 on i386, ppc64el, riscv64

On 2023-12-01 04:53, Emanuele Rocca wrote:
> In constructor ‘symresolution_info::symresolution_info(systemtap_session&, 
> bool)’,
> inlined from ‘int semantic_pass_symbols(systemtap_session&)’ at 
> elaborate.cxx:1872:28:
> elaborate.cxx:2659:21: error: storing the address of local variable ‘sym’ in 
> ‘*s.systemtap_session::symbol_resolver’ [-Werror=dangling-pointer=]
>  2659 |   s.symbol_resolver = this; // save resolver for early PR25841 
> function resolution
>   |   ~~^~
> elaborate.cxx: In function ‘int semantic_pass_symbols(systemtap_session&)’:
> elaborate.cxx:1872:22: note: ‘sym’ declared here
>  1872 |   symresolution_info sym (s);
>   |  ^~~
> elaborate.cxx:1870:43: note: ‘s’ declared here
>  1870 | semantic_pass_symbols (systemtap_session& s)
>   |~~~^

This is happening only with g++-13. With CXX=g++-12 systemtap builds
fine.

Bug#1057315: tiles: CVE-2023-49735

[Salvatore Bonaccorso]

Control: clone -1 -2 -3
Control: retitle -2 tiles: Add README.Debian.security to document support status
Control: reassign -3 src:debian-security-support
Control: retitle -3 Mark tiles as only supported for building applications 
shipped in Debian 

Hi,

On Sun, Dec 03, 2023 at 03:35:31PM +0100, Markus Koschany wrote:
> Am Sonntag, dem 03.12.2023 um 15:10 +0100 schrieb Moritz Muehlenhoff:
> > > But maybe we can set it as "no-dsa", is it only used as build
> > > dependency for libspring-java and not sensible outside?
> > 
> > Spring is already marked as unsupported, so we can simply extend that.
> 
> +1 This is sensible in this case.

Ok your both reasoning make sense.

So adding a README.Debian.security on a next upload to clarify the
situation for only beeing supported for building applications shipped
in Debian.

And then as well a debian-security-support entry.

Cloning and reassigning accordingly two bugs.

Regards,
Salvatore

Bug#1055226: yuzu 0-1335+ds-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055226 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: yuzu
Version: 0-1335+ds-1+deb12u1

Explanation: strip :native from glslang-tools build dependency, fixing build 
failure

Bug#1057233: [Pkg-utopia-maintainers] Bug#1057233: pipewire-bin: installs files into /lib/udev/rules.d

[Michael Biebl]

Hi Chris

Am 02.12.23 um 03:45 schrieb Chris Hofstaedtler:

Control: tags -1 + patch

* Chris Hofstaedtler  [231202 02:17]:

your package installs the file /lib/udev/rules.d/90-pipewire-alsa.rules.

[..]

Please find a patch attached, which delegates placement of the rules
file to udev.pc. In a few weeks, udev.pc will change "udevdir" to
/usr/lib/udev/rules.d, and then your package will pick the new path
up on the next upload or binNMU.
Additionaly, backports do not need to revert anything.


If you are going to use udev.pc/systemd.pc, please consider using 
systemd-dev as Build-Depends instead of udev/systemd


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054401: nagios-plugins-contrib 42.20230308+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1054401 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nagios-plugins-contrib
Version: 42.20230308+deb12u1

Explanation: fix on-disk kernel version detection

Bug#1057341: ruby-jekyll-asciidoc: update to 3.0.1 or a pre-3.1.0 snapshot?

[Yann Dirson]

Package: ruby-jekyll-asciidoc
Version: 3.0.0-2
Severity: wishlist

There is upstream git activity, with 3.0.1 tagged (with no "github ci/release" 
though),
and quite some stuff rowards release 3.1.0 in 'main' - hopefully that could 
help getting
the package up and running again?

Bug#1056998: cdrom: Installation media changes after booting it

[Ram Reddy]

Hello,
Thomas Schmitt wrote:
>
> It would be interesting to check whether any errors get reported if the
> ISO is presented on a read-only CD or DVD instead of a writable USB stick.

Hello, thank you for the help. The DVD+Rs arrived, along with the DVD
Drive. I tested the installer on one of my laptops, and found that its
contents didn't change. (which is to be expected, as DVD+Rs can't be
rewritten) I didn't bother testing that on different computers, because the
result would be the same. However, I have tested the USB drive on a few
other computers and here are my findings:

On the Lenovo Legion 7i Gen 5*, Lenovo Thinkpad X1 Carbon Gen 2*, Lenovo
Thinkpad X1 Carbon Gen 5 Intel*, and one Lenovo Thinkpad E14 Gen 5 all
showed the corruption error.
*These laptops have been tested for installer corruption twice (a week ago,
and just now)

However, on the Lenovo Yoga C740 and a different Lenovo Thinkpad E14 Gen 5
Intel showed no corruption issues.

Both the Thinkpad E14 Gen 5s had the same specifications and type number,
differing only in that the one with corruption of the installer has 24GB of
memory (16GB installed in the slot, 8GB soldered) and the other only has
8GB soldered. They both have the same BIOS version, R2AET32W(1.07). Again,
the ones that had corruption all had it at the same location. (byte
2303211, line 21165)

This seems to be really interesting because the corruption only happened on
certain computers, and it would stay that way on repeated attempts. Thank
you for the help.

Have a wonderful day,
Ram

Bug#1057309: src:haskell-pandoc binary package names conflict with src:pandoc binary packages

[Scott Talbert]

reassign -1 src:pandoc
affects -1 src:haskell-pandoc

On Sun, 3 Dec 2023, Hannes von Haugwitz wrote:


Source: haskell-pandoc
Version: 3.0.1-2
Severity: serious
Control: affects -1 src:pandoc

Hi,

The binary packages provided by src:haskell-pandoc conflict with the
binary packages of src:pandoc; violationg Debian Policy 3.1 ("Every
package must have a name that’s unique within the Debian archive.").

This also makes the pandoc binary package from src:pandoc uninstallable
in unstable:


# apt policy pandoc pandoc-data
pandoc:
 Installed: (none)
 Candidate: 2.17.1.1-3
 Version table:
2.17.1.1-3 500
   500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 Packages
pandoc-data:
 Installed: (none)
 Candidate: 3.0.1-2
 Version table:
3.0.1-2 500
   500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 Packages
2.17.1.1-3 500
   500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 Packages

# apt install pandoc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
pandoc : Depends: pandoc-data (< 2.17.1.1-3.~) but 3.0.1-2 is to be installed
E: Unable to correct problems, you have held broken packages.


As a workaround you can specify the matching version of pandoc-data:

# apt install pandoc pandoc-data=2.17.1.1-3


Yes, this is expected (temporarily).  pandoc has been refactored upstream 
and has been separated into a library and a cli package. 
src:haskell-pandoc will now provide the library and data packages, while 
src:pandoc needs to be updated to just provide the cli package.


Regards,
Scott

Bug#1057340: Please drop Felix from Uploaders

[Felix Lechner]

Package: wolfssl
Severity: wishlist
X-Debbugs-CC: Bastian Germann 

Hi Bastian,

Please replace my name with yours in the Uploaders field when you get a
chance. I do not have time to help maintain wolfSSL at the moment since
my wife had a baby. Thanks!

Kind regards
Felix

Bug#1000044: ccze: depends on obsolete pcre3 library

[Yavor Doganov]

Control: tags -1 + patch

Please find a patch attached (I was not able to test all plugins).
>From 1b55bb243cb69c8f1ce006f237187eca7fb47793 Mon Sep 17 00:00:00 2001
From: Yavor Doganov 
Date: Sun, 3 Dec 2023 20:13:33 +0200
Subject: [PATCH] Port to PCRE2 (#144)

---
 debian/changelog   |7 +
 debian/control |2 +-
 debian/patches/pcre2.patch | 2807 
 debian/patches/series  |1 +
 4 files changed, 2816 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/pcre2.patch

diff --git a/debian/changelog b/debian/changelog
index 9e9de97..95eb7a5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ccze (0.2.1-8) UNRELEASED; urgency=medium
+
+  * debian/patches/pcre2.patch: New; port to PCRE2 (Closes: #144).
+  * debian/control (Build-Depends): Replace libpcre3-dev with libpcre2-dev.
+
+ -- Yavor Doganov   Sun, 03 Dec 2023 20:00:06 +0200
+
 ccze (0.2.1-7) unstable; urgency=medium
 
   * Update debian/watch AGAIN with regards to Github changes.
diff --git a/debian/control b/debian/control
index 895d45e..2b67dd6 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Axel Beckert 
 Standards-Version: 4.6.0
 Build-Depends: debhelper-compat (= 13),
libncurses5-dev,
-   libpcre3-dev
+   libpcre2-dev
 Vcs-Git: https://salsa.debian.org/debian/ccze.git
 Vcs-Browser: https://salsa.debian.org/debian/ccze
 Homepage: https://github.com/madhouse/ccze
diff --git a/debian/patches/pcre2.patch b/debian/patches/pcre2.patch
new file mode 100644
index 000..6b60dc8
--- /dev/null
+++ b/debian/patches/pcre2.patch
@@ -0,0 +1,2807 @@
+Description: Port to PCRE2.
+Bug-Debian: https://bugs.debian.org/144
+Author: Yavor Doganov 
+Forwarded: no
+Last-Update: 2023-12-03
+---
+
+--- ccze.orig/configure.ac
 ccze/configure.ac
+@@ -102,14 +102,14 @@
+ AC_CHECK_FUNC(getopt_long, [], [AC_CHECK_LIB(gnugetopt, getopt_long)])
+ 
+ if test -z "${PCRE_CONFIG}"; then
+-	AC_PATH_PROG(PCRE_CONFIG, pcre-config, no)
++	AC_PATH_PROG(PCRE_CONFIG, pcre2-config, no)
+ fi
+ AC_MSG_CHECKING(for PCRE)
+ if test "${PCRE_CONFIG}" = "no"; then
+ 	AC_ERROR(PCRE not found)
+ fi
+ PCRE_CFLAGS=$($PCRE_CONFIG --cflags)
+-PCRE_LIBS=$($PCRE_CONFIG --libs)
++PCRE_LIBS=$($PCRE_CONFIG --libs8)
+ AC_SUBST(PCRE_CFLAGS)
+ AC_SUBST(PCRE_LIBS)
+ AC_MSG_RESULT(found)
+--- ccze.orig/src/ccze-wordcolor.c
 ccze/src/ccze-wordcolor.c
+@@ -29,9 +29,9 @@
+ #include "ccze-private.h"
+ #include "ccze-compat.h"
+ 
+-static pcre *reg_pre, *reg_post, *reg_host, *reg_mac, *reg_email;
+-static pcre *reg_uri, *reg_size, *reg_ver, *reg_time, *reg_addr;
+-static pcre *reg_num, *reg_sig, *reg_email2, *reg_hostip, *reg_msgid;
++static pcre2_code *reg_pre, *reg_post, *reg_host, *reg_mac, *reg_email;
++static pcre2_code *reg_uri, *reg_size, *reg_ver, *reg_time, *reg_addr;
++static pcre2_code *reg_num, *reg_sig, *reg_email2, *reg_hostip, *reg_msgid;
+ 
+ static char *words_bad[] = {
+   "warn", "restart", "exit", "stop", "end", "shutting", "down", "close",
+@@ -71,33 +71,31 @@
+ void
+ ccze_wordcolor_process_one (char *word, int slookup)
+ {
+-  size_t wlen;
+-  int offsets[99];
++  size_t wlen, l;
+   ccze_color_t col;
+-  int match, printed = 0;
++  int printed = 0;
+   char *pre = NULL, *post = NULL, *tmp, *lword;
++  pcre2_match_data *offsets;
+ 
+   col = CCZE_COLOR_DEFAULT;
+ 
++  offsets = pcre2_match_data_create (99, NULL);
++
+   /** prefix **/
+-  if ((match = pcre_exec (reg_pre, NULL, word, strlen (word), 0, 0,
+-			  offsets, 99)) >= 0)
++  if (pcre2_match (reg_pre, word, strlen (word), 0, 0, offsets, NULL) >= 0)
+ {
+-  pcre_get_substring (word, offsets, match, 1, (const char **));
+-  pcre_get_substring (word, offsets, match, 2, (const char **));
+-  free (word);
++  pcre2_substring_get_bynumber (offsets, 1, (unsigned char **), );
++  pcre2_substring_get_bynumber (offsets, 2, (unsigned char **), );
+   word = tmp;
+ }
+   else
+ pre = NULL;
+ 
+   /** postfix **/
+-  if ((match = pcre_exec (reg_post, NULL, word, strlen (word), 0, 0,
+-			  offsets, 99)) >= 0)
++  if (pcre2_match (reg_post, word, strlen (word), 0, 0, offsets, NULL) >= 0)
+ {
+-  pcre_get_substring (word, offsets, match, 1, (const char **));
+-  pcre_get_substring (word, offsets, match, 2, (const char **));
+-  free (word);
++  pcre2_substring_get_bynumber (offsets, 1, (unsigned char **), );
++  pcre2_substring_get_bynumber (offsets, 2, (unsigned char **), );
+   word = tmp;
+ }
+   else
+@@ -107,45 +105,45 @@
+   lword = _stolower (word);
+   
+   /** Host **/
+-  if (pcre_exec (reg_host, NULL, lword, wlen, 0, 0, offsets, 99) >= 0)
++  if (pcre2_match (reg_host, lword, wlen, 0, 0, offsets, NULL) >= 0)
+ col = CCZE_COLOR_HOST;
+   /** MAC address **/
+-  else if (pcre_exec (reg_mac, NULL, lword, wlen, 0, 0, offsets, 99) >= 0)
++  else if (pcre2_match (reg_mac, lword, wlen, 0, 

Bug#1029968: And some patches

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/linux-iommu/Y9qSwkLxeMpffZK%2F@gallifrey/ 
https://lore.kernel.org/linux-media/cover.1701349092.git.hverkuil-ci...@xs4all.nl/

On Sunday, 3 December 2023 17:50:07 CET Dr. David Alan Gilbert wrote:
> As well as the fixes in 6.6,

A 6.6 kernel is now available in Experimental

> we also need this patchup series here:
> https://lore.kernel.org/linux-media/ZWibhE350L3BTRK8@gallifrey/T/#t
> 
> These seem to make it pretty nicely.

Excellent :) I saw they had "Fixes:" tags, which normally means they'll
get backported to older kernel series like 6.6.

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

Bug#1057190: libhackrf0: udev rules file lost in upgrade

[Helmut Grohne]

Hi Maitland,

On Sat, Dec 02, 2023 at 10:57:40AM -0500, Maitland Bottoms wrote:
> Helmut Grohne  writes:
> 
> > Then when you retry it, please go for experimental first. Then have
> > Chris or me check your upload is ok and only then proceed with uploading
> > to unstable.
> 
> hackrf_2023.01.1-6 now in experimental is the retry with upstream
> updates and the udev rules handling.

This is the earlier reproducer adapted for experimental:

mmdebstrap trixie /dev/null http://deb.debian.org/debian --architectures 
amd64,i386 --include=libhackrf0:amd64,libhackrf0:i386 --customize-hook='sed -i 
-e s/trixie/experimental/ "$1/etc/apt/sources.list"' 
--chrooted-customize-hook="apt update" --chrooted-customize-hook="apt-get 
download -t experimental libhackrf0" --chrooted-customize-hook="dpkg 
--auto-deconfigure --unpack /*.deb" --chrooted-customize-hook="dpkg -r 
libhackrf0:i386" --chrooted-customize-hook="dpkg --configure -a" 
--customize-hook='test -e "$1/lib/udev/rules.d/60-libhackrf0.rules"'

It now succeeds. If you run it, you also see the protective diversion
being created and removed now:

| I: running --chrooted-customize-hook in shell: sh -c 'apt-get download -t 
experimental libhackrf0'
| Get:1 http://deb.debian.org/debian experimental/main amd64 libhackrf0 amd64 
2023.01.1-6 [17.5 kB]
| Fetched 17.5 kB in 0s (197 kB/s)  
| W: Download is performed unsandboxed as root as file 
'//libhackrf0_2023.01.1-6_amd64.deb' couldn't be accessed by user '_apt'. - 
pkgAcquire::Run (13: Permission denied)
| I: running --chrooted-customize-hook in shell: sh -c 'dpkg --auto-deconfigure 
--unpack /*.deb'
| (Reading database ... 10384 files and directories currently installed.)
| Preparing to unpack .../libhackrf0_2023.01.1-6_amd64.deb ...
| De-configuring libhackrf0:i386 (2023.01.1-2), to allow configuration of 
libhackrf0:amd64 (2023.01.1-6) ...
| Adding 'diversion of /lib/udev/rules.d/60-libhackrf0.rules to 
/lib/udev/rules.d/60-libhackrf0.rules.usr-is-merged by usr-is-merged'
| Unpacking libhackrf0:amd64 (2023.01.1-6) over (2023.01.1-2) ...
| Processing triggers for libc-bin (2.37-12) ...
| I: running --chrooted-customize-hook in shell: sh -c 'dpkg -r libhackrf0:i386'
| (Reading database ... 10389 files and directories currently installed.)
| Removing libhackrf0:i386 (2023.01.1-2) ...
| Processing triggers for libc-bin (2.37-12) ...
| I: running --chrooted-customize-hook in shell: sh -c 'dpkg --configure -a'
| Setting up libhackrf0:amd64 (2023.01.1-6) ...
| Removing 'diversion of /lib/udev/rules.d/60-libhackrf0.rules to 
/lib/udev/rules.d/60-libhackrf0.rules.usr-is-merged by usr-is-merged'
| Processing triggers for libc-bin (2.37-12) ...
| I: running --customize-hook in shell: sh -c 'test -e 
"$1/lib/udev/rules.d/60-libhackrf0.rules"' exec /tmp/mmdebstrap.NH48tKvp88

Also dumat (Debain Usr Merge Analysis Tool) noticed the
package without reporting any issues.

> Thanks for your attention on this, indeed my lack of attention before
> making uploads is the problem. I am happier with -6 though.

Shit happens. Thanks for quickly resolving the issue. Please go ahead
for unstable.

Helmut

Bug#1057339: dash FTCBFS: host CFLAGS leak into build compiler invocation

[Helmut Grohne]

Source: dash
Version: 0.5.12-6
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-...@lists.debian.org

Hi arm people and Andrej,

this is one of those PAC/BTI "induced" cross build failures. Don't get
me wrong. This problem has always been there. The PAC/BTI work just
makes the bug visible. Still, this is now making quite a lot of packages
failing to cross build. Help appreciated.

Fundamentally, the host compiler flags and -mbranch-protection=standard
leak into a build architecture compiler invocation and that compiler
fails to understand the flag. Often times, we can get away with deleting
compiler flags from build architecture compiler invocations, but dpkg
also supports emitting CFLAGS_FOR_BUILD and friends.

So here is a patch for dash that adds CFLAGS_FOR_BUILD support and thus
solves this instance. I think there are many more of this and appreciate
help with fixing them. Thanks in advance.

Helmut
--- dash-0.5.12.orig/configure.ac
+++ dash-0.5.12/configure.ac
@@ -15,11 +15,17 @@
 AC_MSG_CHECKING([for build system compiler])
 if test "$cross_compiling" = yes; then
 	CC_FOR_BUILD=${CC_FOR_BUILD-cc}
+	CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-}
+	CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-}
 else
 	CC_FOR_BUILD=${CC}
+	CFLAGS_FOR_BUILD=${CFLAGS}
+	CPPFLAGS_FOR_BUILD=${CPPFLAGS}
 fi
 AC_MSG_RESULT(${CC_FOR_BUILD})
 AC_SUBST(CC_FOR_BUILD)
+AC_SUBST(CFLAGS_FOR_BUILD)
+AC_SUBST(CPPFLAGS_FOR_BUILD)
 
 AC_MSG_CHECKING([for __attribute__((__alias__()))])
 dash_cv_have_attribute_alias=no
--- dash-0.5.12.orig/src/Makefile.am
+++ dash-0.5.12/src/Makefile.am
@@ -12,7 +12,7 @@
 COMPILE_FOR_BUILD = \
 	$(CC_FOR_BUILD) $(DEFAULT_INCLUDES) $(AM_CPPFLAGS_FOR_BUILD) \
 	$(CPPFLAGS_FOR_BUILD) \
-	$(CPPFLAGS) $(CFLAGS) $(LDFLAGS) \
+	$(LDFLAGS) \
 	$(AM_CFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD) 
 
 bin_PROGRAMS = dash

Bug#1057338: sddm FTBFS: systemd.pc moved the upstream unit to /usr

[Helmut Grohne]

Source: sddm
Version: 0.20.0-1
Severity: serious
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2

Hi,

I'm sorry for having noticed this late. When we changed the way
systemd.pc places systemd units, we did a partial archive rebuild and
missed out on sddm. On Nov 30th, the changed systemd was uploaded and
ssdm FTBFS since. The upstream unit is now installed to /usr, which
makes debian/rules fail to delete it and this trips up dh_missing. I've
got a patch for you to delete both locations for now. You may delete the
old location once you are sure that you don't want to backport to
bookworm anymore.

Helmut
diff --minimal -Nru sddm-0.20.0/debian/changelog sddm-0.20.0/debian/changelog
--- sddm-0.20.0/debian/changelog2023-06-24 08:38:52.0 +0200
+++ sddm-0.20.0/debian/changelog2023-12-03 07:36:33.0 +0100
@@ -1,3 +1,10 @@
+sddm (0.20.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS: Also ignore /usr-moved upstream systemd unit. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 03 Dec 2023 07:36:33 +0100
+
 sddm (0.20.0-1) unstable; urgency=medium
 
   [ Aurélien COUDERC ]
diff --minimal -Nru sddm-0.20.0/debian/rules sddm-0.20.0/debian/rules
--- sddm-0.20.0/debian/rules2023-02-20 22:44:19.0 +0100
+++ sddm-0.20.0/debian/rules2023-12-03 07:36:31.0 +0100
@@ -30,7 +30,7 @@
 
 execute_after_dh_auto_install:
# not installed, as the Debian version is used instead
-   rm -f $(CURDIR)/debian/tmp/lib/systemd/system/sddm.service
+   rm -f $(CURDIR)/debian/tmp/lib/systemd/system/sddm.service 
$(CURDIR)/debian/tmp/usr/lib/systemd/system/sddm.service
 
 execute_after_dh_fixperms-arch:
# ensure script is marked as executable

Bug#1055253: amanda: diff for NMU version 1:3.5.1-11.1

[Jose M Calhariz]

Thank you for your work.  No need for the delay. 

Kind regards.
Jose M Calhariz


On December 3, 2023 1:14:09 PM GMT+00:00, Tobias Frost  wrote:
>Control: tags 1055253 + patch
>Control: tags 1055253 + pending
>
>Dear maintainer,
>
>I've prepared an NMU for amanda (versioned as 1:3.5.1-11.1) and
>uploaded it to DELAYED/5. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>

Bug#1057332: sponsorship-requests: Bottom/0.9.6 -- A customizable cross-platform graphical process/system monitor for the terminal

[Robin Gustafsson]

Hi Douglas,

On 12/3/23 16:29, Douglas Baggett wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: doug.bagg...@gmail.com

This package `bottom` is **REALLY NICE**.

https://github.com/ClementTsang/bottom

The author has packages for debian already made from nightlys. It should
be easy to include them.

thanks!


Sounds like you may want a "Request for Package" (RFP) [1] instead.

The upstream's .deb files are not sufficient for inclusion in Debian. A 
Debian source package [2,3] is needed.


[1] https://wiki.debian.org/RFP
[2] https://www.debian.org/doc/debian-policy/ch-source.html
[3] https://wiki.debian.org/Packaging/SourcePackage

--
Regards,
Robin

GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057242: bmusb: will FTBFS when udev.pc changes udevdir

[Steinar H. Gunderson]

On Sat, Dec 02, 2023 at 02:32:03AM +0100, Chris Hofstaedtler wrote:
> thank you for forwarding the Makefile changes from #1056997 to upstream.
> The upstream change works as expected.
> 
> However, udev.pc will change udevdir soon. When this happens, bmusb will
> FTBFS. The upstream build system will install the udev rules into the
> new path, but the Debian packaging expects them in the old path.

Oops, sorry! I noticed that 0.26 upstream already had fixed the Makefile
parts, and then noticed a bit too late that you also had debian/ changes in
your patch. :-) I should have made a new upload immediately, of course.

> For your convenience I'm attaching a patch to fix this.

Thank you again! I'll apply it basically except for the author in the
changelog.

> Please apply at your earliest convenience. Per the wiki [1], it is useful
> to first upload to experimental and wait a few days for the dumat tool
> evaluating the change, and only then upload to unstable.

OK.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1052902: yosys: FTBFS: make[2]: *** [Makefile:971: docs/gen_images] Error 2

[Daniel Gröber]

Hi Lucas,

On Thu, Oct 26, 2023 at 09:45:53AM +0200, Lucas Nussbaum wrote:
> As an additional data point, I can still reproduce this.
> I cannot provide the buildinfo, as sbuild outputs it at the end of
> successful builds.

Doh! Didn't think of that. Something to improve in sbuild I guess :)

> However, in the build log there's the list of installed packages, which
> might be sufficient...

Since I've sucessfully rebuilt yosys agains unstable and it's still failing
for you it's pretty much moot. I just thought you'd have the buildinfos at
hand.

I'm essentially waiting for make 4.4 to make it into Debian as Santiago
pointed out it may help track this down, but if I can't repro this (and I
have still never seen this) there's not much I can do without access to a
system this repros on.

If you can reliably reproduce this could you try doing a -j1 rebuild? That
should at least tell us if it's a concurrency issue or not.

--Daniel


signature.asc
Description: PGP signature

Bug#1057337: bpfcc-tools: RPI ARM64 - bpf: invalid return type 8 of func bpf_get_current_task_btf#158

[jojje]

Package: bpfcc-tools
Version: 0.26.0+ds-1
Severity: normal
X-Debbugs-Cc: nos...@rigarco.com

Dear Maintainer,

The -F flag to opensnoop-bpfcc causes probe injection to fail with a hard 
program crash.

To reproduce: `sudo /usr/sbin/opensnoop-bpfcc -F`

Produces:

```text
bpf: Failed to load program: Invalid argument
0: R1=ctx(off=0,imm=0) R10=fp0
0: (bf) r6 = r1   ; R1=ctx(off=0,imm=0) 
R6_w=ctx(off=0,imm=0)
1: (85) call bpf_get_current_pid_tgid#14  ; R0_w=scalar()
2: (7b) *(u64 *)(r10 -8) = r0 ; R0_w=scalar() R10=fp0 fp-8_w=
3: (b7) r8 = 0; R8_w=0
4: (7b) *(u64 *)(r10 -16) = r8; R8_w=0 R10=fp0 fp-16_w=
5: (7b) *(u64 *)(r10 -24) = r8; R8_w=0 R10=fp0 fp-24_w=
6: (7b) *(u64 *)(r10 -32) = r8; R8_w=0 R10=fp0 fp-32_w=
7: (7b) *(u64 *)(r10 -40) = r8; R8_w=0 R10=fp0 fp-40_w=
8: (7b) *(u64 *)(r10 -48) = r8; R8_w=0 R10=fp0 fp-48_w=
9: (7b) *(u64 *)(r10 -56) = r8; R8_w=0 R10=fp0 fp-56_w=
10: (7b) *(u64 *)(r10 -64) = r8   ; R8_w=0 R10=fp0 fp-64_w=
11: (7b) *(u64 *)(r10 -72) = r8   ; R8_w=0 R10=fp0 fp-72_w=
12: (7b) *(u64 *)(r10 -80) = r8   ; R8_w=0 R10=fp0 fp-80_w=
13: (7b) *(u64 *)(r10 -88) = r8   ; R8_w=0 R10=fp0 fp-88_w=
14: (7b) *(u64 *)(r10 -96) = r8   ; R8_w=0 R10=fp0 fp-96_w=
15: (7b) *(u64 *)(r10 -104) = r8  ; R8_w=0 R10=fp0 fp-104_w=
16: (7b) *(u64 *)(r10 -112) = r8  ; R8_w=0 R10=fp0 fp-112_w=
17: (7b) *(u64 *)(r10 -120) = r8  ; R8_w=0 R10=fp0 fp-120_w=
18: (7b) *(u64 *)(r10 -128) = r8  ; R8_w=0 R10=fp0 fp-128_w=
19: (7b) *(u64 *)(r10 -136) = r8  ; R8_w=0 R10=fp0 fp-136_w=
20: (7b) *(u64 *)(r10 -144) = r8  ; R8_w=0 R10=fp0 fp-144_w=
21: (7b) *(u64 *)(r10 -152) = r8  ; R8_w=0 R10=fp0 fp-152_w=
22: (7b) *(u64 *)(r10 -160) = r8  ; R8_w=0 R10=fp0 fp-160_w=
23: (7b) *(u64 *)(r10 -168) = r8  ; R8_w=0 R10=fp0 fp-168_w=
24: (7b) *(u64 *)(r10 -176) = r8  ; R8_w=0 R10=fp0 fp-176_w=
25: (7b) *(u64 *)(r10 -184) = r8  ; R8_w=0 R10=fp0 fp-184_w=
26: (7b) *(u64 *)(r10 -192) = r8  ; R8_w=0 R10=fp0 fp-192_w=
27: (7b) *(u64 *)(r10 -200) = r8  ; R8_w=0 R10=fp0 fp-200_w=
28: (7b) *(u64 *)(r10 -208) = r8  ; R8_w=0 R10=fp0 fp-208_w=
29: (7b) *(u64 *)(r10 -216) = r8  ; R8_w=0 R10=fp0 fp-216_w=
30: (7b) *(u64 *)(r10 -224) = r8  ; R8_w=0 R10=fp0 fp-224_w=
31: (7b) *(u64 *)(r10 -232) = r8  ; R8_w=0 R10=fp0 fp-232_w=
32: (7b) *(u64 *)(r10 -240) = r8  ; R8_w=0 R10=fp0 fp-240_w=
33: (7b) *(u64 *)(r10 -248) = r8  ; R8_w=0 R10=fp0 fp-248_w=
34: (7b) *(u64 *)(r10 -256) = r8  ; R8_w=0 R10=fp0 fp-256_w=
35: (7b) *(u64 *)(r10 -264) = r8  ; R8_w=0 R10=fp0 fp-264_w=
36: (7b) *(u64 *)(r10 -272) = r8  ; R8_w=0 R10=fp0 fp-272_w=
37: (7b) *(u64 *)(r10 -280) = r8  ; R8_w=0 R10=fp0 fp-280_w=
38: (7b) *(u64 *)(r10 -288) = r8  ; R8_w=0 R10=fp0 fp-288_w=
39: (7b) *(u64 *)(r10 -296) = r8  ; R8_w=0 R10=fp0 fp-296_w=
40: (7b) *(u64 *)(r10 -304) = r8  ; R8_w=0 R10=fp0 fp-304_w=
41: (7b) *(u64 *)(r10 -312) = r8  ; R8_w=0 R10=fp0 fp-312_w=
42: (85) call bpf_ktime_get_ns#5  ; R0=scalar()
43: (bf) r7 = r0  ; R0=scalar(id=1) R7_w=scalar(id=1)
44: (18) r1 = 0xff81135c7c00  ; R1_w=map_ptr(off=0,ks=8,vs=32,imm=0)
46: (bf) r2 = r10 ; R2_w=fp0 R10=fp0
47: (07) r2 += -8 ; R2_w=fp-8
48: (85) call bpf_map_lookup_elem#1   ; 
R0_w=map_value_or_null(id=2,off=0,ks=8,vs=32,imm=0)
49: (bf) r9 = r0  ; 
R0_w=map_value_or_null(id=2,off=0,ks=8,vs=32,imm=0) 
R9_w=map_value_or_null(id=2,off=0,ks=8,vs=32,imm=0)
50: (15) if r9 == 0x0 goto pc+80  ; R9_w=map_value(off=0,ks=8,vs=32,imm=0)
51: (bf) r3 = r9  ; R3_w=map_value(off=0,ks=8,vs=32,imm=0) 
R9_w=map_value(off=0,ks=8,vs=32,imm=0)
52: (07) r3 += 8  ; R3_w=map_value(off=8,ks=8,vs=32,imm=0)
53: (bf) r1 = r10 ; R1_w=fp0 R10=fp0
54: (07) r1 += -288   ; R1_w=fp-288
55: (b7) r2 = 16  ; R2_w=16
56: (85) call bpf_probe_read_kernel#113   ; R0=scalar() fp-280= 
fp-288=
57: (79) r3 = *(u64 *)(r9 +24); R3_w=scalar() 
R9=map_value(off=0,ks=8,vs=32,imm=0)
58: (7b) *(u64 *)(r10 -320) = r6  ; R6=ctx(off=0,imm=0) R10=fp0 fp-320_w=ctx
59: (bf) r6 = r7  ; R6_w=scalar(id=1) R7=scalar(id=1)
60: (bf) r7 = r10 ; R7_w=fp0 R10=fp0
61: (07) r7 += -268   ; R7_w=fp-268
62: (bf) r1 = r7  ; R1_w=fp-268 R7_w=fp-268
63: (b7) r2 = 255 ; R2_w=255
64: (85) call bpf_probe_read_user_str#114 ; 

Bug#1055147: seahorse-adventures: No keypress recognised

[Markus Koschany]

Hi Francesco,

Am Sonntag, dem 03.12.2023 um 17:42 +0100 schrieb Francesco Ariis:
> Il 03 dicembre 2023 alle 17:14 Markus Koschany ha scritto:
> > I spoke too soon. Tested the wrong Debian release. So it appears the
> > underlying
> > problem is in python3-pygame which changed significantly between Bullseye
> > and
> > Bookworm but I'm not sure how I can fix this in seahorse-adventures right
> > now. 
> 
> I managed to get keydown working like this:
> - in /usr/share/games/seahorse-adventures/lib/menu.py
> - go to line 119
> - substitute
>     if e.type is USEREVENT and e.action == 'down':
>   with
>     if e.type == USEREVENT and e.action == 'down':
> - keydown will work again

Thanks a lot for the report and your proposed patch. As soon as I'm back home
tomorrow, I'll give it a try. Thanks for mentioning the other seahorse-
adventures fork. Maybe there are even more improvements. I'll check that too.

Best,

Markus



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

Bug#1053509: shasta: autopkgtest regression on arm64: is memory suddenly not enough?

[Étienne Mollier]

Hi Paul,
> 1) why does it now suddenly start to (nearly always) fail across the 
> board on arm64 (in Debian, Ubuntu still seems fine), without changes to 
> the infrastructure that I know of?

I'm afraid I'm not sure what is up with shasta eating up more
memory on arm64 hosts of CI infrastructure.  What I can see from
my end is that the test roughly requires 8GiB of anonymous
memory to map for doing its job.  Except that, this is already
the case for shasta in bookworm running on bookworm kernel, so
that doesn't look to be a regression per se.

> 2) do you also believe this is related to memory consumption?

The problem you mentioned, where shasta explicitly gives up when
running into memory limits, is reproducible when I disable the
swap on an 8GiB machine that I have at hand.  I attempted to
play with /proc/sys/vm/overcommmit_* settings, but my swap at t
time was too big (10GiB) to give me the granularity necessary to
check whether I could get somewhere with improper overcommit
memory tuning.  In any cases, the "Killed" status suggest
overcommit is active (or heuristic) on your end for at least
some of the hosts.

Per chance, could you double check the memory settings on the CI
hosts, just in case, to make sure that the swap didn't drop off
the machine?  Or maybe check for memory overcommit settings
inconsistencies?

Currently readable test logs suggest that:

  * ci-worker-arm64-10 met memory requirements in November,
  * ci-worker-arm64-07 did not meet requirements in October,
  * ci-worker-arm64-08 did not meet requirements in October,
  * ci-worker-arm64-03 did not meet requirements in October.

So this may already be resolved, in case you changed something
in between.

> 3) If 2 == yes, what are the memory requirements for the test? The test 
> *could* test for that before it starts and bail out (restriction: 
> skippable with exit code 77 [2]) if the amount of memory available is 
> too small.

It shouldn't hurt I guess.  I think I can bolt something reading
the memory commit capacity and usage in /proc/meminfo at the
beginning of the test, and skip the run if the testbed couldn't
meet the memory requirement for whatever reason.  Note this may
involve some trial and error.

Have a nice Sunday,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: Ghost - Avalanche


signature.asc
Description: PGP signature

Bug#1057336: RM: rust-exa -- ROM; replace by eza

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-...@packages.debian.org
Control: affects -1 + src:rust-exa

Hello

exa isn't maintained. it has been replaced by eza.
Please remove exa.

thanks
Sylvestre

Bug#1057327: amanda 3.5.1-11+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057327 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: amanda
Version: 3.5.1-11+deb12u1

Explanation: fix local privilege escalation [CVE-2023-30577]

Bug#1057325: qemu 7.2+dfsg-7+deb12u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057325 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: qemu
Version: 7.2+dfsg-7+deb12u3

Explanation: update to upstream stable release 7.2.7; hw/scsi/scsi-disk: 
Disallow block sizes smaller than 512 [CVE-2023-42467]

Bug#1057157: spyder 5.4.2+ds-5+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057157 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: spyder
Version: 5.4.2+ds-5+deb12u1

Explanation: fix interface language auto-configuration

Bug#1057071: rust-sd 0.7.6-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057071 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: rust-sd
Version: 0.7.6-1+deb12u1

Explanation: ensure binary package versions sorts correctly relative to older 
releases (where it was built from a different source package)

Bug#1057038: php-phpseclib3 3.0.19-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057038 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: php-phpseclib3
Version: 3.0.19-1+deb12u1

Explanation: fix debian of service issue [CVE-2023-49316]

Bug#1056987: ca-certificates-java 20230710~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1056987 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: ca-certificates-java
Version: 20230710~deb12u1

Explanation: remove circular dependencies

Bug#1056741: nvidia-open-gpu-kernel-modules 525.147.05-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1056741 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-open-gpu-kernel-modules
Version: 525.147.05-1~deb12u1

Explanation: new upstream release; fix null pointer dereference issue 
[CVE-2023-31022]

Bug#1055147: seahorse-adventures: No keypress recognised

[Francesco Ariis]

Dear Markus,

Il 03 dicembre 2023 alle 15:31 Markus Koschany ha scritto:
> I could not reproduce your problem. The keys work as expected and I can
> navigate the menu and the game without any problems.

Before submitting the bug report I was also able to reproduce the bug
with another person in libera.chat/#debian (alas I forgot the handle
and the channel is not logged).
See also [1].

[1] https://bugs.launchpad.net/ubuntu/+source/seahorse-adventures/+bug/2038853

I don’t know what to do to help debug, but this fork [2] works on my machine
with `python3 run_game.py -full -scale2x`.

[2] https://github.com/dulsi/seahorse-adventures

Bug#1057335: libperl-languageserver-perl: language server exits on error with «Can't "continue" outside a when block»

[Dominique Dumont]

Package: libperl-languageserver-perl
Version: 2.6.1-2
Severity: important

Dear Maintainer,

With the latest package, the language server always exits on error with:

Can't "continue" outside a when block at 
/usr/share/perl5/Perl/LanguageServer/Parser.pm line 181.

I'm using perl language server via emacs and lsp-mode. This bug happens 
whenever a Perl file is loaded.

Looks like a "continue" statement was not cleaned up with perl5.38 patch that 
was added to last release.

I've tried to fix the issue, but I'm a bit lost in the huge if/then/else 
statement. I'll let you fix this.

All the best



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

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

Versions of packages libperl-languageserver-perl depends on:
ii  libanyevent-aio-perl   1.1-2
ii  libanyevent-perl   7.170-2+b3
ii  libclass-refresh-perl  0.07-2
ii  libcompiler-lexer-perl 0.23-3+b1
ii  libcoro-perl   6.570-3+b1
ii  libdata-dump-perl  1.25-1
ii  libencode-locale-perl  1.05-3
ii  libhash-safekeys-perl  0.04-1+b1
ii  libio-aio-perl 4.80-1
ii  libjson-perl   4.1-1
ii  libmoose-perl  2.2206-1
ii  libpadwalker-perl  2.5-1+b3
ii  libscalar-list-utils-perl  1:1.63-1+b1
ii  perl   5.36.0-10
ii  perl-base [libscalar-list-utils-perl]  5.36.0-10

libperl-languageserver-perl recommends no packages.

libperl-languageserver-perl suggests no packages.

-- no debconf information

Bug#1029968: And some patches

[Dr. David Alan Gilbert]

As well as the fixes in 6.6, we also need this patchup series here:

https://lore.kernel.org/linux-media/ZWibhE350L3BTRK8@gallifrey/T/#t

These seem to make it pretty nicely.
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Bug#1055147: seahorse-adventures: No keypress recognised

[Francesco Ariis]

Il 03 dicembre 2023 alle 17:14 Markus Koschany ha scritto:
> I spoke too soon. Tested the wrong Debian release. So it appears the 
> underlying
> problem is in python3-pygame which changed significantly between Bullseye and
> Bookworm but I'm not sure how I can fix this in seahorse-adventures right 
> now. 

I managed to get keydown working like this:
- in /usr/share/games/seahorse-adventures/lib/menu.py
- go to line 119
- substitute
if e.type is USEREVENT and e.action == 'down':
  with
if e.type == USEREVENT and e.action == 'down':
- keydown will work again

Bug#1057249: elki: please package v0.8

[Erich Schubert]

I have been considering to drop the package, simply because all you need 
to get is a single jar file - no installation necessary, and hence there 
is little benefit from having a full Debian package. Because the build 
process is now Gradle instead of Maven, the package build needs to be 
updated. And so far, there is no dependency on elki that I know of.


Regards,
Erich

Am 02.12.23 um 04:52 schrieb Alexandre Detiste:

Source: elki
Version: 0.7.1-10.1
Severity: normal

A new version 0.8 is available:

https://github.com/elki-project/elki/releases/tag/release0.8.0


Please also add a debian/watch file.

Greetings

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1057318: libgit-raw-perl: FTBFS: Failed 2/42 test programs. 15/1768 subtests failed.

[gregor herrmann]

Control: tag -1 + confirmed

On Sun, 03 Dec 2023 12:24:10 +0100, Sebastian Ramacher wrote:

> Source: libgit-raw-perl
> Version: 0.90+ds-1
> Severity: serious
> Tags: ftbfs sid trixie
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> https://buildd.debian.org/status/fetch.php?pkg=libgit-raw-perl=amd64=0.90%2Bds-1%2Bb1=1701602200=0
> 
> Test Summary Report
> ---
> t/08-branch.t (Wstat: 256 (exited 1) Tests: 34 Failed: 1)
>   Failed test:  17
>   Non-zero exit status: 1
> t/19-push.t   (Wstat: 3584 (exited 14) Tests: 80 Failed: 14)
>   Failed tests:  7, 10, 13, 16, 19, 22, 25, 28, 31, 52, 55
> 58, 61, 64
>   Non-zero exit status: 14
> Files=42, Tests=1768,  9 wallclock secs ( 0.32 usr  0.10 sys +  7.37 cusr  
> 1.78 csys =  9.57 CPU)

Yay, libgit2 1.7.1 broke Git-Raw again …


Some investigation:

1) t/08-branch.t is probably broken by this upstream change in libgit2:

* Fixes #6344: git_branch_move now renames the reflog instead of deleting
  by @arroz in https://github.com/libgit2/libgit2/pull/6345

t/08-branch.t ... 
ok 1 - An object of class 'Git::Raw::Commit' isa 'Git::Raw::Commit'
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12 - An object of class 'Git::Raw::Commit' isa 'Git::Raw::Commit'
ok 13
ok 14
ok 15
ok 16
not ok 17

#   Failed test at t/08-branch.t line 54.
#  got: '2'
# expected: '1'
ok 18
ok 19
ok 20 - An object of class 'Git::Raw::Signature' isa 'Git::Raw::Signature'
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
ok 34
1..34
# Looks like you failed 1 test of 34.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/34 subtests 

I checked that `git reflog some_branch' in t/test_repo has indeed 2
entries in sid (libgit2 1.7.1) and 1 entry in trixie (libgit 1.5.1).



2) t/19-push.t is a bit weird, I've seen varying counts of failing
tests, between 0 (!) and the 14 quoted above and just now 28, with
all kinds of numbers in the `got' output; e.g.:

t/19-push.t . 
ok 1
ok 2 - An object of class 'Git::Raw::Remote' isa 'Git::Raw::Remote'
ok 3
ok 4
ok 5
ok 6
not ok 7

#   Failed test at t/19-push.t line 34.
#  got: '2'
# expected: '1'
ok 8
ok 9
not ok 10

#   Failed test at t/19-push.t line 34.
#  got: '3'
# expected: '1'
ok 11
ok 12
not ok 13

#   Failed test at t/19-push.t line 34.
#  got: '4'
# expected: '1'
ok 14
ok 15
not ok 16

#   Failed test at t/19-push.t line 34.
#  got: '16'
# expected: '1'
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
not ok 34

#   Failed test at t/19-push.t line 73.
#  got: '2'
# expected: '1'
ok 35
ok 36
not ok 37

#   Failed test at t/19-push.t line 73.
#  got: '12'
# expected: '1'
ok 38
ok 39
ok 40
ok 41
ok 42
ok 43
ok 44
ok 45
ok 46
ok 47
ok 48
ok 49
ok 50
ok 51
ok 52
ok 53
# remote push tests require network
1..53
# Looks like you failed 6 tests of 53.
Dubious, test returned 6 (wstat 1536, 0x600)
Failed 6/53 subtests 


Maybe this is a timing issue?


What the test does is

#v+
24  my $total_packed = 0;
25  is $remote -> upload(['refs/heads/main:refs/heads/main'], {
26  'callbacks' => {
27  'pack_progress' => sub {
28  my ($stage, $current, $total) = @_;
29  
30  ok ($stage == 
Git::Raw::Packbuilder->ADDING_OBJECTS ||
31  $stage == 
Git::Raw::Packbuilder->DELTAFICATION);
32  if ($stage == 
Git::Raw::Packbuilder->ADDING_OBJECTS)
33  {
34  is $current, 1;
35  is $total, 0;
36  }
37  else
38  {
39  ok ($current <= $total);
40  ok ($total > 0);
41  }
42  $total_packed++;
43  }
44  }
45  }), 1;
46  ok ($total_packed > 0);
#v-

and pack_progress is a callback which does

   pack_progress
   During the packing of new data, this will regularly be called
   with the progress of the pack operation. Be aware that this is
   called inline with pack building operations, so performance
   may be affected. The callback receives the following integers:
   $stage, $current and $total.


With some `diag()' sprinkled in I get:

t/19-push.t . 
ok 1
ok 2 - An object of class 'Git::Raw::Remote' isa 'Git::Raw::Remote'
# pack_progress: stage 0, current: 1, total: 0