Bug#1060190: src:pyflakes: fails to migrate to testing for too long: unresolved RC issue

[Paul Gevers]

Source: pyflakes
Version: 2.5.0-1
Severity: serious
Control: close -1 3.1.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1058335

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)

[Paul Gevers]

Package: lazarus-src-3.0
Version: 3.0+dfsg1-5
Severity: normal

Hi,

I just did my daily update of my trixie system and spotted the error 
below. The fallback works, but that "error" is highlighted in red, so it 
catches the eye.


Paul

Unpacking lazarus-src-3.0 (3.0+dfsg1-5) over (3.0+dfsg1-3) ...
Removing 'diversion of 
/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk to 
/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk.orig by 
lazarus-src-3.0'
dpkg-divert: error: rename involves overwriting 
'/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk' with
  different file 
'/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk.orig', 
not allowed
dpkg: warning: old lazarus-src-3.0 package post-removal script 
subprocess returned error exit status 2

dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK




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

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

lazarus-src-3.0 depends on no packages.

lazarus-src-3.0 recommends no packages.

Versions of packages lazarus-src-3.0 suggests:
iu  lazarus-ide-3.0  3.0+dfsg1-5

-- no debconf information


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Hi Wouter,

On 06-01-2024 20:51, Wouter Verhelst wrote:

The Release Team considers packages that are out-of-sync between testing and
unstable for more than 30 days as having a Release Critical bug in testing
[1]. Your package src:extrepo has been trying to migrate for 33 days [2].


This should have been fixed with the recent upload of extrepo-offline-data?


Doesn't that mean that there is a versioned relation or a Breaks needed 
somewhere? Or is this a test problem only? I note that extrepo-data 
passed in testing which passed (so with the old extrepo, so no versioned 
Breaks needed), so I *guess* that indeed this is a test only problem.


With versioned breaks or versioned dependencies, britney2 will schedule 
combined tests as it knows that things migrate together (somewhat) 
anyways. I don't think so this time, but autopkgtest catches a lot of 
missing versioned relations this way.



If that didn't happen yet, can you try to trigger another autopkgtest run?


Mostly depending on the answer above. Failing migration tests are 
rescheduled after a day, so if we don't do anything, once extrepo-data 
migrates (it's not blocked by anything now), I expect things to be fine.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060188: transition: flatbuffers

[M. Zhou]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: flatbuff...@packages.debian.org
Control: affects -1 + src:flatbuffers

The flatbuffers version in unstable is rather old. I'd like to start
the transition. All reverse dependencies can be built on amd64.

Note, the package list in transition tracker is not complete.
I get the list by

   for each binary package from src:flatbuffers:
  build-rdeps package

The following list should be the complete version:

armnn [OK]
buildbot [OK]
facet-analyser [not in testing; FTBFS already]
gnome-keysign [OK]
kodi [OK]
libsigmf [OK]
magic-wormhole [OK]
magic-wormhole-mailbox-server [FTBFS already; irrelevant, #1058173]
paraview [OK]
python-autobahn [OK]
python-daphne [OK]
python-django-channels [OK]
pytorch [OK] [1]
starlette [OK]
vast [not in testing; FTBFS already]
zaqar [OK]
zlmdb [OK]

[1] pytorch is undergoing uncoordinated transition, because pytorch is
the only reverse dependency of libdnnl2/libdnnl3 and both maintained by me.
The pytorch/experimental (awaits in NEW) can be successfully built against
new flatbuffers.

I don't know how to write the ben file because not all of them
depend on libflatbuffers2 .



Ben file:

title = "flatbuffers";
is_affected = .depends ~ "libflatbuffers2" | .depends ~ "libflatbuffers23.5.26";
is_good = .depends ~ "libflatbuffers23.5.26";
is_bad = .depends ~ "libflatbuffers2";
Thank you for using reportbug

Bug#1058779: libk5crypto3 fails to install via apt (dpkg error) triggers ci file contains unknown directive 'set'

[Andreas Metzler]

On 2023-12-16 Fernando Toledo  wrote:
> Package: libk5crypto3
> Version: 1.18.3-6+deb11u3
> Severity: important

> Dear Maintainer,

> running apt upgrade on debian 11

> root@scarlet:~# LANG=C apt upgrade
[...]
> dpkg: error processing archive 
> /var/cache/apt/archives/libk5crypto3_1.18.3-6+deb11u4_amd64.deb (--unpack):
>  triggers ci file contains unknown directive 'set'
> Errors were encountered while processing:
>  /var/cache/apt/archives/libk5crypto3_1.18.3-6+deb11u4_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
[...]

Good morning,

could you show the contents (and md5sum) of
/var/lib/dpkg/info/libk5crypto3.triggers? Do any of unpacked trigger
files on your system contain the string "set" (grep -l set
/var/lib/dpkg/info/*triggers)?

cu Andreas


signature.asc
Description: PGP signature

Bug#1057783: libc6:amd64.postinst may lack of response for a long time.

[Hae-woo Park]

FYI, I experienced the same issue in my WSL systems in two
different laptops running Trixie.

I am afraid if this would happen for other people's WSL systems.

Bug#999989: poco 1.1 uses PCRE3, Mumble 1.5 depends on poco

[Chris Knadle]

On 1/5/24 07:30, Jochen Sprickerhof wrote:

* Chris Knadle  [2024-01-02 16:53]:
The way to orphan a package is to do an upload and setting the 
maintainer to be . Until that's done the 
package ends up in maintainership limbo. See the bottom of Policy 
3.3, and Developer's Reference section 5.9.4.


Agreed but I think that is something for the Maintainer: to do, who 
seems to be active in Debian, otherwise.


Normally, yes. But it also doesn't do to have a maintainer that doesn't 
communicate concerning a package; that's the #1 responsibility a package 
maintainer has.


The situation with Poco clearly fits the criteria for when "salvaging" a 
package is needed:


   https://wiki.debian.org/PackageSalvaging

The RC bug for Poco is holding back the following list of source 
packages from migrating: clickhouse, clamfs, gm-assistant, gpsshogi, mumble.



Feel free to ask if you have questions regarding maintaining a library.


The main thing I'd like to understand is how to do coordinate the 
transition (i.e. the release) with the Release Team. I found some hints 
about that here:


https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#lib-trans

--

Chris Knadle
chris.kna...@coredump.us

Bug#1059807: supysonic: does not write log file

[Louis-Philippe Véronneau]

Hi,

How are you running supysonic? If you run it at as a WSGI app, it would 
be the job of your webserver to log the error?


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

On Mon, 01 Jan 2024 19:24:36 +0100 Axel  wrote:

Package: supysonic
Version: 0.7.2+ds-2
Severity: normal
X-Debbugs-Cc: a...@users.sourceforge.net

Dear Maintainer,

some audio files cause the script to die prematurely, probably while attempting 
to
transcode the audio. Unfortunately no log entries are created whatsoever. If 
the log file
cannot be created, an error message is produced, but even the debug setting 
does not
result in any entries.

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

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

Versions of packages supysonic depends on:
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-3
ii  libjs-bootstrap 3.4.1+dfsg-3
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-sphinxdoc 5.3.0-4
ii  python3 3.11.2-1+b1
ii  python3-click   8.1.3-2
ii  python3-flask   2.2.2-3
ii  python3-lxml4.9.2-1+b1
ii  python3-mediafile   0.11.0-1
ii  python3-pil 9.4.0-1.1+b1
ii  python3-pony0.7.16+ds-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-watchdog2.2.1-1
ii  python3-zipstream-ng1.4.0-1

Versions of packages supysonic recommends:
ii  flac 1.4.2+ds-2
ii  lame 3.100-6
ii  libapache2-mod-wsgi-py3  4.9.4-1+b2

Versions of packages supysonic suggests:
ii  python3-psycopg2  2.9.5-1+b1

-- no debconf information




OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Steve Langasek]

On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> Hi,

> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the 
> > > > default
> > > > flags
> > [...]
> > What about the suggestion to not push changes to experimental for packages
> > that already have new versions in experimental, and do the binary package
> > renames in unstable instead, leaving the package in experimental alone?

> How does that play together with the needed dpkg only in experimental?

> You can't build stuff for unstable involving experimental packages (except
> manually with binary upload, which would block testing migration)

The ordering here would be:

- dpkg will be uploaded to experimental with 64-bit time_t in the default
  flags

- the source packages which need an ABI change
  ("source-packages"+"lfs-and-depends-time_t") and do not already have
  versions in experimental, will have sourceful NMUs to experimental with
  the new binary package names in order to clear binary NEW, in coordination

- once these packages have all cleared binary NEW, the new dpkg defaults
  will be uploaded to unstable

- source packages which need an ABI change but already have versions in
  experimental will be uploaded to unstable, with binaries, to clear binary
  NEW

- sourceful NMUs of all the libraries will be reuploaded to unstable
  (without binaries, so that they can be promoted to testing without
  additional uploads).

- perl will also get a sourceful upload, to manually handle 'perlapi'
  Provides.

- binNMUs will be scheduled for all of the reverse-dependencies.


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1060022: acl FTBFS with newer hardening flags

[Guillem Jover]

Hi!

On Thu, 2024-01-04 at 14:04:50 -0800, Steve Langasek wrote:
> Package: acl
> Version: 2.3.1-4
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu noble ubuntu-patch

> This traces back to a use of a 0-length array in a struct as a flexible
> variable-length array, which confuses the compiler's + glibc's string
> hardening and results in a false-positive detection of a buffer overflow.
> 
> While this false-positive could be avoided by downgrading from
> _FORTIFY_SOURCE=3 back to _FORTIFY_SOURCE=2, that would also weaken our
> ability to detect actual bugs, so instead I've prepared the attached patch
> to make the flexible array implementation compatible with the gcc hardening
> implementation, as described at
> .

Thanks for the analysis and patch, I can confirm the issue and the
fix. I've queued this for my next upload to unstable, which I'll be
doing after a quick one into experimental.

Regards,
Guillem

Bug#1060156: acl: move files to /usr for DEP17

[Guillem Jover]

Hi!

On Sat, 2024-01-06 at 15:04:47 +, ca...@allfreemail.net wrote:
> Source: acl
> Followup-For: Bug #1060156
> 
> better patch attached

Ah, thanks for the patch. I had already prepared a patch for this the
other day, but forgot to push to git, as I was meaning to upload right
away, but ended getting pulled in by something else.

(I'm going to be using instead
https://git.hadrons.org/cgit/debian/pkgs/acl.git/log/?h=pu/canonical-paths)

Thanks,
Guillem

Bug#1060157: librust-asn1-dev: please update to a more recent version

[Peter Michael Green]

a more recent version of librust-asn1-dev (>= 0.15) is needed
to be able to update to python3-cryptography (>= 0.41) which
in turn is required by some other package.

I've uploaded the new versions of rust-asn1 and rust-asn1-derive
to experimental,  python-cryptography seems to be the only reverse
dependency so you should be ok to re-upload them to
unstable at the same time as you upload the corresponding
version of python-cryptography.

Bug#928542: ITA: python-fswrap -- unified object oriented interface to file system objects

[Yogeswaran Umasankar]

Control: retitle 928542 ITA: python-fswrap -- unified object oriented interface 
to file system objects
thanks.

Owner: Yogeswaran Umasankar 

Hi,
I would like to adopt this package, and maintain it under Debian Python Team.
Cheers!

Bug#1060187: src:peewee: not all tests are run when building and in the autopkgtest (only 5 out of many)

[Louis-Philippe Véronneau]

Package: src:peewee
Severity: important
Version: 3.17.0+dfsg-1

Dear maintainers,

It seems peewee only runs 5 tests (out of a bunch) when building and in 
the autopkgtest:


=
platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.3.0
rootdir: /tmp/autopkgtest.VGaWKb/autopkgtest_tmp/build
collected 5 items

tests/test_utils.py . 
[100%]

=

This does not seem like a new problem (it's been the case since at least 
Debian 10), but isn't great.


I haven't investigated why this happens, but I see a `runtests.py` 
script in the upstream root directory. This is probably the right way to 
run tests?


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1035312: minetest: New upstream version available (5.7.0)

[Jeremy Shannon]

On Thu, 7 Dec 2023 07:02:37 +0100 Tobias Frost  wrote:
> I guess that complicates things. The change [1] reads to me like it is
> no longer possible (at the moment) to play the game without the need to
> download something.

Not true, you don't need to install anything to play on a server. The
engine is literally all you need. Pick a server, register and log in,
and you're playing!

 If you want to play single player, you do need to install a game, but
then the question is: which one? There's no reason Minetest Game should
be treated as first among equals. It's not fair to all the other games
and the people (like me) who've worked so hard on them to push MTG on
new players as if it were the default.

>This would be a regression IMHO, as well for the
> user experience as well as for user privacy.

 RE user experience: By itself, Minetest Game is a bad game, it's
not meant to be played on its own, it's designed to be a base for
adding mods, and if you don't have a bunch of mods installed, it gives
the false impression that Minetest is nothing more than an empty,
unfinished Minecraft clone.

 As for privacy, it's true that the community-run Contentdb collects
anonymous usage statistics if you download through the client, but you
can always use a browser like Tor to download games.

Bug#1060186: bookworm-pu: libde265/1.0.11-1+deb12u2

[Thorsten Alteholz]

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


The attached debdiff for libde265 fixes CVE-2023-49468, CVE-2023-49467 and
CVE-2023-49465 in Bookworm. All CVEs are marked as no-dsa by the security
team.

The fix was already uploaded to Stretch and nobody complained up to now.

  Thorsten
diff -Nru libde265-1.0.11/debian/changelog libde265-1.0.11/debian/changelog
--- libde265-1.0.11/debian/changelog2023-11-26 13:03:02.0 +0100
+++ libde265-1.0.11/debian/changelog2023-12-29 23:03:02.0 +0100
@@ -1,3 +1,16 @@
+libde265 (1.0.11-1+deb12u2) bookworm; urgency=medium
+
+  * Non-maintainer upload by the LTS Team.
+(Closes: #1059275)
+  * CVE-2023-49465
+heap-buffer-overflow in derive_spatial_luma_vector_prediction()
+  * CVE-2023-49467
+heap-buffer-overflow in derive_combined_bipredictive_merging_candidates()
+  * CVE-2023-49468
+global buffer overflow in read_coding_unit()
+
+ -- Thorsten Alteholz   Fri, 29 Dec 2023 23:03:02 +0100
+
 libde265 (1.0.11-1+deb12u1) bookworm; urgency=medium
 
   * Non-maintainer upload by the LTS Team.
diff -Nru libde265-1.0.11/debian/patches/CVE-2023-49465.patch 
libde265-1.0.11/debian/patches/CVE-2023-49465.patch
--- libde265-1.0.11/debian/patches/CVE-2023-49465.patch 1970-01-01 
01:00:00.0 +0100
+++ libde265-1.0.11/debian/patches/CVE-2023-49465.patch 2023-12-26 
00:54:10.0 +0100
@@ -0,0 +1,26 @@
+commit 1475c7d2f0a6dc35c27e18abc4db9679bfd32568
+Author: Dirk Farin 
+Date:   Thu Nov 23 19:43:55 2023 +0100
+
+possible fix for #435
+
+Index: libde265-1.0.11/libde265/motion.cc
+===
+--- libde265-1.0.11.orig/libde265/motion.cc2023-12-26 00:54:05.172996659 
+0100
 libde265-1.0.11/libde265/motion.cc 2023-12-26 00:54:05.168996661 +0100
+@@ -1859,7 +1859,14 @@
+   logmvcand(vi);
+ 
+   const de265_image* imgX = NULL;
+-  if (vi.predFlag[X]) imgX = ctx->get_image(shdr->RefPicList[X][ 
vi.refIdx[X] ]);
++  if (vi.predFlag[X]) {
++if (vi.refIdx[X] < 0 || vi.refIdx[X] >= MAX_NUM_REF_PICS) {
++  return;
++}
++
++imgX = ctx->get_image(shdr->RefPicList[X][ vi.refIdx[X] ]);
++  }
++
+   const de265_image* imgY = NULL;
+   if (vi.predFlag[Y]) imgY = ctx->get_image(shdr->RefPicList[Y][ 
vi.refIdx[Y] ]);
+ 
diff -Nru libde265-1.0.11/debian/patches/CVE-2023-49467.patch 
libde265-1.0.11/debian/patches/CVE-2023-49467.patch
--- libde265-1.0.11/debian/patches/CVE-2023-49467.patch 1970-01-01 
01:00:00.0 +0100
+++ libde265-1.0.11/debian/patches/CVE-2023-49467.patch 2023-12-26 
00:53:43.0 +0100
@@ -0,0 +1,22 @@
+commit 7e4faf254bbd2e52b0f216cb987573a2cce97b54
+Author: Dirk Farin 
+Date:   Thu Nov 23 19:38:34 2023 +0100
+
+prevent endless loop for #434 input
+
+diff --git a/libde265/slice.cc b/libde265/slice.cc
+index 435123dc..3a8a8de1 100644
+--- a/libde265/slice.cc
 b/libde265/slice.cc
+@@ -2582,6 +2582,11 @@ static int decode_rqt_root_cbf(thread_context* tctx)
+ 
+ static int decode_ref_idx_lX(thread_context* tctx, int numRefIdxLXActive)
+ {
++  // prevent endless loop when 'numRefIdxLXActive' is invalid
++  if (numRefIdxLXActive <= 1) {
++return 0;
++  }
++
+   logtrace(LogSlice,"# ref_idx_lX\n");
+ 
+   int cMax = numRefIdxLXActive-1;
diff -Nru libde265-1.0.11/debian/patches/CVE-2023-49468.patch 
libde265-1.0.11/debian/patches/CVE-2023-49468.patch
--- libde265-1.0.11/debian/patches/CVE-2023-49468.patch 1970-01-01 
01:00:00.0 +0100
+++ libde265-1.0.11/debian/patches/CVE-2023-49468.patch 2023-12-26 
00:53:43.0 +0100
@@ -0,0 +1,26 @@
+commit 3e822a3ccf88df1380b165d6ce5a00494a27ceeb
+Author: Dirk Farin 
+Date:   Thu Nov 23 19:11:34 2023 +0100
+
+fix #432 (undefined IPM)
+
+diff --git a/libde265/image.h b/libde265/image.h
+index 0b536054..0a0c0e32 100644
+--- a/libde265/image.h
 b/libde265/image.h
+@@ -624,7 +624,14 @@ public:
+ 
+   enum IntraPredMode get_IntraPredMode(int x,int y) const
+   {
+-return (enum IntraPredMode)intraPredMode.get(x,y);
++uint8_t ipm = intraPredMode.get(x,y);
++
++// sanitize values if IPM is uninitialized (because of earlier read error)
++if (ipm > 34) {
++  ipm = 0;
++}
++
++return static_cast(ipm);
+   }
+ 
+   enum IntraPredMode get_IntraPredMode_atIndex(int idx) const
diff -Nru libde265-1.0.11/debian/patches/series 
libde265-1.0.11/debian/patches/series
--- libde265-1.0.11/debian/patches/series   2023-11-21 19:08:07.0 
+0100
+++ libde265-1.0.11/debian/patches/series   2023-12-26 00:54:03.0 
+0100
@@ -9,3 +9,6 @@
 CVE-2023-43887.patch
 CVE-2023-47471.patch
 
+CVE-2023-49465.patch
+CVE-2023-49467.patch
+CVE-2023-49468.patch

Bug#1060185: bullseye-pu: libde265/1.0.11-0+deb11u3

[Thorsten Alteholz]

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


The attached debdiff for libde265 fixes CVE-2023-49468, CVE-2023-49467 and 
CVE-2023-49465 in Bullseye. All CVEs are marked as no-dsa by the security 
team.


The fix was already uploaded to Stretch and nobody complained up to now.

  Thorsten
diff -Nru libde265-1.0.11/debian/changelog libde265-1.0.11/debian/changelog
--- libde265-1.0.11/debian/changelog2023-11-26 13:03:02.0 +0100
+++ libde265-1.0.11/debian/changelog2023-12-29 23:03:02.0 +0100
@@ -1,3 +1,16 @@
+libde265 (1.0.11-0+deb11u3) bullseye; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+(Closes: #1059275)
+  * CVE-2023-49465
+heap-buffer-overflow in derive_spatial_luma_vector_prediction()
+  * CVE-2023-49467
+heap-buffer-overflow in derive_combined_bipredictive_merging_candidates()
+  * CVE-2023-49468
+global buffer overflow in read_coding_unit()
+
+ -- Thorsten Alteholz   Fri, 29 Dec 2023 23:03:02 +0100
+
 libde265 (1.0.11-0+deb11u2) bullseye; urgency=high
 
   * Non-maintainer upload by the LTS Team.
diff -Nru libde265-1.0.11/debian/patches/CVE-2023-49465.patch 
libde265-1.0.11/debian/patches/CVE-2023-49465.patch
--- libde265-1.0.11/debian/patches/CVE-2023-49465.patch 1970-01-01 
01:00:00.0 +0100
+++ libde265-1.0.11/debian/patches/CVE-2023-49465.patch 2023-12-29 
23:03:02.0 +0100
@@ -0,0 +1,26 @@
+commit 1475c7d2f0a6dc35c27e18abc4db9679bfd32568
+Author: Dirk Farin 
+Date:   Thu Nov 23 19:43:55 2023 +0100
+
+possible fix for #435
+
+Index: libde265-1.0.11/libde265/motion.cc
+===
+--- libde265-1.0.11.orig/libde265/motion.cc2023-12-26 00:54:05.172996659 
+0100
 libde265-1.0.11/libde265/motion.cc 2023-12-26 00:54:05.168996661 +0100
+@@ -1859,7 +1859,14 @@
+   logmvcand(vi);
+ 
+   const de265_image* imgX = NULL;
+-  if (vi.predFlag[X]) imgX = ctx->get_image(shdr->RefPicList[X][ 
vi.refIdx[X] ]);
++  if (vi.predFlag[X]) {
++if (vi.refIdx[X] < 0 || vi.refIdx[X] >= MAX_NUM_REF_PICS) {
++  return;
++}
++
++imgX = ctx->get_image(shdr->RefPicList[X][ vi.refIdx[X] ]);
++  }
++
+   const de265_image* imgY = NULL;
+   if (vi.predFlag[Y]) imgY = ctx->get_image(shdr->RefPicList[Y][ 
vi.refIdx[Y] ]);
+ 
diff -Nru libde265-1.0.11/debian/patches/CVE-2023-49467.patch 
libde265-1.0.11/debian/patches/CVE-2023-49467.patch
--- libde265-1.0.11/debian/patches/CVE-2023-49467.patch 1970-01-01 
01:00:00.0 +0100
+++ libde265-1.0.11/debian/patches/CVE-2023-49467.patch 2023-12-29 
23:03:02.0 +0100
@@ -0,0 +1,22 @@
+commit 7e4faf254bbd2e52b0f216cb987573a2cce97b54
+Author: Dirk Farin 
+Date:   Thu Nov 23 19:38:34 2023 +0100
+
+prevent endless loop for #434 input
+
+diff --git a/libde265/slice.cc b/libde265/slice.cc
+index 435123dc..3a8a8de1 100644
+--- a/libde265/slice.cc
 b/libde265/slice.cc
+@@ -2582,6 +2582,11 @@ static int decode_rqt_root_cbf(thread_context* tctx)
+ 
+ static int decode_ref_idx_lX(thread_context* tctx, int numRefIdxLXActive)
+ {
++  // prevent endless loop when 'numRefIdxLXActive' is invalid
++  if (numRefIdxLXActive <= 1) {
++return 0;
++  }
++
+   logtrace(LogSlice,"# ref_idx_lX\n");
+ 
+   int cMax = numRefIdxLXActive-1;
diff -Nru libde265-1.0.11/debian/patches/CVE-2023-49468.patch 
libde265-1.0.11/debian/patches/CVE-2023-49468.patch
--- libde265-1.0.11/debian/patches/CVE-2023-49468.patch 1970-01-01 
01:00:00.0 +0100
+++ libde265-1.0.11/debian/patches/CVE-2023-49468.patch 2023-12-29 
23:03:02.0 +0100
@@ -0,0 +1,26 @@
+commit 3e822a3ccf88df1380b165d6ce5a00494a27ceeb
+Author: Dirk Farin 
+Date:   Thu Nov 23 19:11:34 2023 +0100
+
+fix #432 (undefined IPM)
+
+diff --git a/libde265/image.h b/libde265/image.h
+index 0b536054..0a0c0e32 100644
+--- a/libde265/image.h
 b/libde265/image.h
+@@ -624,7 +624,14 @@ public:
+ 
+   enum IntraPredMode get_IntraPredMode(int x,int y) const
+   {
+-return (enum IntraPredMode)intraPredMode.get(x,y);
++uint8_t ipm = intraPredMode.get(x,y);
++
++// sanitize values if IPM is uninitialized (because of earlier read error)
++if (ipm > 34) {
++  ipm = 0;
++}
++
++return static_cast(ipm);
+   }
+ 
+   enum IntraPredMode get_IntraPredMode_atIndex(int idx) const
diff -Nru libde265-1.0.11/debian/patches/series 
libde265-1.0.11/debian/patches/series
--- libde265-1.0.11/debian/patches/series   2023-11-21 19:01:52.0 
+0100
+++ libde265-1.0.11/debian/patches/series   2023-12-29 23:03:02.0 
+0100
@@ -8,3 +8,7 @@
 CVE-2023-27103.patch
 CVE-2023-43887.patch
 CVE-2023-47471.patch
+
+CVE-2023-49465.patch
+CVE-2023-49467.patch
+CVE-2023-49468.patch

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Steve Langasek]

On Sat, Jan 06, 2024 at 09:07:15AM +0100, Rene Engelhard wrote:
> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the 
> > > > default
> > > > flags
> > > I  think at that point in time one should know what breaks and whatnot.
> > > Archive rebuild?
> > > (Probably in stages)
> > What kind of breakage are you looking to avoid here?

> build failures/test failures.

> > As mentioned in other points in the thread, regressions as a result of
> > this change should be rare and easy to fix.  I do not think it's a good
> > use of time / CPU power to do test rebuilds for this instead of just
> > landing the transition.

> Here especially LibreOffices bridge code worries me.

> That one is tied to ABI and calling conventions. I don't see time_t
> mentioned there but "just" in the public libraries (sal), but I am not sure
> what making a type bigger will cause.

> (And since already

>  - i386 needs gcc-12 to build since otherwise the test fails

>  - armhf (and other archs like ppc64el and s390x) need Java disabled[1] -
> without any help from any porter to prevent this - I *do* want to avoid
> breakage here.

> If you say you are going to fix eventual breakage (and not ignoring the test
> results!) and if that means fixing asm on all affected archs, then it's OK
> :)

Well, yes; though I hope we would see some help from e.g. arm porters if
there were actually breakage of this nature.  Alternatively, maybe it would
be better to stop shipping libreoffice on 32-bit archs, in that case?  I'm
not sure how usable libreoffice is these days on such archs.
popcon.debian.org doesn't appear to have the granularity to tell us if there
actually *are* users; and with only 615 armhf popcon reports (vs 215,562 on
amd64) we don't exactly have a statistically significant sample there.

> > > > - the source packages which need an ABI change
> > > > ("source-packages"+"lfs-and-depends-time_t" will have sourceful 
> > > > NMUs to
> > > I get that you probably want NMUs for not needing to ping every 
> > > maintainer,
> > > but this is bad.
> > > That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
> > > when tagged end of next week to not have this caught in the transition. 
> > > (see
> > > also below for the comment about new upstream versions in experimental.)
> > What about the suggestion to not push changes to experimental for packages
> > that already have new versions in experimental, and do the binary package
> > renames in unstable instead, leaving the package in experimental alone?

> If at all - *both*. At the same time.

Most of these packages that are staged in experimental are going to be there
because of library transitions... so I think we definitely don't want to be
renaming those binary packages, they should just drop the t64 suffix when
they move to unstable.

> But yes, that could work.

> (In this specific case I an worrying that the transition will take some
> time, and that I am stuck with 7.6.x instead of uploading 24.2 when it is
> released.)

Ok.  I don't think there would be any need for you to wait before uploading
24.2.  It might have to wait for time_t for testing migration, but  I don't think that should really be long.

> > > > experimental with the new binary package names in order to clear 
> > > > binary
> > > > NEW, in coordination

> > > And what about skipped ones?  When will those be tried?

> > What do you mean here by "skipped ones"?

> https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt

> (which incidentially contains libreoffice)

Ah!  These are packages that have been omitted from the analysis because
they've been manually identified as packages that don't have C or
C++-compatible header files related to a shared library, and therefore even
if they do need updated for 64-bit time_t, they are not affected by CPPFLAGS
and are not part of this transition.  (I am not 100% sure this is accurate
for ObjC; in any case ObjC headers are impossible to analyze using
abi-compliance-checker so if ObjC libraries are possibly affected, someone
would have to figure out what to do with them.)

I'm not sure precisely why Adrien found it necessary/useful to add
libreoffice-dev to this exclude list, but I can confirm that it's
reasonable, as this particular package contains only a single header file
with #define's and no function prototypes; so in effect it has been manually
analyzed and determined to be unaffected.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1060184: ITP: python-django-guid -- Identify Django request logs

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team 


* Package name: python-django-guid
  Version : 3.4.1
  Upstream Contact: Jonas Krüger Svensson 
* URL : https://github.com/snok/django-guid
* License : Expat
  Programming Lang: Python
  Description : Identify Django request logs

 This library allows one to attach a unique ID to all log outputs
 for every request, making debugging more simple.
 .
 Django is a high-level Python web development framework.

It will be maintained by python team and is a dependency of awx.

Bug#1056829: peewee: ftbfs with cython 3.0.x

[Louis-Philippe Véronneau]

owner 1056829 Louis-Philippe Véronneau 
thanks

This is apparently fixed in version 3.16.3. I'll try to update the package.

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


On Sun, 26 Nov 2023 10:05:53 + Matthias Klose  wrote:

Package: src:peewee
Version: 3.14.10+dfsg-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: cython3

[This bug is targeted to the upcoming trixie release]

The package fails to build in a test rebuild on at least arm64 with
cython 3.0.5, but succeeds to build with cython 0.29.36.  Please
update the package to build with cython 3.0.5 (available in experimental).

If the package cannot be built with cython 3.0.5, please change the
build dependency from cython3 to cython3-legacy (available now in
unstable).  There is no replacement for cython3-dbg.

Build logs building with cython 3.0.5 can be found at
https://people.debian.org/~stefanor/cython3/cython-3.0.5/

See also https://lists.debian.org/debian-python/2023/11/msg00034.html




OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053359: U-Boot debian/2024.01-rcX: u-boot-starfve

[Vagrant Cascadian]

On 2024-01-06, Heinrich Schuchardt wrote:
> I have built U-Boot from
>
> https://salsa.debian.org/debian/u-boot/-/commit/e182a8eb13eb6d1990a3d79740b71b0cc52f9f5a
> Merge branch 'debian/2024.01-rcX' into debian/latest
>
> and deployed it to these boards:
>
> StarFive VisionFive 2 v1.3B, 4 GiB
> StarFive VisionFive 2 v1.3B, 8 GiB
> StarFive VisionFive 2 v1.2A, 4 GiB
>
> They boot fine via UEFI into Ubuntu.

Thanks for testing!

I plan to include them in an upload shortly... and then it should wait
in ftp-master NEW queue... who knows how long that will take. That's why
I merged the changes and then reverted them, as it is easier to deal
with NEW when the upstream tarball is already present in the official
repository...


> It may be preferable to upgrade the dependency OpenSBI to v1.4 before
> the new U-Boot release.

I debated weather to bump the dependency, as OpenSBI is now v1.4 in
unstable, so it should default to that version going forward...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1059607: linux-image-6.1.0-16-amd64: Steam Deck does not recognize USB keyboard on Bookworm

[Cordell Bloor]

found 1059607 6.5.13-1
found 1059607 6.6.9-1
thanks

On 2024-01-06 06:24, Salvatore Bonaccorso wrote:

And given this commit was backported to 4.19.298, 5.10.200, 6.1.62,
6.5.11 and 6.6.1. Can you confirm the problem is as well present in
the current available 6.5.13-1 and 6.6.9-1?


I can confirm the problem is present in those versions as well.

Sincerely,
Cory Bloor

Bug#1060150: linux-image-6.6.9-amd64: Unable to update to 6.6.9-1 version

[Carlos Suérez]

Hi ,

The full log for that upgrade was:


Start-Date: 2024-01-02 20:30:06
Commandline: apt upgrade
Requested-By: bitseater (1000)
Install: linux-image-6.6.9-amd64:amd64 (6.6.9-1, automatic)
Upgrade: qemu-system-x86:amd64 (1:8.2.0+ds-1, 1:8.2.0+ds-2), 
udev:amd64 (255.2-2, 255.2-3), libexttextcat-2.0-0:amd64 (3.4.6-1, 
3.4.7-1), libmm-glib0:amd64 (1.22.0-1, 1.22.0-2), 
systemd-container:amd64 (255.2-2, 255.2-3), libnss-myhostname:amd64 
(255.2-2, 255.2-3), modemmanager:amd64 (1.22.0-1, 1.22.0-2), 
qemu-system-modules-opengl:amd64 (1:8.2.0+ds-1, 1:8.2.0+ds-2), 
libpam-systemd:amd64 (255.2-2, 255.2-3), sed:amd64 (4.9-1, 4.9-2), 
xxd:amd64 (2:9.0.2116-1, 2:9.0.2189-1), python3-httpx:amd64 (0.23.3-1, 
0.26.0-1), libnorm1:amd64 (1.5.9+dfsg-2, 1.5.9+dfsg-3), 
vim-common:amd64 (2:9.0.2116-1, 2:9.0.2189-1), 
qemu-system-modules-spice:amd64 (1:8.2.0+ds-1, 1:8.2.0+ds-2), 
libsystemd0:amd64 (255.2-2, 255.2-3), libudev-dev:amd64 (255.2-2, 
255.2-3), systemd:amd64 (255.2-2, 255.2-3), libudev1:amd64 (255.2-2, 
255.2-3), qemu-utils:amd64 (1:8.2.0+ds-1, 1:8.2.0+ds-2), 
systemd-dev:amd64 (255.2-2, 255.2-3), libnss-mymachines:amd64 
(255.2-2, 255.2-3), linux-image-amd64:amd64 (6.6.8-1, 6.6.9-1), 
vim-tiny:amd64 (2:9.0.2116-1, 2:9.0.2189-1), qemu-system-misc:amd64 
(1:8.2.0+ds-1, 1:8.2.0+ds-2), libcrypt-dev:amd64 (1:4.4.36-2, 
1:4.4.36-4), multipath-tools:amd64 (0.9.4-7, 0.9.4-10), 
libcrypt1:amd64 (1:4.4.36-2, 1:4.4.36-4), qemu-system-common:amd64 
(1:8.2.0+ds-1, 1:8.2.0+ds-2), python3-httpcore:amd64 (0.17.3-1, 
1.0.2-1), qemu-block-extra:amd64 (1:8.2.0+ds-1, 1:8.2.0+ds-2), 
libopenmpi3:amd64 (4.1.6-4, 4.1.6-5), libsystemd-shared:amd64 
(255.2-2, 255.2-3), systemd-sysv:amd64 (255.2-2, 255.2-3), 
libexttextcat-data:amd64 (3.4.6-1, 3.4.7-1), libxml-parser-perl:amd64 
(2.46-4, 2.47-1), qemu-system-data:amd64 (1:8.2.0+ds-1, 1:8.2.0+ds-2), 
kpartx:amd64 (0.9.4-7, 0.9.4-10), valgrind:amd64 (1:3.20.0-2, 
1:3.20.0-2.1), qemu-system-gui:amd64 (1:8.2.0+ds-1, 1:8.2.0+ds-2), 
libsystemd-dev:amd64 (255.2-2, 255.2-3), linux-libc-dev:amd64 
(6.6.8-1, 6.6.9-1)

Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2024-01-02  20:31:08

/
/

I don't have any dkms module packages installed.


Regards


El 6/1/24 a las 15:40, Salvatore Bonaccorso escribió:

Hi,

On Sat, Jan 06, 2024 at 02:00:58PM +0100, Carlos Suérez wrote:

Package: linux-image-6.6.9-amd64
Version: 6.6.9-1
Severity: important

Dear Maintainer,

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

* What led up to the situation? System update failure with manual 'apt
update' at terminal.
* What exactly did you do (or not do) that was effective (or
ineffective)? I have tried to install the package only
* What was the outcome of this action? I get the same error
* What outcome did you expect instead? Update done


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

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

Versions of packages linux-image-6.6.9-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.142
ii kmod 31-1
ii linux-base 4.9

Versions of packages linux-image-6.6.9-amd64 recommends:
ii apparmor 3.0.12-1+b2
ii firmware-linux-free 20200122-3

Versions of packages linux-image-6.6.9-amd64 suggests:
pn debian-kernel-handbook 
ii grub-pc 2.12~rc1-12

pn linux-doc-6.6 


*** Output when i try to update/install the linux-image package from 6.6.8
to 6.6.9 ***


/run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return
code 127
dpkg: error al procesar el paquete linux-image-6.6.9-amd64 (--configure):
  el subproceso instalado paquete linux-image-6.6.9-amd64 script
post-installatio
n devolvió el código de salida de error 1
Se encontraron errores al procesar:
  linux-image-6.6.9-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)/

Can you please provide the full log of the update, which other
packages are involved? Do you have any dkms modules packages
installed?

Regards,
Salvatore

Bug#1060060: libclipboard-perl: 'clipbrowse' from Debian package libclipboard-perl executing clipboard contents

[gregor herrmann]

On Sat, 06 Jan 2024 02:08:44 +0100, Florian Schlichting wrote:

> I must admit I did not test this with firefox (only google-chrome), but
> I have done some testing now with "export BROWSER=firefox" set.
> 
> In my testing both work fine when the clipboard contains just a proper URL.
> 
> Newlines seem to be ignored / removed, and the second line concatenated
> to the first. This might be useful in case the MUA broke a long URL.
> 
> Firefox will display a new empty window when the clipboard contains a
> blank, while chrome changes that blank to %20 and displays the resulting
> URL in a new tab. Chrome on the other hand will display a new empty
> window when the clipboard contains a pipe.

Thanks for your extensive testing!
 
> IMHO both failure modes are acceptable, as in those cases the clipboard
> doesn't just contain a URL but some other garbage as well. Apparently
> the "I'm feeling lucky" part mentioned in the clipbrowse manpage is no
> longer implemented in Firefox. And there's clipjoin, which will remove
> some whitespace and pipe characters...

Sounds good to me.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1060183: ITP: python3-django-crum -- Current request user capture middleware for Django

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team 


* Package name: python3-django-crum
  Version : 0.7.9
  Upstream Contact: ch...@ninemoreminutes.com
* URL : https://github.com/ninemoreminutes/django-crum/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Current request user capture middleware for Django

 This Python library enables apps to check permissions, capture
 audit trails or access the current request and user without
 requiring the request object to be passed directly.
 .
 Django is a high-level Python web development framework.

It will be maintained in Debian Python Team, and is a dependency
of awx.

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Free Ekanayaka]

Mathias Gibbens  writes:

>   Late last night I successfully built Incus as a Debian package for
> the first time! ️
>
>   There are two blockers before we can perform the initial upload to
> NEW:
>
>   1 -- Remaining build deps:
>
> * We're still waiting on bin:golang-github-canonical-lxd-dev to
> make it through NEW.
>
> * golang-github-grafana-dskit-dev still needs to be packaged, but
> Incus seems to only have a single use of that library in
> internal/server/loki/loki.go. Last night I just patched out any
> reference in loki.go to dskit/backoff so everything else could build.
> Obviously not an ideal approach. However, do we want to consider
> disabling loki support in Incus for the time being to facilitate
> getting Incus into Debian? I'll keep working on packaging dskit and
> eventually we can re-enable loki support once it's packaged.

I think that's a very reasonable approach. Perfect is the enemy of good.

>   2 -- Testing/QA:
>
> * General testing: Later today I'm planning to start testing Incus
> on a sid machine. I'm sure this will turn up various things to
> fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure
> containers and VMs work out-of-the-box.
>
> * LXD migration: Simple migrations from LXD to Incus should work.
>
> * QA: Go through the debian/ directory in the Incus packaging to
> make sure it's all in good shape and is synced up with current LXD
> packaging work.
>
>   Excited to be close to the finish line on this!

Thank you Mathias!

I've been a bit on the sidelines the last few weeks, but I'm still
around :)

Bug#1060182: transition: simdjson

[M. Zhou]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: simdj...@packages.debian.org
Control: affects -1 + src:simdjson

Hi,

simdjson upstream bumped SOVERSION from 16 to 19 in the latest release.
All reverse dependencies can be rebuilt against 19 on amd64.

pcm [ok]
cloudflare-ddns [ok]

The automatic ben file on transition tracker is correct.
https://release.debian.org/transitions/html/auto-simdjson.html

Ben file:

title = "simdjson";
is_affected = .depends ~ "libsimdjson16" | .depends ~ "libsimdjson19";
is_good = .depends ~ "libsimdjson19";
is_bad = .depends ~ "libsimdjson16";
Thank you for using reportbug

Bug#1060181: Please consider supporting configuration via both /usr/share/apt/verify.d and /etc/apt/verify.d

[Josh Triplett]

Package: apt-verify
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

Many tools that use .d configuration directories support multiple such
directories, to make it easy to separate local sysadmin configuration
from distribution configuration. For instance, a hypothetical
apt-verify-myplugin package could install
/usr/share/apt/verify.d/50myplugin so that it automatically works when
installed, and then the sysadmin could change that with
/etc/apt/verify.d/50myplugin . One of several advantages of this is that
a sysadmin can, themselves, *package* their configuration very easily,
without having to divert files or similar.

(Also, in the process of this, you might consider refusing to run if no
configuration exists, to avoid effectively disabling verification. If a
user really wants to *disable* verification they should use the apt
configuration for *that* rather than installing apt-verify as a hook and
then giving apt-verify nothing to do.)


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

Kernel: Linux 6.6.8-amd64 (SMP w/12 CPU threads; 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)

Bug#1060180: uid-wrapper: cmocka does not set CMOCKA_LIBRARY anymore.

[Hefee]

Package: uid-wrapper
Version: 1.3.0-4
Severity: normal
Tags: patch
X-Debbugs-Cc: he...@debian.org

Hey,

cmocka does not set CMOCKA_LIBRARY anymore with 1.1.6+. You can easly
use cmoka as library name. I tested the attached patch locally and it
makes the autopkgtests pass again.

Additionally enables VERBOSE=1 for make, so it is easier to spot what
command is actually executed.

Regards,

hefee
diff --git a/debian/tests/tests b/debian/tests/tests
index b2b4504..a5adfa6 100755
--- a/debian/tests/tests
+++ b/debian/tests/tests
@@ -6,7 +6,7 @@ rm -rf obj debian
 mkdir obj
 cd obj
 cmake .. -DUNIT_TESTING=1
-make -C tests/
+make VERBOSE=1 -C tests/
 cd tests
 sed -e 's#\(LD_PRELOAD=[^:]*\)[^;]*/\(libuid_wrapper.so\)#\1:\2#' -i 
CTestTestfile.cmake
 make test ARGS="--output-on-failure"
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 635e86e..0398261 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -59,7 +59,7 @@ function(ADD_CMOCKA_TEST_ENVIRONMENT _TEST_NAME)
 ENVIRONMENT "${TORTURE_ENVIRONMENT}")
 endfunction()
 
-set(TESTSUITE_LIBRARIES ${UWRAP_REQUIRED_LIBRARIES} ${CMOCKA_LIBRARY})
+set(TESTSUITE_LIBRARIES ${UWRAP_REQUIRED_LIBRARIES} cmocka)
 
 if (BSD)
 add_definitions(-DBSD)

Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys

[Paul Szabo]

> ... why use a simple tool, when a complex one is almost as good?

Time for mariadb-hotcopy: 0.13user  5.50system 0:06.08elapsed 92%CPU
Time for mariadb-backup:  0.92user 12.31system 0:28.54elapsed 46%CPU

It is common Linux practice to send info to STDOUT, error to STDERR.
mariadb-hotcopy gets this right, while mariadb-backup is extremely(!)
chatty on STDERR.

But then, these are not this bug...

Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia

Bug#1060179: resolv-wrapper: cmocka does not set CMOCKA_LIBRARY anymore.

[Hefee]

Package: resolv-wrapper
Version: 1.1.8-2
Severity: normal
Tags: patch
X-Debbugs-Cc: he...@debian.org

Hey,

cmocka does not set CMOCKA_LIBRARY anymore with 1.1.6+. You can easly
use cmoka as library name. I tested the attached patch locally and it
makes the autopkgtests pass again.

Additionally enables VERBOSE=1 for make, so it is easier to spot what
command is actually executed.

Regards,

hefee
diff --git a/debian/tests/tests b/debian/tests/tests
index b4a4900..1a31031 100755
--- a/debian/tests/tests
+++ b/debian/tests/tests
@@ -6,7 +6,7 @@ rm -rf obj debian
 mkdir obj
 cd obj
 cmake -DUNIT_TESTING=1 ..
-make -C tests/
+make VERBOSE=1 -C tests/
 cd tests
 sed -e 's#\(LD_PRELOAD=\)[^;]*/\(libresolv_wrapper.so\)#\1\2#' -i 
CTestTestfile.cmake
 make test ARGS="--output-on-failure"
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 1262bed..2614d78 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -11,7 +11,7 @@ target_link_libraries(dns_srv ${RWRAP_REQUIRED_LIBRARIES})
 add_executable(test_real_res_query test_real_res_query.c)
 target_compile_options(test_real_res_query PRIVATE ${DEFAULT_C_COMPILE_FLAGS})
 target_include_directories(test_real_res_query PRIVATE ${CMAKE_BINARY_DIR} 
${CMOCKA_INCLUDE_DIR})
-target_link_libraries(test_real_res_query ${RWRAP_REQUIRED_LIBRARIES} 
${CMOCKA_LIBRARY})
+target_link_libraries(test_real_res_query ${RWRAP_REQUIRED_LIBRARIES} cmocka)
 
 configure_file(fake_hosts.in ${CMAKE_CURRENT_BINARY_DIR}/fake_hosts @ONLY)
 
@@ -19,11 +19,11 @@ add_library(${TORTURE_LIBRARY} STATIC torture.c)
 target_compile_options(${TORTURE_LIBRARY} PRIVATE ${DEFAULT_C_COMPILE_FLAGS})
 target_include_directories(${TORTURE_LIBRARY} PRIVATE ${CMAKE_BINARY_DIR} 
${CMOCKA_INCLUDE_DIR})
 target_link_libraries(${TORTURE_LIBRARY}
-${CMOCKA_LIBRARY}
+cmocka
 ${SWRAP_REQUIRED_LIBRARIES})
 
 
-set(TESTSUITE_LIBRARIES ${RWRAP_REQUIRED_LIBRARIES} ${CMOCKA_LIBRARY})
+set(TESTSUITE_LIBRARIES ${RWRAP_REQUIRED_LIBRARIES} cmocka)
 
 # Some tests require socket_wrapper as well.
 find_package(socket_wrapper REQUIRED)

Bug#1060178: priv-wrapper: cmocka does not set CMOCKA_LIBRARY anymore.

[Hefee]

Package: priv-wrapper
Version: 1.0.1-3
Severity: normal
Tags: patch
X-Debbugs-Cc: he...@debian.org

Hey,

cmocka does not set CMOCKA_LIBRARY anymore with 1.1.6+. You can easly
use cmoka as library name. I tested the attached patch locally and it
makes the autopkgtests pass again.

Additionally enables VERBOSE=1 for make, so it is easier to spot what
command is actually executed.

Regards,

hefee
diff --git a/debian/tests/tests b/debian/tests/tests
index 0c268ac..b85a7c0 100755
--- a/debian/tests/tests
+++ b/debian/tests/tests
@@ -4,7 +4,7 @@ rm -rf obj
 mkdir obj
 cd obj
 cmake -DUNIT_TESTING=1 ..
-make -C tests/
+make VERBOSE=1 -C tests/
 cd tests
 sed -e 's#\(LD_PRELOAD=\)[^;]*/\(libpriv_wrapper.so\)#\1\2#' -i 
CTestTestfile.cmake
 make test ARGS="--output-on-failure"
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index d33cf15..11526be 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -66,6 +66,6 @@ foreach(_PWRAP_TEST ${PWRAP_TESTS})
 add_cmocka_test(${_PWRAP_TEST}
 SOURCES ${_PWRAP_TEST}.c
 COMPILE_OPTIONS -D_GNU_SOURCE
-LINK_LIBRARIES ${CMOCKA_LIBRARY} PRIVATE defaults)
+LINK_LIBRARIES cmocka PRIVATE defaults)
 add_cmocka_test_environment(${_PWRAP_TEST})
 endforeach()

Bug#1060177: nss-wrapper: cmocka does not set CMOCKA_LIBRARY anymore.

[Hefee]

Package: nss-wrapper
Version: 1.1.15-2
Severity: normal
Tags: patch
X-Debbugs-Cc: he...@debian.org

Hey,

cmocka does not set CMOCKA_LIBRARY anymore with 1.1.6+. You can easly use cmoka 
as
library name. I tested the attached patch locally and it makes the
autopkgtests pass again.

Regards,

hefee
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 3b94076..e5feaaa 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -1,6 +1,6 @@
 project(tests C)
 
-set(TESTSUITE_LIBRARIES nss_utils ${NWRAP_REQUIRED_LIBRARIES} 
${CMOCKA_LIBRARY})
+set(TESTSUITE_LIBRARIES nss_utils ${NWRAP_REQUIRED_LIBRARIES} cmocka)
 string(TOLOWER "${CMAKE_BUILD_TYPE}" CMAKE_BUILD_TYPE_LOWER)
 
 add_library(nss_nwrap SHARED nss_nwrap.c)

Bug#1060176: dipy: FTBFS on ppc64el: FAILED dipy/segment/tests/test_mrf.py::test_icm_square - AssertionError

[Sebastian Ramacher]

Source: dipy
Version: 1.7.0-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=dipy=ppc64el=1.7.0-4%2Bb2=1704481336=0

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info 
FAILED dipy/segment/tests/test_mrf.py::test_icm_square - AssertionError
 1 failed, 798 passed, 148 skipped, 245 warnings in 2058.73s (0:34:18) =
make[1]: *** [debian/rules:60: override_dh_auto_install] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1060115: vcswatch: look for changelog in debian/experimental branch

[Christoph Berg]

Re: Martin
> + my @branch_list = qw(HEAD debian debian/master debian/sid 
> debian/latest debian/experimental master);

Applied, thanks!

Christoph

Bug#1060175: qemu-system-i386: Display 'sdl' is not available.

[Thorsten Glaser]

Package: qemu-system-x86
Version: 1:5.2+dfsg-11+deb11u3
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

qemu seems to start a VNC server by default now, which is okay for
organised emulation, but not for classical ad-hōc interactive use.

I found that I have to use -display sdl in the manpage, but that
seems to not work either.

This makes qemu much harder to use.


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

Kernel: Linux 5.10.0-27-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1
ii  libaio1   0.3.112-9
ii  libasound21.2.4-1.1
ii  libbrlapi0.8  6.3+dfsg-1+deb11u1
ii  libc6 2.31-13+deb11u7
ii  libcacard01:2.8.0-3
ii  libcapstone4  4.0.2-3
ii  libepoxy0 1.5.5-1
ii  libfdt1   1.6.0-1
ii  libgbm1   20.3.5-1
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1+deb11u1
ii  libgnutls30   3.7.1-5+deb11u4
ii  libibverbs1   33.2-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  libncursesw6  6.2+20201114-2+deb11u2
ii  libnettle83.7.3-1
ii  libnuma1  2.0.12-1+b1
ii  libpixman-1-0 0.40.0-1.1~deb11u1
ii  libpmem1  1.10-2+deb11u1
ii  libpng16-16   1.6.37-3
ii  librdmacm133.2-1
ii  libsasl2-22.1.27+dfsg-2.1+deb11u1
ii  libseccomp2   2.5.1-1+deb11u1
ii  libslirp0 4.4.0-1+deb11u2
ii  libspice-server1  0.14.3-2.1
ii  libtinfo6 6.2+20201114-2+deb11u2
ii  libudev1  247.3-7+deb11u4
ii  liburing1 0.7-3
ii  libusb-1.0-0  2:1.0.24-3
ii  libusbredirparser10.8.0-1+b1
ii  libvdeplug2   4.0.1-2
ii  libvirglrenderer1 0.8.2-5+deb11u1
ii  libxendevicemodel14.14.6-1
ii  libxenevtchn1 4.14.6-1
ii  libxenforeignmemory1  4.14.6-1
ii  libxengnttab1 4.14.6-1
ii  libxenmisc4.144.14.6-1
ii  libxenstore3.04.14.6-1
ii  libxentoolcore1   4.14.6-1
ii  qemu-system-common1:5.2+dfsg-11+deb11u3
ii  qemu-system-data  1:5.2+dfsg-11+deb11u3
ii  seabios   1.14.0-2
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

Versions of packages qemu-system-x86 recommends:
pn  ovmf 
pn  qemu-system-gui  
pn  qemu-utils   

Versions of packages qemu-system-x86 suggests:
pn  qemu-block-extra
ii  qemu-system-data [sgabios]  1:5.2+dfsg-11+deb11u3
pn  samba   
pn  vde2

-- no debconf information

Bug#1060174: rust-lscolors FTBFS: error[E0560]: struct `nu_ansi_term::Style` has no field named `prefix_with_reset`

[Adrian Bunk]

Source: rust-lscolors
Version: 0.16.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=rust-lscolors=0.16.0-1

...
error[E0560]: struct `nu_ansi_term::Style` has no field named 
`prefix_with_reset`
   --> src/style.rs:464:13
|
464 | prefix_with_reset: false,
| ^ `nu_ansi_term::Style` does not have this 
field
|
= note: available fields are: `foreground`, `background`, `is_bold`, 
`is_dimmed`, `is_italic` ... and 6 others
...

Bug#1060173: ruby-hiredis FTBFS with hiredis 1.2.0-6

[Adrian Bunk]

Source: ruby-hiredis
Version: 0.6.3-2
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/logs.php?pkg=ruby-hiredis=0.6.3-2%2Bb7

...
┌──┐
│ Run tests for ruby3.1 from debian/ruby-tests.rb  │
└──┘

RUBYLIB=/<>/debian/ruby-hiredis/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/3.1.0:/<>/debian/ruby-hiredis/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=/<>/debian/ruby-hiredis/usr/share/rubygems-integration/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
 ruby3.1 debian/ruby-tests.rb
Run options: --seed 8491

# Running:

..DEPRECATED: Use assert_nil if expecting nil from 
/<>/test/reader_test.rb:34. This will fail in Minitest 6.
.DEPRECATED: Use assert_nil if expecting nil from 
/<>/test/reader_test.rb:104. This will fail in Minitest 6.
./usr/lib/ruby/gems/3.1.0/gems/minitest-5.15.0/lib/minitest/assertions.rb:130:
 [BUG] Segmentation fault at 0x00841f27
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu]
...

Bug#1060172: xserver-xorg-core: Screen remains desperately black after starting Xorg on Thinkpad X201s

[Stefan Monnier]

Package: xserver-xorg-core
Version: 2:21.1.10-1
Severity: normal

Dear Maintainer,

Xorg refuses to work on my Thinkpad X201s nowadays, tho it used to work just
fine a year or so ago.  Wayland still works fine.

The observed behavior is that when GDM3 starts up (using Xorg because
I have set `WaylandEnable=false` in its config file) at the end of the
boot process, the screen becomes black and remains so.

I can use the keyboard to suspend and resume the machine, but I'm flying blind.

The same happens if I start Xorg "manually".

I have attached the corresponding Xorg.0.log from
/var/lib/gdm3/.local/share/xorg/ (which is very similar to the log
I see below, tho not quite identical because it's more recent).


Stefan

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
Integrated Graphics Controller [8086:0046] (rev 02)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 6.5.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC 
Debian 6.5.13-1 (2023-11-29)

Xorg X server log files on system:
--
-rw-r--r-- 1 monnier monnier 76698 Sep 12  2018 
/home/monnier/.local/share/xorg/Xorg.2.log
-rw-r--r-- 1 monnier monnier 42484 Nov  4 19:30 
/home/monnier/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 monnier monnier 36864 Nov  4 19:40 
/home/monnier/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 rootroot33004 Nov  4 20:48 /var/log/Xorg.2.log

Contents of most recent Xorg X server log file (/var/log/Xorg.2.log):
-
[  1354.627] 
X.Org X Server 1.21.1.9
X Protocol Version 11, Revision 0
[  1354.634] Current Operating System: Linux milanesa 6.5.0-3-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.5.8-1 (2023-10-22) x86_64
[  1354.634] Kernel command line: BOOT_IMAGE=/vmlinuz-6.5.0-3-amd64 
root=/dev/mapper/Milanesa-root ro
[  1354.639] xorg-server 2:21.1.9-1 (https://www.debian.org/support) 
[  1354.641] Current version of pixman: 0.42.2
[  1354.645]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1354.645] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1354.653] (==) Log file: "/var/log/Xorg.2.log", Time: Sat Nov  4 20:35:06 
2023
[  1354.655] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1354.657] (==) No Layout section.  Using the first Screen section.
[  1354.657] (==) No screen section available. Using defaults.
[  1354.657] (**) |-->Screen "Default Screen Section" (0)
[  1354.657] (**) |   |-->Monitor ""
[  1354.658] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1354.658] (==) Automatically adding devices
[  1354.658] (==) Automatically enabling devices
[  1354.658] (==) Automatically adding GPU devices
[  1354.658] (==) Automatically binding GPU devices
[  1354.659] (==) Max clients allowed: 256, resource mask: 0x1f
[  1354.659] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1354.659]Entry deleted from font path.
[  1354.659] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1354.659] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1354.659] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1354.659] (II) Loader magic: 0x568b67a0
[  1354.659] (II) Module ABI versions:
[  1354.659]X.Org ANSI C Emulation: 0.4
[  1354.659]X.Org Video Driver: 25.2
[  1354.659]X.Org XInput driver : 24.4
[  1354.659]X.Org Server Extension : 10.0
[  1354.662] (--) using VT number 1

[  1354.662] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  1354.665] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1354.665] (II) Platform probe for 
/sys/devices/pci:00/:00:02.0/drm/card0
[  1354.673] (--) PCI:*(0@0:2:0) 8086:0046:17aa:215a rev 2, Mem @ 
0xf200/4194304, 0xd000/268435456, I/O @ 0x1800/8, BIOS @ 
0x/131072
[  1354.673] (II) LoadModule: "glx"
[  1354.675] (II) Loading 

Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys

[Paul Szabo]

You convinced me (I convinced myself?): I now use mariadb-backup instead,
as per the lines in my patch in MDEV-33187:

  Seems mariadb-hotcopy is deprecated
  so maybe we should be using mariabackup?

I guess this is progress: why use a simple tool, when a complex one is
almost as good?

Thanks, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia

Join the Union and fight for a better University: www.nteu.au/join

Bug#942563: closed by car...@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

[Kamil Jońca]

Salvatore Bonaccorso  writes:

[..]
>> please reopen the bug, see https://www.debian.org/Bugs/server-control
>> for details.
>
> Oh it seems I miss-closed while doing housekeeping of linux bugs, as
> this was re-eassociated with firmware-nonfree. but I won't open it now
> again. In case the issue is still reproducible with recent version
> then please do so.

To be honest I am not able to recreate bug - I have different hardware
now (new laptop), so now I am not hit by it.

KJ

Bug#1033859: safeeyes: should recommend wlrctl for do not disturb mode

[Matthias Geiger]

On Mon, 03 Apr 2023 00:00:44 +0200 Matthias Geiger 
 wrote:


> Hi,
>
> thanks for maintaining safeeyes. The do not disturb mode under the 
plugins tab is not usable as
> the wlrctl utility is not packaged in debian. The upstream on 
sourcehut [1] seems kinda dead, so I'm not
> sure if introducing this package is viable. Packaging looks like not 
much effort since it's a small C

> program. I might get around to it but can't promise anything.
>
> Regards,
>
> Matthias Geiger (werdahias)
>
> [1] https://git.sr.ht/~brocellous/wlrctl
>

wlrctl is now in unstable thanks to Birger Schacht. patch for 
recommending it attached.


best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg

diff --git a/control b/control-new
index 8615d82..41f6145 100644
--- a/control
+++ b/control-new
@@ -14,7 +14,7 @@ Vcs-Browser: https://salsa.debian.org/debian/safeeyes
 Package: safeeyes
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, python3-gi, python3-dbus, gir1.2-gtk-3.0, gir1.2-notify-0.7
-Recommends: gir1.2-ayatanaappindicator3-0.1, xprintidle
+Recommends: gir1.2-ayatanaappindicator3-0.1, xprintidle, wlrctl
 Description: Protect your eyes from eye strain using this continuous breaks
  Safe Eyes is a simple tool to remind you to take periodic breaks for your
  eyes. This is essential for anyone spending more time on the computer to


OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060171: dosfstools: move files to /usr for DEP17

[cacin]

Source: dosfstools
Version: 4.2-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Dear Maintainer,

Patch attached to move files to /usr/sbin instead of /sbin in accordace with 
usrmerge

---
 debian/dosfstools-udeb.install | 6 +++---
 debian/dosfstools.install  | 1 -
 debian/rules   | 2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/debian/dosfstools-udeb.install b/debian/dosfstools-udeb.install
index 770b86d..09dc734 100644
--- a/debian/dosfstools-udeb.install
+++ b/debian/dosfstools-udeb.install
@@ -1,3 +1,3 @@
-sbin/fatlabel
-sbin/fsck.fat
-sbin/mkfs.fat
+usr/sbin/fatlabel
+usr/sbin/fsck.fat
+usr/sbin/mkfs.fat
diff --git a/debian/dosfstools.install b/debian/dosfstools.install
index 6811ecd..73752c9 100644
--- a/debian/dosfstools.install
+++ b/debian/dosfstools.install
@@ -1,2 +1 @@
-sbin
 usr
diff --git a/debian/rules b/debian/rules
index 126d903..161e79f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
dh ${@}
 
 override_dh_auto_configure:
-   dh_auto_configure -- --sbindir=/sbin --enable-compat-symlinks
+   dh_auto_configure -- --enable-compat-symlinks
 
 override_dh_auto_install:
dh_auto_install
-- 
2.43.0

Bug#1060170: ITP: sirit -- library for runtime SPIR-V assembly

[David James]

Package: wnpp
Severity: wishlist
Owner: David James 
X-Debbugs-Cc: debian-de...@lists.debian.org, davidjamescastor...@proton.me

* Package name: sirit
  Version : 0.0~git20230509
  Upstream Contact: Yuzu-emu team 
* URL : https://github.com/yuzu-emu/sirit
* License : BSD
  Programming Lang: C++, CMake
  Description : library for runtime SPIR-V assembly

I am woking towards packaging the Citra Nintendo 3DS emulator. This is the
second of five dependencies I need to package before I can do this.

In addition to being a Citra dependency, this package would be useful to
anyone developing applications that make use of Khronos' Vulkan API. This 
library emits SPIR-V shader code at runtime eliminating the need for
external applications, thus providing a potential performance benefit.

I plan to maintain this myself but I would need a sponsor to upload it for
me.

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Helmut Grohne]

On Sat, Jan 06, 2024 at 01:20:11PM +0100, Paul Gevers wrote:
> We're not there yet, so please hold your horses. Although I tend to think we
> should allow this too for the use cases you describe. So unless it's really
> the intent of a (source) package or small (source) package set to be meant
> to be used in a multi architecture environment I think we should demand that
> dependencies are not be exclusively fulfilled by packages from another
> architecture (:any is OK, :$arch is not). So indeed, each should require
> manual review. While writing this that *could* mean that britney2 grows
> support for cross-architecture dependencies while still blocking them if not
> forced.

I second this. I think we are already issuing a little too many :native
and :any annotations that occasionally fire back (when changing M-A:no
to M-A:foreign or M-A:allowed to M-A:same). Allowing :$arch for a
reviewed set enables a few useful corner cases and avoids use where it
is not appropriate.

Before we drop -$arch-cross packages, we should consult with Matthias
though. I think he has more reasons for them than britney2. One of them
is that we can perform basic cross compilation to non-release
architectures using only release-architecture packages. If we were to
drop them, I'm not sure how gcc-$VER-cross-ports could exist.

Helmut

Bug#1060026: yade: please move away from python3-future

[Alexandre Detiste]

please push upstream branch on Salsa

Bug#663148: po4a: Text (-o control=...) chokes on a normal dctrl file

[Niels Thykier]

On Sat, 06 Jan 2024 00:27:02 +0100 Martin Quinson 
 wrote:
> I believe the libdpkg-perl package has a dpkg parser that handles the 
> basic parsing.
> 


Indeed, I think that the parser in /usr/share/perl5/Dpkg/Control/HashCore.pm
would cover my needs. I'm still unsure of whether I should use this parser as
is, or copy/paste the code. The second is always crude, but the first one may
be difficult on non-Debian systems, as dpkg is meant to embeed all its
dependency to reduce bootstraping issues.

Anyway, I'm running out of time on po4a for this time and mostly write it down
for future reference.

Thanks for the fish,
Mt




For the record, the module is also on CPAN 
(https://metacpan.org/pod/Dpkg) in case that makes the situation easier 
to resolve.


Best regards,
Niels

Bug#1014890: RFP: python3-looseversion -- Version numbering for anarchists and software realists

[Mike Gabriel]

On  Do 04 Jan 2024 03:03:32 CET, Yaroslav Halchenko wrote:


AFAIK nope -- feel welcome to finish it up and upload.  Then you can
make it follow the desired naming  ;)

On Wed, 03 Jan 2024, Mike Gabriel wrote:


Has there been any progress on uploading python3-looseversion to unstable,
recently? (I'd suggest naming the src:pkg python-looseversion, though).



I need the LooseVersion() API for python-x2go and if you have dropped
interest in looseversion (or similar), would you be ok with me doing an
initial upload of python-looseversion?



Greets + Thanks for feedback,
Mike


Ack. Will take a look at it then.

Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpcOkZ_Vi34o.pgp
Description: Digitale PGP-Signatur

Bug#1060131: pydevd: FAILED tests_python/test_debugger_json.py::test_notify_gevent

[Julian Gilbey]

tags 1060131 - patch
thanks

Hello Dandan,

On Sat, Jan 06, 2024 at 04:00:27PM +0800, zhangdandan wrote:
> Source: pydevd
> Version: 2.10.0+ds-8
> Severity: wishlist
> Tags: patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
> 
> Dear maintainers,
> 
> When compiling the package pydevd for loong64 in the Debian Package
> Auto-Building environment, the error message are as follows:
> ..omit
> [...]

Yes; I have already arranged to skip this test, but not yet uploaded a
version of pydevd which actually does so.

> After analysis, I found that the linux-libc-dev_6.6.8-1 lacks loongarch's
> header files when compiling pydev in Debian Package Auto-Building
> environment.

That's fantastic, thank you!

> We have updated the linux-libc-dev_6.6.9-1 (including
> /usr/include/loongarch64-linux-gnu/asm/errno.h)to debian ports.
> The pydevd source package was compiled successfully on my local environment.
> Feedback the above phenomenon to the maintainer, please help us to giveback.
> If you have any questions, you can contact me at any time.

I'm not sure what this means; is the loong64 build done using Debian
ports?  If so, will your update transfer through to ci.debian.net?  Is
there anything I need to do about this, as it seems that it's not a
bug in pydevd itself, but rather in linux-libc-dev?

(BTW, I'm removing the "patch" tag as you did not appear to provide a
patch.)

Best wishes,

   Julian

Bug#1060099: telegram-desktop: FTBFS on mips64el: ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:16435:(.text+0x1600a0): relocation truncated to fit: R_MI

[Sebastian Ramacher]

Hi

On 2024-01-06 21:04:22 +0300, Nicholas Guriev wrote:
> Hello!
> 
> On 06.01.2024 00:09:14 MSK you wrote:
> > CMakeFiles/td_scheme.dir/gen/scheme.cpp.o: in function 
> > `MTPDchannel::read(int const*&, int const*)':
> > ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:16435:(.text+0x1600a0):
> >  relocation truncated to fit: R_MIPS_GOT_PAGE against `.text'
> > CMakeFiles/td_scheme.dir/gen/scheme.cpp.o: in function `MTPDuser::read(int 
> > const*&, int const*)':
> > ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:15827:(.text+0x16139c):
> >  relocation truncated to fit: R_MIPS_GOT_PAGE against `.text'
> > collect2: error: ld returned 1 exit status
> 
> Sorry, I have no idea how to properly fix this linker error. The 
> aforementioned
> translation unit already uses compiler flags -mxgot -fPIC. They helped before.
> It seems the scheme.cpp has reached the limit of code size of single TU.
> 
> Primary platform for Telegram Desktop is amd64; arm64 is also somewhat 
> popular.
> This issue is platform specific. And I daresay it is not that serious to block
> release on unaffected architectures.

Then please get the mips64el binaries removed and stop building the
package on the platform. Otherwise it will continue to block
telegram-desktop from migrating.

Cheers
-- 
Sebastian Ramacher

Bug#942563: closed by car...@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

[Salvatore Bonaccorso]

Hi,

On Sat, Jan 06, 2024 at 08:27:06AM +, Debian Bug Tracking System wrote:
[...]
> Hi
> 
> This bug was filed for a very old kernel or the bug is old itself
> without resolution.
> 
> If you can reproduce it with
> 
> - the current version in unstable/testing
> - the latest kernel from backports
> 
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.

Oh it seems I miss-closed while doing housekeeping of linux bugs, as
this was re-eassociated with firmware-nonfree. but I won't open it now
again. In case the issue is still reproducible with recent version
then please do so.

Regards,
Salvatore

Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1

[Russ Allbery]

I think the critical thing I missed in the original message is that
News::Article::NoCeM is constructing an inline signature by calling
pgp_sign.  The Hash header here is before the signed body, not before the
signature, which is obvious in your original message but which I failed to
pay proper attention to.

Christoph Biedl  writes:

> So, a blank line doesn't help. The message by gpgv is

> | gpgv: Signature made Fri Jan  5 18:21:01 2024 UTC
> | gpgv:using RSA key 87FB8F9D33883045A832B4FFD90D76CC97A7B20D
> | gpgv: WARNING: signature digest conflict in message
> | gpgv: Can't check signature: General error

> and this leads to an error message from perl-nocem:

> | Article : unknown error (ID D90D76CC97A7B20D)

> where "WARNING: signature digest conflict in message" is the same as
> I had seen in the first place, when there was the hardcoded "SHA1".

> For completeness, this is gpgv 2.2.40-1.1, from Debian 12 ("bookworm").
> Also, neither the NoCeM message nor the key are publicly available.

I think this is a bug in News::Article::NoCeM.  It is constructing an
inline signed document using PGP::Sign's pgp_sign function, but pgp_sign
creates detached signatures.  Detached and inline signatures are subtly
different, which has historically been the cause of all sorts of pain and
suffering trying to deal with OpenPGP signatures.

This is explicitly called out in the PGP::Sign manual page, although it
should be clearer since it implies the only issues are with whitespace
munging, but it seems like there are more issues than just that.

The whitespace munging support addresses the most common difference
between cleartext and detached signatures, but does not deal with all
of the escaping issues that are different between those two
modes. It's likely that extracting a cleartext signature and verifying
it with this module or using a signature from this module as a
cleartext signature will not work in all cases.

The other use cases for PGP::Sign (control message signatures and
PGPMoose) both use detached signatures, and it does try to document that
it only deals with detached signatures:

This module supports only two OpenPGP operations: Generate and check
detached PGP signatures for arbitrary text data.

Again, though, I should make this clearer.

I'm not sure where that leaves this bug, though.  It's quite
understandable that News::Article::NoCeM doesn't want to implement the
annoying logic of figuring out the correct flags to call GnuPG, but if the
expectation for NoCeM messages is that they use inline signatures (which I
believe is the case, although ideally they should use multipart/signed and
application/pgp-signature), PGP::Sign doesn't do that.  I do have other
use cases for inline signatures currently, so I am not completely opposed
to adding that support, although the more correct thing for me to do with
those other use cases would be to switch to multipart/signed instead.  At
least the last time I looked, inline signatures were very poorly
documented and standardized.

It's possible that this specific bug could be fixed if there were a way to
pass the desired hash algorithm into the sign() method of PGP::Sign so
that News::Article::NoCeM can force SHA-1 as a hash algorithm, thus making
the signature match the headers.  You suggested that in your original
message.  That's a bit more within the remit of PGP::Sign and I feel more
comfortable supporting that.  But I fear that may not be a full fix, since
there's still the detached versus inline signature mismatch that I think
is quite likely to produce more problems in the future.  (And of course
there's also the problem that News::Article::NoCeM really should be using
SHA-256, but that raises backwards compatibility issues.  There are a lot
of ancient PGPs out there in Usenet world.)

> It is indeed present there, I used pgpdump to reveal the hash algorithm
> is actually SHA512. So this is a design decision I don't quite follow,
> but possibly there is or was a need to do things that way.

This is ringing a vague bell.  I think the issue with inline signatures is
that since the document is stream-processed, the hash function that should
be used for the text has to be specified *before* the signed body text.
By the time the signature is read, it's too late; the body has already
been consumed and hashed with the default hash algorithm, and the correct
hash is no longer available.

I believe what hash algorithm GnuPG uses by default is controlled by local
GnuPG configuration, and it may well default to SHA-256 these days.

Also, all of these modules should switch to a sane interface to OpenPGP
signing and verification, like sup, but that's a whole other discussion.

-- 
Russ Allbery (r...@debian.org)  

Bug#1060169: axis: CVE-2023-51441

[Salvatore Bonaccorso]

Source: axis
Version: 1.4-29
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.4-28
Control: found -1 1.4-28+deb12u1

Hi,

The following vulnerability was published for axis.

CVE-2023-51441[0]:
| ** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation
| vulnerability in Apache Axis allowed users with access to the admin
| service to perform possible SSRF This issue affects Apache Axis:
| through 1.3.  As Axis 1 has been EOL we recommend you migrate to a
| different SOAP engine, such as Apache Axis 2/Java. Alternatively you
| could use a build of Axis with the patch from
| https://github.com/apache/axis-
| axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06  applied.
| The Apache Axis project does not expect to create an Axis 1.x
| release  fixing this problem, though contributors that would like to
| work towards  this are welcome.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-51441
https://www.cve.org/CVERecord?id=CVE-2023-51441
[1] https://www.openwall.com/lists/oss-security/2024/01/05/2
[2] 
https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06

Regards,
Salvatore

Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression

[Wouter Verhelst]

Hi Paul,

On Sat, Jan 06, 2024 at 01:58:53PM +0100, Paul Gevers wrote:
> Source: extrepo
> Version: 0.11
> Severity: serious
> Control: close -1 0.12
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:extrepo has been trying to migrate for 33 days [2].

This should have been fixed with the recent upload of extrepo-offline-data?

If that didn't happen yet, can you try to trigger another autopkgtest run?

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1055087: golang-1.21: Add support for loong64

[Shengjing Zhu]

On Tue, Oct 31, 2023 at 4:39 PM chenguoqi  wrote:
>
> Package: golang-1.21
> Version: 1.21.3
> Severity: wishlist
> Tags: patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
>
> Hi,
>
> Golang upstream supports loong64 starting from Go1.19 version, and currently
>
> all dependencies　for building golang-1.21 package on debian sid have been
>
> met. Golang-1.21 on loong64 can now be built.
>

Could you look at the failures when bootstrapping Go 1.22?
https://buildd.debian.org/status/fetch.php?pkg=golang-1.22=loong64=1.22%7Erc1-2=170456=0

-- 
Shengjing Zhu

Bug#1040663: linux: Please build linux-libc-dev package for loong64

[Adrian Bunk]

On Wed, Jul 12, 2023 at 11:07:12AM +0200, Bastian Blank wrote:
> Control: tags -1 confirmed
> 
> Hi
> 
> On Sat, Jul 08, 2023 at 08:41:03PM +0200, John Paul Adrian Glaubitz wrote:
> > Please enable building the linux-libc-dev package for the new Debian 
> > architecture loong64.
> > The corresponding kernel architecture is called "loongarch".
> 
> I can't find loong64 in the debian architecture table used on
> ftp-master, so we can't add it yet.

This changed in 6.6.8-1 where you made the linux-libc-dev package 
binary-all. The problem you mention no longer exists in this form,
but not having loong64 headers in the now binary-all package made
many packages FTBFS on loong64.

Please add support for linux-libc-dev-only architectures in 
debian/bin/gencontrol.py.

With a binary-all linux-libc-dev it does still work to have a different 
src:linux in unreleased, but linux-libc-dev does now break every time 
src:linux gets updated since a binary-all package 6.6.10-1 has a higher 
version than linux-libc-dev_6.6.9+loong64 in unreleased.

In practice this means that linux-libc-dev must ship headers at the 
latest when an architecture gets added in ports, far earlier than
building kernel images (which as you said might require other changes
on the ftp-master side).

> Bastian

Thanks
Adrian

Bug#1059845: Add support for loong64

[Andreas Tille]

Control: tags -1 pending

Am Tue, Jan 02, 2024 at 07:31:42PM +0800 schrieb liuxiang:
>   Please add loong64 support, patch file is attached.

I've applied the patch to Git but the package does not build currently due
to the Pandas transition.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1056978: hostname: diff for NMU version 3.23+nmu2

[Chris Hofstaedtler]

Control: tags 1056978 + patch
Control: tags 1056978 + pending

Because hostname gets installed by debootstrap, we'll need it fixed
before base-files can be changed, which should be soonish.

I'll put an NMU (versioned as 3.23+nmu2) into DELAYED/7.

Let me know if you intend to upload in the meantime.

Best,
Chris
diff -Nru hostname-3.23+nmu1/debian/changelog hostname-3.23+nmu2/debian/changelog
--- hostname-3.23+nmu1/debian/changelog	2022-12-19 14:33:11.0 +0100
+++ hostname-3.23+nmu2/debian/changelog	2023-11-27 14:03:42.0 +0100
@@ -1,3 +1,10 @@
+hostname (3.23+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install into /usr/bin instead of /bin. (Closes: #1056978)
+
+ -- Chris Hofstaedtler   Mon, 27 Nov 2023 14:03:42 +0100
+
 hostname (3.23+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru hostname-3.23+nmu1/debian/dirs hostname-3.23+nmu2/debian/dirs
--- hostname-3.23+nmu1/debian/dirs	2018-01-30 11:25:42.0 +0100
+++ hostname-3.23+nmu2/debian/dirs	2023-11-27 14:03:42.0 +0100
@@ -1,2 +1 @@
-/bin
 /usr/share/man/man1
diff -Nru hostname-3.23+nmu1/debian/rules hostname-3.23+nmu2/debian/rules
--- hostname-3.23+nmu1/debian/rules	2019-08-24 19:03:54.0 +0200
+++ hostname-3.23+nmu2/debian/rules	2023-11-27 14:03:42.0 +0100
@@ -51,7 +51,7 @@
 	dh_installdirs
 
 	# Installing package
-	$(MAKE) install BASEDIR=$(CURDIR)/debian/hostname $(CROSS)
+	$(MAKE) install BASEDIR=$(CURDIR)/debian/hostname BINDIR=/usr/bin $(CROSS)
 
 binary-indep: build install
 

Bug#1060168: ITP: python-json-log-formatter -- JSON formatter logging for Python

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team 


* Package name: python-json-log-formatter
  Version : 0.5.2
  Upstream Contact: https://github.com/marselester/json-log-formatter/issues/new
* URL : https://github.com/marselester/json-log-formatter
* License : Expat
  Programming Lang: Python
  Description : JSON formatter logging for Python

 This library allows one to configure Python logging to
 use a JSON formatter.

This library will be under Debian Python Team 
maintenance, and is a dependency of awx.

Bug#1060167: audit: install aliased files into /usr (DEP17 M2)

[Chris Hofstaedtler]

Source: audit
Version: 1:3.1.2-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
X-Debbugs-CC: helm...@debian.org

Dear audit Maintainers,

please find a patch attached to install files into /usr/{lib,sbin}
instead of /{lib,sbin}, for the ongoing Debian UsrMerge effort [1].

audit is relevant now because it is installed by debootstrap, and
thus needs to be converted before base-files can be changed.

A timely upload to experimental for further validation would be very
appreciated, as well as further testing & review.

If you want to backport audit to bookworm or earlier, please use
dh_movetousr instead of the attached patch.

If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru audit-3.1.2/debian/audispd-plugins.install audit-3.1.2/debian/audispd-plugins.install
--- audit-3.1.2/debian/audispd-plugins.install	2023-12-06 20:15:29.0 +0100
+++ audit-3.1.2/debian/audispd-plugins.install	2024-01-06 19:48:00.0 +0100
@@ -2,8 +2,8 @@
 etc/audit/plugins.d/au-remote.conf
 etc/audit/plugins.d/audispd-zos-remote.conf
 etc/audit/zos-remote.conf
-sbin/audisp-remote
-sbin/audispd-zos-remote
+usr/sbin/audisp-remote
+usr/sbin/audispd-zos-remote
 usr/share/man/man5/audisp-remote.conf.5
 usr/share/man/man5/zos-remote.conf.5
 usr/share/man/man8/audisp-remote.8
diff -Nru audit-3.1.2/debian/auditd.init audit-3.1.2/debian/auditd.init
--- audit-3.1.2/debian/auditd.init	2023-12-06 20:15:29.0 +0100
+++ audit-3.1.2/debian/auditd.init	2024-01-06 19:48:00.0 +0100
@@ -16,7 +16,7 @@
 PATH=/sbin:/usr/sbin:/bin:/usr/bin
 DESC="audit daemon"
 NAME=auditd
-DAEMON=/sbin/auditd
+DAEMON=/usr/sbin/auditd
 PIDFILE=/var/run/"$NAME".pid
 SCRIPTNAME=/etc/init.d/"$NAME"
 
@@ -46,11 +46,11 @@
 # Call augenrules to compile audit rules.
 case "$USE_AUGENRULES" in
 no|NO) ;;
-*) [ -d /etc/audit/rules.d ] && /sbin/augenrules >/dev/null ;;
+*) [ -d /etc/audit/rules.d ] && /usr/sbin/augenrules >/dev/null ;;
 esac
 	if [ -f /etc/audit/audit.rules ]
 	then
-		/sbin/auditctl -R /etc/audit/audit.rules >/dev/null
+		/usr/sbin/auditctl -R /etc/audit/audit.rules >/dev/null
 	fi
 }
 
