Bug#625895: logcheck-database: /etc/logcheck/ignore.d.server/dovecot rule misses unusual Message-Id

[Gerald Turner]

Hi Richard,

On Sun, May 12 2024, Richard Lewis wrote:
> On Fri, 06 May 2011 11:32:03 -0700 Gerald Turner  wrote:
>> Hello, I've seen some legitimate mails with unusual Message-Id headers
>> that cause logchecks dovecot delivery rule to be bypassed.
>>
>> Example: … sieve: msgid=<20110422T2108.GA.(stdi.s...@fsing.rootsland.net>:
>> stored mail into mailbox 'Mailing Lists/Debian/debian-devel'
>
> It's a shame no-one replied since 2011.
>
> That doesnt seem to be a valid msgid, so not sure logcheck should be
> ignoring it by default. Obviously you can edit / make your own rules
> to do so.
> So not sure there is anything for debian to do in this one. Perhaps we
> should close the bug?

Yes, please close the bug.

Apparently, thirteen years ago, I was in the spirit of opening many bugs
to try and improve logcheck, however that is an immense task, one size
*does not* fit all (such as invalid Message-Id), and I've grown
accustomed to writing many personal rules.

FWIW, I run logcheck on a dozen machines, have a large catalog of rules
applied via ansible, and I find it immensely useful for 1) discovering
daemon configuration problems, and 2) occasionally dealing with exotic
brute force attempts.  Peace of mind at the expense of adjusting rules
after a dist-upgrade every few years.

Keep up the good work =)

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#1055496: how-can-i-help: should detect that is run by unattended-upgrades & skip

[Paul Wise]

On Tue, 2023-11-07 at 12:10 +0100, Alexandre Detiste wrote:

> how-can-i-help: should detect that is run by unattended-upgrades & skip
> Possible solution: skip execution if STDIN is not a TTY.

I filter and then read my unattended-upgrades mails, so
this would break my normal usage of how-can-i-help output.

> When running unattended-upgrades (from it's .timer/.service),
> how-can-i-help will be called so many times
> and that will clutter logs.

unattended-upgrades should only call how-can-i-help once per upgrade,
unless you have the minimal steps option enabled?

The log clutter could be solved by not printing the header/footer
unless there are some help items to be printed too.

> But the next time apt is run interractively,
> it won't display new "tasks" again,
> becauses they are not considered new anymore.

Perhaps there could be options to mark or not mark the newly discovered
problems as new, then folks could customise the apt hook as needed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1071008: libx52pro0: installs udev rules twice to /usr and /

[Petter Reinholdtsen]

[Helmut Grohne]
> since the last upload, libx52pro0 contains both
> /lib/udev/rules.d/99-x52pro.rules and
> /usr/lib/udev/rules.d/99-x52pro.rule.

Ah, thanks for letting me know.  Sorry I failed to discovered this
during testing.  I will keep the issue with dh_install
vs. dh_installudev in mind for the future when converting to simple 'dh'
based builds.

Note, the package is orphaned and its git repository is available from
https://tracker.debian.org/pkg/x52pro >, so you can push the fix
directly there.

-- 
Happy hacking
Petter Reinholdtsen

Bug#839546: apt upgrade wants to install packages that apt autoremove will remove

[Olly Betts]

On Sat, Oct 01, 2016 at 11:15:28PM +0300, Sami Liedes wrote:
> apt upgrade lists some packages as new packages that will be
> installed, but at the same time lists those packages as "automatically
> installed and no longer required".
[...]
> Note that all of the NEW packages that will be installed are also in
> the autoremoveable list (contrary to what apt says, those packages are
> not yet installed).

I'm seeing what appears to be the same problem, so this bug still seems
to be present:

root@gemse:~# apt upgrade
The following packages were automatically installed and are no longer required:
  libqt6network6t64 libqt6opengl6t64 libqt6openglwidgets6t64 libqt6xml6t64
Use 'apt autoremove' to remove them.

Installing dependencies:
  libqt6network6t64 libqt6opengl6t64 libqt6openglwidgets6t64 libqt6xml6t64

Not upgrading:
  htmldoc libcanberra-pulse libnode-dev libnode109 nodejs octave octave-common 
octave-dev

Summary:
  Upgrading: 0, Installing: 4, Removing: 0, Not Upgrading: 8
  Download size: 1,201 kB
  Space needed: 4,552 kB / 1,749 GB available

Continue? [Y/n] n
Abort.
root@gemse:~# apt autoremove
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 8
root@gemse:~# apt --version
apt 2.9.2 (amd64)

If there's stuff I can usefully prod to help debug what's causing this
please let me know.

Cheers,
Olly

Bug#1071010: Fixed upstream

[Ken McDonell]

Commit 
https://github.com/performancecopilot/pcp/commit/bf6c6f5ed69eeadfe697958b1c060fd947923058
resolves this issue by moving the PCP pmcheck command out of /usr/bin.

Bug#1071025: zathura: please add support for loong64

[wuruilong]

Source: zathura
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

zathura compiled incorrectly on loongarch architecture, the attached patch 
solved the above problem and compiled successfully. Please refer to patch to 
modify the code.

wuruilong

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

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 zathura (0.5.6-1) unstable; urgency=medium
 .
   * Upload to unstable
   * New upstream version 0.5.6
   * debian/control: Bump Standards version
Author: Sebastian Ramacher 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-05-13

--- zathura-0.5.6.orig/zathura/seccomp-filters.c
+++ zathura-0.5.6/zathura/seccomp-filters.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include  /* for clone filter */
+#include 
 
 #ifdef GDK_WINDOWING_X11
 #include 
@@ -74,7 +75,9 @@ seccomp_enable_strict_filter(zathura_t*
   /* ALLOW_RULE(fadvise64); */
   ALLOW_RULE(fallocate);
   ALLOW_RULE(fcntl);  /* TODO: build detailed filter */
+#ifdef __NR_fstat
   ALLOW_RULE(fstat); /* used by older libc, stat (below), lstat(below), 
fstatat, newfstatat(below) */
+#endif
   ALLOW_RULE(fstatfs); /* statfs (below) */
   ALLOW_RULE(ftruncate);
   ALLOW_RULE(futex);

Bug#1071024: RFP: chatterino -- Chatterino is a chat client for Twitch chat.

[matt]

Package: wnpp
Severity: wishlist

* Package name: chatterino
  Version : 2.4.6
  Upstream Author : https://github.com/chatterino/chatterino2
* URL : https://chatterino.com/

* URL :
* License : (MIT)
  Programming Lang: (C++)
  Description : Chatterino is a chat client for Twitch chat.

Chatterino is a chat client for Twitch chat. It aims to be an
improved/extended version of the Twitch web chat.

 - this package is useful to me because I don't need to open the browser
   to look at chat, it does not have dependencies
   for any other packages, I use it, gnome-twitch has similar
   functionality but is unmaintained and lacks features that chatterino has 
example banning seeing certain emotes,
 - I plan on maintaining it by compiling the latest package or use the
   deb they provide, inside a packaging team
 I would need a need a sponsor

Bug#1071023: RFP: streamlink-twitch-gui -- A multi-platform Twitch.tv browser for Streamlink

[matt]

Package: wnpp
Severity: wishlist

* Package name: streamlink-twitch-gui
  Version : 2.4.1
  Upstream Author : Sebastian Meyer
* URL : https://streamlink.github.io/streamlink-twitch-gui/
* License : (MIT/X,)
  Programming Lang: (JavaScript)
  Description : A multi-platform Twitch.tv browser for Streamlink

A graphical user interface on top of the Streamlink command line interface.
Built with NW.js, a web application platform powered by Chromium and Node.js.

- this package is useful to me because I don't need to open the browser
   to watch a twitch stream, it does not have dependencies
   for any other packages, I use it, gnome-twitch has similar
   functionality but is unmaintained and lacks features that 
streamlink-twitch-gui has example hiding vods,

Bug#1071022: RFP: ly -- a TUI display manager

[matt]

Package: wnpp
Severity: wishlist

* Package name: ly
  Version : 0.6.0
  Upstream Author : https://github.com/fairyglade
* URL : https://github.com/fairyglade/ly
* License : (wtfpl)
  Programming Lang: (C)
  Description : a TUI display manager

lightweight TUI (ncurses-like) display manager for Linux and BSD.
this package is useful to me because it's a tui display manager instead
of a graphical display manager, 
it does not have dependencies for any other packages, I use it, 
 emptty  can be considered similar because it's not a graphical display manger 
however, it's a tui display manager instead of a cli display manager,

Bug#1071021: RFP: streamlink-twitch-gui -- A multi-platform Twitch.tv browser for Streamlink

[matt]

Package: wnpp
Severity: wishlist

- this package is useful to me because I don't need to open the browser
   to watch a twitch stream, it does not have dependencies
   for any other packages, I use it, gnome-twitch has similar
   functionality but is unmaintained and lacks features that 
streamlink-twitch-gui has example hiding vods,

Bug#1071020: stenographer: please add support for loong64

[wuruilong]

Source: stenographer
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

stenographer compiled incorrectly on loongarch architecture, the attached patch 
solved the above problem and compiled successfully. Please refer to patch to 
modify the code.

wuruilong

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

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 stenographer (1.0.1-4) unstable; urgency=medium
 .
   * Try to make autopkgtests more robust.
   * Correctly use "skippable" autopkgtest property.
Author: Sascha Steinbiss 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-05-13

--- stenographer-1.0.1.orig/stenotype/stenotype.cc
+++ stenographer-1.0.1/stenotype/stenotype.cc
@@ -307,7 +307,9 @@ void CommonPrivileges(scmp_filter_ctx ct
   SECCOMP_RULE_ADD(ctx, SCMP_ACT_ALLOW, SCMP_SYS(openat), 0);
   SECCOMP_RULE_ADD(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fallocate), 0);
   SECCOMP_RULE_ADD(ctx, SCMP_ACT_ALLOW, SCMP_SYS(ftruncate), 0);
+#ifdef __NR_fstat
   SECCOMP_RULE_ADD(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstat), 0);
+#endif
 #ifdef __NR_fstat64
   SECCOMP_RULE_ADD(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstat64), 0);
 #endif

Bug#1071019: openturns: please add support for loong64

[wuruilong]

Source: openturns
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

openturns compiled incorrectly on loongarch architecture, the attached patch 
solved the above problem and compiled successfully. Please refer to patch to 
modify the code.

wuruilong

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

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--- openturns-1.21.1/debian/rules   2024-04-18 21:10:50.0 +
+++ openturns/debian/rules  2024-05-13 02:52:40.370327122 +
@@ -29,6 +29,11 @@
 test_discardflags := -E \\\"Dlib_.*\\\"
 endif
 
