Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code

[Xiyue Deng]

Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20240113.4c6d636-1 [RC] 
[Team] -- Emacs major mode for editing scala source code

Xiyue Deng  writes:

> Hi,
>
> Xiyue Deng  writes:
>
>> Nicholas D Steeves  writes:
>>
>>> Hi,
>>>
>>> Paul Wise  writes:
>>>
 On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote:

> I think dh_auto_clean is the right place, because the build failure is
> because that the clean target requires the existence of
> scala-mode-pkg.el, which is generated by Cask.  As we don't have Cask,
> we need to provide this before dh_auto_clean runs.
>>>
>>> The generation of this metadata, and file, is one of dh_elpa's primary
>>> functions.  See the section of the dh_elpa man page that discusses
>>> DEB_VERSION_UPSTREAM.
>>
>> Ah I see what you mean: as long as dh_elpa can detect the version
>> correctly we don't need to provide an actual *-pkg.el file and can just
>> let dh_elpa generate it, which also avoids the potential policy
>> violation Paul pointed out.
>>
>> So now I make override_dh_auto_clean to call dh_elpa to generate this
>> file for use.  However, as the generated file is "buried" pretty deep in
>> the generated directory, the command becomes pretty long, but it works.
>> Admittedly that requiring a generated file during clean is pretty exotic
>> and I haven't encountered it elsewhere (yet) which is good.
>>
>> New handling strategy pushed to team repo.  PTAL.
>>
>>>
>>> Read Policy §4.9 closely; Cask cannot be used.
>>>
>>> Grep the buildlog for "dh_" and if you'd like to see a more
>>> comprehensive list of applicable entry points in the sequence, try
>>>
>>>   $ dh binary-indep --no-act
>>>
>>> It's also worth reading the dh man page.
>>
>> Ack.
>>
>>>
 I think it is against ftp-master rules to have generated files
 present that can't be built using only tools from Debian main.
>>>
>>> Yes, and thank you for bringing this up.
>>>
 So I think you would need to package Cask first?
