date:20240509

package release.debian.org
tags 1070670 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: shim-helpers-i386-signed
Version: 1+15.8+1~deb11u1

Explanation: rebuild against shim 15.8.1

Bug#1070670: shim-helpers-arm64-signed 1+15.8+1~deb11u1 flagged for acceptance

package release.debian.org
tags 1070670 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: shim-helpers-arm64-signed
Version: 1+15.8+1~deb11u1

Explanation: rebuild against shim 15.8.1

Bug#1070660: shim-helpers-i386-signed 1+15.8+1~deb12u1 flagged for acceptance

package release.debian.org
tags 1070660 = 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: shim-helpers-i386-signed
Version: 1+15.8+1~deb12u1

Explanation: rebuild against shim 15.8.1

Bug#1070670: shim-helpers-amd64-signed 1+15.8+1~deb11u1 flagged for acceptance

package release.debian.org
tags 1070670 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: shim-helpers-amd64-signed
Version: 1+15.8+1~deb11u1

Explanation: rebuild against shim 15.8.1

Bug#1070660: shim-helpers-arm64-signed 1+15.8+1~deb12u1 flagged for acceptance

package release.debian.org
tags 1070660 = 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: shim-helpers-arm64-signed
Version: 1+15.8+1~deb12u1

Explanation: rebuild against shim 15.8.1

Bug#1070660: shim-helpers-amd64-signed 1+15.8+1~deb12u1 flagged for acceptance

package release.debian.org
tags 1070660 = 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: shim-helpers-amd64-signed
Version: 1+15.8+1~deb12u1

Explanation: rebuild against shim 15.8.1

Bug#982601: python3-paraview Conflicts: python3-vtk9

Control: affects -1 + facet-analyser
Control: block 1040334 by -1

[Alastair McKinstry 2021-02-12]
> Especially as I plan on getting paraview back working with the normal 
> python3-vtk9
> for the next release.

Any idea when this will happen?  This Conflicts make facet-analyser
unbuildable, see https://bugs.debian.org/1040334 >.

It also point to https://bugs.debian.org/654839 >, which seem to
be a duplicate of this issue.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070807: konsole: Konsole did not close redundant FDs when creating shell process in terminal session

2024-05-09 Thread Anthony Lee

Dear Maintainer,

This may not be Konsole's bug.

By deep dive into the problem, I found those redundant FDs were coming from
kwin_wayland, the wayland implementation of KWin. Today I tried to start a
Konsole Terminal in another desktop environment rather than KDE Plasma, and
the redundant FDs problem did not reproduce this time.

So you may close this bug ticket.

So this

On Thu, 09 May 2024 22:11:48 +0800 anthony  wrote:

> Package: konsole

> Version: 4:23.08.1-1+b1

> Severity: important

> X-Debbugs-Cc: lkphantom1...@gmail.com

>

> Dear Maintainer,

>

> * What led up to the situation?

> The terminal did not close redundant FDs when creating shell process.

> * What exactly did you do (or not do) that was effective (or

> ineffective)?

> * What was the outcome of this action?

> The shell process has many unexpected redundant FDs, and those FDs

> were inherit from konsole.

> * What outcome did you expect instead?

> The terminal emulator should not leave any redundant FDs for shell

> process.

>

> Today I found my Zsh comes with 157 FDs, in common sense zsh won't

> create such large amount open files. Then I tried command

> 'konsole -e /bin/sleep 1', even through, the sleep process also

> has 100+ FDs that shouldn't exists.

>

> By comparing the FDs' number, those FDs were inherit from konsole.

>

> I thought you may close redundant FDs before creating shell process,

> or use CLOEXEC flag.

>

>

> This is my test output in konsole:

> % uname -r

> 6.1.27.xeon.ll

> % ls /proc/self/fd | wc -l

> 157

> % ls /proc/$PPID/fd | wc -l

> 179

> % cat /proc/$PPID/cmdline| tr '\0' ' '

> /usr/bin/konsole --new-tab

> %

>

>

> -- System Information:

> Debian Release: trixie/sid

> APT prefers testing

> APT policy: (500, 'testing')

> Architecture: amd64 (x86_64)

>

> Kernel: Linux 6.1.27.xeon.ll (SMP w/8 CPU threads; PREEMPT)

> Kernel taint flags: TAINT_USER

> 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 konsole depends on:

> ii kio 5.107.0-1+b2

> ii konsole-kpart 4:23.08.1-1+b1

> ii libc6 2.37-19

> ii libkf5configcore5 5.107.0-1+b2

> ii libkf5configwidgets5 5.107.0-2+b2

Bug#967941: nautilus: fails to generate thumbnails for h264 encoded video files

On Thu, 22 Oct 2020 22:08:37 +0100 Simon McVittie 
wrote:
> Control: reassign 967941 libopenblas0-pthread 0.3.10+ds-2
> Control: affects 967941 + nautilus totem
> 
> On Thu, 22 Oct 2020 at 21:31:41 +0200, Thorsten Ehlers wrote:
> > So I dug a little bit deeper into this bug
> 
> Please include some context in replies to bugs: package maintainers
will
> usually see your messages out of context.
> 
> For the libopenblas0-pthread maintainers: the original bug report is
that
> h.264 video files were not thumbnailed successfully by GNOME's
Nautilus
> file manager. The actual thumbnailing is delegated to
> totem-video-thumbnailer, from the totem package.
> 
> I can reproduce this with the sample videos from the original bug
report
> after installing libopenblas0-pthread. After removing libopenblas0-
pthread,
> the alternative switches to /usr/lib/x86_64-linux-
gnu/atlas/libblas.so.3
> and the thumbnailer works again.
> 
> Steps to reproduce:
> 
> $ sudo apt install totem libopenblas0-pthread youtube-dl
> $ youtube-dl https://www.youtube.com/watch?v=LTvFsTbyILg
> $ youtube-dl https://www.youtube.com/watch?v=l7GX_XII2K0
> $ totem-video-thumbnailer -v Yosemite\ Nature\ Drone\ Video-
LTvFsTbyILg.webm tmp.png
> (succeeds)
> $ totem-video-thumbnailer -v Beautiful\ Nature\ 1080p.-
l7GX_XII2K0.mkv tmp.png
> 
> Output:
> 
> TotemVideoThumbnailer-Message: 22:02:21.412: Initialised libraries,
about to create video widget
> TotemVideoThumbnailer-Message: 22:02:21.436: setting URI
file:///home/smcv/tmp/Beautiful%20Nature%201080p.-l7GX_XII2K0.mkv
> TotemVideoThumbnailer-Message: 22:02:21.437: Video widget created
> TotemVideoThumbnailer-Message: 22:02:21.437: About to open video file
> TotemVideoThumbnailer-Message: 22:02:21.713: Checking whether file
has cover
> TotemVideoThumbnailer-Message: 22:02:21.713: Opened video file:
'Beautiful Nature 1080p.-l7GX_XII2K0.mkv'
> TotemVideoThumbnailer-Message: 22:02:21.713: About to seek to
0.33
> TotemVideoThumbnailer-Message: 22:02:21.757: About to get frame for
iter 0
> 
> (totem-video-thumbnailer:98347): GStreamer-WARNING **: 22:02:21.758:
failed to create thread: Error creating thread: Resource temporarily
unavailable
> 
> (totem-video-thumbnailer:98347): GLib-ERROR **: 22:02:21.763:
../../../glib/gmem.c:112: failed to allocate 3145167 bytes
> [1]    98347 trace trap (core dumped)  totem-video-thumbnailer -v
Beautiful\ Nature\ 1080p.-l7GX_XII2K0.mkv tmp.png
> 
> > and in my case it turned out
> > the real problem is libopenblas0-pthread version 0.3.10+ds-2 and -
3.
> > 
> > This package is a dependency of libopenblas0 which is a dependency
of Octave and others.
> > 
> > Creating a thumbnail with totem-video-thumbnailer fails for flv and
mkv videos like that one mentioned by the OP:
> > 
> > (totem-video-thumbnailer:37500): GStreamer-WARNING **:
21:23:41.129: failed to create thread: Error creating thread: Die
Ressource ist zur Zeit nicht verfügbar
> > 
> > (totem-video-thumbnailer:37500): GLib-ERROR **: 21:23:41.131:
../../../glib/gmem.c:112: failed to allocate 3145167 bytes
> > Trace/Breakpoint ausgelöst
> > 
> > Installing libopenblas0-pthread_0.3.10+ds-1 or adding the -l option
in /usr/share/thumbnailers/totem.thumbnailer works
> > around this bug.
> 
> The -l option is documented to disable the time limit for thumbnail


the OpenBLAS FAQ tells:
https://github.com/OpenMathLib/OpenBLAS/wiki/faq#multi-threaded "
If your application is already multi-threaded, it will conflict with
OpenBLAS multi-threading. Thus, you must set OpenBLAS to use single
thread as following.
  - export OPENBLAS_NUM_THREADS=1 in the environment variables. Or
  - Call openblas_set_num_threads(1) in the application on runtime. Or
"

Would adding openblas_set_num_threads(1) to totem-resource.c be fine?
Wouldn't it add  a hard dependency to openblas on totem?
Should the ffmpeg or gstreamer provide an API to set this openblas
number or thread to 1 in case the application is multi-threaded (I
believe totem is multi-threaded) to avoid adding such hard dependency
in the upper layers if they don't already provides such an API?


totem might requiring tweaking the openblas settings as:
- not working:
LC_ALL=C totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ Story\ Trailer\ 
#2\ \(Official\)\ \[sC9abcLLQpI\].mp4 a.png

(totem-video-thumbnailer:1576790): GLib-ERROR **: 05:17:03.908: 
../../../glib/gmem.c:106: failed to allocate 3110543 bytes
Trappe pour point d'arrêt et de trace (core dumped)

- working:
OPENBLAS_NUM_THREADS=1 totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ 
Story\ Trailer\ #2\ \(Official\)\ \[sC9abcLLQpI\].mp4 a.png

and:
OPENBLAS_NUM_THREADS= from 1 to 3 is fine, starting at 4 totem errors out with:
OPENBLAS_NUM_THREADS=4 totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ 
Story\ Trailer\ #2\ \(Official\)\ \[sC9abcLLQpI\].mp4 a.png

(totem-video-thumbnailer:1576943): GLib-ERROR **: 05:17:26.026: 
../../../glib/gmem.c:106: failed to allocate 3404718 bytes
Trappe pour point d'arrêt et de t

Bug#1070830: hardinfo had change git repo to https://github.com/hardinfo2/hardinfo2

2024-05-09 Thread xiao sheng wen

Package: hardinfo
Severity: minor
Tags: upstream
X-Debbugs-Cc: u...@atzlinux.com, atzli...@sina.com

Hi,

 From current hardinfo package homepage http://hardinfo.org,
it redirect to his git repo: https://github.com/lpereira/hardinfo

This old git repo had say:

The development continues in the @hardinfo2/hardinfo2 repository:

https://github.com/hardinfo2/hardinfo2

I suggest change upstream to this git repo, update homepage to

https://www.hardinfo2.org/

and release new upstream version.

Thanks!

atzlinux



-- System Information:
Codename:   bookworm
Architecture: x86_64

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

Versions of packages hardinfo depends on:
ii  libc62.36-9+deb12u7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libgtk2.0-0  2.24.33-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libsoup2.4-1 2.74.3-1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  pciutils 1:3.9.0-4
ii  sysbench 1.0.20+ds-5
ii  usb.ids  2024.03.18-1
ii  zlib1g-dev   1:1.2.13.dfsg-1

Versions of packages hardinfo recommends:
ii  lm-sensors  1:3.6.0-7.1

Versions of packages hardinfo suggests:
ii  mesa-utils  8.5.0-1

-- no debconf information

Bug#1070829: ITP: wprs -- rootless remote desktop access for remote Wayland and x11 applications like xpra

2024-05-09 Thread debian

Package: wnpp
Subject: ITP: wprs -- rootless remote desktop access for remote Wayland and X11 
applications like xpra
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Yifei Zhan 
Severity: wishlist

* Package name: wprs
  Version : 0.1.0
  Upstream Contact: Nicolas Avrutin 
* URL : https://github.com/wayland-transpositor/wprs
* License : Apache 2.0
  Programming Lang: Rust
  Description : rootless remote desktop access for remote Wayland (and X11, 
via XWayland) applications like xpra

wprs implements rootless remote desktop access for remote Wayland (and X11, via
XWayland) applications with supports for session resumption (running
applications will survive wprsc disconnection and later reconnection and wprsc
restarts). Currently only the the Core and XDG shell protocols are implemented
and hardware rendering/dmabuf support is not yet implemented.  Generally, wprs
will aim to support as many protocols as feasible, it's a question of time and
prioritization.

Bug#986432: totem: segfault when opening totem

On Mon, 19 Apr 2021 16:31:34 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
 wrote:
> Dear Maintainer,
> I tried to have a look and I could reproduce the crash [1].
> 
> I think this is caused by a call to gtk_list_store_set
> in totem_playlist_steal_current_starttime [2].
> There a variadic argument list contains a plain 0,
> which might occupy just 32 bit, but gets later interpreted
> as gint64, therefore the terminating -1 gets overrun.
> 
> A totem package rebuilt with attached patch does not show
> the crash inside the test VM.
> 
> Kind regards,
> Bernhard


Could you submit a MR upstream for your 32 bits arch patch for totem
(critical to armhf use)?
https://gitlab.gnome.org/GNOME/totem/-/issues

The issue is still
there 
https://gitlab.gnome.org/GNOME/totem/-/blob/master/src/totem-playlist.c?ref_type=heads#L1734

> 
> [1]
>  (gdb) bt
>  #0  strlen () at ../sysdeps/arm/armv6t2/strlen.S:126
>  #1  0xb6e82878 in g_strdup (str=0x63fca6aa ) at ../../../glib/gstrfuncs.c:363
>  #2  0xb6f47144 in value_collect_string (value=0xbeffee60,
n_collect_values=, collect_values=,
collect_flags=) at ../../../gobject/gvaluetypes.c:293
>  #3  0xb680a3be in gtk_list_store_set_valist_internal
(list_store=list_store@entry=0xa0b4c8, iter=iter@entry=0xbeffef44,
emit_signal=emit_signal@entry=0xbeffeefc,
maybe_need_sort=maybe_need_sort@entry=0xbeffef00, var_args=...,
var_args@entry=...) at ../../../../gtk/gtkliststore.c:1033
>  #4  0xb680ab52 in gtk_list_store_set_valist
(list_store=0xa0b4c8, iter=iter@entry=0xbeffef44, var_args=...,
var_args@entry=...) at ../../../../gtk/gtkliststore.c:1137
>  #5  0xb680ac1a in gtk_list_store_set (list_store=, iter=0xbeffef44) at ../../../../gtk/gtkliststore.c:1179
>  #6  0xb6f91c40 in totem_playlist_steal_current_starttime
(playlist=0xa1e100) at ../src/totem-playlist.c:1790
>  #7  0xb6f8b590 in update_seekable (totem=0x450140) at
../src/totem-object.c:2524
>  #8  property_notify_cb_seekable (bvw=,
spec=, totem=0x450140) at ../src/totem-object.c:2616
>  #9  0xb6f2b252 in g_closure_invoke (closure=0x6e7048,
return_value=return_value@entry=0x0, n_param_values=2,
param_values=param_values@entry=0xbefff090,
invocation_hint=invocation_hint@entry=0xbefff00c) at
../../../gobject/gclosure.c:810
>  #10 0xb6f38768 in signal_emit_unlocked_R
(node=node@entry=0x448800, detail=105, instance=0xa6e290,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0xbefff090) at
../../../gobject/gsignal.c:3739
>  #11 0xb6f3ce12 in g_signal_emit_valist
(instance=instance@entry=0xa6e290, signal_id=signal_id@entry=1,
detail=detail@entry=320612, var_args=..., var_args@entry=...) at
../../../gobject/gsignal.c:3495
>  #12 0xb6f3d0a2 in g_signal_emit
(instance=instance@entry=0xa6e290, signal_id=signal_id@entry=1,
detail=105) at ../../../gobject/gsignal.c:3551
>  #13 0xb6f2e33e in g_object_dispatch_properties_changed
(object=0xa6e290, n_pspecs=1, pspecs=) at
../../../gobject/gobject.c:1206
>  #14 0xb6f2faac in g_object_notify_by_spec_internal
(pspec=, object=0xa6e290) at
../../../gobject/gobject.c:1299
>  #15 g_object_notify (object=0xa6e290, property_name=) at ../../../gobject/gobject.c:1347
>  #16 0xb6f9b9ec in got_time_tick (time_nanos=,
bvw=bvw@entry=0xa6e290, play=) at ../src/backend/bacon-
video-widget.c:2614
>  #17 0xb6f9ca02 in bvw_query_timeout (bvw=bvw@entry=0xa6e290) at
../src/backend/bacon-video-widget.c:2830
>  #18 0xb6fa0792 in bvw_bus_message_cb (bus=,
message=, bvw=0xa6e290) at ../src/backend/bacon-video-
widget.c:2485
>  #19 0xb6f2d2e8 in g_cclosure_marshal_VOID__BOXEDv
(closure=0xaaf750, return_value=, instance=0x9f8bf0,
args=..., marshal_data=0x0, n_params=1, param_types=0x7d1118) at
../../../gobject/gmarshal.c:1686
>  #20 0xb6f2b3d8 in _g_closure_invoke_va
(closure=closure@entry=0xaaf750, return_value=0x0, instance=0x9f8bf0,
instance@entry=0x0, args=..., args@entry=...,
n_params=n_params@entry=1, param_types=0x7d1118) at
../../../gobject/gclosure.c:873
>  #21 0xb6f3cef6 in g_signal_emit_valist (instance=0x0,
instance@entry=0x9f8bf0, signal_id=, detail=0,
detail@entry=3204445364, var_args=..., var_args@entry=...) at
../../../gobject/gsignal.c:3404
>  #22 0xb6f3d0a2 in g_signal_emit
(instance=instance@entry=0x9f8bf0, signal_id=,
detail=289) at ../../../gobject/gsignal.c:3551
>  #23 0xb64b1420 in gst_bus_async_signal_func (bus=0x9f8bf0,
message=0xa5405068, data=) at ../gst/gstbus.c:1295
>  #24 0xb64b2008 in gst_bus_source_dispatch (source=0xa8a388,
callback=0xb64b13e5 , user_data=0x0) at
../gst/gstbus.c:851
>  #25 0xb6e6bf4c in g_main_dispatch (context=0x46e678) at
../../../glib/gmain.c:3325
>  #26 g_main_context_dispatch (context=context@entry=0x46e678) at
../../../glib/gmain.c:4043
>  #27 0xb6e6c1e0 in g_main_context_iterate
(context=context@entry=0x46e678, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
../../../glib/gmain.c:4119
>  #28 0xb6e6

Bug#984639: totem-video-thumbnailer: segfault in totem-video-thumbnailer

On Sat, 06 Mar 2021 11:30:43 +0200 Svjatoslav Agejenko
 wrote:
> Package: totem-video-thumbnailer
> Version: totem
> Severity: important
> X-Debbugs-Cc: svjatos...@svjatoslav.eu
> 
> Dear Maintainer,
> 
> Video thumbnails are not shown in GNOME files.
> dmesg output shows errors like this:
> 
> [  173.111788] qtdemux0:sink[5358]: segfault at 0 ip 
sp
> 7f0ef9d45d18 error 14 in totem-video-
thumbnailer[56461b0f5000+3000]
> [  173.111806] Code: Unable to access opcode bytes at RIP
0xffd6.
> [  174.064475] qtdemux0:sink[5395]: segfault at 0 ip 
sp
> 7f50d5f0fd18 error 14 in totem-video-
thumbnailer[55c85c214000+3000]
> [  174.064483] Code: Unable to access opcode bytes at RIP
0xffd6.
> 
> Video thumbnails functionality worked well in Debian 10.
> It is now broken in Debian 11.

This is likely a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973942

Can you try to reproduce the segfault from command line by running:
/usr/bin/totem-video-thumbnailer --verbose --gst-debug-level=3 -s 256  test.png
you should get something like:
 LC_ALL=C totem-video-thumbnailer Rogue\ One：\ A\ Star\ Wars\ Story\ Trailer\ 
#2\ \(Official\)\ \[sC9abcLLQpI\].mp4 c.png

"(totem-video-thumbnailer:1553984): GLib-ERROR **: 03:32:05.259: 
../../../glib/gmem.c:106: failed to allocate 3110543 bytes
Trappe pour point d'arrêt et de trace (core dumped)"
or even only
"Processus stopped"

You could then try if 
/usr/bin/totem-video-thumbnailer -l --verbose --gst-debug-level=3 -s 256  test.png
indeed succeed when the former did not.
Then it will point at a  likely upstream choice to sandbox the totem
video thumbanilera bit too much, at least to get old codec decoded.
We should investigate if the issue was already rejected upstream. If
not open a bug report to have them raise the limit.

The segfault in my case was caused by the totem thumbaniler resource
sandbox too low which lead to failure to spawn thread and alocate
memory ending in a segfault.

Note: Without the internal totem limit on the resource usage the
thumbnailing is really fast on this box, no way it could reach the 30
seconds limit. So I suppose the cpu and memory limits are at fault.

I tried removing libopenblas0-pthread as suggested by
https://blog.frehi.be/2021/06/19/missing-video-thumbnails-in-nautilus-in-debian-bullseye/
but the removal installed libopenblas0-openmp with which totem-video-
thumnailer still failed only with the "Processus stopped" error.

Cheers,
Alban

Bug#1070474: time sync overflows on ARCH armhf(Debian 12, bookworm) with systemd-timesyncd.service

2024-05-09 Thread Perr Zhang

I debuged the systemd core file:
--
root@archlinux:/# gdb /usr/bin/systemd core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/systemd...
Reading symbols from 
/usr/lib/debug/.build-id/08/012654d6118a0fa2d1b816477ee009edee155f.debug...

warning: exec file is newer than core file.
[New LWP 23696]
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `/sbin/init earlyprintk'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb6b674c8 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
120 ../sysdeps/unix/syscall-template.S: No such file or directory.
[Current thread is 1 (LWP 23696)]
(gdb) thread apply all bt

Thread 2 (Thread 0xb69b6d00 (LWP 1)):
warning: Couldn't find general-purpose registers in core file.
Python Exception : Register 13 is not available
#0   in ?? ()

Thread 1 (LWP 23696):
#0  0xb6b674c8 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
#1  0x004220d2 in crash (sig=6, siginfo=, context=) at ../src/core/crash-handler.c:83
#2  
#3  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#4  0xb6b9850c in __pthread_kill_implementation (threadid=3063639296, signo=6, 
no_tid=) at pthread_kill.c:43
#5  0xb6b67322 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#6  0xb6b580ac in __GI_abort () at abort.c:79
#7  0xb6d78d00 in log_assert_failed () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#8  0xb6d8f85e in now () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#9  0xb6d8f8d0 in triple_timestamp_get () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#10 0xb6e08388 in sd_event_wait () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#11 0xb6e0958a in sd_event_run () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-shared-252.so
#12 0xb6f22e68 in manager_loop () from 
/usr/lib/arm-linux-gnueabihf/systemd/libsystemd-core-252.so
#13 0x0041bb6a in invoke_main_loop (ret_error_message=0xbe8e0a3c, 
ret_switch_root_init=, ret_switch_root_dir=, ret_fds=0xbe8e0a34, ret_shutdown_verb=, 
ret_retval=, saved_rlimit_memlock=0xbe8e0a50, 
saved_rlimit_nofile=0xbe8e0a60, m=) at ../src/core/main.c:1904
#14 main (argc=2, argv=0xbe8e0ed4) at ../src/core/main.c:2993
(gdb) 
--

the assert of now() failed at 
https://github.com/systemd/systemd/blob/e8dc52766e1fdb4f8c09c3ab654d1270e1090c8d/src/basic/time-util.c#L53
assert_se(clock_gettime(map_clock_id(clock_id), &ts) == 0); //clock_gettime() 
syscall should failed with EOVERFLOW which means the kernel time exceeds year 
2038 at that time point

Bug#1070828: libslang2: Broken symlink ./usr/lib/libslang.so.2 in debian-installer initrd

2024-05-09 Thread E Shattow

Package: libslang2
Version: 2.3.3-4
Severity: normal
Tags: d-i
X-Debbugs-Cc: luc...@gmail.com

Dear Maintainer,

There's a broken symlink in d-i initrd:

# find -type l -exec test ! -e {} \; -print
./usr/lib/libslang.so.2

# ls -l ./usr/lib/libslang.so.2 ./usr/lib/riscv64-linux-gnu/libslang.so.2 
./usr/lib/riscv64-linux-gnu/libslang.so.2.3.3 
lrwxrwxrwx 1 root root  17 May  9 17:32 ./usr/lib/libslang.so.2 -> 
libslang.so.2.3.2
lrwxrwxrwx 1 root root  17 May  9 17:32 
./usr/lib/riscv64-linux-gnu/libslang.so.2 -> libslang.so.2.3.3
-rw-r--r-- 1 root root 2106736 May  9 17:32 
./usr/lib/riscv64-linux-gnu/libslang.so.2.3.3

https://salsa.debian.org/debian/slang2/-/blob/debian/latest/debian/libslang2-udeb.links?ref_type=heads

libslang2-udeb.links:
usr/lib/libslang.so.2.3.2 usr/lib/libslang.so.2

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

Kernel: Linux 6.9.0-rc7-cmlite-00047-g2dd8e42bb93a (SMP w/4 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libslang2 depends on:
ii  libc6  2.37-18

libslang2 recommends no packages.

libslang2 suggests no packages.

-- no debconf information

Bug#1070827: ITP: libdata-fake-perl -- module for generating fake structured data for testing

2024-05-09 Thread gregor herrmann

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdata-fake-perl
  Version : 0.006
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/Data-Fake
* License : Apache-2.0
  Programming Lang: Perl
  Description : module for generating fake structured data for testing

Data::Fake generates randomized, fake structured data using declarative
syntax.

Data::Fake is built on higher-order programming principles. It provides users
with "factory" functions, which create "generator" functions for specific
pieces of data.

Wherever randomized, fake data is desired, a generator code reference is used
as a placeholder for the desired output. Each time the top-level generator is
run, nested generators are recursively run to turn placeholders into the
desired randomized data.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

Pascal Hambourg wrote:
>
> You could just run grub-install to reinstall GRUB into the new ESP and
> register it in EFI boot variables.

I wanted to try the manual way to learn + to create my EFI boot entry with a 
customized name. I think GRUB installation can only create EFI boot entry with 
the name "debian", or is it possible to change that?

> No, because in manual partitioning it is up to the user to decide which
> ESP(s) is/are suitable for the installation, and set the others as "do
> not use".

So I must have forgotten to set the other ESP as "do not use", stupid me (I 
switched from MBR + BIOS to GPT + UEFI setup not so long ago and I guess it 
shows:). But is there a reason why DI partitioning does not set all (or 
previously existing) ESPs by default to "do not use" and let the user change 
that manually (perhaps with a reminder message if the user forgets to set the 
ESP in UEFI mode)? Maybe it would be more intuitive + it could avoid/minimize 
user errors? Or is a shared ESP so common that DI partitioning needs its 
current defaults?

Anyway, thanks for such a quick reply.

Jmkr

Bug#1070826: totem: Cannot create profiling:/build direcotry errors when quitting totem (even without playback) - Debian packaging?

2024-05-09 Thread Simon McVittie

Control: reassign -1 src:libdmapsharing 3.9.13-1
Control: merge 1055324 -1
Control: found 1055324 3.9.13-2
Control: affects 1055324 + totem

On Fri, 10 May 2024 at 00:07:54 +0200, Alban Browaeys wrote:
> When I open totem then quit it (whatver I dod inside totem even if I do
> nothing), I get this error output on the console.
> It might well be a libdmapsharing library or plugin issue.
...
> profiling:/build:Cannot create directory
> profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-gst-util.gcda:Skip

As the path used suggests, this is a libdmapsharing packaging issue,
see #1055324.

smcv

Bug#1070826: totem: Cannot create profiling:/build direcotry errors when quitting totem (even without playback) - Debian packaging?

Package: totem
Version: 43.0-3+b1
Severity: normal

Dear Maintainer,
When I open totem then quit it (whatver I dod inside totem even if I do
nothing), I get this error output on the console.
It might well be a libdmapsharing library or plugin issue.

I do not get this error from th flatpak of totem:
Vidéos  org.gnome.Totem 
 43.0   stable  
flathub   user
Codecs  org.gnome.Totem.Codecs  
stable  
flathub   user
yt-dl totem-pl-parser plugin
org.gnome.Totem.Videosite.YouTubeDl 
stable  flathub   user


profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-gst-util.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-wav-stream.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-qt-stream.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-mp3-stream.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-transcode-stream.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-mdns-publisher-avahi.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-mdns-browser-avahi.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-mdns-avahi.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-image-record-factory.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-image-record.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-db.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-container-record.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-container-db.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-av-record-factory.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-test-dmap-av-record.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-image-share.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-image-record.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-image-connection.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-utils.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-structure.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-share.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-record-factory.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-record.gcda:Skip
profiling:/build:Cannot create directory
profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-dmap-private-utils.gcda:Sk

Bug#1029007: Bug has reappeared

2024-05-09 Thread Joseph Carter

This bug should've been closed at some point in the past but has reappeared in 
the newer version:

cargo 1.70.0+dfsg2-1
rustc 1.70.0+dfsg2-1

rustc recommends cargo >= 0.71.0~~ and cargo < 0.72.0~~ … The expected solution 
to the problem (merging of the cargo and rustc sources) has already happened, 
so it seems that the thing needed now is some frobbing of substvars for the 
contol file based on the package version? An = versioned recommends based on 
the standard/automatic substvars? Exercise left to rust stakeholders to discuss.

Joseph

Bug#973614: Forwarded to upstream

2024-05-09 Thread Patrick Winnertz


Control: tags -1 + upstream
Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=153406


Hey,
I forwarded that bug upstream so that it will be possible in the future 
to remove libu2f-server.


With best regards
Patrick
--
 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  win...@debian.org/patr...@winnertz.eu
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 8D208172388840811B85DA1CC6D50A4188C70E43
 ⠈⠳⣄

The people who refer to the pandemic in the past tense and climate 
change in the future tense are the reason everything is going to shit.

Bug#1069101: libdbd-oracle-perl: requires rebuild for time_t transition

2024-05-09 Thread Alex Muntada

Hi gregor,

> > The thing is that maybe a hint on libaio will be needed?
> 
> What do you mean be "hint" here?

When I uploaded 1.83-3 the migration to testing was blocked
because oracle-instantclient12.1-devel in B-D was replaced by
oracle-instantclient-devel, and a force hint was needed:

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

I'm wondering if the same thing will happen when replacing
libaio1 with libaio in Depends, since I don't know britney
well enough...

Cheers and thanks for the feedback!
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer 🍥 log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#1070825: libu2f-server is no longer actively developerd and in maintenance mode

2024-05-09 Thread Patrick Winnertz


Source: libu2f-server
Version: 1.1.0-4
Severity: normal
Control: block -1 by 973614

libu2f-server is in maintenance mode, libfido2 is a new project with 
support for U2F and FIDO2 according to the upstream homepage. There is a 
replacement available libfido2. This is a bug to track all packages 
which depends on libu2f-server in order to RoM it after all rdepends are 
gone.


Greetings
Patrick

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

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--
 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  win...@debian.org/patr...@winnertz.eu
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 8D208172388840811B85DA1CC6D50A4188C70E43
 ⠈⠳⣄

The people who refer to the pandemic in the past tense and climate 
change in the future tense are the reason everything is going to shit.

Bug#1066598: FTBFS

2024-05-09 Thread Alexandre Detiste

A Maintained version is here:

http://git.zerfleddert.de/cgi-bin/gitweb.cgi/micropolis

It even includes Markus' patches.

Bug#1069881: bookworm-pu: package systemd/252.24-1~deb12u1

2024-05-09 Thread Luca Boccassi

Control: retitle -1 bookworm-pu: package systemd/252.25-1~deb12u1

On Fri, 26 Apr 2024 11:47:51 +0100 Luca Boccassi 
wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org
> 
> Dear Release Team,
> 
> We would like to upload the latest stable point release of systemd
252
> to bookworm-p-u. Stable release branches are maintained upstream with
> the intention of providing bug fixes only and no compatibility
> breakages, and with automated non-trivial CI jobs that also cover
> Debian and Ubuntu. I have already uploaded to p-u.
> 
> Packaging changes are limited to refreshing patches. Debdiff
attached.
> The list of commits included can be seen at:
> 
> https://github.com/systemd/systemd-stable/compare/v252.23...v252.24

I have uploaded the next point release now, 252.25. Same as before,
just refreshing patches. The debdiff excludes hwdb generated IDs.

List of changes:

https://github.com/systemd/systemd-stable/compare/v252.24...v252.25

-- 
Kind regards,
Luca Boccassi
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.24/debian/changelog systemd-252.25/debian/changelog
--- systemd-252.24/debian/changelog	2024-04-26 01:34:18.0 +0100
+++ systemd-252.25/debian/changelog	2024-05-09 18:11:06.0 +0100
@@ -1,3 +1,10 @@
+systemd (252.25-1~deb12u1) bookworm; urgency=medium
+
+  * New upstream version 252.25
+  * Refresh patches for v252.25
+
+ -- Luca Boccassi   Thu, 09 May 2024 18:11:06 +0100
+
 systemd (252.24-1~deb12u1) bookworm; urgency=medium
 
   * New upstream version 252.24
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.24/debian/patches/debian/Don-t-enable-audit-by-default.patch systemd-252.25/debian/patches/debian/Don-t-enable-audit-by-default.patch
--- systemd-252.24/debian/patches/debian/Don-t-enable-audit-by-default.patch	2024-04-26 01:34:02.0 +0100
+++ systemd-252.25/debian/patches/debian/Don-t-enable-audit-by-default.patch	2024-05-09 18:10:47.0 +0100
@@ -29,7 +29,7 @@
  

 diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index a78e2c0..efeb50c 100644
+index 863575c..1b9b8e1 100644
 --- a/src/journal/journald-server.c
 +++ b/src/journal/journald-server.c
 @@ -2279,7 +2279,7 @@ int server_init(Server *s, const char *namespace) {
diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.24/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch systemd-252.25/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch
--- systemd-252.24/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch	2024-04-26 01:34:02.0 +0100
+++ systemd-252.25/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch	2024-05-09 18:10:47.0 +0100
@@ -16,10 +16,10 @@
  3 files changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
-index 5f4d4b0..cf5e55f 100644
+index 11166f9..b049507 100644
 --- a/src/core/load-fragment.c
 +++ b/src/core/load-fragment.c
-@@ -543,6 +543,7 @@ static int patch_var_run(
+@@ -578,6 +578,7 @@ static int patch_var_run(
  
  const char *e;
  char *z;
@@ -27,7 +27,7 @@
  
  e = path_startswith(*path, "/var/run/");
  if (!e)
-@@ -552,7 +553,8 @@ static int patch_var_run(
+@@ -587,7 +588,8 @@ static int patch_var_run(
  if (!z)
  return log_oom();
  
@@ -51,10 +51,10 @@
  "Please update package to include a native systemd unit file, in order to make it more safe and robust.", fpath);
  
 diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
-index 281284c..8952a26 100644
+index a186246..83f3e5c 100644
 --- a/src/tmpfiles/tmpfiles.c
 +++ b/src/tmpfiles/tmpfiles.c
-@@ -2991,6 +2991,7 @@ static int specifier_expansion_from_arg(const Specifier *specifier_table, Item *
+@@ -2992,6 +2992,7 @@ static int specifier_expansion_from_arg(const Specifier *specifier_table, Item *
  static int patch_var_run(const char *fname, unsigned line, char **path) {
  const char *k;
  char *n;
@@ -62,7 +62,7 @@

Bug#1070824: legiond: depends on lenovolegionlinux-dkms which is in contrib

2024-05-09 Thread Andreas Beckmann

Package: legiond
Version: 0.0.10+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

legiond in main depends on lenovolegionlinux-dkms in contrib, which is
not permitted by the policy.

BTW, why is the -dkms package in contrib?

The -dkms package looks overly complicated:
- the B-D: dkms should be superfluous, since there is dh-sequence-dkms
- aren't preinst and postinst equivalent to what dh_dkms inserts?
- the substitution in dkms.conf can be done by dh_dkms if you use 
  PACKAGE_VERSION="#MODULE_VERSION#"
  and (if ($(UP_VERS) != $(DEB_VERSION_UPSTREAM)))
  override_dh_dkms:
dh_dkms -V $(UP_VERS)

Andreas

Bug#1070823: xorg-gtest: fix FTBFS on Debian sid

Package: xorg-gtest
Version: 0.7.1-8
Severity: important
Tags: patch ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch

Dear Maintainer,

This patch fixes buildability on Debian sid (trixie).
The patch removal is due to upstream reverting the changes:
https://gitlab.freedesktop.org/xorg/test/xorg-gtest/-/commit/03d9896d3152749c68441a6d913a40dd05754082.
You will see the changelog entry mentioning a certain issue gets resolved, and
that issue was resolved by the commit shown above.

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

  - Disable 0005-Properly-escape-the-D-string-defines.patch until upstream
issue https://gitlab.freedesktop.org/xorg/test/xorg-gtest/issues/1 is
resolved, to make compiz buildable again.
  - d/rules: do not build documentation and code in parallel, as this will
break the build system.


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
xorg-gtest-0.7.1/debian/patches/0005-Properly-escape-the-D-string-defines.patch 
xorg-gtest-0.7.1/debian/patches/0005-Properly-escape-the-D-string-defines.patch
--- 
xorg-gtest-0.7.1/debian/patches/0005-Properly-escape-the-D-string-defines.patch 
2022-11-09 15:19:00.0 -0700
+++ 
xorg-gtest-0.7.1/debian/patches/0005-Properly-escape-the-D-string-defines.patch 
1969-12-31 17:00:00.0 -0700
@@ -1,28 +0,0 @@
-From 51a836bf4cafa7fb3d3f71d9cf9b7cb8158a32f2 Mon Sep 17 00:00:00 2001
-From: Peter Hutterer 
-Date: Mon, 13 Jun 2016 13:55:12 +1000
-Subject: [PATCH 5/5] Properly escape the -D string defines
-
-Some compiler change apparently makes this necessary now.
-
-Signed-off-by: Peter Hutterer 

- xorg-gtest.pc.in | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/xorg-gtest.pc.in b/xorg-gtest.pc.in
-index 8fa18a6..612839d 100644
 a/xorg-gtest.pc.in
-+++ b/xorg-gtest.pc.in
-@@ -2,7 +2,7 @@ prefix=@prefix@
- includedir=@includedir@
- sourcedir=@SOURCEDIR@
- datarootdir=@datarootdir@
--CPPflags=-I${includedir} -I${includedir}/xorg -I${sourcedir} 
-DDUMMY_CONF_PATH=\"@DUMMY_CONF_PATH@\" -DLOGFILE_DIR=\"@LOGFILE_DIR@\"
-+CPPflags=-I${includedir} -I${includedir}/xorg -I${sourcedir} 
-D'DUMMY_CONF_PATH=\"@DUMMY_CONF_PATH@\"' -D'LOGFILE_DIR=\"@LOGFILE_DIR@\"'
- 
- Name: xorg-gtest
- Description: X.org Google Test Environment
--- 
-2.18.0
-
diff -Nru xorg-gtest-0.7.1/debian/patches/series 
xorg-gtest-0.7.1/debian/patches/series
--- xorg-gtest-0.7.1/debian/patches/series  2022-11-09 15:19:00.0 
-0700
+++ xorg-gtest-0.7.1/debian/patches/series  2024-05-06 19:36:02.0 
-0600
@@ -5,6 +5,5 @@
 0002-xserver-improve-error-code-reporting.patch
 0003-doc-update-doxygen-file.patch
 0004-doc-remove-DOT_FONTNAME-from-doxygen.in.patch
-0005-Properly-escape-the-D-string-defines.patch
 reproducible-builds.patch
 1001_another-Doxygen-update.patch
diff -Nru xorg-gtest-0.7.1/debian/rules xorg-gtest-0.7.1/debian/rules
--- xorg-gtest-0.7.1/debian/rules   2022-11-09 15:19:00.0 -0700
+++ xorg-gtest-0.7.1/debian/rules   2024-05-06 19:36:02.0 -0600
@@ -12,7 +12,8 @@
  --docdir=/usr/share/doc/libxorg-gtest-doc
 
 override_dh_auto_build:
-   dh_auto_build -- all doc
+   dh_auto_build -- all
+   dh_auto_build -- doc
 
 override_dh_install:
rm -rf debian/tmp/usr/include/gtest

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

2024-05-09 Thread Julian Gilbey

On Thu, May 09, 2024 at 01:13:45PM -0400, Louis-Philippe Véronneau wrote:
> tags 1070770 patch
> thanks
> 
> I've created a patch on Salsa that creates a new Lintian check for this.
> 
> https://salsa.debian.org/lintian/lintian/-/merge_requests/504

Amazing, thanks!

I've added a bunch of suggestions/comments to the patch: the erroneous
check in debian/rules is for the DEB_BUILD_OPTIONS setting rather than
the DEB_BUILD_PROFILES setting, so it should refer to "options" rather
than "profiles", even though the description for the "nodoc" option
appears on the BuildProfilesSpec wiki page!

I also suggest one tweak to the regex.

Best wishes,

   Julian

Bug#1070822: ocrmypdf: autopkgtest regression with ghostscript 10.03.0~dfsg-1

2024-05-09 Thread Sebastian Ramacher

Source: ocrmypdf
Version: 16.1.2+dfsg1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://ci.debian.net/packages/o/ocrmypdf/testing/amd64/46448482/


425s === FAILURES 
===
425s _ test_semfree 
_
425s 
425s resources = 
PosixPath('/tmp/autopkgtest-lxc.6_tdzv6n/downtmp/build.kDh/src/tests/resources')
425s outpdf = PosixPath('/tmp/pytest-of-debci/pytest-0/test_semfree0/out.pdf')
425s 
425s @pytest.mark.skipif(not is_linux(), reason='semfree plugin only works 
on Linux')
425s def test_semfree(resources, outpdf):
425s exitcode = run_ocrmypdf_api(
425s resources / 'multipage.pdf',
425s outpdf,
425s '--skip-text',
425s '--skip-big',
425s '2',
425s '--plugin',
425s 'ocrmypdf.extra_plugins.semfree',
425s '--plugin',
425s 'tests/plugins/tesseract_noop.py',
425s )
425s >   assert exitcode == ExitCode.ok
425s E   assert  == 
425s E+  where  = ExitCode.ok
425s 
425s tests/test_semfree.py:26: AssertionError
425s -- Captured log call 
---
425s WARNING  ocrmypdf._pipeline:_pipeline.py:358 page too big, skipping OCR 
(81.0 MPixels > 2.0 MPixels --skip-big)
425s WARNING  ocrmypdf._pipeline:_pipeline.py:358 page too big, skipping OCR 
(2.0 MPixels > 2.0 MPixels --skip-big)
425s WARNING  ocrmypdf._metadata:_metadata.py:62 Some input metadata could not 
be copied because it is not permitted in PDF/A. You may wish to examine the 
output PDF's XMP metadata.
425s WARNING  ocrmypdf._pipelines._common:_common.py:443 Output file is okay 
but is not PDF/A (seems to be No PDF/A metadata in XMP)
425s === warnings summary 
===
425s tests/test_main.py::test_jbig2_passthrough
425s tests/test_metadata.py::test_creation_date_preserved[pdf-jbig2.pdf]
425s   /usr/lib/python3/dist-packages/pikepdf/_methods.py:264: UserWarning: 
pikepdf is missing some specialized decoders (probably JBIG2) so not all stream 
contents can be tested.
425s self._decode_all_streams_and_discard()
425s 
425s -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
425s === short test summary info 

425s FAILED tests/test_semfree.py::test_semfree - assert

Bug#1070821: docker.io: FTBFS: DONE 2218 tests, 120 skipped, 2 failures in 109.861s

2024-05-09 Thread Sebastian Ramacher

Source: docker.io
Version: 20.10.25+dfsg1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=docker.io&arch=amd64&ver=20.10.25%2Bdfsg1-3&stamp=1715080704&raw=0

=== Failed
=== FAIL: daemon/logger TestCopierWithSized/With_RingLogger (0.00s)
copier_test.go:265: invalid character 'L' after object key:value pair

=== FAIL: daemon/logger TestCopierWithSized (0.00s)

DONE 2218 tests, 120 skipped, 2 failures in 109.861s
make[1]: *** [debian/rules:129: override_dh_auto_test] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1070820: vinagre: fix compatibility with FreeRDP 2.1.1+

Package: vinagre
Version: 3.22.0-8.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch

Dear Maintainer,

This set of patches fix the compatibility with FreeRDP 2.1.1+.

The patches are cherry-picked from the upstream and pending Merge Requests
in the upstream's GitLab instance.

Some of the previous patches got replaced by a newer revision in the upstream
source repository.

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

  * Fix compatibility with FreeRDP 2.1.1 security update.
- debian/patches/freerdp*.patch: backport series of upstream patches to
  fix compatibility wither newer FreeRDP versions.
- d/p/0001-Revert-Improve-FreeRDP-authentication-failure-handli.patch:
  removed, no longer needed.
- d/p/0002-Revert-Store-credentials-for-RDP.patch: removed, no longer
  needed.
- d/p/freerdp2017.patch: removed, replaced with upstream patches.
- d/patches: re-import patches from the upstream and refresh the patches 
  against the Ubuntu-patched source tree.


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru vinagre-3.22.0/debian/control vinagre-3.22.0/debian/control
--- vinagre-3.22.0/debian/control   2021-05-16 15:11:19.0 -0600
+++ vinagre-3.22.0/debian/control   2024-05-08 15:11:43.0 -0600
@@ -18,6 +18,7 @@
libspice-client-gtk-3.0-dev (>= 0.5) [linux-any],
libavahi-ui-gtk3-dev (>= 0.6.26),
libavahi-gobject-dev (>= 0.6.26),
+   libdbus-glib-1-dev,
libsecret-1-dev,
valac (>= 0.12.0),
yelp-tools,
diff -Nru vinagre-3.22.0/debian/control.in vinagre-3.22.0/debian/control.in
--- vinagre-3.22.0/debian/control.in2020-12-31 17:05:07.0 -0700
+++ vinagre-3.22.0/debian/control.in2024-05-08 15:11:43.0 -0600
@@ -14,6 +14,7 @@
libspice-client-gtk-3.0-dev (>= 0.5) [linux-any],
libavahi-ui-gtk3-dev (>= 0.6.26),
libavahi-gobject-dev (>= 0.6.26),
+   libdbus-glib-1-dev,
libsecret-1-dev,
valac (>= 0.12.0),
yelp-tools,
diff -Nru 
vinagre-3.22.0/debian/patches/0001-Revert-Improve-FreeRDP-authentication-failure-handli.patch
 
vinagre-3.22.0/debian/patches/0001-Revert-Improve-FreeRDP-authentication-failure-handli.patch
--- 
vinagre-3.22.0/debian/patches/0001-Revert-Improve-FreeRDP-authentication-failure-handli.patch
   2020-02-13 04:42:44.0 -0700
+++ 
vinagre-3.22.0/debian/patches/0001-Revert-Improve-FreeRDP-authentication-failure-handli.patch
   1969-12-31 17:00:00.0 -0700
@@ -1,53 +0,0 @@
-From 8ebc0685b85e0d1f70eb00171f2e7712de3d44bd Mon Sep 17 00:00:00 2001
-From: Michael Biebl 
-Date: Thu, 22 Sep 2016 01:15:55 +0200
-Subject: [PATCH 1/2] Revert "Improve FreeRDP authentication failure handling"
-
-This reverts commit d7b4f88943e8615d252d27e1efc58cb64a9e1821.

- plugins/rdp/vinagre-rdp-tab.c | 10 ++
- 1 file changed, 6 insertions(+), 4 deletions(-)
-
-diff --git a/plugins/rdp/vinagre-rdp-tab.c b/plugins/rdp/vinagre-rdp-tab.c
-index b731f9b..8572bc3 100644
 a/plugins/rdp/vinagre-rdp-tab.c
-+++ b/plugins/rdp/vinagre-rdp-tab.c
-@@ -1195,8 +1195,8 @@ open_freerdp (VinagreRdpTab *rdp_tab)
-   VinagreTab   *tab = VINAGRE_TAB (rdp_tab);
-   GtkWindow*window = GTK_WINDOW (vinagre_tab_get_window (tab));
-   gboolean  success = TRUE;
-+  gboolean  authentication_error = FALSE;
-   gboolean  cancelled = FALSE;
--  guint authentication_errors = 0;
- 
-   priv->events = g_queue_new ();
- 
-@@ -1205,12 +1205,14 @@ open_freerdp (VinagreRdpTab *rdp_tab)
- 
-   do
- {
-+  authentication_error = FALSE;
-+
-   /* Run FreeRDP session */
-   success = freerdp_connect (priv->freerdp_session);
-   if (!success)
- {
--  authentication_errors += freerdp_get_last_error 
(priv->freerdp_session->context) == 0x20009 ||
--   freerdp_get_last_error 
(priv->freerdp_session->context) == 0x2000c;
-+  authentication_error = freerdp_get_last_error 
(priv->freerdp_session->context) == 0x20009 ||
-+ freerdp_get_last_error 
(priv->freerdp_session->context) == 0x2000c;
- 
-   cancelled = freerdp_get_last_error (priv->freerdp_se

Bug#1070819: Please package latest version of python-googleapi

2024-05-09 Thread Thomas Goirand

Source: python-googleapi
Version: 1.7.12-1
Severity: important

Hi,

The current version of python-googleapi still includes old deprecated
modules like mock (instead of unittest.mock), or oauth2client. I intend to
attempt removing the oauth2client from Debian, as it FTBFS and is deprecated
upstream.

Please package the latest python-googleapi as it looks up-to-date regarding
those things, and then you can probably remove build-depends on mock, six,
oauth2client and so on.

Also, it'd be nice to get this library in the DPT, as it is used by many.

Cheers,

Thomas Goirand (zigo)

Bug#868871: What's the main obstacle?

2024-05-09 Thread Hong Xu


I may have missed the point here, but what's the main obstacle for restoring 
diff-highlight?

Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles

2024-05-09 Thread Preuße


09.05.2024 14:12:32 Manny :


Hi Manny,

normally I don't have time to care about issues like this. Are you 
willing to report this issue to the upstream author?


Hilmar



Package: texlive-latex-extra
Version: 2022.20230122-4
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com

After an upgrade from Bullseye to Bookworm, the acro package breaks
compilation even if no acronyms are even defined. Documents making use
of acro compiled and functioned fine in the past (version
2020.20210202-3) but no longer compile after the upgrade to
2022.20230122-4.

This is a short sample document:


--
#206401 http://counter.li.org



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#832524: hasciicam: Replace ftplib-dev build dependency by libftp-dev

Package: hasciicam
Version: 1.1.2-1.1
Followup-For: Bug #832524
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

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


  * Merge with Debian unstable (LP: #2065107). Remaining changes:
  * debian/patches/10_desktop-file.patch: Fix invalid desktop file,
don't include extension for icons. (LP: #1198969)
  * Explicitly build-depend on libftp-dev instead of old ftplib-dev


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru hasciicam-1.1.2/debian/control hasciicam-1.1.2/debian/control
--- hasciicam-1.1.2/debian/control  2022-12-11 11:39:06.0 -0700
+++ hasciicam-1.1.2/debian/control  2024-05-07 15:23:23.0 -0600
@@ -7,7 +7,7 @@
 Vcs-Git: git://code.dyne.org/hasciicam.git
 Vcs-Browser: http://code.dyne.org/?r=hasciicam
 Homepage: http://ascii.dyne.org/
-Build-Depends: cdbs, debhelper (>= 9), libaa1-dev, ftplib-dev
+Build-Depends: cdbs, debhelper (>= 9), libaa1-dev, libftp-dev
 Standards-Version: 3.9.1
 
 Package: hasciicam

Bug#717690: hasciicam ships with invalid desktop file

Package: hasciicam
Version: 1.1.2-1.1
Followup-For: Bug #717690
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

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

  * debian/patches/10_desktop-file.patch: Fix invalid desktop file,
don't include extension for icons. (LP: #1198969)

Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru hasciicam-1.1.2/debian/patches/10_desktop-file.patch 
hasciicam-1.1.2/debian/patches/10_desktop-file.patch
--- hasciicam-1.1.2/debian/patches/10_desktop-file.patch1969-12-31 
17:00:00.0 -0700
+++ hasciicam-1.1.2/debian/patches/10_desktop-file.patch2024-05-07 
15:21:06.0 -0600
@@ -0,0 +1,15 @@
+Description: Don't include extension for icon.
+Author: Andreas Moog 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1198969
+
+--- hasciicam-1.1.2.orig/share/hasciicam.desktop
 hasciicam-1.1.2/share/hasciicam.desktop
+@@ -5,7 +5,7 @@ GenericName=HasciiCam
+ Comment=(h)ascii for the masses!
+ Exec=hasciicam %U
+ TryExec=hasciicam
+-Icon=hasciicam.png
++Icon=hasciicam
+ Terminal=false
+ Categories=AudioVideo;
+ X-AppInstall-Package=hasciicam
diff -Nru hasciicam-1.1.2/debian/patches/series 
hasciicam-1.1.2/debian/patches/series
--- hasciicam-1.1.2/debian/patches/series   2011-04-26 07:29:30.0 
-0600
+++ hasciicam-1.1.2/debian/patches/series   2024-05-07 15:21:06.0 
-0600
@@ -1 +1,2 @@
 debian-changes-1.1.2-1
+10_desktop-file.patch

Bug#1070818: src:libcbor: fails to migrate to testing for too long: FTBFS on mips64el


Source: libcbor
Version: 0.10.2-1.1
Severity: serious
Control: close -1 0.10.2-1.2
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:libcbor has been trying to migrate for 83 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build from source on mips64el.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055989: Bug reproduced in 1:29.3+1-2

2024-05-09 Thread Christoph Reichenbach

Hello again,

  just to keep the records up to date: the bug is still present in
1:29.3+1-2, and the same patch still works around it (for me).

  All the best,

-- Christoph


signature.asc
Description: PGP signature

Bug#1070817: ITP: rust-gstreamer-allocators -- rust bindings for libgstalloc

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org,, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-gstreamer-allocators
  Version : 0.22.0
  Upstream Contact: Sebastian Dröge 
* URL : https://gitlab.freedesktop.org/gstreamer/gstreamer-rs
* License : MIT or Apache-2.0
  Programming Lang: Rust 
  Description : rust bindings for libgstalloc

This ITP covers both the low-level and high-level rust bindings for
libgstalloc. This is needed to enable the dmabuf feature for
rust-gst-plugin-gtk4 which would allow offloading of videorendering
directly to hardware with little overhead.
This package will be maintained with the Debian Rust Team.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmY9Fg4VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR169wP+wXxVmzzA5qqGAGsvohBndn80fV/
nm42/PCRTSSXO5HeKPXM13klbQulb1iBnQARbsGRra/TBujR9OX2aiSpHM/6P7wo
yG3lBqcXplN18ScdDNl1ViJ2M28BJt29u5ZkGsVVLCYP3Evks+i14CDkan7CRKdk
LQdo/aYiqpbSHs/qtpYxjRw1ZEMhPf6BOSzeaXubw5jUGfdypfaDXuSgdg8aNK/S
jZ5MdIC+j6DSC8PJEuA8zLrksOqzPwU6Iath2HJRS3nAQJ37Ok5Xq6D7xbJZSrZJ
/+JTPlQHtSgWVQCO3yzLlDaUufjEgbqpTZ91KaUtB2eQ81s5v65DcayNZtQoLr7D
OmbdnYQVhARdetLZmBlR2j9V4b+ZHwTmYTBHMpuK0dPrdMShhO656/Ihc6OY7ZEu
SvIaTV+49DKnFVrbdYceGPBdqNvQ/wvWz3yVTjFOt964n3n+xa3dKsf9PUhoJ1Oy
/MUETmRTVKpn7Apz+DJccBD1aIw2voqimvT9wAfMngtFCFc7A9YUE1sHKwhOB80J
nys+a+Wdhp2yA2S/qM88QHvJZjg8tax8nY5cpnqcQrBKpzaMSW1KahH8PH4TA97D
dEe3N8FAnGao6IL2MuUxigQ3PfO0IQZkvBZDFo3HS/0t4S73TZ7uErI/GGRzhUOB
CDGb2MzORAd2mbol
=S7I1
-END PGP SIGNATURE-

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

2024-05-09 Thread Joey Hess

Joey Hess wrote:
> with the old ref I saw on the remote. If the shas are different, I 
> check `git log --oneline $old..$src` -- if this outputs nothing, then
> history is not advancing and it refuses to push that ref, and 
> reports the error to git.

That's not quite right, because git log outputs commits when the two
refs are diverged but share a common ancestor.

I think the best way to detect it is
git merge-base --ancestor $old $src
which will exit nonzero on a non-fast-forward.

-- 
see shy jo

signature.asc
Description: PGP signature

Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles

2024-05-09 Thread Hilmar Preuße

09.05.2024 14:12:32 Manny :

> Package: texlive-latex-extra
> Version: 2022.20230122-4
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com
> 
> After an upgrade from Bullseye to Bookworm, the acro package breaks
> compilation even if no acronyms are even defined. Documents making use
> of acro compiled and functioned fine in the past (version
> 2020.20210202-3) but no longer compile after the upgrade to
> 2022.20230122-4.
> 
> This is a short sample document:
> 
> ===8<
> \documentclass{scrlttr2}
> \usepackage{acro}
> 
> %\DeclareAcronym{foo}{short=FOO, long=breaks even if no acronym is defined}
> 
> \begin{document}
> \begin{letter}{recipient}
>   lipsum
> \end{letter}
> \end{document}
> ===8<
> 
> The error is this:
> 
> ===8<
> ERROR: Package acro Error: Patching `maketitle' failed. Please contact the 
> acro
> (acro)    author.
> 
> Type  to continue.
> ... 
>  
> l.6 \begin{document}
>    
> --- HELP ---
> No help available
> ===8<
> 
> The upstream tag was applied because that’s where the defect is, but
> action can still be taken on the Debian release. Debian should either
> roll back the acro.sty version, or advance it. The current version is
> apparently completely unusable. Both latex and pdflatex fail to
> compile it. This is the fls file:
> 
> ===8<
> PWD /tmp
> INPUT /etc/texmf/web2c/texmf.cnf
> INPUT /usr/share/texmf/web2c/texmf.cnf
> INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
> INPUT /var/lib/texmf/web2c/pdftex/latex.fmt
> INPUT sample.tex
> OUTPUT sample.log
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.

Bug#1070816: src:wsdd: fails to migrate to testing for too long: uploader built arch:all binaries


Source: wsdd
Version: 2:0.7.0-2.1
Severity: serious
Control: close -1 2:0.7.1-5
Tags: sid trixie pending
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:wsdd has been trying to migrate for 82 
days [2]. Hence, I am filing this bug.


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.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070815: libdrm-intel1 should be compiled for arm64

2024-05-09 Thread Vladimir Smirnov

Package: libdrm-intel1
Version: 2.4.120-2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: civil.o...@gmail.com

Dear Maintainer,

   * What led up to the situation?

 I recently got an Ampere Altra board and I've decided to try getting
 Intel Arc 750 working on it. While that requires vendor-specific kernel
 patches (Workaround for Altra's PCIe Errata) and recent kernel
 (6.9.0-rc6 with drm-next/xe), I managed to get it working.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 One of the obstacles I had, was that libdrm-intel1 is not compiled on
 arm64 systems in debian (testing or unstable or experimental). Upstream
 actually have nothing that prevents you from compiling it and only
 requires to add arm64 in control for libdrm-intel1.

   * What was the outcome of this action?

 I've actually managed to build libdrm-intel1 on aarch64.


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

Kernel: Linux 6.9.0-rc6+ (SMP w/64 CPU threads)
Kernel taint flags: TAINT_USER
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 libdrm-intel1 depends on:
ii  libc6  2.38-7
ii  libdrm22.4.120-3
ii  libpciaccess0  0.17-3+b1

libdrm-intel1 recommends no packages.

libdrm-intel1 suggests no packages.

-- no debconf information

-- patch that I've applied to make it build:
--- libdrm-2.4.120.old/debian/control   2024-02-08 08:49:20.0 +0100
+++ libdrm-2.4.120/debian/control   2024-05-09 10:30:48.688180370 +0200
@@ -24,7 +24,7 @@
 Architecture: linux-any hurd-any
 Depends:
  libdrm2 (= ${binary:Version}),
- libdrm-intel1 (= ${binary:Version}) [amd64 i386 hurd-i386 x32],
+ libdrm-intel1 (= ${binary:Version}) [arm64 amd64 i386 hurd-i386 x32],
  libdrm-radeon1 (= ${binary:Version}),
  libdrm-nouveau2 (= ${binary:Version}) [linux-any],
  libdrm-amdgpu1 (= ${binary:Version}),
@@ -104,7 +104,7 @@
  This is a udeb, or a microdeb, for the debian-installer.

 Package: libdrm-intel1
-Architecture: amd64 i386 hurd-i386 x32
+Architecture: arm64 amd64 i386 hurd-i386 x32
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},

Bug#1070814: src:snapraid: fails to migrate to testing for too long: FTBFS on mips64el


Source: snapraid
Version: 12.2-1
Severity: serious
Control: close -1 12.3-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:snapraid has been trying to migrate for 84 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on mips64el.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070813: src:camelot-py: fails to migrate to testing for too long: autopkgtest failure on ppc64el


Source: camelot-py
Version: 0.11.0-3
Severity: serious
Control: close -1 0.11.0-4
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1063891

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:camelot-py has been trying to migrate for 
86 days [2]. Hence, I am filing this bug. As you noticed yourself (in 
bug 1063891) the autopkgtest fails on ppc64el. If you can't easily fix 
it, I suggest you make the test failure on ppc64el not blocking. You can 
do that by either using the Architecture field in d/t/control 
("!ppc64el" works), but I don't recommend that because changes to the 
results would go unnoticed and it would be harder to get a log. 
Alternatively you can annotate the test with the flaky restriction, but 
that would cause failure on !ppc64el to go unnoticed. So, I would 
recommend using the skippable restriction and "exit 77" when the test 
fails on ppc64el (but that's a bit more work to embed in the test).


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=camelot-py



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

2024-05-09 Thread Louis-Philippe Véronneau


tags 1070770 patch
thanks

I've created a patch on Salsa that creates a new Lintian check for this.

https://salsa.debian.org/lintian/lintian/-/merge_requests/504

Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1069231: RFP: swtchr -- Gnome-style window switcher for sway

On Thu, 18 Apr 2024 11:58:25 +0200 Matthias Geiger 
 wrote:
Package: wnpp  > Severity: wishlist > X-Debbugs-Cc: debian-r...@lists.debian.org, 

werdah...@riseup.net > Control: block -1 by 1054539 >

* Package name : swtchr
Version : 0.1.2
Upstream Contact: lostatc
* URL : https://github.com/lostatc/swtchr
* License : MIT
Programming Lang: Rust
Description : Gnome-style window switcher for sway

swtchr is a gnome-like window switcher for sway. Windows can be accessed
by the overlay window and cycled with shift+tab.
.
This needs gtk4-layer-shell (C) packaged first. I might pick this up
later.

best,

werdahias


Missing: gtk4-layer-shell* (already packaged)

sway-ipc

best,


--
Matthias Geiger 
Debian Maintainer

Bug#1059503: RFS: blanket/0.6.0-1 [RFP] -- listen to relaxing sounds


Hi Danial,

once I become a DD (which is hopefully by the end of this month) I will 
sponsor this upload.


best,


--
Matthias Geiger 
Debian Maintainer

Bug#69117: fmtools: fm on and fm off dont turn the radio on and off

[Erik 2000-08-14]
> If i get a chance i'll test out a different kernel, but it wont
> happen today

Is this still a problem?  Without more information, it is hard to tell
how to reproduce and how to fix it.  I suspect the latest version
using vl2 v2 might not behave the same way as the version you tested.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

2024-05-09 Thread Shmerl

On Mon, 6 May 2024 01:28:47 +0300 Jussi Pakkanen  wrote:
> Filed:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070470
>

Thanks!

Do you think it's worth it it to file the bug to rust
upstream too: https://github.com/rust-lang/rust/issues
May be wider Rust developers can have an insight.
Or it's something very Debian specific?

Shmerl.

Bug#1070812: eg25-manager: FTBFS with libgpiod/2.1

2024-05-09 Thread 賴建宇

Source: eg25-manager
Version: 0.4.6-3
Severity: important

Dear Maintainer,

I am planning to have a transition for libgpiod.                                
              
https://release.debian.org/transitions/html/auto-libgpiod.html

Many APIs were changed in this transition.
I tested libgpiod with eg25-manager 0.4.6-3.
As a result, it seems FTBFS. Please have a check.
Feel free to let me know if any information is needed.
Thanks.

===
Found ninja-1.11.1 at /usr/bin/ninja
   dh_auto_build
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v
[1/20] /usr/bin/meson --internal exe --capture doc/eg25-manager.8 -- 
/usr/bin/sh -c '/usr/bin/scdoc < doc/eg25-manager.8.preprocessed'
[2/20] /usr/bin/meson --internal exe --capture doc/eg25-manager.5 -- 
/usr/bin/sh -c '/usr/bin/scdoc < doc/eg25-manager.5.preprocessed'
[3/20] /usr/bin/gdbus-codegen --c-generate-autocleanup all --interface-prefix 
org.ofono. --c-namespace GDBO --body --output src/libgdbofono/gdbo-manager.c 
../src/libgdbofono/manager.xml
[4/20] /usr/bin/gdbus-codegen --c-generate-autocleanup all --interface-prefix 
org.ofono. --c-namespace GDBO --header --output src/libgdbofono/gdbo-manager.h 
../src/libgdbofono/manager.xml
[5/20] /usr/bin/gdbus-codegen --c-generate-autocleanup all --interface-prefix 
org.ofono. --c-namespace GDBO --header --output src/libgdbofono/gdbo-modem.h 
../src/libgdbofono/modem.xml
[6/20] /usr/bin/gdbus-codegen --c-generate-autocleanup all --interface-prefix 
org.ofono. --c-namespace GDBO --body --output src/libgdbofono/gdbo-modem.c 
../src/libgdbofono/modem.xml
[7/20] cc -Isrc/libgdbofono/libgdbofono.a.p -Isrc/libgdbofono 
-I../src/libgdbofono -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/gio-unix-2.0 -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 
'-DEG25_CONFDIR="/etc/eg25-manager"' '-DEG25_DATADIR="/usr/share/eg25-manager"' 
'-DEG25_VERSION="0.4.6"' -DHAVE_MMGLIB=1 -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/build/eg25-manager-0.4.6=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-manager.c.o -MF 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-manager.c.o.d -o 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-manager.c.o -c 
src/libgdbofono/gdbo-manager.c
[8/20] cc -Isrc/eg25-manager.p -Isrc -I../src -Isrc/libgdbofono 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/gudev-1.0 -I/usr/include/libusb-1.0 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libmm-glib 
-I/usr/include/ModemManager -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 
-Wall -Winvalid-pch -std=gnu11 '-DEG25_CONFDIR="/etc/eg25-manager"' 
'-DEG25_DATADIR="/usr/share/eg25-manager"' '-DEG25_VERSION="0.4.6"' 
-DHAVE_MMGLIB=1 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/build/eg25-manager-0.4.6=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -pthread -MD -MQ src/eg25-manager.p/at.c.o -MF 
src/eg25-manager.p/at.c.o.d -o src/eg25-manager.p/at.c.o -c ../src/at.c
[9/20] cc -Isrc/libgdbofono/libgdbofono.a.p -Isrc/libgdbofono 
-I../src/libgdbofono -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/gio-unix-2.0 -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 
'-DEG25_CONFDIR="/etc/eg25-manager"' '-DEG25_DATADIR="/usr/share/eg25-manager"' 
'-DEG25_VERSION="0.4.6"' -DHAVE_MMGLIB=1 -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/build/eg25-manager-0.4.6=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-modem.c.o -MF 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-modem.c.o.d -o 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-modem.c.o -c 
src/libgdbofono/gdbo-modem.c
[10/20] rm -f src/libgdbofono/libgdbofono.a && gcc-ar csrDT 
src/libgdbofono/libgdbofono.a 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-manager.c.o 
src/libgdbofono/libgdbofono.a.p/meson-generated_.._gdbo-modem.c.o
[11/20] cc -Isrc/eg25-manager.p -Isrc -I../src -Isrc/libgdbofono 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/gudev-1.0 -I/usr/include/libusb-1.0 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libmm-glib 
-I/usr/include/ModemManager -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 
-Wall -Winvalid-pch -std=gnu11 '

Bug#714589:

2024-05-09 Thread Alex Henrie

This packaging bug is a big problem for Proton's Wine fork, which
needs both /usr/lib/i386-linux-gnu/libgcrypt.so and
/usr/lib/x86_64-linux-gnu/libgcrypt.so to be available at build time.
Currently, Proton built for Debian can only support ECDH in 32-bit
games or 64-bit games, but not both. See
https://github.com/ValveSoftware/wine/commit/8ae2eb018d5b6ea97879f2acc4623afa4de6bc83

However, it won't do much good to fix libgcrypt20-dev without fixing
its dependency libgpg-error-dev first. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933713

Bug#1070791: solaar: Does not restore DPI after suspend

2024-05-09 Thread Bruno Kleinert

Am Donnerstag, dem 09.05.2024 um 13:59 +0200 schrieb Stephen Kitt:
> Hi Bruno,
> 
> On Thu, 09 May 2024 11:02:11 +0200, Bruno Kleinert  wrote:
> > when the computer wakes up from suspend the DPI setting of the mouse is not
> > restored. This had worked in earlier versions of solaar.
> > 
> > I reproduce this with an MX Master 3S mouse, set to 2000 DPI via the solaar
> > configuration window, and the GNOME desktop environment:
> > 
> > 1. Open solaar from the tray and set mouse to 2000 DPI
> > 2. Put the computer into standby via GNOME's power menu
> > 3. Wake up the computer
> > 4. Moving the mouse cursor appears way slower than the previously configured
> > 2000 DPI. My apologies, I didn't figure out how to read the actual DPI value
> > from the mouse at this step.
> > 
> > To work around after wakeup, I open the solaar configuration, click into the
> > DPI field, which displays still shows 2000 DPI, and just hit enter.
> 
> I think this is fixed upstream — would you mind applying
> https://github.com/pwr-Solaar/Solaar/commit/6c11f4e4808063a9a454d4c034a7e40b8e56da5c
> to /usr/share/solaar/lib/solaar/dbus.py to see if suspend is handled
> correctly?
> 
> Regards,
> 
> Stephen

Hi Stephen,

perfect, I can confirm that fixes the bug! 👍️

Kind regards,
Bruno


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

Bug#1070811: llvm-toolchain-18: FTBFS on armel: cxa_guard.cpp:(.text.unlikely.__cxa_guard_acquire+0x28): undefined reference to `__atomic_load_1'

2024-05-09 Thread Sebastian Ramacher

Source: llvm-toolchain-18
Version: 1:18.1.5-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18&arch=armel&ver=1%3A18.1.5-2&stamp=1714875266&raw=0

1 warning generated.
[1063/1657] /<>/build-llvm/bin/clang++ --target=arm-linux-gnueabi 
-DHAVE___CXA_THREAD_ATEXIT_IMPL -DLIBCXX_BUILDING_LIBCXXABI 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LIBCPP_BUILDING_LIBRARY 
-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCXXABI_BUILDING_LIBRARY 
-D_LIBCXXABI_LINK_PTHREAD_LIB -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I/<>/libunwind/include 
-I/<>/libcxxabi/../libcxx/src 
-I/<>/build-llvm/include/c++/v1 
-I/<>/libcxxabi/include -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-Wno-unused-command-line-argument -march=armv5t -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections 
-fdebug-prefix-map=/<>/build-llvm/runtimes/runtimes-bins=../../../ 
-fdebug-prefix-map=/<>/= -no-canonical-prefixes 
-ffile-prefix-map=/<>/build-llvm/runtimes/runtimes-bins=../../../ 
-ffile-prefix-map=/<>/= -no-canonical-prefixes  -O3 -DNDEBUG 
-std=c++23 -fPIC -nostdinc++ -fstrict-aliasing -D_DEBUG -UNDEBUG -Wall -Wextra 
-Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long 
-Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral 
-Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override 
-Wno-error -MD -MT 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_demangle.cpp.o -MF 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_demangle.cpp.o.d -o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_demangle.cpp.o -c 
/<>/libcxxabi/src/cxa_demangle.cpp
[1064/1657] : && /<>/build-llvm/bin/clang++ 
--target=arm-linux-gnueabi -fPIC -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-Wno-unused-command-line-argument -march=armv5t -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections 
-fdebug-prefix-map=/<>/build-llvm/runtimes/runtimes-bins=../../../ 
-fdebug-prefix-map=/<>/= -no-canonical-prefixes 
-ffile-prefix-map=/<>/build-llvm/runtimes/runtimes-bins=../../../ 
-ffile-prefix-map=/<>/= -no-canonical-prefixes  -O3 -DNDEBUG  
-Wl,-z,relro -Wl,--build-id,--as-needed -latomic -Wl,-z,defs -Wl,-z,nodelete  
-nostdlib++ -shared -Wl,-soname,libc++abi.so.1 -o 
/<>/build-llvm/lib/libc++abi.so.1.0 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_default_handlers.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_demangle.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_exception_storage.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_guard.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_handlers.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_vector.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_virtual.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_exception.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_stdexcept.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_typeinfo.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/abort_message.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/fallback_malloc.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/private_typeinfo.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/stdlib_new_delete.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_exception.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_personality.cpp.o 
libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_thread_atexit.cpp.o  
-lpthread  -lc  -lgcc  -lgcc_s && :
FAILED: /<>/build-llvm/lib/libc++abi.so.1.0 
: && /<>/build-llvm/bin/clang++ --target=arm-linux-g

Bug#1070810: src:unattended-upgrades: fails to migrate to testing for too long: FTBFS


Source: unattended-upgrades
Version: 2.9.1+nmu4
Severity: serious
Control: close -1 2.10
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:unattended-upgrades has been trying to 
migrate for 87 days [2]. Hence, I am filing this bug. The version in 
unstable failed to build.


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=unattended-upgrades



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070809: src:multiqc: fails to migrate to testing for too long: depends on package that doesn't migrate


Source: multiqc
Version: 1.14+dfsg-1.1
Severity: serious
Control: close -1 1.18+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:multiqc has been trying to migrate for 87 
days [2]. Hence, I am filing this bug. The version in unstable has a new 
(Build-)Depends that's not ready to migrate yet (it needs a source-full 
upload).


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069101: libdbd-oracle-perl: requires rebuild for time_t transition

2024-05-09 Thread gregor herrmann

On Thu, 09 May 2024 16:41:10 +0200, Alex Muntada wrote:

> > > It turns out that it's oracle-instantclient-basic that needs
> > > libaio.so.1. I'm not sure what could be done to address this
> > > issue, since the soname renaming to libaio.so.1t64 is Debian
> > > specific.
> 
> I came up with an easy solution to this: since libaio.so.1 is
> required by oracle-instantclient-basic (not in Debian), we could
> add libaio (from Oracle Linux) in Depends and then explain in
> README.Debian to download it from Oracle, build the .deb with
> alien and install it, like the other external dependencies.

Sounds viable to me, with good instructions in the README.Debian
downloading alien'ing two packages instead of one shouldn't be too
terrible for users.
 
> The thing is that maybe a hint on libaio will be needed?

What do you mean be "hint" here?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1069097: openstack-dashboard: postinst error makes designate-dashboard to FTBFS randomly

2024-05-09 Thread Santiago Vila


I wasn't able to reproduce this bug. Can you help?


I'm not sure how I can help, so let's try the "Socratic rubber duck" method.

Apparently, I'm not the only one who found this problem:

https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/2045394

If I were you, I would try to answer the following question:

Who issues this error message? (extracted from the build log)

CommandError: An error occurred during rendering serial_console.html: Syntax 
error: Found 'inline-blo' but expected one of ADD, ALPHA_FUNCTION, 
BANG_IMPORTANT, BAREWORD, COLOR, DOUBLE_QUOTE, FNCT, IF_FUNCTION, INTERP_START, 
LITERAL_FUNCTION, LPAR, NOT, NUM, SIGN, SINGLE_QUOTE, URL_FUNCTION, VAR
dpkg: error processing package openstack-dashboard (--configure):
 installed openstack-dashboard package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
 openstack-dashboard

and under which circumstances the "render" (whatever that is) might receive 
'inline-blo' instead
of one of the other expected commands?

(I have the feeling that trying to answer such question could be what 
ultimately lead us
to find the root cause of the problem).

I could of course provide a machine to reproduce it (please contact me 
privately for that),
but the failure rate is quite low, so in my opinion it would be more productive 
to try
to answer such simple question first.

Also: Please consider forwarding the bug upstream. If it also happens in 
Ubuntu, then
we can reasonably assume that it's not a problem in my machines or my build 
environment.

Thanks.

Bug#1070795: Processed: your mail

2024-05-09 Thread Darrick J. Wong

[actually cc the bugreport this time]

On Thu, May 09, 2024 at 07:40:20AM -0700, Darrick J. Wong wrote:
> On Thu, May 09, 2024 at 10:51:03AM +, Debian Bug Tracking System wrote:
> > Processing commands for cont...@bugs.debian.org:
> > 
> > > tags 1070795 + d-i
> > Bug #1070795 [xfsprogs-udeb] xfsprogs-udeb: the udeb is empty (size 904 
> > bytes) so does not contain mkfs.xfs
> 
> Yeah, someone needs to apply the patches in
> 
> https://lore.kernel.org/linux-xfs/171338841094.1852814.10756994414036094487.stgit@frogsfrogsfrogs/
> 
> and
> 
> https://lore.kernel.org/linux-xfs/171338841109.1852814.13493721733893449217.stgit@frogsfrogsfrogs/
> 
> which were not picked up for 6.7.  Unless the upstream maintainer
> (Carlos) goes ahead with a 6.7.1?
> 
> --D
> 
> > Added tag(s) d-i.
> > > thanks
> > Stopping processing here.
> > 
> > Please contact me if you need assistance.
> > -- 
> > 1070795: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070795
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> > 
>

Bug#1069101: libdbd-oracle-perl: requires rebuild for time_t transition

2024-05-09 Thread Alex Muntada

[Cc to debian-perl for feedback]

Hi Sebastian,

> > > libdbd-oracle-perl depends on libaio1
> > 
> > It turns out that it's oracle-instantclient-basic that needs
> > libaio.so.1. I'm not sure what could be done to address this
> > issue, since the soname renaming to libaio.so.1t64 is Debian
> > specific.

I came up with an easy solution to this: since libaio.so.1 is
required by oracle-instantclient-basic (not in Debian), we could
add libaio (from Oracle Linux) in Depends and then explain in
README.Debian to download it from Oracle, build the .deb with
alien and install it, like the other external dependencies.

The thing is that maybe a hint on libaio will be needed? Plus,
I guess that libaio and libaio1/libaio1t64 are so similar that
it could create too much confusion anyway... What do you think?

If it's too much, then probably it's the time to say goodbye to
libdbd-oracle-perl (popcon number is 52).

Cheers!
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer 🍥 log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#1069097: openstack-dashboard: postinst error makes designate-dashboard to FTBFS randomly

2024-05-09 Thread Thomas Goirand


Hi Santiago,

I wasn't able to reproduce this bug. Can you help?

Cheers,

Thomas Goirand (zigo)