+# On loong64, deactivating Dlib tests (seems to be a bug in Dlib)
+ifeq ($(shell dpkg --print-architecture),loong64)
+test_discardflags := -E \\\"Dlib_.*\\\"
+endif
+
 BUILD_DATE = $(shell date --utc --date="@$(SOURCE_DATE_EPOCH)" "+%a, %d %b %Y 
%H:%M:%S %z")
 
 %:

Bug#1071018: ovn: please add support for loong64

[wuruilong]

Source: ovn
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

ovn compiled incorrectly on loongarch architecture, the attached patch solved 
the above problem and compiled successfully. Please refer to patch to modify 
the code.

wuruilong

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

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
send gratuitous arp on localnet
1 LR with distributed router gateway port
router - check packet length - icmp defrag
multi-vtep SB Chassis encap updates
ACL with Port Group conjunction flow efficiency
ipsec -- basic configuration
ovn-controller incremental processing

Bug#1068352: Looking for an update

[Network Operations Center]

Hello!
Any updates on this request?

Bug#1071017: FTBFS: source-copy.cpp:615:31: error: ‘void obs_sceneitem_get_info(const obs_sceneitem_t*, obs_transform_info*)’ is deprecated [-Werror=deprecated-declarations]

[Joao Eriberto Mota Filho]

Package: obs-source-copy
Version: 0.2.2-5
Severity: serious
Tags: upstream
Justification: FTBFS

When rebuilding the source code, we got:

/usr/bin/c++ -DHAVE_OBSCONFIG_H -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG 
-DQT_WIDGETS_LIB -Dsource_copy_EXPORTS 
-I/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/obj-x86_64-linux-gnu/source-copy_autogen/include
 -isystem /usr/include/obs -isystem /usr/include/x86_64-linux-gnu/qt6/QtWidgets 
-isystem /usr/include/x86_64-linux-gnu/qt6 -isystem 
/usr/include/x86_64-linux-gnu/qt6/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt6/QtGui -g -O2 
-ffile-prefix-map=/PKGS/obs-source-copy/1/obs-source-copy-0.2.2=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-Werror -Wextra -Wvla -Wformat -Wformat-security -Wswitch -Wunused-parameter 
-Wno-unused-function -Wno-missing-field-initializers -fno-strict-aliasing 
-Wconversion-null -fPIC -mmmx -msse -msse2 -MD -MT 
CMakeFiles/source-copy.dir/source-copy.cpp.o -MF 
CMakeFiles/source-copy.dir/source-copy.cpp.o.d -o 
CMakeFiles/source-copy.dir/source-copy.cpp.o -c 
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.cpp
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.cpp: In function 
‘obs_data_t* GetTransformData(obs_sceneitem_t*)’:
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.cpp:595:31: error: 
‘void obs_sceneitem_get_info(const obs_sceneitem_t*, obs_transform_info*)’ is 
deprecated [-Werror=deprecated-declarations]
  595 | obs_sceneitem_get_info(item, );
  | ~~^
In file included from 
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.hpp:3,
 from 
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.cpp:1:
/usr/include/obs/obs.h:1889:1: note: declared here
 1889 | obs_sceneitem_get_info(const obs_sceneitem_t *item,
  | ^~
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.cpp: In function 
‘void LoadTransform(obs_sceneitem_t*, obs_data_t*)’:
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.cpp:615:31: error: 
‘void obs_sceneitem_get_info(const obs_sceneitem_t*, obs_transform_info*)’ is 
deprecated [-Werror=deprecated-declarations]
  615 | obs_sceneitem_get_info(item, );
  | ~~^
/usr/include/obs/obs.h:1889:1: note: declared here
 1889 | obs_sceneitem_get_info(const obs_sceneitem_t *item,
  | ^~
/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/source-copy.cpp:624:31: error: 
‘void obs_sceneitem_set_info(obs_sceneitem_t*, const obs_transform_info*)’ is 
deprecated [-Werror=deprecated-declarations]
  624 | obs_sceneitem_set_info(item, );
  | ~~^
/usr/include/obs/obs.h:1892:1: note: declared here
 1892 | obs_sceneitem_set_info(obs_sceneitem_t *item,
  | ^~
cc1plus: all warnings being treated as errors
make[3]: *** [CMakeFiles/source-copy.dir/build.make:100: 
CMakeFiles/source-copy.dir/source-copy.cpp.o] Error 1
make[3]: Leaving directory 
'/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:89: CMakeFiles/source-copy.dir/all] Error 2
make[2]: Leaving directory 
'/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:159: all] Error 2
make[1]: Leaving directory 
'/PKGS/obs-source-copy/1/obs-source-copy-0.2.2/obj-x86_64-linux-gnu'
dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j16 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:14: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1184:
dpkg-buildpackage -us -uc -ui failed

Eriberto

Bug#1071016: node-temp: missing "let" before crypto trips up nodejs 20

[Jérémy Lal]

Package: node-temp
Version: 0.9.4+~0.9.1-1
Severity: important

Hi,

this is needed to avoid failures when using nodejs 20.13.0

--- node-temp-0.9.4+~0.9.1.orig/lib/temp.js
+++ node-temp-0.9.4+~0.9.1/lib/temp.js
@@ -1,7 +1,7 @@
 let fs   = require('fs');
 let path = require('path');
 let cnst = require('constants');
-crypto = require('crypto');
+let crypto = require('crypto');
 
 let os = require('os');
 let rimraf = require('rimraf');


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

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

Versions of packages node-temp depends on:
ii  node-mkdirp  1.0.4+~1.0.2-4
ii  node-rimraf  3.0.2-2

node-temp recommends no packages.

node-temp suggests no packages.

-- no debconf information

Bug#1071015: RFS: color-picker/1.0.3-3 -- Powerful screen color picker based on Qt

[Hugo Torres de Lima]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "color-picker":

 * Package name : color-picker
   Version  : 1.0.3-3
   Upstream contact : https://github.com/keshavbhatt/ColorPicker/issues
 * URL  : https://github.com/keshavbhatt/ColorPicker
 * License  : MIT
 * Vcs  : https://salsa.debian.org/debian/colorpicker
   Section  : graphics

The source builds the following binary packages:

  color-picker - Powerful screen color picker based on Qt

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

  https://mentors.debian.net/package/color-picker/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/color-picker/color-picker_1.0.3-3.dsc

Changes since the last upload:

 color-picker (1.0.3-3) unstable; urgency=medium
 .
   * debian/control: bumped Standards-Version to 4.7.0.
   * debian/copyright: Updated dates.
   * debian/patches/01-segfaults.patch:
   - Created. Thanks to Sudip Mukherjee (Closes: #1060003)

Regards,
--
  Hugo Torres de Lima

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

[Svjatoslav Agejenko]

Dear Alban Browaeys,

I am writing in response to the recent communication regarding the
segfault issue in totem-video-thumbnailer (Bug#973942), which I
initially reported on Sat, 06 Mar 2021.

Firstly, I would like to thank you for your continued efforts in
maintaining Debian packages and addressing bug reports.

As per your request, I have conducted the suggested tests on my
current system:

OS: Debian GNU/Linux 12
Kernel: 6.1.0-20-amd64


Test 1:

Running the command without the `-l` option resulted in a "Killed"
message, which I believe is different from the expected behavior of a
segmentation fault or a stopped process. The verbose output and
GStreamer debug logs did not indicate any critical errors that would
lead to a segfault.



~/Desktop/thumbnail$ /usr/bin/totem-video-thumbnailer --verbose 
--gst-debug-level=3 -s 256 test.mp4 test.png
TotemVideoThumbnailer-Message: 14:12:36.705: Initialised libraries, about to 
create video widget
TotemVideoThumbnailer-Message: 14:12:36.716: setting URI 
file:///home/n0/Desktop/thumbnail/test.mp4
TotemVideoThumbnailer-Message: 14:12:36.716: Video widget created
TotemVideoThumbnailer-Message: 14:12:36.716: About to open video file
0:00:00.029094396 233674 0x55d6bf93e160 WARN basesrc 
gstbasesrc.c:3693:gst_base_src_start_complete: pad not activated yet
0:00:00.029690764 233674 0x55d6bf93e160 WARN basesrc 
gstbasesrc.c:3693:gst_base_src_start_complete: pad not activated yet
0:00:00.051312188 233674 0x7fe7682e8800 WARN qtdemux 
qtdemux.c:3238:qtdemux_parse_trex: failed to find fragment defaults 
for stream 1
0:00:00.051525758 233674 0x7fe7682e8800 WARN qtdemux 
qtdemux.c:3238:qtdemux_parse_trex: failed to find fragment defaults 
for stream 2
0:00:00.202566191 233674 0x7fe7682e8800 WARNvideodecoder 
gstvideodecoder.c:931:gst_video_decoder_setcaps: Subclass refused 
caps
0:00:00.203669199 233674 0x7fe7682e8800 WARN   decodebin 
gstdecodebin2.c:2554:connect_pad: Couldn't set avdec_h264-0 to 
PAUSED
0:00:00.204188843 233674 0x7fe7682e8800 WARNuridecodebin 
gsturidecodebin.c:982:unknown_type_cb: warning: No decoder 
available for type 'video/x-h264, stream-format=(string)avc, 
alignment=(string)au, level=(string)4.2, profile=(string)high, 
codec_data=(buffer)0164002affe100186764002aacb200b405ad8088014d51089c3ec78078c1924001000568ebccb22c,
 width=(int)1440, height=(int)1440, framerate=(fraction)60/1, 
pixel-aspect-ratio=(fraction)1/1, coded-picture-structure=(string)frame, 
chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, 
parsed=(boolean)true'.
0:00:00.239785202 233674 0x7fe7682e8f00 WARNplaysink 
gstplaysink.c:2908:gen_audio_chain: warning: No volume control found
0:00:00.239834995 233674 0x7fe7682e8f00 WARNplaysink 
gstplaysink.c:2908:gen_audio_chain: warning: Volume/mute is not 
available
0:00:00.242465037 233674 0x7fe70c013180 WARN audio-resampler 
audio-resampler.c:274:convert_taps_gint16_c: can't find exact taps
TotemVideoThumbnailer-Message: 14:12:36.932: Checking whether file has cover
TotemVideoThumbnailer-Message: 14:12:36.933: totem-video-thumbnailer couldn't 
find a video track in 'test.mp4'

Killed





Test 2:

Running the command with the `-l` option successfully generated a
valid thumbnail:


~/Desktop/thumbnail$ /usr/bin/totem-video-thumbnailer -l --verbose 
--gst-debug-level=3 -s 256 test.mp4 test.png
TotemVideoThumbnailer-Message: 14:14:26.802: Initialised libraries, about to 
create video widget
TotemVideoThumbnailer-Message: 14:14:26.812: setting URI 
file:///home/n0/Desktop/thumbnail/test.mp4
TotemVideoThumbnailer-Message: 14:14:26.813: Video widget created
TotemVideoThumbnailer-Message: 14:14:26.813: About to open video file
0:00:00.029025598 234491 0x55fdbaf9f360 WARN basesrc 
gstbasesrc.c:3693:gst_base_src_start_complete: pad not activated yet
0:00:00.029630482 234491 0x55fdbaf9f360 WARN basesrc 
gstbasesrc.c:3693:gst_base_src_start_complete: pad not activated yet
0:00:00.052866322 234491 0x7efbfc2e8800 WARN qtdemux 
qtdemux.c:3238:qtdemux_parse_trex: failed to find fragment defaults 
for stream 1
0:00:00.052963214 234491 0x7efbfc2e8800 WARN qtdemux 
qtdemux.c:3238:qtdemux_parse_trex: failed to find fragment defaults 
for stream 2
0:00:00.293619419 234491 0x7efbfc2e8f00 WARNplaysink 
gstplaysink.c:2908:gen_audio_chain: warning: No volume control found
0:00:00.293762828 234491 0x7efbfc2e8f00 WARNplaysink 
gstplaysink.c:2908:gen_audio_chain: warning: Volume/mute is not 
available
0:00:00.295188401 234491 0x7efb80056de0 WARN audio-resampler 
audio-resampler.c:274:convert_taps_gint16_c: can't find exact taps
TotemVideoThumbnailer-Message: 14:14:27.082: Checking whether file has cover
TotemVideoThumbnailer-Message: 14:14:27.082: Opened video file: 'test.mp4'

Bug#1031439: fixed in gcc-sh-elf 4.1 but unfixed later

[Santiago Vila]

found 1031439 8
tags 1031439 + patch
tags 1031439 - fixed
thanks

Hi.

For some reason, version 8 does not include the fix that was
applied in version 4.1 to fix this bug. As a result, the
current version still has the bug (see attach).

I'm including the patch (taken from the diff between 4 and 4.1
from snapshot.debian.org) in the second attach.

Thanks.

gcc-sh-elf_amd64-20240512T225321Z.gz
Description: application/gzip
commit 2a5b2f8d7a6b55fd9a8e1e1792ab2fde143178d3
Author: John Scott 
Date:   Mon Apr 10 18:56:40 2023 -0400

Include a fix for building with newer GDB. Closes: #1031439.

--- a/debian/rules
+++ b/debian/rules
@@ -39,6 +39,9 @@ src:
then ln -s "$$i" . || exit 1; \
fi; \
done
+# gcc's configure script is too old to build GDB right.
+   cd $@ && rm -f Makefile.def Makefile.in configure
+   cd $@ && cp ../gdb*/Makefile.def ../gdb*/Makefile.in ../gdb*/configure .
 
 # Avoid dh_auto_*, see
 # https://gcc.gnu.org/legacy-ml/gcc/2013-04/msg00171.html.

Bug#1070983: supertuxkart: symbol lookup error: undefined symbol

[Reiner Herrmann]

Hi Bernd,

thanks for your report.
This looks like #1029939 (https://bugs.debian.org/1029939) in shaderc.

supertuxkart 1.4+dfsg-4, which uses the shaderc package instead of a
bundled copy, has migrated to testing before shaderc 2023.8-1, which
fixes the linking problem.
Can you please try upgrading shaderc to 2023.8-1 (from unstable)?

Thanks and kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#1071014: python-neutron-lib: please remove the extraneous python3-mock dependency

[Alexandre Detiste]

Source: python-neutron-lib
Version: 3.11.0-2
Severity: normal

Dear Maintainers,

This package has switched to "unittest.mock" from the standard library.

Greetings

debian/control: python3-mock ,
neutron_lib/fixture.py:from unittest import mock
neutron_lib/tests/_base.py:from unittest import mock
neutron_lib/tests/unit/api/test_conversions.py:from unittest import mock
...

Bug#1065221: O: py7zr -- pure Python 7-zip library

[yokota]

Hello Étienne,

> py7zr was ready for upload to Debian.

py7zr 0.21 is now split-out all architecture-dependent binary module
to external python modules.
And py7zr target architecture is changed to "all".
I think we send RM request to Debian release team to drop old
architecture-dependent packages.

--
YOKOTA Hiroshi

Bug#1071013: neutron-vpnaas-dashboard: please drop the extraneous python3-mock dependency

[Alexandre Detiste]

Source: neutron-vpnaas-dashboard
Version: 10.0.0-1
Severity: normal

mock is not required at all.

Greetings

tchet@quieter:/tmp/neutron-vpnaas-dashboard$ grep mock -r | grep -e debian -e 
import
debian/control: python3-mock,
tchet@quieter:/tmp/neutron-vpnaas-dashboard$ 

Bug#1071012: neutron-dynamic-routing: please drop the build-dependency on python3-mock

[Alexandre Detiste]

Source: neutron-dynamic-routing
Version: 2:24.0.0-2
Severity: normal

Dear Maintainer,

This package has already switched to "unittest.mock"

Greetings

tchet@quieter:/tmp/neutron-dynamic-routing$ grep mock -r | grep -e debian -e 
import
debian/control: python3-mock,
debian/control: python3-requests-mock,
neutron_dynamic_routing/tests/unit/api/rpc/agentnotifiers/test_bgp_dr_rpc_agent_api.py:from
 unittest import mock
neutron_dynamic_routing/tests/unit/api/rpc/handlers/test_bgp_speaker_rpc.py:from
 unittest import mock
neutron_dynamic_routing/tests/unit/db/test_bgp_db.py:from unittest import mock
neutron_dynamic_routing/tests/unit/services/bgp/agent/test_bgp_dragent.py:from 
unittest import mock
neutron_dynamic_routing/tests/unit/services/bgp/driver/os_ken/test_driver.py:from
 unittest import mock
neutron_dynamic_routing/tests/unit/services/bgp/scheduler/test_bgp_dragent_scheduler.py:from
 unittest import mock
neutron_dynamic_routing/tests/unit/services/bgp/test_bgp_plugin.py:from 
unittest import mock
tchet@quieter:/tmp/neutron-dynamic-routing$

Bug#1071011: ITP: golang-gopkg-godo.v2 -- task runner and file watcher (library)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org, 
vil...@debian.org

* Package name: golang-gopkg-godo.v2
  Version : 2.0.9
  Upstream Contact: Mario L. Gutierrez 
* URL : https://gopkg.in/godo.v2
* License : Expat
  Programming Lang: Go
  Description : task runner and file watcher (library)

  godo is a task runner and file watcher
  for golang in the spirit of rake, gulp.

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian,

I've intentionally snipped much of your reply as I think we two agree on
many of the aspects.

On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote:
> > 1. API expectation of *-$arch-cross packages
> 
> I asked exactly that in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55

I guess the best description is to be found in man dpkg-cross
"Conversion process" and even that isn't entirely helpful.

> > 4. cross-toolchain-base being bd-uninstallable
> 
> Which directly correlates to undocumented Build-Conflicts in the
> package.  They neither show up in the changelog or the commit logs.
> 
> >I don't exactly understand why it declares them, but I guess that
> >having a different set of kernel headers available in
> >/usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build
> >and potentially cause misbuilds. cross-toolchain-base builds these
> >packages and it also uses them during build of glibc.
> 
> So this reason is now gone.  linux-source-* and linux-libc-dev are
> similar enough in almost all cases.

It's not gone as non-virtual linux-libc-dev-$arch-cross packages are
still built from c-t-b. If c-t-b were to stop building them, I'd concur.

> > 6. Cross bootstrap cannot tell whether linux-libc-dev supports an
> >architecture
> 
> Even in the past it could not.  It could try to build the linux package
> to see if it gets a working linux-libc-dev.  Or have other code to hack
> around, like changing the config.

In the past, there was no need to tell. It would always build
linux-libc-dev. Now that linux-libc-dev works for many but not all
architectures, there is a need to tell.

> Actually linux-libc-dev-$arch-cross is uncommunicated and uncoordinated
> duplication of exactly the same content as linux-libc-dev.

It is news to me that it is uncommunicated and uncoordinated, but that
very accurately matches the rest of the disagreement. Yes, it is
duplication.

> 9. linux-libc-dev-*-cross provides incompatible headers to
>build-essential
> 
>Both linux-libc-dev and linux-libc-dev-*-cross provide the linux/*
>includes that are used by the compiler but of different versions.  It
>is undefined if those can work with the (always older) asm/* provided
>by linux-libc-dev-*-cross.

Yes, this is a problem. It kinda is the same problem that we have with
libc6-dev vs libc6-dev-$arch-cross and is why libc6-dev declares
versioned breaks for libc6-dev-$arch-cross.

> > 3. cross-toolchain-base could build a linux-libc-dev-cross package
> >that Provides the earlier -$arch-cross packages and contains a
> >similar symlink farm to linux-libc-dev.
> 
> This requires coordination of the versions and strict enough
> dependencies.  So linux-libc-dev-cross would need to come out of the
> same source as linux-libc-dev.

Technically speaking, a linux-libc-dev-cross package could be built from
c-t-b. It would just inherit all the other problems including your
problem 9 from the previous approach and only address the space aspect.
I listed it more for completeness sake than suggesting we actually go
for this.

> > 4. cross-toolchain-base could drop its Build-Conflicts. This may cause
> >further problems though.
> >Patch: https://bugs.debian.org/1067370#17
> 
> The build will now see multiple architectures of headers.  So it needs
> to handle this both for native (where build-conflicts can't be used
> anyway) and cross the same.

I don't understand what you are trying to say here. c-t-b only builds
Arch:all packages, so the terms native and cross appear to not apply.
Then again we also don't know what "further problems" are. I hope
Matthias can shed some light here.

> On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote:
> > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common
> >arch:all m-a:foreign and the symlink farms could be kept in
> >linux-libc-dev:any m-a:same retaining the size reduction.
> 
> This would not actually work.  linux-libc-dev-common would only contain
> known architectures.  So the current "change config, build
> linux-libc-dev" will not longer work as well.  This package would then
> depend on a linux-libc-dev-common without the headers for this
> architecture.

I agree that it is not as simple as I pictured it. I was imagining that
a m-a:same linux-libc-dev could simply contain all the
architecture-dependent stuff. For many architectures that would
practically work initially, but there is no bijective mapping between
kernel architecture names and Debian architecture names, so for
directories like /usr/lib/linux/uapi/arm is is unclear whether it should
be part of linux-libc-dev:armel or linux-libc-dev:armhf or
linux-libc-dev-common.  Even for /usr/lib/linux/uapi/arm64, it is not
clear whether that should be part of linux-libc-dev:arm64 or
linux-libc-dev:musl-linux-arm64 or linux-libc-dev-common. You are
implicitly resolving this to linux-libc-dev-common and conclude that

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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2024-05-12 00:32:42)
> On Sat, 13 Apr 2024 14:50:05 +0200 Francesco Poli wrote:
> > On Fri, 12 Apr 2024 19:57:23 +0200 Johannes Schauer Marin Rodrigues wrote:
> > > Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51)
> > > > Why does sbuild-qemu insist that piuparts be installed on the *host*
> > > > system?
> > > Because it needs to be installed on the host. In the same way as
> > > autopkgtest needs to be on the host. What can sbuild improve?
> > My point is that sbuild{,-qemu} should install piuparts inside the build
> > environment (chroot or VM guest system) and run it from within the build
> > environment, if this is possible.
> If this is possible for piuparts, could you please explain why sbuild-qemu
> does not do so?
> 
> Otherwise, if this is not possible, could please explain why?

it is possible if somebody writes the code for it.

If you want me to write the code for it, you'd first need to convince me that
it is a good idea to run piuparts inside the build environment as it is done
with lintian.

> > Does sbuild{,-qemu} do so for lintian?
> I checked: sbuild-qemu (temporarily) installs lintian inside the build
> environment and runs it from within the build environment.

Correct.

> I think this is the best strategy, especially for lintian, as I have
> previously explained.

Please refresh my memory: where did you explain why installing piuparts inside
the build environment would be the best strategy?

> That reinforces my opinion that the same strategy should probably be followed
> for piuparts, as well...

What is it that reinforces your opinion? If it is the fact that it is done for
Lintian, I do not see the connection. Why would it be a good idea to do this
for piuparts if it is done for lintian?

> Anyway, I am having issues in running piuparts, even after installing it on
> the host.
> 
> I tried to run
> 
>   $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm
> 
> with the following configuration file:
> 
>   $ cat ~/.sbuildrc 
>   $source_only_changes = 1;
>   $autopkgtest_require_success = 1;
>   $lintian_require_success = 0;
>   $piuparts_require_success = 1;
>   $run_autopkgtest = 1;
>   $run_lintian = 1;
>   $run_piuparts = 1;
>   $build_dir = "$HOME/.cache/sbuild/build";
>   
>   # don't remove this, Perl needs it:
>   1;
> 
> It builds the package successfully, but, once it reaches the piuparts
> step, sudo asks for my (host system) regular user's password.
> My understanding is that it should not need to use sudo, since it should
> use the QEMU virtual machine image (where it has root access).
> Is that right? Or am I misunderstanding something?

This is not a functionality that piuparts has at the moment.

> The same thing happens at the autopkgtest step, where, again, sudo asks for
> my regular user's password. Once again, this should not be needed:
> autopkgtest should use the QEMU virtual machine as a testbed.  At least, when
> I manually run autopkgtest, I can use the QEMU virtual machine and no
> password is asked for.
> 
> I tried to modify the configuration file:
> 
>   $ cat ~/.sbuildrc
>   $source_only_changes = 1;
>   $run_lintian = 1;
>   $lintian_require_success = 0;
>   $run_piuparts = 1;
>   $piuparts_root_args = '';
>   $piuparts_require_success = 1;
>   $run_autopkgtest = 1;
>   $autopkgtest_root_args = '';
>   $autopkgtest_require_success = 1;
>   $build_dir = "$HOME/.cache/sbuild/build";
>   
>   # don't remove this, Perl needs it:
>   1;
> 
> It no longer asks for passwords, but fails to run piuparts:
> 
>   piuparts
>   
> 
>   You need to be root to use piuparts.
> 
>   E: Piuparts run failed.
> 
> And it also fails to run autopkgtest:
> 
>   autopkgtest
>   ---
>   
>   autopkgtest [19:56:04]: starting date and time: 2024-05-11 19:56:04+0200
>   [...]
>   autopkgtest [19:56:05]: test unit_test: preparing testbed
>   autopkgtest [19:56:05]: ERROR: "sh -ec
> type apt-ftparchive >/dev/null 2>&1 || DEBIAN_FRONTEND=noninteractive 
> apt-get install -y apt-utils 2>&1
> (cd /tmp/autopkgtest.jrHchc/binaries; apt-ftparchive packages . > 
> Packages; apt-ftparchive release . > Release)
> printf 'Package: *\nPin: origin ""\nPin-Priority: 1002\n' > 
> /etc/apt/preferences.d/90autopkgtest
> echo "deb [ trusted=yes ] file:///tmp/autopkgtest.jrHchc/binaries /" 
> >/etc/apt/sources.list.d/autopkgtest.list
> if [ "x`ls /var/lib/dpkg/updates`" != x ]; then
>   echo >&2 "/var/lib/dpkg/updates contains some files, aargh"; exit 1
> fi
> apt-get --quiet --no-list-cleanup -o 
> Dir::Etc::sourcelist=/etc/apt/sources.list.d/autopkgtest.list -o 
> Dir::Etc::sourceparts=/dev/null update 2>&1
> cp /var/lib/dpkg/status /tmp/autopkgtest.jrHchc/1-apt-update.out
> " failed with stderr "sh: 4: cannot create 
> /etc/apt/preferences.d/90autopkgtest: Permission denied
>   "
>   autopkgtest [19:56:05]: Binaries: resetting testbed apt configuration
>   Reading package lists...
>   E: Could not open lock 

Bug#1032443: webkit2gtk: Consider building with clang instead to speed up build time

[Alberto Garcia]

On Mon, Mar 06, 2023 at 04:07:36PM -0500, Jeremy Bícha wrote:

> I heard that the time to build webkit2gtk can be noticeably reduced
> if we build it with clang.

I'm going to start using clang for the 2.45.x branch since it's the
recommended compiler to build Skia:

   https://skia.org/docs/user/build/#supported-and-preferred-compilers

The problem is that it doesn't work in some architectures, this is
s390x:

Source/WTF/wtf/simde/arm/neon.h:8808:11: error: _Float16 is not supported on 
this target
  typedef _Float16 simde_float16;
  ^
Source/WTF/wtf/simde/arm/neon.h:34339:47: error: _Float16 is not supported on 
this target
return simde_vceq_f16(a, simde_vdup_n_f16(SIMDE_FLOAT16_VALUE(0.0)));
  ^
Source/WTF/wtf/simde/arm/neon.h:8975:38: note: expanded from macro 
'SIMDE_FLOAT16_VALUE'
  #define SIMDE_FLOAT16_VALUE(value) SIMDE_FLOAT16_C(value)
 ^
Source/WTF/wtf/simde/arm/neon.h:8813:55: note: expanded from macro 
'SIMDE_FLOAT16_C'
#define SIMDE_FLOAT16_C(value) HEDLEY_STATIC_CAST(_Float16, (value))
  ^

So I guess I'll start with amd64

Berto

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Santiago Vila]

El 7/5/24 a las 19:43, Uecker, Martin escribió:

Yes, if you do not mind to do the work, please update bullseye.
That would be much appreciated.


Hi. The uploads for bart and bart-cuda have been accepted for 
bullseye-proposed-updates.
So I pushed the pending changes to salsa.

One thing I didn't mention before: I noticed that both packages share
the same git repo, so I understand that only the releases of "bart"
can have git tags on such repository.

Maybe we could use a special tag format for the contrib branches, but I guess
that it does not worth the effort.

Thanks.

Bug#1071008: libx52pro0: installs udev rules twice to /usr and /

[Helmut Grohne]

Package: libx52pro0
Version: 0.1.1-3
Severity: serious
Justification: policy 10.1
Tags: patch
X-Debbugs-Cc: Petter Reinholdtsen 

Hi,

since the last upload, libx52pro0 contains both
/lib/udev/rules.d/99-x52pro.rules and
/usr/lib/udev/rules.d/99-x52pro.rule. Doing so violates Debian policy
section 10.1. The former is installed via the upstream build system
combined with dh_install and debian/libx52pro0.install while the latter
is installed via debian/*.udev with dh_installudev. Given DEP17, the
latter is the desired location. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru x52pro-0.1.1/debian/changelog x52pro-0.1.1/debian/changelog
--- x52pro-0.1.1/debian/changelog   2024-05-12 10:39:38.0 +0200
+++ x52pro-0.1.1/debian/changelog   2024-05-12 22:59:37.0 +0200
@@ -1,3 +1,9 @@
+x52pro (0.1.1-4) UNRELEASED; urgency=medium
+
+  * Install udev rules only once. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2024 22:59:37 +0200
+
 x52pro (0.1.1-3) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru x52pro-0.1.1/debian/libx52pro0.install 
x52pro-0.1.1/debian/libx52pro0.install
--- x52pro-0.1.1/debian/libx52pro0.install  2024-05-12 10:14:01.0 
+0200
+++ x52pro-0.1.1/debian/libx52pro0.install  2024-05-12 22:59:36.0 
+0200
@@ -1,4 +1,3 @@
-lib/udev/rules.d
 usr/bin/x52output
 usr/lib/lib*.so.*
 usr/share/man
diff --minimal -Nru x52pro-0.1.1/debian/not-installed 
x52pro-0.1.1/debian/not-installed
--- x52pro-0.1.1/debian/not-installed   1970-01-01 01:00:00.0 +0100
+++ x52pro-0.1.1/debian/not-installed   2024-05-12 22:59:37.0 +0200
@@ -0,0 +1,2 @@
+# Installed via debian/*.udev symbolic link
+lib/udev/rules.d

Bug#1071010: pcp has an undeclared file conflict on /usr/bin/pmcheck

[Helmut Grohne]

Package: pcp
Version: 6.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pmtools

pcp has an undeclared file conflict. This may result in an unpack error
from dpkg.

The file /usr/bin/pmcheck is contained in the packages
 * pcp/6.2.1-1 as present in unstable
 * pmtools
   * 2.2.0-2 as present in bullseye
   * 2.2.0-3 as present in bookworm|trixie|unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071009: libpoppler-cpp0t64 has an undeclared file conflict

[Helmut Grohne]

Package: libpoppler-cpp0t64
Version: 24.02.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libpoppler-cpp0v5

libpoppler-cpp0t64 has an undeclared file conflict. This may result in
an unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
 * /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.11.0
are contained in the packages
 * libpoppler-cpp0t64/24.02.0-3 as present in unstable
 * libpoppler-cpp0v5/22.12.0-2+b1 as present in bookworm

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py

[Helmut Grohne]

Package: sherlock
Version: 0.14.3+git20240511.b83f5be-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pycrc

sherlock has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/lib/python3/dist-packages/__init__.py is contained in the
packages
 * pycrc/0.10.0-2 as present in trixie|unstable
 * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071006: conky-all, conky-cli and conky-std have an undeclared file conflict

[Helmut Grohne]

Package: conky-cli,conky-std,conky-all
Version: 1.21.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + vc-dev

conky-all, conky-cli and conky-std have an undeclared file conflict.
This may result in an unpack error from dpkg.

The files
 * /usr/lib/cmake/Vc/AddCompilerFlag.cmake
 * /usr/lib/cmake/Vc/CheckCCompilerFlag.cmake
 * /usr/lib/cmake/Vc/CheckCXXCompilerFlag.cmake
 * /usr/lib/cmake/Vc/FindVc.cmake
 * /usr/lib/cmake/Vc/OptimizeForArchitecture.cmake
 * /usr/lib/cmake/Vc/UserWarning.cmake
 * /usr/lib/cmake/Vc/VcConfig.cmake
 * /usr/lib/cmake/Vc/VcConfigVersion.cmake
 * /usr/lib/cmake/Vc/VcMacros.cmake
 * /usr/lib/cmake/Vc/VcTargets.cmake
 * /usr/lib/libVc.a
are contained in the packages
 * conky-all/1.21.0-1 as present in unstable
 * conky-cli/1.21.0-1 as present in unstable
 * conky-std/1.21.0-1 as present in unstable
 * vc-dev
   * 1.4.3-2 as present in bookworm
   * 1.4.4-1 as present in trixie|unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071005: rust-llvm has an undeclared file conflict

[Helmut Grohne]

Package: rust-llvm
Version: 1.71.1+dfsg1-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + rustc rustc-mozilla rustc-web

rust-llvm has an undeclared file conflict. This may result in an unpack
error from dpkg.

The files
 * /usr/bin/rust-clang
 * /usr/bin/rust-lld
 * /usr/bin/rust-llvm-dwp
 * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld
 * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld64
are contained in the packages
 * rust-llvm/1.71.1+dfsg1-1~exp1 as present in experimental
 * rustc
   * 1.63.0+dfsg1-2 as present in bookworm
   * 1.70.0+dfsg2-1 as present in trixie|unstable
 * rustc-mozilla/1.63.0+dfsg1-2~deb11u1 as present in bullseye
 * rustc-web/1.70.0+dfsg1-7~deb12u2 as present in bookworm-proposed-updates

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071000: sbuild-qemu: runs lintian on .changes file with Distribution != changelog target and lintian complains

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (wintermute) (2024-05-12 21:06:24)
> I am still trying to set up sbuild-qemu to build (and check/test) Debian
> packages.
> 
> After creating the virtual machine image:
> 
>   $ mkdir -p ~/.cache/sbuild/build
>   $ cd /dev/shm
>   $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
> --size=25G --boot=efi sid unstable-autopkgtest-amd64.img
>   $ mv -i unstable-autopkgtest-amd64.img ~/.cache/sbuild/
> 
> I prepared the following configuration file:
> 
>   $ cat ~/.sbuildrc 
>   $source_only_changes = 1;
>   $run_lintian = 1;
>   $lintian_require_success = 0;
>   $run_piuparts = 1;
>   $piuparts_root_args = '';
>   $piuparts_require_success = 1;
>   $run_autopkgtest = 1;
>   $autopkgtest_root_args = '';
>   $autopkgtest_require_success = 1;
>   $build_dir = "$HOME/.cache/sbuild/build";
>   
>   # don't remove this, Perl needs it:
>   1;
> 
> I can update the virtual machine:
> 
>   $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img
> 
> and I can build a package from within the unpacked source tree:
> 
>   $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm

cool!

> However, when I do so, I am not necessarily planning to upload the
> Debian package to the Debian archive: it could be still in development
> (not yet ready for an upload) and I just want to check that it can be
> built and perform the usual checks on it, namely lintian (first of all!),
> followed by piuparts and autopkgtest.
> If this is the case, my latest changelog entry will read 'UNRELEASED' in the
> distribution field, but, at the same time, I want to build the package
> with the 'unstable-autopkgtest-amd64.img' VM image (to build it for
> unstable).

Yes, doing that should be possible.

> What happens here? It turns out that sbuild-qemu modifies the Distribution
> field in the .changes file and sets it to 'unstable', despiting reading
> 'UNRELEASED' in the latest changelog entry.
> Hence lintian complains with an error:
> 
>   [...]
>   Running lintian...
>   E: $PKG_NAME changes: unreleased-changes
>   W: $PKG_NAME: changelog-distribution-does-not-match-changes-file unreleased 
> != unstable [usr/share/doc/$PKG_NAME/changelog.gz:1]
>   
>   E: Lintian run failed (runtime error)
>   [...]
> 
> How can I fix this issue?
> Shouldn't it work out of the box?

But it does. Your d/changelog has UNRELEASED as the distribution and Lintian
classifies that as an error.

> I found bug report [#934721], which, however, seems to advocate that
> this is the right behavior ?!? Or am I misinterpreting it?
> 
> [#934721]: 
> 
> How can I run lintian on a still-in-developed UNRELEASED package (with
> sbuild-qemu)?

You just did. And it reports a failure because in its current state, your
package is not ready to be uploaded.

> Please note that my current setup with pbuilder does not have this issue:
> pdebuild generates a .changes file with 'Distribution: UNRELEASED'
> and with the latest changelog entry correctly quoted (with 'UNRELEASED'
> after the version number parenthesis), and hence lintian is happy...

Wait... how is Lintian happy with UNRELEASED as the changelog entry?

> It has to work out of the box with sbuild-qemu, as well!
> 
> Please fix the issue and/or explain what's wrong.
> 
> Thanks for your time and patience.

The only difference between sbuild and pbuilder should be this:

>   W: $PKG_NAME: changelog-distribution-does-not-match-changes-file unreleased 
> != unstable [usr/share/doc/$PKG_NAME/changelog.gz:1]

The reason for that difference is, that sbuild-qemu calls sbuild with the -d
option and that overwrites the distribution field. Christian, why does
sbuild-qemu use the -d option?

But this lintian error should also be present with pbuilder:

>   E: $PKG_NAME changes: unreleased-changes

Can you clarify?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1070881: reportbug: Provide an option to skip loading configuration files

[Xiyue Deng]

Nis Martensen  writes:

> On 11.05.2024 08.23, Xiyue Deng wrote:
>> I'd like to propose adding an option to skip loading configuration files
>> (/etc/reportbug.conf and ~/.reportbugrc).  The use case is for external
>> programs that runs reportbug (e.g. debian-bug in elpa-debian-el) which
>> provides its own command line switches and have an assumption on the
>> output.  When a user set some custom options, notably CC related ones,
>> it may interfere with how X-Debbugs-Cc is handled and broke some of the
>> assumptions of external tools (see https://bugs.debian.org/1032662).
>
> Thanks for the report. Did you intend to link to a different bug as your
> example? The one you cite does not seem to be related to reportbug.

Ah, indeed.  I was trying to refer to https://bugs.debian.org/1069908.
Thanks for the correction!

-- 
Xiyue Deng

Bug#1070998: bookworm-pu: package fossil/2.24-5~deb11u1

[Barak A. Pearlmutter]

Thanks!
I guess preparing these is pretty straightforward.
Would like to think my efforts to keep debian/rules etc clean and tidy
made this work so easily.

Given that the patch is nothing but a changelog entry, I'm assuming
it's not really worth making a branch on fossil.
" * Backport to bookworm (no changes required)"?

Cheers,

--Barak.

Bug#1070881: reportbug: Provide an option to skip loading configuration files

[Nis Martensen]

On 11.05.2024 08.23, Xiyue Deng wrote:
> I'd like to propose adding an option to skip loading configuration files
> (/etc/reportbug.conf and ~/.reportbugrc).  The use case is for external
> programs that runs reportbug (e.g. debian-bug in elpa-debian-el) which
> provides its own command line switches and have an assumption on the
> output.  When a user set some custom options, notably CC related ones,
> it may interfere with how X-Debbugs-Cc is handled and broke some of the
> assumptions of external tools (see https://bugs.debian.org/1032662).

Thanks for the report. Did you intend to link to a different bug as your
example? The one you cite does not seem to be related to reportbug.

Bug#1071004: openfpgaloader: Add Appstream metainfo announcing HW support

[Petter Reinholdtsen]

Package: openfpgaloader
Version: 0.12.0-1
Tags: patch

Here is a patch for openfpgaloader to add Appstream metainfo XML
announcing the hardware handled by this package.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the USB
IDs are discovered.

diff --git a/debian/com.github.trabucayre.openFPGALoader.metainfo.xml 
b/debian/com.github.trabucayre.openFPGALoader.metainfo.xml
new file mode 100644
index 000..03b881c
--- /dev/null
+++ b/debian/com.github.trabucayre.openFPGALoader.metainfo.xml
@@ -0,0 +1,42 @@
+
+
+  com.github.trabucayre.openFPGALoader
+  MIT
+  openfpgaloader
+  Universal utility for programming FPGAs
+  
+FPGAs are software-programmable reconfigurable circuits that
+when may implement arbitrary logics, be it to interface to other
+hardware as some sort of glue logic or to even outsource
+computations from your CPU as an accelerator. Even small FPGAs are
+today sufficiently capable to simulate a CPU.
+
+This package knows how to bring the firmware that is built on a
+regular computer, e.g., with yosys and assorted tools, to the FPGA
+board, such that such a bitstream is then executed.
+
+OpenFPGALoader is compatible with many boards, cables and FPGA
+from major manufacturers (Xilinx, Altera/Intel, Lattice, Gowin,
+Efinix, Anlogic, Cologne Chip).
+  
+  
+usb:v0403%6001d*
+usb:v0403%6010d*
+usb:v0403%6011d*
+usb:v0403%6014d*
+usb:v0403%6015d*
+usb:v0547%1002d*
+usb:v09FB%6001d*
+usb:v09FB%6002d*
+usb:v09FB%6003d*
+usb:v09FB%6810d*
+usb:v09FB%6010d*
+usb:v1209%C0CAd*
+usb:v1366%0105d*
+usb:v1FC9%0090d*
+usb:v0D28%0204d*
+usb:v1D50%6146d*
+usb:v1209%3442d*
+usb:v1A86%55DDd*
+  
+
diff --git a/debian/copyright b/debian/copyright
index df02009..c79b1e2 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -62,6 +62,27 @@ Files: debian/*
 Copyright: 2022 Steffen Moeller 
 License: Apache-2.0
 
+Files: debian/com.github.trabucayre.openFPGALoader.metainfo.xml
+Copyright: 2024 Petter Reinholdtsen 
+License: MIT
+ Permission is hereby granted, free of charge, to any person obtaining a copy
+ of this software and associated documentation files (the "Software"), to deal
+ in the Software without restriction, including without limitation the rights
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ copies of the Software, and to permit persons to whom the Software is
+ furnished to do so, subject to the following conditions:
+ .
+ The above copyright notice and this permission notice shall be included in all
+ copies or substantial portions of the Software.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+
 License: Apache-2.0
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
diff --git a/debian/openfpgaloader.install b/debian/openfpgaloader.install
index ca936dc..181850a 100644
--- a/debian/openfpgaloader.install
+++ b/debian/openfpgaloader.install
@@ -1 +1,2 @@
 99-openfpgaloader.rules lib/udev/rules.d
+debian/com.github.trabucayre.openFPGALoader.metainfo.xml usr/share/metainfo

-- 
Happy hacking
Petter Reinholdtsen

Bug#1059808: [Debian-ha-maintainers] Bug#1059808: ocfs2-tools: isolation-machine autopkgtest fails: Internal logic failure while mounting /dev/loop0 on /mnt

[Valentin Vidic]

On Tue, Mar 12, 2024 at 07:54:52PM +0100, Valentin Vidic wrote:
> On Mon, Jan 01, 2024 at 07:57:38PM +0100, Paul Gevers wrote:
> >  47s === mount ===
> >  47s mount.ocfs2: Internal logic failure while mounting /dev/loop0 on /mnt.
> > Check 'dmesg' for more information on this error 22.
> >  47s umount: /mnt: not mounted.
> 
> Thanks for the report, I'm seeing the same problem on a local KVM
> instance. The test still works with older kernel versions and show be
> fixed for new kernels once they have these two patches:
> 
> Alexander Aring [PATCH 1/2] dlm: fix user space lkb refcounting
> Alexander Aring [PATCH 2/2] dlm: fix off-by-one waiters refcount handling 
>  

The problem should be resolved now with a new kernel version: Linux
6.7.12-amd64 works correctly for me again.

-- 
Valentin

Bug#1067946: dietlibc: Includes non-free Sun RPC

[Thorsten Glaser]

Bastian Germann dixit:

>> Do you have a link?
>
> No. It is not a public address.

Ah, yes, that is unfortunate. I used to be subscribed and have no
idea why I’m not, but I re-subscribed (though have not yet seen any
traffic in the last couple of days).

>> What did upstream say?
>
> No upstream response up to now.

OK.

I just asked in #d-ftp whether we can get an official statement
on whether “we received this as part of dietlibc (a product or
program developed by user” (i.e. Fefe) under GPL will suffice
(which I personally consider true).

If they say yes, I’ll fix that the block is missing from d/copyright
and have a look at #1069365 (unless Christian prefers to).

If they say no, we’ll have to inform reverse dependencies of this,
ask upstream again with some more urgency, and prepare for removal
of this meanwhile (I don’t think we can just swap out such much code
in the packaging)… or possibly excise the sunrpc code and hope this
doesn’t break any users.

Until then… no idea. Wait and drink tea, or something?

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Bug#722344: eog: saving multiple rotations failes, only last is saved

[Lee Garrett]

Package: eog
Version: 43.2-1
Followup-For: Bug #722344
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

this bug is still present in bookworm. The steps to reproduce are trivial:

1) view several (> 2) jpg in a folder
2) rotate the first picture by clicking the rotate right button at the bottom of
the pic
3) repeat the last step for all pictures
4) close eog, and select save images before closing
5) Notice that only the last picture is actually rotated, all the others are
untouched.

It would be nice to get this fixed, as it's easy for people to waste time on
fixing the rotation only to later find out that it doesn't actually persist.

Greets,
Lee

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

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

Versions of packages eog depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-gtk-3.0   3.24.38-2~deb12u1
ii  gir1.2-peas-1.0  1.34.0-1+b1
ii  gsettings-desktop-schemas43.0-1
ii  libc62.36-9+deb12u7
ii  libcairo21.16.0-7
ii  libexempi8   2.6.3-1
ii  libexif120.6.24-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libgnome-desktop-3-2043.2-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libhandy-1-0 1.8.1-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libpeas-1.0-01.34.0-1+b1
ii  librsvg2-2   2.54.7+dfsg-1~deb12u1
ii  librsvg2-common  2.54.7+dfsg-1~deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  shared-mime-info 2.2-1
ii  webp-pixbuf-loader   0.2.1-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages eog recommends:
ii  yelp  42.2-1

Versions of packages eog suggests:
pn  eog-plugins  

-- no debconf information

Bug#1070158: distro-info-data 0.51+deb11u6 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1070158 = 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: distro-info-data
Version: 0.51+deb11u6

Explanation: declare intentions for bulllseye/bookworm; fix past data; add 
Ubuntu 24.10

Bug#1070137: bullseye-pu: package cloud-init/22.4.2-1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Tue, Apr 30, 2024 at 11:21:01AM -0700, Noah Meyerhans wrote:
> There are pros and cons to each option.  Given bullseye's age and
> cloud-init's blast radius (a regression could potentially disrupt the
> provisioning process of cloud VMs, which is particularly disruptive in
> such environments) I lean toward option (2) above, as it minimizes the
> changes.  The obvious drawback is that we now have two versions of
> cloud-init in the bullseye repositories, which was not the case
> previously.  The cloud team is committed to supporting this situation
> for the duration of the bullseye LTS lifetime.

I think I lean towards option 2 as well. I assume the versioning is
calendar-based not semantic, so it's hard to know how disruptive 20.x ->
22.x would be, and meaningful testing across all the platforms it could be
deployed on is unrealistic.

Can you attach proposed debian/control and debian/changelog files please?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1070860: musescore3: CVE-2023-44428

[Thorsten Glaser]

Moritz Mühlenhoff dixit:

>Am Fri, May 10, 2024 at 06:39:20PM + schrieb Thorsten Glaser:
>> This is a bit like the limited security support for binutils,
>> I suppose. Could/should we document that in the same places?
>
>Sure thing, this sounds similar to what was done for Lilypond,

Ah, okay.

>best to simply ship a similar README.Debian.security within

I was thinking a README.Debian with:

-snip-
Note on possible security issues from untrusted input:

Upstream has never considered it on scope that the software
cannot “crash” on incorrect input, unfortunately. There is
also no security or other support for this version branch
from upstream. Please consider this and don’t expose the
software to untrusted, possibly incorrect, input files to
avoid triggering DoS or possible security problems in its
parsers without suitable confining measures. This is even
more true for import filters than for the native formats’
parsers (and includes the MusicXML import).

Mu͒seScore Studio was designed to operate as an unconnected
desktop program and not as a remotely accessible service,
so please take care.
-snap-

I’ll accept suggestions to improve, of course; I think I’ll
add the magic word “sandboxing” to the last paragraph?

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#1069880: bullseye-pu: package cpu/1.4.3-14~deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, Apr 26, 2024 at 12:01:33PM +0200, Andreas Beckmann wrote:
> The last QA upload four years ago fixed a FTBFS (multiple definitions of
> a global variable) by replacing that variable with an extern declaration
> and zero definitions. This didn't result in a linker error (missing
> symbol) because it happens in a plugin library and thus is only detected
> at runtime when the plugin gets loaded (i.e. always).
> So let's ship the plugin with *one* definition of the global variable
> ;-)

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#625895: logcheck-database: /etc/logcheck/ignore.d.server/dovecot rule misses unusual Message-Id

[Richard Lewis]

On Fri, 06 May 2011 11:32:03 -0700 Gerald Turner  wrote:

> Hello, I've seen some legitimate mails with unusual Message-Id headers
> that cause logchecks dovecot delivery rule to be bypassed.
>
> Example: … sieve: msgid=<20110422T2108.GA.(stdi.s...@fsing.rootsland.net>: 
> stored mail into mailbox 'Mailing Lists/Debian/debian-devel'

It's a shame no-one replied since 2011.

That doesnt seem to be a valid msgid, so not sure logcheck should be
ignoring it by default. Obviously you can edit / make your own rules
to do so.
So not sure there is anything for debian to do in this one. Perhaps we
should close the bug?

Bug#1069943: bullseye-pu: package emacs/27.1+1-3.1+deb11u3

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Sat, Apr 27, 2024 at 12:34:45PM +0100, Sean Whitton wrote:
> This update also has the effect of rolling in changes already in
> oldstable-security earlier than the usual point release copy, as
> oldstable-security has deb11u2, while oldstable still has deb11u1.

The security release hasn't been accepted into bullseye yet because there
were reports of it being broken on mips64el. There was a bug but I'm afraid
I don't have a reference to it.

Do you know if your version solves the issue? If it does I can accept the
security first for you to rebase against if that helps with the diffs.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1070158: bullseye-pu: package distro-info-data/0.51+deb11u6

[Jonathan Wiltshire]

On Sun, May 12, 2024 at 11:55:45AM +, stefa...@debian.org wrote:
> Hi Jonathan (2024.05.12_10:56:13_+)
> > Control: tag -1 confirmed
> > 
> > On Tue, Apr 30, 2024 at 08:58:52PM -0400, Stefano Rivera wrote:
> > > 1. bullseye and bookworm LTS & ELTS.
> > > 2. Ubuntu 24.10 Oracular Oriole
> > 
> > Please go ahead, but if you'd prefer to wait until the final date for
> > bullseye is determined feel free to wait and amend.
> 
> It was uploaded when I filed the bug.
 
So it was, sorry.

> I'd say accept it now, and if we miss getting bullseye's final EoL in,
> we can do it via LTS.

Ok.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1071003: src:audit: fails to migrate to testing for too long: piuparts regression

[Paul Gevers]

Source: audit
Version: 1:3.1.2-2
Severity: serious
Control: close -1 1:3.1.2-2.1
X-Debbugs-CC: vor...@debian.org
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1070327

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:audit has been trying to migrate for 74 
days [2]. Hence, I am filing this bug. The version in unstable has 
postrm issues as reported in 1070327.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070761: bart-cuda 0.6.00-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1070761 = 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: bart-cuda
Version: 0.6.00-1+deb11u1

Explanation: fix build test failures by relaxing a floating-point comparison

Bug#1070723: bart 0.6.00-3+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1070723 = 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: bart
Version: 0.6.00-3+deb11u1

Explanation: fix build test failures by relaxing a floating-point comparison

Bug#1071002: ruby-mysql2: FTBFS on ppc64el: test suite hangs

[Lucas Nussbaum]

Package: ruby-mysql2
Version: 0.5.5-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi,

https://buildd.debian.org/status/fetch.php?pkg=ruby-mysql2=ppc64el=0.5.5-2=1715331286=0

It hangs with:

+ ruby3.1 -S rspec
E: Build killed with signal TERM after 150 minutes of inactivity

Build finished at 2024-05-10T08:54:25Z

It fails identically on powerpc and ppc64, so at least there's some
logic.

It built fine rather recently (2024-03-17) but that was a different
upstream version.

Lucas

Bug#491127: logcheck: please consider an option which will always check the entire log file

[Richard Lewis]

On Sun, 12 May 2024 at 19:57, Marc Haber  wrote:
>
> On Sun, May 12, 2024 at 06:54:59PM +0100, R Lewis wrote:
> > On Wed, 16 Jul 2008 23:15:51 +0200 Marc Haber
> >  wrote:
> >
> > > It would help with debugging to have an option that causes logcheck to
> > > always look through the entire log file, ie not using logtail.
> >
> > Looking at this old bug from 2008: does the -t option meet this need?
>
> Not quite. Imagine: I have a system running logcheck hourly. At 11:00, I
> get a mail with a log message from 10:55 that is not yet covered by the
> rule. The stamp gets updated to 11:00.
>
> I now fix the rule that should have filtered the message. logcheck -t
> will still only start checking a 11:00, so the test run will not prove
> that the change has actually filtered the message from 10:55.
>
> Does this make the usecase clear?

Does logcheck-test help with that?

Bug#1071001: how-can-i-help: really needs a test suite

[Lucas Nussbaum]

Package: how-can-i-help
Version: 18
Severity: normal

As shown by #1070713

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

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 how-can-i-help depends on:
ii  libruby2.7 [ruby-json]  2.7.4-1+deb11u1
ii  libruby3.1 [ruby-json]  3.1.2-7+deb12u1
ii  ruby1:3.1
ii  ruby-debian 0.3.10+b8

how-can-i-help recommends no packages.

how-can-i-help suggests no packages.

-- no debconf information

Bug#1065224: ITA: mysql-connector-python -- pure Python implementation of MySQL Client/Server protocol (Python3)

[T K Sourabh]

Hi,

I intend to adopt this package.

Please let me know.

Bug#1071000: sbuild-qemu: runs lintian on .changes file with Distribution != changelog target and lintian complains

[Francesco Poli (wintermute)]

Package: sbuild-qemu
Version: 0.85.8
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello!

I am still trying to set up sbuild-qemu to build (and check/test) Debian
packages.

After creating the virtual machine image:

  $ mkdir -p ~/.cache/sbuild/build
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid unstable-autopkgtest-amd64.img
  $ mv -i unstable-autopkgtest-amd64.img ~/.cache/sbuild/

I prepared the following configuration file:

  $ cat ~/.sbuildrc 
  $source_only_changes = 1;
  $run_lintian = 1;
  $lintian_require_success = 0;
  $run_piuparts = 1;
  $piuparts_root_args = '';
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $autopkgtest_root_args = '';
  $autopkgtest_require_success = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

I can update the virtual machine:

  $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img

and I can build a package from within the unpacked source tree:

  $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm

However, when I do so, I am not necessarily planning to upload the
Debian package to the Debian archive: it could be still in development
(not yet ready for an upload) and I just want to check that it can be
built and perform the usual checks on it, namely lintian (first of all!),
followed by piuparts and autopkgtest.
If this is the case, my latest changelog entry will read 'UNRELEASED' in the
distribution field, but, at the same time, I want to build the package
with the 'unstable-autopkgtest-amd64.img' VM image (to build it for
unstable).

What happens here? It turns out that sbuild-qemu modifies the Distribution
field in the .changes file and sets it to 'unstable', despiting reading
'UNRELEASED' in the latest changelog entry.
Hence lintian complains with an error:

  [...]
  Running lintian...
  E: $PKG_NAME changes: unreleased-changes
  W: $PKG_NAME: changelog-distribution-does-not-match-changes-file unreleased 
!= unstable [usr/share/doc/$PKG_NAME/changelog.gz:1]
  
  E: Lintian run failed (runtime error)
  [...]

How can I fix this issue?
Shouldn't it work out of the box?

I found bug report [#934721], which, however, seems to advocate that
this is the right behavior ?!? Or am I misinterpreting it?

[#934721]: 

How can I run lintian on a still-in-developed UNRELEASED package (with
sbuild-qemu)?

Please note that my current setup with pbuilder does not have this issue:
pdebuild generates a .changes file with 'Distribution: UNRELEASED'
and with the latest changelog entry correctly quoted (with 'UNRELEASED'
after the version number parenthesis), and hence lintian is happy...

It has to work out of the box with sbuild-qemu, as well!

Please fix the issue and/or explain what's wrong.

Thanks for your time and patience.


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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
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 sbuild-qemu depends on:
ii  autopkgtest  5.34
ii  python3  3.11.8-1
ii  python3-pexpect  4.9-2
ii  python3-psutil   5.9.8-2
ii  qemu-system-x86  1:8.2.3+ds-2
ii  qemu-utils   1:8.2.3+ds-2
ii  sbuild   0.85.8
ii  vmdb20.40-1

Versions of packages sbuild-qemu recommends:
ii  qemu-system-arm  1:8.2.3+ds-2
ii  qemu-system-ppc  1:8.2.3+ds-2

sbuild-qemu suggests no packages.

-- no debconf information

Bug#1070999: liquidctl: Add Appstream metainfo announcing HW support

[Petter Reinholdtsen]

Package: liquidctl
Version: 1.13.0-1
Tags: patch

Here is a patch for liquidctl to add Appstream metainfo XML announcing the
hardware handled by this package.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the USB
IDs are discovered.

diff --git a/debian/com.github.liquidctl.liquidctl.metainfo.xml 
b/debian/com.github.liquidctl.liquidctl.metainfo.xml
new file mode 100644
index 000..97ce91a
--- /dev/null
+++ b/debian/com.github.liquidctl.liquidctl.metainfo.xml
@@ -0,0 +1,84 @@
+
+
+  com.github.liquidctl.liquidctl
+  MIT
+  liquidctl
+  CLI and Python drivers for AIO liquid coolers and other 
devices
+  
+Liquidctl is a tool for controlling various settings of PC
+internals, such as:
+
+  liquid cooler pump speed
+  case fan speed
+  RGB LED strip colors
+
+  
+  
+usb:v0B05p19AF*
+usb:v0B05p1939*
+usb:v0B05p18F3*
+usb:v0C70pF00E*
+usb:v0C70pF010*
+usb:v0C70pF011*
+usb:v0C70pF00D*
+usb:v2433pB200*
+usb:v1B1Cp0C1C*
+usb:v1B1Cp0C2A*
+usb:v1B1Cp0C10*
+usb:v1B1Cp0C32*
+usb:v1B1Cp1C07*
+usb:v1B1Cp1C1E*
+usb:v1B1Cp1C08*
+usb:v1B1Cp1C1F*
+usb:v1B1Cp1C05*
+usb:v1B1Cp1C06*
+usb:v1B1Cp0C03*
+usb:v1B1Cp0C18*
+usb:v1B1Cp0C19*
+usb:v1B1Cp0C15*
+usb:v1B1Cp0C20*
+usb:v1B1Cp0C09*
+usb:v1B1Cp0C07*
+usb:v1B1Cp0C0A*
+usb:v1B1Cp0C17*
+usb:v1B1Cp0C13*
+usb:v1B1Cp0C21*
+usb:v1B1Cp0C12*
+usb:v1B1Cp0C22*
+usb:v1B1Cp0C29*
+usb:v1B1Cp0C02*
+usb:v1B1Cp0C08*
+usb:v1B1Cp0C1A*
+usb:v1B1Cp0C0B*
+usb:v1B1Cp1D00*
+usb:v1B1Cp1C0D*
+usb:v1B1Cp1C0A*
+usb:v1B1Cp1C0B*
+usb:v1B1Cp1C0C*
+usb:v1B1Cp0C35*
+usb:v1B1Cp0C37*
+usb:v048Dp5702*
+usb:v048Dp8297*
+usb:v7793p5911*
+usb:v7793p5912*
+usb:v7793p2500*
+usb:v1E71p1711*
+usb:v1E71p2015*
+usb:v1E71p2001*
+usb:v1E71p2002*
+usb:v1E71p1715*
+usb:v1E71p170E*
+usb:v1E71p2007*
+usb:v1E71p2014*
+usb:v1E71p3008*
+usb:v1E71p2009*
+usb:v1E71p200E*
+usb:v1E71p2010*
+usb:v1E71p2011*
+usb:v1E71p2019*
+usb:v1E71p1714*
+usb:v1E71p2006*
+usb:v1E71p200D*
+usb:v1E71p200F*
+  
+
diff --git a/debian/copyright b/debian/copyright
index 99b41f1..e2442ad 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -24,6 +24,27 @@ Files: debian/*
 Copyright: Copyright (C) 2021  Laszlo Boszormenyi (GCS) 
 License: GPL-3+
 
+Files: debian/com.github.liquidctl.liquidctl.metainfo.xml
+Copyright: 2024 Petter Reinholdtsen 
+License: MIT
+ Permission is hereby granted, free of charge, to any person obtaining a copy
+ of this software and associated documentation files (the "Software"), to deal
+ in the Software without restriction, including without limitation the rights
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ copies of the Software, and to permit persons to whom the Software is
+ furnished to do so, subject to the following conditions:
+ .
+ The above copyright notice and this permission notice shall be included in all
+ copies or substantial portions of the Software.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+
 License: GPL-3+
  This package is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
diff --git a/debian/liquidctl.install b/debian/liquidctl.install
index efbcd0e..8f268e2 100644
--- a/debian/liquidctl.install
+++ b/debian/liquidctl.install
@@ -1 +1,2 @@
 extra/linux/71-liquidctl.rules ${env:deb_udevdir}/rules.d/
+debian/com.github.liquidctl.liquidctl.metainfo.xml usr/share/metainfo

-- 
Happy hacking
Petter Reinholdtsen

Bug#975694: [logcheck-database] stop filtering smartd attribute change events

[Richard Lewis]

control: tags -1 + moreinfo
thanks

On Wed, 25 Nov 2020 13:13:14 +0500 Alex Volkov  wrote:

> IDK how it was in 2006 when this stupid decision was made, but nowadays
> `smartd` has all the needed filtering features in itself, in a case someone
> gets "annoyed" by attribute changes. Yeah, sure, it "can send warning mails",
> but by default only in a case of attribute FAILURE, and some Old-age related
> attributes NEVER fail (like Power-On Hours on WD, which counts down to 1 and
> just sits happily there, never getting to "failing" 0). In such cases at least
> seeing them changing (or not) is useful. Overall, it's not the place for a
> *maintainer* to decide (instead of a user) which events of a third-party
> package are annoying and which are not.

Following up on the above  bug from 2020 -- we need more information
here: what is the issue that you would like fixed?
you can already (even in 2020) add or subtract any rules for logcheck
that you like. smartd has a way to alert you to issues, but
that is nothing to do with logcheck.

in the absence of a clearer statement we would need to close this one.

Bug#491127: logcheck: please consider an option which will always check the entire log file

[Marc Haber]

On Sun, May 12, 2024 at 06:54:59PM +0100, R Lewis wrote:
> On Wed, 16 Jul 2008 23:15:51 +0200 Marc Haber
>  wrote:
> 
> > It would help with debugging to have an option that causes logcheck to
> > always look through the entire log file, ie not using logtail.
> 
> Looking at this old bug from 2008: does the -t option meet this need?

Not quite. Imagine: I have a system running logcheck hourly. At 11:00, I
get a mail with a log message from 10:55 that is not yet covered by the
rule. The stamp gets updated to 11:00.

I now fix the rule that should have filtered the message. logcheck -t
will still only start checking a 11:00, so the test run will not prove
that the change has actually filtered the message from 10:55.

Does this make the usecase clear?

Greetings
Marc

P.S. Thanks for doing bug triage.

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#862638: logcheck: Please add suricata rules to logcheck

[Richard Lewis]

control: tags -1 moreinfo
control: severity -1 wishlist
thanks

On Mon, 15 May 2017 10:42:03 +0200

> I am very happy with logcheck. It is great working and very usefull. However, 
> it would be nice, if you could add a ruleset for suricata (a successor to the 
> well known snort IDS), so I get alerted, when something fishy is going on.

It's a shame no-one replied to this bug from 2017 - let's change that now.

>In my case logcheck is run every 30 minutes, so I am very fast aware, when an 
>attack is going on. On the other hand, I found no realtime alert option with 
>suricata. Best way, IMO, would be a ruleset for suricata logs, which do alert 
>me by mail (as logcheck normally do).

Unfortunately more information is needed to help this.

Is the request to use logcheck to scan non-log files created by
suricata? you can definitely do that but would need to write your own
rules to ignore things that are not "fishy".
...but i dont think logcheck-database should ship such rules unless
there is clear demand. It looks like suricata can send its own alerts
so not sure this is even needed in 2024?

If there are messages produced by suricata in the journal that
logcheck should be filtering, then we need to know what those are?

(In the absence of more information we would likely close this bug as
unactionable)

Bug#735287: logcheck: invent conditional logging

[Richard Lewis]

On Tue, 14 Jan 2014 13:33:25 +0100 Arne Wichmann  wrote:

> There is one thing I would like to have in logcheck for quite a long time
> already:
>
> Invent a mechanism by which a pattern is only mailed (or not mailed) if
> another pattern was seen a given time before it (or also possibly after
> it).
>
> For example I would like to make reboots invisible on some machines, but I
> do want to see it if the sshd terminates as long as the machine is not
> rebooting.

Hi - It's a shame no-one replied to this bug in 10 years: let's change that now.

The only realistic way i can see this working is to have some kind of
pre-processing of log entries. I'm thinking you would write a
pre-processor that takes each line in the log
and look back in the journal (or syslog) for related lines -- i dont
think we'd want to implement that in logcheck, as it would be a whole
other project to write, but we could allow
the user to do it. There are several reasons to make logcheck
configurable to pre-processing ( - work on this is in progress. watch
this space!).
You can maybe even today do this with post-processing by writing a
'syslog-summary' script - again this would need the user to write
their own code.

(I think the point in the last para is basically solved by using
systemd, which makes it much easier to restart daemons when they
crash)

In the absence of other suggestions, i suggest we implement
configurable pre-processing, leave syslog-summary support in place and
close this bug.

Bug#919866: logcheck: Feature request: wildcards in .logfiles pathnames

[Richard Lewis]

On Sun, 20 Jan 2019 15:50:55 +0530 Charles Atkinson
 wrote:

> Please consider introducing wildcards into the paths in the .logfiles 
> configuration files.  Perhaps similar to the way they are used in logrotate's 
> paths.

> A use case is when using logcheck to check logs from multiple non-Debian 
> systems such as routers, each having a dedicated directory with the last 
> directory being their FQDN.  The router FQDNs follow a fixed pattern.  
> Currently this requires an /etc/logcheck-for-routers/logcheck.logfile.d file 
> for each router.  If .logfiles supported wildcards, a single 
> /etc/logcheck-for-routers/logcheck.logfile.d file could be used for all 
> routers and there would be one less step in the procedures to commission and 
> to decommission a router.

(It's a shame no-one replied since 2019: let's change that now)

You could instead implement this by a script that updates the
.logfiles file before logcheck runs: if you put this into
logcheck.conf it would work, so eg:

echo /var/log/whatever/*.log >
/etc/logcheck-for-routers/logcheck.logfiles.d/routers.logfiles

If that would meet your needs we could close this bug - the code to
read logfiles.list is already over-complicated and adding more
features needs a good reason

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

[Lucas Castro]

Sorry for top posting.

The debian/control was modified to append Git fields, Cvs-Git and 
Cvs-Browser.


Git repository is following the DEP-14 as suggested, I really 
appreciated that workflow.


Changelog was improved. It reflects the all debian package modification 
right now.


There's something to do yet, about the gbp as Daniel had mentioned, All 
things about debian branch and upstream branch for debian git.



I had uploaded the package to mentors,

https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc

The package can be checked from the git repository too, the following uri

Vcs-Browser: https://git.gnuabordo.com.br/foolsm.git
Vcs-Git: https://git.gnuabordo.com.br/foolsm.git

The debian/latest, debian/trixie and debian/unstable branches, all of 
them reflect debian package.


I'm maintain all those branch right now, and all of them is identical. 
I'm thinking about to delete the unstable.


I'll maintain just the debian/latest for development, debian/ for 
backports, security and propose-update and mentioned on DEP-14.



Thanks,

Lucas Castro


Em 11/05/2024 03:44, Tobias Frost escreveu:

On Mon, May 06, 2024 at 08:02:17PM +0200, Daniel Gröber wrote:

On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote:

  [DEFAULT]
  debian-branch = gnuabordo/latest
  debian-tag = gnuabordo/%(version)s

Please let me suggest to use DEP14 for branch naming:
https://dep-team.pages.debian.net/deps/dep14/

--
tobi



OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote:
> 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common
>arch:all m-a:foreign and the symlink farms could be kept in
>linux-libc-dev:any m-a:same retaining the size reduction.

This would not actually work.  linux-libc-dev-common would only contain
known architectures.  So the current "change config, build
linux-libc-dev" will not longer work as well.  This package would then
depend on a linux-libc-dev-common without the headers for this
architecture.

Bastian

-- 
To live is always desirable.
-- Eleen the Capellan, "Friday's Child", stardate 3498.9

Bug#1036826: Please start handling \c

[Martin Quinson]

Le dimanche 12 mai 2024 à 17:26 +, Helge Kreutzmann a écrit :
> 
> Did you receive my e-mail from this morning, where I compiled the
> remaining examples I'm aware of?

Yes I did (sorry for answering earlier before reading all mails in inbox), but
I did not dig into it yet.

Thanks,
Mt


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

Bug#1070997: sorry about the new bug

[Mike Kupfer]

Apologies, I had meant to update 1070876, not create a new bug.  I guess
they should be merged?

regards,
mike

Bug#491127: logcheck: please consider an option which will always check the entire log file

[R Lewis]

On Wed, 16 Jul 2008 23:15:51 +0200 Marc Haber
 wrote:

> It would help with debugging to have an option that causes logcheck to
> always look through the entire log file, ie not using logtail.

Looking at this old bug from 2008: does the -t option meet this need?

Bug#1070668: Processed: glibc: packages FTBFS caused by vector math library header on arm64

[Aurelien Jarno]

On 2024-05-07 00:29, Simon Chopin wrote:
> As the one who reported the issue in the glibc upstream tracker, I'm now
> of the opinion it's not a glibc bug, but rather issues with the
> individual packages that are now FTBFS. As far as I know, this is either
> a parser pretending to be GCC without implementing all the GCC features
> (e.g. aspectc++), and/or a compiler targetting another platform while
> still using the system headers (e.g. rocm-hipamd).

The goal of the removal was able to progress with the migration of glibc
2.38 to testing to not block other packages for a long time. Anyway this
strategy does not work for glibc 2.39 (it causes a FTBFS of glibc), so
we have to solve the issues before being able to get glibc 2.39 to
unstable.

Among the 4 failures, cxref already got fixed. For aspectc++ and cbmc, I
agree with you that the issues have to be fixed at the package level.
For rocm-hipamd, the maintainer claims this is a toolchain issue...

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

Bug#1070998: bookworm-pu: package fossil/2.24-5~deb11u1

[Bastien Roucariès]

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

this bug was opened by previous arrangement with maintainer.

[ Reason ]
fossil is affected by a regression due to a security update of apache
CVE-2024-24795. Backport was choosen
because upstream does not document all commit needed for fixing the regression.

[ Impact ]
Fossil is broken at least server part

[ Tests ]
Full upstream test suite

[ Risks ]
Broken fossil

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

[ Changes ]
Backport from sid. They are no incompatibility and this is upstream maintenance
and fix only version.

[ Other info ]
I have not attached the debdiff due to the fix beeing a backport from sid. 
Attached debdiff to sid instead
diff -Nru fossil-2.24/debian/changelog fossil-2.24/debian/changelog
--- fossil-2.24/debian/changelog	2024-04-30 14:32:05.0 +
+++ fossil-2.24/debian/changelog	2024-05-07 19:26:27.0 +
@@ -1,3 +1,10 @@
+fossil (1:2.24-6~deb12u1) bookworm; urgency=medium
+
+  * Non maintainer upload with acknowledgement by maintainer
+  * Backport to bookworm
+
+ -- Bastien Roucari??s   Tue, 07 May 2024 19:26:27 +
+
 fossil (1:2.24-6) unstable; urgency=medium
 
   * Add "Breaks: apache2-bin (<< 2.4.59-1~)" per #1070069 discussion.


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

Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

Hi Helmut

On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote:
> > Care to just share what you actually found?  Where is it broken and how
> > to see this?
> > Because this whole thing started with "it is broken, but I won't tell
> > you where or what or how".
> Quite clearly, this is not a single problem, but a mesh of problems and
> in a few cases it is not obvious where to solve them.

Okay, if you re-use a bug report for different things, then problem is
not defined any more.

> > I wonder now.  How would that ever work for the native build?  Or does
> > the native build already do those symlinks?  Or are native and cross
> > configured differently?  Or is that a weird difference in gcc itself?
> Native and cross builds work quite differently indeed.

Both somehow use /usr/include and /usr/include/$multiarch in the end.
So the question remains: why can the native gcc properly use headers
from there to build, but the cross one seems to be unable?

> 1. API expectation of *-$arch-cross packages

I asked exactly that in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55

> 4. cross-toolchain-base being bd-uninstallable

Which directly correlates to undocumented Build-Conflicts in the
package.  They neither show up in the changelog or the commit logs.

>I don't exactly understand why it declares them, but I guess that
>having a different set of kernel headers available in
>/usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build
>and potentially cause misbuilds. cross-toolchain-base builds these
>packages and it also uses them during build of glibc.

So this reason is now gone.  linux-source-* and linux-libc-dev are
similar enough in almost all cases.

During the next step it could just loose the special setup for those
headers and just use them from linux-libc-dev.  Then there is not longer
a chance of mixup.

> 5. gcc-V-cross not being buildable
> 
>The gcc-V-cross package relies on -$arch-cross packages usually built
>from cross-toolchain-base and expects them to provide their
>functionality in /usr/$DEB_HOST_GNU_TYPE. The current linux-libc-dev
>provides the package names but not the expected path (this actually
>is the first problem) and as a consequence, gcc-V-cross currently
>fails to build from source.

Finally we get somewhere.

> 6. Cross bootstrap cannot tell whether linux-libc-dev supports an
>architecture

Even in the past it could not.  It could try to build the linux package
to see if it gets a working linux-libc-dev.  Or have other code to hack
around, like changing the config.

> 7. Cross bootstrap needs to deal with Arch:all packages
> 
>Until linux-libc-dev became an architecture-dependent Arch:all
>package, the entire cross bootstrap was possible by only performing
>arch-only builds and using a repository of only arch:any packages
>used in conjunction with a Debian mirror restricted to Arch:all
>packages. Now, the bootstrap repository must also be able to carry
>an Arch:all package and handle the fact that multiple versions of
>linux-libc-dev exist in a bootstrap setting one of which does not
>work (as a result of the second problem).

So now the arch:all package part of the archive already contains a
working linux-libc-dev.  At least if you ask for it first, instead of
patching packages inline.

> 8. Duplication of functionality via -$arch-cross packages
> 
>When performing cross builds, we currently need both -$arch-cross
>packages and :$arch packages for glibc and linux-libc-dev. These can
>be built from different versions and we know that using
>libc6-dev-$arch-cross packages built from a different glibc version
>than libc6-dev:$arch together causes problems (repeatedly) and hence
>glibc now declares Conflicts with old libc6-dev-$arch-cross packages.
>If gcc-V-cross were to use :$arch packages, it would have to declare
>cross-architecture dependencies, which is not currently supported by
>our buildd network. That is one reason for it still using
>-$arch-cross packages.

Actually linux-libc-dev-$arch-cross is uncommunicated and uncoordinated
duplication of exactly the same content as linux-libc-dev.

9. linux-libc-dev-*-cross provides incompatible headers to
   build-essential

   Both linux-libc-dev and linux-libc-dev-*-cross provide the linux/*
   includes that are used by the compiler but of different versions.  It
   is undefined if those can work with the (always older) asm/* provided
   by linux-libc-dev-*-cross.

   This is fixed by the unification done.

2+3+6+7. linux-libc-dev provides linux-libc-dev-$arch and remains
arch:all.  Then the API for pulling in the correct one will shift.
This also allows to build linux-libc-dev-$arch as special case for
bootstrap purposes without much chance of it showing up in the wrong
location.

The oposite is also working.  linux-libc-dev becomes not-all again, but
is empty and pulls in 

Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Rudy S.]

Hello Erwin,
Thanks a lot for work-around advise ;)

Sorry for late answer but I just read it and give a try to "Disabling 
paravirtualization in virtualbox acceleration"
(i.e. VBox GUI, in the 'Settings...' of the VM, go to 'System' panel than in the 'Acceleration' tab select 'None' as 
'Paravirtualization Interface' ;))


This help me to install like this a Debian-12.5 DVD as a simple SSH server on 
VBox release is 7.0.18 ;)

For what is weird: once the installation is completed , I can switch back the 'Paravirtualization Interface' to 'Default' ( 
even with 'Secure boot' enabled ;) )


Thanks a lot again,
Rudy S.

On Wed, 31 May 2023 12:04:04 +0200 Erwin Van de Velde 
 wrote:

Hi,

Encountering the same issue, I can confirm it still persists in RC4.
However, digging a bit deeper with the error I found on dmesg: "x86/PAT:
bterm:260: map pfn expected mapping type uncached-minus for ..., got
write-combining", I found this workaround:
Disabling paravirtualization in virtualbox acceleration or switching it to
legacy results in a properly booting installer.

Kind regards,
Erwin

Bug#1070997: linux-image-5.10.0-29-amd64: more info

[Mike Kupfer]

Package: src:linux
Version: 5.10.216-1
Followup-For: Bug #1070876
X-Debbugs-Cc: kup...@rawbw.com

Dear Maintainer,

Sorry about the lack of system information in the original submission.
(I had run "reportbug linux" rather than "reportbug kernel".)

The kernel log is from a fresh boot.  Please let me know if there are
any files from /var/log that I should include.

-- Package-specific info:
** Version:
Linux version 5.10.0-29-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.216-1 (2024-05-03)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-29-amd64 root=/dev/mapper/ceylon--vg-root ro quiet

** Not tainted

** Kernel log:
[   10.876427] usbcore: registered new interface driver uvcvideo
[   10.876429] USB Video Class driver (1.1.1)
[   10.877628] intel_rapl_common: Found RAPL domain package
[   10.877630] intel_rapl_common: Found RAPL domain core
[   10.877631] intel_rapl_common: Found RAPL domain uncore
[   10.877638] intel_rapl_common: RAPL package-0 domain package locked by BIOS
[   10.905380] Adding 1003516k swap on /dev/mapper/ceylon--vg-swap_1.  
Priority:-2 extents:1 across:1003516k SSFS
[   10.924828] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[   10.925204] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   10.929617] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input12
[   10.929692] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input13
[   10.929754] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input14
[   10.929825] input: HDA Intel HDMI HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.0/sound/card0/input15
[   10.930695] input: HDA Intel HDMI HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.0/sound/card0/input16
[   10.931777] cfg80211: Loaded X.509 cert 'wens: 
61c038651aabdcf94bd0ac7ff06c7248db18c600'
[   10.938367] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[   10.940753] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[   11.007023] Bluetooth: Core ver 2.22
[   11.007082] NET: Registered protocol family 31
[   11.007084] Bluetooth: HCI device and connection manager initialized
[   11.007216] Bluetooth: HCI socket layer initialized
[   11.007219] Bluetooth: L2CAP socket layer initialized
[   11.007225] Bluetooth: SCO socket layer initialized
[   11.007354] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3235: 
line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
[   11.007356] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 
(0x14/0x0/0x0/0x0/0x0)
[   11.007358] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x15/0x0/0x0/0x0/0x0)
[   11.007360] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   11.007362] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   11.007364] snd_hda_codec_realtek hdaudioC1D0:  Headset Mic=0x1a
[   11.007366] snd_hda_codec_realtek hdaudioC1D0:  Dock Mic=0x19
[   11.007368] snd_hda_codec_realtek hdaudioC1D0:  Headphone Mic=0x18
[   11.007370] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x13
[   11.041503] usbcore: registered new interface driver btusb
[   11.046768] usb 1-1.3: firmware: failed to load ar3k/AthrBT_0x3101.dfu 
(-2)
[   11.046820] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   11.046874] usb 1-1.3: Direct firmware load for ar3k/AthrBT_0x3101.dfu 
failed with error -2
[   11.046885] Bluetooth: Loading patch file failed
[   11.046926] ath3k: probe of 1-1.3:1.0 failed with error -2
[   11.047085] usbcore: registered new interface driver ath3k
[   11.065040] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card1/input17
[   11.065129] input: HDA Intel PCH Dock Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input18
[   11.065190] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input19
[   11.065254] input: HDA Intel PCH Dock Line Out as 
/devices/pci:00/:00:1b.0/sound/card1/input20
[   11.071353] EXT4-fs (sda2): mounting ext2 file system using the ext4 
subsystem
[   11.082092] EXT4-fs (sda2): mounted filesystem without journal. Opts: (null)
[   11.082099] ext2 filesystem being mounted at /boot supports timestamps until 
2038 (0x7fff)
[   11.112440] ath9k :02:00.0: enabling device ( -> 0002)
[   11.112594] ath: phy0: WB335 2-ANT card detected
[   11.112595] ath: phy0: Set BT/WLAN RX diversity capability
[   11.120307] ath: phy0: Enable LNA combining
[   11.121445] ath: phy0: ASPM enabled: 0x42
[   11.121448] ath: EEPROM regdomain: 0x6c
[   11.121449] ath: EEPROM indicates we should expect a direct regpair map
[   11.121451] ath: Country alpha2 being used: 00
[   11.121452] ath: Regpair used: 0x6c
[   11.123371] ieee80211 phy0: Selected rate control algorithm 

Bug#1036826: Please start handling \c

[Helge Kreutzmann]

Hello Martin,
Am Sun, May 12, 2024 at 07:05:32PM +0200 schrieb Martin Quinson:
> Le samedi 11 mai 2024 à 03:31 +, Helge Kreutzmann a écrit :
> > Hello Martin,
> > Am Fri, May 10, 2024 at 06:55:38PM +0200 schrieb Martin Quinson:
> > 
> > 
> > > If you have other failures from other pages, please tell me so that I can
> > > check
> > > whether my fix is enough even before the release.
> > 
> > I can do so tomorrow afternoon, if this has time until then (I have
> > limited access atm). 
> 
> No rush. If some problems presist, I'll try to fix it afterward.

Did you receive my e-mail from this morning, where I compiled the
remaining examples I'm aware of?

Greetings

 Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1036826: Please start handling \c

[Martin Quinson]

Hello Helge,

Le samedi 11 mai 2024 à 03:31 +, Helge Kreutzmann a écrit :
> Hello Martin,
> Am Fri, May 10, 2024 at 06:55:38PM +0200 schrieb Martin Quinson:
> 
> 
> > If you have other failures from other pages, please tell me so that I can
> > check
> > whether my fix is enough even before the release.
> 
> I can do so tomorrow afternoon, if this has time until then (I have
> limited access atm). 

No rush. If some problems presist, I'll try to fix it afterward.

Enjoy your stay,
Mt


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

Bug#1070996: mousetweaks not running under X11

[Yves Saboret]

Package: mousetweaks
Version: 3.32.0-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

sudo apt update
sudo apt install mousetweaks
mousetweaks

** (mousetweaks:5734): CRITICAL **: 08:56:17.159: Not running under X11. 
Aborting.




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

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

Versions of packages mousetweaks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gsettings-desktop-schemas    43.0-1
ii  libc6    2.36-9+deb12u6
ii  libcairo2    1.16.0-7
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxcursor1  1:1.2.1-1
ii  libxfixes3   1:6.0.0-2
ii  libxtst6 2:1.2.3-1.1

mousetweaks recommends no packages.

mousetweaks suggests no packages.

-- no debconf information

Bug#1070995: src:eclib: fails to migrate to testing for too long: FTBFS on arm 32 bits

[Paul Gevers]

Source: eclib
Version: 20231212-1
Severity: serious
Control: close -1 20240408-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1069515

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:eclib has been trying to migrate for 74 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on armel and armhf, as reported in bug 106.9515


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070994: src:praat: fails to migrate to testing for too long: FTBFS on arm64, armel, armhf, ppc64el and riscv64

[Paul Gevers]

Source: praat
Version: 6.4.05+dfsg-1
Severity: serious
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:praat has been trying to migrate for 74 
days [2]. Hence, I am filing this bug. The version in unstabled failed 
to build on most architectures where it build before.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070993: src:ukui-power-manager: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: ukui-power-manager
Version: 3.1.1-1
Severity: serious
Control: close -1 4.0.0.1-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1070426

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:ukui-power-manager has been trying to 
migrate for 77 days [2]. Hence, I am filing this bug. The version in 
unstable is blocked by bug 1070426.


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=ukui-power-manager



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070784: birdfont: unable to run

[Hideki Yamane]

severity -1 normal
tags -1 +unreproducible
thanks


On Thu, 09 May 2024 06:19:47 +0200
Janusz S. Bień  wrote:

> Package: birdfont
> Version: 2.32.3-2

> I get
> 
> birdfont: symbol lookup error: /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: 
> undefined symbol: gst_transcoder_get_sync_signal_adapter

 I've tested it with freshly-installed Debian12.5 VM on gnome-boxes and
 birdfont works fine, so tagged this bug as unreproducible and severity
 as normal.


> ii  libwebkit2gtk-4.0-37  2.42.5-1~deb12u1

 Could you check its files with "LANG=C ls -l 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so*"
 and update its package with newest libwebkit2gtk-4.0-37 package, please?

 It was updated as 
https://lists.debian.org/debian-security-announce/2024/msg00095.html
 

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#1070992: siege: New upstream version of siege

[Josue Abarca]

Package: siege
Version: 4.0.7-1
Severity: wishlist

Update siege package to version: 4.1.6  - https://download.joedog.org/siege/

Bug#241787: options to seperate hosts and for log compaction would both be nice

[Richard Lewis]

> This bug is nearly 20 years old. (It is a shame no-one replied - the links
> no longer work and there is not enough info recorded to action)
>
> Unless anyone is watching and can proivde more info about what the issue
> is/was then i suggest we close it.

A year later: closing.

logcheck can send reports as gzip'd attachments so perhaps it was even
fixed sometime in the last 20 years.

Bug#302379: dh_installlogcheck installs files as root:root 644, not root:logcheck 640

[Richard Lewis]

On Mon, 24 Aug 2009 08:36:21 -0400
=?iso-8859-1?B?RnLpZOlyaWMgQnJp6HJl?=  wrote:
> On Thu, Mar 31, 2005 at 09:54:34AM -0500, Marc Sherman wrote:
> > I reported a bug on a couple clamav packages (302253, 302254) which
> > noted that in Sarge, logcheck files are supposed to be root:logcheck
> > 640, not root:root 644.  The clamav maintainer replied that he's using
>
> I should note that while the /etc/logcheck/* directories are setgid to
> attempt to fix this discrepancy, this doesn't work, as dpkg will chown()
> the installed files anyway.
>
> I guess there should be a note in README.Maintainer to instruct people
> not to install those files as 640, as tempting as it may be.

Closing this bug because it no longer applies some 15 years later:
- The directory /etc/logcheck is no longer setgid (since bookworm),
- Rules can have any permissions (as long as logcheck can read them).
  (the default is 644 and  root:root (which means harder to delete rules files).
- so no need for dh_logcheck to be patched here

therefore, closing as no more bug. (But feel free to reopen if there
is anything more to do)

Bug#1070838: xine-lib-1.2: diff for NMU version 1.2.13+hg20230710-2.1

[Boyuan Yang]

Control: tags -1 +patch  +pending


Dear maintainer,

I've prepared an NMU for xine-lib-1.2 (versioned as 1.2.13+hg20230710-2.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.


diff -Nru xine-lib-1.2-1.2.13+hg20230710/debian/changelog 
xine-lib-1.2-1.2.13+hg20230710/debian/changelog
--- xine-lib-1.2-1.2.13+hg20230710/debian/changelog 2023-08-22 
11:15:41.0 -0400
+++ xine-lib-1.2-1.2.13+hg20230710/debian/changelog 2024-05-12 
11:42:36.0 -0400
@@ -1,3 +1,13 @@
+xine-lib-1.2 (1.2.13+hg20230710-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/libxine2-bin.symbols: Remove private symbols not externally used.
+(Closes: #1070838)
+  * debian/rules: Delete .cvsversion to correct the behavior of version.sh.
+(Closes: #1070990)
+
+ -- Boyuan Yang   Sun, 12 May 2024 11:42:36 -0400
+
 xine-lib-1.2 (1.2.13+hg20230710-2) unstable; urgency=medium
 
   * Apply patch from Pino Toscano to avoid a FTBFS on hurd-i386 and to improve
diff -Nru xine-lib-1.2-1.2.13+hg20230710/debian/libxine2-bin.symbols 
xine-lib-1.2-1.2.13+hg20230710/debian/libxine2-bin.symbols
--- xine-lib-1.2-1.2.13+hg20230710/debian/libxine2-bin.symbols  2023-08-22 
11:15:41.0 -0400
+++ xine-lib-1.2-1.2.13+hg20230710/debian/libxine2-bin.symbols  2024-05-12 
11:29:33.0 -0400
@@ -399,8 +399,6 @@
  xine_post_wire@Base 1.2.0
  xine_post_wire_audio_port@Base 1.2.0
  xine_post_wire_video_port@Base 1.2.0
- xine_private_strlcat@Base 1.2.9
- xine_private_strlcpy@Base 1.2.9
  xine_profiler_allocate_slot@Base 1.2.0
  xine_profiler_init@Base 1.2.0
  xine_profiler_print_results@Base 1.2.0
diff -Nru xine-lib-1.2-1.2.13+hg20230710/debian/rules 
xine-lib-1.2-1.2.13+hg20230710/debian/rules
--- xine-lib-1.2-1.2.13+hg20230710/debian/rules 2023-08-22 11:15:41.0 
-0400
+++ xine-lib-1.2-1.2.13+hg20230710/debian/rules 2024-05-12 11:42:35.0 
-0400
@@ -47,6 +47,8 @@
 
 override_dh_clean:
rm -f $(CURDIR)/po/*.gmo
+   # Delete .cvsversion, to force version.sh to use preset version string 
(See #1070990)
+   rm -f $(CURDIR)/.cvsversion
dh_clean
 
 override_dh_installdocs:


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

Bug#1070991: RFS: libcdio-paranoia/10.2+2.0.2-1 -- audio CD reading utility which includes extra data verification features

[Philippe SWARTVAGHER]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libcdio-paranoia":

 * Package name : libcdio-paranoia
   Version  : 10.2+2.0.2-1
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://www.gnu.org/software/libcdio/
 * License  : [fill in]
 * Vcs  : https://salsa.debian.org/debian/libcdio-paranoia
   Section  : libs

The source builds the following binary packages:

  libcdio-cdda-dev - library to read and control digital audio CDs
(development files)
  libcdio-cdda2t64 - library to read and control digital audio CDs
  libcdio-paranoia-dev - library to read digital audio CDs with error
correction (development files)
  libcdio-paranoia2t64 - library to read digital audio CDs with error
correction
  cd-paranoia - audio CD reading utility which includes extra data
verification features

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

  https://mentors.debian.net/package/libcdio-paranoia/

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

  dget -x
https://mentors.debian.net/debian/pool/main/libc/libcdio-paranoia/libcdio-paranoia_10.2+2.0.2-1.dsc

Changes since the last upload:

 libcdio-paranoia (10.2+2.0.2-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Remove constraints unnecessary since buster (oldstable):
 + Build-Depends: Drop versioned constraint on libcdio-dev.
 + libcdio-cdda-dev: Drop versioned constraint on libcdio-dev in
Depends.
 + libcdio-paranoia-dev: Drop versioned constraint on libcdio-dev
in Depends.
 + cd-paranoia: Drop versioned constraint on libcdio-utils in Replaces.
 + cd-paranoia: Drop versioned constraint on libcdio-utils in Breaks.
 .
   [ Philippe SWARTVAGHER ]
   * d/control: update Build-Depends packages, as suggested by Lintian
   * New upstream release
 - Drop all patches (applied upstream).
 - Closes: #981017.
   * Bump Standards-Version to 4.7.0 (no change)
   * Add patches to fix typos

Regards,
--
  Philippe

Bug#383289: RFE: logtail locking

[Richard Lewis]

On Wed, 16 Aug 2006 05:33:26 -0500 bingo  wrote:

> It would be good if logtail supports locking.

I think we need some more information if this bug is to be action-ed.
logcheck uses logtail2 now (and syslog is not the default):so perhaps
it is not relevant after nearly 20 years (there were other replies
requesting patches in the intervening period, and no-one has provided
them -- so perhaps we should just close this as no longer relevant).

If the issue is that rsyslog might still be writing to the file, when
logtail runs, surely all that might happen is that the same entries
might be re-checked on the next run?
(and I dont think it would be sensible for logtail to try and stop
rsyslog writing while logtail runs)
the journal has a better way to avoid races, using --cursor-file --
logcheck doesnt yet use that (watch this space!) which i think might
also avoid potential race conditions here

Bug#1070990: xine-lib-1.2: Use hg snapshot but dependency not found in version.sh

[Boyuan Yang]

Source: xine-lib-1.2
Version: 1.2.13+hg20230710-2
Severity: normal
Control: tags -1 +patch

Dear Debian xine-lib-1.2 package maintainer,

You are now using an snapshot version of xine-lib-1.2 in Debian.
This introduces .cvsversion file, which will change the behavior
of version.sh file to use `hg` to retrieve the software version.

However, hg is not present in the build-dependency. We are not
supposed to use hg to retrieve version as well in the packaging.

A proper patch would be remove .cvsversion file pre-build, or
use upstream-released tarball.

Thanks,
Boyuan Yang


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

Bug#750232: logtail2 should not not print the final log entry if it does not end with "\n"

[Richard Lewis]

On Mon, 2 Jun 2014 10:25:40 -0700 (PDT) Chris Stromsoe  wrote:

> logtail2 does not do any sanity checking on the final line of input to
> make sure that it is complete and "\n" terminated.  If syslog is not set
> to flush on every write, it's possible for consecutive runs of logcheck to
> get a single log entry split in half for each run, resulting in false
> positives from logcheck.

Is this still an issue in 2024? if not we could close this old bug.

If you ran logtail2 on a non-syslog file (which might actually be an
increasingly common usage in a systemd world?), then ignoring a line
without a trailing \n means that last line might never be checked,
which seems far worse than the occasional false-positive. I dont think
i ever saw such false positives with rsyslog, when i used it.

Bug#470997: logcheck: allow running w/o locking

[Richard Lewis]

On Fri, 14 Mar 2008 21:50:17 -0400 =?utf-8?b?RnLDqWTDqXJpYyBCcmnDqHJl?= <

> When testing a checked-out copy of the rulefiles against an old log copy
> and sending the output to stdout, I still have to use sudo because
> logcheck insists on creating a lockfile.  It'd be nice to provide an
> option to skip that part.

This is easy to solve by changing LOCKDIR to point to something you can access.
You presumably are setting a custom configuration file to run as
non-root (since you wont be able to read /etc/logcheck/logcheck.conf
without sudo), and then
that custom config file can change the location to /tmp or wherever.

I think this already works in the version in bookworm, so perhaps we
can close this bug

Bug#963101: cozy-audiobook-player: "Request For Package"

[Manuel Traut]

Hi wRAR,

On Fri, May 10, 2024 at 07:31:47PM +0500, Andrey Rakhmatullin wrote:
> On Fri, May 10, 2024 at 01:47:29PM +, Manuel Traut wrote:
> > Hi,
> > 
> > I am currently working on this package [0].
> In that case please retitle this report to ITP and mark yourself as its
> owner, as described at https://www.debian.org/devel/wnpp/#l3

Thanks for the hints. ..applied.

Bug#1070154: bullseye-pu: qtbase-opensource-src/5.15.2+dfsg-9+deb11u1

[Thorsten Alteholz]

Hi Jonathan,

On 12.05.24 13:13, Jonathan Wiltshire wrote:

Please go ahead.


great, thanks ...

... and done.

  Thorsten

Bug#1070989: src:ruby-parslet: fails to migrate to testing for too long: triggers autopkgtest issues

[Paul Gevers]

Source: ruby-parslet
Version: 1.8.2-4
Severity: serious
Control: close -1 2.0.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:ruby-parslet has been trying to migrate 
for 79 days [2]. Hence, I am filing this bug. The version in unstable 
causes autopkgtest issues in src:ruby-toml (although from the log it's 
not clear why as all tests seem to pass but still exit code is 1).


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=ruby-parslet



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070988: src:q2-feature-table: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: q2-feature-table
Version: 2023.9.0+dfsg-1
Severity: serious
Control: close -1 2024.2.0+dfsg-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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=q2-feature-table



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070987: src:tiktoken: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: tiktoken
Version: 0.4.0-2
Severity: serious
Control: close -1 0.6.0-3
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:tiktoken has been trying to migrate for 84 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#470608: work-around for logcheck email charset

[Richard Lewis]

On Sat, 16 May 2020 17:12:42 -0700 Wade Richards  wrote:
> This is regarding Debian bug #47608 "wrong charset in logcheck mail
> (charset=unknown-8bit)"
>
>
> The maintainer has closed this bug as 'wontfix', but if an end-user is
> looking for a work-around, you can add the following to your
> /etc/logcheck.conf file
>
>
> # Additional args to mime-construct for sending email
>
> MIMECONSTRUCTARGS="$MINECONSTRUCTARGS --type 'text/plain;
> charset=UTF-8'"
>
>
> It's an undocumented option, so it may stop working with a future
> version of logcheck, but it works for now.

logcheck also has an option 'MIMEENCODING=' does that solve this issue?

Bug#1070986: linux-source-6.7: Signing error building 6.7 custom kernel

[Tom Overlund]

Package: linux-source-6.7
Version: 6.7.12-1
Severity: normal
X-Debbugs-Cc: to...@dilacero.org

Dear Maintainer,

I'm following the directions at the Kernel Handbook, "4.2. Building a custom 
kernel from Debian kernel source".

I apt-get installed: linux-source libncurses-dev pahole

I configured with:
$ make localmodconfig

and took defaults to any prompts.

I then ran:
$ make menuconfig

and turned on:
Kernel hacking->Generic Kernel Debugging Instruments->KGDB: kernel debugger 
(KGDB=y)

And finally, ran:
$ make bindeb-pkg

The kernel compiled, but then failed with:
  ...
  HDRINST usr/include/asm/types.h
  INSTALL debian/linux-libc-dev/usr/include
  SIGN
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
At main.c:298:
- SSL error:8002:system library::No such file or directory: 
../crypto/bio/bss_file.c:67
- SSL error:1080:BIO routines::no such file: ../crypto/bio/bss_file.c:75
sign-file: 
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
make[6]: *** [scripts/Makefile.modinst:137: 
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko] 
Error 1
make[5]: *** [Makefile:1844: modules_install] Error 2
make[4]: *** [Makefile:2059: run-command] Error 2
make[3]: *** [debian/rules:17: binary-arch] Error 2
ESC[1mdpkg-buildpackage: ESC[0mESC[1;31merrorESC[0m: make -f debian/rules 
binary subprocess returned exit status 2
make[2]: *** [scripts/Makefile.package:144: bindeb-pkg] Error 2
make[1]: *** [/home/virt/linux-source-6.7/Makefile:1560: bindeb-pkg] Error 2
make: *** [Makefile:246: __sub-make] Error 2

I did some digging, and it looks like it's trying to double-sign the .ko files. 
For example, earlier in the make output, it says:

run-command KBUILD_RUN_COMMAND=+./scripts/package/builddeb
  SYMLINK debian/linux-image/lib/modules/6.7.12/build
  INSTALL debian/linux-image/lib/modules/6.7.12/modules.order
  INSTALL debian/linux-image/lib/modules/6.7.12/modules.builtin
  INSTALL debian/linux-image/lib/modules/6.7.12/modules.builtin.modinfo
  INSTALL 
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
  SIGN
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko
  XZ  
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko.xz

And ls shows the .xz file is there:
$ ls debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel*
debian/linux-image/lib/modules/6.7.12/kernel/arch/x86/crypto/aesni-intel.ko.xz

So then when it tries to sign the .ko file again, it can't find it, because 
it's been compressed to .xz.

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

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

Versions of packages linux-source-6.7 depends on:
ii  binutils  2.42-4
ii  xz-utils  5.6.1+really5.4.5-1

Versions of packages linux-source-6.7 recommends:
ii  bc1.07.1-4
ii  bison 2:3.8.2+dfsg-1+b1
ii  build-essential   12.10
ii  cpio  2.15+dfsg-1
ii  flex  2.6.4-8.2+b2
ii  kmod  32-1
ii  libelf-dev0.191-1+b1
ii  libssl-dev3.2.1-3
ii  linux-config-6.7  6.7.12-1
ii  rsync 3.3.0-1

Versions of packages linux-source-6.7 suggests:
ii  libncurses-dev [ncurses-dev]  6.4+20240414-1
ii  pkgconf [pkg-config]  1.8.1-1+b2
pn  qtbase5-dev   

-- no debconf information

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Richard Lewis]

On Sat, 18 Mar 2023 18:55:25 + Richard Lewis
 wrote:
> On Sat, 18 Mar 2023, 15:12 Holger Levsen,  wrote:
>
> > On Thu, Mar 16, 2023 at 06:00:06PM +, Holger Levsen wrote:
> > > aaah, thanks! I only checked
> > /usr/share/doc/logcheck/NEWS.Debian.gz
> > > but not /usr/share/doc/logcheck-database/NEWS.Debian.gz
> >
> > now that I read it and followed the advice and the very nice
> > sed example there, I can they that it worked flawlessly and was
> > very easy to do. Thank you for that NEWS entry!
> >
> > > so maybe reassign this bug to src:release-notes?
> >
> > this question is still open... though maybe cloning the bug is even
> > better, I'd really appreciated a small pointer to logcheck-database's NEWS
> > file in the NEWS for logcheck...

Think we may as well close this bug, unless anyone objects. bookworm
release-notes cover the issue.
Next big change im planning to document in logcheck's NEWS.Debian to
catch all users - watch this space!

Bug#1056704: xfce4-pabel-profiles: Checking in on this bug

[Faulk Johnny]

Good morning, 
This bug has been her over 6 months now. Is there some sort of issue? I want to 
check in because this bug is a fairly straightforward fix, or so it seems. 
Seems well overdue that this be resloved and the package returned to testing...

Bug#1070784: birdfont: unable to run

[Janusz S . Bień]

On Sun, May 12 2024 at 22:20 +09, Hideki Yamane wrote:
> severity -1 normal
> tags -1 +unreproducible
> thanks
>
>
> On Thu, 09 May 2024 06:19:47 +0200
> Janusz S. Bień  wrote:
>
>> Package: birdfont
>> Version: 2.32.3-2
>
>> I get
>> 
>> birdfont: symbol lookup error: 
>> /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: undefined symbol: 
>> gst_transcoder_get_sync_signal_adapter
>
>  I've tested it with freshly-installed Debian12.5 VM on gnome-boxes and
>  birdfont works fine, so tagged this bug as unreproducible and severity
>  as normal.

I installed the program on my notebook which in principle has the same
system version as the desktop, and there birdfont also works...

>
>
>> ii  libwebkit2gtk-4.0-37  2.42.5-1~deb12u1
>
>  Could you check its files with "LANG=C ls -l 
> /lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so*"
>  and update its package with newest libwebkit2gtk-4.0-37 package, please?
>
>  It was updated as 
> https://lists.debian.org/debian-security-announce/2024/msg00095.html

This is the output from the desktop:

LANG=C ls -l /lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so*
lrwxrwxrwx 1 root root   27 May  8 12:14 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0 -> libwebkit2gtk-4.1.so.0.13.5
-rw-r--r-- 1 root root 76081696 May  8 12:14 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0.13.5

jsbien@JSBbookworm:~$ birdfont
birdfont: symbol lookup error: /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: 
undefined symbol: gst_transcoder_get_sync_signal_adapter

Could the kernel be the culprit??? I avoid to reboot the system because
sometimes it fails for unknown reason (perhaps a hardware problem?). So on
the desktop the kernel is older than on the notebook, on which the
program works.

Best regards

JSB

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien