Bug#1056171: librocblas0-tests: rocblas-test alarm timeout on slow hosts

[Cordell Bloor]

Package: librocblas0-tests
Version: 5.5.1+dfsg-3
Severity: important
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

The rocblas-test executable sets a five-second alarm signal before it
executes some tests. If the alarm goes off before the test completes,
rocblas-test will abort, under the assumption that there was deadlock
that prevented the test from completing.

On slow hosts, such as lyra.rocm.debian.net, the timeout set for the
alarm is insufficient to complete the test even when everything is
functioning normally. This problem can be observed in the test logs for
amd64+gfx900 [1].

There is no single value that would be appropriate for the alarm timeout
on every machine, so the timeout should either be configurable at
runtime or entirely removed from the rocblas-test utility.

Sincerely,
Cory Bloor

[1]: 
https://ci.rocm.debian.net/data/autopkgtest/testing/amd64+gfx900/r/rocblas/913/log.gz

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages librocblas0-tests depends on:
ii  libamdhip64-55.2.3-13
ii  libblas3 [libblas.so.3]  3.11.0-2
ii  libc62.37-12
ii  libgcc-s113.2.0-5
ii  libgfortran5 13.2.0-5
ii  libquadmath0 13.2.0-5
ii  librocblas0  5.5.1+dfsg-3
ii  librocblas0-tests-data   5.5.1+dfsg-3
ii  libstdc++6   13.2.0-5

librocblas0-tests recommends no packages.

librocblas0-tests suggests no packages.

-- no debconf information

Bug#1056170: libhsa-runtime64-1: ROCr must assume xnack is disabled

[Cordell Bloor]

Package: libhsa-runtime64-1
Version: 5.2.3-5
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

Each time a HIP application is executed, the rocr-runtime prints the message:

KFD does not support xnack mode query.
ROCr must assume xnack is disabled.

It is unclear to me whether something is actually wrong or not. This
message is emitted from a debug_print statement in amd_topology.cpp. An
example of this message can be found in the CI logs [1].

If there's something wrong with KFD, then that problem should be
reported to the kernel developers. If there's nothing wrong with KFD,
then this message should be suppressed.

An LLVM developer pointed out to me that these stray messages cause
failures in the LLVM test suite (because the tests assert upon the
unexpected error messages in the program output).

Sincerely,
Cory Bloor

[1]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx900/r/rocrand/502/log.gz

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libhsa-runtime64-1 depends on:
ii  libc6   2.37-12
ii  libelf1 0.189-4
ii  libgcc-s1   13.2.0-5
ii  libhsakmt1  5.2.3+dfsg-1
ii  libstdc++6  13.2.0-5

libhsa-runtime64-1 recommends no packages.

libhsa-runtime64-1 suggests no packages.

-- no debconf information

Bug#1056169: bookworm-pu: package di-netboot-assistant/0.78~deb12u1

[Andreas B. Mundt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: di-netboot-assist...@packages.debian.org, a...@debian.org
Control: affects -1 + src:di-netboot-assistant

[ Reason ]
With Bookworm, a few modifications have happened to the Debian Live ISO
images' meta data [1].  These changes make di-netboot-assistant
partially fail when bookworm ISO images are in use (the menus for the
network boot loaders like grub and iPXE are not generated properly).

The Live ISO images side has improved and stabilized [2], and also
di-netboot-assistant has been made more robust to account for these
modifications.  In addition a few minor fixes to documentation and
examples (bookworm, preseed file) have been applied.

[1] https://lists.debian.org/debian-live/2023/06/msg00023.html
[2] https://lists.debian.org/debian-live/2023/07/msg00030.html

[ Impact ]
The inclusion of bookworm live ISO images fails.

[ Tests ]
I tested the changes with the 12.2.0 gnome, kde and standard ISOs.
Grub and iPXE menu.

[ Risks ]
There are almost no risks involved.

[ 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 ]
Mostly parsing latest meta data from the live images and more robust
handling of kernel/initrd (with/without version number).

[ Other info ]
I'll already upload the updated package.
The release team is doing a great job, thank you!
diff -Nru di-netboot-assistant-0.76/config/grub.cfg.HEAD 
di-netboot-assistant-0.78~deb12u1/config/grub.cfg.HEAD
--- di-netboot-assistant-0.76/config/grub.cfg.HEAD  2023-03-16 
17:05:12.0 +0100
+++ di-netboot-assistant-0.78~deb12u1/config/grub.cfg.HEAD  2023-06-18 
09:11:47.0 +0200
@@ -18,7 +18,7 @@
 set default='Boot from local disk..'
 #set timeout=10
 
-if background_image 
/d-i/n-pkg/images/11/amd64/text/debian-installer/amd64/boot-screens/splash.png; 
then
+if background_image 
/d-i/n-pkg/images/12/amd64/text/debian-installer/amd64/boot-screens/splash.png; 
then
   set color_normal=light-gray/black
   set color_highlight=white/black
 elif background_image /d-i/n-a/stable/amd64/boot-screens/splash.png; then
diff -Nru di-netboot-assistant-0.76/debian/changelog 
di-netboot-assistant-0.78~deb12u1/debian/changelog
--- di-netboot-assistant-0.76/debian/changelog  2023-03-16 17:05:12.0 
+0100
+++ di-netboot-assistant-0.78~deb12u1/debian/changelog  2023-06-18 
09:11:47.0 +0200
@@ -1,3 +1,10 @@
+di-netboot-assistant (0.78~deb12u1) bookworm; urgency=medium
+
+  * Fixes for bookworm live iso image inclusion.
+  * Update/add/fix preseed examples.  Thanks to Holger Wansing.
+
+ -- Andreas B. Mundt   Sun, 18 Jun 2023 09:11:47 +0200
+
 di-netboot-assistant (0.76) unstable; urgency=medium
 
   * Fix typo in preseeding example.
diff -Nru di-netboot-assistant-0.76/di-netboot-assistant 
di-netboot-assistant-0.78~deb12u1/di-netboot-assistant
--- di-netboot-assistant-0.76/di-netboot-assistant  2023-03-16 
17:05:12.0 +0100
+++ di-netboot-assistant-0.78~deb12u1/di-netboot-assistant  2023-06-18 
09:11:47.0 +0200
@@ -26,7 +26,7 @@
 
 # -- Declare the constants --- #
 PACKAGE_NAME=di-netboot-assistant
-PACKAGE_VERSION=0.76
+PACKAGE_VERSION=0.78
 
 # -- Initialize the global variables - #
 OFFLINE=false
@@ -253,8 +253,8 @@
 # Returns: (EXIT STATUS) 0=Success, 1=Error
 #  #
 prepare_grub() {
-local v="" opt=$1 VERS V GRUB AR DIR 
-
+local v="" opt=$1 VERS V GRUB AR DIR
+
 $VERBOSE && v="-v"
 [ -z "$opt"  ] && [ -d $TFTP_ROOT/$N_A_DIR/grub ] && return 0
 
@@ -263,7 +263,7 @@
 [ ! -e "$TFTP_ROOT/debian-installer" ] && \
 ln -srv $TFTP_ROOT/$N_A_DIR/ $TFTP_ROOT/debian-installer
 
-for AR in x64 aa64 ; do 
+for AR in x64 aa64 ; do
 ## We link bootnet*.efi and grub*.efi from the latest available image:
 echo "I: Preparing EFI executables for '${AR}'."
 GRUB=""
@@ -533,7 +533,7 @@
 
 EOF
 sed -i "s%\(\# END_PKG_LIVE_MENU.*\)%item $tag $title\n\1%" menu.ipxe
-
+
 for AR in amd64 arm64 ; do
 gcfg="${TFTP_ROOT}/${relpath}/debian-installer/${AR}/grub/grub.cfg"
 if [ -f "$gcfg" ] ; then
@@ -560,7 +560,7 @@
 relpath=$(dirname "$x" | sed -e "s#${TFTP_ROOT}##" -e "s#^/*##" -e 
"s#\/.disk##")
 # shellcheck disable=SC2034
 ISO_NAME=$(basename "$relpath")
-title=$(sed -e "s#Official ##" -e "s#T.*\$##" "$x")
+title="$(sed -e "s#Official ##" -e 
"s#\(T\|-\)[0-9]\{2\}:[0-9]\{2\}\$##" "$x")"
 ## We cannot modify the iso images, copy grub.cfg instead:
 cfg="${TFTP_ROOT}/${relpath}/isolinux/menu.cfg"
 ncfgdir="live/pxe-${relpath//'/'/'_'}"
@@ -578,9 +57

Bug#1056001: spamd: user_prefs include files are only read on the first scan

[Martin Schwenke]

On Fri, 17 Nov 2023 21:27:40 -0800, Noah Meyerhans 
wrote:

> Thank you.  Fixed with 
> https://salsa.debian.org/debian/spamassassin/-/commit/5e3d193894de527a22dac427a308a4387dc4d890
> 
> 
> Will upload this to unstable in the not-too-distant future.

Thank you!

Might this fix make it into a bug fix for Debian 12.3?

Thanks again...

peace & happiness,
martin

Bug#1056149: Update: Working after disabling VDPAU hardware acceleration

[Yurui Hong]

Package: vlc
Version: 3.0.20-1+b1
Followup-For: Bug #1056149
X-Debbugs-Cc: yuruihon...@outlook.com

Bug#1056168: ITP: python-pycm -- Multi-class confusion matrix library

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-pycm
  Version : 4.0
  Upstream Contact: Sepand Haghighi 
* URL : https://github.com/sepandhaghighi/pycm 
* License : Expat
  Programming Lang: Python
  Description : Multi-class confusion matrix library

Pycm supports both input data vectors and direct matrix,
 and a proper tool for post-classification model evaluation
 that supports most classes and overall statistics
 parameters. PyCM is the swiss-army knife of confusion
 matrices, targeted mainly at data scientists that need a
 broad array of metrics for predictive models and accurate
 evaluation of a large variety of classifiers.

Bug#1056001: spamd: user_prefs include files are only read on the first scan

[Noah Meyerhans]

Control: tags -1 + pending


On 11/15/2023 2:31 PM, Martin Schwenke wrote:

This was reported upstream via:

   https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8130

and fixed in the trunk via commit:

   
https://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin.pm?r1=1913789&r2=1913803&diff_format=h



Thank you.  Fixed with 
https://salsa.debian.org/debian/spamassassin/-/commit/5e3d193894de527a22dac427a308a4387dc4d890



Will upload this to unstable in the not-too-distant future.


noah

Bug#1055284: Acknowledgement (RFP: harpoon -- CLI tool for open source and threat intelligence)

[Antoine Beaupré]

On 2023-11-03 10:30:49, Antoine Beaupré wrote:
> https://github.com/kpcyrd/sn0int
> https://github.com/aancw/Belati
> https://github.com/nitefood/asn

Another, more minimalistic tool is simply a DNS resolver with support
for looking up ASNs:

https://github.com/natesales/q

Specifically those options are interesting:

  -w   Resolve ASN/ASName for A and  records
  -R, --resolve-ipsResolve PTR records for IP addresses in A and
    records

It's unclear how much batch support this supports and obviously it
doesn't do much beyond that (e.g. no lookup on other databases or
geoip...)

a.

-- 
If I can't dance, I don't want to be part of your revolution.
- Emma Goldman

Bug#1056166: systemd-homed: `passwd` fails

[Michael Biebl]

Am 18.11.23 um 03:25 schrieb Jack Pearson:

$ apt install systemd-homed
$ passwd
passwd: Authentication token manipulation error


Installing systemd-homed changes the PAM configuration of common-passwd:


 # here are the per-package modules (the "Primary" block)
-password   [success=1 default=ignore]  pam_unix.so obscure yescrypt
+password   [success=2 default=ignore]  pam_systemd_home.so 
+password   [success=1 default=ignore]  pam_unix.so obscure use_authtok try_first_pass yescrypt



Enabling some debug flags yields


Nov 18 05:39:03 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): 
pam-systemd-homed account management
Nov 18 05:39:03 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): Not a 
user managed by systemd-homed: No home for user michael known
Nov 18 05:39:03 debian passwd[6463]: pam_unix(passwd:chauthtok): username 
[michael] obtained
Nov 18 05:39:06 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): 
pam-systemd-homed account management
Nov 18 05:39:06 debian passwd[6463]: pam_unix(passwd:chauthtok): username 
[michael] obtained
Nov 18 05:39:06 debian passwd[6463]: pam_unix(passwd:chauthtok): password - new 
password not obtained


I'm not really familiar with PAM though, so no idea how to fix this.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056167: /usr/libexec/gnome-initial-setup: Fails to boot into desktop environment due to SIGSEGV around cc-input-chooser.c

[Flaviu Tamas]

Package: gnome-initial-setup
Version: 43.2-6
Severity: important
File: /usr/libexec/gnome-initial-setup
X-Debbugs-Cc: m...@flaviutamas.com

Dear Maintainer,

   * What led up to the situation?

I had a fully working & configured system with gnome.

I performed automatic updates through the software center and did the
suggested restart. These updates do not seem to be related to the crash
though:

Start-Date: 2023-11-17  22:24:40
Commandline: packagekit role='update-packages'
Upgrade: libjavascriptcoregtk-4.1-0:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), gir1.2-javascriptcoregtk-4.0:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), gir1.2-javascriptcoregtk-4.1:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), gir1.2-webkit2-4.0:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), gir1.2-webkit2-4.1:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), libjavascriptcoregtk-6.0-1:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), libjavascriptcoregtk-4.0-18:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), libwebkit2gtk-4.1-0:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), libwebkit2gtk-4.0-37:amd64 (2.42.1-1~deb12u1, 
2.42.2-1~deb12u1), libwebkitgtk-6.0-4:amd64 (2.42.1-1~deb12u1, 2.42.2-1~deb12u1)
End-Date: 2023-11-17  22:24:46

When the automatic login kicked in after this reboot, I got a segfault
in gnome-initial-setup. Full stack trace:

#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f8fe30a9d9f in __pthread_kill_internal (signo=6, 
threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f8fe305af32 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7f8fe3045472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f8fe309e340 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f8fe31b8459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x7f8fe30b36ba in malloc_printerr (str=str@entry=0x7f8fe31b60b1 
"free(): invalid pointer") at ./malloc/malloc.c:5660
#6  0x7f8fe30b5444 in _int_free (av=, p=, 
have_lock=have_lock@entry=0) at ./malloc/malloc.c:4435
#7  0x7f8fe30b7d9f in __GI___libc_free (mem=) at 
./malloc/malloc.c:3385
#8  0x7f8fe882f755 in g_free (mem=) at 
../../../glib/gmem.c:229
#9  0x556d25634163 in get_locale_infos (chooser=) at 
../gnome-initial-setup/pages/keyboard/cc-input-chooser.c:448
#10 cc_input_chooser_constructed (object=) at 
../gnome-initial-setup/pages/keyboard/cc-input-chooser.c:761
#11 0x7f8fe8928e06 in g_object_new_internal 
(class=class@entry=0x556d2688a870, params=params@entry=0x0, 
n_params=n_params@entry=0) at ../../../gobject/gobject.c:2279
#12 0x7f8fe892a3fc in g_object_new_with_properties 
(object_type=93927280192000, n_properties=, 
names=names@entry=0x0, values=values@entry=0x0) at 
../../../gobject/gobject.c:2391
#13 0x7f8fe892b001 in g_object_new (object_type=, 
first_property_name=first_property_name@entry=0x0) at 
../../../gobject/gobject.c:2037
#14 0x7f8fe7d018f1 in _gtk_builder_construct (builder=0x556d262b83a0, 
info=0x556d262d5b70, error=) at ../../../gtk/gtkbuilder.c:844
#15 0x7f8fe7d03585 in builder_construct 
(data=data@entry=0x7ffe52f96f80, object_info=object_info@entry=0x556d262d5b70, 
error=error@entry=0x7ffe52f96ef0) at ../../../gtk/gtkbuilderparser.c:474
#16 0x7f8fe7d05c3a in end_element (error=0x7ffe52f96ef0, 
user_data=0x7ffe52f96f80, element_name=, context=) at ../../../gtk/gtkbuilderparser.c:1941
#17 end_element (context=, element_name=, 
user_data=0x7ffe52f96f80, error=0x7ffe52f96ef0) at 
../../../gtk/gtkbuilderparser.c:1842
#18 0x7f8fe7d0368f in proxy_end_element 
(gm_context=gm_context@entry=0x0, element_name=0x556d262bb5c0 "object", 
user_data=user_data@entry=0x7ffe52f96fa8, error=error@entry=0x7ffe52f96ef0) at 
../../../gtk/gtkbuilderparser.c:104
#19 0x7f8fe7f367b8 in replay_end_element (tree=0x7ffe52f96ee0, 
strings=0x556d262bb5a6 "property", error=0x7ffe52f97080, 
context=0x7ffe52f96fa8) at ../../../gtk/gtkbuilderprecompile.c:656
#20 _gtk_buildable_parser_replay_precompiled 
(context=context@entry=0x7ffe52f96fa8, data=data@entry=0x556d262bb5a0 "GBU", 
data_len=data_len@entry=622, error=error@entry=0x7ffe52f97080) at 
../../../gtk/gtkbuilderprecompile.c:738
#21 0x7f8fe7d06600 in gtk_buildable_parse_context_parse 
(error=0x7ffe52f97080, text_len=622, text=0x556d262bb5a0 "GBU", 
context=0x7ffe52f96fa8) at ../../../gtk/gtkbuilderparser.c:191
#22 _gtk_builder_parser_parse_buffer (builder=builder@entry=0x556d262b83a0, 
filename=filename@entry=0x556d262b98c0 "", 
buffer=buffer@entry=0x556d262bb5a0 "GBU", length=length@entry=622, 
requested_objs=requested_objs@entry=0x0, error=error@entry=0x7ffe52f97080) at 
../../../gtk/gtkbuilderparser.c:2196
#23 0x7f8fe7cff119 in gtk_builder_extend_with_template 
(builder=builder@entry=0x556d262b83a0, object=object@entry=0x556d26259d60, 
template_type=template_type@entry=93927280

Bug#1054125: dh-builtusing: Please backport dh-builtusing to bookworm

[Daniel Gröber]

Hi Nicolas,

Sorry for taking so long to get back to you I've had some family issues to
deal with.

On Thu, Oct 19, 2023 at 12:42:18PM +0200, Nicolas Boulenguez wrote:
> > would it be possible to get dh-builtusing backported for bookworm? We
> > want to use dh-builtusing in ghdl (as you know ;), but I run my
> > package builds on bookworm, inside an sbuild chroot, so gbp breaks
> > when building the source package it's going to hand to the chroot.
> 
> Please first consider a simple solution that I have been using for
> years.
> 
> Dpkg-buildpackage --build=source (run by $tool) cleans the source tree
> before preparing the .dsc (that $tool then copies into the chroot).

Incidentally, I've done some light code review of dpkg-dev a while ago. I
was looking at how/when patches are applied/unapplied but the cleaning
logic is close by.

> The motivation for the cleaning was probably to prevent objects
> embedded into the .dsc, but

I think it might also be related to the automatic patch generation some
source formats support. From that perspective: if you don't clean up before
building the dsc the generated patch could contain build cruft. Of course
there's extend-diff-ignore to prevent this so I'm not entirely sure this
tracks.

> * dpkg-buildpackage now (source format 3.0) aborts when it detects a
>   file present in the source tree but missing or different in the
>   .orig tarball

I had this same throught "why can't we just disable pre-clean for 3.0
(quilt)" but that's forgetting about debian/. Build products end up there
so we need to clean those up or we could include build cruft in the dsc and
potentially change the behaviour of the build that way.

> The clean step may even be harmful.
>  * It requires build dependencies outside the chroot
>(your issue with dh-builtusing).
>  * Even if these are installed, the versions and behaviour may differ.
>(probable cause of your issue with dh-ada-library)

I suppose in theory this behavioural difference could reflect in the dsc
content. I don't think that's a really a huge problem, it's just another of
a number of reasons why a dsc freshly built from packaging git may differ
from whats in the archive.

I kind of see this (source) build diversity to be a good thing. It means
I'm going to encounter (and fix) issues users doing their own ghetto
backports (like I used to ;) are going to encounter.

Perhaps it would be worthwhile to setup some system (salsa CI?) to detect
this case tho.

I've been toying with the idea of setting up a Debian-wide system to nag
maintainers about out-of-date, inconsistent or plain broken packaging git
repos. This logic to diff the dsc against one built from unstable could be
part of that effort.

>  * The upstream clean process may execute surprising commands like
>  find . -name '*~' -delete
>  git reset --hard
>or make applied debian/patches hard to revert.
>  * Various packages require incompatible Build-Dependencies.
>  * ...
> 
> You can disable the clean with
> # dpkg-buildpackage -nc
> # pdebuild --debbuildopts -nc
> or a similar gbp-buildpackage option.

I enabled this on my workstation by way of

$ echo no-pre-clean > ~/.config/dpkg/buildpackage.conf

and after using it for a while I can't say I enjoy it or consider it
safe. It's wayyy too easy to forget to clean this way.

Even with git what may be missing is a hook in dpkg-buildpackage to abort
the (source) build when the worktree is unclean, but even then I'm not sure
gbp export-orig will apply debian/.gitignore if it exists, which could be
another pitfall.

> In case you want to keep a basic check of the clean target, the right
> place is a pbuilder script cleaning inside the chroot after the build,
> then reporting any difference between the source and the .dsc.
> The output is almost always either
>  * trivial to work-around in Debian
>(echo '*.o' > debian/clean)
>(fixing upstream may be another story)
>  * short enough to be easily ignored
>(./configure),
>  * or a real issue.

I never really used pbuilder, I went straight to sbuild so I'm not sure
what this setup would look like, could you elaborate or show an example?

--Daniel


signature.asc
Description: PGP signature

Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port

[Daniel Gröber]

Hi Peter,

On Mon, Nov 13, 2023 at 09:40:46AM +, peter.gasparo...@orange.com wrote:
> In the meantime, I was stubborn to find a solution to what I need in
> order to progress and MACVLAN tech actually delivered it (private mode
> enough),

I used to love macvlan too but now I do L3 instead ;P

> something newer than VETH tech what I could read about, and it's
> just perfect avoiding bridge itself. So no problem to cooperate on this
> fix, I will be glad, just it can get lower priority on your side if you
> even attributed it some 😊

I'd be happy to still track this bug down but I need you to investigate the
behaviour in your environment. If you've torn down the lab already we can
also just call it quits.

If you do want to continue some questions are still pending, see quoted below.

> On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > 1) As was reported, foreign external world MAC@ does not pass into 
> > network namespace, just external border point "vlan199"
> 
> How did you check this?
>
> > 2) now collecting data for you, honestly I don’t see external mac 
> > address on "inet-br" object, so my previous statement was incorrect.. 
> > {ossibly I might mixed this up with another "labinet-br" (working in 
> > its limited
> > scope) which is IP-defined, while "inet-br" in question is not.
> >
> > 3) so question is, if the MACs learnt via vlan199 are supposed to be 
> > paired (displayed) with "inet-br" object and all way up into NS
> 
> I want to make sure we're on the same page, how do you check if the MAC is 
> reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump 
> this will tell you whether ARP is even reaching the NS or not.
> 
> Something simple like
> 
> $ tcpdump -enli $IFACE 'arp or icmp'
> 
> optionally you can filter by MAC (`ether host` in pcap-filter speak):
> 
> $ tcpdump -enli $IFACE ('arp or icmp) and ether host aa:00:00:00:00:01
> 
> Oh and one last thing: please double and tripple check that a firewall isn't 
> interfering.

--Daniel


signature.asc
Description: PGP signature

Bug#1056166: systemd-homed: `passwd` fails

[Jack Pearson]

Package: systemd-homed
Version: 255~rc2-1
Severity: important

Dear Maintainer,

In a minimal Debian installation, `systemd-homed` breaks `passwd`.

Just run these commands:

```
$ sudo -sE
$ debootstrap unstable unstable-dir
$ chroot unstable-dir
$ apt install systemd-homed
$ passwd
passwd: Authentication token manipulation error
passwd: password unchanged
```

I'm certain this isn't a quirk of the chroot installation, I first found this 
issue on Raspbian installed on actual hardware, version bookworm.


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages systemd-homed depends on:
ii  init-system-helpers  1.65.2
ii  libblkid12.39.2-6
ii  libc62.37-12
ii  libcap2  1:2.66-4
ii  libfdisk12.39.2-6
ii  libpam-runtime   1.5.2-9.1
ii  libpam0g 1.5.2-9.1
ii  libssl3  3.0.12-2
ii  libsystemd-shared255~rc2-1
ii  systemd  255~rc2-1
ii  systemd-userdbd  255~rc2-1

systemd-homed recommends no packages.

systemd-homed suggests no packages.

-- debconf information excluded

Bug#1056165: google.protobuf stubs missing?

[David Mandelberg]

Package: python3-typeshed
Version: 0.0~git2023.6764465-2

python3-typeshed has python3-types-protobuf in its Provides, so I assume 
it's supposed to provide types for google.protobuf? But I don't actually 
see any stubs for that package, and mypy gives this error:


dseomn@solaria:/tmp/tmp.ENkl9u3Pjr$ cat foo.py
from google.protobuf import json_format
dseomn@solaria:/tmp/tmp.ENkl9u3Pjr$ mypy foo.py
foo.py:1: error: Module "google.protobuf" has no attribute "json_format" 
 [attr-defined]

Found 1 error in 1 file (checked 1 source file)


Until recently, I just configured mypy with `ignore_missing_imports = 
true` for google.protobuf.*, but that stopped working sometime around 
the upgrade from python3-typeshed 0.0~git20221107.4f381af-1 to 
0.0~git2023.6764465-2. (I don't know if that's the cause or if the 
timing is a coincidence, but either way, it looks like the stubs are 
missing.)

Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)

[Maytham Alsudany]

Hi Nilesh,

On Fri, 2023-11-17 at 16:45 +0530, Nilesh Patra wrote:
> On Fri, Nov 17, 2023 at 06:18:04PM +0800, Maytham Alsudany wrote:
> > golang-github-go-logfmt-logfmt doesn't have this Handler type that's being 
> > used,
> > and humanlog already uses go-logfmt as much as it can
> > 
> > I've made an issue upstream at [3] regarding this and I've patched out the
> > Handler type completely from humanlog for now.
> > 
> > Would you like me to close this RFS bug and the ITP?
> 
> If this is needed for some actual functionality in humanlog, I will upload 
> kr-logfmt
> which would otherwise block your work.

There's only one thing, a Go interface, in humanlog that uses kr-logfmt
functionality, but it is possible to patch out (as lazygit doesn't use it).

humanlog/handler.go[4]:

import (
"github.com/humanlogio/humanlog/internal/pkg/config"
"github.com/kr/logfmt"
)

// Handler can recognize it's log lines, parse them and prettify them.
type Handler interface {
CanHandle(line []byte) bool
Prettify(skipUnchanged bool) []byte
logfmt.Handler
}

This is the only place kr-logfmt is used, and humanlog's Handler interface is
not used anywhere else within humanlog.

> From your mail, it is not clear to me whether or not it is needed.
> Please let me know.

Yes, it is needed, but I've let humanlog upstream and the lazygit packaging
effort know about your concerns.

I see two options:
  1. Patch out kr-logfmt out of humanlog, removing the single Handler interface
that uses it, and when a package needs the Handler interface from humanlog,
we revist the issue.
  2. Upload kr-logfmt and package humanlog as usual.

> > [1]: https://bugs.debian.org/1055740
> > [2]:
> > https://salsa.debian.org/go-team/packages/golang-github-humanlogio-humanlog/
> > [3]: https://github.com/humanlogio/humanlog/issues/71
[4]:
https://github.com/humanlogio/humanlog/blob/eceedbf5df8383202e34d3aa4cb3d8dc182b3600/handler.go

Kind regards,
Maytham


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

Bug#1042853: docknot: FTBFS with Perl 5.38: t/spin/errors.t failure

[gregor herrmann]

On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote:

> gregor herrmann  writes:
> > According to https://github.com/rra/docknot/issues/6 fixed upstream
> > (in git, not released yet).
> Yeah, I'm sorry about the delay here.  I'm trying to get a new release out
> shortly and if I fail at that I'll patch this in the Debian package.
> Please feel free to move forward with Perl and don't block on this
> package; this is totally my own (known) problem.

Hi Russ,

in the light of #1055955 (perl5.38 transition bug) -- do you think
you can upload a fixed version (the current version plus a patch or a
new release) in the near future, or should I upload an NMU with your
upstream commit or should we just ignore docknot for the transition …
or something else? :)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1056164: bookworm-pu: package libervia-backend/0.9.0~hg3993-4+deb12u1

[Martin]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-xmpp-de...@lists.alioth.debian.org

Fixes three bugs:

#1056163  libervia-backend: start fails without pre-existing configuration
#1055445  libervia-backend: manual page says it is autorun, but it is not
#1055446  libervia-backend: requires python3-txdbus

Debdiff is attached.

diff -Nru libervia-backend-0.9.0~hg3993/debian/changelog 
libervia-backend-0.9.0~hg3993/debian/changelog
--- libervia-backend-0.9.0~hg3993/debian/changelog  2023-02-07 
08:34:29.0 +
+++ libervia-backend-0.9.0~hg3993/debian/changelog  2023-11-17 
23:29:54.0 +
@@ -1,3 +1,11 @@
+libervia-backend (0.9.0~hg3993-4+deb12u1) bookworm; urgency=medium
+
+  * Fix dependencies on python3-txdbus/python3-dbus (Closes: #1055446)
+  * Add patch to make exec path absolute in dbus service file (Closes: 
#1055445)
+  * Fix start failure without pre-existing configuration (Closes: #1056163)
+
+ -- Martin   Fri, 17 Nov 2023 23:29:54 +
+
 libervia-backend (0.9.0~hg3993-4) unstable; urgency=medium
 
   * add patch to not use SCM version (Closes: #1030429)
diff -Nru libervia-backend-0.9.0~hg3993/debian/control 
libervia-backend-0.9.0~hg3993/debian/control
--- libervia-backend-0.9.0~hg3993/debian/control2023-02-07 
00:01:12.0 +
+++ libervia-backend-0.9.0~hg3993/debian/control2023-11-17 
23:29:54.0 +
@@ -31,7 +31,7 @@
python3-alembic,
python3-babel,
python3-dateutil (>= 2.7.3~),
-   python3-dbus,
+   python3-txdbus,
python3-idna,
python3-lxml,
python3-mutagen,
@@ -113,6 +113,7 @@
${python3:Depends},
python3,
 libervia-backend (= ${source:Version}),
+   python3-dbus,
python3-gi,
 Recommends: python3-progressbar,
python3-pygments,
diff -Nru libervia-backend-0.9.0~hg3993/debian/patches/fix-exec-path.patch 
libervia-backend-0.9.0~hg3993/debian/patches/fix-exec-path.patch
--- libervia-backend-0.9.0~hg3993/debian/patches/fix-exec-path.patch
1970-01-01 00:00:00.0 +
+++ libervia-backend-0.9.0~hg3993/debian/patches/fix-exec-path.patch
2023-11-17 23:29:54.0 +
@@ -0,0 +1,14 @@
+Description: Exec path must be absolute
+Author: Martin 
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/1055445
+Last-Update: 2023-11-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/misc/org.libervia.Libervia.service
 b/misc/org.libervia.Libervia.service
+@@ -1,3 +1,3 @@
+ [D-BUS Service]
+ Name=org.libervia.Libervia
+-Exec=libervia-backend
++Exec=/usr/bin/libervia-backend
diff -Nru libervia-backend-0.9.0~hg3993/debian/patches/fix-startup-error.patch 
libervia-backend-0.9.0~hg3993/debian/patches/fix-startup-error.patch
--- libervia-backend-0.9.0~hg3993/debian/patches/fix-startup-error.patch
1970-01-01 00:00:00.0 +
+++ libervia-backend-0.9.0~hg3993/debian/patches/fix-startup-error.patch
2023-11-17 23:29:54.0 +
@@ -0,0 +1,18 @@
+Description: fix exception on startup without pre-existing configuration
+Author: Martin 
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/1056163
+Last-Update: 2023-11-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/sat/memory/migration/env.py
 b/sat/memory/migration/env.py
+@@ -3,6 +3,8 @@
+ from sqlalchemy import pool
+ from sqlalchemy.ext.asyncio import create_async_engine
+ from alembic import context
++import sys
++sys.path.append("/usr/share/libervia")
+ from sat.memory import sqla_config
+ from sat.memory.sqla_mapping import Base
+ 
diff -Nru libervia-backend-0.9.0~hg3993/debian/patches/series 
libervia-backend-0.9.0~hg3993/debian/patches/series
--- libervia-backend-0.9.0~hg3993/debian/patches/series 2023-02-07 
08:27:18.0 +
+++ libervia-backend-0.9.0~hg3993/debian/patches/series 2023-11-17 
23:29:54.0 +
@@ -1,3 +1,5 @@
+fix-startup-error.patch
+fix-exec-path.patch
 replace-getargspec.patch
 0001-Search-.mo-files-in-default-system-locale-dir.patch
 0002-add-sat_tmp.patch

Bug#1036255: python3-onelogin-saml2: FTBFS in testing: AssertionError: "Invalid issuer in the Logout Request" does not match "Could not validate timestamp: expired. Check system clock.)"

[Santiago Vila]

owner 1036255 !
thanks

El 18/5/23 a las 20:36, Andrey Rakhmatullin escribió:

https://github.com/SAML-Toolkits/python-saml/commit/a6a21109179571c9ca23f92e03017759741603c2
looks like a fix for this, though I haven't tested it.


Thanks a lot for the hint. Yes, such commit was the beginning of the fix,
but two additional commits after that one were also required.

I plan to fix this in stable as well.

Thanks.

Bug#1056163: libervia-backend: start fails without pre-existing configuration

[Martin]

Package: libervia-backend
Severity: serious
Version: 0.9.0~hg3993-4
Tags: bookworm

When there is no pre-existing configuration (`~/.local/share/libervia/`),
starting `libervia-backend fg` fails with an exception:

```
  File "/usr/share/libervia/sat/memory/migration/env.py", line 8, in 
from sat.memory import sqla_config
ModuleNotFoundError: No module named 'sat'
2023-11-18T00:00:00+ /!\ Can't upgrade database (exit code 1)
```

Bug#1056162: linux-cpupower: could use a little amd support

[debian user]

Package: linux-cpupower
Version: 6.5.3-1~bpo12+1
Severity: wishlist
Tags: upstream

Dear Maintainer,

The linux-cpupower pkg doesn't seem able to support CPU frequency control 
mechanism on modern AMD APU 
and CPU series in Linux kernel.

current kernel efforts for amd cpu:
https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html

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

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

Versions of packages linux-cpupower depends on:
ii  libc6 2.36-9+deb12u3
ii  libcap2   1:2.66-4
ii  libcpupower1  6.5.3-1~bpo12+1
ii  libpci3   1:3.9.0-4

linux-cpupower recommends no packages.

linux-cpupower suggests no packages.

-- no debconf information
#!/bin/sh
# /usr/local/sbin/amdepp.sh

# uncomment one in each group to enable
ACTIVE_GOV=powersave
#ACTIVE_GOV=performance

#ACTIVE_PREF=performance
ACTIVE_PREF=balance_performance
#ACTIVE_PREF=balance_power
#ACTIVE_PREF=power

#PASSIVE_GOV=powersave
PASSIVE_GOV=ondemand
#PASSIVE_GOV=conservative
#PASSIVE_GOV=performance

TEEPATH=/sys/devices/system/cpu/cpu*/cpufreq
READPATH=/sys/devices/system/cpu/cpufreq/policy0

if [ ! -d /sys/devices/system/cpu/amd_pstate ] ; then
echo not amd_pstate compatible cpu
exit 1
fi
read DRIVER_NAME <$READPATH/scaling_driver || exit 2
case "$1" in
set)
case $DRIVER_NAME in
amd-pstate-epp)
echo $ACTIVE_GOV | /usr/bin/tee $TEEPATH/scaling_governor
echo $ACTIVE_PREF | /usr/bin/tee 
$TEEPATH/energy_performance_preference
;;
amd-pstate|acpi-cpufreq)
[ -d  /sys/module/cpufreq_$PASSIVE_GOV ] || modprobe 
cpufreq_$PASSIVE_GOV
echo $PASSIVE_GOV | /usr/bin/tee $TEEPATH/scaling_governor
;;
*) echo no compatible scaling driver
esac
;;
*|get)
# default info only
echo driver: $DRIVER_NAME
read DRIVER_MODE 

Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10

[Heinrich Schuchardt]

On 11/18/23 00:30, Vagrant Cascadian wrote:

On 2023-10-02, Heinrich Schuchardt wrote:

U-Boot v2023.10 has been released. It provides sufficient support for
the StarFive Visionfive 2 board.


Thanks!



I would suggest to package it as u-boot-starfive.


I will probably wait until u-boot 2023.10 lands in Debian before
uploading a new binary package that requires NEW review, but probably
not long after.



64fd30d367a1 ("tools: mkimage: Add StarFive SPL image support")
90602e779d3a ("riscv: dts: starfive: generate u-boot-spl.bin.normal.out")
ad4b1bc39eef ("configs: NVMe/USB target boot devices on VisionFive 2")
98d17450cd4b ("starfive: visionfive2: add mmc0 and nvme boot targets")


I presume the above commits have now landed in upstream u-boot git?


Above commit hashes are present in upstream origin/master.





[PATCH v2] i2c: designware_i2c: adjust timing calculation
https://lore.kernel.org/u-boot/20231013130939.19803-1-heinrich.schucha...@canonical.com/


Did this land upstream yet?


35e8007ef382 ("i2c: designware_i2c: adjust timing calculation")
in origin/master.



Anything else needed?


To my knowledge this is all that is needed on top of v2023.10.

Best regards

Heinrich

Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10

[Vagrant Cascadian]

On 2023-10-02, Heinrich Schuchardt wrote:
> U-Boot v2023.10 has been released. It provides sufficient support for 
> the StarFive Visionfive 2 board.

Thanks!


> I would suggest to package it as u-boot-starfive.

I will probably wait until u-boot 2023.10 lands in Debian before
uploading a new binary package that requires NEW review, but probably
not long after.


> 64fd30d367a1 ("tools: mkimage: Add StarFive SPL image support")
> 90602e779d3a ("riscv: dts: starfive: generate u-boot-spl.bin.normal.out")
> ad4b1bc39eef ("configs: NVMe/USB target boot devices on VisionFive 2")
> 98d17450cd4b ("starfive: visionfive2: add mmc0 and nvme boot targets")