>>>
>>> Cask is not relevant nor needed, and dh_elpa is used.  Whenever this
>>> topic comes up on IRC, new contributors are briefed and are additionally
>>> referred to the RFP for Cask, where the unsuitability of this type of
>>> tool for Debian packaging is discussed (#837922).  It's also worth
>>> noting that dh_elpa was written by people by current and/or past members
>>> of the Debian TC.
>>>
>>> Xiyue Deng  writes:
>>>
 Cask and similar tools like Eask and Eldev are tools that automatically
 install dependencies of an Emacs addon package, which doesn't use and
 circumvents the system package management.  I think the Emacsen team
 chooses not to package those tools and prefers using dh-elpa for the
 job, and may override build target to avoid using those tools.
>>>
>>> If you're familiar with the concept of "hats", then when you're working
>>> on debian/* you need to put on your Debian packaging hat, and when
>>> you're working on !(debian/*) you use your upstream
>>> development/debugging/packaging hat.  These tools are not relevant to
>>> Debian packaging and referring to them is not useful for describing
>>> packaging problems or decisions; there will always be a more direct and
>>> useful description.
>>
>> I think those external tools are not completely irrelevant but just in
>> the sense that we do it the Debian way.  Usually they provide two types
>> of functions: 1) automatic dependency management, and 2) automatic file
>> generation required for testing and distribution through elpa.  In
>> Debian, the former is handled by apt, and the latter by dh_elpa, and we
>> take effort to make sure they behave the same.
>>
>>>
>>> Cheers,
>>> Nicholas
>>>


It looks like the bug was archived so the previous mail didn't reach
BTS.  So unarchived, reopened, and retitle the bug with newer snapshot,
and also resending the following from previous message.

>
> With the release of the new policy version, I have done some more clean
> up to the package and update team repo and mentors.  PTAL.  TIA!

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#826576: Additional information

[Ron Murray]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sorry, I forgot to add some information. I'm running Debian Testing on
amd64, and the package details are:

Package: evolution
Version: 3.50.3-1
Priority: optional
Section: gnome
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmYjUTcACgkQEvfoZbXi
52FW3BAAm7G51p3eesI8Oic80o3Om1cXumi3Ry3CAt70u4dzZ7eSv/l/pSjgBp40
Q2Vkzi8ixb7tvAy2TobRP5M36e/BNypIUguxDT3TjwJdU0QRpTox9MrGaIcjWYbF
3u4+AQu6xL5SoYUY+CROkXI+qgcYXA36F23cYHQNmUbNV35O/1rN2C9YcO+qiXXR
+WKCP5erGePn6jwpRKDOri1FnCELzYgiy3U2qMglmxeABitEhvEFLMP7cV3h1xV3
sJlexs3SibHMGIjj1euOdP72JwSvENVHOwTrN4vPRJgUqsmgYpIinCfV+ZDpYPOw
IsUipFQPgj96c6KjM9QBweBwNfTnejNK1gtHfTzzSN+U+naznf1iBMqGRCgyT+2N
t7EF/Y5nOJH7RI/0zwc70VzsbEnJdKBmCYWcptE4e/PL350ax/kXSDbdAvanIc51
uVvZyuv9QCZhbgdhbkHZYocH43CTOew449kuhKiSy9AFKWD5GPNYviX1W5ZjV1V4
R+PzE9OncPIgEzmN1ph9u4dfB90kzl64OjPviL5xcazDTBj5wVUmzks3R6RlhV42
plFZhxs8Mhz2aCXfmlMZYKlDbvVtBEdd55CL/c9u1M5XOwSbpRyHzeqsOUcONgWD
Lz9s4f2pvNmyPT+VDhsZ3SrPJTFd5MB4CCx4fQWEf34DL3NoEsE=
=JnJj
-END PGP SIGNATURE-



-- 
Ron Murray  
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761 

Bug#1067539: Moved my depending packages to autopkgtest

[Joachim Zobel]

Hi.

My packages gap-polymaking and gap-hapcryst are now using autopkgtest.
In both cases the FTBFS was caused by tests running as part of the
build, so my problem is solved. 

Sincerely,
Joachim

Bug#1037699: intel-mediasdk: ftbfs with GCC-13

[Zixing Liu]

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

Dear Maintainer,

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

  * debian/patches/fix-missing-includes.patch: Add missing header
includes. (LP: #2062948).


Thanks for considering the patch.


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

Kernel: Linux 6.5.0-28-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru intel-mediasdk-22.5.4/debian/patches/fix-missing-includes.patch 
intel-mediasdk-22.5.4/debian/patches/fix-missing-includes.patch
--- intel-mediasdk-22.5.4/debian/patches/fix-missing-includes.patch 
1969-12-31 17:00:00.0 -0700
+++ intel-mediasdk-22.5.4/debian/patches/fix-missing-includes.patch 
2024-04-19 21:28:34.0 -0600
@@ -0,0 +1,18 @@
+Description: Add missing header includes
+Author: Zixing Liu 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037699
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2062948
+Forwarded: no
+Last-Update: 2024-04-19
+---
+--- intel-mediasdk-22.5.4.orig/api/mfx_dispatch/linux/mfxparser.cpp
 intel-mediasdk-22.5.4/api/mfx_dispatch/linux/mfxparser.cpp
+@@ -22,7 +22,7 @@
+ #include 
+ #include 
+ #include 
+-
++#include 
+ #include 
+ 
+ #include "mfxloader.h"
diff -Nru intel-mediasdk-22.5.4/debian/patches/series 
intel-mediasdk-22.5.4/debian/patches/series
--- intel-mediasdk-22.5.4/debian/patches/series 2022-10-18 05:16:05.0 
-0600
+++ intel-mediasdk-22.5.4/debian/patches/series 2024-04-19 21:13:23.0 
-0600
@@ -1 +1,2 @@
 #placeholder
+fix-missing-includes.patch

Bug#1068772: uhd-host: usrpctl fails to run

[A. Maitland Bottoms]

The quick fix is for you to install the python3-uhd package.

Fixing this bug will either be done by moving usrpctl
to the python3-uhd package, or just add python3-uhd
to the uhd-host Depends: list (or at least Recommends:).

-Maitland

Bug#1069329: diffoscope: XZ: compare metadata before comparing compressed data

[Paul Wise]

Package: diffoscope
Severity: wishlist
X-Debbugs-Cc: Sam James 

When comparing two XZ compressed files that decompress to identical
data, please compare the metadata before comparing compressed data.

The xz --list option can be used for this, from the manual page:

   Print information about compressed files. No uncompressed output is
   produced, and no files are created or removed. In list mode, the 
   program cannot read the compressed data from standard input or from
   other unseekable sources.
   
   The default listing shows basic information about files, one file
   per line. To get more detailed information, use also the --verbose
   option. For even more information, use --verbose twice, but note
   that this may be slow, because getting all the extra information
   requires many seeks. The width of verbose output exceeds 80
   characters, so piping the output to, for example, less -S may be
   convenient if the terminal isn't wide enough.
   
   The exact output may vary between xz versions and different locales.
   For machine-readable output, --robot --list should be used.

In addition, the filename printed is the one from the command-line,
there does not appear to be filename metadata embedded in XZ files,
so the filename could be stripped before comparison where possible,
since diffoscope already compares filenames at a different layer.

The human-readable output may change between xz versions, so the
filename stripping will be brittle and could break on xz updates,
but comparing human-readable output is more user-friendly than
comparing the robot output, so any stripping would have to be
best-effort, but since any tests for it could break on xz upgrades,
and probably many comparisons will be between the same filenames within
different dirs, it might not be worth adding filename stripping yet,
until xz itself offers an option for hiding the filenames.

In addition, currently the xz --list option only supports the xz file
format and does not support the lzma and lzip file formats.

   $ echo foo > foo
   $ xz -0 < foo > foo.0.xz
   $ xz -9 < foo > foo.9.xz
   
   $ diffoscope foo.0.xz foo.9.xz 
   --- foo.0.xz
   +++ foo.9.xz
   │┄ Format-specific differences are supported for XZ compressed files but no 
file-specific differences were detected; falling back to a binary diff. file(1) 
reports: XZ compressed data, checksum CRC64
   @@ -1,4 +1,4 @@
: fd37 7a58 5a00 0004 e6d6 b446 0200 2101  .7zXZ..F..!.
   -0010: 0c00  8f98 419c 0100 0366 6f6f 0a00  ..Afoo..
   +0010: 1c00  10cf 58cc 0100 0366 6f6f 0a00  ..Xfoo..
0020: ffd7 ac5a 3031 9cf2 0001 1c04 6f2c 9cc1  ...Z01..o,..
0030: 1fb6 f37d 0100  0004 595a...}..YZ
   
   $ diff -u <(xz --list foo.0.xz) <(xz --list foo.9.xz)
   --- /dev/fd/63   2024-04-20 08:26:27.769377608 +0800
   +++ /dev/fd/62   2024-04-20 08:26:27.769377608 +0800
   @@ -1,2 +1,2 @@
Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
   -1   1 60 B  4 B---  CRC64   foo.0.xz
   +1   1 60 B  4 B---  CRC64   foo.9.xz
   
   $ diff -u <(xz --list --verbose foo.0.xz) <(xz --list --verbose foo.9.xz)
   --- /dev/fd/63   2024-04-20 08:26:43.701196927 +0800
   +++ /dev/fd/62   2024-04-20 08:26:43.705196881 +0800
   @@ -1,4 +1,4 @@
   -foo.0.xz (1/1)
   +foo.9.xz (1/1)
  Streams:   1
  Blocks:1
  Compressed size:   60 B
   
   $ diff -u <(xz --list --verbose --verbose foo.0.xz) <(xz --list --verbose 
--verbose foo.9.xz)
   --- /dev/fd/63   2024-04-20 08:26:56.029056126 +0800
   +++ /dev/fd/62   2024-04-20 08:26:56.029056126 +0800
   @@ -1,4 +1,4 @@
   -foo.0.xz (1/1)
   +foo.9.xz (1/1)
  Streams:   1
  Blocks:1
  Compressed size:   60 B
   @@ -11,7 +11,7 @@
 1 1   0   0  60
   4---  CRC640
  Blocks:
Stream Block  CompOffsetUncompOffset   TotalSize  
UncompSize  Ratio  Check  CheckVal  Header  FlagsCompSize   
 MemUsage  Filters
   - 1 1  12   0  28
   4  7.000  CRC64  f29c31305aacd7ff  12  --  8 
  1 MiB  --lzma2=dict=256KiB
   -  Memory needed: 1 MiB
   + 1 1  12   0  28
   4  7.000  CRC64  f29c31305aacd7ff  12  --  8 
 65 MiB  --lzma2=dict=64MiB
   +  Memory needed: 65 MiB
  Sizes in headers:  No
  Minimum XZ Utils version: 5.0.0
   
   $ diff -u <(xz --robot --list --verbose --verbose foo.0.xz) <(xz --robot 
--list --verbose --verbose foo.9.xz)
   --- /dev/fd/63   2024-04-20 08:31:42.445584805 +0800
   +++ /dev/fd/62   2024-04-20 08:31:42.449584755 +0800
   @@ -1,6 +1,6 @@
   -namefoo.0.xz
   

Bug#1069328: Installation of ksmbd-tools without a config file spams the syslog

[Eddie Carswell]

Apparently I misspelled my own email address..


R/S


Eddie Carswell

Bug#1069328: Installation of ksmbd-tools without a config file spams the syslog

[Eddie Carswell]

Package: ksmbd-tools
Version: 3.4.7-1
Severity: minor
X-Debbugs-Cc: edidecarswel...@yahoo.com

After installing the ksmbd-tools package, it enables and starts `ksmbd.service`
by default, which starts `ksmbd.mountd`. The problem arises when `ksmbd.mountd`
spawns a `ksmbd-worker` and the worker attempts to read the nonexistent config
file `/etc/ksmbd/ksmbd.conf`. An example file `/etc/ksmbd/ksmbd.conf.example`
is provided, that requires user intervention to get the proper config setup.

Because of this disconnect, the worker process dies and `ksmbd.mountd` tries to
spawn another one in its place. This happens almost every second, flooding the
system logs, and continues indefinitely until the user stops `ksmbd.service` or 
places a file at `/etc/ksmbd/ksmbd.conf` (even an empty file works). 

I see two solutions here:

1. Create an empty file at the expected location, or

2. Add a `ConditionPathExists` statement to the service:

mkdir /etc/systemd/system/ksmbd.service.d
cat 

Bug#1068024: revert to version that does not contain changes by bad actor

[Christoph Anton Mitterer]

Hey.


On Sun, 2024-03-31 at 01:46 +, Thorsten Glaser wrote:
> Yes, a multi-team task force is working on it and will inform users
> once it is known how to proceed, inclusing how much to throw away
> and rebuild.

Kindly wanted to ask whether anything has come out meanwhile of that?


I've tried to follow quite extensively what the various reverse
engineering efforts (e.g. [0], [1], [2], [3]) found out or what's
revealed on index pages like [4] or [5].

It feels as if there are still many discussions about how to prevent
such things in the future, but less so about the concrete fallout of
the particular backdoor, where it seems most people were lead to
conclude from media reports, that an attack was only possible if sshd
was actually running an reachable.

This may of course be true, which would mean that most people are
actually safe and we had quite some luck this time:
- servers, because they run stable distros that haven't had the
  backdoor
- workstations/laptops, because they typically don't run a publicly
  listending sshd

But there are still new findings about the backdoor every now and then,
like that it may read/write on IPC sockets (contained in [2]) and I've
read similar[6] without the restriction on IPC.
Also I've seen some vague statements[7] that it might "install" public
keys (didn't really grasp what was meant there - something like "in
authorized_keys"). And one report[8] talked about it collecting
usernames and IPs and passing the on to some function with unknown
purpose.

It also seems like these effort focus mostly on the 5.6.1 version and
while it's said that the 5.6.0 version is quite similar, who knows the
exact details!?


In any case and (too) long story short:

It would be nice to know whether there's still work done about finding
out whether people who had the malicious code on their systems (in any
version of the backdoor), but
- had sshd not running at all
and/or
- it was not reachable from the internet

can feel safe.

Or whether it may be possible that:
- the backdoor did call home (loaded commands from there, leaked
  private keys or so from the system)
- used completely different vectors not involving sshd
- or somehow else infested the system


Right now people might still have backups to torch their possibly
compromised systems and start over from a safe sate.


So Thorsten, in case you or someone else is aware of any [intermediate]
results from these task forces ([9[) it would be nice to hear about
them or better even in form of some "official" statement from Debian.


Thanks,
Chris.


[0] https://discord.gg/u6MzmQm5
[1] https://github.com/smx-smx/xzre
[2] 
https://github.com/binarly-io/binary-risk-intelligence/tree/master/xz-backdoor
[3] https://securelist.com/xz-backdoor-story-part-1/112354/
[4] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
[5] https://github.com/przemoc/xz-backdoor-links
https://przemoc.github.io/xz-backdoor-links/  (rendering of that)
[6] 
https://discord.com/channels/1223666474091020432/1223666474972090430/1230974749522530304
[7] 
https://discord.com/channels/1223666474091020432/1223666474972090430/1230173131746840606
[8] https://isc.sans.edu/diary/30802
[9] E.g. on d-d https://lists.debian.org/debian-devel/2024/03/msg00338.html
Moritz Mühlenhoff has mentioned that some company was working on it
and results were expected in some time.

Bug#1068538: ruby-ffi-libarchive: arch:all package depends on pre-t64 library

[Bastian Germann]

This can be fixed with a binNMU.

Bug#1059673: trololio: autopkgtest failure with Python 3.12

[me]

Hi,

I'm the author of Trololio.
I've never posted to Debian mailing lists, so apologies if I don't
follow proper etiquette. I did take a quick look at the relevant Wiki
page and CoC.

Trololio was written to make Python 3 async easily back-compatible
with Python 2.
The context is Trollius was a back-port of Python 3's asyncio module
to Python 2, and Trololio provides a compatibility layer to support
both with a single codebase.
Similar to what the six module does for general 2/3 compatibility.

Nowadays, Python 2 compatibility is not a priority for most anymore,
and Trollius has been deprecated since at least 2018 [1].
And as per the discussion on GitHub, pagure-ev-server seems to be the
only reverse dependency. Its author removed the dependency in a commit
yesterday [2].

With that in mind, I think it's best to retire the package.
If you do need to keep it working for stable, then I can try and update
it to use importlib. Though I would rather not spend time on a Python 2
related project these days :)

Thanks,
ThinkChaos (they/them)

[1] 
https://github.com/jamadden/trollius/commit/479788fb7b568c0c685599e55e0e98cab9fe474c
[2] 
https://pagure.io/pagure/c/59edf699016d1049fdaecd1ff728ad8eeb355b64?branch=master

Bug#1069327: rapid-photo-downloader: Depends on pre-t64 name

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is attached.diff -Nru rapid-photo-downloader-0.9.36/debian/changelog 
rapid-photo-downloader-0.9.36/debian/changelog
--- rapid-photo-downloader-0.9.36/debian/changelog  2024-03-14 
15:01:42.0 +
+++ rapid-photo-downloader-0.9.36/debian/changelog  2024-04-19 
22:36:39.0 +
@@ -1,3 +1,10 @@
+rapid-photo-downloader (0.9.36-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Update build dependency to libgphoto2-6t64 (Closes: #1069327)
+
+ -- Bastian Germann   Fri, 19 Apr 2024 22:36:39 +
+
 rapid-photo-downloader (0.9.36-1) unstable; urgency=medium
 
   [ Tino Mettler ]
diff -Nru rapid-photo-downloader-0.9.36/debian/control 
rapid-photo-downloader-0.9.36/debian/control
--- rapid-photo-downloader-0.9.36/debian/control2024-03-14 
15:01:42.0 +
+++ rapid-photo-downloader-0.9.36/debian/control2024-04-19 
22:29:48.0 +
@@ -32,7 +32,7 @@
  gstreamer1.0-libav,
  gstreamer1.0-plugins-good,
  ifuse,
- libgphoto2-6,
+ libgphoto2-6t64,
  libimage-exiftool-perl,
  libimobiledevice-utils,
  libmediainfo0v5,

Bug#1069327: rapid-photo-downloader: Depends on pre-t64 name

[Bastian Germann]

Package: rapid-photo-downloader
Version: 0.9.36-1
Severity: important

The package depends on libgphoto2-6, which was replaced by libgphoto2-6t64.

Bug#1067209: jruby: please update libfixposix4 runtime depency

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is attached.diff -Nru jruby-9.4.6.0+ds/debian/changelog jruby-9.4.6.0+ds/debian/changelog
--- jruby-9.4.6.0+ds/debian/changelog   2024-02-29 00:39:52.0 +
+++ jruby-9.4.6.0+ds/debian/changelog   2024-04-19 22:06:26.0 +
@@ -1,3 +1,12 @@
+jruby (9.4.6.0+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Gianfranco Costamagna ]
+  * d/control: update libfixposix4 runtime depency (Closes: #1067209)
+
+ -- Bastian Germann   Fri, 19 Apr 2024 22:06:26 +
+
 jruby (9.4.6.0+ds-1) unstable; urgency=medium
 
   * New upstream version 9.4.6.0+ds
diff -Nru jruby-9.4.6.0+ds/debian/control jruby-9.4.6.0+ds/debian/control
--- jruby-9.4.6.0+ds/debian/control 2024-02-29 00:39:52.0 +
+++ jruby-9.4.6.0+ds/debian/control 2024-04-19 22:05:30.0 +
@@ -62,7 +62,7 @@
  libasm-java (>= 9.5),
  libbackport9-java (>= 1.10),
  libdirgra-java,
- libfixposix4,
+ libfixposix4t64,
  libheadius-options-java (>= 1.4),
  libinvokebinder-java (>= 1.13),
  libjansi1-java,

Bug#1068801: (No Subject)

[mYnDstrEAm]

When I run apper from the console there is this:

> apper.lib: errorCode:  PackageKit::Transaction::ErrorNotAuthorized "Failed to 
> obtain authentication."
> apper.lib: PackageKit::Transaction::ExitFailed 
> PackageKit::Transaction::RoleInstallPackages
> kf.kwidgetsaddons: Invalid pixmap specified.

The problems means when installing packages apt-get needs to be used. Something 
is broken there. I thought it used to happen because of unattended-upgrades 
which is not even installed anymore. Let me know if I should try or check 
something.

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Santiago Vila]

El 25/3/24 a las 20:12, Chris Lamb escribió:

Alberto Bertogli wrote:


If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.


Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.


Hi.

I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.

Several cloud vendors (like GCP, AWS or Hetzner) offer arm64 machines,
billed hourly and relatively cheap.

Also (but only if your stomach allows it :-), Oracle Cloud has arm64 machines in
their Free Tier. In this case I think they only have Ubuntu and not Debian,
but this would be not matter if you are using a Debian chroot.

Thanks.

Bug#1066483: scrollz: FTBFS: configure: error: Fatal: You must get working getaddrinfo() function.

[Mike Markley]

I've updated this package to a newer upstream release and it seems to
build fine on my own amd64 system.

However, I haven't had a key in the Debian key ring for quite some time
and I'm not able to upload.

I'm starting here in the hopes that someone who's also interested in this
package will see it; I'll seek a sponsor to upload it on my behalf soon if
this bug doesn't catch anyone's eye.

-- 
Mike Markley 

Bug#1069326: dh-elpa: Don't rename files under test directories during autopkgtest by default

[Xiyue Deng]

Package: dh-elpa
Version: 2.0.17
Severity: normal
X-Debbugs-Cc: none, Xiyue Deng 

During autopkgtest, dh_elpa_test will rename the non-test source files
so as to ensure we are running the test using the Emacs add-on modules
from the installed package instead of from the source directories.  The
way that dh_elpa_test currently works is to only keep files that have a
test case defined in it.  However, this doesn't take utilities and
artifacts, which are usually defined under test directories, under
consideration, and without those the tests are broken as well.

Therefore I'd like to propose retaining all files under test directories
from being renamed in autopkgtest.  I have been testing a fix in [1]
which seems to work in common cases.  I have also attached the patches
at the end of the email as well.  Please review and comment.  TIA!

[1] 
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...retain-test-files-in-autopkgtest?from_project_id=18920

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

Kernel: Linux 6.1.0-20-amd64 (SMP w/16 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 dh-elpa depends on:
ii  debhelper   13.11.4
ii  emacs   1:29.3+1-2~bpo12+0manphiz1
ii  emacs-gtk [emacs]   1:29.3+1-2~bpo12+0manphiz1
ii  libarray-utils-perl 0.5-3
ii  libconfig-tiny-perl 2.28-2
ii  libdebian-source-perl   0.122
ii  libdpkg-perl1.21.22
ii  libfile-find-rule-perl  0.34-3
ii  libtext-glob-perl   0.11-3
ii  perl5.36.0-7+deb12u1

dh-elpa recommends no packages.

dh-elpa suggests no packages.

-- no debconf information
>From 48514b41927f8601c6e1af7ebcf49c4af9a16b54 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Fri, 19 Apr 2024 14:14:31 -0700
Subject: [PATCH 1/2] Exclude test directories from renaming in autopkgtest by
 default

* Files under test directories may also include utilities that are
used in tests but don't have any test in them.  It makes sense to keep
them by default during autopkgtest to make it work out-of-the-box.
---
 dh_elpa_test | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/dh_elpa_test b/dh_elpa_test
index 14e31dd..b9f1152 100755
--- a/dh_elpa_test
+++ b/dh_elpa_test
@@ -271,7 +271,9 @@ if ($autopkgtest) {
 my $rule = File::Find::Rule->new;
 $rule
   ->or(File::Find::Rule
-   ->name('.pc', 'debian', '.git')
+   ->name('.pc', 'debian', '.git', # exclude non-source directories
+  'test', 'tests', # exclude test directories
+   )
->directory->prune->discard,
File::Find::Rule->new);
 $rule
-- 
2.39.2

>From eb4f407d6c1541fda298dcfe8bcaee1fdebd5677 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Fri, 19 Apr 2024 14:24:40 -0700
Subject: [PATCH 2/2] Add more comments to describe the purpose of renaming
 source files

---
 dh_elpa_test | 4 
 1 file changed, 4 insertions(+)

diff --git a/dh_elpa_test b/dh_elpa_test
index b9f1152..c0e99e0 100755
--- a/dh_elpa_test
+++ b/dh_elpa_test
@@ -268,6 +268,10 @@ if ($autopkgtest) {
 exit 0;
 }
 
+# Compile a list of files to be renamed during autopkgtest.  This usually
+# renames source *.el file outside the test directories so that during
+# autopkgtest we are testing the installed package instead of relying on
+# source files from the source directory.
 my $rule = File::Find::Rule->new;
 $rule
   ->or(File::Find::Rule
-- 
2.39.2

Bug#1069325: A smaller lockscreen is shown above a larger one due to a second enabled powered-off display device

[mYnDstrEAm]

Package: kde-plasma-desktop
Version: 5:142

This is occurring after upgrading to Debian12 whenever waking from sleep or 
locking the screen.

First submitted this here: https://bugs.kde.org/show_bug.cgi?id=485199

I could click on both password boxes to enter the password and login (it 
doesn't matter if it's the smaller or larger lockscreen). The problem was 
solved by going to Display Configuration -> selecting the other monitor and 
disabling it. But it is occurring again now after I reenabled it. (I powered on 
the other display, enabled it, selected extend to side with meta+P, configured 
a few things like the wallpaper of the other display, and then powered it off 
without disabling it.) The two displays have different resolutions.

I'm using Wayland now. I had plasmashell running from the kstart5 plasmashell 
command in the konsole and this is the output in the console that could be 
useful:

> file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/PipeWireThumbnail.qml:11:1:
>  module "org.kde.pipewire" is not installed
> Could not find the Plasmoid for Plasma::FrameSvgItem(0x55be4a604ee0) 
> QQmlContext(0x55be4763e640) 
> QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
> Could not find the Plasmoid for Plasma::FrameSvgItem(0x55be4a604ee0) 
> QQmlContext(0x55be4763e640) 
> QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Checking screens: available: (QScreen(0xid1, name="HDMI-A-1")) redundant: 
> QHash((QScreen(0xid2, name="HDMI-A-2"), QScreen(0xid1, name="HDMI-A-1"))) 
> fake: QSet() all: (QScreen(0xid1, name="HDMI-A-1"), QScreen(0xid2, 
> name="HDMI-A-2"))
> Initializing  
> "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/kcms/systemsettings/kcm_fonts.so"
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:20:
>  TypeError: Cannot read property 'pluginName' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:75:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:78:
>  TypeError: Cannot read property 'pluginName' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:80:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:81:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:82:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:83:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:84:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:16:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:17:
>  TypeError: Cannot read property 'configuration' of null
> file:///usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:18:
>  TypeError: Cannot read property 'configuration' of null

This seems to happen at every resume from sleep but if the mouse is located on 
the larger lockscreen once it is moved just slightly the smaller lockscreen 
disappears. Also it would be useful if the two displays have different 
resolutions and Unify screen rather than Extend screen is used (as now) the 
larger resolution is kept on the display with the larger resolution. If there's 
something I should test or some logs I should check, please let me know.

Bug#1061546: srcpd: installs file into aliased location

[Preuße]

Control: tags -1 + pending

On 26.01.2024 23:01, Preuße...@buxtehude.debian.org, Hilmar wrote:

On 26.01.2024 09:35, Chris Hofstaedtler wrote:


Hi,


Please move /lib/udev/rules.d/10-liusb.rules into /usr/lib before
srcpd reaches testing.



hille42@hz:~/devel/srcpd$ dpkg-deb -c srcpd_2.1.6-2_amd64.deb|grep usb
-rw-r--r-- root/root   151 2024-01-26 21:45 
./usr/lib/udev/rules.d/10-liusb.rules


I guess this looks OK, not sure when I'll upload.


Tag bug pending, time for upload still not determined.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069017: rtags: FTBFS due to time64_t changes

[Denis Danilov]

Hi Gianfranco,

thanks for the patch with the fix. I will upload new version with our patch 
included.

Best regards,
Denis


On Mon, Apr 15, 2024 at 09:00:06AM +0200, Gianfranco Costamagna wrote:
> Package: rtags
> Version: 2.38-9
> Severity: serious
> Tags: patch
> 
> Hello maintainer, I fixed a FTBFS on armhf due to time64_t. The regex was 
> causing "=64" to be stripped from _FILE_OFFSET_BITS, causing cmake to fail to 
> build test code.
> 
> With this regex the example test code of clang fails in cmake, causing an 
> error.
> this is due to -I/usr/lib/llvm-18/include -std=c++17 -fno-exceptions 
> -funwind-tables -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
> -D__STDC_LIMIT_MACROS
> becoming:
> -I/usr/lib/llvm-18/include;-D_GNU_SOURCE;-D_FILE_OFFSET_BITS;-D_LARGEFILE_SOURCE;-D_FILE_OFFSET_BITS;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS
> 
> If you undefine _FILE_OFFSET_BITS and you enable _TIME_BITS=64 you get a FTBFS
> 
> /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed 
> only with _FILE_OFFSET_BITS=64"
> 26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
> 
> 
>   * Fix regex on find clang without stripping defines content.
> 
> 
> Thanks for considering the patch.
> diff -Nru rtags-2.38/debian/patches/fix-regex.patch 
> rtags-2.38/debian/patches/fix-regex.patch
> --- rtags-2.38/debian/patches/fix-regex.patch 1970-01-01 01:00:00.0 
> +0100
> +++ rtags-2.38/debian/patches/fix-regex.patch 2024-04-15 08:50:11.0 
> +0200
> @@ -0,0 +1,18 @@
> +Description:
> +   * Add -D_FILE_OFFSET_BITS=64 to fix FTBFS on armhf
> + (bad regex on find clang making build fail)
> +Author: Gianfranco Costamagna 
> +Forwarded: https://github.com/Andersbakken/rtags/pull/1439
> +Last-Update: 2024-04-15
> +
> +--- rtags-2.38.orig/cmake/FindLibClang.cmake
>  rtags-2.38/cmake/FindLibClang.cmake
> +@@ -88,7 +88,7 @@ if (NOT LIBCLANG_CXXFLAGS)
> + endif ()
> + set(LIBCLANG_CXXFLAGS "-I${LIBCLANG_CXXFLAGS}")
> + endif ()
> +-string(REGEX MATCHALL "-(D__?[a-zA-Z_]*|I([^\" ]+|\"[^\"]+\"))" 
> LIBCLANG_CXXFLAGS "${LIBCLANG_CXXFLAGS}")
> ++string(REGEX MATCHALL "-(D__?[a-zA-Z_=0-9]*|I([^\" ]+|\"[^\"]+\"))" 
> LIBCLANG_CXXFLAGS "${LIBCLANG_CXXFLAGS}")
> + string(REGEX REPLACE ";" " " LIBCLANG_CXXFLAGS "${LIBCLANG_CXXFLAGS}")
> + set(LIBCLANG_CXXFLAGS ${LIBCLANG_CXXFLAGS} CACHE STRING "The LLVM C++ 
> compiler flags needed to compile LLVM based applications.")
> + unset(LIBCLANG_CXXFLAGS_HACK_CMAKECACHE_DOT_TEXT_BULLSHIT CACHE)
> diff -Nru rtags-2.38/debian/patches/series rtags-2.38/debian/patches/series
> --- rtags-2.38/debian/patches/series  2023-08-29 19:36:08.0 +0200
> +++ rtags-2.38/debian/patches/series  2024-04-15 08:49:15.0 +0200
> @@ -15,3 +15,4 @@
>  0015-expand-range-of-llvm-versions.patch
>  0016-always-finish-the-connection.patch
>  0017-Add-when-argument-to-define-obsolete-function-alias.patch
> +fix-regex.patch

Bug#1066871: Fwd: Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

[Mo Zhou]

On 4/19/24 12:24, Alan M Varghese wrote:



If you feel it is worth it to push from my repo, please feel free to 
do so.


Or, I am also okay with it if you just keep what you have done there

and we can iterate on top of it without pushing from my repo (from a 
cursory look,


we just need to bring in latest upstream version, add a watch file etc).


In that case we can simply add these several new files and commit them, 
not pulling the whole git tree.


PS: Are you active on IRC? I am usually active daytime, Indian 
Standard Time.


What are your preferred timings?


My only contact point for debian work is email and I do not use IRC at 
all. For email, timing does not matter.


On 17/04/24 20:39, Mo Zhou wrote:

Hi Alan,

I granted you with the maintainer access to this repo:
https://salsa.debian.org/debian/hyprlang

This package has cleared the NEW queue a while ago:
https://tracker.debian.org/pkg/hyprlang

Could you please push your changes from personal repo
to the above repo? I can also do it for you if you don't
mind not being the git committer.

I agree with splitting these packages for the long run.
Will create repos for other packages and invite you as well.
Does it sound good to you? Repos under the public debian/
namespace allows other people to help without much permission
issues.

On 3/14/24 16:36, Alan M Varghese wrote:

Hello Mo,

May I address you Mo?

I am happy to co-maintain hyprland with you. :)

The ITP for hyprland[0] was created by werdahias@ who had created an
initial skeleton for the packaging a while ago. Under his advise,
I decided to de-vendor all of udis86, tracy and hyprland-protocols.
As far as I understand, the Debian policy recommends de-vendoring
over including files from other sources.

I have been working on this for a while and just uploaded them all
to mentors and created RFS for them. Currently I have completed
packaging hyprland and all its dependencies to the best of my ability.

Regarding the points you shared:
1. I wasn't sure what to do with tracy. I have however de-vendored
it and created an RFS for it[1]. But, I am unable to get the GPU
traces working on my AMD RX 6600 (for a debug build of Hyprland with
tracy enabled). I am not sure if this is because of my device or
something else. I have seen some discussion upstream that tracy's
GPU traces are not always reliable.

    Tracy seems to work fine, otherwise.

2. I have de-vendored udis86 too. The library and the included CLI
seems to run fine. Here is the RFS[2].

3. Again, I have separated hyprland-protocols and the RFS is here[3].

You can find the VCS for all hyprland related stuff I did, under the
NyxTrail namespace in salsa[4].

The packages all seem to run fine so far.

This is my first time packaging for Debian and any feedback is
welcome.

Let me know how you wish to proceed.

Regards,
Alan

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868
[4] https://salsa.debian.org/NyxTrail

On 3/15/24 01:10, Mo Zhou wrote:

Hi Alan,

Thank you for your work!

I did not check the ITP bugs before we make overlapping efforts:
https://salsa.debian.org/debian/hyprlang
https://salsa.debian.org/debian/hyprland

I just rushed the two packages within a short time the last night.
They work properly on Sid with my laptop.

I have uploaded hyprlang to NEW without checking ITP
https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html

The hyprland is still pending as I've not yet finished
the debian/copyright part.

In terms of build depends of hyprland:
1. tracy is optional. USE_TRACY is by default off. We can build
 the package without tracy.
2. the udis86 is embedded in the upstream tarball as well.
 Maybe we can keep it embedded as udis86 is only needed by
 hyprland
3. hyprland-protocols is also embedded. I suppose it is ok
 to keep this specific project, instead of splitting the
 package to increase the required amount of work.

Shall we merge our work and co-maintain this?

On 3/14/24 14:46, Alan M Varghese wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "libhyprlang":

   * Package name : libhyprlang
 Version  : 0.5.0-1
 Upstream contact : vaxerski 
   * URL  : https://github.com/hyprwm/hyprlang
   * License  : LGPL-3+
   * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
 Section  : x11

The source builds the following binary packages:

    libhyprlang2 - Configuration language for Hyprland (library)
    libhyprlang-dev - Configuration language for Hyprland 
(development files)


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


    https://mentors.debian.net/package/libhyprlang/

Alternatively, you 

Bug#1069324: gbp-export-orig does not take into account Files-Excluded

[Gioele Barabucci]

Package: git-buildpackage
Version: 0.9.33

Dear git-buildpackage maintainer,

tarballs generated by gbp-export-orig should not include files listed in 
the Files-Excluded stanza of d/copyright.


mk-origtargz (called by uscan) respects this setting, so it and 
gbp-export-orig confusingly generate two different orig tarballs.


Regards,

--
Gioele Barabucci

Bug#1067018: lnav: FTBFS on arm{el,hf}: test failures

[Salvatore Bonaccorso]

FWIW, I will try to work on the new available upstream version in the
next days and see if the two RC bugs on lnav can be addressed along.

it does not make sense to investigate the testsuite failure right now
without rebasing to the new version.

Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs

[Xiyue Deng]

Sean Whitton  writes:

> Hello,
>
> On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote:
>
>> Sean Whitton  writes:
>>
>>> control: tag -1 + moreinfo
>>>
>>> Hello Xiyue,
>>>
>>> Please explain the autopkgtest_keep change.  Remember that autopkgtests
>>> are to test the installed package.  If you need to keep the .el files,
>>> it must be for some reason other than because the test suite actually
>>> just tests those.
>>>
>>
>> I think this is another example of buttercup tests that requires source
>> .el files to run.  I'll probably open a bug on buttercup to see whether
>> this is required for buttercup.  Meanwhile I think it'd probably be
>> better to just disable autopkgtest as the tests are already run as part
>> of the build process.
>
> I agree.  It is important not to use autopkgtest_keep without being sure
> it's the right answer.
>

So it turns out using "disable" in d/elpa-test also disable dh_elpa_test
in d/rules so that the test is not run as part of the package building,
which would be suboptimal in that we don't run any test at all.  I'll
try to see a way to disable it only in autopkgtest in dh-elpa.

On the other hand, it looks like I misjudged the situation of the
buttercup tests that with "autopkgtest_keep = test/*" it just works,
which is much better than disabling.

>>> You've removed the Built-Using with the justification that it's an
>>> arch:all package, but that doesn't make sense; Built-Using is for
>>> licensing reasons, and may well be applicable to an arch:all package (I
>>> think this came up before with one of your uploads?).
>>
>> Ah I was following the suggestions of Lintian which said it cannot be
>> used by arch:all packages which is probably wrong.
>
> See #999785.
>

Ack.  I also checked that bug before and wondering why that lintian tag
is still enabled.  Hopefully Bug#1069256 will move things forward.

>> On the other hand, on a closer look at the policy regarding
>> Built-Using on section 7.8[1], it has the following passage:
>>
>> ,
>> | This field should be used only when there are license or DFSG
>> | requirements to retain the referenced source packages. It should not be
>> | added solely as a way to locate packages that need to be rebuilt against
>> | newer versions of their build dependencies.
>> `
>>
>> I checked that lua-mode is of GPL-2+[2], and of all its dependencies
>> lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL
>> 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using
>> requirement.  The change was introduced in [3] but it was part of the
>> modernization effort so there is no direct justification of adding the
>> field.  May be I'm missing something here?
>
> It sounds like it shouldn't have been introduced.  So you can remove it
> based on your reading of Policy, and briefly note your reasoning in
> d/changelog.

Updated d/changelog accordingly.

Also took this opportunity to add myself to uploaders.  That way we
don't have to deal with the "team upload" complications for sponsors.

Mentors and team repo are both updated.  PTAL.  Thanks!

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1069323: syncevolution-common: Depends on pre-t64 package name

[Bastian Germann]

Package: syncevolution-common
Version: 2.0.0-3
Severity: important

The package depends on libsynthesis0v5 which was renamed during the t64 
transition.

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

[Jeremy Bícha]

Control: block -1 by 1068930

You'll also need to bump the dependency on rust-async-channel to build
against the version that was built for event-listener 5.

Thank you,
Jeremy Bícha

Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Jeremy,

On Fri, Apr 19, 2024 at 05:37:41PM +0200, Jeremy Lainé wrote:
> Package: src:linux
> Version: 6.1.85-1
> Severity: important
> X-Debbugs-Cc: jeremy.la...@m4x.org
> 
> Dear Maintainer,
> 
> After upgrading from linux-image-6.1.0-18-amd64 to
> linux-image-6.1.0-20-amd64, bluetooth no longer works and a kernel BUG is
> visible in dmesg hinting at a memory safety issue.
> 
> It is not necessary to attempt to connect to any specific bluetooth
> device to trigger the problem, the problem arises as soon as the system
> boots.
> 
> I cannot reproduce the problem when booting back into the previous kernel
> image.

Would it be possible to do some experiments/debugging:

- Can you reproduce the issue with 6.1.85 upstream itself?

- If so can you try the current 6.1.87 (as of time of writing), does
  the issue reproduce there?

- If it's still happening, can you try to bisect the changes between
  6.1.76 and 6.1.85 to identify the culprit?

Regards,
Salvatore

Bug#1067616: FTBFS: error: ‘struct input_event’ has no member named ‘time’

[Andreas Beckmann]

Followup-For: Bug #1067616
Control: tag -1 patch

I'm attaching a patch fixing input_event.time usage.

Andreas
>From 8435c93a70ae65035002d0039a9a511a5974df90 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Fri, 19 Apr 2024 17:12:42 +0200
Subject: [PATCH 1/2] fix --link-doc package

---
 debian/changelog | 6 ++
 debian/rules | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index a124d88..05ea064 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+clanlib (1.0~svn3827-12) UNRELEASED; urgency=medium
+
+  * Fix --link-doc package.
+
+ -- Andreas Beckmann   Fri, 19 Apr 2024 17:10:30 +0200
+
 clanlib (1.0~svn3827-11.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/rules b/debian/rules
index ccb1097..0bd042f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -46,7 +46,7 @@ override_dh_auto_clean:
rm -f Documentation/Tutorial/Kavanek/*.html
 
 override_dh_installdocs-arch:
-   dh_installdocs --link-doc=libclanapp-1.0v5
+   dh_installdocs --link-doc=libclanapp-1.0t64
 
 override_dh_installexamples-indep:
dh_installexamples -pclanlib-doc Examples/*
-- 
2.20.1

>From 822447ffd6362ea37f48441f630275a98c0b2d34 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Fri, 19 Apr 2024 18:22:23 +0200
Subject: [PATCH 2/2] work around struct input_event.time kernel api change

---
 debian/changelog  |  1 +
 debian/patches/input_event.time.patch | 30 +++
 debian/patches/series |  1 +
 3 files changed, 32 insertions(+)
 create mode 100644 debian/patches/input_event.time.patch

diff --git a/debian/changelog b/debian/changelog
index 05ea064..4c916e2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 clanlib (1.0~svn3827-12) UNRELEASED; urgency=medium
 
   * Fix --link-doc package.
+  * Work around struct input_event.time kernel api change.  (Closes: #1067616)
 
  -- Andreas Beckmann   Fri, 19 Apr 2024 17:10:30 +0200
 
diff --git a/debian/patches/input_event.time.patch 
b/debian/patches/input_event.time.patch
new file mode 100644
index 000..e52873d
--- /dev/null
+++ b/debian/patches/input_event.time.patch
@@ -0,0 +1,30 @@
+Author: Andreas Beckmann 
+Description: work around struct input_event.time kernel api change
+ 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f
+
+--- a/Sources/GL/GLX/input_device_linuxevent.cpp
 b/Sources/GL/GLX/input_device_linuxevent.cpp
+@@ -266,12 +266,12 @@ CL_InputDevice_LinuxEvent::keep_alive()
+   if (ev[i].type == EV_SYN) 
+   {
+   printf("Event: time %ld.%06ld, 
-- %s \n",
+-   
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].code ? "Config Sync" : "Report 
Sync" );
++   
ev[i].input_event_sec, ev[i].input_event_usec, ev[i].code ? "Config Sync" : 
"Report Sync" );
+   }
+   else if (ev[i].type == EV_MSC && 
(ev[i].code == MSC_RAW || ev[i].code == MSC_SCAN)) 
+   {
+   printf("Event: time %ld.%06ld, 
type %d (%s), code %d (%s), value %02x\n",
+-   
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
++   
ev[i].input_event_sec, ev[i].input_event_usec, ev[i].type,
+
events[ev[i].type] ? events[ev[i].type] : "?",
+ev[i].code,
+
names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? 
names[ev[i].type][ev[i].code] : "?") : "?",
+@@ -280,7 +280,7 @@ CL_InputDevice_LinuxEvent::keep_alive()
+   else 
+   {
+   printf("Event: time %ld.%06ld, 
type %d (%s), code %d (%s), value %d\n",
+-   
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
++   
ev[i].input_event_sec, ev[i].input_event_usec, ev[i].type,
+
events[ev[i].type] ? events[ev[i].type] : "?",
+ev[i].code,
+
names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? 
names[ev[i].type][ev[i].code] : "?") : "?",
diff --git a/debian/patches/series b/debian/patches/series

Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts

[Holger Levsen]

Package: diffoscope
Version: 264
Severity: normal
X-Debbugs-Cc: team+pkg...@tracker.debian.org

Dear Maintainer,

diffoscope crashes when comparing the build results of src:dasel. To make it
more fun, src:dasel is only unreproducible on i386 (out of our four tested
archs, amd64/i386/arm64/armhf) and only *sometimes*.

vagrant added the following note to reproducible-notes.git, visible at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/dasel.html

---begin-note---
timezone-dependent date in manpages triggered when building with
reprotest but not reproducible builds test infrastructure.
dasel itself is used to generate the manpage.
https://sources.debian.org/src/dasel/2.7.0-1/internal/command/man.go/
.
Something non-deterministic, possibly GO BUILDID only on i386.
---end-note---

several build artifacts at available at 
https://tests.reproducible-builds.org/debian/artifacts/r00t-me/
and only the i386 ones are sometimes unreproducible and then
crashing diffoscope. (Please download them for investigations,
they will vanish after 48h but I can easily and quickly recreate
them anytime.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

I used to be scared for our grandchildren's future. Such optimism!


signature.asc
Description: PGP signature

Bug#1069321: FTBFS: [Makefile:163: check] Error 1

[Andrey Rakhmatullin]

Source: hypre
Version: 2.28.0-8
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=hypre=armhf=2.28.0-8%2Bb2=1713420980=0

I couldn't find the actual failing command.


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

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

Bug#1069320: FTBFS on mips64el: cannot find -lasan: No such file or directory

[Andrey Rakhmatullin]

Source: datatype99
Version: 1.6.4-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=datatype99=mips64el=1.6.4-1=1713121986=0

make[4]: Entering directory '/<>/testsbuild'
[ 10%] Building C object CMakeFiles/tests.dir/tests.c.o
[ 20%] Linking C executable tests
/usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
/usr/bin/ld: cannot find -lasan: No such file or directory
collect2: error: ld returned 1 exit status


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

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

Bug#1069319: FTBFS on armel: undefined reference to `__atomic_store_8'

[Andrey Rakhmatullin]

Source: datatype99
Version: 1.6.4-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=datatype99=armel=1.6.4-1=1713120793=0

make[4]: Entering directory '/<>/testsbuild'
[ 10%] Building C object CMakeFiles/tests.dir/tests.c.o
[ 20%] Linking C executable tests
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/13/libasan.so: undefined reference
to `__atomic_store_8'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/13/libasan.so: undefined reference
to `__atomic_load_8'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/13/libasan.so: undefined reference
to `__atomic_compare_exchange_8'
collect2: error: ld returned 1 exit status


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

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

Bug#1069318: FTBFS: error: unknown type name ‘StdVideoH264LevelIdc’

[Andrey Rakhmatullin]

Source: wine-development
Version: 8.21~repack-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=wine-
development=amd64=8.21%7Erepack-1%2Bb5=1712016271=0


In file included from dlls/d3d12/d3d12_main.c:27:
include/wine/vulkan.h:11804:5: error: unknown type name ‘StdVideoH264LevelIdc’
11804 | StdVideoH264LevelIdc maxLevelIdc;
  | ^~~~
include/wine/vulkan.h:11822:11: error: unknown type name
‘StdVideoEncodeH264ReferenceInfo’
11822 | const StdVideoEncodeH264ReferenceInfo *pStdReferenceInfo;
  |   ^~~
include/wine/vulkan.h:11847:11: error: unknown type name
‘StdVideoEncodeH264SliceHeader’
11847 | const StdVideoEncodeH264SliceHeader *pStdSliceHeader;
  |   ^
include/wine/vulkan.h:11856:11: error: unknown type name
‘StdVideoEncodeH264PictureInfo’
11856 | const StdVideoEncodeH264PictureInfo *pStdPictureInfo;
  |   ^
include/wine/vulkan.h:11864:5: error: unknown type name
‘StdVideoH264ProfileIdc’
11864 | StdVideoH264ProfileIdc stdProfileIdc;
  | ^~
include/wine/vulkan.h:11917:5: error: unknown type name ‘StdVideoH264LevelIdc’
11917 | StdVideoH264LevelIdc maxLevelIdc;
  | ^~~~
include/wine/vulkan.h:11925:11: error: unknown type name
‘StdVideoH264SequenceParameterSet’
11925 | const StdVideoH264SequenceParameterSet *pStdSPSs;
  |   ^~~~
include/wine/vulkan.h:11927:11: error: unknown type name
‘StdVideoH264PictureParameterSet’
11927 | const StdVideoH264PictureParameterSet *pStdPPSs;
  |   ^~~
include/wine/vulkan.h:11962:5: error: unknown type name ‘StdVideoH265LevelIdc’
11962 | StdVideoH265LevelIdc maxLevelIdc;
  | ^~~~
include/wine/vulkan.h:11983:11: error: unknown type name
‘StdVideoEncodeH265ReferenceInfo’
11983 | const StdVideoEncodeH265ReferenceInfo *pStdReferenceInfo;
  |   ^~~
include/wine/vulkan.h:12008:11: error: unknown type name
‘StdVideoEncodeH265SliceSegmentHeader’
12008 | const StdVideoEncodeH265SliceSegmentHeader *pStdSliceSegmentHeader;
  |   ^~~~
include/wine/vulkan.h:12017:11: error: unknown type name
‘StdVideoEncodeH265PictureInfo’
12017 | const StdVideoEncodeH265PictureInfo *pStdPictureInfo;
  |   ^
include/wine/vulkan.h:12024:5: error: unknown type name
‘StdVideoH265ProfileIdc’
12024 | StdVideoH265ProfileIdc stdProfileIdc;
  | ^~
include/wine/vulkan.h:12076:5: error: unknown type name ‘StdVideoH265LevelIdc’
12076 | StdVideoH265LevelIdc maxLevelIdc;
  | ^~~~
include/wine/vulkan.h:12084:11: error: unknown type name
‘StdVideoH265VideoParameterSet’
12084 | const StdVideoH265VideoParameterSet *pStdVPSs;
  |   ^
include/wine/vulkan.h:12086:11: error: unknown type name
‘StdVideoH265SequenceParameterSet’
12086 | const StdVideoH265SequenceParameterSet *pStdSPSs;
  |   ^~~~
include/wine/vulkan.h:12088:11: error: unknown type name
‘StdVideoH265PictureParameterSet’
12088 | const StdVideoH265PictureParameterSet *pStdPPSs;
  |   ^~~


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

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

Bug#1069310: FTBFS: tests failed

[Shengjing Zhu]

Control: reassign -1 golang-github-hanwen-go-fuse-dev
Control: affects -1 src:gocryptfs

On Sat, Apr 20, 2024 at 2:54 AM Andrey Rakhmatullin  wrote:
>
> Source: gocryptfs
> Version: 2.4.0-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=gocryptfs=mips64el=2.4.0-1%2Bb6=1713405841=0
>
> panic: DIRECT (8000) overlaps with LARGEFILE (8000)
>
> goroutine 1 [running]:
> github.com/hanwen/go-fuse/fuse.(*flagNames).set(0xc000126708, 0x8000,
> {0x1201d640e, 0x6})
> 
> /<>/_build/src/github.com/hanwen/go-fuse/fuse/print.go:126
> +0x234
> github.com/hanwen/go-fuse/fuse.init.1()
> /<>/_build/src/github.com/hanwen/go-
> fuse/fuse/print_linux.go:13 +0x68
> FAILgithub.com/rfjakob/gocryptfs/internal/syscallcompat 0.007s
>

This is similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061659 and
https://github.com/hanwen/go-fuse/issues/502 which is only fixed on
i386.

-- 
Shengjing Zhu

Bug#1069317: FTBFS: tests failed

[Andrey Rakhmatullin]

Source: sonic-visualiser
Version: 4.5.2-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=sonic-
visualiser=armel=4.5.2-2%2Bb3=1713251413=0

FAIL!  : TestVampRealTime::fromTimeval() Compared values are not the same
   Loc: [test-svcore-base.p/../../svcore/base/test/TestVampRealTime.h(144)]



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

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

Bug#1069250: swappy: "tool" mispelled "toool" in short package description

[Krzysztof Adamski]

Control: tags -1 pending
thanks

Hi Beatrice,

Thank you for reporting this. I have just pushed a fix to the package 
repository. I'm not uploading a new package now since the severity is very low 
and the package is part of two ongoing testing transitions. It will be fixed in 
next upload, though.

Best regards,
Krzysztof

Bug#1069316: network-manager-gnome: Debian 11 Xfce panel Network Manager applet has disappeared

[David Christensen]

Package: network-manager-gnome
Version: 1.20.0-3
Severity: important
X-Debbugs-Cc: dpchr...@holgerdanske.com

Dear Maintainer,

Please see:

https://lists.debian.org/debian-user/2024/04/msg00171.html


David



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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.28-0+deb11u1
ii  libatk1.0-0   2.36.0-2
ii  libayatana-appindicator3-10.5.5-2+deb11u2
ii  libc6 2.31-13+deb11u8
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0  2.66.8-1+deb11u1
ii  libgtk-3-03.24.24-4+deb11u3
ii  libjansson4   2.13.1-1.1
ii  libmm-glib0   1.14.12-0.2
ii  libnm01.30.6-1+deb11u1
ii  libnma0   1.8.30-1
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libsecret-1-0 0.20.4-2
ii  libselinux1   3.1-3
ii  network-manager   1.30.6-1+deb11u1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.36.0-1
ii  iso-codes4.6.0-1
ii  mobile-broadband-provider-info   20201225-1
ii  notification-daemon  3.20.0-4
ii  xfce4-notifyd [notification-daemon]  0.6.2-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#1069315: Update Build-Depends for the time64 library renames

[Andrey Rakhmatullin]

Source: openjdk-20
Version: 20.0.2+9-1
Severity: serious
Tags: ftbfs

The package explicitly Build-Depends: libgtk2.0-0 | libgtk-3-0,
these need to be changed to lib*t64 if these deps are needed at all.


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

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

Bug#1069314: sphinxbase-utils: Package description spells "utilities" as "utililities"

[Marnanel Thurman]

Package: sphinxbase-utils
Version: 0.8+5prealpha+1-16
Severity: normal

Dear Maintainer,

The description of this package, as given by apt, is

"Speech recognition tool - utililities"

It should read

"Speech recognition tool - utilities"


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/2 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 sphinxbase-utils depends on:
ii  libc6   2.36-9+deb12u4
ii  libsphinxbase3  0.8+5prealpha+1-16

sphinxbase-utils recommends no packages.

sphinxbase-utils suggests no packages.

-- no debconf information

Bug#1065007: pycurl: Please reconsider SSL choice (OpenSSL instead of GnuTLS)

[Samuel Henrique]

Hello Boyuan and Scott,

> I was made aware of issues encountered by multiple users due to pycurl using
> GnuTLS instead of OpenSSL. Reviewing https://bugs.debian.org/515200 , it 
> looks like the
> only reason of not using OpenSSL is the old OpenSSL licensing issue in the 
> past.

That bug is 15 years old and you did not mention any details about the issues
that you're having. Effectively there is no documented reason to switch to
openssl on this bug.

Scott, I see that you went ahead and switched to openssl anyway:
> I don't have any objections to rebuilding pycurl with openssl.
We are close to enabling support to http3 for the gnutls libcurl, so this
switch kills any possibility of pycurl supporting http3, at least until openssl
gets proper http3 support (might not happen for the next stable release).

On the curl side, we are considering switching the default backend used by curl
(the cli) for the gnutls one, so we can enable http3.

Boyuan, can you provide any details on the issues you found? Otherwise I would
recommend staying with gnutls for now and so pycurl will soon make use of a
http3-enabled libcurl.

Cheers,

--
Samuel Henrique 

Bug#1069313: FTBFS: implicit declaration of function ‘jpeg_memio_dest’; did you mean ‘jpeg_mem_dest’?

[Andrey Rakhmatullin]

Source: jskeus
Version: 1.2.4+dfsg-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=jskeus=armhf=1.2.4%2Bdfsg-3%2Bb2=1710976387=0

gcc -g -c -o /<>/irteus/LinuxARM/obj/irtmath.o -DARM -DLinux
-Wimplicit -falign-functions=4 -DGCC3  -DGCC -fsigned-char  -DTHREADED
-DPTHREAD -fpic  -I/usr/share/euslisp/include -O2 -g -O2 -Werror=implicit-
function-declaration -ffile-prefix-map=/<>=. -fstack-protector-
strong -fstack-clash-protection -Wformat -Werror=format-security
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2 -DLinux -D_REENTRANT -DGCC -I/usr/share/euslisp/include
-DTHREADED -DPTHREAD -DSVNVERSION=\"\" -fPIC -falign-functions=8 ./irtmath.c;
ld -shared -build-id -o /<>/irteus/LinuxARM/obj/irtmath.so
/<>/irteus/LinuxARM/obj/irtmath.ojpegmemcd.c: In function
‘JPEG_compress’:
jpegmemcd.c:29:3: error: implicit declaration of function ‘jpeg_memio_dest’;
did you mean ‘jpeg_mem_dest’? [-Werror=implicit-function-declaration]
   29 |   jpeg_memio_dest(, jpeg_image_buffer, _count);
  |   ^~~
  |   jpeg_mem_dest
jpegmemcd.c: In function ‘JPEG_header’:
jpegmemcd.c:92:3: error: implicit declaration of function ‘jpeg_memio_src’; did
you mean ‘jpeg_mem_src’? [-Werror=implicit-function-declaration]
   92 |   jpeg_memio_src(, jpeg_image, jpeg_size);
  |   ^~
  |   jpeg_mem_src


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

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

Bug#1069312: FTBFS: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1

[Andrey Rakhmatullin]

Source: haskell-gi-gtk
Version: 3.0.41-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=haskell-gi-
gtk=armel=3.0.41-1%2Bb6=1713045220=0

[707 of 708] Compiling GI.Gtk.Structs   ( GI/Gtk/Structs.hs, dist-
ghc/build/GI/Gtk/Structs.o, dist-ghc/build/GI/Gtk/Structs.dyn_o )
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build
--builddir=dist-ghc returned exit"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm
line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", "--
builddir=dist-ghc") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 656
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25


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

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

Bug#1069311: php-symfony-polyfill: Fix typo in pkg-php-tools-autoloaders for php84

[Mitchell Dzurick]

Package: php-symfony-polyfill
Version: 1.29.0-3
Subject: Fix typo in pkg-php-tools-autoloaders for php84

Hi, I have a simple MR up at
https://salsa.debian.org/php-team/pear/php-symfony-polyfill/-/merge_requests/2
to fix a typo in the autoloaders.

Thanks!
-Mitch

Bug#1069310: FTBFS: tests failed

[Andrey Rakhmatullin]

Source: gocryptfs
Version: 2.4.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=gocryptfs=mips64el=2.4.0-1%2Bb6=1713405841=0

panic: DIRECT (8000) overlaps with LARGEFILE (8000)

goroutine 1 [running]:
github.com/hanwen/go-fuse/fuse.(*flagNames).set(0xc000126708, 0x8000,
{0x1201d640e, 0x6})
/<>/_build/src/github.com/hanwen/go-fuse/fuse/print.go:126
+0x234
github.com/hanwen/go-fuse/fuse.init.1()
/<>/_build/src/github.com/hanwen/go-
fuse/fuse/print_linux.go:13 +0x68
FAILgithub.com/rfjakob/gocryptfs/internal/syscallcompat 0.007s


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

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

Bug#1069309: xfractint FTBFS: error: implicit declaration of function

[Adrian Bunk]

Source: xfractint
Version: 20.4.10-4
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Petter Reinholdtsen 

https://buildd.debian.org/status/logs.php?pkg=xfractint=20.4.10-4

...
/usr/bin/gcc -I../headers -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -I./headers -DXFRACT  -DNOBSTRING   -g 
-DBIG_ANSI_C -DLINUX -fno-builtin -fcommon -O2 -Wdate-time -D_FORTIFY_SOURCE=2  
-c -o 3d.o 3d.c
3d.c: In function ‘longvmultpersp’:
3d.c:290:20: error: implicit declaration of function ‘multiply’ 
[-Werror=implicit-function-declaration]
  290 |  tmp[j] += multiply(s[i],m[i][j],bitshift);
  |^~~~
3d.c:318:20: error: implicit declaration of function ‘divide’ 
[-Werror=implicit-function-declaration]
  318 |   tmpview[0] = divide(lview[0],denom,bitshift);
  |^~
cc1: some warnings being treated as errors
make[3]: *** [: 3d.o] Error 1

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Mon, Mar 25, 2024 at 07:12:24PM +, Chris Lamb wrote:

Alberto Bertogli wrote:


If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.


Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.


I totally understand the access part, that's very reasonable on Debian's 
part.


But unfortunately, if I can't even run a local VM to try to reproduce 
the problem, it's too limiting for me. Especially considering the kind 
of issues libfiu often runs into, which tend to be a bit on the esoteric 
side :)




Hm, googling the actual error message a little, I think this might be
a bigger issue... or perhaps more accurately, at least one that has
potentially been also solved elsewhere:

 * Same think in lightdm: 

 * Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils
   


Thank you for looking at this!

I think they could be similar; in particular the second one.

Maybe there's something like `#define pread pread64` in the 
architecture's headers that is triggering these errors?




Does this spark anything worth trying? :-)


Maybe seeing the preprocessor output and the actual (temporary) file 
getting the complaints could be useful in figuring out what's going on.


That said, even if we find what the problem is, we may keep finding 
other issues in the future. If I'm not able to have a VM for this
platform where I can try to reproduce problems, I'm not sure it's viable 
to support the package on it :(


Thanks!
Alberto

Bug#1069308: FTBFS: tests failed

[Andrey Rakhmatullin]

Source: gnome-subtitles
Version: 1.8-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=gnome-
subtitles=amd64=1.8-1%2Bb3=1712013676=0

@@ -747,7 +747,7 @@

 "GstDiscovererClass.starting": "144"
 "GstDiscovererClass.discovered": "152"
 "GstDiscovererClass.source_setup": "160"
-"GstDiscovererClass._reserved": "176"
+"GstDiscovererClass._reserved": "168"
 "sizeof(GstDiscoverer)": "64"
 "GstDiscoverer.priv": "24"
 "GstDiscoverer._reserved": "32"


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

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

Bug#1069307: FTBFS: configure: error: must specify --with-locking-method option

[Andrey Rakhmatullin]

Source: courier
Version: 1.0.16-3.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=courier=armel=1.0.16-3.2%2Bb4=1712019536=0

checking for locking method... configure: error: must specify --with-locking-
method option
configure: error: ./configure failed for libs/liblock


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

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

Bug#996433: transmission-daemon: Transmission fails to send mail using exim4

[JT Hundley]

If that's the official way to fix it, I think so. Hopefully this page stays
findable by search engines so that others trying to get Transmission to
send emails through Exim don't have to do all the troubleshooting that I
did :)
I've made this change to my system, thanks for the tip. I'm still learning
systemd.

Bug#1069275: apt: random display of the "Summary:" line

[Antonio]

Damn, I didn't notice, even though I had it under my nose the whole time...

Thanks for the explanation.


Il 19/04/24 15:26, David Kalnischkies ha scritto:

On Fri, Apr 19, 2024 at 02:06:44PM +0200, Antonio wrote:

If you find the "apt autoremove --purge" command in the sequence of the
commands I have indicated, you will notice that it appears three times:

- in second position produces this output:

$ apt autoremove --purge

 ^^^

Summary:
    Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

- in seventh position it produces the same output

$ apt autoremove --purge

 ^^^

Summary:
    Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

but the same command, in the fifteenth position produces a different output:

   

$ apt-get autoremove --purge

 ^^^

0 updated, 0 installed, 0 to be removed and 0 not updated.

what has changed? I would always expect the same output...

(Lets play a game! Lets call it: Spot the difference. )

As Julian already mentioned, "apt" and "apt-get" have different output.
This is intended (for compat) and not random, but yes, it can be a bit
confusing if your muscle memory lets you end up mix their use.

(Note that not only their output is different; they also have behaviour
  differences e.g. "apt-get upgrade" vs "apt upgrade")

As an interactive user, its is probably best to forget apt-{get,cache,…}
exist and get used to 'apt'. If that is missing something compared to
the others feel free to report a bug so we can add it – or suggest an
alternative as sometimes that might be better approach.


Best regards

David Kalnischkies

Bug#1069306: pax-britannica appears reduced in its window

[Rémi Letot]

Package: pax-britannica
Version: 1.0.0-5+b2
Severity: normal
X-Debbugs-Cc: hob...@poukram.net

Dear Maintainer,

when launching the game in a window, the window honnors the scale of
my display, but the game content itself stays at 100%. 

So with a scale of 175%, the game appears in the lower left quarter of 
its window. The rest of the window is black.

I don't know exactly when it started, but it's relativly recent.

Don't hesitate to ask for more info

Thanks for your work, 
-- 
Rémi

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

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

Versions of packages pax-britannica depends on:
ii  libasound2t64   1.2.11-1+b1
ii  libc6   2.37-18
ii  libgl1  1.7.0-1
ii  libglfw33.4-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  liblua5.1-0 5.1.5-9+b2
ii  pax-britannica-data 1.0.0-5

pax-britannica recommends no packages.

pax-britannica suggests no packages.

-- no debconf information

Bug#1069305: cython3: dependency on python3-dbg intended?

[Jörg-Volker Peetz]

Package: cython3
Version: 3.0.10+dfsg-3
Severity: wishlist

Dear Debian Python Team,

is the dependency on python3-dbg intended?
When upgrading apt wants to install the packages libpython3-dbg,
libpython3.11t64-dbg, python3-dbg, and python3.11-dbg.

Regards,
Jörg.

Bug#1069304: daciti: Fix incorrect work when using default_factory

[Walter Lozano]

Package: daciti
Version: 1.8.0-1
Severity: important

Dear Maintainer,

The version or daciti 1.8.0-1 ships an upstream bug which was fixed in 1.8.1 as
it is rather important. In particular this is the only major difference between
the version Bookworm (1.8.0-1) and Trixie (1.8.1-2), so probably it can be
backported.

As reference https://github.com/konradhalas/dacite/pull/216

Thanks in advance,

Walter


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

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

Bug#1069303: dia: Cisco - Network: Cloud* does not draw outline on SVG export

[Linus Lüssing]

Package: dia
Version: 0.98+git20240130-1+b1
Severity: normal
X-Debbugs-Cc: linus.luess...@c0d3.blue

Dear Maintainer,

When I try to export an image involving a cloud from the "Cisco - Network"
category to SVG then its outline is not drawn.

When then converting for instance a "Cloud White" from SVG to PNG
(for instance via the ImageMagick "convert" CLI tool) then the cloud
vanishes completely, due to the missing outline.

Regards, Linus

*** 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: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages dia depends on:
ii  dia-common   0.98+git20240130-1
ii  gir1.2-gtk-3.0   3.24.41-4
ii  libc62.37-15.1
ii  libcairo21.18.0-3
ii  libemf1  1.0.13-7
ii  libgcc-s114-20240315-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b2
ii  libglib2.0-0t64  2.78.4-6
ii  libgraphene-1.0-01.10.8-3+b1
ii  libgtk-3-0t643.24.41-4
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpangocairo-1.0-0  1.52.1+ds-1
ii  libpoppler126t64 22.12.0-2.2
ii  libpython3.11t64 3.11.8-3+b2
ii  libstdc++6   14-20240315-1
ii  libxml2  2.9.14+dfsg-1.3+b2
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages dia recommends:
ii  dia-shapes0.6.0-5
ii  fonts-urw-base35  20200910-8

dia suggests no packages.

-- no debconf information

Bug#1068129: ITP: redict -- Distributed key/value store - forked from Redis

[Andrea Pappacoda]

On Tue, 02 Apr 2024 11:06:16 +0300 Maytham Alsudany  
wrote:
> If you are interested in packaging redict and you'd like to join the team,
> please go to https://salsa.debian.org/redict-team and request access.

Hi Maytham, thanks for your work on this! I'd live to work on Redict packaging 
too, and I've sent a request to join the redict-team group on Salsa.

I'm not a DD, so I can't help with sponsoring, but I think I'll apply for 
becoming one soon - I've been contributing to Debian for some years now.

Bye!

Bug#1064459: refining DEP17 patches for glibc and base-files

[Santiago Vila]

Hi.

I've added two commits, one to create symlinks with a "shell" for, and the last
one for a sample changelog (because this is really a "team upload" or a "guest 
upload"
more than a NMU). I think for simplicity it's ok if you skip the changelog part
in your repo.

Thanks.

Bug#1069302: libxerces-c-samples: k.zmi...@gmail.com

[Konrad Zminda]

Package: libxerces-c-samples
Version: 3.2.4+debian-1
Severity: important
X-Debbugs-Cc: k.zmi...@gmail.com

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

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

Versions of packages libxerces-c-samples depends on:
ii  libc6   2.36-9+deb12u4
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  libxerces-c3.2  3.2.4+debian-1

libxerces-c-samples recommends no packages.

libxerces-c-samples suggests no packages.



Hello


There seems to be bug when using StdInParse on Debian12 :

I did prepare a 2 test envs with fresh install of Debian11 and Debian12


Debian12

Linux konrad-debian12 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 
(2024-02-01) x86_64 GNU/Linux

libxerces-c-samples 3.2.4+debian-1  
libxerces-c3.2  3.2.4+debian-1  
apache2 2.4.59-1~deb12u1

Debian11

Linux konrad-debian11 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) 
x86_64 GNU/Linux

libxerces-c-samples 3.2.3+debian-3+deb11u1  
libxerces-c3.2  3.2.3+debian-3+deb11u1  
apache2 2.4.59-1~deb11u1



On debian 12

Trying to use StdInParse :


root@konrad-debian12:~# /usr/bin/StdInParse -n -v=always -s -f < /root/bopa.xml 


Fatal Error at (file , line 0, char 0): internal error in NetAccessor

Fatal Error at (file stdin, line 2, char 239): fatal error during schema scan



The error is caused by not fully reciving the generator.xsd (48KiB) from 
localhost apache (moved localy to rule out network)


Lets take a quick look at loopback

root@konrad-debian12:~# tcpdump -i lo
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:19:16.982472 IP localhost.37128 > localhost.http: Flags [S], seq 3312200642, 
win 43690, options [mss 65495,sackOK,TS val 218223881 ecr 0,nop,wscale 10], 
length 0
14:19:16.982482 IP localhost.http > localhost.37128: Flags [S.], seq 
2074508043, ack 3312200643, win 43690, options [mss 65495,sackOK,TS val 
218223881 ecr 218223881,nop,wscale 10], length 0
14:19:16.982499 IP localhost.37128 > localhost.http: Flags [.], ack 1, win 43, 
options [nop,nop,TS val 218223881 ecr 218223881], length 0
14:19:16.982528 IP localhost.37128 > localhost.http: Flags [P.], seq 1:66, ack 
1, win 43, options [nop,nop,TS val 218223881 ecr 218223881], length 65: HTTP: 
GET /generator.xsd HTTP/1.1
14:19:16.982544 IP localhost.http > localhost.37128: Flags [.], ack 66, win 43, 
options [nop,nop,TS val 218223881 ecr 218223881], length 0
14:19:16.982816 IP localhost.http > localhost.37128: Flags [.], seq 1:22017, 
ack 66, win 43, options [nop,nop,TS val 218223881 ecr 218223881], length 22016: 
HTTP: HTTP/1.1 200 OK
14:19:16.982848 IP localhost.http > localhost.37128: Flags [P.], seq 
22017:44033, ack 66, win 43, options [nop,nop,TS val 218223881 ecr 218223881], 
length 22016: HTTP
14:19:16.982965 IP localhost.37128 > localhost.http: Flags [.], ack 22017, win 
22, options [nop,nop,TS val 218223882 ecr 218223881], length 0
14:19:16.983013 IP localhost.37128 > localhost.http: Flags [R.], seq 66, ack 
44033, win 43, options [nop,nop,TS val 218223882 ecr 218223881], length 0


the client stops reciving the data, and the generator.xsd gets cut at (44KiB  
and the complete file is 48KiB) :

If i follow the tcp session payload,  its clear that file is incomplete,

#Fragment that got cut at 44KiB

  

   /lib/x86_64-linux-gnu/libxerces-c-3.2.so 
(0x7f4e5900)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f4e58c0)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f4e594e8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4e58e1f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f4e594e3000)
libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 
(0x7f4e59436000)
libicuuc.so.67 => /lib/x86_64-linux-gnu/libicuuc.so.67 (0x7f4e58a17000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f4e58938000)
/lib64/ld-linux-x86-64.so.2 (0x7f4e5951c000)
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 
(0x7f4e59407000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7f4e593d6000)
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x7f4e593b5000)
libssh2.so.1 => /lib/x86_64-linux-gnu/libssh2.so.1 (0x7f4e588f7000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x7f4e593a1000)
libnettle.so.8 => 

Bug#1066005: NMU: error: implicit declaration of function ‘strlcpy’

[Bastian Germann]

I am uploading a NMU to fix this.
Please find the debdiff attached.

epic4_2.10.10-1.1.debdiff
Description: Binary data

Bug#1066871: Fwd: Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

[Alan M Varghese]

Hello Mo,


Thank you for granting me access.


I believe this would require me to force push from local repo? Wouldn't this 
result

in the loss of your own commit history?


Or we could merge the two from a different branch. But that feels like too much

work :p


If you feel it is worth it to push from my repo, please feel free to do so.

Or, I am also okay with it if you just keep what you have done there

and we can iterate on top of it without pushing from my repo (from a cursory 
look,

we just need to bring in latest upstream version, add a watch file etc).


PS: Are you active on IRC? I am usually active daytime, Indian Standard Time.

What are your preferred timings?

On 17/04/24 20:39, Mo Zhou wrote:

Hi Alan,

I granted you with the maintainer access to this repo:
https://salsa.debian.org/debian/hyprlang

This package has cleared the NEW queue a while ago:
https://tracker.debian.org/pkg/hyprlang

Could you please push your changes from personal repo
to the above repo? I can also do it for you if you don't
mind not being the git committer.

I agree with splitting these packages for the long run.
Will create repos for other packages and invite you as well.
Does it sound good to you? Repos under the public debian/
namespace allows other people to help without much permission
issues.

On 3/14/24 16:36, Alan M Varghese wrote:

Hello Mo,

May I address you Mo?

I am happy to co-maintain hyprland with you. :)

The ITP for hyprland[0] was created by werdahias@ who had created an
initial skeleton for the packaging a while ago. Under his advise,
I decided to de-vendor all of udis86, tracy and hyprland-protocols.
As far as I understand, the Debian policy recommends de-vendoring
over including files from other sources.

I have been working on this for a while and just uploaded them all
to mentors and created RFS for them. Currently I have completed
packaging hyprland and all its dependencies to the best of my ability.

Regarding the points you shared:
1. I wasn't sure what to do with tracy. I have however de-vendored
it and created an RFS for it[1]. But, I am unable to get the GPU
traces working on my AMD RX 6600 (for a debug build of Hyprland with
tracy enabled). I am not sure if this is because of my device or
something else. I have seen some discussion upstream that tracy's
GPU traces are not always reliable.

    Tracy seems to work fine, otherwise.

2. I have de-vendored udis86 too. The library and the included CLI
seems to run fine. Here is the RFS[2].

3. Again, I have separated hyprland-protocols and the RFS is here[3].

You can find the VCS for all hyprland related stuff I did, under the
NyxTrail namespace in salsa[4].

The packages all seem to run fine so far.

This is my first time packaging for Debian and any feedback is
welcome.

Let me know how you wish to proceed.

Regards,
Alan

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868
[4] https://salsa.debian.org/NyxTrail

On 3/15/24 01:10, Mo Zhou wrote:

Hi Alan,

Thank you for your work!

I did not check the ITP bugs before we make overlapping efforts:
https://salsa.debian.org/debian/hyprlang
https://salsa.debian.org/debian/hyprland

I just rushed the two packages within a short time the last night.
They work properly on Sid with my laptop.

I have uploaded hyprlang to NEW without checking ITP
https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html

The hyprland is still pending as I've not yet finished
the debian/copyright part.

In terms of build depends of hyprland:
1. tracy is optional. USE_TRACY is by default off. We can build
     the package without tracy.
2. the udis86 is embedded in the upstream tarball as well.
     Maybe we can keep it embedded as udis86 is only needed by
     hyprland
3. hyprland-protocols is also embedded. I suppose it is ok
     to keep this specific project, instead of splitting the
     package to increase the required amount of work.

Shall we merge our work and co-maintain this?

On 3/14/24 14:46, Alan M Varghese wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "libhyprlang":

   * Package name : libhyprlang
     Version  : 0.5.0-1
     Upstream contact : vaxerski 
   * URL  : https://github.com/hyprwm/hyprlang
   * License  : LGPL-3+
   * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
     Section  : x11

The source builds the following binary packages:

    libhyprlang2 - Configuration language for Hyprland (library)
    libhyprlang-dev - Configuration language for Hyprland (development files)

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

    https://mentors.debian.net/package/libhyprlang/

Alternatively, you can 

Bug#1040307: imagemagick: Converting PNG to AVIF replaces transparent pixels with black pixels

[Nikita Radchenko]

The problem is fixed in ImageMagick 6.9.12-68.

I confirm that starting with commit cc4e5a63 
(https://github.com/ImageMagick/ImageMagick6/commit/cc4e5a6383961c03d340e0237feedfff83f9af0b)
 ImageMagick can convert PNG images with transparent background to AVIF without 
issues.

Bug#1056574: transition: ppp

[Chris Boot]

On 26/11/2023 11:36, Chris Boot wrote:

On 26/11/2023 10:56, Chris Boot wrote:
Any way to reduce possible breakage, or to detect and fix it before 
the transition starts? Like rebuilding rdeps, or checking rdep 
autopkgtests?


I'll go an do some rebuilds now and see how they go. If any breakage 
occurs it will be obvious at build time.


The status of the rdeps (list taken from the tracker):

connman: OK
network-manager: OK
pptpd: https://bugs.debian.org/1056898
sstp-client: https://bugs.debian.org/1056900

network-manager-fortisslvpn: https://bugs.debian.org/1056901
network-manager-l2tp: OK
network-manager-pptp: OK
network-manager-sstp: https://bugs.debian.org/1056903


All that's left now is pptpd (with an offer from Christoph to upload 
when ready) and network-manager-fortisslvpn (with commits fixing the 
issues upstream, but no upstream release).


In the mean time, #1065940 has become a blocker for the time_t 
transition. I think I'd rather upload 2.5.0 and break 
network-manager-fortisslvpn than just the patch to fix the breakage.


Would the release team be happy to continue with this transition?

Thanks,
Chris

--
Chris Boot
bo...@debian.org

Bug#1068079: crash: FTBFS on loong64

[Troy Heber]

Hello Dandan,

Thanks for the bug report. It doesn't look like Debian has official
porter/maintainer boxes for the LoongArch architecture. Having access
to stable platform is a bit of a pre-req before enabling the support.

Troy


signature.asc
Description: PGP signature

Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2

[Jeremy Lainé]

Package: src:linux
Version: 6.1.85-1
Severity: important
X-Debbugs-Cc: jeremy.la...@m4x.org

Dear Maintainer,

After upgrading from linux-image-6.1.0-18-amd64 to
linux-image-6.1.0-20-amd64, bluetooth no longer works and a kernel BUG is
visible in dmesg hinting at a memory safety issue.

It is not necessary to attempt to connect to any specific bluetooth
device to trigger the problem, the problem arises as soon as the system
boots.

I cannot reproduce the problem when booting back into the previous kernel
image.


-- Package-specific info:
** Version:
Linux version 6.1.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-20-amd64 root=/dev/mapper/yuzu--vg-root ro quiet

** Tainted: D (128)
 * kernel died recently, i.e. there was an OOPS or BUG

** Kernel log:
[   19.489647] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   19.497033] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   19.497276] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   19.719465] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   19.739192] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   19.739699] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   19.740149] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   19.740166] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[   20.037515] wlp0s20f3: authenticate with 3e:94:ed:ae:f8:23
[   20.037540] wlp0s20f3: 80 MHz not supported, disabling VHT
[   20.044248] wlp0s20f3: send auth to 3e:94:ed:ae:f8:23 (try 1/3)
[   20.077295] wlp0s20f3: authenticated
[   20.080607] wlp0s20f3: associate with 3e:94:ed:ae:f8:23 (try 1/3)
[   20.184598] wlp0s20f3: associate with 3e:94:ed:ae:f8:23 (try 2/3)
[   20.199647] wlp0s20f3: RX AssocResp from 3e:94:ed:ae:f8:23 (capab=0x1431 
status=0 aid=3)
[   20.220862] wlp0s20f3: associated
[   20.361778] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s20f3: link becomes ready
[   20.424603] Bluetooth: hci0: command 0x0408 tx timeout
[   20.424648] Bluetooth: hci0: Opcode 0x0408 failed: -110
[   20.474223] kauditd_printk_skb: 24 callbacks suppressed
[   20.474230] audit: type=1400 audit(1713540473.670:38): apparmor="DENIED" 
operation="open" profile="mariadbd_akonadi" name="/sys/devices/system/node/" 
pid=2378 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[   20.545041] audit: type=1400 audit(1713540473.742:39): apparmor="DENIED" 
operation="open" profile="mariadbd_akonadi" name="/sys/devices/system/node/" 
pid=2453 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[   20.602910] audit: type=1400 audit(1713540473.798:40): apparmor="DENIED" 
operation="open" profile="mariadbd_akonadi" name="/sys/block/" pid=2453 
comm="mysqld" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[   20.637180] audit: type=1400 audit(1713540473.834:41): apparmor="DENIED" 
operation="open" profile="mariadbd_akonadi" 
name="/sys/devices/virtual/block/dm-1/queue/physical_block_size" pid=2453 
comm="mysqld" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[   22.500681] Bluetooth: hci0: command 0x0408 tx timeout
[   22.500728] Bluetooth: hci0: Opcode 0x0408 failed: -110
[   22.660771] Bluetooth: hci0: Opcode 0x0408 failed: -114
[   22.660847] list_del corruption, 94d9f6302000->prev is LIST_POISON2 
(dead0122)
[   22.660887] [ cut here ]
[   22.660890] kernel BUG at lib/list_debug.c:56!
[   22.660907] invalid opcode:  [#1] PREEMPT SMP NOPTI
[   22.660917] CPU: 10 PID: 139 Comm: kworker/u25:0 Not tainted 6.1.0-20-amd64 
#1  Debian 6.1.85-1
[   22.660929] Hardware name: Dell Inc. XPS 9315/00KRKP, BIOS 1.19.1 03/14/2024
[   22.660936] Workqueue: hci0 hci_cmd_sync_work [bluetooth]
[   22.661128] RIP: 0010:__list_del_entry_valid.cold+0x4b/0x6f
[   22.661147] Code: fe ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 48 18 7a 9f e8 14 
a1 fe ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 10 18 7a 9f e8 00 a1 fe ff <0f> 0b 48 
89 fe 48 c7 c7 d8 17 7a 9f e8 ef a0 fe ff 0f 0b 48 89 fe
[   22.661156] RSP: :ae0e406efde0 EFLAGS: 00010246
[   22.661164] RAX: 004e RBX: 94d9f6302000 RCX: 0027
[   22.661172] RDX:  RSI: 0001 RDI: 94dfaf8a03a0
[   22.661177] RBP: 94d859392000 R08:  R09: ae0e406efc78
[   22.661182] R10: 0003 R11: 9fed4448 R12: 94d859392000
[   22.661187] R13: 94d859392770 R14: 94d858cb9800 R15: dead0100
[   22.661194] FS:  () GS:94dfaf88() 
knlGS:
[   22.661202] CS:  0010 DS:  ES:  CR0: 80050033
[   22.661208] CR2: 7f423c024038 

Bug#1069300: ITP: autotiling -- automatically switch the window split orientation in sway and i3

[Johannes Schauer Marin Rodrigues]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer Marin Rodrigues 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: autotiling
  Version : 1.9.1
  Upstream Contact: Piotr Miller 
* URL : https://github.com/nwg-piotr/autotiling/
* License : GPL-3+
  Programming Lang: Python
  Description : automatically switch the window split orientation in sway 
and i3

This script uses the i3ipc-python library to switch the layout splith/splitv
depending on the currently focused window dimensions. It works on both sway and
i3 window managers.

Bug#1064293: less: diff for NMU version 590-2.1

[Salvatore Bonaccorso]

Control: tags 1064293 + patch
Control: tags 1064293 + pending
Control: tags 1068938 + patch
Control: tags 1068938 + pending


Dear maintainer,

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

As well pushed in a separte branch on salsa, which can be merged if
accepted to unstable:

https://salsa.debian.org/debian/less/-/tree/sid-2024-security-fixes?ref_type=heads

Regards.
Salvatore
diff -Nru less-590/debian/changelog less-590/debian/changelog
--- less-590/debian/changelog	2023-03-12 17:18:18.0 +0100
+++ less-590/debian/changelog	2024-04-19 15:09:49.0 +0200
@@ -1,3 +1,13 @@
+less (590-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Shell-quote filenames when invoking LESSCLOSE (CVE-2022-48624)
+(Closes: #1064293)
+  * Fix bug when viewing a file whose name contains a newline (CVE-2024-32487)
+(Closes: #1068938)
+
+ -- Salvatore Bonaccorso   Fri, 19 Apr 2024 15:09:49 +0200
+
 less (590-2) sid; urgency=medium
 
   * d/control: set standards version to 4.6.2
diff -Nru less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch
--- less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch	1970-01-01 01:00:00.0 +0100
+++ less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch	2024-04-19 15:09:49.0 +0200
@@ -0,0 +1,67 @@
+From: Mark Nudelman 
+Date: Thu, 11 Apr 2024 17:49:48 -0700
+Subject: Fix bug when viewing a file whose name contains a newline.
+Origin: https://github.com/gwsw/less/commit/007521ac3c95bc76e3d59c6dbfe75d06c8075c33
+Bug-Debian: https://bugs.debian.org/1068938
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-32487
+
+---
+ filename.c | 31 +--
+ 1 file changed, 25 insertions(+), 6 deletions(-)
+
+--- a/filename.c
 b/filename.c
+@@ -136,6 +136,15 @@ metachar(c)
+ }
+ 
+ /*
++ * Must use quotes rather than escape char for this metachar?
++ */
++static int must_quote(char c)
++{
++	/* {{ Maybe the set of must_quote chars should be configurable? }} */
++	return (c == '\n'); 
++}
++
++/*
+  * Insert a backslash before each metacharacter in a string.
+  */
+ 	public char *
+@@ -168,6 +177,9 @@ shell_quote(s)
+  * doesn't support escape chars.  Use quotes.
+  */
+ use_quotes = 1;
++			} else if (must_quote(*p))
++			{
++len += 3; /* open quote + char + close quote */
+ 			} else
+ 			{
+ /*
+@@ -197,15 +209,22 @@ shell_quote(s)
+ 	{
+ 		while (*s != '\0')
+ 		{
+-			if (metachar(*s))
++			if (!metachar(*s))
+ 			{
+-/*
+- * Add the escape char.
+- */
++*p++ = *s++;
++			} else if (must_quote(*s))
++			{
++/* Surround the char with quotes. */
++*p++ = openquote;
++*p++ = *s++;
++*p++ = closequote;
++			} else
++			{
++/* Insert an escape char before the char. */
+ strcpy(p, esc);
+ p += esclen;
++*p++ = *s++;
+ 			}
+-			*p++ = *s++;
+ 		}
+ 		*p = '\0';
+ 	}
diff -Nru less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch
--- less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch	1970-01-01 01:00:00.0 +0100
+++ less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch	2024-04-19 15:09:49.0 +0200
@@ -0,0 +1,43 @@
+From: Mark Nudelman 
+Date: Sat, 25 Jun 2022 11:54:43 -0700
+Subject: Shell-quote filenames when invoking LESSCLOSE.
+Origin: https://github.com/gwsw/less/commit/c6ac6de49698be84d264a0c4c0c40bb870b10144
+Bug-Debian: https://bugs.debian.org/1064293
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-48624
+
+---
+ filename.c | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/filename.c b/filename.c
+index 5824e385dce4..dff20c08d81c 100644
+--- a/filename.c
 b/filename.c