diff -Nru audit-3.1.2/debian/auditd.install audit-3.1.2/debian/auditd.install
--- audit-3.1.2/debian/auditd.install	2023-12-06 20:15:29.0 +0100
+++ audit-3.1.2/debian/auditd.install	2024-01-06 19:48:00.0 +0100
@@ -3,15 +3,15 @@
 etc/audit/plugins.d/af_unix.conf
 etc/audit/plugins.d/syslog.conf
 etc/audit/rules.d/audit.rules
-init.d/auditd.service lib/systemd/system
-sbin/audisp-af_unix
-sbin/audisp-syslog
-sbin/auditctl
-sbin/auditd
-sbin/augenrules
-sbin/aureport
-sbin/ausearch
-sbin/autrace
+init.d/auditd.service usr/lib/systemd/system
+usr/sbin/audisp-af_unix
+usr/sbin/audisp-syslog
+usr/sbin/auditctl
+usr/sbin/auditd
+usr/sbin/augenrules
+usr/sbin/aureport
+usr/sbin/ausearch
+usr/sbin/autrace
 usr/bin/aulast
 usr/bin/aulastlog
 usr/bin/ausyscall
diff -Nru audit-3.1.2/debian/auditd.lintian-overrides audit-3.1.2/debian/auditd.lintian-overrides
--- audit-3.1.2/debian/auditd.lintian-overrides	2023-12-06 20:15:29.0 +0100
+++ audit-3.1.2/debian/auditd.lintian-overrides	2024-01-06 19:48:00.0 +0100
@@ -1,9 +1,9 @@
 ## Only to be forked by auditd, which explicitly checks for 750
-#auditd: executable-is-not-world-readable sbin/audispd 0750 != 0755
+#auditd: executable-is-not-world-readable usr/sbin/audispd 0750 != 0755
 ## Only root can run
-#auditd: non-standard-executable-perm sbin/auditctl 0754 != 0755
-#auditd: non-standard-executable-perm sbin/auditd 0754 != 0755
-#auditd: non-standard-executable-perm sbin/autrace 0754 != 0755
+#auditd: non-standard-executable-perm usr/sbin/auditctl 0754 != 0755
+#auditd: non-standard-executable-perm usr/sbin/auditd 0754 != 0755
+#auditd: non-standard-executable-perm usr/sbin/autrace 0754 != 0755
 #auditd: non-standard-executable-perm usr/bin/aulastlog 0754 != 0755
 ## Normal users should not see what is being audited
 auditd: non-standard-dir-perm 0750 != 0755 [etc/audit/]
diff -Nru audit-3.1.2/debian/auditd.README.Debian audit-3.1.2/debian/auditd.README.Debian
--- audit-3.1.2/debian/auditd.README.Debian	2023-12-06 20:15:29.0 +0100
+++ audit-3.1.2/debian/auditd.README.Debian	2024-01-06 19:48:00.0 +0100
@@ -13,7 +13,7 @@
   /etc/systemd/system/auditd.service.d/augenrules.conf:
 [Service]
 ExecStartPost=
-ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
+ExecStartPost=-/usr/sbin/auditctl -R /etc/audit/audit.rules
 
 Check that the needed rules are present in /etc/audit/audit.rules before
 restarting the daemon.
diff -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog
--- audit-3.1.2/debian/changelog	2023-12-06 20:15:29.0 +0100
+++ 

Bug#1058945: python3-secretstorage: please do not depend on dbus package

[Ansgar]

Hi,

On Sat, 2024-01-06 at 20:39 +0300, Dmitry Shachnev wrote:
> On Mon, Dec 18, 2023 at 08:14:55PM +0100, Ansgar wrote:
> > If anything, only applications should require specific interfaces.
> > A library like python3-secretstorage cannot know whether its use is
> > essential (in which case dbus should probably be a dependency) or
> > totally optional (in which case dbus should be
> > suggested/recommended).
> 
> I am confused. In version 3.3.3-2, python3-secretstorage changed
> dependency from dbus to default-dbus-session-bus | dbus-session-bus.
> 
> And you filed this bug against the new version, 3.3.3-2. Is that a
> mistake? Or the new dependency is still not good?

That doesn't help much unless one takes special care. This is what
installing python3-poetry in a Podman container looks like:

% podman run --rm -it debian:unstable
root@6663e6910965:/# apt update
Get:1 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 Packages [9642 kB]
Fetched 9840 kB in 2s (5939 kB/s)   
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
39 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@6663e6910965:/# apt install python3-poetry
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  adduser adwaita-icon-theme at-spi2-common at-spi2-core binutils 
binutils-common
  binutils-x86-64-linux-gnu bsdutils build-essential bzip2 ca-certificates cpp 
cpp-13 dbus dbus-bin
  dbus-daemon dbus-session-bus-common dbus-system-bus-common dbus-user-session 
dconf-gsettings-backend
  dconf-service dirmngr dmsetup dpkg dpkg-dev fakeroot fontconfig 
fontconfig-config fonts-dejavu-core
  fonts-dejavu-mono g++ g++-13 gcc gcc-13 gcr gnome-keyring 
gnome-keyring-pkcs11 gnupg gnupg-l10n
  gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm 
gsettings-desktop-schemas
  gtk-update-icon-cache hicolor-icon-theme javascript-common krb5-locales 
libabsl20220623
  libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl 
libaom3 libapparmor1
  libargon2-1 libasan8 libassuan0 libatk-bridge2.0-0 libatk1.0-0 libatomic1 
libatspi2.0-0
  libavahi-client3 libavahi-common-data libavahi-common3 libavif16 libbinutils 
libblkid1 libbrotli1
  libbsd0 libbz2-1.0 libc-dev-bin libc-devtools libc6-dev libcairo-gobject2 
libcairo2 libcc1-0
  libcloudproviders0 libcolord2 libcrypt-dev libcrypt1 libcryptsetup12 
libctf-nobfd0 libctf0 libcups2
  libdatrie1 libdav1d7 libdbus-1-3 libdconf1 libde265-0 libdeflate0 
libdevmapper1.02.1 libdpkg-perl
  libepoxy0 libexpat1 libexpat1-dev libfakeroot libfdisk1 
libfile-fcntllock-perl libfontconfig1
  libfreetype6 libfribidi0 libgav1-1 libgcc-13-dev libgck-1-0 libgcr-base-3-1 
libgcr-ui-3-1 libgd3
  libgdbm-compat4 libgdbm6 libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-bin 
libgdk-pixbuf2.0-common
  libglib2.0-0 libglib2.0-data libgomp1 libgpm2 libgprofng0 libgraphite2-3 
libgssapi-krb5-2 libgtk-3-0
  libgtk-3-bin libgtk-3-common libharfbuzz0b libheif-plugin-aomenc 
libheif-plugin-dav1d
  libheif-plugin-libde265 libheif-plugin-x265 libheif1 libhwasan0 libicu72 
libisl23 libitm1
  libjansson4 libjbig0 libjpeg62-turbo libjs-jquery libjs-sphinxdoc 
libjs-underscore libjson-c5
  libk5crypto3 libkeyutils1 libkmod2 libkrb5-3 libkrb5support0 libksba8 
liblcms2-2 libldap-2.5-0
  libldap-common liblerc4 liblocale-gettext-perl liblsan0 liblzma5 libmount1 
libmpc3 libmpfr6
  libncursesw6 libnpth0 libnsl-dev libnsl2 libnss-systemd libnuma1 libp11-kit0 
libpam-gnome-keyring
  libpam-systemd libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 
libperl5.36 libpixman-1-0
  libpng16-16 libproc2-0 libpython3-dev libpython3-stdlib libpython3.11 
libpython3.11-dev
  libpython3.11-minimal libpython3.11-stdlib libquadmath0 librav1e0 
libreadline8 librsvg2-2
  librsvg2-common libsasl2-2 libsasl2-modules libsasl2-modules-db libsecret-1-0 
libsecret-common
  libsframe1 libsharpyuv0 libsmartcols1 libsqlite3-0 libstdc++-13-dev 
libsvtav1enc1d1
  libsystemd-shared libsystemd0 libthai-data libthai0 libtiff6 libtirpc-common 
libtirpc-dev libtirpc3
  libtsan2 libubsan1 libudev1 libuuid1 libwayland-client0 libwayland-cursor0 
libwayland-egl1 libwebp7
  libx11-6 libx11-data libx265-199 libxau6 libxcb-render0 libxcb-shm0 libxcb1 
libxcomposite1
  libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxi6 libxinerama1 
libxkbcommon0 libxml2
  libxpm4 libxrandr2 libxrender1 libxtst6 libyuv0 linux-libc-dev make manpages 
manpages-dev
  media-types mount netbase openssl p11-kit p11-kit-modules patch perl 
perl-base perl-modules-5.36
  pinentry-gnome3 procps psmisc python-pkginfo-doc python3 python3-build 
python3-cachecontrol
  python3-certifi python3-cffi-backend python3-chardet 
python3-charset-normalizer python3-cleo
  python3-crashtest python3-cryptography python3-dev python3-distlib 
python3-distutils 

Bug#1060166: RFP: dippi -- Calculate display info like DPI and aspect ratio

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: dippi
  Version : 4.0.6
  Upstream Contact: Cassidy James
* URL : https://github.com/cassidyjames/dippi
* License : GPL-3
  Programming Lang: Vala
  Description : Calculate display info like DPI and aspect ratio

dippi is a small program calculating display info like doi or aspect
ratio. I think this would make a good addition to debian.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWZoS8VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1K60P/2CNQDiA9cXPwtwRVcN5i41lEEfH
PviPSHiiiO9+h/JXcm6i5P2MeW14Ku1GZ+D94VLleekHB1nhb+1Rj9AwwtnFZUDl
7b5C9z9FgTigLGZ7y/hrUfXODxOq8qUcE8tVrgM69LGjKw/1XZnce4aslZgA89GE
ko8WgUTFsJDCNqDq3WbkAptiKhzuEDHQ/uFgLjhcVOiaoq9VrutIeECAT22agYeV
PlBt5mjAWsVKA3goNFOL6Kbf8yztVuTobvjy71rjCEX7zjx54uKc+pQpJ4LpBohf
urmy0VAjKEY4Zu/ZaSTnen6ndb/MUGKueV2DDMASsY2uKC7BNU1HfrFNu+gvS2nW
SPye3dV+y1E35GNBuw4TTjNC78wsl/NEeueWpUZ2xu10jJn4q53waDYIfCYdSTj9
p43zBTb3f899nNUSv7/OMINnRIX6mz5yUlRC6Kn/I90559Hp2ft3HuKLWqwkHAn9
kTa+rDxpBqqWG45II8tnIqf+gHlcYx55wAU7bUmp+qv96/U7AAf/URbW28fuSWJ9
t1hWb1yu9Rd4/pZc2re2X+c6stZoIQDcg6bKbjuN1B3haUM0MGi8/uc0K8QwrPVz
qTU/G8L3Mgxv5RaxGmMLRBaXAUf3e4lmpoS2NVpz68CyGrg8C4TRroYSUQ8NnX4M
Bscu4fo7IGuNen+d
=rKmS
-END PGP SIGNATURE-

Bug#1060165: RM: liblouisutdml/2.12.0-2

[Samuel Thibault]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: liblouisut...@packages.debian.org
Control: affects -1 + src:liblouisutdml

Hello,

One month later, upstream liblouisutdml is failing to update to the
newer liblouis (3.28):

https://github.com/liblouis/liblouisutdml/issues/103

thus making it fail to build in unstable (#1058514) and its autopkgtest
failing with the newer liblouis, thus leading to an automatic request
for removal of liblouis (#1060148).

We really rather want to update liblouis and remove liblouisutdml from
testing rather than see liblouis stuck at 3.27.

Thanks,
Samuel

Bug#1059945: toil: please remove extraneous build-dep on python3-future

[Andreas Tille]

Control: tags -1 pending
Control: block -1 by 1058654

Unfortunately we can't upload toil until bug #1058654 is fixed.

-- 
http://fam-tille.de

Bug#1058654: toil: python3-boto is being removed from the archive

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/DataBiosphere/toil/issues/4718


-- 
http://fam-tille.de

Bug#1060099: telegram-desktop: FTBFS on mips64el: ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:16435:(.text+0x1600a0): relocation truncated to fit: R_MI

[Nicholas Guriev]

Hello!

On 06.01.2024 00:09:14 MSK you wrote:
> CMakeFiles/td_scheme.dir/gen/scheme.cpp.o: in function `MTPDchannel::read(int 
> const*&, int const*)':
> ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:16435:(.text+0x1600a0):
>  relocation truncated to fit: R_MIPS_GOT_PAGE against `.text'
> CMakeFiles/td_scheme.dir/gen/scheme.cpp.o: in function `MTPDuser::read(int 
> const*&, int const*)':
> ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:15827:(.text+0x16139c):
>  relocation truncated to fit: R_MIPS_GOT_PAGE against `.text'
> collect2: error: ld returned 1 exit status

Sorry, I have no idea how to properly fix this linker error. The aforementioned
translation unit already uses compiler flags -mxgot -fPIC. They helped before.
It seems the scheme.cpp has reached the limit of code size of single TU.

Primary platform for Telegram Desktop is amd64; arm64 is also somewhat popular.
This issue is platform specific. And I daresay it is not that serious to block
release on unaffected architectures.


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

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Tobias Frost]

Control: tags -1 moreinfo

On Sat, Dec 30, 2023 at 07:27:26AM +0300, Igor B. Poretsky wrote:
> Hello Tobias,
> 
> > "Tobias" == Tobias Frost  writes:
> 
> Tobias> - m4/* has undocumentd files.
> 
> Why should these files be mentioned especially? Isn't the "Files: *"
> stanza sufficient?

Those undocumented files have a different license, license holders
and/or copyright years. So they need to be mentioned extra.

As the license is different, they need to be in an extra Files:
section.)

For example:

$ head m4/libtool.m4
# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
#
#   Copyright (C) 1996-2001, 2003-2015 Free Software Foundation, Inc.
#   Written by Gordon Matzigkeit, 1996
#
# This file is free software; the Free Software Foundation gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.

your d/copyright do not mention them, so this needs to be fixed.

> Tobias> - */Makefile.in are not documented
> 
> The Makefile.in files are autogenerated. How should be they documented
> apart from others? And, maybe, some other autogenerated files as well?
>
> Apparently there is something I don't understand clearly here.

You need to document the verbatim copyright infomation every file that
you ship in your orig.tar.  Those autogenerated Makefile.in are:

# Makefile.in generated by automake 1.15 from Makefile.am.
# @configure_input@

# Copyright (C) 1994-2014 Free Software Foundation, Inc.

# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

So, as long as you ship them in your tarball, they must be documented.
(As for libtool.m4 and Makefile.in the license is the same, you might
be able to document in a single additional Files: * section.)

(I suggest that you verify each and every file and see if something else
is missing in d/copyright.)

> Best regards,
> Igor.
> 

-- 
tobi


signature.asc
Description: PGP signature

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Stéphane Graber]

On Sat, Jan 6, 2024 at 12:52 PM Mathias Gibbens  wrote:
>
>   Late last night I successfully built Incus as a Debian package for
> the first time! ️

Nice!

>   There are two blockers before we can perform the initial upload to
> NEW:
>
>   1 -- Remaining build deps:
>
> * We're still waiting on bin:golang-github-canonical-lxd-dev to
> make it through NEW.
>
> * golang-github-grafana-dskit-dev still needs to be packaged, but
> Incus seems to only have a single use of that library in
> internal/server/loki/loki.go. Last night I just patched out any
> reference in loki.go to dskit/backoff so everything else could build.
> Obviously not an ideal approach. However, do we want to consider
> disabling loki support in Incus for the time being to facilitate
> getting Incus into Debian? I'll keep working on packaging dskit and
> eventually we can re-enable loki support once it's packaged.

I'm not terribly familiar with the LOKI integration but that
particular dependency has been bothering me for a while given how much
stuff it pulls in.
I'd love to see it gone, but I'd have to figure out exactly what's
needed and how easy it may be to re-implement.

I wouldn't expect the LOKI log ingest protocol to be so complicated
that it needs such a large dependency chain.

>   2 -- Testing/QA:
>
> * General testing: Later today I'm planning to start testing Incus
> on a sid machine. I'm sure this will turn up various things to
> fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure
> containers and VMs work out-of-the-box.
>
> * LXD migration: Simple migrations from LXD to Incus should work.
>
> * QA: Go through the debian/ directory in the Incus packaging to
> make sure it's all in good shape and is synced up with current LXD
> packaging work.
>
>   Excited to be close to the finish line on this!

Yep, exciting times!

> Mathias



-- 
Stéphane

Bug#731164: ghostscript: ps2pdf makes highlighted/annotated text unreadable by poppler-based PDF viewers

[Vincent Lefevre]

On 2024-01-06 18:17:20 +0100, Vincent Lefevre wrote:
> I confirm. However, Firefox 121 (from the Debian package) still
> has the same issue with "out.pdf". That said, if I try again
> "ps2pdf temp.pdf out.pdf" with ghostscript 10.02.1~dfsg-1 (on
> my Debian/unstable machine), Firefox displays the new out.pdf
> document just like the poppler-based PDF viewers, with readable
> text (and with no warnings). So, if there was a bug in ghostscript,
> it is now "fixed".

I may have done something wrong in my tests, because actually,
only xpdf is now fine with the old out.pdf file. But all xpdf,
zathura and atril have no issues with the file generated by the
current ps2pdf. This confirms a good change in ghostscript.