I presume the above commits have now landed in upstream u-boot git?


> [PATCH v2] i2c: designware_i2c: adjust timing calculation
> https://lore.kernel.org/u-boot/20231013130939.19803-1-heinrich.schucha...@canonical.com/

Did this land upstream yet?

Anything else needed?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1040393: msmtp: please reintroduce SetGID permission as an optional package

[Daniel Gröber]

Hi Emannuel,

Just a ping on this issue.

I'd be happy to work on a patch and I intend to (get around to) preparing
an NMU for this issue if you don't act on it.

Thanks,
--Daniel

On Wed, Jul 05, 2023 at 01:10:58PM +0200, Daniel Gröber wrote:
> I've just upgraded my workstation to Bookworm and the upgrade broke my
> (outgoing) mail setup where I'm using msmtp due to permission errors
> involving files owned by msmtp:msmtp. I see from your NEWS entry that
> SetGID support was removed because it conflicts with passwords
> retrieved through libsecret.
> 
> Problem is in my deployment I'm not using passwords but rather TLS
> client certificates, which AFAICT the libsecret integration simply
> does not support so I cannot migrate my config to the non-setgid
> msmtp.
> 
> I'd like to request a new package, say msmtp-sysconfig, that will make
> /usr/bin/msmtp setgid again on installation. I'd be happy to provide a
> patch if you agree this is a reasonable idea.
> 
> Thanks,
> --Daniel
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-security'), (500, 
> 'stable-debug'), (500, 'proposed-updates-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages msmtp depends on:
> ii  adduser3.134
> ii  debconf [debconf-2.0]  1.5.82
> ii  libc6  2.36-9
> ii  libgnutls303.7.9-2
> ii  libgsasl18 2.2.0-1
> ii  libsecret-1-0  0.20.5-3
> ii  ucf3.0043+nmu1
> 
> Versions of packages msmtp recommends:
> ii  ca-certificates  20230311
> 
> Versions of packages msmtp suggests:
> ii  msmtp-mta  1.8.23-1
> 
> -- debconf information excluded


signature.asc
Description: PGP signature

Bug#1056160: ITS: auctex

[Hilmar Preusse]

Package: auctex
Version: 12.2-1
Severity: important

Dear Maintainer,

I intend to salvage that package as a member of the Debian TeX team and
to put it into team maintenance. I contacted Davide G. M. Salvetti two
times [1] and offered a co-maintenance, but did not get a response.

The criteria directly copied from "5.12.1. When a package is eligible
for package salvaging?"

- Bugs filed against the package do not have answers from the maintainer.

There are a few.

- Upstream has released several versions, but despite there being a bug
  entry asking for it, it has not been packaged.

https://git.savannah.gnu.org/gitweb/?p=auctex.git&view=view+git+repository

6 months agorelease_13_2| commit | shortlog | log
20 months ago   release_13_1| commit | shortlog | log
3 years ago release_12_3| commit | shortlog | log

2 Bugs requesting packaging.

- There are QA issues with the package.

Currently there is #1052909 (FTBFS bug) open since September w/o response
until now.

Regards,
  Hilmar

[1]
https://lists.debian.org/debian-tex-maint/2021/12/msg8.html
https://lists.debian.org/debian-tex-maint/2022/03/msg00037.html


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 auctex depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  emacs  1:28.2+1-15
ii  emacs-nox [emacs]  1:28.2+1-15
ii  emacsen-common 3.0.5
pn  preview-latex-style
ii  procps 2:4.0.2-3

Versions of packages auctex recommends:
ii  ghostscript10.0.0~dfsg-11+deb12u2
pn  texlive-latex-recommended  
pn  xpdf | evince | okular 

Versions of packages auctex suggests:
pn  catdvi   
pn  dvipng   
pn  lacheck  

Bug#1056159: ITP: python3-browser-cookie3 -- Python module for extracting cookies from browser

[Eduardo M KALINOWSKI]

Package: wnpp
Severity: wishlist
Owner: Eduardo M Kalinowski 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name    : python3-browser-cookie3
  Version : 0.19.1
  Upstream Contact: Boris Babic 
* URL : https://github.com/borisbabic/browser_cookie3/
* License : LGPL-3
  Programming Lang: Python
  Description : Python module for extracting cookies from browser

This module extracts cookies from a web browser (Chrome, Firefox,
LibreWolf, Opera, Opera GX, Edge, Chromium, Brave, Vivaldi, and Safari)
and stores them in a cookiejar object.

I hope to maintain this part as part of the Python team.

--
Do not flush.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Bug#1052724: u-boot: FTBFS: cc1: error: ‘-fcf-protection=full’ is not supported for this target

[Vagrant Cascadian]

On 2023-09-26, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
...
>> cc1: error: ‘-fcf-protection=full’ is not supported for this target
>> make[3]: *** [/<>/Makefile:1816: include/generated/env.in] 
>> Error 1

Because several of the qemu targets for the u-boot-qemu arch:all are
cross-built, when dpkg-buildflags enabled the hardening=+branch feature
by default, this broke some of the cross builds which do not support the
resulting -fcf-protection=full feature added to the default compiler
flags.

I have disabled this feature in git for now, although a better fix might
be preferred allowing this to be used on other targets where it did not
cause an issue.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1056151: fai-client: Diversion makes /usr/sbin/init vanish in /usr-move conditions

[Thomas Lange]

Hi Chris,

> On Fri, 17 Nov 2023 20:54:29 +0100, Chris Hofstaedtler  
> said:

> Now a problem arises, when:
> - I use a basefile tar.gz, made with an old systemd (say, it uses
>   testing as of today)
> - During baseupdate, systemd gets updated and moves its file (say, I'm
>   actually installing unstable)
Mmm, I do not know if it's possible to catch this.
Using an old system which is then updated may always cause strange
problems.

Does this problem also arises when you use a basefile from unstable?
This is the main question I have.

fai-client 5.11? I do not know this version. I guess it's some
other version.

-- 
viele Grüße Thomas

Bug#1056158: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u2

[Hilmar Preusse]

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

[ Reason ]
In Proftp 1.3.8 the buffer size for SSL communicatio set to small,
so some SFTP client connections fail, in case the "KEXINIT"
messages from both sides are too large. The patch solves the
regression, which was caused by bullseye -> bookworm upgrade.

[ Impact ]
Currently in some situations (large "KEXINIT" messages from
both sides) the SSL communication may fail.

[ Tests ]
I provided a fixed package to the bug submitter for testing.
He confirmed that his specific issue is solved. The package
itself passes the built it test suite.

[ Risks ]
Patch is trivial, there are no real functional changes, but
rather changes in buffer sizes.

[ 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

Debdiff is here 
https://release.debian.org/proposed-updates/bookworm_diffs/proftpd-dfsg_1.3.8+dfsg-4+deb12u2.debdiff

[ Changes ]
The patch extends the buffer length to do SSL computation.
In Proftp 1.3.8 the size set to small, so some SFTP client
connections fail. The patch solves the regression, which
was caused by bullseye -> bookworm upgrade.

Bug#1056157: libfalcosecurity0-dev: libsinsp.pc lists wrong libs: -lgRPC::grpc++ -lgRPC::grpc -lgRPC::gpr

[Bálint Réczey]

Source: falcosecurity-libs
Version: 0.11.3+repack-6
Severity: wishlist
Affects: wireshark

Dear Maintainer,

libsinsp.pc should list the grpc libs without the gRPC:: prefix. That
prevents configuring wireshark to build Logray.

Cheers,
Balint

Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack

[Salvatore Bonaccorso]

Source: varnish
Version: 7.1.1-1.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for varnish.

CVE-2023-44487[0]:
| The HTTP/2 protocol allows a denial of service (server resource
| consumption) because request cancellation can reset many streams
| quickly, as exploited in the wild in August through October 2023.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-44487
https://www.cve.org/CVERecord?id=CVE-2023-44487
[1] https://varnish-cache.org/security/VSV00013.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055492: appstream-generator: FTBFS with ldc 1.35

[Witold Baryluk]

Package: appstream-generator
Followup-For: Bug #1055492
X-Debbugs-Cc: witold.bary...@gmail.com

FYI.

The underlying issue was "fixed" in appstream-generator upstream and is
part of 0.9.1 release from the last week.

This was done by making rpmmd backend optional (one requiring std.xml
which was removed from Phobos).

Note however, that for 0.9.1 to compile, one might need to update some
build depdencies. And make libappstream-dev/libappstream-compose-dev to
be >= 1.0

After updating libappstream-dev and libappstream-compose-dev to 1.0 (in
experimental), I was able to build appstream-generator 0.9.1+ without
issues.

Bug#1056135: regression: hibernation issues with 255~rc2-1

[Christoph Anton Mitterer]

Control: forwarded -1 https://github.com/systemd/systemd/issues/30083

On Fri, 2023-11-17 at 13:48 +, Luca Boccassi wrote:
> Please open an issue on github and attach debug level logs showing
> the
> error


Done.

Cheers,
Chris.

Bug#1054814: criu: FTBFS: make[2]: git: No such file or directory

[Salvatore Bonaccorso]

Hi

This should be fixed with 3.18 upstream, so instread of an isolated
fix I'm rather going to do that anyway. Can hopefully tackle it soon
over the next few days.

Regards,
Salvatore

Bug#1051433: mysql-workbench: FTBFS: error: ‘int64_t’ has not been declared in ‘std’

[Sebastiaan Couwenberg]

Control: tags -1 patch

The attached patch resolves the build failure.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1diff -Nru mysql-workbench-8.0.32+dfsg/debian/changelog 
mysql-workbench-8.0.32+dfsg/debian/changelog
--- mysql-workbench-8.0.32+dfsg/debian/changelog2023-03-22 
04:10:41.0 +0100
+++ mysql-workbench-8.0.32+dfsg/debian/changelog2023-11-17 
21:08:37.0 +0100
@@ -1,3 +1,11 @@
+mysql-workbench (8.0.32+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix FTBFS with GCC 13.
+(closes: #1051433)
+
+ -- Bas Couwenberg   Fri, 17 Nov 2023 21:08:37 +0100
+
 mysql-workbench (8.0.32+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mysql-workbench-8.0.32+dfsg/debian/patches/gcc-13.patch 
mysql-workbench-8.0.32+dfsg/debian/patches/gcc-13.patch
--- mysql-workbench-8.0.32+dfsg/debian/patches/gcc-13.patch 1970-01-01 
01:00:00.0 +0100
+++ mysql-workbench-8.0.32+dfsg/debian/patches/gcc-13.patch 2023-11-17 
21:08:37.0 +0100
@@ -0,0 +1,69 @@
+Description: Include  for int64_t.
+ Per https://gcc.gnu.org/gcc-13/porting_to.html
+Author: Bas Couwenberg 
+
+--- a/library/base/base/util_functions.h
 b/library/base/base/util_functions.h
+@@ -53,6 +53,8 @@
+ #define BASE_PATH_SEPARATOR_STR "/"
+ #endif
+ 
++#include 
++
+ #define BASE_ORDPTR(value) ((void *)(unsigned long)(value))
+ 
+ // TODO: move Windows specific stuff to base.windows library.
+--- a/library/cdbc/src/driver_manager.h
 b/library/cdbc/src/driver_manager.h
+@@ -33,6 +33,8 @@
+ #include "grts/structs.db.mgmt.h"
+ #include 
+ 
++#include 
++
+ namespace wb {
+   class SSHTunnel;
+ }
+--- a/library/base/base/string_utilities.h
 b/library/base/base/string_utilities.h
+@@ -43,6 +43,8 @@
+ #include 
+ #include 
+ 
++#include 
++
+ #define _(s) s // TODO: replace with localization code.
+ 
+ using std::int64_t;
+--- a/library/base/base/utf8string.h
 b/library/base/base/utf8string.h
+@@ -30,6 +30,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ namespace base {
+   /**
+--- a/library/forms/mforms/treeview.h
 b/library/forms/mforms/treeview.h
+@@ -25,6 +25,8 @@
+ 
+ #include 
+ 
++#include 
++
+ /**
+  * Implementation of a control class for a treeview control based on node 
objects.
+  */
+--- a/backend/wbpublic/sqlide/sqlide_generics_private.h
 b/backend/wbpublic/sqlide/sqlide_generics_private.h
+@@ -31,6 +31,8 @@
+ #include 
+ #include 
+ 
++#include 
++
+ namespace sqlide {
+ 
+   using namespace sqlite;
diff -Nru mysql-workbench-8.0.32+dfsg/debian/patches/series 
mysql-workbench-8.0.32+dfsg/debian/patches/series
--- mysql-workbench-8.0.32+dfsg/debian/patches/series   2021-05-31 
14:24:05.0 +0200
+++ mysql-workbench-8.0.32+dfsg/debian/patches/series   2023-11-17 
21:04:08.0 +0100
@@ -10,3 +10,4 @@
 specify-char-signedness.patch
 un-mysql.patch
 #~wbcopytables-rpath.patch
+gcc-13.patch
diff -Nru mysql-workbench-8.0.32+dfsg/debian/rules 
mysql-workbench-8.0.32+dfsg/debian/rules
--- mysql-workbench-8.0.32+dfsg/debian/rules2023-03-22 03:56:22.0 
+0100
+++ mysql-workbench-8.0.32+dfsg/debian/rules2023-11-17 21:08:37.0 
+0100
@@ -9,7 +9,7 @@
 ## "bindnow" causes run-time errors:
 #export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
 
-export DEB_CPPFLAGS_MAINT_APPEND= -Wno-error=deprecated-declarations 
-Wno-error=maybe-uninitialized
+export DEB_CPPFLAGS_MAINT_APPEND= -Wno-error=deprecated-declarations 
-Wno-error=maybe-uninitialized -Wno-error=c++20-compat 
-Wno-error=overloaded-virtual=
 # -Wno-error=deprecated-copy -Wno-error=format-overflow=
 # -std=c++11
 

Bug#1056153: 6.1.0-0.deb11.9-amd64: Linux version 6.1.0-0.deb11.9-amd64 booting to black screen, but 6.1.0-0.deb11.7-amd64 works

[Salvatore Bonaccorso]

Hi,

On Fri, Nov 17, 2023 at 09:47:42PM +0100, Rud wrote:
> Package: 6.1.0-0.deb11.9-amd64
> Version: Linux version 6.1.0-0.deb11.9-amd64
> Severity: critical
> Tags: a11y
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Upgrading to Kernel Linux 6.1.0-0.deb11.9-amd64
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Booting with Kernel Linux 6.1.0-0.deb11.7-amd64 still works and the system 
> runs stable.
> I compared the kernel config files without finding any particular differences.
> I compared the boot log of both kernels without finding any particular 
> differences, except this:
> Both boot logs shows this error:
> mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: a6020408
> mce: [Hardware Error]: TSC 0 ADDR fef13bc0
> mce: [Hardware Error]: PROCESSOR 0:506ca TIME 1700060631 SOCKET 0 APIC 0 
> microcode 28
> The board is brand new and has been replaced twice, always with the same 
> error message.
> 
>* What was the outcome of this action?
> I found no evidence of an error in the boot log or differences in the config 
> file
> 
>* What outcome did you expect instead?
> Helpful errors or config parameter

As this is not the most recent kernel in backports, can you please try
with the recent one? Ideally test please version up to 6.1.55 current
in bookworm itself.

Regards,
Salvatore

Bug#1056155: ITP: ruby-binding-of-caller -- Ruby gem to retrieve the binding of a method's caller

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist

* Package name: ruby-binding-of-caller
  Version: 1.0.0
  Upstream Author: John Mair (banisterfiend)
* URL: https://github.com/banister/binding_of_caller
* License: Expat
  Programming Lang: Ruby
  Description: Ruby gem to retrieve the binding of a method's caller

 Retrieve the binding of a method's caller in MRI (>= 2.0.0) and RBX 
(Rubinius).

 .
 The binding_of_caller gem provides the Binding#of_caller method.
 .
 Using binding_of_caller we can grab bindings from higher up the call 
stack and
 evaluate code in that context. Allows access to bindings arbitrarily 
far up the

 call stack, not limited to just the immediate caller.
 .
 Recommended for use only in debugging situations. Do not use this in
 production apps.

This package is needed by the src:ruby-rspec-parameterized-table-syntax 
which will fix a FTBFS against ruby 3.2. It will be maintained under the 
Ruby team's umbrella.


--
Lucas Kanashiro

Bug#1056154: ITP: ruby-rspec-parameterized-table-syntax -- Simple parameterized test syntax for RSpec - table_syntax

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist

* Package name: ruby-rspec-parameterized-table-syntax
  Version: 1.0.1
  Upstream Author: sue445 
* URL: 
https://github.com/rspec-parameterized/rspec-parameterized-table_syntax

* License: Expat
  Programming Lang: Ruby
  Description: Simple parameterized test syntax for RSpec - table_syntax

 RSpec::Parameterized supports simple parameterized test syntax in rspec.
 .
 This is the table_syntax gem to support rspec-parameterized.

This package is needed by the src:ruby-rspec-parameterized latest 
upstream version which will fix a FTBFS against ruby 3.2. It will be 
maintained under the Ruby team's umbrella.


--
Lucas Kanashiro

Bug#1042844: elinks: diff for NMU version 0.16.1.1-4.1

[gregor herrmann]

Control: tags 1042844 + patch
Control: tags 1042844 + pending


Dear maintainer,

I've prepared an NMU for elinks (versioned as 0.16.1.1-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru elinks-0.16.1.1/debian/changelog elinks-0.16.1.1/debian/changelog
--- elinks-0.16.1.1/debian/changelog	2023-06-30 03:01:41.0 +0200
+++ elinks-0.16.1.1/debian/changelog	2023-11-17 21:39:04.0 +0100
@@ -1,3 +1,12 @@
+elinks (0.16.1.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS with Perl 5.38: error: redefinition of 'struct object'":
+add patch from upstream pull request/commit.
+(Closes: #1042844)
+
+ -- gregor herrmann   Fri, 17 Nov 2023 21:39:04 +0100
+
 elinks (0.16.1.1-4) unstable; urgency=medium
 
   [ Pino Toscano ]
diff -Nru elinks-0.16.1.1/debian/patches/perl_5.38.patch elinks-0.16.1.1/debian/patches/perl_5.38.patch
--- elinks-0.16.1.1/debian/patches/perl_5.38.patch	1970-01-01 01:00:00.0 +0100
+++ elinks-0.16.1.1/debian/patches/perl_5.38.patch	2023-11-17 21:38:58.0 +0100
@@ -0,0 +1,64 @@
+From 393bf23a2683971a72217839657bb2945a36ee54 Mon Sep 17 00:00:00 2001
+From: "Azamat H. Hackimov" 
+Date: Mon, 3 Jul 2023 14:12:22 +0300
+Subject: [PATCH] Fix compilation with Perl 5.38
+
+Perl now includes own `struct object` which clashes with elinks
+implementation. Renamed `struct object` to `struct elinks_object` to
+avoid it.
+
+Bug-Gentoo: https://bugs.gentoo.org/909042
+Bug-Debian: https://bugs.debian.org/1042844
+Bug: https://github.com/rkd77/elinks/pull/243
+---
+ src/main/object.h  | 6 +++---
+ src/protocol/uri.c | 2 +-
+ src/protocol/uri.h | 2 +-
+ 3 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/src/main/object.h
 b/src/main/object.h
+@@ -11,7 +11,7 @@
+ #define DEBUG_REFCOUNT
+ #endif
+ 
+-struct object {
++struct elinks_object {
+ 	int refcount;
+ #ifdef CONFIG_DEBUG
+ 	char *name;
+@@ -20,10 +20,10 @@
+ 
+ #define OBJECT_HEAD(type)		\
+ 	LIST_HEAD(type);		\
+-	struct object object
++	struct elinks_object object
+ 
+ struct object_head {
+-	OBJECT_HEAD(struct object *);
++	OBJECT_HEAD(struct elinks_object *);
+ };
+ 
+ #ifdef DEBUG_REFCOUNT
+--- a/src/protocol/uri.c
 b/src/protocol/uri.c
+@@ -1578,7 +1578,7 @@
+ 
+ struct uri_cache {
+ 	struct hash *map;
+-	struct object object;
++	struct elinks_object object;
+ };
+ 
+ static struct uri_cache uri_cache;
+--- a/src/protocol/uri.h
 b/src/protocol/uri.h
+@@ -89,7 +89,7 @@
+ 	unsigned int form:1;	/* URI originated from form */
+ 
+ 	/* Usage count object. */
+-	struct object object;
++	struct elinks_object object;
+ };
+ 
+ enum uri_errno {
diff -Nru elinks-0.16.1.1/debian/patches/series elinks-0.16.1.1/debian/patches/series
--- elinks-0.16.1.1/debian/patches/series	2023-06-30 03:01:41.0 +0200
+++ elinks-0.16.1.1/debian/patches/series	2023-11-17 21:35:59.0 +0100
@@ -3,3 +3,4 @@
 07_617713_cache_control.diff
 14_debug_disable_Werror.diff
 fix-mailcap-test.diff
+perl_5.38.patch


signature.asc
Description: Digital Signature

Bug#1056153: 6.1.0-0.deb11.9-amd64: Linux version 6.1.0-0.deb11.9-amd64 booting to black screen, but 6.1.0-0.deb11.7-amd64 works

[Rud]

Package: 6.1.0-0.deb11.9-amd64
Version: Linux version 6.1.0-0.deb11.9-amd64
Severity: critical
Tags: a11y
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation?
Upgrading to Kernel Linux 6.1.0-0.deb11.9-amd64

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Booting with Kernel Linux 6.1.0-0.deb11.7-amd64 still works and the system runs 
stable.
I compared the kernel config files without finding any particular differences.
I compared the boot log of both kernels without finding any particular 
differences, except this:
Both boot logs shows this error:
mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: a6020408
mce: [Hardware Error]: TSC 0 ADDR fef13bc0
mce: [Hardware Error]: PROCESSOR 0:506ca TIME 1700060631 SOCKET 0 APIC 0 
microcode 28
The board is brand new and has been replaced twice, always with the same error 
message.

   * What was the outcome of this action?
I found no evidence of an error in the boot log or differences in the config 
file

   * What outcome did you expect instead?
Helpful errors or config parameter

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.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 6.1.0-0.deb11.9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages 6.1.0-0.deb11.9-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages 6.1.0-0.deb11.9-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-3~deb11u6
pn  linux-doc-6.1   

Bug#1056152: ITP: ruby-rspec-parameterized-core -- Simple parameterized test syntax for RSpec

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist

* Package name: ruby-rspec-parameterized-core
  Version: 1.0.0
  Upstream Author: sue445 
* URL: https://github.com/rspec-parameterized/rspec-parameterized-core
* License: Expat
  Programming Lang: Ruby
  Description: Simple parameterized test syntax for RSpec

 RSpec::Parameterized supports simple parameterized test syntax in rspec.

This package is needed by the src:ruby-rspec-parameterized latest 
upstream version which will fix a FTBFS against ruby 3.2. It will be 
maintained under the Ruby team's umbrella.

Bug#1050633: wireshark: Downgrade to lua5.1

[Bálint Réczey]

Control: tags -1 confirmed wontfix

Hi Bastian,

While I agree with dropping obsolete libraries and old interpreters
from the archive after some time, I'm sorry, but I can't downgrade
Wireshark to Lua 5.1 because that would break users' Lua scripts.
That's a problem for RHEL already:
https://blog.4loeser.net/2021/05/wireshark-with-lua-on-rhel-centos.html

Please keep Lua 5.1 in the archive until Wireshark upstream moves to a
later version.
It is under discussion for years, but eventually will happen, I think.
See:
https://www.wireshark.org/lists/wireshark-dev/202205/msg00022.html
and:
https://gitlab.com/wireshark/wireshark/-/issues/10881

Thanks,
Balint

Bastian Germann  ezt írta (időpont: 2023. aug. 27., V, 13:01):
>
> Source: wireshark
> Severity: wishlist
> Version: 4.0.8-1
>
> Please build your package with lua5.1 so we can drop v5.2 from the archive.
> The build system supports it as fallback but you can certainly also try 
> patching to a more up to date lua version.

Bug#1042525: localehelper: diff for NMU version 0.1.4-3.1

[gregor herrmann]

Control: tags 1042525 + patch
Control: tags 1042525 + pending


Dear maintainer,

I've prepared an NMU for localehelper (versioned as 0.1.4-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru localehelper-0.1.4/debian/changelog localehelper-0.1.4/debian/changelog
--- localehelper-0.1.4/debian/changelog	2017-10-18 22:55:23.0 +0200
+++ localehelper-0.1.4/debian/changelog	2023-11-17 21:19:05.0 +0100
@@ -1,3 +1,12 @@
+localehelper (0.1.4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS with Perl 5.38: t/help.t failure": add patch from two upstream
+commits to replace given/when with plain if's.
+(Closes: #1042525)
+
+ -- gregor herrmann   Fri, 17 Nov 2023 21:19:05 +0100
+
 localehelper (0.1.4-3) unstable; urgency=medium
 
   * Updated priority to optional due to extra being deprecated
diff -Nru localehelper-0.1.4/debian/patches/given_when.patch localehelper-0.1.4/debian/patches/given_when.patch
--- localehelper-0.1.4/debian/patches/given_when.patch	1970-01-01 01:00:00.0 +0100
+++ localehelper-0.1.4/debian/patches/given_when.patch	2023-11-17 21:18:57.0 +0100
@@ -0,0 +1,98 @@
+From af9dabda61314d79500824bcea888efcfabbc2a2 Mon Sep 17 00:00:00 2001
+From: Jakub Wilk 
+Date: Thu, 24 Aug 2023 21:32:31 +0200
+Subject: [PATCH] Stop using switch statements.
+
+Fixes:
+
+given is deprecated at .../localehelper line 153.
+when is deprecated at .../localehelper line 154.
+when is deprecated at .../localehelper line 159.
+when is deprecated at .../localehelper line 167.
+when is deprecated at .../localehelper line 171.
+
+https://bugs.debian.org/1042525
+---
+ localehelper | 46 +-
+ 1 file changed, 21 insertions(+), 25 deletions(-)
+
+
+
+From ef6ca54a5b570bda80c12094355439e4f68f3722 Mon Sep 17 00:00:00 2001
+From: Jakub Wilk 
+Date: Mon, 28 Aug 2023 13:39:26 +0200
+Subject: [PATCH] Fix arg parsing control flow.
+
+Fixes: commit af9dabda61314d79500824bcea888efcfabbc2a2
+---
+ localehelper | 2 ++
+ 1 file changed, 2 insertions(+)
+
+
+--- a/localehelper
 b/localehelper
+@@ -30,7 +30,6 @@
+ use warnings;
+ 
+ use v5.10;
+-no if $] >= 5.018, warnings => 'experimental::smartmatch';
+ 
+ # cwd in @INC is harmful:
+ # http://www.nntp.perl.org/group/perl.perl5.porters/2010/08/msg162729.html
+@@ -150,32 +149,31 @@
+ my @extra_locales = ();
+ my %env = ();
+ while (scalar(@ARGV) > 0) {
+-given ($ARGV[0]) {
+-when (m/^($category_re)=(.*)$/) {
+-my ($category, $locale) = ($1, $2);
+-$env{$category} = $locale;
+-shift @ARGV;
+-}
+-when ('-x') {
+-shift @ARGV;
+-if (not @ARGV) {
+-diag('error: -x requires an argument');
+-exit 1;
+-}
+-push @extra_locales, split(m/,/, shift @ARGV);
+-}
+-when (['-h', '--help']) {
+-show_usage();
+-exit 0;
+-}
+-when ('--') {
+-shift @ARGV;
+-last;
+-}
+-default {
+-last;
+-}
++$_ = $ARGV[0];
++if (m/^($category_re)=(.*)$/) {
++my ($category, $locale) = ($1, $2);
++$env{$category} = $locale;
++shift @ARGV;
++next;
++}
++if ($_ eq '-x') {
++shift @ARGV;
++if (not @ARGV) {
++diag('error: -x requires an argument');
++exit 1;
++}
++push @extra_locales, split(m/,/, shift @ARGV);
++next;
++}
++if ($_ eq '-h' or $_ eq '--help') {
++show_usage();
++exit 0;
++}
++if ($_ eq '--') {
++shift @ARGV;
++last;
+ }
++last;
+ }
+ 
+ if (not @ARGV) {
diff -Nru localehelper-0.1.4/debian/patches/series localehelper-0.1.4/debian/patches/series
--- localehelper-0.1.4/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ localehelper-0.1.4/debian/patches/series	2023-11-17 21:17:21.0 +0100
@@ -0,0 +1 @@
+given_when.patch


signature.asc
Description: Digital Signature

Bug#1056151: fai-client: Diversion makes /usr/sbin/init vanish in /usr-move conditions

[Chris Hofstaedtler]

Package: fai-client
Version: 5.11
Severity: important
X-Debbugs-Cc: m...@grml.org

Hello Thomas,

you will have noticed that systemd 255 moves its files from / to /usr.
This includes /sbin/init.

Now a problem arises, when:
- I use a basefile tar.gz, made with an old systemd (say, it uses
  testing as of today)
- During baseupdate, systemd gets updated and moves its file (say, I'm
  actually installing unstable)

What happens is this:
- base image gets unpacked, /sbin is a symlink to /usr/sbin,
  /sbin/init is actually /usr/sbin/init
- baseupdate diverts /sbin/init to /sbin/init.distrib (and using
  symlinks, /usr/sbin/init became /usr/sbin/init.distrib)
- baseupdate updates systemd, dpkg 'moves' /sbin/init to /usr/sbin/init,
  but the divert stays in place for /sbin/init.
  At this time, dpkg will have overwritten /usr/sbin/init with the new
  file(!)
- fai-divert -R runs, removes /sbin/init, and removes the divert of
  /sbin/init.
  But: at this point /sbin/init was already the new /usr/sbin/init,
  which is now lost.

As a result /usr/sbin/init is missing, and the system does not boot.

I would suggest dropping all the fai-divert calls in baseupdate.

Chris

Bug#1056150: RFS: python-opem/1.3-1 [ITP] -- Open-Source PEMFC Simulation Tool

[Yogeswaran Umasankar]

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

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-opem":

 * Package name : python-opem
   Version  : 1.3-1
   Upstream contact : Sepand Haghighi 
 * URL  : https://github.com/ECSIM/opem
 * License  : Expat
 * Vcs  : https://salsa.debian.org/yogu/python-opem
   Section  : python

The source builds the following binary packages:

  python3-opem - Open-Source PEMFC Simulation Tool

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

  https://mentors.debian.net/package/python-opem/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-opem/python-opem_1.3-1.dsc

Changes for the initial release:

 python-opem (1.3-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1056148)

Regards,
-- 
  Yogeswaran Umasankar

Bug#1056149: vlc: fail to play some certain .mp4 videos: segmentation fault

[Yurui Hong]

Package: vlc
Version: 3.0.20-1+b1
Severity: important
X-Debbugs-Cc: yuruihon...@outlook.com

Dear Maintainer,

The recent vlc version 3.0.20-1+b1 in Debian unstable fails to play some 
certain .mp4 videos, while the previous version 3.0.20-1 works well. The error 
message is segmentation fault, but I am unable to get a backtrace because I am 
not familiar with gdb. The difference between the playable and unplayable 
videos is that the unplayable ones are streamed from a website and captured by 
a Firefox Add-on called Video DownloadHelper.


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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.20-1+b1
ii  vlc-plugin-base  3.0.20-1+b1
ii  vlc-plugin-qt3.0.20-1+b1
ii  vlc-plugin-video-output  3.0.20-1+b1

Versions of packages vlc recommends:
pn  vlc-l10n   
pn  vlc-plugin-access-extra
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
pn  vlc-plugin-skins2  
pn  vlc-plugin-video-splitter  
pn  vlc-plugin-visualization   

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
pn  vlc-plugin-jack
pn  vlc-plugin-pipewire
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.37-12
ii  libvlc5  3.0.20-1+b1

Versions of packages libvlc5 depends on:
ii  libc62.37-12
ii  libvlccore9  3.0.20-1+b1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.20-1+b1

Versions of packages vlc-bin depends on:
ii  libc6   2.37-12
ii  libvlc-bin  3.0.20-1+b1
ii  libvlc5 3.0.20-1+b1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.7.2-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.10-1
ii  libass9  1:0.17.1-1
ii  libavahi-client3 0.8-13
ii  libavahi-common3 0.8-13
ii  libavc1394-0 0.5.4-5
ii  libavcodec60 7:6.1-2
ii  libavformat607:6.1-2
ii  libavutil58  7:6.1-2
ii  libbluray2   1:1.3.4-1
ii  libc62.37-12
ii  libcairo21.18.0-1
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-4
ii  libdav1d71.3.0-2
ii  libdbus-1-3  1.14.10-3
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.3-1
ii  libebml5 1.4.4-1
ii  libfaad2 2.11.1-1
ii  libflac121.4.3+ds-2
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libfribidi0  1.0.13-3
ii  libgcc-s113.2.0-6
ii  libgcrypt20  1.10.2-3
ii  libglib2.0-0 2.78.1-4
ii  libgnutls30  3.8.1-4+b1
ii  libgpg-error01.47-2
ii  libharfbuzz0b8.0.1-1
ii  libixml111:1.14.18-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-7.2
ii  liblua5.2-0  5.2.4.1-1+rebuild
ii  libmad0  0.15.1b-10.1+b1
ii  libmatroska7 1.7.1-1
ii  libmpcdec6   2:0.1.1-1+rebuild
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.32.3-1
ii  libmtp9  1.1.21-1
ii  libncursesw6 6.4+20231016-1
ii  libnfs14 5.0.2-1
ii  libogg0  1.3.5-3
ii  libopenmpt-modplug1  0.8.9.0-openmpt1-2+b1
ii  libopus0 1.4-1
ii  libpng16-16  1.6.40-2
ii  libpostproc577:6.1-2
ii  libprotobuf-lite32   3.21.12-8
ii  libpulse016.1+dfsg1-2+b1
ii  libraw1394-112.1.2-2
ii  libresid-builder0c2a 2.1.1-15+b1
ii 

Bug#1056148: ITP: python-opem -- Open-Source PEMFC Simulation Tool

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-opem
  Version : 1.3
  Upstream Contact: Sepand Haghighi 
* URL : https://github.com/ECSIM/opem
* License : Expat
  Programming Lang: Python
  Description : Open-Source PEMFC Simulation Tool

OPEM is a modeling tool
 for evaluating the performance of proton exchange membrane fuel cells.
 This package is a combination of models (static/dynamic) that predict
 the optimum operating parameters of PEMFC. OPEM contained generic
 models that will accept as input, not only values of the operating
 variables such as anode and cathode feed gas, pressure and
 compositions, cell temperature and current density, but also cell
 parameters including the active area and membrane thickness. OPEM is a
 platform for collaborative development of PEMFC models.

Bug#1055101: Remove moreinfo tag

[Daniel Fancsali]

Control: tag - moreinfo

Thanks for the review Tobias.

Well, that happens if you put something on the back-burner for some 
time. ;)


I do apologise...

All should be fixed now.

Cheers,
Daniel

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

[Dirk Eddelbuettel]

On 14 November 2023 at 07:42, Dirk Eddelbuettel wrote:
| 
| On 14 November 2023 at 12:26, Graham Inggs wrote:
| | Hi Dirk
| | 
| | On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel  wrote:
| | > Well that seems to be a) the wrong severity and b) the wrong package.
| | 
| | Both are correct.  We do not want rmatrix to migrate and break
| | packages in testing.
| 
| Doesn't 'normal' do that? I always get the shivers when I see 'serious' as I
| fear that my package is at the risk of removal (which we of course Matrix
| can't be 'really' given its systemic status from its "recommended" status
| within R and very widespread use).
| 
| | However, in this case, I only set the severity to match reality;
| | rmatrix is already blocked from migrating due to the autopkgtest
| | regressions.
| | 
| | > We need to address the packages needing a rebuild. Mine (r-cran-lme4,
| | > r-cran-rcppeigen).  have been taken care of.
| | 
| | Agreed, and rmatrix may need some new Breaks to allow the affected
| | packages to migrate together.
| 
| The issue is actually hugely problematic for CRAN and R Core, and there are
| some discussions but no solutions. They do not have (formal) notions like
| binary rebuild for parts where they distribute binaries, and no means of
| reaching binary redistributors such as us. Oh well.  At least it doesn't
| happen often.
| 
| Anyway. Now that you made it a bug I let you drive this.  Upstream just made
| an unrelated bugfix Matrix 1.6-3 which I just sent to unstable.

There are two known failures left which the maintainer(s) do not want to fix.

As I have fixed my dependents of package Matrix, I continue to find it unfair
that I am being to an open bug requiring fixes via builds in other packages
that are not mine. So I guess this bug will stay open 'forever' or
until those packages get normal routine updates.

Dirk

| 
| Dirk
| 
| -- 
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1042646: dh-virtualenv: FTBFS with Sphinx 7.1, docutils 0.20: error: invalid command 'build_sphinx'

[Uwe Kleine-König]

On Sun, Jul 30, 2023 at 08:22:59PM +0200, Lucas Nussbaum wrote:
> Source: dh-virtualenv
> Version: 1.2.2-1.3
> Severity: important
> Tags: ftbfs
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: sphinx7.1
> 
> Hi,
> 
> dh-virtualenv fails to build with Sphinx 7.1 and docutils 0.20, both of which
> are currently available in experimental.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > python3 setup.py build_sphinx
> > usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
> >or: setup.py --help [cmd1 cmd2 ...]
> >or: setup.py --help-commands
> >or: setup.py cmd --help
> > 
> > error: invalid command 'build_sphinx'
> > make[1]: *** [debian/rules:28: override_dh_installdocs] Error 1

This bug resulted in dh-virtualenv being dropped from trixie.

The easy workaround is to drop the sphinx documentation.

The following debdiff makes the package build again:

dpkg-source: warning: extracting unsigned source package 
(/home/uwe/debsrc/dh-virtualenv_1.2.2-1.4.dsc)
diff -Nru dh-virtualenv-1.2.2/debian/changelog 
dh-virtualenv-1.2.2/debian/changelog
--- dh-virtualenv-1.2.2/debian/changelog2023-02-02 20:10:21.0 
+0100
+++ dh-virtualenv-1.2.2/debian/changelog2023-11-17 19:40:18.0 
+0100
@@ -1,3 +1,10 @@
+dh-virtualenv (1.2.2-1.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Sphinx docs (Closes: #1042646)
+
+ -- Uwe Kleine-König   Fri, 17 Nov 2023 19:40:18 +0100
+
 dh-virtualenv (1.2.2-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dh-virtualenv-1.2.2/debian/control dh-virtualenv-1.2.2/debian/control
--- dh-virtualenv-1.2.2/debian/control  2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/control  2023-11-17 19:40:18.0 +0100
@@ -3,25 +3,16 @@
 Priority: optional
 Maintainer: Jyrki Pulliainen 
 Build-Depends: debhelper-compat (= 12), python3,
- python3-setuptools, python3-sphinx, python3-mock, dh-exec,
+ python3-setuptools, python3-mock, dh-exec,
  dh-python, libjs-jquery, libjs-underscore,
-# python-sphinx-rtd-theme doesn't exist in distributions
-# predating Debian Jessie and Ubuntu Xenial. On these legacy
-# systems:
-# 1. Comment the dependency below.
-# 2. pip install sphinx_rtd_theme.
-# 3. Proceed with your build process (typically dpkg-build).
-# See https://github.com/spotify/dh-virtualenv/issues/230
- python3-sphinx-rtd-theme
 Standards-Version: 4.5.0
 Homepage: https://www.github.com/spotify/dh-virtualenv
 Rules-Requires-Root: no
 
 Package: dh-virtualenv
 Architecture: all
-Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends}, 
${sphinxdoc:Depends},
+Depends: ${python3:Depends}, ${perl:Depends}, ${misc:Depends},
  virtualenv | python3-virtualenv (>= 1.7) | python${pyversion}-venv
-Built-Using: ${sphinxdoc:Built-Using}
 Description: wrap and build Python packages using virtualenv
  This package provides a dh sequencer that helps you to deploy your
  virtualenv wrapped installation inside a Debian package.
diff -Nru dh-virtualenv-1.2.2/debian/rules dh-virtualenv-1.2.2/debian/rules
--- dh-virtualenv-1.2.2/debian/rules2022-08-25 21:00:57.0 +0200
+++ dh-virtualenv-1.2.2/debian/rules2023-11-17 19:39:38.0 +0100
@@ -22,9 +22,3 @@
 
 override_dh_gencontrol:
dh_gencontrol -- -Vpyversion=$(PYTHON_VERSION)
-
-ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
-override_dh_installdocs:
-   python3 setup.py build_sphinx
-   dh_installdocs doc/_build/html
-endif

I intend to nmu this package in a week from now with the above changes.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#1056146: xsok possibly contains non-DFSG-free data files

[Ivan Shmakov]

Source: xsok
Version: 1.02-19
Severity: serious
Justification: possible DFSG violation

[Please do not Cc: me, as I’m “on the list,” so to say, and
I prefer to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]

The xsok debian/copyright file seems to suggest that xsok
was created solely by Michael Bischoff:

$ tar --xz -xO -- debian/copyright < xsok_1.02-19.debian.tar.xz 
This is Debian GNU/Linux's prepackaged version of xsok.
xsok was written by Michael Bischoff .

The upstream source was downloaded from
ftp://ftp.io.com/pub/mirror/FreeBSD/ports/distfiles/xsok-1.02-src.tar.gz

The current Debian maintainer is Peter Samuelson .
Much of the packaging work was done by previous Debian maintainers
Sven Rudolph and Joel Rosdahl.

Copyright (c) 1994 by Michael Bischoff (m...@mo.math.nat.tu-bs.de)

[GNU GPL 2+ notice follows.]

There’re two issues with this.  First, xsok includes
doc/cyberbox.doc, authored by Doug Beeferman (I presume
lib/Cyberbox/ files are also derivatives rather than
original xsok work.)  The .doc file (quoted below) appears
to allow verbatim redistribution of the respective game,
but there’s no indication that ‘modifications and derived
works’ are allowed (as DFSG requires) as well:

S O R T A F R E E W A R E   N O T I C E

This game can be distributed freely and played free of charge.  If you like
it, however, I wouldn't mind a small donation for the effort I put into
writing the program and (ughh!) in making the levels.  I say "ughh!" because
making the levels was by far the more time-consuming of the two projects.

Neither is there any such indication on http://dougb.com/ .
(I intend to contact the author of Cyberbox shortly to comment
on this issue and (or) possibly re-release at least the
portions of xsok derived from the original game in DFSG-
compliant fashion.)

Worse still, the ‘screens’ (= maps, levels) included in
lib/Sokoban/ appear to mostly come from the original,
proprietary version(s) of Soko-Ban.  Consider, e. g.:

http://web.archive.org/web/2023/https://www.mobygames.com/game/1715/soko-ban/

http://web.archive.org/web/20230407165659im_/https://cdn.mobygames.com/8e54fc3c-bee0-11ed-9c42-02420a000140.webp
http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/0b7522d4-c204-11ed-ab6b-02420a000194.webp

The first Soko-Ban screen, identical to lib/Sokoban/screen.01 .

http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/058c7f98-ab6b-11ed-aaf5-02420a00019c.webp

The second Soko-Ban screen, identical to lib/Sokoban/screen.02 .

Moreover, taking a look at an earlier curses-based implementation
of the game from [1], which (according to its README.v2, as
quoted below) borrows screens from ‘the PC-version’, we find
out that likely /all/ levels from 1 to 50 inclusive are taken
from other software, while several other levels (86‒88) are
derived from the same.

I’m not aware of any evidence to suggest that the original
Soko-Ban might be out of copyright or ever released as free
software, from whence I conclude it’s likely proprietary,
including the level designs.

The first thing I have to say is that I don't have the sources for SOKOBAN
under MS-DOS. I believe that this program is copyrighted. I took only the
idea and the screens of the PC-version.

[1] http://ibiblio.org/pub/linux/games/strategy/sokoban-src.tar.gz

bash$ diff -dbuF^\; -- \
  <((tar -zxOv --wildcards -- \*/screen.\?   < sokoban-src.tar.gz ; \
 tar -zxOv --wildcards -- \*/screen.\?\? < sokoban-src.tar.gz) \
2>&1 | sed -e "s,^sokoban.*\\.,;LEVEL ,;") \
  share/games/xsok/Sokoban.def | head -n23 
--- /dev/fd/63
+++ share/games/xsok/Sokoban.def2019-01-05 12:10:54 +
@@ -1,3 +1,14 @@
+;WALLS
+12 f f   ff  0   standard floor
+.   13 f f   ff  4   target field
+#0 0 00  0   walls
+
+;OBJECTS
+@0   f   0101   2011 0 player
+$1   f   0100 02  1000 heavy box
+
+;MAXLEVEL 88
+;ATOP *$.
 ;LEVEL 1
 #
 #   #
@@ -759,3 +770,521 @@ ;LEVEL 50
   #  ###   ## #
   #  #  ###
     ##
+;LEVEL 51
+#

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1056147: midge possibly contains non-DFSG-free examples

[Ivan Shmakov]

Source: midge
Version: 0.2.41-4
Severity: serious
Justification: possible DFSG violation

[Please do not Cc: me, as I’m “on the list,” so to say, and
I prefer to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]

The source currently contains a number of covers/*.mg files
that are, so far as I can tell, derivatives of songs for
which there’re no indication of being out of copyright or
ever released under a DFSG-compliant license.  In particular,
a cursory look at Wikipedia articles (below) do not seem to
mention anything related to possible free culture status of
the songs transcribed in paranoid.mg & wish_you_were_here.mg.

http://en.wikipedia.org/wiki/Paranoid_(Black_Sabbath_album)
http://en.wikipedia.org/wiki/Wish_You_Were_Here_(Pink_Floyd_song)

I believe the source needs to be repackaged so to exclude
the examples/covers/ directory entirely.

-- 
FSF associate member #7257  np. The Last Refugee — Roger Waters

Bug#1056145: e2fsprogs: FTBFS on hurd-i386

[Svante Signell]

Source: e2fsprogs
Version: 1.47.0-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

e2fsprogs FTBFS on hurd-i386 due to usage of PATH_MAX which is not defined on
GNU/Hurd. (Built in the past, last successful build was 1.46.6-1)

A patch enabling a successful build on GNU/Hurd is attached:
misc_tune2fs.c.diff

I chose to submit this patch to Debian instead of upstream as recommended. The
upstream reports seemed to be a little dated:
https://sourceforge.net/projects/e2fsprogs/ However, that page has the latest
version available for download.

Regarding the patch it is a very simple ifdef solution to that specific file. As
can be found in other parts of the code similar definitions are made. Maybe a
common header file defining PATH_MAX would be a better solution. (or dynamically
allocating space for strings as is recommended for GNU/Hurd) 

Thanks!








--- a/misc/tune2fs.c	2023-02-07 04:31:53.0 +0100
+++ b/misc/tune2fs.c	2023-11-17 16:09:42.0 +0100
@@ -3159,6 +3159,9 @@
 int tune2fs_main(int argc, char **argv)
 #endif  /* BUILD_AS_LIB */
 {
+#ifndef MATH_MAX
+#define PATH_MAX 4096
+#endif
 	errcode_t retval;
 	ext2_filsys fs;
 	struct ext2_super_block *sb;

Bug#734401: postfix

[joeDoe]

I'm still not sure if my experiences with postfix on Freedombox are related.
However, no one has told me that my last message was noise. So, I will just
add that the same thing has happened again: postfix's main.cf was
overwritten somehow and didn't include my domainname in it anymore.

The result was valid incoming mail to my domain was being rejected with the
error code 454 4.7.1 and the message Relay access denied. "ls -lAF" dated
main.cf at November 11.

According to the apt logs, freedombox, freedombox-doc-en and
freedombox-doc-es were updated on November 11.

Bug#1056104: libreoffice: please enable ENABLE_WASM_STRIP_PINGUSER

[Rene Engelhard]

severity 1056104 wishlist

thanks

Am 16.11.23 um 23:52 schrieb Cyril Brulebois:

LibreOffice features a prompt that pops up every now and then, asking
users to get involved or to donate. I'm not sure asking repeatedly is
reasonable,


Not sure.

We need people who care about portability. upstream definitely does not.

(And the Debian "porters" don't either, at least they are missing in any 
action. OK, they are probably not in LibreOffices userbase and thus 
don't see it, but others might..)



and it seems like ENABLE_WASM_STRIP_PINGUSER would be
appropriate to turn that off.


Which would need to be hacked in since it's only flagged by 
--enable-wasm-strip which as the name says is for WebAssembly 
(cross-)compile and thus can't be done generically (and strips out a 
sh*load of stuff)...


So it would boil down to

rene@frodo:~/LibreOffice/git/master/debian$ git diff rules
diff --git a/rules b/rules
index e7152c60..ed7a8157 100755
--- a/rules
+++ b/rules
@@ -2247,6 +2247,7 @@ config_host.mk:
    MARIADBCONFIG=$(MARIADBCONFIG) \
    FIREBIRD_CFLAGS=$(FIREBIRD_CFLAGS) FIREBIRD_LIBS=$(FIREBIRD_LIBS) \
    ./autogen.sh $(CONFIGURE_FLAGS)
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


 build:
    $(CURDIR)/debian/rules build-arch
@@ -2270,6 +2271,7 @@ ifeq "$(BUILD_NOGUI_PACKAGES)" "y"
    --without-doxygen --without-javadoc \
    --with-galleries=no --with-theme="$(DEFAULT_IMAGE)" \
    --disable-gui --disable-introspection --disable-qt5 
--disable-kf5
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


    PATH=$(BUILD_PATH) LD_LIBRARY_PATH=$(BUILD_LD_LIBRARY_PATH) 
ARCH_FLAGS=$(ARCH_FLAGS) TMP=`mktemp -q -d` $(MAKE) build-non-l10n-only



I am not sure this is worthwile.

  
  Thanks for considering.


Not for oldstable ;-)


Regards,


Rene

Bug#1056143: libeval-context-perl: t/012_safe.t fails

[gregor herrmann]

Source: libeval-context-perl
Version: 0.09.11-5
Severity: serious
Tags: ftbfs trixie sid
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As noted by ci.debian.net, t/012_safe.t started to fail recently:

#   Failed test 'Test STDOUT'
#   at t/012_safe.t line 127.
#  got: '`- A = 1  [S1]
# '
# expected: '
# `- A = 1  [S1]
# '
# |- CURRENT_RUNNING_PACKAGE = TEST  [S1]
# |- FILE = t/012_safe.t  [S2]
# |- INTERACTION  [H3]
# |  |- DIE = CODE(0x5600b3ac9f50)  [C4]
# |  |- EVAL_DIE = CODE(0x5600b3aca058)  [C5]
# |  |- INFO = CODE(0x5600b3ac9ba8)  [C6]
# |  `- WARN = CODE(0x5600b2dc5f18)  [C7]
# |- LATEST_CODE = #line 0 'Anonymous_called_at_t_012_safe.t:121'[\n]#  Note: 
evaluated PRE_CODE before running SAFE code[\n]=comment[\n][\n][\n]package TEST 
;[\n]use Data::TreeDumper;[\n][\n][\n][\n]=cut[\n][\n]# PRE_CODE[\n][\n]#line 0 
'Anonymous_called_at_t_012_safe.t:121'[\n]# CODE[\n]DumpTree({A => 1}) ;[\n]# 
POST_CODE[\n][\n]#end of context 'Anonymous_called_at_t_012_safe.t:121'[\n]  
[S8]
# |- LINE = 116  [S9]
# |- NAME = Anonymous  [S10]
# |- PACKAGE = TEST  [S11]
# |- REMOVE_PACKAGE_AFTER_EVAL = 1  [S12]
# `- SAFE (no elements)  [H13]
# Looks like you failed 1 test of 22.
t/012_safe.t  
ok 1 - unsafe code, using default safe
ok 2 - unsafe code
ok 3 - Invalid SAFE definition
ok 4 - PRE_SAFE_CODE error
ok 5 - PRE_SAFE_CODE
ok 6 - use strict by default
ok 7 - USE_STRICT
ok 8 - COMPARTMENT
ok 9 - first eval package
not ok 10 - Test STDOUT
ok 11 - sub pushed into safe context
ok 12 - new sub pushed into same safe context
ok 13 - access to persistent functionality
ok 14 - void context
ok 15 - right value in scalar context
ok 16 - scalar context
ok 17 - right value in array  context
ok 18 - array context
ok 19 - die within a safe
ok 20 - right value in scalar context
ok 21 - croak within a safe
ok 22 - die within a safe while using Carp
1..22
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/22 subtests 


Test Summary Report
- ---
t/012_safe.t  (Wstat: 256 (exited 1) Tests: 22 Failed: 
1)
  Failed test:  10
  Non-zero exit status: 1
Files=13, Tests=223,  2 wallclock secs ( 0.05 usr  0.01 sys +  1.29 cusr  0.17 
csys =  1.52 CPU)
Result: FAIL


Cf. e.g. 
https://ci.debian.net/packages/libe/libeval-context-perl/unstable/amd64/39667202/


As this is also run during building the package, it causes a build
failure.



Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmVXor5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgb6mg/+PuZrDFpUes2CebybnDYOJN5qj/RsS4oTbrYN4aTrhc3KlzgQ8vd0kSV2
jDUyMphzX8veUaQe9X2ss6+VL/O/eLa9jtDCpl8infH9vV1q7EcYp21LL6lN0zq9
VZtVeIXN6m+BTqwT1oS/lBzpgtpm8HOFv4qjJocKkufck3speXE65pQe0zu78Fp0
pGG5DMdA4683IhM4oS7g/2G+vBviMldReApNm6FV9vcKOmmag8CqYwEk/AUb4Q7Z
QCiaBBGy/J3oLdiIAt+JdWe6pg44pd2t1pqct4E1s6snpoIo+vwdbp4+Nox0ioQK
mT+7Au/fF12duWSxYyVpeDsm86rN6zlB/czksFgFey4Vggk/FfmzOVH2PCtdgV1h
InfkW0E9j4xQjrAlPtIXHKdE5FikDr3iQoOj7qyEPwpyIScIpZFTtWqoNIvxxEU7
H841HbstKVWzhxFZBa+bmBtpGeCE6sVhwgdNXvetnfzFPajvM8y/A7wnxsO9KRI5
58wZSvKE1Y8cNFcJTX5oWC2FyvvGLZepMArHA75D6yFxaQaGBnEXMDgw5ELArT8r
aYhKOFnzQiq6+a+rKskujAlHdDivBBK+BpwnVCbO1EZ/JwA5jgTdZ9fKFVQbOEPc
i3bdaBjny8rJEgjRlYLfND/Zy6dKdxbUxZTaIbgInzqM/jFTrQI=
=eiGi
-END PGP SIGNATURE-

Bug#1056142: liblc3: fails to clean when V=1 is set

[Jeremy Bícha]

Source: liblc3
Version: 1.0.4-1
Severity: important
Tags: ftbfs

liblc3 fails to clean when V=1 is set. V=1 is a popular way to enable
verbose output with automake. In fact, it is mentioned in the automake
documentation [1]

Ubuntu sets V=1 and the recent change to the package to run  make
clean  is now causing the Ubuntu build to fail. (Ubuntu's
configuration is in line with Debian Policy which encourages setting
builds to be "as verbose as reasonably possible".)

Minimal test case
---
V=1 debian/rules clean

Suggested fix
--
It looks like this package already empties the V environment variable
for "make test". I guess it should do that for "make clean" too.

Build log excerpt
--
debian/rules execute_after_dh_auto_clean
make[1]: Entering directory '/<>'
make clean
make[2]: Entering directory '/<>'
1rm -rf build
make[2]: 1rm: No such file or directory
make[2]: *** [Makefile:145: clean] Error 127

Full build log

https://launchpad.net/ubuntu/+source/liblc3/1.0.4-1/+latestbuild/amd64

[1] 
https://www.gnu.org/software/automake/manual/html_node/Automake-Silent-Rules.html

Thank you,
Jeremy Bícha

Bug#1055837: c-evo-dh-gtk2: game unusable because directory ~/.config/c-evo-dh/Saved is not created

[Peter B]

Hi Davide,

Thanks for reporting this problem.

The game only created the Saved folder if there was something to install in it.
The removal of the original example game (for incompatibility) caused this 
regression.

Fix in 1.10


Regards,
Peter

Bug#1056141: nvenc encoder not available after installing libnvidia-encode1 and enabling ffnvcodec

[Brian Bostwick]

Package: ffmpeg
Version: 7:6.1-2

Hi in Trixie, using nvidia-driver 525.125.06-2, libnvidia-encode1
525.125.06-2, and ffmpeg 7:6.1-2, I can't seem to get the nvenc codec
built into ffmpeg.

$ ffmpeg -codecs | grep 264
H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_v4l2m2m
h264_qsv h264_cuvid ) (encoders: libx264 libx264rgb h264_omx h264_qsv
h264_v4l2m2m h264_vaapi )

These are the additional enable flags I added to the debian/rules file:

--enable-nonfree \
--enable-cuda-llvm \
--enable-ffnvcodec

Full build configuration:

  configuration:
--prefix=/usr
--extra-version=9
--toolchain=hardened
--libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu
--arch=amd64
--enable-gpl
--disable-stripping
--enable-gnutls
--enable-ladspa
--enable-libaom
--enable-libass
--enable-libbluray
--enable-libbs2b
--enable-libcaca
--enable-libcdio
--enable-libcodec2
--enable-libdav1d
--enable-libflite
--enable-libfontconfig
--enable-libfreetype
--enable-libfribidi
--enable-libglslang
--enable-libgme
--enable-libgsm
--enable-libjack
--enable-libmp3lame
--enable-libmysofa
--enable-libopenjpeg
--enable-libopenmpt
--enable-libopus
--enable-libpulse
--enable-librabbitmq
--enable-librist
--enable-librubberband
--enable-libshine
--enable-libsnappy
--enable-libsoxr
--enable-libspeex
--enable-libsrt
--enable-libssh
--enable-libtheora
--enable-libtwolame
--enable-libvidstab
--enable-libvorbis
--enable-libvpx
--enable-libwebp
--enable-libx265
--enable-libxml2
--enable-libxvid
--enable-libzimg
--enable-libzmq
--enable-libzvbi
--enable-lv2
--enable-omx
--enable-openal
--enable-opencl
--enable-opengl
--enable-sdl2
--enable-nonfree
--enable-cuda-llvm
--enable-ffnvcodec
--disable-sndio
--enable-libjxl
--enable-pocketsphinx
--enable-librsvg
--enable-libvpl
--disable-libmfx
--enable-libdc1394
--enable-libdrm
--enable-libiec61883
--enable-chromaprint
--enable-frei0r
--enable-libsvtav1
--enable-libx264
--enable-libplacebo
--enable-librav1e
--enable-shared

After being built I just installed the ffmpeg and libavcodec debs.

$ dpkg -i': sudo dpkg -i ffmpeg_6.0-9_amd64.deb
libavcodec60_6.0-9_amd64.deb libavcodec-extra*

I originally had the proprietary driver installed via the vendor's
script, but it has since been removed.

My goal is to have nvenc appear as an option in OBS, which depends on
ffmpeg to have the codec available.

Bug#1056140: debos: fails to build from source: cannot find package "github.com/alessio/shellescape"

[Jeremy Bícha]

Source: debos
Version: 1.1.2-1
Severity: serious
Tags: ftbfs
X-Debbugs-CC: obba...@gmail.com

Build log excerpt

dh_auto_build
cd obj-x86_64-linux-gnu && go install -trimpath -v -p 8
github.com/go-debos/debos github.com/go-debos/debos/actions
github.com/go-debos/debos/cmd/debos
src/github.com/go-debos/fakemachine/machine.go:10:2: cannot find
package "github.com/alessio/shellescape" in any of:
/usr/lib/go-1.21/src/github.com/alessio/shellescape (from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/github.com/alessio/shellescape
(from $GOPATH)
dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath
-v -p 8 github.com/go-debos/debos github.com/go-debos/debos/actions
github.com/go-debos/debos/cmd/debos returned exit code 1

Thank you,
Jeremy Bícha

Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Christoph Anton Mitterer]

On Fri, 2023-11-17 at 15:37 +0100, Michael Biebl wrote:
> downgrades are not officially supported by Debian.

Sure... and if it's not fixable... well then it's not. But at least it
would be better then to abort the downgrade if it's detected that e.g.
a DE is running.
In my case it didn't matter but people may have important/unsaved data
open.

And maybe there is just some accidental restart of dbus or so involved
(that usually kills of the DE, too).


Cheers,
Chris.

Bug#1056139: tracker.debian.org: Migration data stuck on or before 2023-11-14

[Chris Hofstaedtler]

Package: tracker.debian.org
Severity: serious

Dear tracker.d.o owners,

as you probably have already noticed, the migration data for a lot of
packages appears stuck in the past, probably on or before 2023-11-14.

As an example, https://tracker.debian.org/pkg/multipath-tools shows "Too
young, only 4 of 5 days old", but the package migrated on 2023-11-16:
https://tracker.debian.org/news/1478834/multipath-tools-094-7-migrated-to-testing/

Thanks,
Chris

Bug#1056117: meson: generates non-determinstic .pkgconfig files

[Jussi Pakkanen]

On Fri, 17 Nov 2023 at 10:45, Chris Lamb  wrote:

> Whilst working on the Reproducible Builds effort, we noticed that
> meson was generates .pkgconfig files that are not reproducible.

Please file all changeslike these directly upstream. The Meson
packaging prohibits patches that alter functionality.

Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Michael Biebl]

Am 17.11.23 um 15:31 schrieb Christoph Anton Mitterer:

Control: tags -1 - moreinfo

Hey Luca.


On Fri, 2023-11-17 at 14:03 +, Luca Boccassi wrote:

Please attach the journal from around the time where the installation
was happening


Please see the attached file.

Also I just remembered, that with 255~rc2-1, and after it happened that
downgrading killed my DE session... I logged into Cinnamon again, and
when *then* pressing the power button, it wasn't even like in #1056135,
that *only* the Hibernation button was missing, but *no* pop-up dialog
(with at least Suspend, Cancel, Restart, Shutdown) showed up, and it
went straight without any further confirmation into shutdown.


Just a word of warning: downgrades are not officially supported by Debian.
They might just work most of the time for more trivial packages, but 
often they don't (e.g. because data structures have changed that are 
converted on upgrades but not on downgrades).



Regards,
Michael





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056059: dracut: systemd 255: dracut fails to boot due to lack of systemd-executor

[Michael Biebl]

Hi Thomas

Am 17.11.23 um 10:12 schrieb Thomas Lange:

I've already included the upstream patch to the git master branch of
dracut on salsa. The next dracut release in Debian will include the
fix.



Great, thanks. I assume this version will be 059-5 ?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056138: bullseye-pu: package nvidia-graphics-drivers/470.223.02-1

[Andreas Beckmann]

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

[ Reason ]
In oder to fix CVE-2023-31022 we need to upgrade nvidia-graphics-drivers
to a new upstream release.

[ Impact ]
A proprietary graphics driver with more CVEs open.

[ Tests ]
Only module building has been tested. Anything else would require
certain hardware and driver usage.

[ Risks ]
Low. Upgrading to a new nvidia driver release in (old-)stable is an
established procedure.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  (excluding the blobs)
  [*] attach debdiff against the package in (old)stable
  (excluding the blobs)
  [ ] the issue is verified as fixed in unstable
  will be fixed by uploads of src:nvidia-graphics-drivers{,-tesla} 525.*
  and src:nvidia-graphics-drivers-tesla-470 to sid soon

[ Changes ]
There is a new patch added which is only relevant for using this driver
with a backported Linux 6.2+ on a recent Intel CPU. As the blob parts
are not built with Indirect Branch Tracking (IBT) support, the module
cannot be used on CPU+kernel combination that enables IBT by default
unless it is booted with ibt=off.
There are only minor additional packaging changes.

[ Other info ]
This package is functionally equivalent to
src:nvidia-graphics-drivers-tesla-470 470.223.02-1 which will soon be in
sid and bookworm-pu.

Andreas
diff --git a/debian/README.source b/debian/README.source
index 4c3ae0a0..ad7d55ba 100644
--- a/debian/README.source
+++ b/debian/README.source
@@ -29,7 +29,7 @@ Upstream support timeframes
 Tesla 410   EoL
 Tesla 418 (LTSB)03/2022 EoL
 Tesla 440   11/2020 EoL
-Tesla 450 (LTSB)07/2023
+Tesla 450 (LTSB)07/2023 EoL
 Tesla 460 (PB)  01/2022 EoL
 Tesla 470 (LTSB)07/2024
 Tesla 510 (PB)  01/2023 EoL
@@ -61,9 +61,10 @@ The branch structure in the GIT repository
 418-bullseyeEoL   (bullseye)  450, 418-tesla
 418-tesla   EoL   (bullseye)  450-tesla, tesla-418/main
 tesla-418/main  EoL   bullseye,sidtesla-450/main
-450   (bullseye)  460, 450-tesla
-450-tesla (bullseye)  460-tesla, tesla-450/main
-tesla-450/mainbullseye,sidtesla-460/main
+450 EoL   (bullseye)  460, 450-tesla
+450-tesla   EoL   (bullseye)  460-tesla, tesla-450/main
+tesla-450/main  EoL   (bullseye),(sid)tesla-460/main, 
tesla-450/transition-470
+tesla-450/transition-470  bullseye,sidtesla-460/transition-470
 460 EoL   (bullseye)  470, 460-tesla
 460-tesla   EoL   (bullseye)  470-tesla, tesla-460/main
 tesla-460/main  EoL   (bullseye),(sid)tesla-470/main, 
tesla-460/transition-470
diff --git a/debian/changelog b/debian/changelog
index 95a17e09..70ab5236 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,44 @@
+nvidia-graphics-drivers (470.223.02-1) bullseye; urgency=medium
+
+  * New upstream long term support branch release 470.223.02 (2023-10-31).
+* Fixed CVE-2023-31022.  (Closes: #1055136)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5491
+- Fixed a bug which caused incorrect reporting of presentation
+  times when using the VK_NV_present_barrier Vulkan extension.
+* Improved compatibility with recent Linux kernels.
+
+  [ Andreas Beckmann ]
+  * Refresh patches.
+  * Upload to bullseye.
+
+ -- Andreas Beckmann   Fri, 17 Nov 2023 14:40:09 +0100
+
+nvidia-graphics-drivers (470.199.02-4) UNRELEASED; urgency=medium
+
+  * Refuse to load module if IBT is enabled.  (Closes: #1052069)
+  * Switch suggestion from obsolete vulkan-utils to vulkan-tools
+(525.125.06-3).  (Closes: #1055503)
+
+ -- Andreas Beckmann   Wed, 15 Nov 2023 09:41:22 +0100
+
+nvidia-graphics-drivers (470.199.02-3) UNRELEASED; urgency=medium
+
+  * Revert backport of pin_user_pages changes.
+  * Backport drm_gem_prime_handle_to_fd changes from 470.223.02 to fix kernel
+module build for Linux 6.6.
+
+ -- Andreas Beckmann   Fri, 03 Nov 2023 12:03:43 +0100
+
+nvidia-graphics-drivers (470.199.02-2) UNRELEASED; urgency=medium
+
+  * Backport get_user_pages and pin_user_pages changes from 520.56.06,
+525.53 and 535.86.05 to fix kernel module build for Linux 6.5.
+
+ -- Andreas Beckmann   Wed, 16 Aug 2023 20:12:16 +0200
+
 nvidia-graphics-drivers (470.199.02-1) bullseye; urgency=medium
 
-  * New upstream production branch release 470.199.02 (2023-06-26).
+  * New upstream long term support branch release 470.199.02 (2023-06-26).
 * Fixed CVE-2023-25515, CVE-2023-25516.  (Closes: #1039678)
   https://nvidia.custhelp.com/app/answers/detail/a_id/5468
 * Improved compatibility with recent Linux kernels.
@@ -13,16 +51,16 @@ nvidia-graphics-drivers (47

Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Luca Boccassi]

Control: tags -1 moreinfo

On Fri, 17 Nov 2023 14:40:05 +0100 Christoph Anton Mitterer
 wrote:
> Package: systemd
> Version: 255~rc2-1
> Severity: important
> 
> Hey.
> 
> Because of #1056135 I was downgradin systemd/udev packages to 254.5-
1.
> While apt was still running, this causes the whole desktop
environment
> (I use cinnamon) to be killed (and all processes in it ;-) ).
> 
> Tried it twice, happened twice.

Please attach the journal from around the time where the installation
was happening

-- 
Kind regards,
Luca Boccassi


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

Bug#1055032: Please update to latest upstream version

[Marcin Owsiany]

Awesome, looking forward to seeing it in the archive!
BTW, the package description might need some refresh (the promise about CSS
seems to have come to life already).

Marcin

pt., 17 lis 2023 o 12:11 Antonio Terceiro  napisał(a):

> On Fri, Nov 17, 2023 at 10:05:19AM +0100, Marcin Owsiany wrote:
> > Antonio, https://salsa.debian.org/terceiro/textual is now a 404.
> > Is your work available somwehere else?
>
> No, by mistake I ended up not making it public in the first place. It's
> public now.
>

Bug#1013356: fzf: Bash completions not active by default

[Christoph Anton Mitterer]

On Fri, 2023-11-17 at 08:40 +0100, Bastian Venthur wrote:
> If bash completion is not enabled on purpose, I would
> consider this behaviou a bug. But I believe just enabling the bash
> completion
> by default would be the better solution.

In any case, please do not enable the fzf-completion (i.e. **) by
default, unless there's an easy way to manually disable that (which is
not easy if the file is installed to /usr/share/bash-
completion/completions/fzf )

The problem with fzf’s completion file is, that it contains both:
1. the completion for the fzf program itself
2. the "generic" (well only to some very limited amount) **
   completion

The latter is unfortunately rather limited and even buggy in many
cases.
I tried to get that improved, but upstream eventually decided that he
doesn't want the functionality to be expanded/fixed.

Alternative integrations exist, but these do not work properly when
fzf’s own is also enabled.


Therefore, please stop installing the completion file to:
   /usr/share/bash-completion/completions/fzf

This is anyway not an appropriate location, as neither of the two
completions mentioned above actually use bash-completion.

IMO the proper way would be:
- users need to manually source (2) (or manually install it in
  /etc/profile.d or the likes)
- the parts for (1) should be split of into a separate file and that
  could actually be installed into
  /usr/share/bash-completion/completions/
  (not because it would really use anything of bash-completion, but
  only to get the opportunistic loading of that)

I've had talked to upstream about splitting the two
(https://github.com/junegunn/fzf/issues/3457), but again... he does not
seem to have much interest in improving things.

If you really need to have fzf's completion file automatically loaded,
please add some easy way to disable that. Otherwise you break the setup
of people who want to use better alternative integrations.

Cheers,
Chris.

Bug#1056135: regression: hibernation issues with 255~rc2-1

[Luca Boccassi]

Control: tags -1 upstream

On Fri, 17 Nov 2023 14:20:14 +0100 Christoph Anton Mitterer
 wrote:
> Package: systemd
> Version: 255~rc2-1
> Severity: normal
> 
> Hey.
> 
> The following two issues are both solved when downgrading to 254.5-1
(and completely
> rebooting the system, before trying again - they also shop up again,
only after
> completely rebooting the upgraded systemd again):

Please open an issue on github and attach debug level logs showing the
error

-- 
Kind regards,
Luca Boccassi


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

Bug#1054290: zlib: CVE-2023-45853

[James Addison]

Followup-For: Bug #1054290

Sorry, I made an important mistake in my phrasing about these two packages:

>  * mupen64plus-core - this appears unaffected in Debian; it declares a
>build-time dependency on libminizip-dev, and the build system uses this
>when available.  I've verified that by recompiling it successfully with the
>'minizip' subproject directory deleted from the filesystem.

>  * widelands - appears unaffected in Debian; similar to mupen64plus-core, it
>declares a dependecy on libminizip-dev, and the build system for the
>codebase uses system-provided minizip in preference to the vendored copy.

I should not have said that these are unaffected; they may be affected if the
system-provided minizip library is vulnerable.

Additionally, patching the vendored copy of minizip source code within those
packages alone would not help, again for the same reason that they use the
system-provided minizip.

This is the same condition as the libxlsxwriter case.

Bug#1052523: conda-package-handling: please remove extraneous dependency on python3-six

[Alexandre Detiste]

I see this dependency chain.

python3-conda-package-streaming -> python3-requests -> python3-urllib3
-> python3-six

and python3-urrlib3 has been fixed in experimental right now

  
https://tracker.debian.org/news/1478063/accepted-python-urllib3-207-1-source-into-experimental/

Can you please try again with  python3-urrlib3 from experimental ?

Moreover python3-urllib3 will need a lot more tests,
so help is welcome.

Greetings

Le ven. 17 nov. 2023 à 14:19, Santiago Vila  a écrit :
> Hello. As an experiment, I tried removing python3-six
> from a chroot which had all the build-dependencies installed,
> and this is what happened:
>
> The following packages will be REMOVED:
>python3-conda-package-streaming python3-requests python3-six 
> python3-urllib3
>
> and I also checked that the package does not build anymore.
>
> Ok, policy says Build-Depends should only contain direct dependencies,
> so if python3-six is not used directly and as such during build, removing from
> build-depends would be ok.

Bug#1054290: zlib: CVE-2023-45853

[James Addison]

Followup-For: Bug #1054290

Updates on some other codebases where minizip appears vendored in Debian source
packages:

  * gdal - the fix for minizip is included in upstream version 3.8.0 and a
packaged version of that release has been accepted into Debian unstable.

  * mupen64plus-core - this appears unaffected in Debian; it declares a
build-time dependency on libminizip-dev, and the build system uses this
when available.  I've verified that by recompiling it successfully with the
'minizip' subproject directory deleted from the filesystem.

  * orthanc - appears unaffected due to the nature of the inputs to the
filename parameter.

  * widelands - appears unaffected in Debian; similar to mupen64plus-core, it
declares a dependecy on libminizip-dev, and the build system for the
codebase uses system-provided minizip in preference to the vendored copy.

Bug#1056121: Acknowledgement (mariadb-server: debian-start uses obsolate hardcoded /etc/mysql/debian.cnf)

[Sebastian Fiedler]

This is a duplicate of bug 1056120.

Sorry for any inconvenience.

On 17.11.23 11:06, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1056121: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056121.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian MySQL Maintainers 

If you wish to submit further information on this problem, please
send it to 1056...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.



--
Sebastian Fiedler

gnupg encrypted messages are welcome - key ID: 2C833234
gnupg fingerprint: 92F0 89C6 5FE2 3657 CB44 2D2B 39C4 9E11 2C83 3234

Unsere Mitarbeiter sind möglicherweise im Home-Office und werden die 
Verbindungen zu Ihnen aus dem Home-Office aufbauen.

Wege, wie Sie uns erreichen:
unser Festnetz +49 351 802981, Email an support@ und der Chat - der rote Knopf 
rechts unten auf der Seite https://schlittermann.de. Ist die Chat Ikone grau, 
sind wir offline.

internet & unix support
Heiko Schlittermann
Tannenstrasse 2 - 01099 Dresden
Web: http://www.schlittermann.de/
Tel.: +49 351 8029981
Fax:  +49 351 8029983

Bug#1056136: bookworm-pu: package intel-graphics-compiler/1.0.12504.6-1+deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: block 1055874 with -1

[ Reason ]
A recent rebuild of all packages in bookworm discovered an
incompatibility of intel-graphics-compiler/bookworm with
intel-vc-intrinsics/bookworm, causing the former to FTBFS.
#1055874
The intel-graphics-compiler binaries in bookworm were built against an
older version of intel-vc-intrinsics (0.8.1) than what was shipped in
bookworm (0.11.0).

[ Impact ]
src:intel-graphics-compiler does FTBFS in bookworm in case someone wants
to rebuild it or a security update needs to happen.

[ Tests ]
Unfortunately there is no testsuite here, but src:intel-compute-runtime
(which heavily uses this package) has one.

[ Risks ]
The upstream commits required for the fix are larger than I would have
liked, but they apply cleanly. There seems to have been some major
reorganization in intel-vc-intrinsics.

intel-graphics-compiler has only one user: intel-compute-runtime (which
is a leaf package), so we cannot break much.
intel-vc-intrinsics also has only one user (intel-graphics-compiler),
therefore no similar bugs could have occurred elsewhere.

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

[ Changes ]
* Replace our patches with the corresponding upstream commits (which are
  larger, but fix all occurrences of the problems and do this more
  thoroughly), s.t. subsequent patches apply cleanly. (Only two minor
  adjustments were needed to make
  0002-Changed-relative-paths-in-include-directives.patch apply.)
* Cherry-pick (without any adjustments needed) two patches which update
  the codebase for the changes in intel-vc-intrinsics 0.11.0, making it
  incompatible with older versions (therefore bumping the b-d version).

[ Other info ]
I'll upload the fixed package right now.

 b/debian/changelog   |   10
 b/debian/control |2
 b/debian/patches/0001-Preinstalled-SPIRV-Tools-CMakeFile-fix.patch   |   51
 b/debian/patches/0002-Changed-relative-paths-in-include-directives.patch |  
524 
 b/debian/patches/0003-Add-multi-indirect-byte-regioning-feature.patch|  
162 +
 b/debian/patches/0004-VC-subtarget-refactoring.patch | 
1075 ++
 b/debian/patches/series  |7
 debian/patches/fix-relative-includes.patch   |   15
 debian/patches/fix-spirv-check.diff  |   13
 9 files changed, 1827 insertions(+), 32 deletions(-)


Andreas


intel-graphics-compiler_1.0.12504.6-1+deb12u1.diff.xz
Description: application/xz

Bug#1056135: regression: hibernation issues with 255~rc2-1

[Christoph Anton Mitterer]

Package: systemd
Version: 255~rc2-1
Severity: normal

Hey.

The following two issues are both solved when downgrading to 254.5-1 (and 
completely
rebooting the system, before trying again - they also shop up again, only after
completely rebooting the upgraded systemd again):

1) I have a somewhat special hibernation setup.
   Hibernation goes to a btrfs swap file on top of dm-crypt.
   The following unit files are used for that:
   /etc/systemd/system/data-swap-hibernation.swap:
[Unit]
Before=systemd-hibernate.service
StopWhenUnneeded=true

[Swap]
What=/data/swap/hibernation
Options=noauto

[Install]
RequiredBy=systemd-hibernate.service
   
   I also have a /etc/systemd/system/hibernation-cleanup.service:
[Unit]
Description=synchronise cached writes to persistent storage and free 
page cache before hibernation in order to minimise the image
Before=hibernate.target

[Service]
Type=oneshot
ExecStart=sync
ExecStart=@sh %n:sh -c 'printf 1 >/proc/sys/vm/drop_caches'

[Install]
WantedBy=hibernate.target
   but I don't think this has anything to do with the issue here.

   There are symlinks:

/etc/systemd/system/systemd-hibernate.service.requires/data-swap-hibernation.swap
 -> /etc/systemd/system/data-swap-hibernation.swap
/etc/systemd/system/hibernate.target.wants/hibernation-cleanup.service 
-> /etc/systemd/system/hibernation-cleanup.service


   Especially, the hibernation file may not be availabe (or activated as swap),
   yet, when I go into hibernation.
   This caused desktop environments (I use Cinnamon) not to show the "Hiberate"
   button, which I've been able to solve via a:
   
/etc/systemd/system/systemd-logind.service.d/disable-hibernation-swap-check.conf:
[Service]
Environment="SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1"

   However, starting with 255~rc2-1 (but solved when going back to 254.5-1)
   this no longer seems to have an effect. At least Cinnamon then doesn't show
   the Hibernate button anymore.


2) When, because of (1), manually calling:
   # systemctl hibernate
   Call to Hibernate failed: No such file or directory

   The above error occurs (which itdoes not with 254.5-1), but the system then
   still seems to hibernate normally (and can also resume from that).


Notice also that I've changed logind.conf and sleep.conf.


Any ideas? I can forward the issue upstream if you think it's happening there.

Thanks,
Chris.



-- Package-specific info:

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.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 systemd depends on:
ii  libacl12.3.1-3
ii  libapparmor1   3.0.12-1
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-6
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.4-0.1
ii  libmount1  2.39.2-6
ii  libpam0g   1.5.2-9.1
ii  libseccomp22.5.4-2
ii  libselinux13.5-1
ii  libssl33.0.12-2
ii  libsystemd-shared  255~rc2-1
ii  libsystemd0255~rc2-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.39.2-6
ii  systemd-dev255~rc2-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.14.10-3
ii  ntpsec [time-daemon]1.2.2+dfsg1-2

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1+b1
ii  libip4tc2 1.8.9-2
ii  libp11-kit0   0.25.0-5
ii  libqrencode4  4.1.1-1
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
ii  polkitd   123-3
ii  python3   3.11.4-5+b1
pn  python3-pefile
pn  systemd-boot  
ii  systemd-container 255~rc2-1
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-3
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 255~rc2-1
ii  libpam-systemd 255~rc2-1
ii  udev   255~rc2-1

-- Configuration Files:
/etc/systemd/logind.conf changed:
[Login]
HandleSuspendKey=ignore
HandleSuspendKeyLongPress=ignore
HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=lock

/etc/systemd/sleep.conf changed:
[Sleep]
HibernateMode=shutdown platform


-- no debconf information

Bug#1054663: telegram-send: Fails to run

[Dale Richards]

I've filed a request for python3-python-telegram-bot to update to the latest 
upstream:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054663

If that request is actioned, this bug could be closed by updating its 
dependencies to point to the newer version. Otherwise, we may need to revert 
telegram-send to a version that works with the older python-telegram-bot.

Best regards,
Dale Richards

Bug#1052523: conda-package-handling: please remove extraneous dependency on python3-six

[Santiago Vila]

El 23/9/23 a las 23:05, Alexandre Detiste escribió:

Source: conda-package-handling
Version: 2.2.0-1
Severity: minor
User: python3-...@packages.debian.org
Usertags: python3-six-removal

conda-package-handling as been cleaned up from Python2/six code

https://github.com/conda/conda-package-handling/pull/92

There remain a stale (build-)Depends: on python3-six,
can you prune those ?


Hello. As an experiment, I tried removing python3-six
from a chroot which had all the build-dependencies installed,
and this is what happened:

The following packages will be REMOVED:
  python3-conda-package-streaming python3-requests python3-six python3-urllib3

and I also checked that the package does not build anymore.

Ok, policy says Build-Depends should only contain direct dependencies,
so if python3-six is not used directly and as such during build, removing from
build-depends would be ok.

However, I'm concerned about the fact that python3-conda-package-streaming
still depends on python3-six.

Could it be the case that the depends/build-depends of
python3-conda-package-streaming on python3-six is also "extraneous"?

(If so, it would help if you could file that as a separate bug, which
maybe should be fixed before this one).

Thanks.

Bug#1056134: python3-python-telegram-bot: Consider update to >=20?

[Dale Richards]

Package: python3-python-telegram-bot
Version: 13.15-1
Severity: wishlist
X-Debbugs-Cc: d...@dalerichards.net

Dear Maintainer,

With version 14, python-telegram-bot merged a refactor of the
telegram/constants.py file:
https://github.com/python-telegram-bot/python-telegram-bot/pull/2708

Recent versions of telegram-send (other packages may be affected) expect
the new format of constants.py, which is why telegram-send is currently
broken in sid:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054663

Would you please consider updating python3-python-telegram-bot to the
latest upstream version?

Many thanks,
Dale Richards

Bug#1056133: ITP: sfwbar -- flexible taskbar application for wayland compositors

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 
X-Debbugs-Cc: debian-de...@lists.debian.org, bir...@debian.org

* Package name: sfwbar
  Version : 1.0_beta13
  Upstream Contact: Lev Babiev 
* URL : https://github.com/LBCrion/sfwbar
* License : GPL
  Programming Lang: C
  Description : flexible taskbar application for wayland compositors

SFWBar (S* Floating Window Bar) is a flexible taskbar application for
wayland compositors, designed with a stacking layout in mind. Originally
developed for Sway, SFWBar will work with any wayland compositor
supporting layer shell protocol, the taskbar and window switcher
functionality shall work with any compositor supportinig foreign
toplevel protocol, but the pager, and window placement functionality
require sway (or at least i3 IPC support).

Bug#1056132: skimage: FTBFS in testing and unstable

[Graham Inggs]

Source: skimage
Version: 0.22.0-2
Severity: serious
Tags: ftbfs

Hi Maintainer

As can be seen on reproducible builds [1], skimage currently FTBFS in
testing and unstable.  I've copied what I hope is the relevant part of
the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/skimage.html


dumping search index in English (code: en)... done
dumping object inventory... done

Sphinx-Gallery successfully executed 118 out of 118 files subselected by:

gallery_conf["filename_pattern"] = '/plot'
gallery_conf["ignore_pattern"]   = '__init__\\.py'

after excluding 0 files that had previously been run (based on MD5).

embedding documentation hyperlinks...
/usr/lib/python3/dist-packages/sphinx_gallery/docs_resolv.py:145:
RemovedInSphinx80Warning:

Sphinx 8 will drop support for representing paths as strings. Use
"pathlib.Path" or "os.fspath" instead.


Extension error:
Documentation options could not be found in index.
make[2]: *** [Makefile:50: html] Error 2
make[2]: Leaving directory '/build/reproducible-path/skimage-0.22.0/doc'
make[1]: *** [debian/rules:59: override_dh_installdocs-indep] Error 2
make[1]: Leaving directory '/build/reproducible-path/skimage-0.22.0'
make: *** [debian/rules:31: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Bug#1002789: python-pycdlib: FTBFS: failed tests

[Santiago Vila]

severity 1002789 serious
thanks

Hello. This bug has been hidden for me because the package
had a missing build-dependency on tzdata (#1031362). Such bug
is now reassigned to libpython3.11-stdlib, where it probably belongs.

Now, when I build the package in bookworm using a chroot with
tzdata installed, the package FTBFS for me as reported here.

Because trixie and sid are moving targets, I'm attaching a build log
made in bookworm, and I recommend that you try to debug the problem
in bookworm first (doing a diff between two different build logs
made in unstable at very different times is not fun).

My build environment is pretty standard: A machine running bookworm
using the standard kernel in bookworm (not the -cloud variant).

I'm building packages using schroot and sbuild with a file-based chroot.
You can get a similar build environment by just using sbuild-createchroot.

Note that the failure also happens in reproducible-builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-pycdlib.html

By distribution, we can see that the package:

FTBFS in bookworm
FTBFS in trixie
FTBFS in sid

By architecture: we can see that the package:

FTBFS on amd64
FTBFS on arm64
FTBFS on armhf
FTBFS on i386

So please stop downgrading the bug. If at this point you still
can't reproduce it, contact me privately and I will gladly provide
a machine where the failure happens 100% of the time.

Thanks.

python-pycdlib_1.12.0+ds1-4_amd64-20231115T223314.744Z.gz
Description: application/gzip

Bug#1055516: Uploaded python-jsonschema-specifications

[Thomas Goirand]

Hi,

FYI, I have just uploaded python-jsonschema-specifications, when it 
clears the NEW queue, I can move forward with updating python-jsonschema.


Cheers,

Thomas Goirand (zigo)

Bug#1056074: libreoffice: FTBFS: boost1.83 transition

[René Engelhard]

Am 16. November 2023 22:19:57 MEZ schrieb Anton Gladky :
>Let's keep the bug open for now, till we switch to a newer
>version and if all is OK, the bug will be closed.

That does not make sense. Either it fails to build or not. Only in the first 
case there was a warrant for a bug. In the second case it should just be closed.

A broken build tree is not a bug here. 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules#L2441
 is done before the install but it doesn't remove util/ itself.

Regards

René

Bug#1056131: override: libsoup2.4:oldlibs/optional

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: libsoup...@packages.debian.org
Control: affects -1 + src:libsoup2.4

Please move all binary packages from src:libsoup2.4, except for the
documentation and tests, to the oldlibs section:

libsoup2.4-dev:oldlibs/optional
libsoup2.4-1:oldlibs/optional
libsoup-gnome2.4-1:oldlibs/optional
libsoup-gnome2.4-dev:oldlibs/optional
libsoup2.4-common:oldlibs/optional
gir1.2-soup-2.4:oldlibs/optional

src:libsoup2.4 is a deprecated version of libsoup, and has been superseded
by src:libsoup3. I plan to do a mass-bug-filing for dependent packages at
some point, asking them to move to libsoup3.

Thanks,
smcv

Bug#1054533: nvme-stas: autopkgtest fails on all architectures

[Olivier Gayot]

Although this issue appears as a regression in nvme-stas 2.3-1, it looks like 
it was already
affecting the usability of the nvme-stas version in testing (i.e., 2.2.2-2) - 
outside of autopkgtests.

Here with nvme-stas 2.2.2-2 (after configuring a controller in 
/etc/stas/stafd.conf):

Nov 17 11:14:05 usable-whippet systemd[1]: Reloaded stafd.service - STorage 
Appliance Finder (STAF).
Nov 17 11:14:07 usable-whippet stafd[1268]: Error reading mandatory Host NQN 
(see stasadm --help): [Errno 2] No such file or directory: '/etc/nvme/hostnqn'
Nov 17 11:14:07 usable-whippet systemd[1]: stafd.service: Main process exited, 
code=exited, status=1/FAILURE
Nov 17 11:14:07 usable-whippet systemd[1]: stafd.service: Failed with result 
'exit-code'.

To make the autopkgtest pass, I believe we can either:

* add a Test-Depends on nvme-cli; or
* running those commands as part of the autopkgtest:
* mkdir --parents /etc/nvme
* systemctl start stas-config@hostnqn
* systemctl start stas-config@hostid

That said, I suggest we look for a solution that also resolves the issue 
outside of autopkgtests.
Would introducing a Depends on nvme-cli be a bad thing?

Kind regards,
Olivier

Bug#1056130: gthumb: (unused?) build-dependency on deprecated libsoup-gnome2.4-dev

[Simon McVittie]

Source: gthumb
Version:  3:3.12.4-1
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libsoup2.4 libsoup-gnome

While checking how many packages are still using the deprecated
libsoup2.4, I noticed that gthumb is one of only two packages in Debian
that still depend on libsoup-gnome2.4-dev.

libsoup-gnome was originally a sub-library for parts of libsoup that
depended on GNOME infrastructure, like GNOME's gconf settings for proxies.
My understanding is that all of that functionality has now been superseded
by components at the cross-desktop layer, like GIO extension points and
the glib-networking package.

gthumb has a build-dependency, but the actual binary has no dependency
on libsoup-gnome2.4-1, and from a quick look at codesearch I can't
see any sign that it is actually using this sub-library. Can the
build-dependency be removed?

This would also be a step closer to being able to port
gthumb from the deprecated libsoup2.4/libwebkit2-gtk-4.0-dev to
libsoup3/libwebkit2-gtk-4.1-dev (a mass bug filing for that will follow
at some point). libsoup3 does not have libsoup-gnome any more.

Thanks,
smcv

Bug#1056129: libmateweather: (unused?) dependency on deprecated libsoup-gnome2.4-dev

[Simon McVittie]

Source: libmateweather
Version: 1.26.2-1
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libsoup2.4 libsoup-gnome

While checking how many packages are still using the
deprecated libsoup2.4, I noticed that libmateweather is one of only
two packages in Debian that still depend on libsoup-gnome2.4-dev.

libsoup-gnome was originally a sub-library for parts of libsoup that
depended on GNOME infrastructure, like GNOME's gconf settings for proxies.
My understanding is that all of that functionality has now been superseded
by components at the cross-desktop layer, like GIO extension points and
the glib-networking package.

libmateweather has a build-dependency and the -dev package Depends on
it, but the actual library has no dependency on libsoup-gnome2.4-1,
and quick look at codesearch, I can't see any sign that it is actually
using this sub-library. Can the (build-)dependency be removed?

This would also be a step closer to being able to port libmateweather
from the deprecated libsoup2.4 to libsoup3 (a mass bug filing for that
will follow at some point). libsoup3 does not have libsoup-gnome any more.

Thanks,
smcv

Bug#1056128: sugar-browse-activity: please replace SoupGNOME.CookieJarSqlite with Soup.CookieJarDB

[Simon McVittie]

Package: sugar-browse-activity
Version: 207-2
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libsoup2.4 libsoup-gnome

While checking how many packages are still using the
deprecated libsoup2.4, I noticed that according to codesearch,
sugar-browse-activity appears to be the only package in Debian that
requires SoupGNOME-2.4.typelib.

It seems that it's only using that typelib to construct an instance
of SoupGNOME.CookieJarSqlite. libsoup2.4 (the not-GNOME part) has a
CookieJarDB class, documented like this:

> SoupCookieJarDB is a SoupCookieJar that reads cookies from and writes
> them to a sqlite database in the new Mozilla format.
>
> (This is identical to SoupCookieJarSqlite in libsoup-gnome; it has
> just been moved into libsoup proper, and renamed to avoid conflicting.)

I hope this means that it would be straightforward to switch from
SoupGNOME.CookieJarSqlite to Soup.CookieJarDB, which would bring us one
step closer to being able to drop libsoup-gnome.

This would also be a step closer to being able to port sugar-browse-activity
from libsoup2.4/gir1.2-webkit2-4.0 to libsoup3/gir1.2-webkit2-4.1
(a mass bug filing for that will follow at some point). libsoup3 does
not have libsoup-gnome any more.

Thanks,
smcv

Bug#1056127: warzone2100-data: Missing texture pack for High terrain quality

[Philipp Klaus Krause]

Package: warzone2100-data
Version: 4.4.0-1
Severity: normal
X-Debbugs-Cc: p...@spth.de

Dear Maintainer,

   What I did: I started current warzone2100 in debian testing and opened the
graphics options tochange the terrain quality setting
   What I saw: the "High" entry was greyed out, on the console I got a
diagnostic "Missing texture pack for High terrain quality - reverting to Normal
terrain quality"
   What I expected: the "High" is displayed white and can be selected

This new "High" setting for terrain quality is considered the main improvement
in 4.4.0 over the previous version. It is thus quite unfortunate that it
doesn't work in Debian.


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

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

warzone2100-data depends on no packages.

warzone2100-data recommends no packages.

Versions of packages warzone2100-data suggests:
ii  warzone2100  4.4.0-1

-- no debconf information

Bug#1056126: libclang1-17: libclang-17.so.1 uses wrong SONAME

[Norbert Lange]

Package: libclang1-17
Version: 1:17.0.5-1
Severity: normal
X-Debbugs-Cc: nolang...@gmail.com

Dear Maintainer,

libclang-17.so.1 specifies the wrong SONAME,
namely the full revision like for example:
'libclang-17.so.17.0.5'

It should be 'libclang-17.so.1'.

Otherwise users of the library like doxygen will
need to be rebuilt for every patch release.



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

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

Versions of packages libclang1-17 depends on:
ii  libc6   2.36-9+deb12u3
ii  libgcc-s1   12.2.0-14
ii  libllvm17   1:17.0.5-1
ii  libstdc++6  12.2.0-14

libclang1-17 recommends no packages.

libclang1-17 suggests no packages.

-- no debconf information

Bug#1056125: libsoup2.4: superseded by libsoup3, should eventually be removed

[Simon McVittie]

Source: libsoup2.4
Version: 2.74.3-1
Severity: important
Tags: wontfix

libsoup2.4 is a deprecated version of libsoup and has been superseded by
the libsoup3 source package. Packages that depend on libsoup 2 should move
to libsoup 3.

Migration guide:
https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html

Thanks,
smcv

Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)

[Nilesh Patra]

On Fri, Nov 17, 2023 at 06:18:04PM +0800, Maytham Alsudany wrote:
> golang-github-go-logfmt-logfmt doesn't have this Handler type that's being 
> used,
> and humanlog already uses go-logfmt as much as it can
> 
> I've made an issue upstream at [3] regarding this and I've patched out the
> Handler type completely from humanlog for now.
> 
> Would you like me to close this RFS bug and the ITP?

If this is needed for some actual functionality in humanlog, I will upload 
kr-logfmt
which would otherwise block your work.

From your mail, it is not clear to me whether or not it is needed.
Please let me know.

> [1]: https://bugs.debian.org/1055740
> [2]:
> https://salsa.debian.org/go-team/packages/golang-github-humanlogio-humanlog/
> [3]: https://github.com/humanlogio/humanlog/issues/71


Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Fri, Nov 17, 2023 at 10:05:19AM +0100, Marcin Owsiany wrote:
> Antonio, https://salsa.debian.org/terceiro/textual is now a 404.
> Is your work available somwehere else?

No, by mistake I ended up not making it public in the first place. It's
public now.


signature.asc
Description: PGP signature

Bug#1056124: libvirt-daemon-system: segfault snapshot restore

[Maxou56800]

Package: libvirt-daemon-system
Version: 9.9.0-1
Severity: important
Tags: upstream
X-Debbugs-Cc: maxou56...@morpheus.re

Dear Maintainer,

* What led up to the situation?

Restore a VM Snapshot

* What outcome did you expect instead?

A successful VM snapshot restore.

Logs:

PID: 2245 (libvirtd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Fri 2023-11-17 11:47:47 CET (5min ago)
Command Line: /usr/sbin/libvirtd --timeout 120
Executable: /usr/sbin/libvirtd
Control Group: /system.slice/libvirtd.service
Unit: libvirtd.service
Slice: system.slice
Storage:
/var/lib/systemd/coredump/core.libvirtd.0.bca0dd123eb844c0a2e386b65dc62067.2245.170021806700.zst
(present)
Size on Disk: 1.8M
Message: Process 2245 (libvirtd) of user 0 dumped core.

Module libnss_systemd.so.2 from deb systemd-255~rc2-1.amd64
Module libsystemd.so.0 from deb systemd-255~rc2-1.amd64
Module libudev.so.1 from deb systemd-255~rc2-1.amd64
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Stack trace of thread 2257:
#0 0x7fcdac6104f4 qemuSaveImageDecompressionStart
(libvirt_driver_qemu.so + 0x1524f4)
#1 0x7fcdac60c82a qemuProcessStartWithMemoryState
(libvirt_driver_qemu.so + 0x14e82a)
#2 0x7fcdac617b49 qemuSnapshotRevert
(libvirt_driver_qemu.so + 0x159b49)
#3 0x7fcdac587dcf n/a (libvirt_driver_qemu.so + 0xc9dcf)
#4 0x7fcdb4f31f16 virDomainRevertToSnapshot (libvirt.so.0
+ 0x331f16)
#5 0x5616ccf23d6e n/a (libvirtd + 0x40d6e)
#6 0x7fcdb4dfb9f9 virNetServerProgramDispatch
(libvirt.so.0 + 0x1fb9f9)
#7 0x7fcdb4e015e2 n/a (libvirt.so.0 + 0x2015e2)
#8 0x7fcdb4e01921 n/a (libvirt.so.0 + 0x201921)
#9 0x7fcdb4d35c05 n/a (libvirt.so.0 + 0x135c05)
#10 0x7fcdb4d351e8 n/a (libvirt.so.0 + 0x1351e8)
#11 0x7fcdb47203ec start_thread (libc.so.6 + 0x883ec)
#12 0x7fcdb47a0a4c __clone3 (libc.so.6 + 0x108a4c)

Stack trace of thread 2267:
#0 0x7fcdb471d156 __futex_abstimed_wait_common64
(libc.so.6 + 0x85156)
#1 0x7fcdb471f818 __pthread_cond_wait_common (libc.so.6 +
0x87818)
#2 0x7fcdb4d3509a virCondWait (libvirt.so.0 + 0x13509a)
#3 0x7fcdb4d35c84 n/a (libvirt.so.0 + 0x135c84)
#4 0x7fcdb4d351e8 n/a (libvirt.so.0 + 0x1351e8)
#5 0x7fcdb47203ec start_thread (libc.so.6 + 0x883ec)
#6 0x7fcdb47a0a4c __clone3 (libc.so.6 + 0x108a4c)

Stack trace of thread 2308:
#0 0x7fcdb471d156 __futex_abstimed_wait_common64
(libc.so.6 + 0x85156)
#1 0x7fcdb471f818 __pthread_cond_wait_common (libc.so.6 +
0x87818)
#2 0x7fcdb4d3509a virCondWait (libvirt.so.0 + 0x13509a)
#3 0x7fcdb4d35b83 n/a (libvirt.so.0 + 0x135b83)
#4 0x7fcdb4d351e8 n/a (libvirt.so.0 + 0x1351e8)
#5 0x7fcdb47203ec start_thread (libc.so.6 + 0x883ec)
#6 0x7fcdb47a0a4c __clone3 (libc.so.6 + 0x108a4c)

Stack trace of thread 2258:
#0 0x7fcdb471d156 __futex_abstimed_wait_common64
(libc.so.6 + 0x85156)
#1 0x7fcdb471f818 __pthread_cond_wait_common (libc.so.6 +
0x87818)
#2 0x7fcdb4d3509a virCondWait (libvirt.so.0 + 0x13509a)
#3 0x7fcdb4d35b83 n/a (libvirt.so.0 + 0x135b83)
#4 0x7fcdb4d351e8 n/a (libvirt.so.0 + 0x1351e8)
#5 0x7fcdb47203ec start_thread (libc.so.6 + 0x883ec)
#6 0x7fcdb47a0a4c __clone3 (libc.so.6 + 0x108a4c)

Stack trace of thread 2311:
#0 0x7fcdb471d156 __futex_abstimed_wait_common64
(libc.so.6 + 0x85156)
#1 0x7fcdb471f818 __pthread_cond_wait_common (libc.so.6 +
0x87818)
#2 0x7fcdb4d3509a virCondWait (libvirt.so.0 + 0x13509a)
#3 0x7fcdb4d35b83 n/a (libvirt.so.0 + 0x135b83)
#4 0x7fcdb4d351e8 n/a (libvirt.so.0 + 0x1351e8)
#5 0x7fcdb47203ec start_thread (libc.so.6 + 0x883ec)
#6 0x7fcdb47a0a4c __clone3 (libc.so.6 + 0x108a4c)

Stack trace of thread 2245:
#0 0x7fcdb4793a1f __GI___poll (libc.so.6 + 0xfba1f)
#1 0x7fcdb4b14277 n/a (libglib-2.0.so.0 + 0x5a277)
#2 0x7fcdb4b14930 g_main_context_iteration
(libglib-2.0.so.0 + 0x5a930)
#3 0x7fcdb4cde034 virEventGLibRunOnce (libvirt.so.0 +
0xde034)
#4 0x7fcdb4e013d2 virNetDaemonRun (libvirt.so.0 +
0x2013d2)
#5 0x5616ccf0a480 main (libvirtd + 0x27480)
#6 0x7fcdb46bf6ca __libc_start_call_main (libc.so.6 +
0x276ca)
#7 0x7fcdb46bf785 __libc_start_main_impl (libc.so.6 +
0x27785)
#8 0x5616ccf0ad21 _start (libvirtd + 0x27d21)

Stack trace of thread 2313:
#0 0x7fcdb471d156 __futex_abstimed_wait_common64
(libc.so.6 + 0x85156)
#1 0x7fcdb471f818 __pthread_cond_wait_common (libc.so.6 +
0x87818)
#2 0x7fcdb4d3509a virCondWait (libvirt.so.0 + 0x13509a)
#3 0x7fcdb4d35b83 n/a (libvirt.so.0 + 0x135b83)
#4 0x7fcdb4d351e8 n/a (libvirt.so.0 + 0x1351e8)
#5 0x7fcdb47203ec start_thread (libc.so.6 + 0x883ec)
#6 0x7fcdb47a0a4c __clone3 (libc.so.6 + 0x108a4c)

Stack trace of thread 2263:
#0 0x7fcdb471d156 __futex_abstimed_wait_common64
(libc.so.6 + 0x85156)
#1 0x7fcdb471f818 __pthread_cond_wait_common (libc.so.6 +
0x87818)
#2 0x7fcdb4d3509a virCondWait (libvirt.so.0 + 0x13509a)
#3 0x7fcdb4d35c84 n/a (libvirt.so.0 + 0x135c84)
#4 0x7fcdb4d351e8 n/a (libvirt

Bug#1056123: bullseye-pu: package conda-package-handling/1.7.2-2+deb11u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: conda-package-handl...@packages.debian.org, sanv...@debian.org
Control: affects -1 + src:conda-package-handling

[ Reason ]
This upload fixes Bug #976506: FTBFS due to flaky test.

Upstream added a time condition to skip the failing test,
but that just moved the problem to a future which has already arrived.

This upload removes the condition and skip the test without conditions,
as it was done already in unstable.

[ Impact ]
Anybody trying to build the package from source may get the error:

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/conda-package-handling.html

[ Tests ]
There are no code changes. I've verified that the package
now builds from source.

[ Risks ]
Very low. No code changes. Patch is trivial.

[ 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 ]
The attached patch is in git diff format, which is
a little bit clearer than debdiff because the existing
patch has been renamed.

[ Other info ]
The package is already uploaded.diff --git a/debian/changelog b/debian/changelog
index 306c900..c06fada 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+conda-package-handling (1.7.2-2+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Disable flaky test. Closes: #976506.
+
+ -- Santiago Vila   Fri, 17 Nov 2023 11:30:00 +0100
+
 conda-package-handling (1.7.2-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/series b/debian/patches/series
index 3d1dca5..b36fda0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,4 +1,4 @@
 fix_linking.patch
 fix_test.patch
 fix-out-dir.patch
-extend-test-datetime-to-dec-2021.patch
+skip-test-timeline.patch
diff --git a/debian/patches/extend-test-datetime-to-dec-2021.patch 
b/debian/patches/skip-test-timeline.patch
similarity index 71%
rename from debian/patches/extend-test-datetime-to-dec-2021.patch
rename to debian/patches/skip-test-timeline.patch
index 4b22288..78aee74 100644
--- a/debian/patches/extend-test-datetime-to-dec-2021.patch
+++ b/debian/patches/skip-test-timeline.patch
@@ -1,9 +1,10 @@
-Description: Extend datetime to Dec 1, 2021 in 
test_secure_refusal_to_extract_abs_paths to prevent failing tests in arm64.
+Description: Stop extending datetime in 
test_secure_refusal_to_extract_abs_paths to prevent failing tests in arm64.
 Upstream has confirmed this here: 
https://github.com/conda/conda-package-handling/issues/74#issuecomment-739349646
 Author: Nilesh Patra 
 Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976506
 Forwarded: https://github.com/conda/conda-package-handling/pull/75
-Last-Update: 2020-12-06
+Last-Update: 2023-11-17
+
 --- a/tests/test_api.py
 +++ b/tests/test_api.py
 @@ -183,7 +183,7 @@
@@ -11,7 +12,7 @@ Last-Update: 2020-12-06
  
  
 -@pytest.mark.skipif(datetime.now() <= datetime(2020, 12, 1), reason="Don't 
understand why this doesn't behave.  Punt.")
-+@pytest.mark.skipif(datetime.now() <= datetime(2021, 12, 1), reason="Don't 
understand why this doesn't behave.  Punt.")
++@pytest.mark.skip(reason="Don't understand why this doesn't behave.  Punt.")
  def test_secure_refusal_to_extract_abs_paths(testing_workdir):
  with tarfile.open('pinkie.tar.bz2', 'w:bz2') as tf:
  open('thebrain', 'w').close()

Bug#1055696: 1055696: more info

[Andrius Merkys]

Hi,

I have reassigned this issue to python3-rdkit as Python 3.12 specific 
issue seems to be confined to python3-rdkit:


$ python3.12 -c 'import rdkit'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/rdkit/__init__.py", line 6, in 


from . import rdBase
ImportError: cannot import name 'rdBase' from partially initialized 
module 'rdkit' (most likely due to a circular import) 
(/usr/lib/python3/dist-packages/rdkit/__init__.py)


Andrius

Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)

[Maytham Alsudany]

Hi Nilesh,

On Fri, 2023-11-17 at 14:11 +0530, Nilesh Patra wrote:
> This looks like _really_ old code, and there's
> golang-github-go-logfmt-logfmt in debian already.
> 
> Can the code in the target package be patched to use go-logfmt or is it
> using specific features from kr-logfmt?

The target package (golang-github-humanlogio-humanlog[1][2]) uses the Handler
type from kr-logfmt for its own Handler type (handler.go), and this is the only
occurrence of kr-logfmt in the code.

golang-github-go-logfmt-logfmt doesn't have this Handler type that's being used,
and humanlog already uses go-logfmt as much as it can

I've made an issue upstream at [3] regarding this and I've patched out the
Handler type completely from humanlog for now.

Would you like me to close this RFS bug and the ITP?

[1]: https://bugs.debian.org/1055740
[2]:
https://salsa.debian.org/go-team/packages/golang-github-humanlogio-humanlog/
[3]: https://github.com/humanlogio/humanlog/issues/71

Kind regards,
Maytham



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

Bug#1052573: dicomscope: FTBFS with OpenJDK 21 due to unsupported javac source/target level 7

[Vladimir Petko]

Dear Maintainers,

Would it be possible to consider a merge proposal[1] that replaces a
hardcoded value with a variable provided by java-common?

Thank you for considering this patch!

Best Regards,
 Vladimir.

[1] https://salsa.debian.org/med-team/dicomscope/-/merge_requests/1

Bug#1056121: mariadb-server: debian-start uses obsolate hardcoded /etc/mysql/debian.cnf

[Sebastian Fiedler]

Package: mariadb-server
Version: 1:10.11.4-1~deb12u1
Severity: normal

Dear Maintainer,

debian-start uses obsolate hardcoded /etc/mysql/debian.cnf. The file
will bee removed in the future. When this file exists, I get
"Access denied for user 'root'@'localhost'" with mariaDB Unix Socket 
Authentication Plugin.

Here is a possible fix:

--- debian-start2023-11-17 10:22:20.02000 +0100
+++ debian-start.new2023-11-17 09:57:04.7 +0100
@@ -17,11 +17,15 @@
   . /etc/default/mariadb
 fi

-MYSQL="/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf"
-MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
+if [ -f /etc/mysql/debian.cnf ]; then
+  EXTRAPARAM='--defaults-file=/etc/mysql/debian.cnf'
+fi
+
+MYSQL="/usr/bin/mysql $EXTRAPARAM"
+MYADMIN="/usr/bin/mysqladmin $EXTRAPARAM"
 # Don't run full mysql_upgrade on every server restart, use --version-check to 
do it only once
-MYUPGRADE="/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf 
--version-check --silent"
-MYCHECK="/usr/bin/mysqlcheck --defaults-file=/etc/mysql/debian.cnf"
+MYUPGRADE="/usr/bin/mysql_upgrade $EXTRAPARAM --version-check --silent"
+MYCHECK="/usr/bin/mysqlcheck $EXTRAPARAM"
 MYCHECK_SUBJECT="WARNING: mysqlcheck has found corrupt tables"
 MYCHECK_PARAMS="--all-databases --fast --silent"
 MYCHECK_RCPT="${MYCHECK_RCPT:-root}"


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages mariadb-server depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  galera-4   26.4.13-1
ii  gawk   1:5.2.1-2
ii  iproute2   6.1.0-3
ii  libc6  2.36-9+deb12u3
ii  libdbi-perl1.643-4
ii  libpam0g   1.5.2-6+deb12u1
ii  libssl33.0.11-1~deb12u2
ii  libstdc++6 12.2.0-14
ii  lsof   4.95.0-1
ii  mariadb-client 1:10.11.4-1~deb12u1
ii  mariadb-common 1:10.11.4-1~deb12u1
ii  mariadb-server-core1:10.11.4-1~deb12u1
ii  passwd 1:4.13+dfsg1-1+b1
ii  perl   5.36.0-7
ii  procps 2:4.0.2-3
ii  psmisc 23.6-1
ii  rsync  3.2.7-1
ii  socat  1.7.4.4-2
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages mariadb-server recommends:
pn  libhtml-template-perl   
pn  mariadb-plugin-provider-bzip2   
pn  mariadb-plugin-provider-lz4 
pn  mariadb-plugin-provider-lzma
pn  mariadb-plugin-provider-lzo 
pn  mariadb-plugin-provider-snappy  
ii  pv  1.6.20-1

Versions of packages mariadb-server suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
pn  mariadb-test   
ii  netcat-openbsd 1.219-1

-- Configuration Files:
/etc/mysql/mariadb.conf.d/50-server.cnf changed [not included]

-- debconf information excluded



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056122: slurmctld.log not available after logrotate

[Alois Schlögl]

Package: slurmctld
Version: 22.05.8-4+deb12u1
Severity: normal
Tags: patch
X-Debbugs-Cc: alois.schlo...@gmail.com


Dear Maintainer,

   After migrating the slurmctld from debian11/slurm20 to a host with 
debian12/slurm22,
   /var/log/slurm/slurmctld.log was rotated at midnight, to 
/var/log/slurm/slurmctld.log.1.gz

   but no /var/log/slurm/slurmctld.log was generated.

   syslog of logrotate showed this log message:

   2023-11-17T00:00:01.825407+01:00 l74 logrotate[3441040]: 
start-stop-daemon: matching only on non-root pidfile 
/var/run/slurm/slurmctld.pid is insecure
   2023-11-17T00:00:03.356036+01:00 l74 logrotate[3440981]: error: 
Compressing program wrote following message to stderr when compressing 
log /var/log/slurm/slurmctld.log.1:
   2023-11-17T00:00:03.356307+01:00 l74 logrotate[3440981]: gzip: 
stdin: file size changed while zipping



   I believe the following patch fixes the issue:

   l74:# diff -uw /etc/logrotate.d/slurmctld.orig 
/etc/logrotate.d/slurmctld

--- /etc/logrotate.d/slurmctld.orig 2023-11-17 10:15:45.751842740 +0100
+++ /etc/logrotate.d/slurmctld  2023-11-17 10:15:30.132636120 +0100
@@ -3,7 +3,7 @@
   missingok
   nocopytruncate
   nocreate
-  nodelaycompress
+  delaycompress
   nomail
   notifempty
   noolddir

I'd like suggesting to include this change in the slurmctld package.


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/56 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages slurmctld depends on:
ii  libc6    2.36-9+deb12u3
ii  munge    0.5.15-2
ii  slurm-client 22.05.8-4+deb12u1
ii  slurm-wlm-basic-plugins  22.05.8-4+deb12u1
ii  ucf  3.0043+nmu1

slurmctld recommends no packages.

slurmctld suggests no packages.

-- Configuration Files:
/etc/logrotate.d/slurmctld changed:
/var/log/slurm-llnl/slurmctld.log /var/log/slurm/slurmctld.log {
  compress
  missingok
  nocopytruncate
  nocreate
  delaycompress
  nomail
  notifempty
  noolddir
  rotate 12
  sharedscripts
  size=5M
  postrotate
  /usr/sbin/invoke-rc.d --quiet slurmctld reconfig >/dev/null
  /bin/sleep 1
  endscript
}