+@@ -972,6 +972,8 @@ close_altfile(altfilename, filename)
+ {
+ #if HAVE_POPEN
+ 	char *lessclose;
++	char *qfilename;
++	char *qaltfilename;
+ 	FILE *fd;
+ 	char *cmd;
+ 	int len;
+@@ -986,9 +988,13 @@ close_altfile(altfilename, filename)
+ 		error("LESSCLOSE ignored; must contain no more than 2 %%s", NULL_PARG);
+ 		return;
+ 	}
+-	len = (int) (strlen(lessclose) + strlen(filename) + strlen(altfilename) + 2);
++	qfilename = shell_quote(filename);
++	qaltfilename = shell_quote(altfilename);
++	len = (int) (strlen(lessclose) + strlen(qfilename) + strlen(qaltfilename) + 2);
+ 	cmd = (char *) ecalloc(len, sizeof(char));
+-	SNPRINTF2(cmd, len, lessclose, filename, altfilename);
++	SNPRINTF2(cmd, len, lessclose, qfilename, qaltfilename);
++	free(qaltfilename);
++	free(qfilename);
+ 	fd = shellcmd(cmd);
+ 	free(cmd);
+ 	if (fd != NULL)
+-- 
+2.43.0
+
diff -Nru less-590/debian/patches/series 