However, the new ps2pdf triggers a bug / unimplemented feature
in atril (but this isn't a bug in ghostscript).

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

Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1

[Christoph Biedl]

Russ Allbery wrote...

> Christoph Biedl  writes:
>
> > * Omitting the hash declaration is not an option either, perl-nocem
> >   fails then.
>
> I'm somewhat surprised by this, as my impression was that these Hash lines
> are optional and GnuPG did the right thing if they were omitted entirely
> (although you do still need a blank line).

That impression was on my side as well, and later the surprise. It would
habe been a quick solution.

It seems that pseudo-header is mandatory but I haven't checked further:
https://sources.debian.org/src/gnupg2/2.2.40-1.1/g10/sig-check.c/?hl=188#L188

So, a blank line doesn't help. The message by gpgv is

| gpgv: Signature made Fri Jan  5 18:21:01 2024 UTC
| gpgv:using RSA key 87FB8F9D33883045A832B4FFD90D76CC97A7B20D
| gpgv: WARNING: signature digest conflict in message
| gpgv: Can't check signature: General error

and this leads to an error message from perl-nocem:

| Article : unknown error (ID D90D76CC97A7B20D)

where "WARNING: signature digest conflict in message" is the same as
I had seen in the first place, when there was the hardcoded "SHA1".

For completeness, this is gpgv 2.2.40-1.1, from Debian 12 ("bookworm").
Also, neither the NoCeM message nor the key are publicly available.

> I have not looked into this in
> detail, but I thought the hash algorithm was also present in metadata
> inside the signature itself.

It is indeed present there, I used pgpdump to reveal the hash algorithm
is actually SHA512. So this is a design decision I don't quite follow,
but possibly there is or was a need to do things that way.

(...)

> perl-nocem itself doesn't seem to care and just copies the whole input
> into a temporary file for GnuPG.  What's the nature of the failure?  Is
> GnuPG failing to validate the resulting file if the hash algorithm is
> omitted?

See above.

Christoph


signature.asc
Description: PGP signature

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Mathias Gibbens]

  Late last night I successfully built Incus as a Debian package for
the first time! ️

  There are two blockers before we can perform the initial upload to
NEW:

  1 -- Remaining build deps:

* We're still waiting on bin:golang-github-canonical-lxd-dev to
make it through NEW.

* golang-github-grafana-dskit-dev still needs to be packaged, but
Incus seems to only have a single use of that library in
internal/server/loki/loki.go. Last night I just patched out any
reference in loki.go to dskit/backoff so everything else could build.
Obviously not an ideal approach. However, do we want to consider
disabling loki support in Incus for the time being to facilitate
getting Incus into Debian? I'll keep working on packaging dskit and
eventually we can re-enable loki support once it's packaged.

  2 -- Testing/QA:

* General testing: Later today I'm planning to start testing Incus
on a sid machine. I'm sure this will turn up various things to
fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure
containers and VMs work out-of-the-box.

* LXD migration: Simple migrations from LXD to Incus should work.

* QA: Go through the debian/ directory in the Incus packaging to
make sure it's all in good shape and is synced up with current LXD
packaging work.

  Excited to be close to the finish line on this!

Mathias


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

Bug#1060026: [Help] yade: please move away from python3-future

[Andreas Tille]

Control: tags -1 help

I'd happily upload a fixed package but I've found a lot of instances
of future and would prefer if you could provide a patch.

Thanks a lot for your effort to remove future from Debian
Andreas.

-- 
http://fam-tille.de

Bug#1058945: python3-secretstorage: please do not depend on dbus package

[Dmitry Shachnev]

Control: tags -1 +moreinfo

Hi Ansgar!

On Mon, Dec 18, 2023 at 08:14:55PM +0100, Ansgar wrote:
> Package: python3-secretstorage
> Version: 3.3.3-2
> Severity: normal
>
> Please do not depend on dbus.
>
> Currently installing anything depending on python3-secretstorage will
> install dbus-user-session and with it systemd-sysv, for example:
> python3-poetry -> python3-keyring -> poetry3-secretstorage -> dbus
>
> This is pretty useless in containers. So please do not force to
> install it: it should be fine to just return an error in case the
> secret storage service is not reachable, for example because there is
> no dbus bus to use.
>
> If anything, only applications should require specific interfaces. A
> library like python3-secretstorage cannot know whether its use is
> essential (in which case dbus should probably be a dependency) or
> totally optional (in which case dbus should be suggested/recommended).

I am confused. In version 3.3.3-2, python3-secretstorage changed dependency
from dbus to default-dbus-session-bus | dbus-session-bus.

And you filed this bug against the new version, 3.3.3-2. Is that a mistake?
Or the new dependency is still not good?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1060164: libxeus9 incompatible with nlohmann::json_abi_v3_11_3

[Bill Allombert]

Package: xeus-dev
Version: 3.1.3-1
Severity: serious

Dear Debian Science maintainers,

I have trouble with linking with libxeus9 since I upgraded
nlohmann-json3-dev to 3.11.3-1.

It seems to me nlohmann-json3-dev 3.11.3-1. is changing the API of libxeus9 in 
an incompatible way.

/lib/x86_64-linux-gnu/libxeus.so.9 defines 

xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, 
std::__cxx11::basic_string, std::allocator > 
const&, std::__cxx11::basic_string, 
std::allocator > const&, nlohmann::json_abi_v3_11_2::basic_json, 
std::allocator >, bool, long, unsigned
long, double, std::allocator, nlohmann::json_abi_v3_11_2::adl_serializer, 
std::vector > > const&)

while programs compiled with xeus-dev and nlohmann-json3-dev require

xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, 
std::__cxx11::basic_string, std::allocator > 
const&, std::__cxx11::basic_string, 
std::allocator > const&, nlohmann::json_abi_v3_11_3::basic_json, 
std::allocator >, bool, long, unsigned
long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, 
std::vector >, void> const&)'

That is 'nlohmann::json_abi_v3_11_3' instead of 'nlohmann::json_abi_v3_11_2'

This causes xeus-based kernels to fail to link.