Bug#1070808: zsh(1) changes behavior of the keypad Enter key and didn't restore it on exiting

2024-05-09 Thread WHR

Package: zsh
Version: 5.9-6
Severity: normal
X-Debbugs-Cc: bmy...@gmail.com, w...@rivoreo.one


Hello.

I actually don't use zsh myself, but sometimes when I comes to collaborate
with others in tmux(1), where their login shell is zsh, or I just need to test
something in zsh, I always encounters this annoying bug.

First, zsh changes the behavior of the keypad Enter key, so this key didn't
work in zsh at all; this is already very inconvenient for me, as I'm very used
to pressing this Enter key on the keypad. To make it worse, zsh didn't revert
this change on exiting, so even I exited zsh(1), the Enter key is still
non-functional in my parent shell (bash(1) in this case), and I have to
reset(1) the terminal to recover.

To reproduce:
1, Run zsh from bash
   (once in zsh, the keypad Enter key is no longer functional)
2, Exit zsh by using 'exit' command or pressing ^D
   (the keypad Enter key remains non-functional even in bash)



-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  systemd254.5-1  ppc64system and service manager
ii  udev   254.5-1  ppc64/dev/ and hotplug management daemon

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

Kernel: Linux 4.19.271-rivoreo-powerpc64-largepage (SMP w/176 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_TW:zh_CN:zh:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages zsh depends on:
ii  debianutils  5.17
ii  libc62.37-15.1
ii  libcap2  1:2.66-5
ii  libtinfo66.4+20240414-1
ii  zsh-common   5.9-6

Versions of packages zsh recommends:
ii  libc6 2.37-15.1
ii  libgdbm6  1.23-3
ii  libncursesw6  6.4+20240414-1
ii  libpcre2-8-0  10.42-4

Versions of packages zsh suggests:
pn  zsh-doc  

-- no debconf information

Bug#1070741: Fixed

2024-05-09 Thread Thomas Goirand


Hi Scott,

Sorry, I fixed python-openstackclient and removed its build-depends on 
python3-karborclient today (and removed the moreinfo tag on this bug).


FYI, it was there so openstackclient could generate its autocompletion 
and doc correctly with karborclient support.


Cheers,

Thomas Goirand (zigo)

Bug#1070807: konsole: Konsole did not close redundant FDs when creating shell process in terminal session

2024-05-09 Thread anthony

Package: konsole
Version: 4:23.08.1-1+b1
Severity: important
X-Debbugs-Cc: lkphantom1...@gmail.com

Dear Maintainer,

   * What led up to the situation?
   The terminal did not close redundant FDs when creating shell process.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   The shell process has many unexpected redundant FDs, and those FDs 
   were inherit from konsole.
   * What outcome did you expect instead?
   The terminal emulator should not leave any redundant FDs for shell
   process.

   Today I found my Zsh comes with 157 FDs, in common sense zsh won't 
   create such large amount open files. Then I tried command
   'konsole -e /bin/sleep 1', even through, the sleep process also
   has 100+ FDs that shouldn't exists.

   By comparing the FDs' number, those FDs were inherit from konsole.

   I thought you may close redundant FDs before creating shell process, 
   or use CLOEXEC flag.


   This is my test output in konsole:
   % uname -r
   6.1.27.xeon.ll
   % ls /proc/self/fd | wc -l
   157
   % ls /proc/$PPID/fd | wc -l
   179
   % cat /proc/$PPID/cmdline| tr '\0' ' '
   /usr/bin/konsole --new-tab
   %


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

Kernel: Linux 6.1.27.xeon.ll (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 konsole depends on:
ii  kio5.107.0-1+b2
ii  konsole-kpart  4:23.08.1-1+b1
ii  libc6  2.37-19
ii  libkf5configcore5  5.107.0-1+b2
ii  libkf5configwidgets5   5.107.0-2+b2
ii  libkf5coreaddons5  5.107.0-1+b2
ii  libkf5crash5   5.107.0-1+b2
ii  libkf5dbusaddons5  5.107.0-1+b2
ii  libkf5globalaccel-bin  5.107.0-2+b2
ii  libkf5globalaccel5 5.107.0-2+b2
ii  libkf5guiaddons5   5.107.0-1+b2
ii  libkf5i18n55.107.0-1+b2
ii  libkf5kiowidgets5  5.107.0-1+b2
ii  libkf5notifyconfig55.107.0-1+b4
ii  libkf5service-bin  5.107.0-1+b2
ii  libkf5service5 5.107.0-1+b2
ii  libkf5widgetsaddons5   5.107.0-1+b2
ii  libkf5windowsystem55.107.0-1+b2
ii  libkf5xmlgui5  5.107.0-1+b2
ii  libqt5core5t64 5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64  5.15.10+dfsg-7.2+b1
ii  libqt5widgets5t64  5.15.10+dfsg-7.2+b1
ii  libstdc++6 14-20240330-1

konsole recommends no packages.

Versions of packages konsole suggests:
ii  lrzsz  0.12.21-11

-- no debconf information

Bug#1066941: coz-profiler: FTBFS: what(): unknown compilation unit version 5

[Sebastian Ramacher]
> I gave it back on the buildds. Let's see if it works now.

Seem to still fail.  I suspect the trigger is this code in d/rules:

  override_dh_auto_test:
@if [ "$$(cat /proc/sys/kernel/perf_event_paranoid)" -le 2 ] ; then \
  $(MAKE) check; \
else \
  echo ; \
  echo "***"; \
  echo "error: not running test suite, 
/proc/sys/kernel/perf_event_paranoid value too high"; \
  echo "***"; \
  echo ; \
fi


My chroot got '3' in that /proc/ file, so the test code is not executed.
I guess the failure indicate that the program do not work as it should,
but do not really know the innter workings here.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1070778: [Debian-astro-maintainers] Bug#1070778: indi-armadillo-platypus: Add Appstream metainfo announcing HW support

[Thorsten Alteholz]
> There are lots of drivers in this repository, distributed over several 
> packages. Shouldn't there be a unique id for each package?

Yes, most likely.  I just had a look at the homepage url in d/control
and synthesized something I hoped was unique.  I did not know there were
several packages with the same homepage url.  Please make a better ID.
The only requirement is reverse DNS notation and uniqueness.  Would be
nice if it is stable and shared across Linux distributions too, but I do
not thing anyone care about this at the moment. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070806: RM: kseexpr/experimental -- ROM; 64bit time_t transition not needed

2024-05-09 Thread Pino Toscano

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

Hi,

please remove kseexpr from experimental: the 64bit time_t transition
for it is not needed, as the only time_t reference is an unused typedef
in a public header.

Thanks,
-- 
Pino

Bug#1070805: aide fails to concurrently read extended attributes

2024-05-09 Thread Hannes von Haugwitz

Package: aide
Version: 0.18.3-1+deb12u2
Severity: important
Tags: upstream patch

Hello,

aide 0.18 (<= 0.18.7) fails to concurrently read extended attributes
(xattrs) due to variables erroneously shared between worker threads.

This has been fixed upstream in AIDE [v0.18.8] via [732e7e2e] (and
[3831c717] in the default branch).

Best regards

Hannes

[v0.18.8]  https://github.com/aide/aide/releases/tag/v0.18.8
[732e7e2e] 
https://github.com/aide/aide/commit/732e7e2e7dc91bb614c508518c0abc6cab85565c
[3831c717] 
https://github.com/aide/aide/commit/93831c717eaaa19d58da12ebeb28607cc6d43116

Bug#1054698: pixmap: FTBFS: ././Pixmap.c:1145:(.text+0xe631): undefined reference to `xpmReadRgbNames'

2024-05-09 Thread Bo YU


Hi,
On Thu, Nov 23, 2023 at 03:00:58PM +0100, Paul Slootman wrote:

On Fri 27 Oct 2023, Lucas Nussbaum wrote:


...

on libxpm:
Explicitly mark non-static symbols as export or hidden

Hides private API from external linkage

Signed-off-by: Alan Coopersmith 

That commit marks those functions as hidden for some reason.

I'm contacting the libxpm maintainers.


Thanks for working on it.

Is there any progress here? If so,  could you update some 
progress/news here?


--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1070804: Launching polari crashes GNOME shell

Package: polari
Version: 46.0-1
Severity: important
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since the recent update to GNOME shell 44.9-2 launching polari crashes
the shell and I get logged out back to gdm3. journalctl log is
attached (see first 200 lines).
Let me know if you need more information.

thanks,

werdahias


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

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

Versions of packages polari depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  gir1.2-adw-1 1.5.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3+b3
ii  gir1.2-glib-2.0 [gir1.2-gio-2.0] 2.80.1-1
ii  gir1.2-gtk-4.0   4.12.5+ds-6
ii  gir1.2-pango-1.0 1.52.2+ds-1
ii  gir1.2-secret-1  0.21.4-1+b1
ii  gir1.2-soup-3.0  3.4.4-5+b1
ii  gir1.2-telepathyglib-0.120.24.2-0.3
ii  gir1.2-tracker-3.0   3.7.3-1
ii  gjs  1.80.2-1
ii  libc62.38-8
ii  libgirepository-1.0-11.80.1-2
ii  libgjs0g 1.80.2-1
ii  libglib2.0-0t64  2.80.1-1
ii  libglib2.0-bin   2.80.1-1
ii  libtelepathy-glib0t640.24.2-0.3
ii  libtracker-sparql-3.0-0  3.7.3-1
ii  telepathy-idle   0.2.2-1+b1
ii  telepathy-mission-control-5  1:5.16.5-2.2
ii  tracker  3.7.3-1

polari recommends no packages.

polari suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmY80VIVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1LoYP/0NOONlcqVdaL0Yph2iY5BcTwEd3
CV6mxbIBZOfM8M1Gwn+TqcTdyTBZofbve8G27NM9DFIMiDQRluWk19826bnyW3j4
YqtEwR+f3gzzRpkI/SrJOqz2F8d/OcUODCvj+kFFYBqykwfv601iuH0HxT0nkEdb
xiiOqyOWigjRht+sUKh6PmvZT+cCIsiObSFkBmPcEQ3ixF/eEokcfbgdsAPc5HAa
qefkbD3sKBpc3G/kw5hVEhOKtZND+RGKmzVRXqFCzz/PNSGTtZ7cq95VpIluNl/+
A2BYaXNK7yFLyET4Vn0DTwOaBDI/dyhhPhO9zl5+yBn8Wm4/FLVDEtIpmKf/qKha
m2IgNKpFVMExzPFHWYA2IQGBZOcXXBW7Hz43uw+Udf62bokymrVms/PmAXpu9Oaa
ISiyREk+RMvC7SVEfKq+dVrwuOsOhifxYSEPgDstp44KESjDjrKZlUciIrOVS5Oz
DQW0AxjY9IlzamV9YiBaeC237i7ORyWIkYIkn6zWhQphefNSN3onnR9FAtjFSnDu
3HA+hm8NzkvMgWTjrcxQ7kKhCzVTzqfW1xPte0UGoGziMa7883R6mat8BDokdce9
3YdP0APXqKuO6xOQGY9YBW6jCSesaDl80SqH2+a+g/9hCO/zx+hDtEhtHBm4oaGo
XZNlFWOphxlKHsUN
=2/Ne
-END PGP SIGNATURE-

(polari:9399): Adwaita-WARNING **: 15:18:04.020: AdwNavigationPage 
0x60afe8638720 is missing a title. To hide a header bar title, consider using 
AdwHeaderBar:show-title instead.

(polari:9399): Adwaita-WARNING **: 15:18:04.020: AdwNavigationPage 
0x60afe8638b70 is missing a title. To hide a header bar title, consider using 
AdwHeaderBar:show-title instead.
Mai 09 15:21:33 yggsdrasil gnome-shell[13993]: Object St.BoxLayout 
(0x610082297570), has been already disposed — impossible to access it. This 
might be caused by the object having been destroyed from C code using something 
such as destroy(), dispose(), or remove() vfuncs.
   == Stack trace for context 
0x610080062530 ==
   #0   610080d11b28 i   
resource:///org/gnome/shell/ui/search.js:322 (1a775e59cf60 @ 25)
   #1   7ffd56c740c0 b   
resource:///org/gnome/shell/ui/search.js:266 (1a775e59cce0 @ 26)
   #2   7ffd56c74130 I   
self-hosted:203 (5dadcb906a0 @ 245)
   #3   610080d11a78 i   
resource:///org/gnome/shell/ui/search.js:265 (1a775e59cc90 @ 385)
   #4   610080d119c8 i   
self-hosted:1461 (194d8d32c290 @ 30)
   #5   7ffd56c74ae0 b   
self-hosted:852 (194d8d3fafb0 @ 15)
Mai 09 15:21:33 yggsdrasil gnome-shell[13993]: Object St.Label 
(0x610082295790), has been already disposed — impossible to set any property on 
it. This might be caused by the object having been destroyed from C code using 
something such as destroy(), dispose(), or remove() vfuncs.
   == Stack trace for context 
0x610080062530 ==
   #0   610080d11bb8 i   
resource:///org/gn

Bug#985442: Fix

2024-05-09 Thread Tiago Bortoletto Vaz

Control: severity 985442 wishlist

Hi,

Thanks for reporting and sorry for the long delay. This is indeed an important
issue and I have fixed it in a quick way. I like your suggestion but I'll need
some time to make it work without breaking users installations.

I'll keep this bug open as wishlist.

Bests,

-- 
Tiago Vaz
https://tvaz.cc

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

2024-05-09 Thread Pascal Hambourg


On 09/05/2024 at 12:42, Jmkr wrote:


- I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/
Archive.tar".

- Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to
"/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again.

- Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/
sdb1".

- Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and
created a new entry for ESP on "/dev/sdb1".


You could just run grub-install to reinstall GRUB into the new ESP and 
register it in EFI boot variables.



Do the fixes mentioned above also address the manual partitioning case?


No, because in manual partitioning it is up to the user to decide which 
ESP(s) is/are suitable for the installation, and set the others as "do 
not use".

Bug#1070803: keepassxc: SSH Agent options not shown, agent does not start

2024-05-09 Thread erebion


Package: keepassxc
Version: keepassxc 2.7.7+dfsg.1-2
Severity: important
X-Debbugs-Cc: ereb...@erebion.eu

Dear maintainer,

SSH agent support has been broken since keepassxc 2.7.7+dfsg.1-2, while 
it works fine with keepassxc 2.7.4+dfsg.1-2.


The menus no longer show the SSH agent functionality and the SSH agent 
no longer works.


Currently the only way to get a working SSH agent setup again is 
downgrading, unfortunately.


This bug seems to have been introduced while solving #1067095.

Please consider having a look at this. :)

Cheers,

erebion

-- System Information:


(The following information might be partly incorrect as I had already 
downgraded the package when I ran reportbug. It is actually for version 
2.7.4+dfsg.1-2, if necessary I can run it again after upgrading.)



Debian Release: trixie/testing
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages keepassxc depends on:
ii libargon2-1 0~20190702+dfsg-4+b1
ii libbotan-2-19 2.19.4+dfsg-1
ii libc6 2.38-7
ii libgcc-s1 14-20240330-1
ii libminizip1t64 [libminizip1] 1:1.3.dfsg-3.1
ii libpcsclite1 2.0.3-1
ii libqrencode4 4.1.1-1+b2
ii libqt5concurrent5t64 [libqt5concurrent5] 5.15.10+dfsg-7.2+b1
ii libqt5core5t64 [libqt5core5a] 5.15.10+dfsg-7.2+b1
ii libqt5dbus5t64 [libqt5dbus5] 5.15.10+dfsg-7.2+b1
ii libqt5gui5t64 [libqt5gui5] 5.15.10+dfsg-7.2+b1
ii libqt5network5t64 [libqt5network5] 5.15.10+dfsg-7.2+b1
ii libqt5svg5 5.15.10-2+b2
ii libqt5widgets5t64 [libqt5widgets5] 5.15.10+dfsg-7.2+b1
ii libqt5x11extras5 5.15.10-2+b2
ii libreadline8t64 [libreadline8] 8.2-4
ii libstdc++6 14-20240330-1
ii libusb-1.0-0 2:1.0.27-1
ii libx11-6 2:1.8.7-1+b1
ii libxtst6 2:1.2.3-1.1+b1
ii libzxcvbn0 2.5+dfsg-2
ii zlib1g 1:1.3.dfsg-3.1

Versions of packages keepassxc recommends:
ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1

Versions of packages keepassxc suggests:
pn webext-keepassxc-browser 
pn xclip 

-- no debconf information

--
erebion

Matrix: @erebion:erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the aforementioned 
languages.



OpenPGP_0x8EAF40326E02AE7D.asc
Description: OpenPGP public key
BEGIN:VCARD
VERSION:4.0
N:;erebion;;;
FN:erebion
EMAIL;PREF=1:ereb...@erebion.eu
IMPP:matrix:u/erebion:erebion.eu
URL:https://erebion.eu
TZ:Europe/Berlin
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#998197: kdeconnectd: should not listen on all interfaces by default

2024-05-09 Thread Patrick Franz

Control: severity -1 important

Hi Witold,

On Tue, 07 May 2024 02:36:46 + Witold Baryluk 
 wrote:
[...]
> Elevating severity, because it looks like I didn't even installed this
> package (I did inspect all apt-get install invokations since system
> creation), and it kdeconnect could only be installed due to some
> suggests / recommends, not due to any dependency or direct request.

How the package was installed on your system, I don't know, but as you 
suspect it was likely a recommendation of another package.

Regarding the issue at hand:
I can see why you consider this a problem. But unfortunately, there is 
no way of changing that behaviour, I suspect the behaviour might be 
intentional. People have requested this feature upstream (https://
bugs.kde.org/show_bug.cgi?id=432378) and even asked for ways to disable 
kdeconnectd (https://bugs.kde.org/show_bug.cgi?id=417615). The latter 
bug report could give you ideas how to achieve that.

If this issue poses a serious problem for you, you can remove kdeconnect 
from your system. That might also give you a hint why it was installed 
in the first place. Upstream KDE actually recommends installing 
kdeconnect as part of the Plasma installation. Whether that 
recommendation fits the Debian's recommendation, is yet to be determined 
and we might have to see over the recommendation.

However, I do disagree about the severity of this. I don't think that 
this issue warrants the removal of kdeconnect from Debian and hence, I'm 
lowering it to important.

-- 
Med vänliga hälsningar

Patrick Franz

Bug#1070667: closed by Sebastian Andrzej Siewior (Re: [Pkg-openssl-devel] Bug#1070667: libssl3: Cannot remove system package:)

2024-05-09 Thread Odysseas Romanos

Dear Sebastian

Thank you very much for your support. I will try manually as you suggested. Do 
you need me to keep you updated or leave it as it is?

Odysseus
Στάλθηκε από το iPhone μου

> 9 Μαΐ 2024, 12:48, ο χρήστης «Debian Bug Tracking System 
> » έγραψε:
> 
> This is an automatic notification regarding your Bug report
> which was filed against the libssl3 package:
> 
> #1070667: libssl3: Cannot remove system package:
> 
> It has been closed by Sebastian Andrzej Siewior .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Sebastian Andrzej 
> Siewior  by
> replying to this email.
> 
> 
> --
> 1070667: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070667
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
>

Bug#1069254: nwipe: FTBFS: configure: error: libconfig library not found

2024-05-09 Thread Emilio Pozuelo Monfort

On Mon, 29 Apr 2024 16:56:55 +0200 "M. van Brummelen"  wrote:

Hi,

On 2024-04-29 10:28, Bo YU wrote:
> Tags: patch
> 
> hi,

> On Thu, Apr 18, 2024 at 10:00:30PM +0200, Sebastian Ramacher wrote:
>> 
>> checking for libconfig... no

>> checking for main in -llibconfig... no
>> configure: error: libconfig library not found
> 
> It seems it shuold use libconfig-dev.

Thanks didn't have the time to test/verify this yet.
Will test/fix and upload in a few days.

You should also look at doing source-only uploads. The current package, even if 
it had built fine, wouldn't have migrated to testing due to the source+amd64 upload:

$ grep-excuses nwipe
[...]
Issues preventing migration:
∙ ∙ Updating nwipe would introduce bugs in testing: #1069254
∙ ∙ Not built on buildd: arch amd64 binaries uploaded by mart...@brumit.nl

Cheers,
Emilio

Bug#1066831: tagging 1066831

2024-05-09 Thread Emilio Pozuelo Monfort


Hi Wouter,

On Wed, 03 Apr 2024 14:17:38 +0200 Wouter Verhelst  wrote:

tags 1066831 + upstream fixed-upstream pending
thanks


Can we have a fix for this in sid? That would help with some ongoing 
transitions, and probably with some installability issues on arm* on testing.


Thanks,
Emilio

Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles

2024-05-09 Thread Manny

Package: texlive-latex-extra
Version: 2022.20230122-4
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com

After an upgrade from Bullseye to Bookworm, the acro package breaks
compilation even if no acronyms are even defined. Documents making use
of acro compiled and functioned fine in the past (version
2020.20210202-3) but no longer compile after the upgrade to
2022.20230122-4.

This is a short sample document:

===8<
\documentclass{scrlttr2}
\usepackage{acro}

%\DeclareAcronym{foo}{short=FOO, long=breaks even if no acronym is defined}

\begin{document}
\begin{letter}{recipient}
  lipsum
\end{letter}
\end{document}
===8<

The error is this:

===8<
ERROR: Package acro Error: Patching `maketitle' failed. Please contact the acro
(acro)author.

Type  to continue.
 ...  
  
l.6 \begin{document}

--- HELP ---
No help available
===8<

The upstream tag was applied because that’s where the defect is, but
action can still be taken on the Debian release. Debian should either
roll back the acro.sty version, or advance it. The current version is
apparently completely unusable. Both latex and pdflatex fail to
compile it. This is the fls file:

===8<
PWD /tmp
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/latex.fmt
INPUT sample.tex
OUTPUT sample.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile-hook.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile-hook.sty

Bug#1070801: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u6

2024-05-09 Thread Michael Tokarev


09.05.2024 14:53, Michael Tokarev wrote:

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: q...@packages.debian.org, pkg-qemu-de...@lists.alioth.debian.org
Control: affects -1 + src:qemu

[ Reason ]
There were 2 qemu stable/bugfix releases (7.2.10 and 7.2.11) since
the previous debian release, fixing a number of various issues.
It would be nice to have these fixes in debian too, so debian users
will benefit from the qemu stable series.

Among others, this release fixes several (low-priority) security
issues: CVE-2024-3446 CVE-2024-3447 CVE-2024-26327 CVE-2024-26328


I forgot to mention here which I already mentioned in the previous qemu
pu report (#1062044).  In this debian release of qemu, I removed revert
of a change which supposedly broke suspend-resume cycle of qemu-based VMs
and hence broke cryptsetup autopkgtests.  The change in question, which is
a bugfix, monitor-only-run-coroutine-commands-in-qemu_aio_context.patch,
has exactly nothing to do with suspend-resume, it's a red herring.
The issue depends on the guest kernel instead, - I *think* it is a memory
layout issue instead.  With current bookworm kernels, with or without
the patch in question, this suspend-resume issue is present for current
qemu and for a few older qemu releases too.

So I'm dropping this revert in this release, hence making debian qemu
sources to match the upstream.

Thanks,

/mjt

Bug#1070791: solaar: Does not restore DPI after suspend

2024-05-09 Thread Stephen Kitt

Hi Bruno,

On Thu, 09 May 2024 11:02:11 +0200, Bruno Kleinert  wrote:
> when the computer wakes up from suspend the DPI setting of the mouse is not
> restored. This had worked in earlier versions of solaar.
> 
> I reproduce this with an MX Master 3S mouse, set to 2000 DPI via the solaar
> configuration window, and the GNOME desktop environment:
> 
> 1. Open solaar from the tray and set mouse to 2000 DPI
> 2. Put the computer into standby via GNOME's power menu
> 3. Wake up the computer
> 4. Moving the mouse cursor appears way slower than the previously configured
> 2000 DPI. My apologies, I didn't figure out how to read the actual DPI value
> from the mouse at this step.
> 
> To work around after wakeup, I open the solaar configuration, click into the
> DPI field, which displays still shows 2000 DPI, and just hit enter.

I think this is fixed upstream — would you mind applying
https://github.com/pwr-Solaar/Solaar/commit/6c11f4e4808063a9a454d4c034a7e40b8e56da5c
to /usr/share/solaar/lib/solaar/dbus.py to see if suspend is handled
correctly?

Regards,

Stephen


pgpJsK0_Qsdmq.pgp
Description: OpenPGP digital signature

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

Sorry about the wrong order/formatting of last two messages. The webmail 
interface of Seznam.cz has totally idiotic and unconfigurable defaults and I 
keep forgetting to click their "Plain Text" button and keep forgetting to 
remove unnecessary "Quoted Reply Texts" that their idiotic interface forces on 
me. I will fix my Thunderbird profile to save myself from Seznam's idiotic 
webmail interface as soon as I have time for it.

Jmkr

Bug#1070753: (no subject)

2024-05-09 Thread Steven Maddox

It would seem the -A argument (for pppoe-discovery not ps) has been 
removed as a result of this bug report... #1042881


However this doesn't change that pppoe-discovery seems to indefinitely 
pause (preventing grep from realising there is an AC) in some 
circumstances.  Ultimately I've logged an issue about this upstream 
here... https://github.com/ppp-project/ppp/issues/490


But none of this would be an issue if this was rewritten to use -Q instead.

--
Steven Maddox
Lantizia

Bug#1070773: libglib2.0-dev:i386 on amd64 should not require qemu-user

2024-05-09 Thread Simon McVittie

Control: retitle -1 libglib2.0-dev:i386 on amd64 should not require qemu-user
Control: severity -1 wishlist
Control: tags -1 + help

On Wed, 08 May 2024 at 23:32:03 +0100, Simon McVittie wrote:
> > So, I now have to install qemu-user as dependency, which comes with a few 
> > other
> > heavy dependencies. Is this really needed, and how does that help at all?
> 
> For the special case of i386 on an amd64 system, qemu is usually not
> actually needed because amd64 systems can nearly always run i386 binaries
> directly (although I believe there are kernel configurations that will
> not allow that), but it's not obvious how to express that conditional
> dependency in apt syntax.
> 
> Tested patches welcome

Retitling the bug to reflect this.

smcv

Bug#1070800: ITP: evremap -- keyboard input remapper for Linux/Wayland systems

2024-05-09 Thread debian

Subject: ITP: evremap -- keyboard input remapper for Linux/Wayland systems
Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Yifei Zhan 
Severity: wishlist

* Package name: evremap
  Version : 0.1.0
  Upstream Author : Wez Furlong
* URL : https://github.com/wez/evremap
* License : MIT
  Programming Lang: Rust
  Description : keyboard input remapper for Linux/Wayland systems

evremap works by grabbing exclusive access to an input device and maintaining 
a model of the keys that are pressed. It then applies your remapping 
configuration to produce the effective set of pressed keys and emits 
appropriate changes to a virtual output device.

Because evremap targets the evdev layer of libinput, its remapping is 
effective system-wide: in Wayland, X11 and the linux console.

(^ from project readme)

It works well on my machines and supports more complex mapping (e.g. dual role
key based on tapping/holding and M <-> N mapping (F3 -> Ctrl-K / Shift-K ->
F5)) while maintaining a simple configure syntax.

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

I had a similar problem with my customized Debian 10 installer. I have not
customized PARTMAN related UDEB packages yet, so these are at Debian 10 
versions. What I did was I installed my Debian in one of my test laptops 
that also had another SSD with some Windows 11 installation that I plan to
nuke later:). All was working and booting, but when I added ESP capacity 
monitoring to my CONKY configurations, I noticed that this laptop had
different ESP space occupied than my other laptops with the same hardware.
After checking what is going on I found that:

- The ESP created by me during manual disk partitioning on the SSD that is
used for my Debian system was empty and not used at all (not mounted at "/
boot/efi" and not mentioned in "/etc/fstab").

- Instead the ESP from the other SSD with the Windows 11 installation was 
used. It was mounted at "/boot/efi", its UUID was in "/etc/fstab" and DI/
GRUB installed the "EFI/debian/grubx64.efi" file there right next to the 
"Microsoft" and "Boot" directories that contained the Windows garbage.

Thankfully I did not boot that Windows 11 installation, so Windows were not
able to mess around with the Debian files that rudely appeared on "their" 
disk. I was able to (hopefully) fix the situation when I noticed it:

- I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/
Archive.tar".

- Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to
"/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again.

- Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/
sdb1".

- Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and
created a new entry for ESP on "/dev/sdb1".

- Then, I tested that the system boots as before using the new EFI and FSTAB
entries and correct ESP.

Did I forget something (that will cause problems in the future) by not
reinstalling GRUB or some other stuff?

Do the fixes mentioned above also address the manual partitioning case? If
not perhaps you could check that case also. I will keep the Windows 11
installation (as this laptop is for testing anyway) = if you want I could
test the fixed PARTMAN files, if these are provided so that my script for 
customizing the Debian Netinst ISO can include them (after I modify it to 
extract a new PARTMAN TAR or copy new PARTMAN files directly to the
extracted Debian Netinst ISO). (In the future I plan to learn how to create
DI ISO from scratch to be able to include modified UDEB packages etc. => if
that is needed for testing and you can provide some starting instructions 
for me I could try that also.)

Regards,
Jmkr

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

By the way at
"https://www.reddit.com/r/debian/comments/wfk4xt/debian_keeps_installing_bootloader_in_wrong_disk/";
other people mention similar problems that are/could be related to this bug.

Jmkr

-- Původní e-mail --
Od: Jmkr
Komu: 1034...@bugs.debian.org, pas...@plouf.fr.eu.org, k...@debian.org,
deb...@jamesie.de, a...@hax0rbana.org
Datum: 9. 5. 2024 10:42:41
Předmět: Re: Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
I had a similar problem with my customized Debian 10 installer. I have not
customized PARTMAN related UDEB packages yet, so these are at Debian 10
versions. What I did was I installed my Debian in one of my test laptops that
also had another SSD with some Windows 11 installation that I plan to nuke
later:). All was working and booting, but when I added ESP capacity monitoring
to my CONKY configurations, I noticed that this laptop had different ESP space
occupied than my other laptops with the same hardware. After checking what is
going on I found that:

- The ESP created by me during manual disk partitioning on the SSD that is used
for my Debian system was empty and not used at all (not mounted at "/boot/efi"
and not mentioned in "/etc/fstab").

- Instead the ESP from the other SSD with the Windows 11 installation was used.
It was mounted at "/boot/efi", its UUID was in "/etc/fstab" and DI/GRUB
installed the "EFI/debian/grubx64.efi" file there right next to the "Microsoft"
and "Boot" directories that contained the Windows garbage.

Thankfully I did not boot that Windows 11 installation, so Windows were not
able to mess around with the Debian files that rudely appeared on "their" disk.
I was able to (hopefully) fix the situation when I noticed it:

- I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to
"/Archive.tar".

- Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to
"/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again.

- Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on
"/dev/sdb1".

- Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and
created a new entry for ESP on "/dev/sdb1".

- Then, I tested that the system boots as before using the new EFI and FSTAB
entries and correct ESP.

Did I forget something (that will cause problems in the future) by not
reinstalling GRUB or some other stuff?

Do the fixes mentioned above also address the manual partitioning case? If not
perhaps you could check that case also. I will keep the Windows 11 installation
(as this laptop is for testing anyway) = if you want I could test the fixed
PARTMAN files, if these are provided so that my script for customizing the
Debian Netinst ISO can include them (after I modify it to extract a new PARTMAN
TAR or copy new PARTMAN files directly to the extracted Debian Netinst ISO).
(In the future I plan to learn how to create DI ISO from scratch to be able to
include modified UDEB packages etc. => if that is needed for testing and you
can provide some starting instructions for me I could try that also.)

Regards,
Jmkr

Bug#1070771: upgrade-reports: After updating with apt upgrade, writing dead keys in Portuguese stopped working

2024-05-09 Thread Dudu

Hi, I hope to see you well,

I verified that the issue has been fixed by updating the glib2 package to
version 2.74.6-2+deb12u2 in my simulation setup, as you instructed.

Thanks for the answer!

Kind regards,

Em qui., 9 de mai. de 2024 às 03:13, Paul Gevers 
escreveu:

> Hi
>
> On 08-05-2024 10:27 p.m., Eduardo Rolim wrote:
> > After the upgrade, the system no longer recognizes Portuguese accents,
> > rendering typing of accents impossible.
>
> Might this be related to
> https://lists.debian.org/debian-security-announce/2024/msg00094.html
>
> If so, updating glib2.0 with the latest version in stable-security
> should solve the problem.
>
> Paul
>

-- 
*"Se a criptografia fosse proibida, fbzragr bf sbenf qn yrv grevnz
cevinpvqnqr"*

*Eduardo Rolim*
Uberlândia, Minas Gerais, Brasil

Bug#1070799: bullseye-pu: package rustc-web/1.70.0+dfsg1-7~deb11u1

2024-05-09 Thread Emilio Pozuelo Monfort

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hi,

rustc-web is needed to keep supporting firefox-esr/thunderbird on bullseye,
for the upcoming ESR 128 releases. Instead of updating rustc-mozilla, I
decided to backport the newer rustc-web (adopting that name) from bookworm.
The backport is clean, just a changelog bump. I'm attaching the debdiff from
the bookworm update to this one.

Package is already uploaded, but if you find any issues feel free to reject
it. Hopefully this can make it into the final bullseye point release.

I've successfully used this to build a backport of cbindgen and then firefox
125, which works well. A cbindgen pu for both bookworm and bullseye will
be proposed later once I verify that it doesn't cause any issues to current
ESR 115.

Thanks,
Emilio
diff -Nru rustc-web-1.70.0+dfsg1/debian/changelog 
rustc-web-1.70.0+dfsg1/debian/changelog
--- rustc-web-1.70.0+dfsg1/debian/changelog 2024-03-02 08:23:15.0 
+0100
+++ rustc-web-1.70.0+dfsg1/debian/changelog 2024-04-29 11:08:43.0 
+0200
@@ -1,3 +1,10 @@
+rustc-web (1.70.0+dfsg1-7~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport to bullseye.
+
+ -- Emilio Pozuelo Monfort   Mon, 29 Apr 2024 11:08:43 +0200
+
 rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium
 
   * Non-maintainer upload.

Bug#1064648: allegro5-doc: please make the build reproducible.

2024-05-09 Thread Andreas Rönnquist

Control: reopen 1064648

Those fixes was obviously not enough, just see the repro reports.

The strange thing is that it according to the tests does seem to build
reproducible on arm64... 

One other detail is that on armhf the only change seems to be the
architecture which is included in the ALLEGRO_PKG_HOST_SYSTEM variable.

Is there some magic like SOURCE_DATE_EPOCH to use that would avoid this
problem in this case?

best
/Andreas
gus...@debian.org

Bug#1070794: dh_clean should not remove pycache folder by default

2024-05-09 Thread Niels Thykier


Control: tags 1070794 wontfix
# Solution options provided below.
# (BTS processing instructions have to go in the top)

On Thu, 9 May 2024 09:20:01 + Hang Lei  wrote:

Package: debhelper
Version: 13.11.10

Dear Maintainer,

I'm writing to discuss a change introduced in debhelper 13.10.10: this 
PR fixes 
#1048890 by deleting the 
__pycache__ folder.

[...]

Considering the impact on performance, I believe that removing the __pycache__ 
directory may not be beneficial. Could we explore the possibility of reverting 
this change?

Thanks for your time and consideration.

Related issue: [Packaging] Add Ubuntu 24.04 Noble Numbat support by bebound * Pull 
Request #2 * Azure/azure-cli 
(github.com)

Cheers,
Hang


Hi Hang

Thanks for reaching out. :)

No Debian package ships `.pyc` files directly in the `.deb`. Instead 
they generate them during installation. I am not super well-versed in 
this area, so I cannot be fully helpful on all of the rationales behind 
the decision to byte-compile on install (and clean up on removal). You 
would have to ask the Debian Python Team / Debian Python Policy 
maintainers if that rationale is important. As I recall, it involves (or 
involved) cases like people running python code as root, reproducible 
builds, multiple interpreter support (including embedded interpreters) 
and special cases in that ballpark.


What I do know, is that this byte compilation for Debian packages is 
generally triggered by using `dh_python3` from the `dh-python` package 
for python3 files[1]. The `dh_python3` helper is *not* enabled by 
default.  With modern debhelper versions adding `dh-sequence-python3` to 
Build-Depends would do. Older versions of `debhelper` would require a 
`dh ... --with python3`.


Since the package in question does not seem to install the python files 
in the "standard" locations (I noted an `/opt` in the GitHub PR), you 
may have to consult the `dh-python` documentation for having it set up 
the recompilation correctly. See 
https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dh_python3.rst?ref_type=heads 
(heading "private dirs" seems relevant)


That documentation also has sections for exceptions to the byte 
compilation via the `bcep` files. Like if certain files can only be 
compiled with a given version of python (etc.).


This is the only solution I can offer you with the current Python 
landscape in Debian. If you want to change that landscape, I am afraid I 
will have to ask you to raise the concerns with the Python team and they 
are the authority on this topic.  Because it is not my jurisdiction and 
I cannot offer to be middleman in challenging the landscape, I have 
tagged this bug as `wontfix`, since it is the closest tag we have for 
this case.


I hope it was helpful and enable you to restore the original performance.

Best regards,
Niels

[1]: Historically, there was also a `dh_python`, which may be relevant 
if you still support python2 and Debian/Ubuntu releases that still have 
`python2`. That is probably so old that it only works with

`dh ... --with python`.

Bug#1066941:

2024-05-09 Thread Lluís Vilanova

Ñ la Kate de casa de mi hermana. N.  3344



















55

Bug#1070798: O: libelfin -- C++11 ELF/DWARF parser



Package: wnpp
Severity: normal

The maintainer of libelfin, Lluís Vilanova, has not been around for
several years, so I believe it is time to orphan the package I helped
him maintain.

https://tracker.debian.org/pkg/libelfin >
-- 
Happy hacking
Petter Reinholdtsen

Bug#1070797: O: coz-profiler -- Finding Code that Counts with Causal Profiling