Bug#1069285: trixie-pu: package flatpak/1.14.6-1~deb13u1

[Simon McVittie]

On Fri, 19 Apr 2024 at 14:09:24 +0200, Emilio Pozuelo Monfort wrote:
> On 19/04/2024 12:49, Simon McVittie wrote:
> > Fix CVE-2024-32462, a sandbox escape vulnerability, without having to
> > wait for the whole 64-bit time_t transition.
> 
> Please go ahead once you're ready, and let us know so that we can hint it
> into testing.

Uploaded, no changes since the debdiff you saw.

smcv

Bug#1064459: refining DEP17 patches for glibc and base-files

[Santiago Vila]

El 17/4/24 a las 20:07, Helmut Grohne escribió:

Please let me know when you did your editorial changes such that I can
replace my patch with yours and retest.


I did those minor changes in the branch wip-202404-usrmerge, just after your 
patch.
(If you adopt those changes, I'll rewrite the branch to be a single commit 
again)

Additionally (but did not have time to look at it yet), I'd like this line:

   $(foreach d,$(USR_MERGE),ln -s usr/$(d) debian/base-files/$(d) &&) :

to be a "shell" for instead (similar to the way debian/triggers is created).
The foreach feature is perfect in the dh_installdirs line, but in this case,
I would prefer shell code, for readability.