main.cpp:(.text+0x58b): undefined reference to 
`xeus::make_null_debugger(xeus::xcontext&, xeus::xconfiguration const&, 
std::__cxx11::basic_string, std::allocator > 
const&, std::__cxx11::basic_string, 
std::allocator > const&, nlohmann::json_abi_v3_11_3::basic_json, 
std::allocator >, bool, long, unsigned long, double, std::allocator, 
nlohmann::json_abi_v3_11_3::adl_serializer, std::vector >, void> const&)'

Downgrading nlohmann-json3-dev to 3.11.2-2 fixes this issue.

binNMUing libxeus9 might fix this issue, but will probably silently change the 
ABI of libxeus9 without
updating the shlibs. This is worrysome. I hope I am wrong about that.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1060163: packages.debian.org should offer https links to binaries

[Bill Allombert]

Package: www.debian.org
Severity: normal

Dear packages.d.o team,

Binary download pages like this one:
https://packages.debian.org/bookworm/all/nlohmann-json3-dev/download
only offer http links to packages and not https links.

firefox flags downloading binaries through http links as dangerous

Hopefully most mirrors should support https download now.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#731164: ghostscript: ps2pdf makes highlighted/annotated text unreadable by poppler-based PDF viewers

[Vincent Lefevre]

On 2024-01-05 22:58:58 -0600, Steven Robbins wrote:
> On Mon, 2 Dec 2013 17:15:19 +0100 Vincent Lefevre  wrote:
> > Package: ghostscript
> > Version: 9.05~dfsg-8
> > Severity: important
> > 
> > When I use ps2pdf on a file with highlighted/annotated text (as
> > produced by Apple's Preview on Mac OS X 10.6.8), this text is
> > displayed below the background with poppler-based PDF viewers
> > (xpdf, evince, okular).
> > 
> > I've attached the original file temp.pdf (no problems with it),
> > the out.pdf file produced by "ps2pdf temp.pdf out.pdf", which
> > cannot be read correctly by poppler-based PDF viewers, and the
> > out.png file, which is a screenshot of "xpdf out.pdf" (so that
> > you can see the problem).
> 
> I don't know where the problem lay, but just tested now with xpdf 
> 3.04+git20231213-1.  Both temp.pdf and out.pdf displayed identically.

I confirm. However, Firefox 121 (from the Debian package) still
has the same issue with "out.pdf". That said, if I try again
"ps2pdf temp.pdf out.pdf" with ghostscript 10.02.1~dfsg-1 (on
my Debian/unstable machine), Firefox displays the new out.pdf
document just like the poppler-based PDF viewers, with readable
text (and with no warnings). So, if there was a bug in ghostscript,
it is now "fixed".

FYI, "qpdf --check temp.pdf" signals an error in the PDF file:

WARNING: temp.pdf (object 11 0): object has offset 0

and "ps2pdf temp.pdf out.pdf" now fixes it silently.

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

Bug#1060162: sssd_ad: Dynamic DNS updates fail with NOTZONE for PTR records if interface has multiple IPv6 adresses

[Dirk Heinrichs]

Package: sssd-ad
Version: 2.8.2-4
Severity: normal
Tags: upstream ipv6
X-Debbugs-Cc: dirk.heinri...@altum.de



If a network interface has multiple IPv6 addresses (here: a public one and one
on the fd00 network), dynamic DNS updates fail with a NOTZONE error when
updating the PTR records, although there's a zone for each of the networks
configured in the DNS (Samba AD) server. The reason is that the commands to
update the records are sent at the same time, like this (according to the log
file):

update delete .in-addr.arpa. in PTR
update add .in-addr.arpa. 3600 in PTR .
send
update delete .ip6.arpa. in PTR
update add .ip6.arpa. 3600 in PTR .
update delete .ip6.arpa. in PTR
update add .ip6.arpa. 3600 in PTR .
send

which I can also reproduce by copy/pasting the same commands into an nsupdate
session.

The problem can easily be solved by adding another send command, like so:

update delete .in-addr.arpa. in PTR
update add .in-addr.arpa. 3600 in PTR .
send
update delete .ip6.arpa. in PTR
update add .ip6.arpa. 3600 in PTR .
send
update delete .ip6.arpa. in PTR
update add .ip6.arpa. 3600 in PTR .
send

The problem has been solved upstream already (see
https://github.com/SSSD/sssd/issues/7110) and released with version 2.9.3.
Please backport the fix to 2.8.2 included in Bookworm.


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

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

Versions of packages sssd-ad depends on:
ii  libc6 2.36-9+deb12u3
ii  libdhash1 0.6.2-1
ii  libini-config50.6.2-1
ii  libldap-2.5-0 2.5.13+dfsg-5
ii  libldb2   2:2.6.2+samba4.17.12+dfsg-0+deb12u1
ii  libpopt0  1.19+dfsg-1
ii  libsasl2-22.1.28+dfsg-10
ii  libsmbclient  2:4.17.12+dfsg-0+deb12u1
ii  libsss-idmap0 2.8.2-4
ii  libtalloc22.4.0-f2
ii  libtevent00.14.1-1
ii  samba-libs2:4.17.12+dfsg-0+deb12u1
ii  sssd-ad-common2.8.2-4
ii  sssd-common   2.8.2-4
ii  sssd-krb5-common  2.8.2-4

sssd-ad recommends no packages.

Versions of packages sssd-ad suggests:
ii  adcli  0.9.1-2

-- no debconf information

Bug#1060161: apt install -V sometimes does not show a version while it knows the version

[Witold Baryluk]

Package: apt
Version: 2.7.7
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com


Trying to install wine from winehq, on debian testing. No issue with
that, but got an interesting result with -V:

...
...
Suggested packages:
   libcurl4-doc (8.5.0-2)
   libgnutls28-dev (3.8.2-1)
   libidn-dev (1.41-1)
   libkrb5-dev (1.20.1-5)
   libldap2-dev (2.5.13+dfsg-5)
   librtmp-dev (2.4+20151223.gitfa8646d.1-2+b2)
   libssh2-1-dev (1.11.0-4)
   gdbm-l10n:i386
   hplip (3.22.10+dfsg0-4)
   hplip:i386 (3.22.10+dfsg0-4)
   libtap-harness-archive-perl (0.18-4)
Recommended packages:
   sane-airscan (0.99.27-1+b1)
   libodbc1
   libtiff5
   libodbc1:i386
   libtiff5:i386
The following packages will be REMOVED:
   sane-airscan (0.99.27-1+b1)
   wine


I can understand that apt does not always show exact version in
Suggested and Recommended, because these packages might not even exist,
and version might complexly depend whetever it is going to be installed
or not, some of them might conflict with each other, and in general
could be costly to compute.


But, REMOVED section should clear, because it should show the currently 
installed version:

user@debian:~$ dpkg -l wine
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   VersionArchitecture Description
+++-==-==--===
ii  wine   8.0.1~repack-3 all  Windows API implementation - 
standard suite


So, no idea why it is not showing version in the case of wine.


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

Kernel: Linux 6.7.0-rc4 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: 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)

Versions of packages apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.3
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.7.7
ii  libc6   2.37-13
ii  libgcc-s1   13.2.0-9
ii  libgnutls30 3.8.2-1
ii  libseccomp2 2.5.4-2+b1
ii  libstdc++6  13.2.0-9
ii  libsystemd0 255.2-3

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc 
ii  dpkg-dev1.22.2
ii  gnupg   2.2.40-1.1
ii  powermgmt-base  1.37
ii  synaptic0.91.3

-- no debconf information

Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1

[Russ Allbery]

Christoph Biedl  writes:

> * Omitting the hash declaration is not an option either, perl-nocem
>   fails then.

I'm somewhat surprised by this, as my impression was that these Hash lines
are optional and GnuPG did the right thing if they were omitted entirely
(although you do still need a blank line).  I have not looked into this in
detail, but I thought the hash algorithm was also present in metadata
inside the signature itself.  This is essentially required for the main
use case of PGP::Sign, Usenet control messages, since the syntax of the
X-PGP-Sig header has nowhere to put this metadata and thus it is always
lost.

perl-nocem itself doesn't seem to care and just copies the whole input
into a temporary file for GnuPG.  What's the nature of the failure?  Is
GnuPG failing to validate the resulting file if the hash algorithm is
omitted?

-- 
Russ Allbery (r...@debian.org)  

Bug#1060160: pam: install into /usr (DEP17 M2)

[Chris Hofstaedtler]

Source: pam
Version: 1.5.2-9.1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
X-Debbugs-CC: helm...@debian.org

Please find a patch attached to have PAM install its files into
/usr/{lib,sbin}, instead of /{lib,sbin}, for the currently ongoing
Debian UsrMerge effort [1].
src:pam is relevant now because its part of the "bootstrap set", and
needs to be converted before base-files can be modified, which we'd
like to do soon.

The patch also adds two simple, superficial autopkgtests to compile
and link a PAM module and a PAM client. They seemed helpful in
validating the change.

Please upload to experimental at your earliest convenience, to give
this a wider audience. Additional reviews and tests are obviously
also welcome.

If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru pam-1.5.2/debian/changelog pam-1.5.2/debian/changelog
--- pam-1.5.2/debian/changelog	2023-10-24 19:38:53.0 +0200
+++ pam-1.5.2/debian/changelog	2024-01-06 12:57:21.0 +0100
@@ -1,3 +1,14 @@
+pam (1.5.2-9.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install into /usr/{lib,sbin} instead of /{lib,sbin}. Assumes
+usrmerge aliasing symlinks are in place since bookworm to keep
+compatibility with PAM modules still installing into /lib.
+(DEP17 M2) (Closes: #-1).
+  * Update lintian override for setgid binary.
+
+ -- Chris Hofstaedtler   Sat, 06 Jan 2024 12:57:21 +0100
+
 pam (1.5.2-9.1) unstable; urgency=medium
 
   * Non-maintainer upload acked by Sam Hartman.
diff -Nru pam-1.5.2/debian/libpam0g-dev.install pam-1.5.2/debian/libpam0g-dev.install
--- pam-1.5.2/debian/libpam0g-dev.install	2023-10-24 17:19:43.0 +0200
+++ pam-1.5.2/debian/libpam0g-dev.install	2024-01-06 12:57:21.0 +0100
@@ -1,4 +1,4 @@
 #!/usr/bin/dh-exec
 usr/include/security/*
-lib/${DEB_HOST_MULTIARCH}/*.a		usr/lib/${DEB_HOST_MULTIARCH}
-lib/${DEB_HOST_MULTIARCH}/pkgconfig/*.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
+usr/lib/${DEB_HOST_MULTIARCH}/*.a		usr/lib/${DEB_HOST_MULTIARCH}
+usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/*.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
diff -Nru pam-1.5.2/debian/libpam0g-dev.links pam-1.5.2/debian/libpam0g-dev.links
--- pam-1.5.2/debian/libpam0g-dev.links	2023-10-24 17:19:43.0 +0200
+++ pam-1.5.2/debian/libpam0g-dev.links	2024-01-06 12:57:21.0 +0100
@@ -1,4 +1,4 @@
 #!/usr/bin/dh-exec
-/lib/${DEB_HOST_MULTIARCH}/libpam.so.0 usr/lib/${DEB_HOST_MULTIARCH}/libpam.so
-/lib/${DEB_HOST_MULTIARCH}/libpamc.so.0 usr/lib/${DEB_HOST_MULTIARCH}/libpamc.so
-/lib/${DEB_HOST_MULTIARCH}/libpam_misc.so.0 usr/lib/${DEB_HOST_MULTIARCH}/libpam_misc.so
+/usr/lib/${DEB_HOST_MULTIARCH}/libpam.so.0 usr/lib/${DEB_HOST_MULTIARCH}/libpam.so
+/usr/lib/${DEB_HOST_MULTIARCH}/libpamc.so.0 usr/lib/${DEB_HOST_MULTIARCH}/libpamc.so
+/usr/lib/${DEB_HOST_MULTIARCH}/libpam_misc.so.0 usr/lib/${DEB_HOST_MULTIARCH}/libpam_misc.so
diff -Nru pam-1.5.2/debian/libpam0g.install pam-1.5.2/debian/libpam0g.install
--- pam-1.5.2/debian/libpam0g.install	2023-10-24 17:19:43.0 +0200
+++ pam-1.5.2/debian/libpam0g.install	2024-01-06 12:57:21.0 +0100
@@ -1 +1 @@
-lib/*/lib*.so.*
+usr/lib/*/lib*.so.*
diff -Nru pam-1.5.2/debian/libpam-modules-bin.install pam-1.5.2/debian/libpam-modules-bin.install
--- pam-1.5.2/debian/libpam-modules-bin.install	2023-10-24 17:19:43.0 +0200
+++ pam-1.5.2/debian/libpam-modules-bin.install	2024-01-06 12:57:21.0 +0100
@@ -1,9 +1,9 @@
-sbin/unix_chkpwd	sbin
-sbin/unix_update	sbin
-sbin/mkhomedir_helper	sbin
-sbin/pam_namespace_helper
-sbin/pwhistory_helper
-sbin/pam_timestamp_check	usr/sbin
-sbin/faillock usr/sbin
+usr/sbin/unix_chkpwd
+usr/sbin/unix_update
+usr/sbin/mkhomedir_helper
+usr/sbin/pam_namespace_helper
+usr/sbin/pwhistory_helper
+usr/sbin/pam_timestamp_check
+usr/sbin/faillock
 modules/pam_faillock/faillock.8 usr/share/man/man8
 usr/lib/systemd/system/pam_namespace.service
diff -Nru pam-1.5.2/debian/libpam-modules-bin.lintian-overrides pam-1.5.2/debian/libpam-modules-bin.lintian-overrides
--- pam-1.5.2/debian/libpam-modules-bin.lintian-overrides	2023-10-24 17:19:43.0 +0200
+++ pam-1.5.2/debian/libpam-modules-bin.lintian-overrides	2024-01-06 12:57:21.0 +0100
@@ -1,2 +1,2 @@
 # yes, we know it's sgid, that's the whole point...
-libpam-modules-bin: setgid-binary *sbin/unix_chkpwd* 2755 root/shadow
+libpam-modules-bin: elevated-privileges 2755 root/shadow [usr/sbin/unix_chkpwd]
diff -Nru pam-1.5.2/debian/libpam-modules.install pam-1.5.2/debian/libpam-modules.install
--- pam-1.5.2/debian/libpam-modules.install	2023-10-24 17:19:43.0 +0200
+++ pam-1.5.2/debian/libpam-modules.install	2024-01-06 12:57:21.0 +0100
@@ -1,3 +1,3 @@
 etc/security/*		etc/security
-lib/*/security/*.so
+usr/lib/*/security/*.so
 

Bug#1025099: plocate: autofs pruning doesn't seem to work

[Steinar H. Gunderson]

On Wed, Nov 30, 2022 at 12:09:56AM +0100, Steinar H. Gunderson wrote:
> Most of this logic is inherited from mlocate's updatedb, though not all.
> It may be fixable or it may not; I'd really need to check. But it really
> sounds like one should be able to stat() something without bad things
> happening :-) I guess as a workaround, you can ask systemd to sandbox away
> the mount for updatedb?

Hi,

plocate 1.1.21 doesn't fully fix this, but it gives you a new possible
workaround; if you add the path (/mnt/storage in your case) to PRUNEPATHS,
updatedb won't be entering it.

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

Bug#1058887: linux-image-6.5.0-5-amd64: impossible to switch off iwlwifi adaptor

[Salvatore Bonaccorso]

Hi Jean-Marc,

On Sat, Jan 06, 2024 at 03:01:10PM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> The issue should be fixed with
> https://git.kernel.org/linus/400f6ebbc175286576c7f7fddf3c347d09d12310
> . Can you check that commit on top of the most current version in
> unstable to confirm?

Let me be a bit more specific: This is about testing the attached
patch with help of
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
to build a kernel image with the patch applied, to confirm if it fixes
the issue. Though I'm almost sure that this is the same issue.

Regards,
Salvatore
From: Johannes Berg 
Date: Fri, 15 Dec 2023 11:13:34 +0100
Subject: wifi: iwlwifi: pcie: don't synchronize IRQs from IRQ
Origin: https://git.kernel.org/linus/400f6ebbc175286576c7f7fddf3c347d09d12310
Bug-Debian: https://bugs.debian.org/1058887

On older devices (before unified image!) we can end up calling
stop_device from an rfkill interrupt. However, in stop_device
we attempt to synchronize IRQs, which then of course deadlocks.

Avoid this by checking the context, if running from the IRQ
thread then don't synchronize. This wouldn't be correct on a
new device since RSS is supported, but older devices only have
a single interrupt/queue.

Fixes: 37fb29bd1f90 ("wifi: iwlwifi: pcie: synchronize IRQs before NAPI")
Reviewed-by: Miri Korenblit 
Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Kalle Valo 
Link: https://msgid.link/20231215111335.59aab00baed7.Iadfe154d6248e7f9dfd69522e5429dbbd72925d7@changeid
---
 .../net/wireless/intel/iwlwifi/pcie/internal.h  |  4 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c|  8 
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 17 +
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
index 56def20374f3..7805a42948af 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -770,7 +770,7 @@ static inline void iwl_enable_rfkill_int(struct iwl_trans *trans)
 	}
 }
 
-void iwl_pcie_handle_rfkill_irq(struct iwl_trans *trans);
+void iwl_pcie_handle_rfkill_irq(struct iwl_trans *trans, bool from_irq);
 
 static inline bool iwl_is_rfkill_set(struct iwl_trans *trans)
 {
@@ -817,7 +817,7 @@ static inline bool iwl_pcie_dbg_on(struct iwl_trans *trans)
 	return (trans->dbg.dest_tlv || iwl_trans_dbg_ini_valid(trans));
 }
 
-void iwl_trans_pcie_rf_kill(struct iwl_trans *trans, bool state);
+void iwl_trans_pcie_rf_kill(struct iwl_trans *trans, bool state, bool from_irq);
 void iwl_trans_pcie_dump_regs(struct iwl_trans *trans);
 
 #ifdef CONFIG_IWLWIFI_DEBUGFS
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index bc6a9f861711..07931c2db494 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1783,7 +1783,7 @@ static u32 iwl_pcie_int_cause_ict(struct iwl_trans *trans)
 	return inta;
 }
 
-void iwl_pcie_handle_rfkill_irq(struct iwl_trans *trans)
+void iwl_pcie_handle_rfkill_irq(struct iwl_trans *trans, bool from_irq)
 {
 	struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
 	struct isr_statistics *isr_stats = _pcie->isr_stats;
@@ -1807,7 +1807,7 @@ void iwl_pcie_handle_rfkill_irq(struct iwl_trans *trans)
 	isr_stats->rfkill++;
 
 	if (prev != report)
-		iwl_trans_pcie_rf_kill(trans, report);
+		iwl_trans_pcie_rf_kill(trans, report, from_irq);
 	mutex_unlock(_pcie->mutex);
 
 	if (hw_rfkill) {
@@ -1947,7 +1947,7 @@ irqreturn_t iwl_pcie_irq_handler(int irq, void *dev_id)
 
 	/* HW RF KILL switch toggled */
 	if (inta & CSR_INT_BIT_RF_KILL) {
-		iwl_pcie_handle_rfkill_irq(trans);
+		iwl_pcie_handle_rfkill_irq(trans, true);
 		handled |= CSR_INT_BIT_RF_KILL;
 	}
 
@@ -2370,7 +2370,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void *dev_id)
 
 	/* HW RF KILL switch toggled */
 	if (inta_hw & MSIX_HW_INT_CAUSES_REG_RF_KILL)
-		iwl_pcie_handle_rfkill_irq(trans);
+		iwl_pcie_handle_rfkill_irq(trans, true);
 
 	if (inta_hw & MSIX_HW_INT_CAUSES_REG_HW_ERR) {
 		IWL_ERR(trans,
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 92253260f568..d10208075ae5 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1082,7 +1082,7 @@ bool iwl_pcie_check_hw_rf_kill(struct iwl_trans *trans)
 	report = test_bit(STATUS_RFKILL_OPMODE, >status);
 
 	if (prev != report)
-		iwl_trans_pcie_rf_kill(trans, report);
+		iwl_trans_pcie_rf_kill(trans, report, false);
 
 	return hw_rfkill;
 }
@@ -1237,7 +1237,7 @@ static void iwl_pcie_init_msix(struct iwl_trans_pcie *trans_pcie)
 	trans_pcie->hw_mask = trans_pcie->hw_init_mask;
 }
 
-static void _iwl_trans_pcie_stop_device(struct iwl_trans *trans)
+static void 

Bug#1060159: amavisd-new: Owner and group of /var/lib/amavis/.spamassassin/bayes_toks changes

[Lupe Christoph]

Package: amavisd-new
Version: 1:2.11.1-5
Severity: important
X-Debbugs-Cc: l...@lupe-christoph.de

Sometimes the owner and group of /var/lib/amavis/.spamassassin/bayes_toks 
change to root:root. This makes the cronjob fail:

Date: Sat,  6 Jan 2024 15:18:04 +0100 (CET)
From: Cron Daemon 
To: ama...@octomain.octogon.de
Subject: Cron  test -e /usr/sbin/amavisd-new-cronjob && 
/usr/sbin/amavisd-new-cronjob sa-sync

bayes: cannot open bayes databases /var/lib/amavis/.spamassassin/bayes_* R/O: 
tie failed: Permission denied
bayes: cannot open bayes databases /var/lib/amavis/.spamassassin/bayes_* R/O: 
tie failed: Permission denied

Manually restting to amavis:amavis allows the cronjob to run.

I have no idea what is changing owner and group, especially since the other 
files in /var/lib/amavis/.spamassassin/ are unchanged:

# ls -l /var/lib/amavis/.spamassassin/
total 19712
-rw-rw-rw- 1 amavis amavis 20406272 Jan  6 14:58 bayes_seen
-rw--- 1 root   root5484544 Jan  6 14:58 bayes_toks
-rw--- 1 amavis amavis  2539520 Jan 25  2019 bayes_toks.expire4427
-rw-r--r-- 1 amavis amavis 1869 Jul 13  2014 user_prefs

The change happened at the same time as the last access:

# ls -l --full-time /var/lib/amavis/.spamassassin/bayes_toks
-rw--- 1 root root 5484544 2024-01-06 14:58:43.988842231 +0100 
/var/lib/amavis/.spamassassin/bayes_toks
# ls -lc --full-time /var/lib/amavis/.spamassassin/bayes_toks
-rw--- 1 root root 5484544 2024-01-06 14:58:43.988842231 +0100 
/var/lib/amavis/.spamassassin/bayes_toks

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

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

Versions of packages amavisd-new depends on:
ii  adduser3.118+deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  file   1:5.39-3+deb11u1
ii  init-system-helpers1.60
pn  libarchive-tar-perl
ii  libarchive-zip-perl1.68-1
ii  libberkeleydb-perl 0.64-1+b1
ii  libconvert-tnef-perl   0.18-1.1
ii  libconvert-uulib-perl  1:1.5~dfsg-1+b3
pn  libdigest-md5-perl 
ii  libio-stringy-perl 2.111-3
ii  libmail-dkim-perl  1.20200907-1
ii  libmailtools-perl  2.21-1
pn  libmime-base64-perl
ii  libmime-tools-perl 5.509-1
ii  libnet-libidn-perl 0.12.ds-3+b3
ii  libnet-server-perl 2.009-2
ii  libnet-snmp-perl   6.0.1-6
ii  libunix-syslog-perl1.1-3+b3
ii  lsb-base   11.1.0
ii  pax1:20201030-1
ii  perl [libtime-hires-perl]  5.32.1-4+deb11u2

Versions of packages amavisd-new recommends:
ii  altermime 0.3.10-12
ii  libnet-patricia-perl  1.22-1+b7
pn  ripole

Versions of packages amavisd-new suggests:
ii  apt-listchanges  3.24
pn  arj  
pn  cabextract   
ii  clamav   0.103.10+dfsg-0+deb11u1
ii  clamav-daemon0.103.10+dfsg-0+deb11u1
ii  cpio 2.13+dfsg-7.1~deb11u1
pn  dspam
pn  lhasa
ii  libauthen-sasl-perl  2.1600-1.1
ii  libdbi-perl  1.643-3+b1
ii  libmail-dkim-perl1.20200907-1
pn  libnet-ldap-perl 
pn  libsnmp-perl 
pn  libzeromq-perl   
pn  lzop 
pn  nomarch  
ii  p7zip16.02+dfsg-8
pn  rpm  
ii  spamassassin 3.4.6-1
pn  unrar

-- Configuration Files:
/etc/amavis/conf.d/15-content_filter_mode changed:
use strict;
@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
1;  # ensure a defined return

/etc/amavis/conf.d/50-user changed:
use strict;
$max_servers  = 4;   # number of pre-forked children
$final_virus_destiny  = D_PASS;
undef $virus_quarantine_to;
undef $virus_admin;
$final_banned_destiny = D_PASS;
undef $banned_quarantine_to;
undef $banned_admin;
$final_bad_header_destiny = D_PASS;
undef $bad_header_quarantine_to;
undef $bad_header_admin;
$final_spam_destiny   = D_PASS;
undef $spam_quarantine_to;
undef $spam_admin;
$sa_tag2_level_deflt = 5.0;   # add 'spam detected' headers at that level
$sa_kill_level_deflt = 9; # triggers spam evasive actions
$sa_dsn_cutoff_level = 0; # spam level beyond which a DSN is not sent
undef $sa_spam_subject_tag;
@local_domains_acl = qw(octogon.de octogon-gmbh.de med-data.de 
toscanatradizionale.de);
$recipient_delimiter = '+';
@addr_extension_spam_maps = ('spam');
@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, 

Bug#1060008: sioyek: segmentation fault with LANG=pt_BR.UTF-8

[Hermógenes Oliveira]

Hi.

>> Message: Process 8174 (sioyek) of user 1000 dumped core.
>>
>>  Module libudev.so.1 from deb systemd-255.2-3.amd64
>>  Module libsystemd.so.0 from deb systemd-255.2-3.amd64
>>  Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
>>  Stack trace of thread 8174:
>>  #0  0x7f9c5755e773 
>> _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_assignERKS4_ 
>> (libstdc++.so.6 + 0x15e773)
>>  #1  0x55fff30c0f40 n/a (sioyek + 0xd4f40)

> This location in the sioyek binary points to line 1589 or 1590 in
> pdf_viewer/main_widget.cpp in the function
> MainWidget::update_current_history_index, but I'm unable to recreate the
> crash myself.

Oh, I see. Something about my local environment then.

> Does the crash happen after a specific sequence of events? Or at random?
> Are you able to reproduce it yourself?

It happens consistently at launch.

hermogenes@avalon:~$ sioyek 
default_config_path: /etc/sioyek/prefs.config
default_keys_path: /etc/sioyek/keys.config
user_config_path: [ 0 ] 
/usr/share/desktop-base/kf5-settings/sioyek/prefs_user.config
user_config_path: [ 1 ] /etc/xdg/sioyek/prefs_user.config
user_config_path: [ 2 ] 
/home/hermogenes/.config/kdedefaults/sioyek/prefs_user.config
user_config_path: [ 3 ] /home/hermogenes/.config/sioyek/prefs_user.config
user_keys_path: [ 0 ] 
/usr/share/desktop-base/kf5-settings/sioyek/keys_user.config
user_keys_path: [ 1 ] /etc/xdg/sioyek/keys_user.config
user_keys_path: [ 2 ] 
/home/hermogenes/.config/kdedefaults/sioyek/keys_user.config
user_keys_path: [ 3 ] /home/hermogenes/.config/sioyek/keys_user.config
database_file_path: /home/hermogenes/.local/share/sioyek/test.db
local_database_file_path: /home/hermogenes/.local/share/sioyek/local.db
global_database_file_path: /home/hermogenes/.local/share/sioyek/shared.db
tutorial_path: /usr/share/sioyek/tutorial.pdf
last_opened_file_address_path: 
/home/hermogenes/.local/share/sioyek/last_document_path.txt
shader_path: /usr/share/sioyek/shaders
Creating shared memory block...
Shared memory created: this is the primary application.
Starting IPC server...
IPC server started.
Falha de segmentação (imagem do núcleo gravada)

I created a fresh user account for which the problem indeed does not appear. 
The account experiencing the crash doesn't seem to contain anything unusual in 
the configuration and database files:

 /home/hermogenes/.config/kdedefaults/sioyek/prefs_user.config doesn't exist
/home/hermogenes/.config/sioyek/prefs_user.config also doesn't exist
/home/hermogenes/.config/kdedefaults/sioyek/keys_user.config doesn't exist
/home/hermogenes/.config/sioyek/keys_user.config also doesn't exist

hermogenes@avalon:~$ sqlite3 .local/share/sioyek/local.db 
SQLite version 3.44.2 2023-11-24 11:41:44
Enter ".help" for usage hints.
sqlite> .tables
document_hash
sqlite> select * from document_hash;
1|/usr/share/sioyek/tutorial.pdf|2aae0eaa25c30153bffb37bddb925d26
2|/home/hermogenes/Nuvem/Work/doktorarbeit/PTS3-slides.pdf|ad2fed9472ce10ac7898f9b6806825ad
3|/home/hermogenes/Arquivos/paratodxs/forallxyyc.pdf|2a7b0c72937ecdc019a2f6ef769b76a6
4|/home/hermogenes/Downloads/2209.00626.pdf|5b3eca6ef422479e5e251336bd885ff3
sqlite> .quit

hermogenes@avalon:~$ sqlite3 .local/share/sioyek/shared.db 
SQLite version 3.44.2 2023-11-24 11:41:44
Enter ".help" for usage hints.
sqlite> .tables
bookmarks highlightslinks marks opened_books
sqlite> select * from bookmarks;
sqlite> select * from highlights;
sqlite> select * from marks;
1|2a7b0c72937ecdc019a2f6ef769b76a6|/|1616.0
sqlite> select * from opened_books;
2|2aae0eaa25c30153bffb37bddb925d26|1.0|0.0|216.0|2023-03-04 21:14:23
4|ad2fed9472ce10ac7898f9b6806825ad|3.0|0.0|582.0|2023-04-15 15:41:23
7|2a7b0c72937ecdc019a2f6ef769b76a6|1.0|0.0|3835.0|2023-12-09 20:25:24
15|5b3eca6ef422479e5e251336bd885ff3|0.897059|0.0|400.0|2024-01-04 16:24:12
sqlite> .quit

hermogenes@avalon:~$ sqlite3 .local/share/sioyek/test.db 
SQLite version 3.44.2 2023-11-24 11:41:44
Enter ".help" for usage hints.
sqlite> .tables
bookmarks  highlights marks
document_hash  links  opened_books 
sqlite> select * from bookmarks;
sqlite> select * from document_hash;
sqlite> select * from highlights;
sqlite> select * from marks;
sqlite> select * from links;
sqlite> select * from opened_books;
sqlite> .quit

After I moved local.db out of the way, sioyek launched successfully. But even 
after a moved it back in place, it continued to launch successfully.

hermogenes@avalon:~$ mv .local/share/sioyek/test.db ~/
hermogenes@avalon:~$ sioyek 
default_config_path: /etc/sioyek/prefs.config
default_keys_path: /etc/sioyek/keys.config
user_config_path: [ 0 ] 
/usr/share/desktop-base/kf5-settings/sioyek/prefs_user.config
user_config_path: [ 1 ] /etc/xdg/sioyek/prefs_user.config
user_config_path: [ 2 ] 
/home/hermogenes/.config/kdedefaults/sioyek/prefs_user.config
user_config_path: [ 3 

Bug#1060158: warzone2100: cannot connect to lobby

[Pti Zoom]

Package: warzone2100
Version: 4.4.2-1
Severity: normal

Dear Maintainer,

using the wrapper 

"...
exec bwrap --bind $HOME/.local/share/warzone2100 $HOME/.local/share/warzone2100 
--bind-try /run/user/$UID/pulse /run/user/$UID/pulse --bind-try 
/run/user/$UID/wayland-0 /run/user/$UID/wayland-0 --bind-try 
/run/user/$UID/wayland-0.lock /run/user/$UID/wayland-0.lock --ro-bind /usr /usr 
--ro-bind /etc /etc --symlink usr/bin /bin --symlink usr/lib64 /lib64 --symlink 
usr/lib /lib --proc /proc --dev /dev --unshare-pid --dev-bind /dev/dri /dev/dri 
--ro-bind-try $HOME/.pulse $HOME/.pulse --ro-bind-try $XAUTHORITY $XAUTHORITY 
--ro-bind /sys /sys /usr/games/warzone2100.real
.."

the name resolution fails... then cannot play networked game.


I agree to put this game inside a sand box... it looks pretty security dodgy!
but I have this error "...Failed to connect PipeWire event context..."
which could I think lead to this domain name resolution failure ?:

"...
info|16:12:06: [urlSelectSSLBackend:1322] cURL has no available thread-safe 
SSL backends to configure
info|16:12:06: [urlSelectSSLBackend:1325] (Ignored backend: 1 (build did 
not permit thread-safe configuration)
info|16:12:06: [urlSelectSSLBackend:1325] (Ignored backend: 2 (build did 
not permit thread-safe configuration)
info|16:12:06: [wzChangeFullscreenDisplayMode:2168] Changing fullscreen 
mode to [0] 640x480
info|16:12:06: [createGLContext:185] Requested OpenGL ES 3.0 context
info|16:12:06: [initGLContext:3422] OpenGL Vendor: Mesa
info|16:12:06: [initGLContext:3425] OpenGL Renderer: NV136
info|16:12:06: [initGLContext:3428] OpenGL Version: OpenGL ES 3.2 Mesa 
23.3.2-2
info|16:12:06: [initGLContext:3641] Success
info|16:12:06: [_initialize:3232]   * Instanced rendering support was 
detected
[ALSOFT] (EE) Failed to connect PipeWire event context (errno: 112)
info|16:12:14: [lookupRatingAsync:145] Requesting 
"https://wz2100-autohost.net/rating/; for player 0 (ptizoom) 
(25af27c3372f42cc40aa12ba74e51641ed93ac4e37e2aecdc65a1ae6f22e59bd)
error   |16:12:18: [NETenumerateGames:4695] Cannot resolve hostname 
"lobby.wz2100.net": Resource temporarily unavailable
last message repeated 2 times
..."


something must be missing in the setup of bwrap or in the users environment?

help please!





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

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

Versions of packages warzone2100 depends on:
ii  bubblewrap  0.8.0-2
ii  libasound2  1.2.10-3
ii  libc6   2.37-13
ii  libcurl3-gnutls 8.5.0-2
ii  libdecor-0-00.2.1-1
ii  libdrm2 2.4.117-1
ii  libfreetype62.13.0+dfsg-1
ii  libfribidi0 1.0.13-3
ii  libgbm1 23.3.2-2
ii  libgcc-s1   13.2.0-9
ii  libharfbuzz0b   8.0.1-1
ii  libminiupnpc17  2.2.5-1
ii  libogg0 1.3.5-3
ii  libopenal1  1:1.23.1-4
ii  libopus01.4-1
ii  libphysfs1  3.0.2-6
ii  libpng16-16 1.6.40-3
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsamplerate0  0.2.2-4
ii  libsodium23 1.0.18-1
ii  libsqlite3-03.44.2-1
ii  libstdc++6  13.2.0-9
ii  libtheora0  1.1.1+dfsg.1-16.1+b1
ii  libvorbis0a 1.3.7-1
ii  libvorbisfile3  1.3.7-1
ii  libwayland-client0  1.22.0-2.1
ii  libwayland-cursor0  1.22.0-2.1
ii  libwayland-egl1 1.22.0-2.1
ii  libx11-62:1.8.7-1
ii  libxcursor1 1:1.2.1-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxi6  2:1.8-1+b1
ii  libxkbcommon0   1.6.0-1
ii  libxrandr2  2:1.5.2-2+b1
ii  libxss1 1:1.2.3-1
ii  warzone2100-data4.4.2-1
ii  zlib1g  1:1.3.dfsg-3

Versions of packages warzone2100 recommends:
ii  warzone2100-music  4.4.2-1

warzone2100 suggests no packages.

-- no debconf information

Bug#1058698: mozilla-devscripts should be removed from testing/unstable

[Mechtilde Stehmann]

Hello,

as an information for the archive:

to build the webext packages, you didn't need mozilla-devscripts.

I used it to build the orig.tar.gz from the xpi in former time.

But it is not necessary any more

Regards

MEchtilde

Am 15.12.23 um 10:39 schrieb Carsten Schoenert:

Hello Mechtilde,

Am Thu, Dec 14, 2023 at 07:09:16PM +0100 schrieb Mechtilde:

Hello Mathias,

thanks for the hint,

At this time mozilla-devscript is needed when you want to build
Mozilla-AddOns from the *.xpi.

So we need to elaborate another way to do it.


I've dropped mozilla-devscripts as an dependency for thunderbird long
ago.
To get the l10n XPI files creatable I picked up the main part of
mozilla-devscripts, the shell script xpi-pack.sh, and placed it within
the debian/ folder.

https://salsa.debian.org/mozilla-team/thunderbird/-/commit/b31360b05e048826571245a2fda26d56592da435

We call this shell script then directly in debian/rules, it's quite
simple and straight forward to use.

https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/sid/debian/rules#L134

I think shipping this shell script now in only a few source packages is
acceptable, otherwise we would need to fix mozilla-devscripts with a bit
effort for not really big gain.

Another option could be to move the XPI package build functionaliy into
some debhelper package, but I haven't looked really seriously into any
option.

Regards
Carsten

Bug#1060156: acl: move files to /usr for DEP17

[cacin]

Source: acl
Followup-For: Bug #1060156

better patch attached
---
 debian/acl-udeb.install |  2 +-
 debian/acl.install  |  2 +-
 debian/acl.postinst | 12 
 debian/acl.postrm   | 12 
 debian/rules|  3 ---
 5 files changed, 2 insertions(+), 29 deletions(-)
 delete mode 100644 debian/acl.postinst
 delete mode 100644 debian/acl.postrm

diff --git a/debian/acl-udeb.install b/debian/acl-udeb.install
index e660fd9..c703cf8 100644
--- a/debian/acl-udeb.install
+++ b/debian/acl-udeb.install
@@ -1 +1 @@
-bin/
+usr/bin/
diff --git a/debian/acl.install b/debian/acl.install
index 519c581..3d70f27 100644
--- a/debian/acl.install
+++ b/debian/acl.install
@@ -1,4 +1,4 @@
-bin/
+usr/bin/
 usr/share/locale/
 usr/share/man/man1/
 usr/share/man/man5/
diff --git a/debian/acl.postinst b/debian/acl.postinst
deleted file mode 100644
index ea33a8d..000
--- a/debian/acl.postinst
+++ /dev/null
@@ -1,12 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'configure' ]; then
-  for file in chacl getfacl setfacl; do
-if [ ! -e /usr/bin/$file ]; then
-  ln -s /bin/$file /usr/bin/$file
-fi
-  done
-fi
-
-#DEBHELPER#
diff --git a/debian/acl.postrm b/debian/acl.postrm
deleted file mode 100644
index 8ec03fc..000
--- a/debian/acl.postrm
+++ /dev/null
@@ -1,12 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'remove' ]; then
-  for file in chacl getfacl setfacl; do
-if [ -L /usr/bin/$file ]; then
-  rm /usr/bin/$file
-fi
-  done
-fi
-
-#DEBHELPER#
diff --git a/debian/rules b/debian/rules
index 9f7759e..fb3c415 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,9 +18,6 @@ endif
 %:
dh $@
 
-override_dh_auto_configure:
-   dh_auto_configure -- --bindir=/bin
-
 override_dh_auto_test:
 ifeq ($(TESTS_FLAKY),yes)
@echo "Notice: Running tests in flaky mode, errors will be ignored."
-- 
2.43.0

Bug#1060157: librust-asn1-dev: please update to a more recent version

[Jérémy Lal]

Package: librust-asn1-dev
Version: 0.12.2
Severity: wishlist

Hi,

a more recent version of librust-asn1-dev (>= 0.15) is needed
to be able to update to python3-cryptography (>= 0.41) which
in turn is required by some other package.


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

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

Bug#1060155: dbus: please usrmerge in unstable

[Chris Hofstaedtler]

Source: dbus
Version: 1.14.10-3
User: helm...@debian.org
Usertag: dep17m2


Hi Simon, Utopia Maintainers,

I was about to send a patch for dbus to move libdbus into /usr, but
then noticed it's already done in experimental.

Do you know about any open blockers to apply this in unstable? If
not, could I ask you to upload to unstable, please?

(This bug also serves as a useful tracking bug.)

Thanks,
Chris

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Johannes Schauer Marin Rodrigues]

Quoting Paul Gevers (2024-01-06 13:20:11)
> Thanks for being elaborate in your reply, it matches what I was thinking. (I
> wasn't aware of the other examples though).

there are certainly more examples. For example I maintain the package box64
which allows running amd64 binaries on arm64 but requires amd64 libc to
operate. Because pkg:amd64 doesn't work for britney, I used this:

Depends: libgcc-s1:amd64 | libgcc-s1-amd64-cross, libstdc++6:amd64 | 
libstdc++6-amd64-cross

I had to patch the software to also look into the paths that
libgcc-s1-amd64-cross and libstdc++6-amd64-cross use to make this work. Those
two packages are Architecture:all but they do contain amd64 shared libraries.
Helmut probably has a much better idea whether, in an ideal world, Arch:all
packages like libgcc-s1-amd64-cross should go away and be replaced by
corresponding architecture-qualified dependencies on the architecture-specific
libraries.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1028613: [Pkg-zfsonlinux-devel] Bug#1028613: libpam-zfs: zfs_umount failed on closing ssh session

[Aron Xu]

Hi,

On Sat, Jan 6, 2024 at 1:27 AM 陈 晟祺  wrote:
>
>
> You may want to try (as workaround):
>
> 1. skip pam_zfs_key when pam_systemd is used, as #12430 suggests; or,
> 2. use `zfs allow` to grant `mount` permission to yourself.
>

I'd like to mention that zfs-allow cannot grant mount/umount
permission on Linux as stated in zfs-allow(8):
   Delegations are supported under Linux with the exception of
   mount, unmount, mountpoint, canmount, rename, and share.
   These permissions cannot be delegated because the Linux
   mount(8) command restricts modifications of the global
   namespace to the root user.

A way to work this around could be to allow zfs commands through
/etc/sudoers.d/zfs configuration, which is commented out on Debian by
default.

Thanks,
Aron

Bug#1060156: acl: move files to /usr for DEP17

[cacin]

Source: acl
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Dear Maintainer,

I attach a patch to make sure all files are moved to /usr/bin and instead of 
/bin

---
 debian/acl-udeb.install |  2 +-
 debian/acl.install  |  2 +-
 debian/acl.postinst | 12 
 debian/acl.postrm   | 12 
 debian/rules|  2 +-
 5 files changed, 3 insertions(+), 27 deletions(-)
 delete mode 100644 debian/acl.postinst
 delete mode 100644 debian/acl.postrm

diff --git a/debian/acl-udeb.install b/debian/acl-udeb.install
index e660fd9..c703cf8 100644
--- a/debian/acl-udeb.install
+++ b/debian/acl-udeb.install
@@ -1 +1 @@
-bin/
+usr/bin/
diff --git a/debian/acl.install b/debian/acl.install
index 519c581..3d70f27 100644
--- a/debian/acl.install
+++ b/debian/acl.install
@@ -1,4 +1,4 @@
-bin/
+usr/bin/
 usr/share/locale/
 usr/share/man/man1/
 usr/share/man/man5/
diff --git a/debian/acl.postinst b/debian/acl.postinst
deleted file mode 100644
index ea33a8d..000
--- a/debian/acl.postinst
+++ /dev/null
@@ -1,12 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'configure' ]; then
-  for file in chacl getfacl setfacl; do
-if [ ! -e /usr/bin/$file ]; then
-  ln -s /bin/$file /usr/bin/$file
-fi
-  done
-fi
-
-#DEBHELPER#
diff --git a/debian/acl.postrm b/debian/acl.postrm
deleted file mode 100644
index 8ec03fc..000
--- a/debian/acl.postrm
+++ /dev/null
@@ -1,12 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'remove' ]; then
-  for file in chacl getfacl setfacl; do
-if [ -L /usr/bin/$file ]; then
-  rm /usr/bin/$file
-fi
-  done
-fi
-
-#DEBHELPER#
diff --git a/debian/rules b/debian/rules
index 9f7759e..640759e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,7 +19,7 @@ endif
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --bindir=/bin
+   dh_auto_configure -- --bindir=/usr/bin
 
 override_dh_auto_test:
 ifeq ($(TESTS_FLAKY),yes)
-- 
2.43.0

Bug#1060154: turing: does not start at all

[Alexandre Detiste]

Package: turing
Version: 0.11~beta-4
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: Andreas Tille 

Turing does not starts at all.

$ turing 
NoneType: None
Traceback (most recent call last):
  File "/usr/share/turing/src/main.py", line 101, in 
from forms import mainwindow
  File "/usr/share/turing/src/forms/mainwindow.py", line 21, in 
import pyqode.python.backend
  File "/usr/share/turing/pyqode/python/backend/__init__.py", line 7, in 

from .workers import calltips
  File "/usr/share/turing/pyqode/python/backend/workers.py", line 179, in 

messages.ReturnWithArgsInsideGenerator,
^^
AttributeError: module 'pyflakes.messages' has no attribute 
'ReturnWithArgsInsideGenerator'


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

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

Versions of packages turing depends on:
ii  python3 3.11.4-5+b1
ii  python3-altgraph0.17.4+ds-1
ii  python3-autopep82.0.4-1
ii  python3-cycler  0.11.0-1
ii  python3-dateutil2.8.2-3
ii  python3-docutils0.20.1+dfsg-3
ii  python3-future  0.18.2-6  --> I know...
ii  python3-jedi0.18.2-1
ii  python3-kiwisolver  1.4.4-1+b2
ii  python3-macholib1.16.3+ds-1
ii  python3-matplotlib  3.6.3-1+b2
ii  python3-numpy   1:1.24.2-2
ii  python3-parso   0.8.3-1
ii  python3-pefile  2023.2.7-3
ii  python3-pep81.7.1-11
ii  python3-pyflakes3.1.0-1
ii  python3-pygments2.15.1+dfsg-1
ii  python3-pyparsing   3.1.1-1
ii  python3-pyqt5   5.15.10+dfsg-1
ii  python3-tz  2023.3.post1-2

turing recommends no packages.

turing suggests no packages.

-- no debconf information

Bug#1060150: linux-image-6.6.9-amd64: Unable to update to 6.6.9-1 version

[Salvatore Bonaccorso]

Hi,

On Sat, Jan 06, 2024 at 02:00:58PM +0100, Carlos Suérez wrote:
> Package: linux-image-6.6.9-amd64
> Version: 6.6.9-1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate
> ***
> 
> * What led up to the situation? System update failure with manual 'apt
> update' at terminal.
> * What exactly did you do (or not do) that was effective (or
> ineffective)? I have tried to install the package only
> * What was the outcome of this action? I get the same error
> * What outcome did you expect instead? Update done
> 
> 
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.6.8-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_USER
> Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages linux-image-6.6.9-amd64 depends on:
> ii initramfs-tools [linux-initramfs-tool] 0.142
> ii kmod 31-1
> ii linux-base 4.9
> 
> Versions of packages linux-image-6.6.9-amd64 recommends:
> ii apparmor 3.0.12-1+b2
> ii firmware-linux-free 20200122-3
> 
> Versions of packages linux-image-6.6.9-amd64 suggests:
> pn debian-kernel-handbook 
> ii grub-pc 2.12~rc1-12
> 
> pn linux-doc-6.6 
> 
> 
> *** Output when i try to update/install the linux-image package from 6.6.8
> to 6.6.9 ***
> 
> > /run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return
> > code 127
> > dpkg: error al procesar el paquete linux-image-6.6.9-amd64 (--configure):
> >  el subproceso instalado paquete linux-image-6.6.9-amd64 script
> > post-installatio
> > n devolvió el código de salida de error 1
> > Se encontraron errores al procesar:
> >  linux-image-6.6.9-amd64
> > E: Sub-process /usr/bin/dpkg returned an error code (1)/

Can you please provide the full log of the update, which other
packages are involved? Do you have any dkms modules packages
installed?

Regards,
Salvatore

Bug#1056042: xrayutilities ftbfs with Python 3.12

[s3v]

Dear Maintainer,

After uncertainties/3.1.7 entered in unstable, your package builds fine
in my sid chroot environment and all tests pass.

Import that triggers the failure:

  from past.builtins import basestring

was turned in:

if sys.version_info < (3,):
 from past.builtins import basestring
else:
 # Avoid importing from past in Python 3 since it utilizes the builtin
 # 'imp' module, which is deprecated as of Python 3.4, see
 # https://docs.python.org/3/library/imp.html. The 2to3 tool replaces
 # basestring with str, so that's what we effectively do here as well:
 basestring = str


Kind Regards

[1] 
https://salsa.debian.org/debian/python-uncertainties/-/commit/f9951a9e9d708c8ec38d6a0488f865d8


On Thu, 16 Nov 2023 09:57:09 +0100 Matthias Klose  wrote:
> Package: src:xrayutilities
> Version: 1.7.4-1
> Severity: important
> Tags: sid trixie
> User: debian-pyt...@lists.debian.org
> Usertags: python3.12
>
> some tests fail with:
>
> [...]
> /usr/lib/python3.12/subprocess.py:571: CalledProcessError
> - Captured stderr call
> -
> Traceback (most recent call last):
> File
> "/<>/.pybuild/cpython3_3.12_xrayutilities/build/examples/simpack_xrr_SiO2_Ru_CoFe_IrMn_Al2O3.py",
> line 20, in 
> import lmfit
> File "/usr/lib/python3/dist-packages/lmfit/__init__.py", line 38, in
> 
> from .confidence import conf_interval, conf_interval2d
> File "/usr/lib/python3/dist-packages/lmfit/confidence.py", line 10,
> in 
> from .minimizer import MinimizerException
> File "/usr/lib/python3/dist-packages/lmfit/minimizer.py", line 41, in
> 
> from .parameter import Parameter, Parameters
> File "/usr/lib/python3/dist-packages/lmfit/parameter.py", line 10, in
> 
> from uncertainties import correlated_values, ufloat
> File "/usr/lib/python3/dist-packages/uncertainties/__init__.py", line
> 225, in 
> from .core import *
> File "/usr/lib/python3/dist-packages/uncertainties/core.py", line 22,
> in 
> from past.builtins import basestring
> File "/usr/lib/python3/dist-packages/past/builtins/__init__.py", line
> 54, in 
> from past.builtins.misc import (apply, chr, cmp, execfile, intern, oct,
> File "/usr/lib/python3/dist-packages/past/builtins/misc.py", line 45,
> in 
> from imp import reload
> ModuleNotFoundError: No module named 'imp'
>
> complete build log at
> https://launchpadlibrarian.net/697894338/buildlog_ubuntu-noble-amd64.xrayutilities_1.7.4-1build2_BUILDING.txt.gz
>
>

Bug#1060153: /usr/bin/pbr: please package v6.0.0

[Alexandre Detiste]

Package: python3-pbr
Version: 5.11.1-5
Severity: normal

Please package v6.0.0 and strip-out trival usage of six.

I can provide a real .patch on request.

Greetings

(please don't me use Launchpad)

$ grep six -r
- test-requirements.txt:six>=1.12.0 # MIT
- pbr/tests/test_util.py:import six
- pbr/tests/test_util.py:from six.moves import configparser
+ pbr/tests/test_util.py:import configparser
- pbr/tests/test_util.py:ini = textwrap.dedent(six.u(ini))
+ pbr/tests/test_util.py:ini = textwrap.dedent(str(ini))
- pbr/tests/test_packaging.py:import six
- pbr/tests/test_packaging.py:'setup.py': textwrap.dedent(six.u("""\
+ pbr/tests/test_packaging.py:'setup.py': textwrap.dedent("""\  + 
handle closing parenthesis
- pbr/tests/test_packaging.py:'setup.cfg': textwrap.dedent(six.u("""\
+ pbr/tests/test_packaging.py:'setup.cfg': textwrap.dedent("""\
- pbr/sphinxext.py:from six.moves import configparser
+ pbr/sphinxext.py:import configparser
- doc/requirements.txt:six==1.12.0 # MIT


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

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

Versions of packages python3-pbr depends on:
ii  python33.11.4-5+b1
ii  python3-pkg-resources  68.1.2-2
ii  python3-setuptools 68.1.2-2
ii  python3-six1.16.0-4

python3-pbr recommends no packages.

python3-pbr suggests no packages.

-- no debconf information

Bug#1060152: python3-jupyterlab should provide jupyterlab

[Yadd]

Package: python3-jupyterlab
Severity: normal
X-Debbugs-Cc: y...@debian.org

Hi,

python3-jupyterlab provides bin/jupyterlab, then it should
"Provides: jupyterlab (= ${binary:Version})"

Bug#1058887: linux-image-6.5.0-5-amd64: impossible to switch off iwlwifi adaptor

[Salvatore Bonaccorso]

Hi

The issue should be fixed with
https://git.kernel.org/linus/400f6ebbc175286576c7f7fddf3c347d09d12310
. Can you check that commit on top of the most current version in
unstable to confirm?

Regards,
Salvatore

Bug#1057273: Possibly fixed

[Артём]

I tried this bug in kernel linux-image-6.1.0-17-amd64 (Version 6.1.69-1),
and it looks like the bug has been fixed

Bug#1013584: octave-iso2mesh: FTBFS: dh_missing: error: missing files, aborting

[Rafael Laboissière]

Control: notfixed -1 1.9.6+ds-8
Control: fixed -1 1.9.6+ds-9

* Yue Gui  [2024-01-05 22:53]:


Source: octave-iso2mesh
Version: 1.9.6+ds-7
Severity: serious
Justification: FTBFS
Tags: sid ftbfs

Dear octave-iso2mesh Maintainer,

About the issue reported, there is a solution that add "not-installed" 
file to /debian. This solution refers to Bug Report #964666. More 
details can be found in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964666 and 
https://salsa.debian.org/multimedia-team/libopenshot/-/commit/43689f7b3b058dfd0ee83dd7ff6a6bc863a02004#1823cfdb97f631de92d185f9a7ef6c1f58bc9147


The dh_missing error is caused by *.m exists in debian/tmp but is not 
installed to anywhere, so the solution is effective.I have tested it 
successfully in local. Please let me know if the solution accepted.


The "not-installed" file is in the attachment.


I went too fast and released version 1.9.6+ds-8 with eh proposed "fix" 
(adding debian/not-installed). Actually, this is not the right thing to 
do, since the files in debian/tmp/usr/share/octave/packages/ should go 
into the binary package octave-iso2mesh.


I am hereby rectifying the situation.

Best,

Rafael Laboissière