BTW: I am completely ok that we wait until the t64 transition is finished.

Thanks.

Bug#1052451: when receiving a SIGINT, unison should send it to the process group, not just to ssh

[Vincent Lefevre]

While doing tests, I've noticed a similar issue when I don't type
the passphrase and wait. In this case, there is a timeout from
unison: "Timed out negotiating connection with the server".
This corresponds (in src/remote.ml) to

let initConnection ?(connReady=fun () -> ()) ?cleanup in_ch out_ch =
  (* [makeConnection] is not expected to raise any recoverable exceptions.
 If this assumption changes in the future then [in_ch] and [out_ch] must
 be closed in the recovery code. *)
  let conn = makeConnection false in_ch out_ch in
  let close_on_fail t =
Lwt.catch (fun () -> t) (fun e -> closeConnection conn; Lwt.fail e)
  in
  let with_timeout t =
Lwt.choose [t;
  Lwt_unix.sleep 120. >>= fun () ->
  Lwt.fail (Util.Fatal "Timed out negotiating connection with the server")]
  in
  close_on_fail (with_timeout (
peekWithBlocking conn.inputBuffer >>= fun _ ->
connReady (); Lwt.return () >>= fun () -> (* Connection working, notify *)
checkHeader conn >>=
checkServerUpgrade conn >>=
checkServerVersion conn)) >>= fun () ->
  registerConnCleanup conn cleanup;
[...]

I can see that the process gets a SIGTERM.

But at least in this case, I think that unison is correct, and that my
wrapper should catch the signal and kill its child process if there is
one. And it could do that for SIGINT too (original issue).

In short, it may not be worth to change unison.

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

Bug#1064459: refining DEP17 patches for glibc and base-files

[Helmut Grohne]

Hi Santiago,

On Wed, Apr 17, 2024 at 01:40:21PM +0200, Santiago Vila wrote:
> Nice feature indeed. To simplify the usr-merge patch, I've adopted
> the -D change in debian/postinst *before* we apply the usr-merge patch.

Thank you.

> Please take a look at branch "wip-202404-usrmerge" here:
> 
> https://salsa.debian.org/sanvila/base-files-not-yet/-/tree/wip-202404-usrmerge?ref_type=heads
> 
> (The repository name speaks for itself... I'm still not comfortable enough
> with salsa, but I'd like to experiment and see how it goes).
> 
> I've rebased the patch relative to version 13.1 which I have just uploaded.

Yeah, looks reasonable.

> If the rebase is ok, I'd like to make some minor editorial changes there as 
> well.

I noticed your upload before your mail and already updated the
integration branch:

https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo/-/blob/main/patches/base-files

Please let me know when you did your editorial changes such that I can
replace my patch with yours and retest.

At this time, we're down to the 5 planned packages base-files, bash,
dash, glibc and util-linux and could upload in principle, but we really
want time64 to migrate first and it's not clear when that'll happen. I'm
negotiating a transition slot.

Helmut

Bug#1069299: kodi-visualization-waveform FTBFS on arm*: does not agree on gl vs gles

[Helmut Grohne]

Source: kodi-visualization-waveform
Version: 20.2.1+ds1-1
Severity: serious
Tags: ftbfs

kodi-visualization-waveform fails to build from source on arm
architectures. A build fails like this:

| CMake Error at 
/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
|   Could NOT find OpenGLES (missing: OPENGLES_gl_LIBRARY OPENGLES_INCLUDE_DIR)
| Call Stack (most recent call first):
|   /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
|   FindOpenGLES.cmake:37 (find_package_handle_standard_args)
|   CMakeLists.txt:41 (find_package)

Looking into CMakeLists.txt, one can see that it takes the
APP_RENDER_SYSTEM=gles path. I guess this is rooted in kodi recently
having changed this for all arm architectures via #1056563. Now
kodi-visualization-waveform does not have any dependency on gles
libraries but happens to pull gl libraries transitively. As a result the
build now fails.

I'm not sure whether this is to be fixed in kodi-visualization-waveform
or kodi. The end result is that this very package FTBFS. Hence filing
here initially, but reassigning may still make sense.

Helmut

Bug#1069298: libsfml FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: libsfml
Version: 2.6.1+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libsfml fails to cross build from source, because it fails running its
test suite despite being given DEB_BUILD_OPTIONS=nocheck. I'm attaching
a patch to add support for disabling tests and verified that doing so
does not affect the output artifacst via reproducible builds.

Helmut
diff --minimal -Nru libsfml-2.6.1+dfsg/debian/changelog 
libsfml-2.6.1+dfsg/debian/changelog
--- libsfml-2.6.1+dfsg/debian/changelog 2023-12-02 12:33:22.0 +0100
+++ libsfml-2.6.1+dfsg/debian/changelog 2024-04-19 08:28:52.0 +0200
@@ -1,3 +1,10 @@
+libsfml (2.6.1+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Support DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 19 Apr 2024 08:28:52 +0200
+
 libsfml (2.6.1+dfsg-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru libsfml-2.6.1+dfsg/debian/control 
libsfml-2.6.1+dfsg/debian/control
--- libsfml-2.6.1+dfsg/debian/control   2023-12-02 12:33:22.0 +0100
+++ libsfml-2.6.1+dfsg/debian/control   2024-04-19 08:28:27.0 +0200
@@ -6,7 +6,7 @@
  James Cowgill 
 Build-Depends: debhelper-compat (= 13),
  cmake,
- catch,
+ catch ,
  doxygen,
  libflac-dev,
  libfreetype-dev,
diff --minimal -Nru libsfml-2.6.1+dfsg/debian/rules 
libsfml-2.6.1+dfsg/debian/rules
--- libsfml-2.6.1+dfsg/debian/rules 2023-12-02 12:33:22.0 +0100
+++ libsfml-2.6.1+dfsg/debian/rules 2024-04-19 08:28:50.0 +0200
@@ -8,7 +8,7 @@
dh_auto_configure -- \
-DSFML_BUILD_DOC=ON \
-DSFML_BUILD_EXAMPLES=ON \
-   -DSFML_BUILD_TEST_SUITE=ON
+   -DSFML_BUILD_TEST_SUITE=$(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),OFF,ON)
 
 override_dh_auto_build:
dh_auto_build -- all doc

Bug#1001751: debfoster: Debfoster offers to remove python that many fostered packages depend on

[Andrey Rakhmatullin]

I've just got a problem which may be related:

python3-dbg is keeping the following 3 packages installed:
  libpython3-dbg libpython3.11t64-dbg python3.11-dbg
Keep python3-dbg? [Ynpsiuqx?], [H]elp: N
Keep libpython3-dbg? [Ynpsiuqx?], [H]elp: N

python3.11-dbg is keeping the following 1 packages installed:
  libpython3.11t64-dbg
Keep python3.11-dbg? [Ynpsiuqx?], [H]elp: N
Keep libpython3.11t64-dbg? [Ynpsiuqx?], [H]elp: N
The following packages will be REMOVED:
  cython3* libpython3-dbg* libpython3.11t64-dbg* python3-dbg* python3.11-dbg*

So it doesn't "see" cython3 which depends on python3-dbg:any. Can it be a
problem with handling :any deps? debfoster -v prints a lot of noise
regarding them. #910682 may be related too.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1069296: sbmltoolbox: Depends on pre-t64 libsbml5

[Bastian Germann]

I am uploading a LowNMU in order to fix this.
The debdiff is attached.

sbmltoolbox_4.1.0-5.1.debdiff
Description: Binary data

Bug#1069297: bullseye-pu: package reportbug/7.10.3+deb11u2

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Reportbug Maintainers 
Control: affects -1 + src:reportbug

[ Reason ]
After the release of bookworm, we should rotate the release codenames in
reportbug/bullseye again to keep reportbug/bullseye useful. Fixed in
sid/bookworm via #1034260.

[ Impact ]
Requires manual error prone adjustments if templates for e.g. some
release.debian.org bug classes are not available.

[ Tests ]
This bug report. :-)

[ Risks ]
low, only data update

[ 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 ]
+reportbug (7.10.3+deb11u2) bullseye; urgency=medium
+
+  * Rotate suite names after the bookworm release.
+
+ -- Andreas Beckmann   Fri, 19 Apr 2024 15:45:33 +0200

[ Other info ]
n/a

Andreas
diff -Nru reportbug-7.10.3+deb11u1/debian/changelog 
reportbug-7.10.3+deb11u2/debian/changelog
--- reportbug-7.10.3+deb11u1/debian/changelog   2021-09-06 17:35:39.0 
+0200
+++ reportbug-7.10.3+deb11u2/debian/changelog   2024-04-19 15:45:33.0 
+0200
@@ -1,3 +1,9 @@
+reportbug (7.10.3+deb11u2) bullseye; urgency=medium
+
+  * Rotate suite names after the bookworm release.
+
+ -- Andreas Beckmann   Fri, 19 Apr 2024 15:45:33 +0200
+
 reportbug (7.10.3+deb11u1) bullseye; urgency=medium
 
   [ Thomas Goirand ]
diff -Nru reportbug-7.10.3+deb11u1/reportbug/__init__.py 
reportbug-7.10.3+deb11u2/reportbug/__init__.py
--- reportbug-7.10.3+deb11u1/reportbug/__init__.py  2021-09-06 
17:35:39.0 +0200
+++ reportbug-7.10.3+deb11u2/reportbug/__init__.py  2024-04-19 
15:45:33.0 +0200
@@ -25,7 +25,7 @@
 __all__ = ['bugreport', 'utils', 'urlutils', 'checkbuildd', 'checkversions',
'debbugs', 'exceptions', 'submit', 'tempfile', 'mailer']
 
-VERSION_NUMBER = "7.10.3+deb11u1"
+VERSION_NUMBER = "7.10.3+deb11u2"
 
 VERSION = "reportbug " + VERSION_NUMBER
 COPYRIGHT = VERSION + '\nCopyright (C) 1999-2008 Chris Lawrence 
' + \
diff -Nru reportbug-7.10.3+deb11u1/reportbug/utils.py 
reportbug-7.10.3+deb11u2/reportbug/utils.py
--- reportbug-7.10.3+deb11u1/reportbug/utils.py 2021-09-06 17:35:39.0 
+0200
+++ reportbug-7.10.3+deb11u2/reportbug/utils.py 2024-04-19 15:45:33.0 
+0200
@@ -95,13 +95,14 @@
'/usr/man', '/usr/doc', '/usr/bin']
 
 # A map between codenames and suites
-CODENAME2SUITE = {'wheezy': 'oldoldoldoldstable',
-  'jessie': 'oldoldoldstable',
-  'stretch': 'oldoldstable',
-  'buster': 'oldstable',
-  'bullseye': 'stable',
-  'bookworm': 'testing',
-  'trixie': 'next-testing',
+CODENAME2SUITE = {'wheezy': 'oldoldoldoldoldstable',
+  'jessie': 'oldoldoldoldstable',
+  'stretch': 'oldoldoldstable',
+  'buster': 'oldoldstable',
+  'bullseye': 'oldstable',
+  'bookworm': 'stable',
+  'trixie': 'testing',
+  'forky': 'next-testing',
   'sid': 'unstable',
   'experimental': 'experimental'}
 SUITE2CODENAME = dict([(suite, codename) for codename, suite in 
list(CODENAME2SUITE.items())])

Bug#1069296: sbmltoolbox: Depends on pre-t64 libsbml5

[Bastian Germann]

Package: sbmltoolbox
Version: 4.1.0-5
Severity: important

The package depends on libsbml5, which was renamed as part of the t64 
transition.
Please drop that dependency as it is implicit via libsbml5-octave, which 
already depends on the new name.

Bug#1064293: less: CVE-2022-48624

[Salvatore Bonaccorso]

Hi,

FWIW, I'm actually preparing a security update for the two CVEs and
for bookworm I was first planning to do a 590-2.1 reaching unstable,
and so then 590-2.1~deb12u1 for bookworm.

But if you want to override it with a NMU and proposing to salvage the
package this is equally fine.

Regards,
Salvatore

Bug#1069295: bookworm-pu: package python-asdf/2.14.3-1+deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Ole Streicher 
Control: block 1054581 with -1
Control: affects -1 + src:python-asdf

[ Reason ]
python3-asdf has an internal dependency on asdf-unit-schemas which is
neither mapped to a package dependency nor does it exist in the archive.
This internal dependency (which only exists for backward compatibility
but is not required) has been patched out in sid, let's backport this.

[ Impact ]
Some usage paths of python3-asdf are failing because of unsatisfied
requirements.

[ Tests ]
python3 -c 'import pkg_resources; pkg_resources.require("asdf")'
does no longer fail with the updated package.

[ Risks ]
Low. Removes unneeded requirements.

[ 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 ]
+python-asdf (2.14.3-1+deb12u1) bookworm; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Backport dependency fix from 3.0.0-2.
+
+  [ Ole Streicher ]
+  * Remove asdf-unit-schemas as a dependency (Closes: #1054581)
+
+ -- Andreas Beckmann   Fri, 19 Apr 2024 14:06:08 +0200

[ Other info ]
n/a

Andreas
diff -Nru python-asdf-2.14.3/debian/changelog 
python-asdf-2.14.3/debian/changelog
--- python-asdf-2.14.3/debian/changelog 2022-12-20 11:26:17.0 +0100
+++ python-asdf-2.14.3/debian/changelog 2024-04-19 14:06:08.0 +0200
@@ -1,3 +1,14 @@
+python-asdf (2.14.3-1+deb12u1) bookworm; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Backport dependency fix from 3.0.0-2.
+
+  [ Ole Streicher ]
+  * Remove asdf-unit-schemas as a dependency (Closes: #1054581)
+
+ -- Andreas Beckmann   Fri, 19 Apr 2024 14:06:08 +0200
+
 python-asdf (2.14.3-1) unstable; urgency=medium
 
   * New upstream version 2.14.3
diff -Nru 
python-asdf-2.14.3/debian/patches/Remove-asdf-unit-schemas-as-a-dependency.patch
 
python-asdf-2.14.3/debian/patches/Remove-asdf-unit-schemas-as-a-dependency.patch
--- 
python-asdf-2.14.3/debian/patches/Remove-asdf-unit-schemas-as-a-dependency.patch
1970-01-01 01:00:00.0 +0100
+++ 
python-asdf-2.14.3/debian/patches/Remove-asdf-unit-schemas-as-a-dependency.patch
2024-04-19 14:06:08.0 +0200
@@ -0,0 +1,22 @@
+From: Ole Streicher 
+Date: Fri, 27 Oct 2023 09:12:53 +0200
+Subject: Remove asdf-unit-schemas as a dependency
+
+This dependency was only added for backward compatibility and is no
+strict requirement.
+
+Closes: #1054581
+---
+ pyproject.toml | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/pyproject.toml
 b/pyproject.toml
+@@ -18,7 +18,6 @@ classifiers = [
+ dependencies = [
+ 'asdf-standard >=1.0.1',
+ 'asdf-transform-schemas >=0.3.0',
+-'asdf-unit-schemas >= 0.1.0',
+ 'importlib_resources >=3; python_version <"3.9"',
+ 'importlib-metadata >=4.11.4',
+ 'jmespath >=0.6.2',
diff -Nru python-asdf-2.14.3/debian/patches/series 
python-asdf-2.14.3/debian/patches/series
--- python-asdf-2.14.3/debian/patches/series2022-12-20 11:26:17.0 
+0100
+++ python-asdf-2.14.3/debian/patches/series2024-04-19 14:06:08.0 
+0200
@@ -6,3 +6,4 @@
 Disable-fetching-of-latest-patch-in-test.patch
 Remove-dependency-on-sphinx-asdf.patch
 Ignore-Astropy-deprecation-warnings-in-tests.patch
+Remove-asdf-unit-schemas-as-a-dependency.patch

Bug#1035064: software-properties-qt: First tab labeled 'Ubuntu Software'

[john faulk]

Package: software-properties-qt
Version: 0.99.30-4
Followup-For: Bug #1035064
X-Debbugs-Cc: johnny.faul...@yahoo.com

Can confirm that this bug still affects software-properties-qt in Bookworm
-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Versions of packages software-properties-qt depends on:
ii  debconf-kde-helper   1.1.0-1
ii  python3  3.11.2-1+b1
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-software-properties  0.99.30-4
ii  software-properties-common   0.99.30-4

software-properties-qt recommends no packages.

Versions of packages software-properties-qt suggests:
ii  plasma-discover  5.27.5-2

-- no debconf information

Bug#1069294: [PATCH] install emacs-nox desktop file

[Brendan O'Dea]

Package: emacs-nox
Version: 1:29.3+1-1
Tags: patch

A minor typo in debian/rules installs the emacs.term-desktop file in the
wrong location for emacs-nox.

It appears to be a simple typo (copy-and-paste error).  Compare the
entries in /usr/share/applications of:

  https://packages.debian.org/sid/amd64/emacs-gtk/filelist
  https://packages.debian.org/sid/amd64/emacs-nox/filelist

Patch follows.

--bod

diff --git a/debian/rules b/debian/rules
index b7ab47c912f..6250f60ea9b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -565,9 +565,9 @@ override_dh_auto_install: $(autogen_install_files)
  $(call emacs_inst,build-nox,$(install_dir_nox))
  $(call 
install_common_binpkg_bits,$(install_dir_nox),$(pkgdir_nox),emacs-nox,nox)
   # install desktop entry
- install -d $(pkgdir_gtk)/usr/share/applications
+ install -d $(pkgdir_nox)/usr/share/applications
  install -m 0644 \
-   debian/emacs-term.desktop $(pkgdir_gtk)/usr/share/applications/
+   debian/emacs-term.desktop $(pkgdir_nox)/usr/share/applications/
  rm -rf $(install_dir_nox)
 endif
 

Bug#1069293: ITP: pico-sdk -- headers and libraries to write programs for RP2040-based devices

[Johannes Schauer Marin Rodrigues]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer Marin Rodrigues 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pico-sdk
  Version : 1.5.1
  Upstream Contact: https://github.com/raspberrypi/pico-sdk/issues
* URL : https://github.com/raspberrypi/pico-sdk/
* License : BSD-3-clause
  Programming Lang: C/C++
  Description : headers and libraries to write programs for RP2040-based 
devices

The Raspberry Pi Pico SDK provides the headers, libraries and build system
necessary to write programs for the RP2040-based devices such as the Raspberry
Pi Pico in C, C++ or assembly language.

The SDK is designed to provide an API and programming environment that is
familiar both to non-embedded C developers and embedded C developers alike. A
single program runs on the device at a time and starts with a conventional
main() method. Standard C/C++ libraries are supported along with C level
libraries/APIs for accessing all of the RP2040's hardware include PIO.

Additionally the SDK provides higher level libraries for dealing with timers,
synchronization, USB (TinyUSB) and multi-core programming along with various
utilities.

The SDK can be used to build anything from simple applications, to fully
fledged runtime environments such as MicroPython, to low level software such
as RP2040's on-chip bootrom itself.

Bug#1060546: mandos: Please switch Build-Depends to systemd-dev

[Bastian Germann]

I am uploading a NMU in order to fix this without delay as this is part of the 
t64 transition.

mandos_1.8.16-1.1.debdiff
Description: Binary data

Bug#1069275: apt: random display of the "Summary:" line

[David Kalnischkies]

On Fri, Apr 19, 2024 at 02:06:44PM +0200, Antonio wrote:
> If you find the "apt autoremove --purge" command in the sequence of the
> commands I have indicated, you will notice that it appears three times:
> 
> - in second position produces this output:
> 
> $ apt autoremove --purge
^^^
> Summary:
>    Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> - in seventh position it produces the same output
> 
> $ apt autoremove --purge
^^^
> Summary:
>    Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> but the same command, in the fifteenth position produces a different output:
  
> 
> $ apt-get autoremove --purge
^^^
> 0 updated, 0 installed, 0 to be removed and 0 not updated.
> 
> what has changed? I would always expect the same output...

(Lets play a game! Lets call it: Spot the difference. )

As Julian already mentioned, "apt" and "apt-get" have different output.
This is intended (for compat) and not random, but yes, it can be a bit
confusing if your muscle memory lets you end up mix their use.

(Note that not only their output is different; they also have behaviour
 differences e.g. "apt-get upgrade" vs "apt upgrade")

As an interactive user, its is probably best to forget apt-{get,cache,…}
exist and get used to 'apt'. If that is missing something compared to
the others feel free to report a bug so we can add it – or suggest an
alternative as sometimes that might be better approach.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1069292: libcurl4t64: regression: CURLINFO_REQUEST_SIZE returns 0

[Antonio Terceiro]

Package: libcurl4t64
Version: 8.7.1-2
Severity: important
Tags: upstream patch
Forwarded: https://github.com/curl/curl/issues/13269

Dear Maintainer,

curl 8.7 no longer fills in the request_size field. This has been
reported upstream in the following issue:

https://github.com/curl/curl/issues/13269

This causes at least ruby-ethon, a Ruby library that wraps libcurl via
FFI, to fail its test suite (after fixing it to not hardcode libcurl4 as
a dependency), like this:

8<8<8<-
Failures:

  1) Ethon::Easy::Informations#request_size returns 53
 Failure/Error: expect(easy.request_size).to eq(53)

   expected: 53
got: 0

   (compared using ==)
 # ./spec/ethon/easy/informations_spec.rb:92:in `block (3 levels) in '

Finished in 5.06 seconds (files took 0.80166 seconds to load)
578 examples, 1 failure, 2 pending

Failed examples:

rspec ./spec/ethon/easy/informations_spec.rb:91 # 
Ethon::Easy::Informations#request_size returns 53
8<8<8<-

(the same test suite passes just fine against libcurl4 8.6.0-3 from testing.)

I have tested the patch in https://github.com/curl/curl/pull/13275 and
it indeed fixes this. I'm including a patch against the Debian package
in the archive that includes this patch in debian/patches, with the
fuzzyness already removed, and updates debian/patches/series accordingly.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.15-arm64 (SMP w/32 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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 libcurl4t64 depends on:
ii  libbrotli11.1.0-2+b3
ii  libc6 2.37-15
ii  libgssapi-krb5-2  1.20.1-5+b1
ii  libidn2-0 2.3.7-2
ii  libldap-2.5-0 2.5.13+dfsg-5+b3
ii  libnghttp2-14 1.59.0-1
pn  libpsl5t64
ii  librtmp1  2.4+20151223.gitfa8646d.1-2+b2
pn  libssh2-1t64  
pn  libssl3t64
ii  libzstd1  1.5.5+dfsg2-2
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages libcurl4t64 recommends:
ii  ca-certificates  20240203

libcurl4t64 suggests no packages.
diff -Nru curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch
--- curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch	1970-01-01 00:00:00.0 +
+++ curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch	2024-04-19 13:18:39.0 +
@@ -0,0 +1,210 @@
+From 2793acbfc5e89fb130b1d4e045cb6cd7b6549412 Mon Sep 17 00:00:00 2001
+From: Stefan Eissing 
+Date: Thu, 4 Apr 2024 11:06:06 +0200
+Subject: [PATCH] Fix CURLINFO_REQUEST_SIZE, add tests for transfer infos
+ reported
+
+- refs #13269
+- tests for 'size_request' and other stats reported, for
+  presence and consistency
+---
+ lib/transfer.c  |   3 +
+ tests/http/test_16_info.py  | 162 
+ tests/http/testenv/httpd.py |   1 +
+ 3 files changed, 166 insertions(+)
+ create mode 100644 tests/http/test_16_info.py
+
+Index: curl-8.7.1/lib/transfer.c
+===
+--- curl-8.7.1.orig/lib/transfer.c
 curl-8.7.1/lib/transfer.c
+@@ -1221,6 +1221,9 @@ CURLcode Curl_xfer_send(struct Curl_easy
+ result = CURLE_OK;
+ *pnwritten = 0;
+   }
++  else if(!result && *pnwritten)
++data->info.request_size += *pnwritten;
++
+   return result;
+ }
+ 
+Index: curl-8.7.1/tests/http/test_16_info.py
+===
+--- /dev/null
 curl-8.7.1/tests/http/test_16_info.py
+@@ -0,0 +1,162 @@
++#!/usr/bin/env python3
++# -*- coding: utf-8 -*-
++#***
++#  _   _   _
++#  Project ___| | | |  _ \| |
++# / __| | | | |_) | |
++#| (__| |_| |  _ <| |___
++# \___|\___/|_| \_\_|
++#
++# Copyright (C) Daniel Stenberg, , et al.
++#
++# This software is licensed as described in the file COPYING, which
++# you should have received as part of this distribution. The terms
++# are also available at https://curl.se/docs/copyright.html.
++#
++# You may opt to use, copy, modify, merge, publish, distribute and/or sell
++# copies of the Software, and permit persons to whom the Software is
++# furnished to do so, under the terms of the COPYING file.
++#
++# This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
++# KIND, either express or implied.
++#
++# SPDX-License-Identifier: curl
++#

Bug#1069291: bookworm-pu: package comitup/1.38-2~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: David Steele 
Control: block 1041447 with -1
Control: tag -1 + src:comitup

[ Reason ]
On certain upgrade paths installation/upgrade will fail if a masked
service file from a previous installation is still present.

[ Impact ]
This is mostly triggered by QA tests.

[ Tests ]
Local piuparts tests of the affected upgrade path.

[ Risks ]
Low. Unmasking a not masked service is a no-op.

[ 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 ]
-comitup (1.38-1.1) unstable; urgency=medium
+comitup (1.38-2~deb12u1) bookworm; urgency=medium
 
   * Non-maintainer upload.
-  * No source change upload to rebuild with debhelper 13.10.
+  * Rebuild for bookworm.
 
- -- Michael Biebl   Sat, 15 Oct 2022 11:57:26 +0200
+ -- Andreas Beckmann   Fri, 19 Apr 2024 14:56:56 +0200
+
+comitup (1.38-2) unstable; urgency=medium
+
+  * Ensure service is unmasked in post install (Closes: #1041447).
+
+ -- David Steele   Fri, 28 Jul 2023 17:12:44 -0400

There is also a new autopkgtest, but it is unrelated to this issue.

[ Other info ]
This is a rebuild of the package that has been in sid and testing for 5
months before it got superseded by a new upstream release.

Andreas
diff -Nru comitup-1.38/debian/changelog comitup-1.38/debian/changelog
--- comitup-1.38/debian/changelog   2022-10-15 11:57:26.0 +0200
+++ comitup-1.38/debian/changelog   2024-04-19 14:56:56.0 +0200
@@ -1,9 +1,15 @@
-comitup (1.38-1.1) unstable; urgency=medium
+comitup (1.38-2~deb12u1) bookworm; urgency=medium
 
   * Non-maintainer upload.
-  * No source change upload to rebuild with debhelper 13.10.
+  * Rebuild for bookworm.
 
- -- Michael Biebl   Sat, 15 Oct 2022 11:57:26 +0200
+ -- Andreas Beckmann   Fri, 19 Apr 2024 14:56:56 +0200
+
+comitup (1.38-2) unstable; urgency=medium
+
+  * Ensure service is unmasked in post install (Closes: #1041447).
+
+ -- David Steele   Fri, 28 Jul 2023 17:12:44 -0400
 
 comitup (1.38-1) unstable; urgency=medium
 
diff -Nru comitup-1.38/debian/comitup.postinst 
comitup-1.38/debian/comitup.postinst
--- comitup-1.38/debian/comitup.postinst2022-07-08 04:51:57.0 
+0200
+++ comitup-1.38/debian/comitup.postinst2023-07-28 21:02:12.0 
+0200
@@ -12,6 +12,7 @@
   rm -f /etc/NetworkManager/dnsmasq-shared.d/nm-dns-sabotage.conf
 fi
 
+systemctl unmask comitup
 systemctl enable comitup
 
 python3 /usr/share/comitup/comitup/wificheck.py || true
diff -Nru comitup-1.38/debian/tests/control comitup-1.38/debian/tests/control
--- comitup-1.38/debian/tests/control   2022-07-08 04:51:57.0 +0200
+++ comitup-1.38/debian/tests/control   2023-07-28 03:54:33.0 +0200
@@ -1,4 +1,5 @@
 Test-Command: py.test-3 test/test_config.py test/test_persist.py test/test_web*
+Features: test-name=pytest
 Depends:
 @,
 @builddeps@,
@@ -8,3 +9,6 @@
 python3-dev,
 libdbus-glib-1-dev,
 libdbus-1-dev
+
+Tests: fileloc
+Depends: @, bash
diff -Nru comitup-1.38/debian/tests/fileloc comitup-1.38/debian/tests/fileloc
--- comitup-1.38/debian/tests/fileloc   1970-01-01 01:00:00.0 +0100
+++ comitup-1.38/debian/tests/fileloc   2023-07-28 03:54:33.0 +0200
@@ -0,0 +1,20 @@
+#!/bin/bash
+
+declare -a Paths=("/etc/comitup.conf" \
+   "/etc/dbus-1/system.d/comitup-dbus.conf" \
+   "/lib/systemd/system/comitup.service" \
+   "/usr/share/comitup/comitup-cmd" \
+   "/usr/share/comitup/web/comitupweb.py"\
+   "/usr/sbin/comitup" \
+   "/var/lib/comitup" \
+   "/usr/share/comitup/comitup/comitup.py")
+
+retval=0
+for path in ${Paths[@]}; do
+if [ ! -e $path ]; then
+echo "Not found - $path"
+retval=1
+fi
+done
+
+exit $retval

Bug#1069290: ITP: picotool -- interact with RP2040 devices or binaries

[Johannes Schauer Marin Rodrigues]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer Marin Rodrigues 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: picotool
  Version : 1.1.2
  Upstream Contact: Graham Sanderson 
* URL : https://github.com/raspberrypi/picotool/
* License : BSD-3-clause
  Programming Lang: C++
  Description : interact with RP2040 devices or binaries

Tool for interacting with a RP2040 device in BOOTSEL mode, or with a RP2040
binary. It allows one to load programs onto the device or save programs from
flash to a file. It allows one to verify device contents or reboot the device.

Bug#1067923: alsa-ucm-conf: should depend on libasound2t64 instead of libasound2

[Bastian Germann]

I am uploading a NMU to fix this.
The debdiff is attached.

alsa-ucm-conf_1.2.11-1.1.debdiff
Description: Binary data

Bug#1069285: trixie-pu: package flatpak/1.14.6-1~deb13u1

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 19/04/2024 12:49, Simon McVittie wrote:

Package: release.debian.org
Severity: normal
Tags: trixie
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: flat...@packages.debian.org
Control: affects -1 + src:flatpak

[ Reason ]
Fix CVE-2024-32462, a sandbox escape vulnerability, without having to
wait for the whole 64-bit time_t transition.

[ Impact ]
If not fixed, malicious or compromised Flatpak apps can execute arbitrary
code on the host system. (Severity: grave)

The new upstream release also fixes one high-visibility non-security bug:
after some infrastructure changes on Flathub, the flatpak(1) CLI currently
mis-displays apps' developer names as though they were the name of the app,
for example showing org.chromium.Chromium as "The Chromium Authors" instead
of the correct "Chromium Web Browser". The proposed version corrects this.
(Severity: important)

[ Tests ]
Flatpak has a rather large test suite, which still passes. Unfortunately,
most tests have to be skipped when running under schroot or lxc because
those frameworks don't allow creating a nested user namespace, but I do
run the autopkgtest suite under autopkgtest-virt-qemu before uploading.

There is new automated test coverage for CVE-2024-32462 and for the
mis-display of app names.

I'll do a smoke-test on a trixie GNOME VM (install an app, run an app,
and verify that CVE-2024-32462 is fixed) before uploading.


Please go ahead once you're ready, and let us know so that we can hint it into 
testing.


Cheers,
Emilio

Bug#1069289: arguments to dbus_server_get_address() were incorrect, assertion "server != NULL" failed in file ../../../dbus/dbus-server.c line 840

[Arturo Borrero Gonzalez]

Source: sssd
Version: 2.8.2-4
Severity: normal
Tags: upstream

Hi there,

thanks for your work with the sssd packages, really appreciated.

Today I found this assert that is preventing the sssd.service from starting:

Apr 19 14:02:17 debian sssd[586]: Starting up
Apr 19 14:02:17 debian sssd[586]: dbus[586]: arguments to 
dbus_server_get_address() were incorrect, assertion "server != NULL" failed in 
file ../../../dbus/dbus-server.c line 840.
Apr 19 14:02:17 debian sssd[586]: This is normally a bug in some application 
using the D-Bus library.
Apr 19 14:02:17 debian sssd[586]:   D-Bus not built with -rdynamic so unable to 
print a backtrace
Apr 19 14:02:17 debian systemd[1]: sssd.service: Main process exited, 
code=killed, status=6/ABRT
Apr 19 14:02:17 debian systemd[1]: sssd.service: Failed with result 'signal'.
Apr 19 14:02:17 debian systemd[1]: Failed to start sssd.service - System 
Security Services Daemon.

My configuration:

$ sudo cat /etc/sssd/sssd.conf
[sssd]
domains = files
config_file_version = 2

[domain/files]
id_provider = files
access_provider = permit


Packages in my system:

$ dpkg -l *sss*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---
ii  libnss-sss:amd64  2.8.2-4  amd64Nss library for the System 
Security Services Daemon
ii  libpam-sss:amd64  2.8.2-4  amd64Pam module for the System 
Security Services Daemon
ii  libsss-certmap0   2.8.2-4  amd64Certificate mapping library for 
SSSD
ii  libsss-idmap0 2.8.2-4  amd64ID mapping library for SSSD
ii  libsss-nss-idmap0 2.8.2-4  amd64SID based lookups library for 
SSSD
un  libsss-sudo (no description available)
ii  python3-sss   2.8.2-4  amd64Python3 module for the System 
Security Services Daemon
ii  sssd  2.8.2-4  amd64System Security Services Daemon 
-- metapackage
ii  sssd-ad   2.8.2-4  amd64System Security Services Daemon 
-- Active Directory back end
ii  sssd-ad-common2.8.2-4  amd64System Security Services Daemon 
-- PAC responder
ii  sssd-common   2.8.2-4  amd64System Security Services Daemon 
-- common files
un  sssd-dbus   (no description available)
ii  sssd-ipa  2.8.2-4  amd64System Security Services Daemon 
-- IPA back end
ii  sssd-krb5 2.8.2-4  amd64System Security Services Daemon 
-- Kerberos back end
ii  sssd-krb5-common  2.8.2-4  amd64System Security Services Daemon 
-- Kerberos helpers
ii  sssd-ldap 2.8.2-4  amd64System Security Services Daemon 
-- LDAP back end
ii  sssd-proxy2.8.2-4  amd64System Security Services Daemon 
-- proxy back end
ii  sssd-tools2.8.2-4  amd64System Security Services Daemon 
-- tools


I'm not sure who is to blame, if Dbus or sssd.
In any case, in my opinion, some actionable error message should be produced, 
rather than a weird assert.

Bug#1069275: apt: random display of the "Summary:" line

[Antonio]

Hi,
I noticed this by chance, so I did some testing to find why the same 
command produces two different outputs (note that I ran the commands one 
after the other, as root, in the same session).


If you find the "apt autoremove --purge" command in the sequence of the 
commands I have indicated, you will notice that it appears three times:


- in second position produces this output:

$ apt autoremove --purge
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

- in seventh position it produces the same output

$ apt autoremove --purge
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

but the same command, in the fifteenth position produces a different output:

$ apt-get autoremove --purge
0 updated, 0 installed, 0 to be removed and 0 not updated.

what has changed? I would always expect the same output...

It seems like this is a random issue because it doesn't always happen 
(and I don't know how to reproduce it).



Il 19/04/24 13:28, Julian Andres Klode ha scritto:

On Fri, Apr 19, 2024 at 10:06:31AM +0200, Antonio wrote:

Package: apt
Version: 2.9.1
Severity: minor
X-Debbugs-Cc: antde...@gmail.com

Dear Maintainer,
I report a minor bug on apt that I sometimes get by running the commands
below
in sequence.

Note that in the last commands the "Summary:" line is not displayed whereas
previously, with the same commands, it was displayed.

I tried this sequence as root; as a user I see that the word "Summary" never
appears.

Seems to be a random problem.

Thank you for your bug report,

looking at your output, everything seems to be in order:

All your apt(8) executions use the apt(8) modern interface,
and all your apt-get(8) executions use the classic interface
- as they should for backwards-compatibility.

Is it possible your muscle memory is playing tricks on you, making
you type sudo apt-get whereas you use apt as a user?

But maybe I missed it, so do double check.

Have a nice day!


-- SEQUENCE --

$ apt autoremove
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

$ apt autoremove --purge
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

$ sudo apt autoremove --purge
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

$ (sudo apt autoremove --purge)
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0


These are all apt(8) with the modern interface.


$ gawk '{print}'< <(sudo apt-get autoremove; sudo apt-get clean; sudo
apt-get
autoclean; sudo apt-get -f install; sudo apt-get check)
Lettura elenco dei pacchetti...
Generazione albero delle dipendenze...
Lettura informazioni sullo stato...
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
Lettura elenco dei pacchetti...
Generazione albero delle dipendenze...
Lettura informazioni sullo stato...
Lettura elenco dei pacchetti...
Generazione albero delle dipendenze...
Lettura informazioni sullo stato...
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
Lettura elenco dei pacchetti...
Generazione albero delle dipendenze...
Lettura informazioni sullo stato...

These are all apt-get(8) with the classic interface.


$ apt autoremove
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

$ apt autoremove --purge
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

$ (sudo apt autoremove --purge)
Summary:
   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

These are all apt(8) and all have the summary line.


$ sudo apt-get autoremove; sudo apt-get clean; sudo apt-get autoclean; sudo
apt-get -f install; sudo apt-get check
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

$ sudo apt-get autoremove
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

$ sudo apt-get autoremove
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

$ sudo apt-get autoremove --purge
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

$ sudo apt-get autoremove --purge
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

$ apt-get autoremove
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

$ apt-get autoremove --purge
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

These are all apt-get(8) which uses the classic interface.

Bug#1069288: init: runit-init disappeared from PreDepends somewhere around 1.60

[Peter Gervai]

Package: init
Version: 1.60
Severity: normal

init 1.56+nmu1 had predepends on systemd-sysv | sysvinit-core | runit-init
init 1.60 and on has only systemd-sysv | sysvinit-core
runit-init seems to be gone?

I see nothing about that in changelog, nor it's obvious why this have happened, 
but it does not look right; it very much tries to break very hard any systems
using runit-init.

It's also a bit confusing what have (not) happened in #924132 since, erm, may 
2019?

Thanks!

Bug#1069287: RFS: winff/1.6.4+dfsg-1 -- graphical video and audio batch converter using ffmpeg or avconv

[Peter Blackman]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "winff":

 * Package name : winff
   Version  : 1.6.4+dfsg-1
   Upstream contact : Matthew Weatherford 
 * URL  : https://github.com/WinFF/winff
 * License  : GFDL-1.3+, GPL-2+, GPL-3+
 * Vcs  : https://salsa.debian.org/pascal-team/winff
   Section  : video

The source builds the following binary packages:

  winff - graphical video and audio batch converter using ffmpeg or avconv
  winff-qt - Qt variant of winff
  winff-data - winff data files
  winff-doc - winff documentation

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


  https://mentors.debian.net/package/winff/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/winff/winff_1.6.4+dfsg-1.dsc


Changes since the last upload:

 winff (1.6.4+dfsg-1) unstable; urgency=medium
 .
   * Use faketime for building the pdfs (reproducible build)
   * Add escapes for ';', '&' in file names (Closes: #1068471)
   * Add detox to suggests
   * Make the documentation a recommends instead of suggests
   * Update standards version to 4.7.0, no changes needed.

Regards,
--
  Peter Blackman

Bug#1069286: bookworm-pu: package dcmtk/3.6.7-9~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Andreas Tille 

[ Reason ]
postrm purge may fail on removing an obsolete directory due to usage of
rm -f without -r

[ Impact ]
Users need to manually clean up cruft in order to purge the package.

[ Tests ]
Local piuparts tests of the affetced upgrade path.

[ Risks ]
Low. Trivial fix.

[ 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 ]
+dcmtk (3.6.7-9~deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Fri, 19 Apr 2024 13:06:33 +0200
+
+dcmtk (3.6.7-9) unstable; urgency=medium
+
+  * Team upload.
+  * Fix postrm
+Closes: #1038776
+
+ -- Andreas Tille   Thu, 22 Jun 2023 09:53:48 +0200

[ Other info ]
This is a rebuild of the package from testing with no further changes.
The fixed package has already been uploaded.

Andreas
diff --git a/debian/changelog b/debian/changelog
index 07333ee..ef6b5c9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+dcmtk (3.6.7-9~deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Fri, 19 Apr 2024 13:06:33 +0200
+
+dcmtk (3.6.7-9) unstable; urgency=medium
+
+  * Team upload.
+  * Fix postrm
+Closes: #1038776
+
+ -- Andreas Tille   Thu, 22 Jun 2023 09:53:48 +0200
+
 dcmtk (3.6.7-8) unstable; urgency=medium
 
   * d/patches: Fix CVE-2022-43272. Closes: #1027165
diff --git a/debian/dcmtk.postrm b/debian/dcmtk.postrm
index 98e717c..b8efc7e 100644
--- a/debian/dcmtk.postrm
+++ b/debian/dcmtk.postrm
@@ -15,7 +15,7 @@ if [ "$1" = "purge" ] ; then
fi
 
if [ -d /var/lib/dcmtk/db/STORESCP ]; then
-  rm -f /var/lib/dcmtk/db/STORESCP
+  rm -rf /var/lib/dcmtk/db/STORESCP
fi
 fi
 

Bug#1069275: apt: random display of the "Summary:" line

[Julian Andres Klode]

On Fri, Apr 19, 2024 at 10:06:31AM +0200, Antonio wrote:
> Package: apt
> Version: 2.9.1
> Severity: minor
> X-Debbugs-Cc: antde...@gmail.com
> 
> Dear Maintainer,
> I report a minor bug on apt that I sometimes get by running the commands
> below
> in sequence.
> 
> Note that in the last commands the "Summary:" line is not displayed whereas
> previously, with the same commands, it was displayed.
> 
> I tried this sequence as root; as a user I see that the word "Summary" never
> appears.
> 
> Seems to be a random problem.

Thank you for your bug report,

looking at your output, everything seems to be in order:

All your apt(8) executions use the apt(8) modern interface,
and all your apt-get(8) executions use the classic interface
- as they should for backwards-compatibility.

Is it possible your muscle memory is playing tricks on you, making
you type sudo apt-get whereas you use apt as a user?

But maybe I missed it, so do double check.

Have a nice day!

> 
> -- SEQUENCE --
> 
> $ apt autoremove
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ apt autoremove --purge
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ sudo apt autoremove --purge
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ (sudo apt autoremove --purge)
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0


These are all apt(8) with the modern interface.

> 
> $ gawk '{print}'< <(sudo apt-get autoremove; sudo apt-get clean; sudo
> apt-get
> autoclean; sudo apt-get -f install; sudo apt-get check)
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...

These are all apt-get(8) with the classic interface.

> 
> $ apt autoremove
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ apt autoremove --purge
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ (sudo apt autoremove --purge)
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

These are all apt(8) and all have the summary line.

> 
> $ sudo apt-get autoremove; sudo apt-get clean; sudo apt-get autoclean; sudo
> apt-get -f install; sudo apt-get check
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove --purge
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove --purge
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ apt-get autoremove
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ apt-get autoremove --purge
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

These are all apt-get(8) which uses the classic interface.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1069163: closed by Debian FTP Masters (reply to Patrick Franz ) (Bug#1069163: fixed in libkf5ksieve 4:22.12.3-2)

[Jonas Schäfer]

Hi there,

With a test build provided by Patrick, I was able to confirm that this 
fixes the issue on my system.

Thank you for the swift response!

kind regards,
-- 
Jonas Schäfer
Team Lead Cloud Infrastructure Development

Cloud Technologies GmbH
Königsbrücker Straße 96 | 01099 Dresden
+49 351 479 367 37
jonas.schae...@cloudandheat.com | www.cloudandheat.com

Green, Open, Efficient.
Your Cloud Service and Cloud Technology Provider from Dresden.
https://www.cloudandheat.com/

Commercial Register: District Court Dresden
Register Number: HRB 30549
VAT ID No.: DE281093504
Managing Director: Nicolas Röhrs
Authorized signatory: Dr. Marius Feldmann


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

Bug#1053266: python3-h5sparse incomplete Depends: python3-h5py-serial

[Andreas Beckmann]

Control: tag -1 sid trixie

On Sat, 30 Sep 2023 12:34:07 +0200 Drew Parsons  wrote:

Package: python3-h5sparse
Version: 0.1.0-6


doing 'import h5sparse' with this package version installed in bookworm
works fine without python3-h5py while it fails in sid without python3-h5py:


import h5sparse

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/h5sparse/__init__.py", line 2, in 

from .h5sparse import Group, File, Dataset  # noqa: F401
^^
  File "/usr/lib/python3/dist-packages/h5sparse/h5sparse.py", line 29, in 

class Group(h5py.Group):
^^
AttributeError: module 'h5py' has no attribute 'Group'


Andreas

Bug#1069285: trixie-pu: package flatpak/1.14.6-1~deb13u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: trixie
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: flat...@packages.debian.org
Control: affects -1 + src:flatpak

[ Reason ]
Fix CVE-2024-32462, a sandbox escape vulnerability, without having to
wait for the whole 64-bit time_t transition.

[ Impact ]
If not fixed, malicious or compromised Flatpak apps can execute arbitrary
code on the host system. (Severity: grave)

The new upstream release also fixes one high-visibility non-security bug:
after some infrastructure changes on Flathub, the flatpak(1) CLI currently
mis-displays apps' developer names as though they were the name of the app,
for example showing org.chromium.Chromium as "The Chromium Authors" instead
of the correct "Chromium Web Browser". The proposed version corrects this.
(Severity: important)

[ Tests ]
Flatpak has a rather large test suite, which still passes. Unfortunately,
most tests have to be skipped when running under schroot or lxc because
those frameworks don't allow creating a nested user namespace, but I do
run the autopkgtest suite under autopkgtest-virt-qemu before uploading.

There is new automated test coverage for CVE-2024-32462 and for the
mis-display of app names.

I'll do a smoke-test on a trixie GNOME VM (install an app, run an app,
and verify that CVE-2024-32462 is fixed) before uploading.

[ Risks ]
Low risk, targeted changes only.

[ 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 testing
  [x] the issue is verified as fixed in unstable

[ Changes ]
Lightly filtered debdiff attached.

* app/flatpak-builtins-build.c,
  common/flatpak-run.c:
  Fix CVE-2024-32462

* common/flatpak-appdata.c:
  Fix the developer name bug described above

* common/flatpak-version-macros.h,
  configure,
  configure.ac,
  NEWS,
  tests/package_version.txt:
  New upstream version

* debian/control:
  Change real|transitional dependencies to real package name only

* doc/reference/html/*.html:
  Regenerated for the new upstream release (and re-regenerated during build)
  Filtered from debdiff

* ltmain.sh:
  The new upstream release was generated on Debian 12 rather than on
  testing/unstable (normally I would filter this out of the debdiff,
  but I'm being extra-vigilant right now after the discovery of the
  xz backdoor). This file is deleted and re-created during build anyway.

* po/flatpak.pot,
  po/*.po:
  Regenerated for the new upstream release (different line numbering)
  Filtered from debdiff

* tests/make-test-app.sh,
  tests/test-info.sh:
  Regression test for the developer name bug

* tests/test-run.sh:
  Regression test for CVE-2024-32462
Filtered: filterdiff -p1 -x'po/*.po' -x'po/*.pot' -x'doc/reference/html/*.html'

diffstat for flatpak-1.14.5 flatpak-1.14.6

 NEWS   |   15 
 app/flatpak-builtins-build.c   |3 
 common/flatpak-appdata.c   |   13 
 common/flatpak-dir.c   |1 
 common/flatpak-run.c   |5 
 common/flatpak-version-macros.h|2 
 configure  |   26 
 configure.ac   |2 
 debian/changelog   |   19 
 debian/control |4 
 doc/reference/html/FlatpakBundleRef.html   |   44 
 doc/reference/html/FlatpakInstallation.html|  706 +-
 doc/reference/html/FlatpakInstalledRef.html|   88 -
 doc/reference/html/FlatpakInstance.html|   22 
 doc/reference/html/FlatpakRef.html |8 
 doc/reference/html/FlatpakRelatedRef.html  |   44 
 doc/reference/html/FlatpakRemote.html  |   62 
 doc/reference/html/FlatpakRemoteRef.html   |   38 
 doc/reference/html/FlatpakTransaction.html |  310 ++--
 doc/reference/html/FlatpakTransactionOperation.html|   28 
 doc/reference/html/FlatpakTransactionProgress.html |   22 
 doc/reference/html/flatpak-Error-codes.html|2 
 doc/reference/html/flatpak-Version-information.html|2 
 doc/reference/html/gdbus-org.freedesktop.Flatpak.Authenticator.html|   22 
 doc/reference/html/gdbus-org.freedesktop.Flatpak.AuthenticatorRequest.html |4 
 

Bug#1069279: loading /etc/profile.d scripts should enforce consistent ordering

[Santiago Vila]

I saw in #604918 that /etc/profile is deliberately not treated as a
conffile. Is there any way to get the new version installed on package
upgrade, other than an external configuration management system such
as Ansible?


The way /etc/profile is handled changed slightly in version 6.10,
one year and a half after the bug you mention.

Now, if you did not modify your /etc/profile file, it will be updated to the
new default. If you are curious about how it's done, see 
update_to_current_default()
function in the postinst.

If you did modify it, ansible would be appropriate.

Thanks.

Bug#1069279: loading /etc/profile.d scripts should enforce consistent ordering

[Dave Holland]

On Fri, 19 Apr 2024 at 10:51, Santiago Vila  wrote:
> Thanks for the report. Is this not already addressed by the proposed
> patch in Bug #885414, in which we explicitly use run-parts --list
> to get the files to be processed?

Hi,

Thanks for the quick reply. I had only read the first few entries in
#885414 and assumed from the dates that it wasn't making progress. Now
I read to the end, I see it is active, and that using run-parts does
seem like it will cover this. Great!

I saw in #604918 that /etc/profile is deliberately not treated as a
conffile. Is there any way to get the new version installed on package
upgrade, other than an external configuration management system such
as Ansible?

Cheers,
Dave

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

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2024-04-19 at 00:01 +0100, Peter Green wrote:
> Thanks, upstream has now accepted a patch that takes a slightly different
> approach to fixing the issue.
> 
> https://github.com/canonical/lightdm/issues/352

Yes I saw. That's why I think this should have been reported and talked
directly with upstream, before the NMU, but eh...
> 
> Could we get this uploaded to sid, so that the lightweight desktops
> are installable on armel/armhf again?

Yes I'll look into it.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYiRuIACgkQ3rYcyPpX
RFsQkQgA1h8bIbWp0Sj6VqgcdG/dkwKEQ6Xrcuh6gpL7Gy2BiT2d1tY4HFN94bhG
FJVz9E9QOqlZt2Mo7JQ6EBYyvcTspO0T09ZU/22VjA2NdP0eSRHTiyiFXq4hyoYf
OBnPpKTxq0Wp9L7Tefta7uNPIBX+lsVlw9cdwv6PIEy6jlF3xjX+B8FoK/K/fIeY
FuQh5qOw/k/nnPAM4pHxYGAfRw+BNBEnI3ADFCCWDvpQSgZ9uJ9UB3wnEo50aXub
dsNsXAZx3UIX2CfDBs1jXsPc/B37csOr9sJIqDn1xJKaT/Q6Yk1A/LV8uTa38wGh
MykmdfDqWLT0nK4atbVH5fxjkTNdDg==
=Fysh
-END PGP SIGNATURE-