Bug#1052490: rust-async-task, build-depends on old version of rust-flume.

[Peter Green]

Package: rust-async-task
Version: 4.4.0-3
Severity: serious
Tags: patch

rust-async-task's build-dependencies are unsatisfiable in testing/unstable
due to a recent update to rust-flume.

upstream bumped the dependency with no code changes, and after adding the
patch to the Debian package and adjusting the rest of the packaging
accordingly I was able to get a succesfull build and autopkgtest run.

debdiff attached.diff -Nru rust-async-task-4.4.0/debian/changelog 
rust-async-task-4.4.0/debian/changelog
--- rust-async-task-4.4.0/debian/changelog  2023-09-10 13:43:24.0 
+
+++ rust-async-task-4.4.0/debian/changelog  2023-09-23 05:20:54.0 
+
@@ -1,3 +1,14 @@
+rust-async-task (4.4.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch 0001_update_flume.patch
++ Trivial upstream patch to bump flume depdency to 0.11
+  * Reduce context in 2001_flaky-test.patch so it will apply on top of
+0001_update_flume.patch
+  * Update build and autopkgtest dependencies for flume 0.11.
+
+ -- Peter Michael Green   Sat, 23 Sep 2023 05:20:54 +
+
 rust-async-task (4.4.0-3) unstable; urgency=medium
 
   * omit testing examples for autopkgtest without feature std;
diff -Nru rust-async-task-4.4.0/debian/control 
rust-async-task-4.4.0/debian/control
--- rust-async-task-4.4.0/debian/control2023-07-16 09:24:09.0 
+
+++ rust-async-task-4.4.0/debian/control2023-09-23 05:20:54.0 
+
@@ -7,7 +7,7 @@
  librust-async-task-4+default-dev ,
  librust-atomic-waker-1+default-dev ,
  librust-easy-parallel-3+default-dev ,
- librust-flume-0.10-dev ,
+ librust-flume-0.11-dev ,
  librust-once-cell-1+default-dev ,
  librust-smol-1+default-dev ,
  libstring-shellquote-perl,
diff -Nru rust-async-task-4.4.0/debian/patches/0001_update_flume.patch 
rust-async-task-4.4.0/debian/patches/0001_update_flume.patch
--- rust-async-task-4.4.0/debian/patches/0001_update_flume.patch
1970-01-01 00:00:00.0 +
+++ rust-async-task-4.4.0/debian/patches/0001_update_flume.patch
2023-09-23 05:17:33.0 +
@@ -0,0 +1,29 @@
+commit c42a143176fbf5201411f97f27247ba52e054135
+Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
+Date:   Mon Aug 21 00:25:27 2023 +
+
+Update flume requirement from 0.10 to 0.11
+
+Updates the requirements on [flume](https://github.com/zesterer/flume) to 
permit the latest version.
+- [Changelog](https://github.com/zesterer/flume/blob/master/CHANGELOG.md)
+- [Commits](https://github.com/zesterer/flume/commits)
+
+---
+updated-dependencies:
+- dependency-name: flume
+  dependency-type: direct:production
+...
+
+Signed-off-by: dependabot[bot] 
+
+diff --git a/Cargo.toml b/Cargo.toml
+index 4345762..fb239ba 100644
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -23,5 +23,5 @@ std = []
+ easy-parallel = "3"
+ flaky_test = "0.1"
+-flume = { version = "0.10", default-features = false }
++flume = { version = "0.11", default-features = false }
+ futures-lite = "1.12.0"
+ once_cell = "1"
diff -Nru rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch 
rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch
--- rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch  2023-08-14 
09:47:35.0 +
+++ rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch  2023-09-23 
05:19:12.0 +
@@ -7,14 +7,8 @@
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/Cargo.toml
 +++ b/Cargo.toml
-@@ -21,7 +21,6 @@
- [dev-dependencies]
- atomic-waker = "1"
- easy-parallel = "3"
+@@ -24,1 +24,0 @@
 -flaky_test = "0.1"
- flume = { version = "0.10", default-features = false }
- futures-lite = "1.12.0"
- once_cell = "1"
 --- a/tests/waker_panic.rs
 +++ b/tests/waker_panic.rs
 @@ -238,60 +238,6 @@
diff -Nru rust-async-task-4.4.0/debian/patches/series 
rust-async-task-4.4.0/debian/patches/series
--- rust-async-task-4.4.0/debian/patches/series 2023-02-03 11:05:22.0 
+
+++ rust-async-task-4.4.0/debian/patches/series 2023-09-23 05:16:50.0 
+
@@ -1 +1,2 @@
+0001_update_flume.patch
 2001_flaky-test.patch
diff -Nru rust-async-task-4.4.0/debian/tests/control 
rust-async-task-4.4.0/debian/tests/control
--- rust-async-task-4.4.0/debian/tests/control  2023-09-10 13:40:58.0 
+
+++ rust-async-task-4.4.0/debian/tests/control  2023-09-23 05:20:54.0 
+
@@ -6,7 +6,7 @@
  librust-async-task-4-dev,
  librust-atomic-waker-1+default-dev,
  librust-easy-parallel-3+default-dev,
- librust-flume-0.10-dev,
+ librust-flume-0.11-dev,
  librust-once-cell-1+default-dev,
  librust-smol-1+default-dev,
 Restrictions: allow-stderr
@@ -19,7 +19,7 @@
  librust-async-task-4+default-dev,
  librust-atomic-waker-1+default-dev,
  librust-easy-parallel-3+default-dev,
- librust-flume-0.10-dev,
+ librust-flume-0.11-dev,
  librust-once-cell-1+default-dev,
  librust-smol-1+default-dev,
 Restrictions: allow-stderr
@@ 

Bug#1051445: syslinux.efi crashes on isohybrid boot as cdrom

[Ralph Ronnquist]

Note that a debian package patch on 3:6.04~git20190206.bf6db5b4+dfsg1-3
is available at:

https://git.devuan.org/devuan/syslinux/raw/branch/suites/experimental/debian/patches/0020-fix-cdrom-on-uefi.patch

That's the patch used for the Devuan experimental release package.
Presumably it can be used directly a Debian pcakage upgrade.

regards,

Ralph.


signature.asc
Description: PGP signature

Bug#1052239: transition: ocaml

[Stéphane Glondu]

Hi all,

Le 20/09/2023 à 09:44, Sebastian Ramacher a écrit :

Good. Please go ahead


I've uploaded ocaml 4.14.1-1 3 days ago, then uploaded camlp4, ocamlnet, 
a few other arch:all packages that could not be binNMUed, and binNMUed 
all the rest.


All packages, except the ones I had already spotted during my test 
rebuild, built fine on all release architectures:


  https://release.debian.org/transitions/html/ocaml.html

scilab's status is unrelated to this transition; there are open RC bugs 
for the other "bad" packages:



https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.14.1-transition;users=debian-ocaml-ma...@lists.debian.org

The following packages should be removed from testing for now:

  gmetadom otags xmlrpc-light mlpost ulex0.8 ocamlviz


There is also another issue I didn't foresee: the binary package 
libllvm-13-ocaml-dev would be broken in testing by the migration of 
ocaml 4.14.1. Its source package, llvm-toolchain-13, has been removed 
from unstable and cannot be removed from testing because of... Haskell!


libllvm-13-ocaml-dev has no reverse dependencies, though... Is it 
possible to remove just this one from testing as well? Or to explicitly 
allow its breakage?



The transition is also looking good on riscv64. For the convenience of 
riscv porters, I've set up a transition tracker for OCaml packages on 
this architecture:


  https://people.debian.org/~glondu/ben/ocaml.html


Cheers,

--
Stéphane

Bug#1052210: lxappearance: segfault after upgrade to lxappearance 0.6.3-3

[jim_p]

Package: lxappearance
Followup-For: Bug #1052210
X-Debbugs-Cc: pitsior...@outlook.com

If anyone is interested to patch lxappearance-obconf, there is this patch in
its github page which fixes the segfault in gtk3.
https://github.com/lxde/lxappearance-
obconf/commit/b9d45ea632235f4a07eba4fd6b5e5cee3a27f59e

There are also 10 more patches in there, all of which were made this month for
addressing several other issues, because a new version won't come out anytime
soon.


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

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

Versions of packages lxappearance depends on:
ii  libc62.37-10
ii  libdbus-1-3  1.14.10-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-2
ii  libgtk-3-0   3.24.38-5
ii  libx11-6 2:1.8.6-1

Versions of packages lxappearance recommends:
pn  lxde-settings-daemon  

lxappearance suggests no packages.

-- no debconf information

Bug#1052489: iproute2: broken formatting in manual pages due to hermetic-/usr changes

[Paul Wise]

Package: iproute2
Version: 6.5.0-4
Severity: minor
Usertags: formatting

The hermetic-/usr changes to the manual pages documenting the new
locations in /usr of the files previously in /etc and overridable
by user files in /etc broke the formatting in the manual pages.

The /usr paths have "or" appended to them instead of as a separate
word and the /etc paths have "(hasprecedenceifexists)" appended to
them instead of with spaces as a separate phrase.

Note that not all mentions of /usr and /etc paths have this issue.

There may be other formatting issues I haven't noticed yet.

   $ for f in $(dpkg -L iproute2 | grep 'man.*\.gz' ) ; do if output=$(man $f 
2> /dev/null | grep "hasprecedenceifexists") ; then echo "$f" ; echo "$output" 
; fi ; done
   /usr/share/man/man8/ip-address.8.gz
 the  scope of the area where this address is valid.  The 
available scopes are listed in /usr/lib/iproute2/rt_scopesor 
/etc/iproute2/rt_scopes(hasprecedenceifexists).  Pre‐
   /usr/share/man/man8/ip-link.8.gz
 specify the group the device belongs to.  The available groups 
are listed in /usr/lib/iproute2/groupor 
/etc/iproute2/group(hasprecedenceifexists).
   /usr/share/man/man8/ip-route.8.gz
/usr/lib/iproute2/rt_dsfieldor 
/etc/iproute2/rt_dsfield(hasprecedenceifexists).
the table to add this route to.  TABLEID may be a 
number or a string from /usr/lib/iproute2/rt_tablesor 
/etc/iproute2/rt_tables(hasprecedenceifexists).  If this pa‐
the realm to which this route is assigned.  REALMID may 
be a number or a string from /usr/lib/iproute2/rt_realmsor 
/etc/iproute2/rt_realms(hasprecedenceifexists).
/etc/iproute2/rt_scopes(hasprecedenceifexists).   If 
this parameter is omitted, ip assumes scope global for all gatewayed unicast 
routes, scope link for direct uni‐
the routing protocol identifier of this route.  RTPROTO 
may be a number or a string from  /etc/iproute2/rt_protosor  
/etc/iproute2/rt_protos(hasprecedenceifexists).
number  or  a string from 
/usr/lib/iproute2/rt_tablesor /etc/iproute2/rt_tables(hasprecedenceifexists).  
If vrftable is used, the argument must be a VRF
string  from  /usr/lib/iproute2/rt_tablesor 
/etc/iproute2/rt_tables(hasprecedenceifexists).  The argument must be a VRF 
device associated with the table
ber or a string from 
/usr/lib/iproute2/rt_tablesor /etc/iproute2/rt_tables(hasprecedenceifexists).  
The argument must be a VRF  device  associated  with

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libbpf11:1.2.2-2
ii  libbsd00.11.7-4
ii  libc6  2.37-10
ii  libcap21:2.66-4
ii  libcap2-bin1:2.66-4
ii  libdb5.3   5.3.28+dfsg2-2
ii  libelf10.189-4
ii  libmnl01.0.4-3
ii  libselinux13.5-1
ii  libtirpc3  1.3.3+ds-1
ii  libxtables12   1.8.9-2

Versions of packages iproute2 recommends:
pn  libatm1  

Versions of packages iproute2 suggests:
pn  iproute2-doc  
ii  python3   3.11.4-5+b1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1039857: podman crashes my systemd-managed sway session on exit

[Antoine Beaupré]

On 2023-09-22 21:56:53, Birger Schacht wrote:
> Hi anarcat,
>
> I'd rather not diverge from upstream and carry a patch for a bugfix that 
> is a wontfix on upstreams side.
> My hope is that upstream either reconsiders or that there is a another 
> solution for that problem, that does not require us patching every new 
> version of sway.

Thanks. I'll rollback my patch and try to find another way.

I strongly doubt upstream will reconsider, they seem to be pretty stuck
up on that one...

a.
-- 
The true revolutionary is guided by a great feeling of love.
- Ernesto "Che" Guevara

Bug#831786: dh-exec: breaks dh_install --fail-missing

[Craig Small]

On Sat, 23 Sept 2023 at 08:09, Michael Biebl  wrote:

> Is there some work being done to support this in dh-exec?
> Is there a way I can work around this issue for now?
>
The short answer is, that no work has been done on that issue. The main
use-case I have seen for dh-exec was for the multiarch directories but that
is solved elsewhere.
It's a 5-year-old bug, I'm not really sure what dh_missing needs to be
happy that the file has been handled.

 - Craig

Bug#1052488: Persian translation [ Re: mrtg 2.17.10-10: Please translate debconf PO for the package mrtg ]

[Holger Wansing]

Package: mrtg
Severity: wishlist
Tags: patch,l10n


Danial Behzadi  wrote (Fri, 08 Sep 2023 22:43:27 +0330):
> This is the Persian (fa) translation file attached:

I'm submitting this into a bug against mrtg, so that it doesn't get lost on 
this 
mailinglist.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


mrtg.fa.po.gz
Description: application/gzip

Bug#1042438: root caused to shim

[dann frazier]

OK, I finally found some time to debug this. I debugged it with an
Ubuntu VM that used shim 15.7, but I suspect it is the same issue with
Fedora 38 and AlmaLinux 9.2.

shim 15.6 introduced the following commit:

commit 226fee25ffcbd29988399ba080c7706eb1d52251
Author: Peter Jones 
Date:   Thu Dec 2 18:29:50 2021 -0500

PE Loader: support and require NX

This adds support in our PE loader for NX support utilizing the
EFI_MEMORY_ATTRIBUTE protocol.  Specifically, it changes the loader such
that:

- binaries without the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag set
  in the Optional Header are rejected as EFI_UNSUPPORTED
- binaries with non-discardable sections that have both the
  EFI_SCN_MEM_WRITE and EFI_SCN_MEM_EXECUTE flags set are rejected as
  EFI_UNSUPPORTED
- if the EFI_MEMORY_ATTRIBUTE protocol is installed, then:
  - sections without the EFI_SCN_MEM_READ flag set will be marked with
EFI_MEMORY_RP
  - sections without the EFI_SCN_MEM_WRITE flag set will be marked with
EFI_MEMORY_RO
  - sections without the EFI_SCN_MEM_EXECUTE flag set will be marked
with EFI_MEMORY_XP

Signed-off-by: Peter Jones 


EDK2 didn't expose the EFI_MEMORY_ATTRIBUTE protocol for ARM until
2023.05-1, so at that point this shim code was activated. Unfortunately,
this shim code had a bug that causes this problem. Luckily it has
since been fixed in upstream git:

  From c7b305152802c8db688605654f75e1195def9fd6 Mon Sep 17 00:00:00 2001
  From: Nicholas Bishop 
  Date: Mon, 19 Dec 2022 18:56:13 -0500
  Subject: [PATCH] pe: Align section size up to page size for mem attrs

  Setting memory attributes is generally done at page granularity, and
  this is enforced by checks in `get_mem_attrs` and
  `update_mem_attrs`. But unlike the section address, the section size
  isn't necessarily aligned to 4KiB. Round up the section size to fix
  this.

  Signed-off-by: Nicholas Bishop 


I've asked Ubuntu to pick this up (LP: #2036604). Please ask your
favorite guest OS distributions to pick it up as well.

Bug#1052487: aide-common: please recommend canonical "cron | cron-daemon"

[Alexandre Detiste]

Package: aide-common
Version: 0.18.6-1
Severity: minor

Please recommends the canonical "cron | cron-daemon"
instead of plain "cron".

This way apt won't say anything about cron being
recommended when the stop-gap systemd-cron stub is already installed.




On my side I have added to systemd-cron an ignore rule for aide-common:

https://salsa.debian.org/detiste-guest/systemd-cron/-/commit/356bfedd393b0bd8663b7737e7ba5b987916b403

(this is a list of cron job that does 
 "[ -d /run/systemd/system ] && exit 0")

Greetings,

Alexandre


-- 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.4.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
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 aide-common depends on:
ii  aide0.18.6-1
ii  debconf [debconf-2.0]   1.5.82
ii  liblockfile11.17-1+b1
ii  systemd [systemd-sysusers]  254.1-3
ii  ucf 3.0043+nmu1

Versions of packages aide-common recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
pn  cron   
ii  mailutils [mailx]  1:3.16-1+b1

aide-common suggests no packages.

-- debconf information excluded

Bug#1052298: metafun broken?

[Norbert Preining]

Hi Siep,

> context --metapost --format=metafun --pdf mfun-mrun-demo.mp

That is not really a solution for other tools that run metafun as is. We have 
to be aware that we are not in a vacuum and our tools are used.

Why have the mkii files been dropped from TL2022 in the first place, was there 
an urgent reason for that?

Thanks and best regards

Norbert

-- 
PREINING Norbert  https://www.preining.info
Mercari   +    IFMGA ProGuide    +   TU Wien    +   TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Sep 23, 2023 04:45:34 Siep Kroonenberg :

> On Fri, Sep 22, 2023 at 09:49:04PM +0900, Norbert Preining wrote:
>> Hi all,
>> 
>> is metafun broken?
> 
> While testing metafun while working on inclusion of ConTeXt in
> TL2023, I successfully used command-lines such as
> 
> context --metapost --format=metafun --pdf mfun-mrun-demo.mp
> 

Bug#1052427: dh-builtusing: remove constraint on number of packages to match a wildcard

[Nicolas Boulenguez]

Package: dh-builtusing
Followup-For: Bug #1052427

Hello.

The motivation for
  Built-Using: ${dh-builtusing:gcc-S-source}
is that the maintainer wants everyone else to be able to replace
  Build-Depends: gcc-13-source
with
  Build-Depends: gcc-14-source
and rebuild the package.

The purpose of dh-builtusing is to generate the version of each
package, but I fear that computing (part of) the package list may
easily lead to false positives. For example a source may start
building several rust libraries with distinct new build dependencies.

Also, the benefice is low because a change (not restricted to
versions) in the list of Build-Depends is rare and probably already
involves decisions by the maintainer anyway.

Also, should
  Built-Using: ${dh-builtusing:librust-WILDCARD-dev} [amd64] 
be forbidden?
The only logic expansion is
  Built-Using: librust-a-dev [amd64] , librust-b-dev [amd64] 
This can be implemented, but would be inconsistent and probably fragile.

Same question for ${dh-builtusing:librust-WILDCARD-dev:amd64}.

Bug#1051560: jpeg-xl: FTBFS: failing test conformance_tooling_test

[Boyuan Yang]

X-Debbugs-CC: ma...@debian.org
Control: tags -1 +patch

On Tue, 19 Sep 2023 15:06:33 -0400 Boyuan Yang  wrote:
> X-Debbugs-CC: ma...@debian.org
> 
> On Sat, 09 Sep 2023 16:04:38 -0400 Boyuan Yang  wrote:
> > Source: jpeg-xl
> > X-Debbugs-Cc: by...@debian.org
> > Version: 0.7.0-10
> > Severity: serious
> > Tags: ftbfs sid trixie
> > 
> > Dear Maintainer,
> > 
> > For jpeg-xl/0.7.0-10, it currently fails to build from source in Debian Sid.
> > One of the post-build tests will fail:
> > 
> > 
> >   Start 2874: conformance_tooling_test
> > 2874/2874 Test #2874: conformance_tooling_test
> > ..***Failed
> >     0.15 sec
> > + CLEANUP_FILES=()
> > + trap 'retcode=$?; { set +x; } 2>/dev/null; cleanup' INT TERM EXIT
> > + main /<>/obj-x86_64-linux-gnu /usr/share/libjxl-testdata
> > ++ mktemp -d
> > + local tmpdir=/tmp/tmp.qnjN0F3yQR
> > + CLEANUP_FILES+=("${tmpdir}")
> > + python3 -c 'import numpy'
> > + local build_dir=/<>/obj-x86_64-linux-gnu
> > + [[ -z /<>/obj-x86_64-linux-gnu ]]
> > + local decoder=/<>/obj-x86_64-linux-gnu/tools/djxl
> > + /<>/tools/conformance/generator.py 
> > --decoder=/<>/obj-x86_64-linux-gnu/tools/djxl 
> > --output=/tmp/tmp.qnjN0F3yQR --peak_error=0.001 --rmse=0.001
> > /usr/share/libjxl-testdata/jxl/blending/cropped_traffic_light.jxl
> > /<>/obj-x86_64-linux-gnu/tools/djxl: error while loading 
> > shared libraries: libjxl_threads.so.0.7: cannot open shared object file: No 
> > such file or directory
> > Generating cropped_traffic_light
> > Traceback (most recent call last):
> >   File "/<>/tools/conformance/generator.py", line 128, in 
> >
> > main()
> >   File "/<>/tools/conformance/generator.py", line 124, in main
> > GenerateConformanceCorpus(args)
> >   File "/<>/tools/conformance/generator.py", line 70, in 
> >GenerateConformanceCorpus
> > subprocess.check_call(cmd)
> >   File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
> > raise CalledProcessError(retcode, cmd)
> > subprocess.CalledProcessError: Command 
> > '['/<>/obj-x86_64-linux-gnu/tools/djxl', 
> > '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/input.jxl',
> > '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/reference_image.npy', 
> > '--metadata_out', '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/test.json', 
> > '--icc_out',
> > '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/reference.icc']' returned 
> > non-zero exit status 127.
> > + retcode=1
> > 
> > 
> > 99% tests passed, 1 tests failed out of 2872
> > 
> 
> Just made a little bit investigation.
> 
> * Previously the test conformance_tooling_test was skipped since 
> python3-numpy was not installed
> during build.
> 
> * With recent builds, python3-numpy was introduced as build-dependency 
> (implicitly) due to
> build toolchain changes, thus unskipping the test.
> 
> * It looks like upstream has some special handling around such test; please 
> check
> .github/workflows/conformance.yml .

I am providing a hacky patch by manipulating LD_LIBRARY_PATH. Please find the 
patch
in the attachment.

In the long run, it would be better to systematically solve this issue by 
working
with upstream.

In the short term, I am really looking into fixing the FTBFS of src:jpeg-xl so 
that
the transition at https://release.debian.org/transitions/html/auto-libavif.html 
can
proceed. Of course, it really depends on when will FTP Masters get rid of 
jpeg-xl/0.9
packages in Experimental. If the RM request is stuck, I might as well start the
transition of libavif before the upload of jpeg-xl 8.x; otherwise I will wait 
till
jpeg-xl 8.x to migrate to Testing.

If you don't mind, I may make a NMU of jpeg-xl to DELAYED/14 to at least solve 
FTBFS.
Please let me know if you have any suggestions.

Thanks,
Boyuan Yang
From: Boyuan Yang 
Date: Fri, 22 Sep 2023 17:34:23 -0400
Subject: Fix conformance test

---
 tools/conformance/generator.py| 2 +-
 tools/conformance/tooling_test.sh | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/conformance/generator.py b/tools/conformance/generator.py
index e2a9b2e..d59c3f4 100755
--- a/tools/conformance/generator.py
+++ b/tools/conformance/generator.py
@@ -67,7 +67,7 @@ def GenerateConformanceCorpus(args):
 cmd.extend(['--icc_out', pixel_prefix + '.icc'])
 
 # Decode and generate the reference files.
-subprocess.check_call(cmd)
+subprocess.check_call(' '.join(cmd), shell=True)
 
 with open(metadata_filename, 'r') as f:
 metadata = json.load(f)
diff --git a/tools/conformance/tooling_test.sh b/tools/conformance/tooling_test.sh
index 95adefb..892b7a2 100755
--- a/tools/conformance/tooling_test.sh
+++ b/tools/conformance/tooling_test.sh
@@ -41,6 +41,7 @@ main() {
 build_dir=$(realpath 

Bug#1052486: jpeg-xl: FTBFS with libwebp 1.3.2: Use static libwebp library without linking libsharpyuv

[Boyuan Yang]

Source: jpeg-xl
Severity: serious
Version: 0.7.0-10
X-Debbugs-CC: ma...@debian.org
Control: tags -1 +patch

Dear Debian jpeg-xl packager,

Unfortunately jpeg-xl in Sid now FTBFS more due to a corner case in searching 
of its
build-dependency libwebp.

In jpeg-xl CMakeLists.txt, it searches libwebp in order to build some test 
binaries.
Unfortunately the CMakeList.txt is hardcoding the logic to prefer static 
library if
present, and fall back to using shared library. However, with libwebp 1.3.x 
series,
the static library of libwebp also depends on symbols in libsharpyuv (which is 
built
together with libwebp). The building of jpeg-xl will unfortunately FTBFS if the 
static
libsharpyuv is not linked together with libwebp explicitly.

I am preparing a patch to solve this problem, which adds the logic of static 
libsharpyuv
linkage. Unfortunately this patch will be incompatible with libwebp (<< 1.3). 
The
alternative solution is to enforce dynamic linking at all time, which will be 
compatible
with all libwebp versions.

Thanks,
Boyuan Yang
From: Boyuan Yang 
Date: Fri, 22 Sep 2023 17:12:33 -0400
Subject: tools/CMakeLists.txt: Fix compatibility with static libwebp 1.3.x

---
 tools/CMakeLists.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/CMakeLists.txt b/tools/CMakeLists.txt
index 934ed89..6556845 100644
--- a/tools/CMakeLists.txt
+++ b/tools/CMakeLists.txt
@@ -249,7 +249,12 @@ if(JPEGXL_ENABLE_BENCHMARK AND JPEGXL_ENABLE_TOOLS)
   message(WARNING "Using dynamic libwebp")
   target_link_libraries(benchmark_xl PkgConfig::WebP)
 else()
+  # Debian-specific patch
+  # libwebp 1.3.x: libsharpyuv static library must be linked as well
+  find_library(SHARPYUV_STATIC_LINK_LIBRARY NAMES libsharpyuv.a
+  PATHS "${WebP_LIBDIR}" REQUIRED)
   target_link_libraries(benchmark_xl "${WebP_STATIC_LINK_LIBRARY}")
+  target_link_libraries(benchmark_xl "${SHARPYUV_STATIC_LINK_LIBRARY}")
   target_include_directories(benchmark_xl
   PRIVATE ${WebP_STATIC_INCLUDE_DIRS})
   target_compile_options(benchmark_xl PRIVATE ${WebP_STATIC_CFLAGS_OTHER})


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

Bug#831786: dh-exec: breaks dh_install --fail-missing

[Michael Biebl]

On Sat, 26 Aug 2017 08:04:00 + Niels Thykier  wrote:


The new interface is that:

 * dh_install records what it installs where for all packages (even
   packages not acted on to support -a/-i builds)

 * dh_missing checks the logs from dh_install (among other) and compares
   it with what is present in d/tmp (--sourcedir).
   - dh_missing also responds to d/not-installed and --exclude, which
 can also be used to control what is important to install and what
 is not.

 * If all files in d/tmp are recorded (or excluded), everything is
   presumed to be fine.

 * Caveat: Files can be processed twice!  For packages that do a
   separate -i and -a run under a regular build, the config files will
   be processed twice as dh_install cannot know that the other call will
   happen.

In summary:

 * If dh-exec ensures that all files are properly recorded (even for
   packages that are not acted on) then we are good.
   - this applies to more helpers now as e.g. dh_installman also records
 what files are installed.

 * For packages not acted on, dh_install (et al) will just record the
   file as being installed, but won't actually do anything.
   - For renames, this means that dh-exec can probably just list the
 original source file without doing the rename in the "no-act"
 case.



I'm running into this issue.
I was considering making use of dh-exec to rename a binary via .install 
files in systemd, which would look like this:


$ cat debian/systemd-standalone-tmpfiles.install
#!/usr/bin/dh-exec
bin/systemd-tmpfiles.standalone => bin/systemd-tmpfiles


This breaks a --build=all build though:

dh_missing: warning: bin/systemd-sysusers.standalone exists in 
debian/tmp but is not installed to anywhere

...
The following debhelper tools have reported what they installed (with 
files per package)

 * dh_install: ... systemd-standalone-tmpfiles (0)


Is there some work being done to support this in dh-exec?
Is there a way I can work around this issue for now?

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050385: driftnet: Import new upstream release

[Bastian Germann]

Please see https://github.com/deiv/driftnet/pull/49

Bug#970557: Closing this bug (BTS maintenance for src:linux bugs)

[Vincent Lefevre]

Hi,

On 2023-09-22 17:10:37 +0200, car...@debian.org wrote:
> 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
[...]

Just a note to say that the machine on which I got this crash
no longer exists.

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

Bug#792390: gradle: improve bootstrapping by using groovyc

[Emmanuel Bourg]

It looks like Fedora gave up with Gradle [1], I'm not sure the upgrades
are significantly easier with this approach.


[1] 
https://src.fedoraproject.org/rpms/gradle/c/4a126e8e3380eda7ceda22b18a9d9633bcd8cda8?branch=rawhide

Bug#1052145: gjs: Please upgrade gjs to >= 1.77.2

[Jeremy Bícha]

On Mon, Sep 18, 2023 at 3:09 AM Jérémy Lal  wrote:
> gpaste for gnome 45 depends on gjs >= 1.77.2.

I am fairly confident this was an erroneous version bump. Nothing in
the particular commit uses JavaScript at all.

https://github.com/Keruspe/GPaste/commit/a6bb4d79

Could you revert the gjs bump in meson.build and upload the extension
to Experimental? I did a test build from your git repo and things
seems to work fine for me.

Thank you,
Jeremy Bícha

Bug#1052485: Help with packaging LilyPond 2.24.2?

[John Zaitseff]

Package: lilypond
Version: 2.24.1-2
Severity: wishlist

Thank you for packaging LilyPond for Debian!  I really appreciate
having this package available.

I note that LilyPond 2.24.2 was been released just over a month ago.
It would be great to have it in Debian Sid at least (I take your
package and backport/crossport it to Debian Bookworm, Ubuntu Jammy
and Ubuntu Lunar [1]).  Would you like any help in preparing an
updated package?

[1] https://www.zap.org.au/git-browser/debian-packages/pkg-lilypond.git/

Yours truly,

John Zaitseff

-- 
John Zaitseff   ╭───╮   Email: j.zaits...@zap.org.au
The ZAP Group   │ Z │   GnuPG: 0x0D254111C4EE569B
Australia Inc.  ╰───╯   https://www.zap.org.au/~john/

Bug#1052470: [Pkg-javascript-devel] Bug#1052470: nodejs: Please fix testsuite for openssl-3.1

[Jérémy Lal]

Le ven. 22 sept. 2023 à 22:18, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> a écrit :

> On 2023-09-22 17:59:51 [+0200], To sub...@bugs.debian.org wrote:
> > Now I'm about to test this… But it looks promising ;)
>
> Okay, builds.
>

Thanks, will include it soon.

Bug#1043131: hcrypto: rename abort to _afscrypto_abort

[Jeremy Stanley]

Seems like this commit may address the build failure?

https://git.openafs.org/?p=openafs.git;a=commit;h=c4c1689

-- 
Jeremy Stanley

Bug#1052445: Request for permission to upload to sid

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-09-22 19:25:15 +0200, Teus Benschop wrote:
> Hello Release Team,
> 
> For clarity, this is a request for me to upload libpqxx to sid to start the
> transition there.
> 
> A binNMU is enough for each reverse dependency.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1052401: plasma-mobile: correction to short description

[Marco Mattiolo]

Hi,

hmm, that description was taken from [1], as far as I can remember.

Any specific reason the "open-source" should be dropped?

Kind regards

Marco

[1] https://invent.kde.org/plasma-mobile

Bug#1052470: nodejs: Please fix testsuite for openssl-3.1

[Sebastian Andrzej Siewior]

On 2023-09-22 17:59:51 [+0200], To sub...@bugs.debian.org wrote:
> Now I'm about to test this… But it looks promising ;)

Okay, builds.

Sebastian

Bug#1052463: bookworm-pu: package debian-edu-doc/2.12.18~deb12u1

[Holger Levsen]

On Fri, Sep 22, 2023 at 03:28:28PM +, Holger Levsen wrote:
> On Fri, Sep 22, 2023 at 04:45:49PM +0200, Holger Levsen wrote:
> > I'll attach the full (compressed) debdiff in a reply, once this bug has 
> > made it
> > to the list.
> see below.

hm, I guess attachments over 500K are not send to the list, just to the BTS.
However, I've also uploaded to bookworm now, so you can also just diff there.

thanks!


-- 
cheers,
Holger

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

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature

Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package

[Russ Allbery]

Jonathan Kamens  writes:

> * Speaking as an end user, I do not agree with the statement, "I see that
>   python3-selenium now has a NEWS.Debian entry that points to
>   README.Debian, which seems like a reasonable way to bring this to users'
>   attention." Most users don't know to look for either of these
>   files.

Just a quick side note on this point: I strongly encourage everyone
running Debian to install apt-listchanges.  I feel like we added that to
the default install these days but maybe we didn't.  You can configure it
to show you only NEWS.Debian files, not the full changelog.  Any new
NEWS.Debian file entry for a package that you have installed is generally
worth reading, and this is the supported way (other than the Release Notes
for the full stable release) that Debian communicates major breaking
changes like this to users.

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

Bug#1052298: metafun broken?

[Siep Kroonenberg]

On Fri, Sep 22, 2023 at 09:49:04PM +0900, Norbert Preining wrote:
> Hi all,
> 
> is metafun broken?

While testing metafun while working on inclusion of ConTeXt in
TL2023, I successfully used command-lines such as

context --metapost --format=metafun --pdf mfun-mrun-demo.mp

-- 
Siep Kroonenberg

Bug#1039857: podman crashes my systemd-managed sway session on exit

[Birger Schacht]

Hi anarcat,

I'd rather not diverge from upstream and carry a patch for a bugfix that 
is a wontfix on upstreams side.
My hope is that upstream either reconsiders or that there is a another 
solution for that problem, that does not require us patching every new 
version of sway.


cheers,
Birger

Bug#1052484: fail2ban: jail.conf manual page not current, no documentation for bantime.increment etc.

[Alex King]

Package: fail2ban
Version: 1.0.2-2
Severity: normal
X-Debbugs-Cc: a...@king.net.nz

Dear Maintainer,

I was trying to use the bantime increment feature in fail2ban.

At
https://serverfault.com/questions/1093451/fail2ban-bantime-increment-not-working,
I see the author recommends "please read the mans attentively".

I read the manual page at JAIL.CONF(5), but it did not contain any
mention of bantime.increment, or related bantime.* directives.

I checked the file
/usr/lib/python3/dist-packages/fail2ban/server/observer.py which
includes the text "This module was written as part of ban time increment
feature."  This suggests the functionality is in the Debian package
already.  (Also the author mentions "Bantime increment facility is
released with fail2ban 0.11", so it has probably been in Debian since
Bullseye.)

I expect that relevant documentation including manual pages should be
included in the debian pakage.


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

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

Versions of packages fail2ban depends on:
ii  python3  3.11.2-1+b1

Versions of packages fail2ban recommends:
ii  iptables   1.8.9-2
ii  nftables   1.0.6-2+deb12u1
pn  python3-pyinotify  
pn  python3-systemd
ii  whois  5.5.17

Versions of packages fail2ban suggests:
ii  mailutils [mailx]1:3.15-4
pn  monit
ii  rsyslog [system-log-daemon]  8.2302.0-1
ii  sqlite3  3.40.1-2

-- no debconf information

Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package

[Jonathan Kamens]

Thank you to everyone here who explained the context of which I was 
unaware surrounding this issue. I appreciate that you took the time to 
do that. A couple points in response...


* For the record, if the package maintainer had said in the other 
ticket, "Yes, the package is broken, but including Selenium Manager in 
the package is not currently possible because the tools to build it in 
Debian don't exist and that's not a trivial problem to solve," then we 
would be having a very different conversation right now, and I would 
never have escalated this to the technical committee. Instead, what they 
said was (paraphrasing), "I don't think we should consider the package 
broken just because it used to work and now suddenly stopped working and 
the same code that used to work now causes a stack trace, because if the 
user reads the stack trace and spends about 30 minutes Googling they 
should be able to figure out how to work around the problem." This is 
not, in my opinion, a reasonable response. Just because fixing the issue 
"correctly" involves a lot of work we can't currently do doesn't make 
that a reasonable response. I realize that adjudicating whether a 
response from a maintainer is reasonable is outside the purview of the 
technical committee and I'm not asking for a "ruling" on this one way or 
another; I just feel compelled to point out that the only reason why I 
escalated to the technical committee was because the maintainer was not 
forthcoming.


* I want to push back a bit on the attitude I seem to be hearing here, 
that people shouldn't report issues unless they're prepared to do the 
work to fix them, or the corollary, that if no one is currently prepared 
to do the work to fix an issue then it should just be closed. I don't 
think people should be rebuffed from reporting real issues just because 
they don't have the skills or time necessary to fix them themselves, and 
I think that unresolved or incompletely resolved issues should be kept 
open until they can be resolved properly.


* Speaking as an end user, I do not agree with the statement, "I see 
that python3-selenium now has a NEWS.Debian entry that points to 
README.Debian, which seems like a reasonable way to bring this to users' 
attention." Most users don't know to look for either of these files. 
It's simply not going to occur to them that this is a Debian issue 
requiring special handling; they're simply going to think the package is 
broken. I could be wrong about this, of course, but this is my gut 
instinct. Given that the Python code is always going to crash in the 
same place if it can't find Selenium Manager, then a workaround for this 
problem would be patch the code so that it catches the exception and 
points the user at README.Debian before re-raising it.


* If this really is going to be "fixed" just with documentation, then I 
would argue that the better documentation fix would be to tell the user 
how they can install Selenium Manager themselves rather than telling 
them how to hack their code to work around the missing Selenium Manager. 
That would mean telling amd64 users where to download it, and providing 
instructions for users on other architectures on how to compile and 
install it. Heck, maybe even put a shell script in the python3-selenium 
package that compiles and installs it and just tell the user what it 
does (full disclosure is important here!) and how to run it.


If there is interest in a combination of the above two changes as an 
acceptable improved fix for this issue, and someone can point me at 
where I can get started learning how to submit patches to Debian 
packages, then I am willing to work on this and submit a patch.


* I agree that patching the Python binding on Debian to restore the 
previous behavior would be a better short-term fix than what we have now 
(though I think a combination of the two fixes above would be 
preferable). However, I'm not sure that's a viable long-term fix, 
because I imagine that if Selenium Manager "catches on" it will become 
harder and harder to patch it over time. There's no saying whether I'm 
right about that or if I am what the time-frame will be, and it could 
actually go in the opposite direction, i.e., if the maintainers of 
Selenium get enough push-back about their choice to require their 
Selenium Manager binary they may reverse that decision.


* Another potential fix for this is to package Webdriver Manager 
, which is essentially a 
pure-Python replacement for Selenium Manager, make it a dependency of 
python3-selenium, and patch python3-selenium to use it by default 
instead of Selenium Manager. I think this would satisfy everyone's 
concerns, and it would restore python3-selenium to a working state 
out-of-the-box.


I am also willing to work on this and submit a patch if there is 
interest in this solution.


* In my opinion, keeping the old version of the Python bindings that 
didn't 

Bug#1052447: libwebp: Missing change "Fix invalid incremental decoding check."

[Salvatore Bonaccorso]

Control: severity -1 normal
Control: tags -1 - security

On Fri, Sep 22, 2023 at 09:24:48AM +0200, Salvatore Bonaccorso wrote:
> Source: libwebp
> Version: 1.2.4-0.3
> Severity: grave
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi
> 
> While the security fix in bookworm correctly included as well
> 
> https://chromium.googlesource.com/webm/libwebp.git/+/95ea5226c870449522240ccff26f0b006037c520%5E%21/#F0
> 
> this is missing in the 1.2.4-0.3 upload and as well in the 1.3.2-0.2
> version currently in unstable.
> 
> While one might strictly arguing only the first commit is needed from
> https://security-tracker.debian.org/tracker/CVE-2023-4863 as we have
> not enough ifnormation from the issue, the second one should have been
> as well included.

It looks that in the end this assessment was wrong. Some details are
in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62136#c7 .
Samewise for the other applied commits, they are just clean-ups but
not security issues.

For transparency I'm commenting the above, while leaving now the
patches applied, but lowering the severity accordingly and removing
the security tag.

Regards,
Salvatore

Bug#1051395: bookworm-pu: package pywinrm/0.3.0-4+deb12u1

[Sebastiaan Couwenberg]

With the upload window closing next week, I've uploaded these changes to 
bookworm.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1050399: RM: starplot -- RoQA; low popcon; depends on gtk2

[Bastian Germann]

Control: severity -1 normal
Control: reassign -1 ftp.debian.org

Please remove starplot. It has a low popcon and depends on gtk2. The last 
maintainer upload was in 2014.
The last upstream release was in 2008.

Bug#1052467: transition: svt-av1

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-09-22 17:07:48 +0200, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Please schedule a transition slot for svt-av1.
> 
> The auto-generated ben tracker looks good:
> https://release.debian.org/transitions/html/auto-svt-av1.html

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1052483: emacs-gtk: rcirc doesn't rejoin channels on reconnecting

[Manphiz]

control: tag -1 patch
control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65882

Patch attached.

-- 
Manphiz

--- emacs-29.1+1.orig/lisp/net/rcirc.el
+++ emacs-29.1+1/lisp/net/rcirc.el
@@ -859,6 +859,7 @@ If QUIET is non-nil, no not emit a messa
   (if (rcirc--connection-open-p process)
   (throw 'exit (or quiet (message "Server process is alive")))
 (delete-process process))
+  (setq rcirc-user-authenticated nil)
   (let ((conn-info rcirc-connection-info))
 (setf (nth 5 conn-info)
   (cl-remove-if-not #'rcirc-channel-p

Bug#1052483: emacs-gtk: rcirc doesn't rejoin channels on reconnecting

[Xiyue Deng]

Package: emacs-gtk
Version: 1:29.1+1-5~bpo12+1manphiz1
Severity: normal
X-Debbugs-Cc: none, Xiyue Deng 

rcirc can be set up to automatically join a list of channels on
connecting to a server.  However, in case of network issue and rcirc
reconnecting to the server, it won't rejoin those channels.  A more
detailed analysis and fix can be found on the upstream bug.  I'll
provide the patch in a follow-up email.

Please note that the package version looks funny as it's built locally
with the patch to confirm it works.  It can be reproduced in the current
packaged 28.2 or 29.1 versions.


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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:29.1+1-5~bpo12+1manphiz1
ii  emacs-common 1:29.1+1-5~bpo12+1manphiz1
ii  libacl1  2.3.1-3
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9+deb12u1
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.8-2~deb12u1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgccjit0   12.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgif7  5.2.1-2.5
ii  libglib2.0-0 2.74.6-2
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libgnutls30  3.7.9-2
ii  libgpm2  1.20.7-10+b1
ii  libgtk-3-0   3.24.37-2
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libm17n-01.8.0-6
ii  libotf1  0.9.16-4
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  librsvg2-2   2.54.7+dfsg-1~deb12u1
ii  libselinux1  3.4-1+b6
ii  libsm6   2:1.2.3-1
ii  libsqlite3-0 3.40.1-2
ii  libsystemd0  252.12-1~deb12u1
ii  libtiff6 4.5.0-6
ii  libtinfo66.4-4
ii  libtree-sitter0  0.20.7-1
ii  libwebp7 1.2.4-0.2+deb12u1
ii  libwebpdemux21.2.4-0.2+deb12u1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libxcomposite1   1:0.4.5-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages emacs-gtk recommends:
ii  fonts-noto-color-emoji  2.038-1

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:29.1+1-1~bpo12+0manphiz1

-- no debconf information

Bug#979466: dh-sysuser: Create users in preinst instead of postinst

[Lorenzo]

Hi Christopher,

On Thu, 21 Sep 2023 16:19:25 +0200
Christopher Odenbach  wrote:

> 
> Hi,
> 
> I just stumbled across the same problem: Creating a package which 
> creates a system user and then gives this user ownership of a
> directory. 
> Currently this is not possible as the user is created in
> the postinst script at the very last point.

Well, you can write your code after the #DEBHELPER# token.. but I guess
this doesn't work for your use case?
Do you have the same problem as Lars -
" move the `#DEBHELPER#` marker  to the top of the postinst script.
But this would lead to related services being restarted (via the other
debhelper snippets) before the directory permissions are configured. "

or there is another use case where the current order does not work?
If you have another example I'm interested in hearing it.

> 
> The logical approach would be:
> 
> - create the system user (preinst)
> - install all files and directories ("inst")
> - transfer ownership (postinst)
> 
> In your last email you said you wanted to discuss this matter on
> Debian Devel. So could you please be so kind?

Yeah that was the idea, but then I realized that writing in preinstall
doesn't work with this package design: the preinstall snippet will
call sysuser-helper which is not guaranteed to be installed yet :(

So far I can think of the following:

1. The code can be written entirely in the preinstall but this defeats
 the idea of having the code in a separate binary (sysuser-helper) which
 has drawbacks like this bug but also has other advantages that I would
 like not to give up; maybe there can be a specific option to do this?

2. dh-sysuser can grow an interface similar to systemd-tempfiles but
 less complex and specialized in changing mode and ownership to
 files and dirs and makes sure that the snippet in postinstall is run
 after the creation of the user (I'm not particularly eager to do
 this..) 

3. declare that for such cases systemd-tmpfiles is mandatory (but I
 still need to check that the order is correct)

In case 1. is not feasible, do you dislike 2? Would it work for your use
case?

> I really like the idea
> of your package, but currently it does not really help me.

I neglected a bit this package during the last cycle, hopefully I'll
manage to do better in this cycle

Regards,
Lorenzo

> 
> Thank you,
> 
> Christopher
> 

Bug#1051125: RFS: a2d/2.0.0-1 [ITP] -- APRS to DAPNET portal

[Boyuan Yang]

X-Debbugs-CC: kd8...@gmail.com

Hi,

On Tue, 12 Sep 2023 22:54:25 -0400 Yogu NY3W  wrote:
> I've removed the redundant dh_auto_clean in d/rules, created
> debian/a2d.install to list the extra files, and made necessary adjustments
> in setup.py to manage these files. Would you kindly review and confirm if
> the package now aligns with Debian's requirements?

A bypasser here and took a look at your package. Some comments:

* debian/a2d.conffiles is empty and obviously useless. Please drop it.

* The non-atomic modification to crontab all over the place is worrying.
Please avoid manual invocation of crontab whenever possible and use
dh_installcron(1) whenever applicable.

* "Name" field in debian/upstream/metadata is deprecated. Please check
  the up-to-date instruction on this file at 
  https://wiki.debian.org/UpstreamMetadata .

* I am deeply worried by your invasive manipulation of system files,
especially the manipulation of files of other packages. Namely:

-> Executing "rm -r" for files under /usr/lib/ (!!)

-> Executing "rm -r" for files under /usr/local/ (!!!)

-> Creating files under /usr/local/ in preinst script (!!!)
   This is a clear violation of Debian Policy. Regular package shall not touch
   files under /usr/local/ under any circumstances.

-> Using "mkdir -p" to create directories (!)
   Please use debian/.dirs file as used by dh_installdirs(1) for safe
   directory creation and deletion.

-> Executing "rm" for /etc/nginx/sites-enabled/default (!)
   This will be catastrophic if the user had any manual modification
   to the default configuration file.

Those with (!) marked are clear red flags and will definitely be rejected
during package review.

The general rule is to avoid writing anything into maintscripts (preinst,
preinst, postinst, postrm) whenever possible since they are error-prone.

Since your package seems to have deep integration with the system, such
integration will need to be carefully designed. I encourage looking into other
system packages and see how they handle /var/, crontab, etc.

Thanks,
Boyuan Yang


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

Bug#1052482: gradle: Raise the minimum source/target level to 8 for OpenJDK 21

[Emmanuel Bourg]

Package: gradle
Version: 4.4.1-18
Severity: important
Tags: ftbfs sid trixie
User: debian-j...@lists.debian.org
Usertags: default-java21

Gradle currently adjusts the minimum Java source/target level to 7,
but it order to support OpenJDK 21 it should now set the minimum
level to 8.

Bug#1052469: default resolution is too high, fonts too small

[Marco Mattiolo]

Hi,

I will need more details to try and debug this.

In the bug report you're mentioning version 5.27.6, which is actually in 
Trixie: are you still using that? Or have you upgraded to the sid 
version 5.27.8?


What's the upgrade that broke resolution? You can `cat 
/var/log/apt/history.log`  to get the list of apt actions.


Is it possible for you to access plasma-settings and then change the 
scale inside "Display configuration"?


Kind regards

Marco

Bug#1052431: RFP: rust-tonic -- rust implementation of gRPC

[Jonas Smedegaard]

Quoting Reinhard Tartler (2023-09-22 13:09:08)
> How about I take care of hyper-timeout and prettyplease in debcargo-conf
> (i.e., the rust team mass-packaging repo), and try to assist you with 
> packaging
> the workspace builds of tonic (which includes tonic-build, cf. 
> https://github.com/hyperium/tonic/tree/master/tonic-build)
> and axum?

Deal! :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1052216: plasma-mobile should depend on plasma-dialer

[Marco Mattiolo]

Hi,

thank you for the feedback. As there's nothing left to be done here, I'm 
going to close this bug report.


Kind regards

Marco

Il 22/09/23 15:25, Pirate Praveen ha scritto:
On Thu, 21 Sep 2023 19:32:46 +0200 Marco Mattiolo 
 wrote:

Hi,

thank you for reporting.

For the point of plasma-mobile not depending on plasma-dialer, I'm 
sorry that's a "wontfix": there are usecases (e.g. tablet) where 
plasma-mobile can be used without plasma-dialer, then it makes no 
sense for plasma-mobile to depend on plasma-dialer and to force some 
user to install plasma-dialer even if not needed.


Thanks for the explanation, makes sense. I was not thinking about the 
tablet use case.


Your point will be addressed in the near future, as a metapackage is 
being worked on to bring something like plasma-mobile-phone (which 
will depend on plasma-dialer and many others) and 
plasma-mobile-tablet (which will not depend on plasma-dialer) to 
Debian. In the phone usecase, you will have to install 
plasma-mobile-phone to get a full plasma-mobile system for the phone 
usecase, including the dialer.


Thanks for this.



For the point of the plasma-dialer error, that's an error I've seen 
in two situations: inside a virtual machine (hence no modem available 
to route audio calls) or when something was crashing really bad. Just 
to be sure, have you installed plasma-dialer from the Debian repo 
with all its dependencies, right? 


yes installed via apt.
> Does this error still happen after reboot?

It seems to be fixed now and I can make calls with plasma dialer now, 
lso incoming calls are also handled via plasma dialer now.



Kind regards

Marco

Bug#1052445: Request for permission to upload to sid

[Teus Benschop]

Hello Release Team,

For clarity, this is a request for me to upload libpqxx to sid to start the
transition there.

A binNMU is enough for each reverse dependency.

With thanks,

Teus Benschop
teusbensc...@debian.org

Bug#1052481: ITP: libgedit-gtksourceview -- Gedit's fork of gtksourceview4

[Amin Bandali]

Package: wnpp
Severity: wishlist
Owner: Amin Bandali 

* Package name: libgedit-gtksourceview
  Version : 299.0.4
  Upstream Contact: Sébastien Wilmet 
* URL : https://github.com/gedit-technology/libgedit-gtksourceview
* License : LGPL-2.1+
  Programming Lang: C
  Description : libgedit-gtksourceview is a library that extends 
GtkTextView, the standard GTK widget for multiline text editing

libgedit-gtksourceview is a library that extends GtkTextView, the
standard GTK widget for multiline text editing.  This library adds
support for syntax highlighting, undo/redo, file loading and saving,
search and replace, a completion system, printing, displaying
line numbers, and other features typical of a source code editor.

gedit 45.0 and later depend on libgedit-gtksourceview instead of
GtkSourceView, thus this package is needed for packaging newer
versions of gedit.  This package will be maintained as part of the
Debian GNOME team.

Bug#1052480: bookworm-pu: package libpam-mklocaluser/0.18+deb12u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libpam-mklocalu...@packages.debian.org, 
debian-...@lists.debian.org
Control: affects -1 + src:libpam-mklocaluser

[ Reason ]

In Debian Edu, we provide roaming workstations. The mechanism of
persistent user creation is handled by libpam-mklocaluser (Users in
LDAP get created as local users on such machines when logging in
on the school's network. From then on, the user exists locally on
that machine).

It was observed that with LightDM it would always take two logins
to complete this process. The first login would create the user
but bump back into the login manager.

With GDM3 this is not the case.

While investigating this deeper, it was discovered that it is
important to place libpam-mklocaluser at the very top of the
PAM session type stack. This is provided with the changeset of
this package. Furthermore, we cherry-picked a change that fixes
various (awful) grammar mistakes and typos in the README.

[ Impact ]
Users will continue to login twice on Debian Edu roaming workstations.

There will also be a fix to LightDM, that we plan to propose as a
bookworm-pu. If that finds its way into bookworm, having this change
is mandatory, otherwise the successful initial login will have
broken systemd user services.

[ Tests ]
Manual tests on Debian Edu 12 (preview installations).

[ Risks ]
Not much, libpam-mklocaluser seems to be used by Debian Edu, only,
it seems.

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

[ Changes ]

+  [ Mihai Moldovan ]
+  * README: Typo and grammar fixes.

-> the mentioned language fixes...

+  [ Guido Berhoerster ]
+  * debian/pam-auth-update/mklocaluser:
++ Ensure this PAM module is ordered before other session type modules.
+  Since this potentially changes the home directory, the module should be
+  ordered before others which require the correct location of the home
+  directory and/or start executables, particularly pam_systemd. (Closes:
+  #1052475).

-> the priority bump for pam-auth-update.

[ Other info ]
None.
diff -Nru libpam-mklocaluser-0.18/debian/changelog 
libpam-mklocaluser-0.18+deb12u1/debian/changelog
--- libpam-mklocaluser-0.18/debian/changelog2020-05-22 18:01:47.0 
+0200
+++ libpam-mklocaluser-0.18+deb12u1/debian/changelog2023-09-22 
18:50:27.0 +0200
@@ -1,3 +1,18 @@
+libpam-mklocaluser (0.18+deb12u1) bookworm; urgency=medium
+
+  [ Mihai Moldovan ]
+  * README: Typo and grammar fixes.
+
+  [ Guido Berhoerster ]
+  * debian/pam-auth-update/mklocaluser:
++ Ensure this PAM module is ordered before other session type modules.
+  Since this potentially changes the home directory, the module should be
+  ordered before others which require the correct location of the home
+  directory and/or start executables, particularly pam_systemd. (Closes:
+  #1052475).
+
+ -- Mike Gabriel   Fri, 22 Sep 2023 18:50:27 +0200
+
 libpam-mklocaluser (0.18) unstable; urgency=medium
 
   * Team upload.
diff -Nru libpam-mklocaluser-0.18/debian/control 
libpam-mklocaluser-0.18+deb12u1/debian/control
--- libpam-mklocaluser-0.18/debian/control  2020-05-22 17:58:46.0 
+0200
+++ libpam-mklocaluser-0.18+deb12u1/debian/control  2023-09-22 
18:49:18.0 +0200
@@ -18,13 +18,13 @@
  ${python3:Depends},
  libpam-python
 Suggests: libpam-ccreds | libpam-sss,
-Description: Configure PAM to create a local user if it do not exist already
+Description: Configure PAM to create a local user if it does not exist already
  When the user logs in for the first time, a local POSIX user account is
- created in /etc/passwd and primary group created in /etc/group, and a
+ created in /etc/passwd, a primary group is created in /etc/group, and a
  local home directory is created in /home.
  .
  This is useful on roaming computers when the password is set up to be
- cached by for example libpam-ccreds or sssd to allow login without
+ cached by, for example, libpam-ccreds or sssd to allow login without
  network connectivity using the password provided by a network
  authentication service like Kerberos or LDAP.
  .
diff -Nru libpam-mklocaluser-0.18/debian/pam-auth-update/mklocaluser 
libpam-mklocaluser-0.18+deb12u1/debian/pam-auth-update/mklocaluser
--- libpam-mklocaluser-0.18/debian/pam-auth-update/mklocaluser  2020-05-22 
07:52:53.0 +0200
+++ libpam-mklocaluser-0.18+deb12u1/debian/pam-auth-update/mklocaluser  
2023-09-22 18:47:33.0 +0200
@@ -1,6 +1,6 @@
 Name: Create local accounts and home directory on first time login
 Default: yes
-Priority: 0
+Priority: 1024
 Session-Interactive-Only: yes
 Session-Type: Additional
 Session-Final:
diff -Nru libpam-mklocaluser-0.18/debian/README 

Bug#1052479: bookworm-pu: package lxc/1:5.0.2-1+deb12u1

[Mathias Gibbens]

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

[ Reason ]
lxc 1:5.0.2-1 contains a typo in its IPv6 NAT rules, as reported in
#1049976. This prevents the lxc-net service from starting if
LXC_IPV6_NAT is set to true.

This was fixed in lxc version 5.0.3, which I have recently uploaded to
unstable. I would like to include this fix in bookworm's version of lxc
as it's a trivial fix affecting an actual Debian user.

[ Impact ]
IPv6 NAT is broken in bookworm's current version of lxc.

[ Tests ]
The changes have been reviewed and accepted by the upstream developers.

[ Risks ]
No risks -- a simple typo fix that has been fixed upstream since
February.

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

[ Changes ]
Backport upstream commit 4de047f51365cc06a626ee9de49fec5f76556c66,
which was included in lxc version 5.0.3. There's also a small change to
adjust the default branch used by gbp to reflect the new branch for
bookworm fixes.

[ Other info ]
The source debdiff is attached.
diff -Nru lxc-5.0.2/debian/changelog lxc-5.0.2/debian/changelog
--- lxc-5.0.2/debian/changelog	2023-01-17 02:53:00.0 +
+++ lxc-5.0.2/debian/changelog	2023-09-22 16:35:52.0 +
@@ -1,3 +1,10 @@
+lxc (1:5.0.2-1+deb12u1) bookworm; urgency=medium
+
+  * Cherry-pick upstream "fix nftables syntax for IPv6 NAT" (Closes: #1049976)
+  * Adjust branch in d/gbp.conf
+
+ -- Mathias Gibbens   Fri, 22 Sep 2023 16:35:52 +
+
 lxc (1:5.0.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru lxc-5.0.2/debian/gbp.conf lxc-5.0.2/debian/gbp.conf
--- lxc-5.0.2/debian/gbp.conf	2023-01-17 02:53:00.0 +
+++ lxc-5.0.2/debian/gbp.conf	2023-09-22 16:35:47.0 +
@@ -1,3 +1,3 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = master
+debian-branch = debian/bookworm
diff -Nru lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch
--- lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch	1970-01-01 00:00:00.0 +
+++ lxc-5.0.2/debian/patches/0100-fix-nftables-ipv6.patch	2023-09-22 16:35:47.0 +
@@ -0,0 +1,34 @@
+From 4de047f51365cc06a626ee9de49fec5f76556c66 Mon Sep 17 00:00:00 2001
+From: Quentin Lyons <36303164+n0...@users.noreply.github.com>
+Date: Sun, 12 Feb 2023 02:03:42 +
+Subject: [PATCH] lxc-net.in: fix nftables syntax for IPv6 NAT
+
+The nftables masquarade rule for IPv6 was using the IPv4 syntax. This
+resulted in the following error when starting the lxc-net.service with
+LXC_IPV6_NAT="true" and nftables:
+
+Feb 11 18:54:54 pc lxc-net[4936]: Error: conflicting protocols specified: ip6 vs. ip
+Feb 11 18:54:54 pc lxc-net[4936]:  
+Feb 11 18:54:54 pc lxc-net[4917]: Failed to setup lxc-net.
+Feb 11 18:54:54 pc systemd[1]: lxc-net.service: Main process exited, code=exited, status=1/FAILURE
+Feb 11 18:54:54 pc systemd[1]: lxc-net.service: Failed with result 'exit-code'.
+Feb 11 18:54:54 pc systemd[1]: Failed to start LXC network bridge setup.
+
+Signed-off-by: Quentin Lyons <36303164+n0...@users.noreply.github.com>
+---
+ config/init/common/lxc-net.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/config/init/common/lxc-net.in b/config/init/common/lxc-net.in
+index efee9b96f0..e9ab88890a 100755
+--- a/config/init/common/lxc-net.in
 b/config/init/common/lxc-net.in
+@@ -92,7 +92,7 @@ start_nftables() {
+ add table ip6 lxc;
+ flush table ip6 lxc;
+ add chain ip6 lxc postrouting { type nat hook postrouting priority 100; };
+-add rule ip6 lxc postrouting ip saddr ${LXC_IPV6_NETWORK} ip daddr != ${LXC_IPV6_NETWORK} counter masquerade;
++add rule ip6 lxc postrouting ip6 saddr ${LXC_IPV6_NETWORK} ip6 daddr != ${LXC_IPV6_NETWORK} counter masquerade;
+ "
+ fi
+ NFT_RULESET="${NFT_RULESET};
diff -Nru lxc-5.0.2/debian/patches/series lxc-5.0.2/debian/patches/series
--- lxc-5.0.2/debian/patches/series	2023-01-17 02:53:00.0 +
+++ lxc-5.0.2/debian/patches/series	2023-09-22 16:35:47.0 +
@@ -1,3 +1,4 @@
 0004-apparmor.d-Sets-container-base-accordingly-to-container-base.in.patch
 0005-lxc.service-Starts-after-remote-fs.target.patch
 0004-nesting-Extend-mount-permissions-in-apparmor-to-allo.patch
+0100-fix-nftables-ipv6.patch


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

Bug#1052478: RM: cernlib -- RoQA; RC-buggy; orphaned; dead upstream

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:cernlib
Control: block -1 by 1051709
Control: block -1 by 1051708

cernlib is RC-buggy, dead upstream, orphaned, and was released with buster for 
the last time. Please remove it.

Bug#1051709: RM: paw -- RoQA; dead upstream

[Bastian Germann]

Control: reassign -1 ftp.debian.org

Please remove paw. It is dead upstream and missed bullseye and bookworm due to 
(Build-)Depends on the RC-buggy cernlib.

Bug#925037: Updating the cernlib Uploaders list

[Bastian Germann]

Control: reassign -1 wnpp
Control: retitle -1 O: cernlib -- data analysis suite

On behalf of the Science Team, I am orphaning cernlib now.
Without Lifeng Sun, nobody in the team cares about the package.

Description: CERNLIB data analysis suite
 CERNLIB is a suite of data analysis tools and libraries created for
 use in physics experiments, but also with applications to other
 fields such as the biological sciences.

Bug#1052445: Transition: libpqxx 6.4->7.8

[Maarten van Geijn]

reassign 1052445 release.debian.org

On 22/09/2023 17:22, Christoph Berg wrote:

Re: Maarten van Geijn

Hi Christoph,

Thanks for pointing this out.
Yes, this is intended as pre-approval request for the transition into sid. I
got this https://wiki.debian.org/Teams/ReleaseTeam/Transitions site, from
which I understood that a bug-report on this was necessary for the sid
upload, but perhaps I misunderstood.


Yes, a bug report on the "release.debian.org" pseudo package.

(You can reassign this bug, or open a new one.)

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052477: RM: xbindkeys-config -- RoQA; orphaned; dead upstream; depends on gtk2

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:xbindkeys-config

Please remove xbindkeys-config. It is orphaned, dead upstream, and depends on 
obsolete gtk2.

Bug#967518: hardinfo: depends on deprecated GTK 2

[Bastian Germann]

Am 03.09.23 um 18:15 schrieb Bastian Germann:

Please try to build a gtk3 version with the HARDINFO_GTK3 option.


You should first update to ef03a9ce3788bdb8ce6b23564b139577c9438655 at least
because that includes the uber-graph files that the GTK 3 version needs.

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

[Emmanuel Bourg]

Source: surankco
Version: 0.0.r5+dfsg-3
Severity: important
Tags: ftbfs sid trixie
User: debian-j...@lists.debian.org
Usertags: default-java21


surankco fails to build with OpenJDK 21 because it invokes javac with
the source/target options set to 7. Since OpenJDK 20 the minimum version
supported is 8.


  dpkg-buildpackage
  -
  
  Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot
  dpkg-buildpackage: info: source package surankco
  dpkg-buildpackage: info: source version 0.0.r5+dfsg-3
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Andreas Tille 
   dpkg-source --before-build .
  dpkg-buildpackage: info: host architecture amd64
   debian/rules clean
  dh clean --with javahelper
 jh_clean
 dh_clean
   debian/rules binary
  dh binary --with javahelper
 dh_update_autotools_config
 dh_autoreconf
 jh_linkjars
 debian/rules override_dh_auto_build
  make[1]: Entering directory '/<>'
  mv src/de/rki/ng4/surankco/data/Reads.java 
src/de/rki/ng4/surankco/data/Reads.java_ignore_at_build_time
  jh_build --javacopts='-target 1.7' --javacopts='-source 1.7' surankco.jar src
  jh_build: warning: Java machine does not support --release 7, using --release 
8
  warning: [options] bootstrap class path not set in conjunction with -source 7
  error: Source option 7 is no longer supported. Use 8 or later.
  jh_build: error: find src -name '*.java' -and -type f -print0 | xargs -s 
512000 -0 /usr/lib/jvm/default-java/bin/javac -g -cp 
/usr/share/java/htsjdk.jar:debian/_jh_build.surankco -d 
debian/_jh_build.surankco -source 1.7 -encoding ISO8859-1  returned exit code 
123
  make[1]: *** [debian/rules:16: override_dh_auto_build] Error 25
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:12: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2
  

Bug#1052475: libpam-mklocaluser: needs to be sorted-in before other session type PAM modules that might require the modified location of $HOME

[Mike Gabriel]

Package: libpam-mklocaluser
Severity: important:
Version: 0,18

While debugging an issue with Debian Edu roaming workstations and  
LightDM [1], it was discovered that libpam-mklocaluser needs to be  
sorted-in before other session type PAM modules are processed during  
PAM based authentication. Esp. it needs to be sorted in before  
pam_systemd.so gets processed.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029557

Upload fixing this will come soon. This issue should also be resolved  
in Debian bookworm.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpJPpNfXxlah.pgp
Description: Digitale PGP-Signatur

Bug#1052474: checker-framework-java: FTBFS with OpenJDK 21 due to new compiler warnings

[Emmanuel Bourg]

Source: checker-framework-java
Version: 3.2.0+ds-2
Severity: important
Tags: ftbfs sid trixie
User: debian-j...@lists.debian.org
Usertags: default-java21


checker-framework-java fails to build with OpenJDK 21, the code is compiled with
the -Werror flag and javac now emits new warnings, thus triggering an error:

  :javacutil:compileJava (Thread[#57,Task worker for ':' Thread 6,5,main]) 
started.
  :javacutil:compileJava
  Putting task artifact state for task ':javacutil:compileJava' into context 
took 0.0 secs.
  Replacing org.plumelib:plume-util:jar:1.1.0  ->  
org.plumelib:plume-util:jar:debian
  Passing through org.plumelib:reflection-util:jar:debian
  Passing through org.plumelib:hashmap-util:jar:debian
  Passing through org.checkerframework:checker-qual:jar:debian
  Up-to-date check for task ':javacutil:compileJava' took 0.134 secs. It is not 
up-to-date because:
No history is available.
  All input files are considered out-of-date for incremental task 
':javacutil:compileJava'.
  Compiling with JDK Java compiler API.
  
/<>/javacutil/src/main/java/org/checkerframework/javacutil/trees/TreeBuilder.java:130:
 warning: [cast] redundant cast to JCFieldAccess
  (JCTree.JCFieldAccess)
  ^
  
/<>/javacutil/src/main/java/org/checkerframework/javacutil/trees/TreeBuilder.java:166:
 warning: [cast] redundant cast to JCFieldAccess
  (JCTree.JCFieldAccess)
  ^
  
/<>/javacutil/src/main/java/org/checkerframework/javacutil/trees/TreeBuilder.java:222:
 warning: [cast] redundant cast to JCFieldAccess
  (JCTree.JCFieldAccess) maker.Select((JCTree.JCExpression) 
iteratorExpr, nextMethod);
  ^
  
/<>/javacutil/src/main/java/org/checkerframework/javacutil/trees/TreeBuilder.java:236:
 warning: [cast] redundant cast to JCFieldAccess
  return (JCTree.JCFieldAccess)
 ^
  
/<>/javacutil/src/main/java/org/checkerframework/javacutil/trees/TreeBuilder.java:418:
 warning: [cast] redundant cast to JCFieldAccess
  (JCTree.JCFieldAccess) maker.Select((JCTree.JCExpression) 
expr, valueOfMethod);
  ^
  
/<>/javacutil/src/main/java/org/checkerframework/javacutil/trees/TreeBuilder.java:482:
 warning: [cast] redundant cast to JCFieldAccess
  (JCTree.JCFieldAccess) maker.Select((JCTree.JCExpression) 
expr, primValueMethod);
  ^
  error: warnings found and -Werror specified
  1 error
  6 warnings
  :javacutil:compileJava FAILED

Bug#1052473: libgoogle-gson-java: FTBFS with OpenJDK 21 due to new compiler warnings

[Emmanuel Bourg]

Package: libgoogle-gson-java
Version: 2.10-1
Severity: important
Tags: ftbfs sid trixie
User: debian-j...@lists.debian.org
Usertags: default-java21


libgoogle-gson-java fails to build with OpenJDK 21, the code is compiled with
the -Werror flag and javac now emits new warnings, thus triggering an error:

  [INFO] -
  [WARNING] COMPILATION WARNING :
  [INFO] -
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/stream/JsonReader.java:[1609,21]
 implicit cast from int to char in compound assignment is possibly lossy
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/stream/JsonReader.java:[1611,21]
 implicit cast from int to char in compound assignment is possibly lossy
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/stream/JsonReader.java:[1613,21]
 implicit cast from int to char in compound assignment is possibly lossy
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/internal/$Gson$Types.java:[484,24]
 non-transient instance field of a serializable class declared with a 
non-serializable type
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/internal/$Gson$Types.java:[485,24]
 non-transient instance field of a serializable class declared with a 
non-serializable type
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/internal/$Gson$Types.java:[486,26]
 non-transient instance field of a serializable class declared with an array 
having a non-serializable base component type java.lang.reflect.Type
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/internal/$Gson$Types.java:[553,24]
 non-transient instance field of a serializable class declared with a 
non-serializable type
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/internal/$Gson$Types.java:[587,24]
 non-transient instance field of a serializable class declared with a 
non-serializable type
  [WARNING] 
/<>/gson/src/main/java/com/google/gson/internal/$Gson$Types.java:[588,24]
 non-transient instance field of a serializable class declared with a 
non-serializable type
  [INFO] 9 warnings
  [INFO] -
  [INFO] -
  [ERROR] COMPILATION ERROR :
  [INFO] -
  [ERROR] 
/<>/gson/src/main/java/com/google/gson/stream/JsonReader.java: 
warnings found and -Werror specified
  [INFO] 1 error
  [INFO] -

Bug#1052472: linux-image-6.5.0-1-powerpc64: Can't run program if its executable file was made immutable via chattr(1)

[WHR]

Package: src:linux
Version: 6.5.3-1
Severity: normal
X-Debbugs-Cc: msl023...@gmail.com, msl023...@gmail.com


Taking executable file /usr/bin/ssh to demonstrate the issue:

# which ssh
/usr/bin/ssh
# ssh   
   
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
   [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
   [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
   [-i identity_file] [-J [user@]host[:port]] [-L address]
   [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p 
port]
   [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
   [-w local_tun[:remote_tun]] destination [command]
# chattr +i /usr/bin/ssh
   
# ssh
Segmentation fault


By trying to load the program via ld.so(1) with truss (actually strace), it 
shows that a mmap(2) call used to load the data segument failed due to EPERM:

# truss -s 128 -f /lib/powerpc64-linux-gnu/ld64.so.1 /usr/bin/ssh
execve("/lib/powerpc64-linux-gnu/ld64.so.1", 
["/lib/powerpc64-linux-gnu/ld64.so.1", "/usr/bin/ssh"], 0x7fffc0380530 /* 29 
vars */) = 0
brk(NULL)   = 0x1000db6
openat(AT_FDCWD, "/usr/bin/ssh", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\22h\220\0\0\0\0\0\0\0@\0\0\0\0\0\22\4\330\0\0\0\1\0@\08\0\t\0@\0\35\0\34\0\0\0\6\0\0\0\4\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\1\370\0\0\0\0\0\0\1\370\0\0\0\0\0\0\0\10\0\0\0\3\0\0\0\4"...,
 832) = 832
mmap(NULL, 1259760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7fff9372
mprotect(0x7fff9383, 65536, PROT_NONE) = 0
mmap(0x7fff9384, 131072, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11) = -1 EPERM (Operation not 
permitted)
close(3)= 0
writev(2, [{iov_base="/usr/bin/ssh", iov_len=12}, {iov_base=": ", 
iov_len=2}, {iov_base="error while loading shared libraries", iov_len=36}, 
{iov_base=": ", iov_len=2}, {iov_base="/usr/bin/ssh", iov_len=12}, {iov_base=": 
", iov_len=2}, {iov_base="failed to map segment from shared object", 
iov_len=40}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0}, 
{iov_base="\n", iov_len=1}], 10/usr/bin/ssh: error while loading shared 
libraries: /usr/bin/ssh: failed to map segment from shared object
) = 107
exit_group(127) = ?
+++ exited with 127 +++


I can also reproduce this issue on Bullseye (with Linux 5.10.0-21-amd64);
while Buster (Linux 4.19.0-23-amd64) is fine.



-- Package-specific info:
** Version:
Linux version 6.5.0-1-powerpc64 (debian-ker...@lists.debian.org) (gcc-13 
(Debian 13.2.0-4) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP Debian 
6.5.3-1 (2023-09-13)

** Command line:
root=ZFS=zr/ROOT/debiansid-be ro quiet 
cgroup_enable=cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,perf_event,net_prio
 systemd.unified_cgroup_hierarchy=0 
net.ifname-policy=keep,onboard,slot,path,kernel zfs.zfs_txg_timeout=60 
zfs.zfs_arc_max=2166172771 init=/init

** Tainted: PDO (4225)
 * proprietary module was loaded
 * kernel died recently, i.e. there was an OOPS or BUG
 * externally-built ("out-of-tree") module was loaded

** Kernel log:
[ 9345.731918] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9345.731916] ata16: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9345.732177] ata16.00: configured for UDMA/66
[ 9345.732243] ata8.00: configured for UDMA/66
[ 9346.079899] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9346.079900] ata16: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9346.080160] ata16.00: configured for UDMA/66
[ 9346.080225] ata8.00: configured for UDMA/66
[ 9346.427890] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9346.427891] ata16: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9346.428151] ata8.00: configured for UDMA/66
[ 9346.428217] ata16.00: configured for UDMA/66
[ 9346.771879] ata16: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9346.771879] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9346.772139] ata8.00: configured for UDMA/66
[ 9346.772204] ata16.00: configured for UDMA/66
[ 9347.115855] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9347.115856] ata16: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9347.116116] ata16.00: configured for UDMA/66
[ 9347.116182] ata8.00: configured for UDMA/66
[ 9347.467841] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9347.467842] ata16: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 9347.468102] ata16.00: configured for UDMA/66
[ 9347.468166] ata8.00: configured for UDMA/66
[ 9347.811831] ata8: SATA link 

Bug#1052471: mmdebstrap: with libpam-tmpdir, fails to use temp dir created by --format=tar/squashfs/ext2/null code: Permission denied

[Paul Wise]

Package: mmdebstrap
Version: 1.3.8-3
Severity: normal

The code for --format=tar/squashfs/ext2/null creates a temporary
directory in the $TMP dir. When libpam-tmpdir is being used, $TMP
is set to a directory that the current user can access but no other
user can access. Consequently because mmdebstrap uses a separate user
namespace(?) it cannot access the temporary dir it just created. In
addition, it fails to clean up that temporary dir after the error.

This does not happen when TMP is set to /tmp with libpam-tmpdir off.

Probably the solution would be to reset TMP to /tmp when the current
value isn't usable after the namespace change, or to create the
temporary dir in the same directory as the output if there is one.

The same should happen to the TMPDIR/TEMP/TEMPDIR variables,
since usage of TMP is not universal across all packages.

$ env | grep -E 'TE?MP'
TEMPDIR=/tmp/user/1000
TMPDIR=/tmp/user/1000
TEMP=/tmp/user/1000
TMP=/tmp/user/1000

$ ls -ld /tmp /tmp/user /tmp/user/1000
drwxrwxrwt 25 root root  16K Sep 22 23:39 /tmp/
drwx--x--x  7 root root 4.0K Sep 16 13:22 /tmp/user/
drwx-- 16 pabs root 4.0K Sep 22 23:51 /tmp/user/1000/

$ mmdebstrap unstable /dev/null
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/user/1000/mmdebstrap.mAT11ELelW as tempdir
E: cannot create /tmp/user/1000/mmdebstrap.mAT11ELelW: Permission denied; 
cannot create /tmp/user/1000/mmdebstrap.mAT11ELelW//etc: Permission denied; 
cannot create /tmp/user/1000/mmdebstrap.mAT11ELelW//etc/apt: Permission denied; 
cannot create /tmp/user/1000/mmdebstrap.mAT11ELelW//etc/apt/apt.conf.d: 
Permission denied
I: main() received signal PIPE: waiting for setup...
I: removing tempdir /tmp/user/1000/mmdebstrap.mAT11ELelW...
env: cannot change directory to '/tmp/user/1000/mmdebstrap.mAT11ELelW': 
Permission denied
E: rm failed: 32000
E: remove_tree failed

$ echo $?
29

$ find /tmp/user/1000/mmdebstrap.mAT11ELelW
/tmp/user/1000/mmdebstrap.mAT11ELelW

$ ls -ld /tmp/user/1000/mmdebstrap.mAT11ELelW
drwxr-xr-x 2 296608 296608 4.0K Sep 22 23:54 
/tmp/user/1000/mmdebstrap.mAT11ELelW

$ rmdir /tmp/user/1000/mmdebstrap.mAT11ELelW

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages mmdebstrap depends on:
ii  apt  2.7.3
ii  perl 5.36.0-9
ii  python3  3.11.4-5+b1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.32.1-1
ii  gpg  2.2.40-1.1
ii  libdistro-info-perl  1.5
ii  libdpkg-perl 1.22.0
ii  mount2.39.2-1
ii  pseudo [fakeroot]1.9.0+git20230301+ec6151a2b057-1
ii  uidmap   1:4.13+dfsg1-1+b1

Versions of packages mmdebstrap suggests:
ii  apt-transport-tor  0.5
ii  apt-utils  2.7.3
ii  binfmt-support 2.2.2-2
ii  ca-certificates20230311
ii  debootstrap1.0.132
ii  distro-info-data   0.58
ii  dpkg-dev   1.22.0
ii  genext2fs  1.5.0-3
ii  perl-doc   5.36.0-9
pn  qemu-user  
ii  qemu-user-static   1:8.1.0+ds-6
ii  squashfs-tools-ng  1.2.0-1
ii  systemd254.1-3

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#967320: dvdisaster: depends on deprecated GTK 2

[Bastian Germann]

The first patch version was missing build dependency libgdk-pixbuf2.0-bin that 
was implied by the former libgtk2.0-dev.
I am attaching a 2nd version.From a0cdbfc7f7f02dd64e160fb398002f03fd2e8abd Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Fri, 22 Sep 2023 17:30:59 +0200
Subject: Drop GUI (Closes: #967320)

---
 debian/control| 3 ++-
 debian/dvdisaster.install | 1 -
 debian/rules  | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index caefe67..11b03dd 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,8 @@ Uploaders: TANIGUCHI Takaki ,
 Build-Depends: debhelper (>= 12),
gettext,
libbz2-dev,
-   libgtk2.0-dev,
+   libglib2.0-dev,
+   libgdk-pixbuf2.0-bin,
libpng-dev,
pkg-config
 Build-Depends-Indep: texlive-fonts-recommended ,
diff --git a/debian/dvdisaster.install b/debian/dvdisaster.install
index ae9e496..bacc64e 100644
--- a/debian/dvdisaster.install
+++ b/debian/dvdisaster.install
@@ -1,4 +1,3 @@
-contrib/dvdisaster.desktop usr/share/applications
 usr/bin
 usr/share/icons
 usr/share/locale
diff --git a/debian/rules b/debian/rules
index 164fcee..27818aa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,6 +41,7 @@ override_dh_auto_configure:
 		--localedir=share/locale \
 		--docdir=share/doc \
 		--docsubdir=dvdisaster \
+		--with-gui=no \
 		--with-embedded-src-path=no
 
 override_dh_auto_build-arch:

Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package

[Russ Allbery]

Jonathan Kamens  writes:

> 2. Download a bazel binary from
>https://github.com/bazelbuild/bazelisk/releases and make it
>executable in your search path

This is going to be the biggest obstacle in the way of any proper fix for
this bug.

All Debian packages in main must be built with tools that are already
packaged in Debian main.  This is a hard requirement that we will not
change under any circumstances; it goes to the heart of what Debian is and
what it means to be a distribution.  Bazel is *incredibly* difficult to
support in Debian because it is a massive Java and C++ application with a
bunch of other dependencies and complex bootstrapping requirements.  I see
there are some Bazel packages now in the archive, but I don't believe
they're a complete Bazel system.  The work was being coordinated at
https://salsa.debian.org/bazel-team but it looks like it may have stalled
based on the last commit times.

It sounds from your summary like packaging Selenium Manager will first
require packaging Bazel, which I believe has been attempted before without
complete success, or rewriting the upstream build system to not use Bazel.
I believe this is also blocking inclusion of tensorflow in Debian
(although there may be some forward progress there by using CMake instead
of Bazel), so you are not alone in wanting this, but also if it were
striaghtforward we would have done it already.

If it's possible to build Selenium Manager directly with Cargo, that may
bypass this part of the problem and would make the problem more tractable,
but that would presumably require some research since it sounds like
that's not what upstream is recommending.  (And someone would still need
to ensure that any Rust crates it depends on are packaged.)

None of this is a problem created by the maintainer and overriding the
maintainer will not help.  Someone will have to do this work, and it is
very far from trivial.

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

Bug#1052470: nodejs: Please fix testsuite for openssl-3.1

[Sebastian Andrzej Siewior]

Package: nodejs
Version: 18.13.0+dfsg1-1
Severity: important
Tags: patch

The nodejs version in unstable FTBFS against openssl 3.1 due to the
testsuite. I had something working and then looked in the upstream git
and backported their against the packaging master-18.x branch. Hopefully
this makes less work for everyone. One patch is for upstream, one I made
myself.
Now I'm about to test this… But it looks promising ;)

Sebastian
From 85aa9556000424fcde6748bed969a01e864be266 Mon Sep 17 00:00:00 2001
From: OttoHollmann 
Date: Thu, 1 Jun 2023 16:52:53 +0200
Subject: [PATCH 1/2] test: adapt tests for OpenSSL 3.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

PR-URL: https://github.com/nodejs/node/pull/47859
Reviewed-By: Tobias Nießen 
Reviewed-By: Richard Lau 
(cherry picked from commit 5f283722072e400234d3e15f1f2caa2ca2fd8d60)
Signed-off-by: Sebastian Andrzej Siewior 
---
 test/common/index.js |  6 +-
 .../test-https-agent-session-eviction.js |  1 +
 test/parallel/test-tls-alert.js  |  1 +
 test/parallel/test-tls-getprotocol.js| 16 +---
 test/parallel/test-tls-min-max-version.js|  3 +++
 test/parallel/test-tls-session-cache.js  |  1 +
 6 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/test/common/index.js b/test/common/index.js
index e0c6e7aa0c996..35c3eac6481b3 100644
--- a/test/common/index.js
+++ b/test/common/index.js
@@ -56,7 +56,10 @@ const hasCrypto = Boolean(process.versions.openssl) &&
   !process.env.NODE_SKIP_CRYPTO;
 
 const hasOpenSSL3 = hasCrypto &&
-require('crypto').constants.OPENSSL_VERSION_NUMBER >= 805306368;
+require('crypto').constants.OPENSSL_VERSION_NUMBER >= 0x3000;
+
+const hasOpenSSL31 = hasCrypto &&
+require('crypto').constants.OPENSSL_VERSION_NUMBER >= 0x3010;
 
 const hasQuic = hasCrypto && !!process.config.variables.openssl_quic;
 
@@ -899,6 +902,7 @@ const common = {
   hasIntl,
   hasCrypto,
   hasOpenSSL3,
+  hasOpenSSL31,
   hasQuic,
   hasMultiLocalhost,
   invalidArgTypeHelper,
diff --git a/test/parallel/test-https-agent-session-eviction.js b/test/parallel/test-https-agent-session-eviction.js
index 940c43cc40bf1..36c360a96503d 100644
--- a/test/parallel/test-https-agent-session-eviction.js
+++ b/test/parallel/test-https-agent-session-eviction.js
@@ -54,6 +54,7 @@ function faultyServer(port) {
 function second(server, session) {
   const req = https.request({
 port: server.address().port,
+ciphers: (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT'),
 rejectUnauthorized: false
   }, function(res) {
 res.resume();
diff --git a/test/parallel/test-tls-alert.js b/test/parallel/test-tls-alert.js
index 31b07104c241a..04000771aa977 100644
--- a/test/parallel/test-tls-alert.js
+++ b/test/parallel/test-tls-alert.js
@@ -42,6 +42,7 @@ const server = tls.Server({
   cert: loadPEM('agent2-cert')
 }, null).listen(0, common.mustCall(() => {
   const args = ['s_client', '-quiet', '-tls1_1',
+'-cipher', (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT'),
 '-connect', `127.0.0.1:${server.address().port}`];
 
   execFile(common.opensslCli, args, common.mustCall((err, _, stderr) => {
diff --git a/test/parallel/test-tls-getprotocol.js b/test/parallel/test-tls-getprotocol.js
index d45287d671d8a..7da2f60676d00 100644
--- a/test/parallel/test-tls-getprotocol.js
+++ b/test/parallel/test-tls-getprotocol.js
@@ -11,9 +11,18 @@ const tls = require('tls');
 const fixtures = require('../common/fixtures');
 
 const clientConfigs = [
-  { secureProtocol: 'TLSv1_method', version: 'TLSv1' },
-  { secureProtocol: 'TLSv1_1_method', version: 'TLSv1.1' },
-  { secureProtocol: 'TLSv1_2_method', version: 'TLSv1.2' },
+  {
+secureProtocol: 'TLSv1_method',
+version: 'TLSv1',
+ciphers: (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT')
+  }, {
+secureProtocol: 'TLSv1_1_method',
+version: 'TLSv1.1',
+ciphers: (common.hasOpenSSL31 ? 'DEFAULT:@SECLEVEL=0' : 'DEFAULT')
+  }, {
+secureProtocol: 'TLSv1_2_method',
+version: 'TLSv1.2'
+  },
 ];
 
 const serverConfig = {
@@ -30,6 +39,7 @@ const server = tls.createServer(serverConfig, common.mustCall(clientConfigs.leng
 tls.connect({
   host: common.localhostIPv4,
   port: server.address().port,
+  ciphers: v.ciphers,
   rejectUnauthorized: false,
   secureProtocol: v.secureProtocol
 }, common.mustCall(function() {
diff --git a/test/parallel/test-tls-min-max-version.js b/test/parallel/test-tls-min-max-version.js
index 5cea41ca7e0bd..ab351558a4c8b 100644
--- a/test/parallel/test-tls-min-max-version.js
+++ b/test/parallel/test-tls-min-max-version.js
@@ -22,6 +22,9 @@ function test(cmin, cmax, cprot, smin, smax, sprot, proto, cerr, serr) {
 if (serr !== 'ERR_SSL_UNSUPPORTED_PROTOCOL')
   ciphers = 'ALL@SECLEVEL=0';
   }
+  if (common.hasOpenSSL31 && cerr === 

Bug#1052469: default resolution is too high, fonts too small

[Pirate Praveen]

package: plasma-mobile
version: 5.27.6-1
severity: important

With recent apt dist-upgrade the default resolution of plasma mobile is 
too high and applications open in desktop mode. This was working 
earlier, I wonder if mobian has some patches to set correct resolution.

Bug#1003192: debian-edu-config: /etc/login.defs not adjusted for Debian Edu like /etc/adduser.conf

[Mike Gabriel]

On  Fr 22 Sep 2023 13:04:11 UTC, Guido Berhoerster wrote:

On Fri, 22 Sep 2023 13:57:09 +0200 Guido Berhoerster  
 wrote:



- change the DebianEdu scheme giving LDAP users a UID/GIDs range
  2000-6 or similar


imho, we should default to 2000 as first LDAP uidNumber and gidNumber.

Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

Bug#967320: dvdisaster: depends on deprecated GTK 2

[Bastian Germann]

Control: tags -1 patch

Am 15.08.23 um 15:38 schrieb Bastian Germann:
Upstream version 0.79.10 comes with this change: "Added --with-gui=no option to build a command line version without GTK 
linkage."


Please find a patch attached. It applies on the changes that I have made in
https://salsa.debian.org/optical-media-team/dvdisaster/-/merge_requests/3
From 0ac5c92c10d159e8632b061fb57ddbd296a898c5 Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Fri, 22 Sep 2023 17:30:59 +0200
Subject: [PATCH] Drop GUI (Closes: #967320)

---
 debian/control| 2 +-
 debian/dvdisaster.install | 1 -
 debian/rules  | 1 +
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index caefe67..18e6ebb 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Uploaders: TANIGUCHI Takaki ,
 Build-Depends: debhelper (>= 12),
gettext,
libbz2-dev,
-   libgtk2.0-dev,
+   libglib2.0-dev,
libpng-dev,
pkg-config
 Build-Depends-Indep: texlive-fonts-recommended ,
diff --git a/debian/dvdisaster.install b/debian/dvdisaster.install
index ae9e496..bacc64e 100644
--- a/debian/dvdisaster.install
+++ b/debian/dvdisaster.install
@@ -1,4 +1,3 @@
-contrib/dvdisaster.desktop usr/share/applications
 usr/bin
 usr/share/icons
 usr/share/locale
diff --git a/debian/rules b/debian/rules
index 164fcee..27818aa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,6 +41,7 @@ override_dh_auto_configure:
 		--localedir=share/locale \
 		--docdir=share/doc \
 		--docsubdir=dvdisaster \
+		--with-gui=no \
 		--with-embedded-src-path=no
 
 override_dh_auto_build-arch:
-- 
2.40.1

Bug#1041999: tgt: Drop glusterfs support for 32-bit architectures

[Michael Prokop]

* Patrick Matthäi [Tue Jul 25, 2023 at 04:00:46PM +0200]:
>
> because of the bug #1039604 [0] I will drop glusterfs completly from
> non x64 architectures. You package has a reverse dependency on.
> 
> So you should change your (build)-dependeny e.g. on libglusterfs-dev to:
>   libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 
> sparc64]
> 
> In experimental with glusterfs 11.0-1 the !x64 support has been already 
> dropped.
> I plan to upload it to unstable after the reverse dependencies are fixed.
> 
> If you need help, please let me know :)
> 
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039604

This is available as MR now:
https://salsa.debian.org/debian/tgt/-/merge_requests/2

Apollon, could you please merge and upload this, so we get tgt back
to Debian/testing?

regards
-mika-


signature.asc
Description: PGP signature

Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game

[James Addison]

Package: wnpp
Followup-For: Bug #1026277
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org

Hi folks,

I've been fairly inactive re: Debian contributions since bookworm was released,
but would like to get involved again.

Would anyone be willing to sponsor my package 'quadrilateralcowboy'?

I'd spent a bit of time earlier this year packaging it for Debian, a process
that resulted in creation of a fork[1] and a corresponding Salsa repo[2].

The game data is available using game-data-packager, and I've playtested the
amd64 build.  Theoretically arm64 is available too, but I haven't playedtested
that.

Cheers,
James

[1] - https://github.com/jayaddison/quadrilateralcowboy/

[2] - https://salsa.debian.org/jayaddison/quadrilateralcowboy/

Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0

[Michael Prokop]

* Adrian Bunk [Fri Jul 14, 2023 at 09:19:31PM +0300]:
> Source: thin-provisioning-tools
> Version: 0.9.0-2
> Severity: serious
> Tags: ftbfs trixie sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/thin-provisioning-tools.html
> 
> ...
> In file included from 
> /usr/src/googletest/googletest/include/gtest/gtest-message.h:57,
>  from 
> /usr/src/googletest/googletest/include/gtest/gtest-assertion-result.h:46,
>  from /usr/src/googletest/googletest/include/gtest/gtest.h:64,
>  from /usr/src/googletest/googletest/src/gtest-all.cc:38:
> /usr/src/googletest/googletest/include/gtest/internal/gtest-port.h:270:2: 
> error: #error C++ versions less than C++14 are not supported.
>   270 | #error C++ versions less than C++14 are not supported.
>   |  ^
> ...
> 
> 
> 
> This can be fixed by changing the two -std=c++11 to -std=c++14
> in unit-tests/Makefile.in

Thanks, Adrian. Available as MR now:
https://salsa.debian.org/lvm-team/thin-provisioning-tools/-/merge_requests/3

Bastian, could you please merge and upload it, so we get
thin-provisioning-tools back in Debian/testing?

regards
-mika-



signature.asc
Description: PGP signature

Bug#1052445: Transition: libpqxx 6.4->7.8

[Christoph Berg]

Re: Maarten van Geijn
> Hi Christoph,
> 
> Thanks for pointing this out.
> Yes, this is intended as pre-approval request for the transition into sid. I
> got this https://wiki.debian.org/Teams/ReleaseTeam/Transitions site, from
> which I understood that a bug-report on this was necessary for the sid
> upload, but perhaps I misunderstood.

Yes, a bug report on the "release.debian.org" pseudo package.

(You can reassign this bug, or open a new one.)

Christoph

Bug#1052445: Transition: libpqxx 6.4->7.8

[Maarten van Geijn]

Hi Christoph,

Thanks for pointing this out.
Yes, this is intended as pre-approval request for the transition into 
sid. I got this https://wiki.debian.org/Teams/ReleaseTeam/Transitions 
site, from which I understood that a bug-report on this was necessary 
for the sid upload, but perhaps I misunderstood.


I will discuss with Teus on uploads.

Regards
Maarten

On 22/09/2023 13:31, Christoph Berg wrote:

Re: Maarten van Geijn

Dear Release Team,


Hi Maarten,

you filed this on the libpqxx package, the release team won't see it
there.

Is this the pre-approval request for the transition?


Package libpqxx has a new update from upstream in experimental.

Checked sqlsmith and osm2pgrouting source packages, which seem to be unaffected.

Ben information:
 Affected: .depends ~ /\b(libpqxx\-7\.8|libpqxx\-6\.4)\b/
 Good: .depends ~ /\b(libpqxx\-7\.8)\b/
 Bad: .depends ~ /\b(libpqxx\-6\.4)\b/


The automatic tracker got that right already:

https://release.debian.org/transitions/html/auto-libpqxx.html


Request scheduled binNMU for libpqxx into sid.


You need to actually upload libpqxx to sid, it won't transition like
sid->testing works.

BinNMUs can then take care of the two rdeps.

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052462: parted: libparted2 package dependencies (dmidecode) differ between arm64 and amd64

[Colin Watson]

On Fri, Sep 22, 2023 at 03:41:53PM +0100, Phil Roche wrote:
> While working on new arm64 Ubuntu 23.10 Mantic minimal cloud images
> (http://cloud-images.ubuntu.com/minimal/daily/mantic/) we discovered that
> `dmidecode` was not being installed in the arm64 images.
> 
> In debugging, I found that the package dependencies of the libparted2
> package
> differ between arm64 and amd64. arm64 `libparted2` does not depend on
> `dmidecode` but on amd64 it does.

This is intentional, because libparted only uses dmidecode for
identifying old Intel Macs with special GPT quirks, and that's only
relevant on x86.  I don't personally see why this needs to be extended
to arm64, although of course if somebody comes forward and explicitly
confirms that it's relevant to partitioning on Apple Silicon or whatever
then we could do that - but I wouldn't do it just for architectural
symmetry.

If you explicitly need dmidecode to be on your images, then I think you
should have an explicit dependency or similar to ensure that, rather
than relying on a dependency via libparted (which is an implementation
detail).  Is that a problem?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1020217: S3-backed snapshot implementation on AWS?

[Bastian Blank]

Hi Lucas

On Fri, Sep 22, 2023 at 08:42:10AM +0200, Lucas Nussbaum wrote:
> Could we use the Debian AWS account to host that service?

I would assume that a service like snapshot would be within the scope
for our AWS usage.  Noah?

>   It would
> require one fairly powerful VM, and a large S3 bucket (approximately
> 150-200 TB).

200 TB should be no problem.

However we need to talk about that "one […] VM", because this sounds
like you intend to use AWS as VM hosting, which it is not.

Please think about this in form of services and there should be at least
two:
- the injestor, which can only exist once and writes, and
- the web frontend, which should be able to exist several times and only
  reads.

So you want to plan with running the multiple web frontends with load
balancers and maybe even cloudfront.

Regards,
Bastian

-- 
I object to intellect without discipline;  I object to power without
constructive purpose.
-- Spock, "The Squire of Gothos", stardate 2124.5

Bug#1052467: transition: svt-av1

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for svt-av1.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-svt-av1.html

All reverse deps (ffmpeg, libavif and libheif) build fine with the new version
in experimental.

Thanks,
Dylan

Bug#1052466: OOM killed

[Philipp Marek]

Package: pipewire
Version: 0.3.80-2
Severity: normal
X-Debbugs-Cc: phil...@marek.priv.at

I just got my pipewire process OOM killed:

[62615.563546] 
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service,task=pipewire,pid=2550,uid=1000
[62615.563573] Out of memory: Killed process 2550 (pipewire) 
total-vm:22028128kB, anon-rss:21793560kB, file-rss:3972kB, shmem-rss:1204kB, 
UID:1000 pgtables:42860kB oom_score_adj:200

The interesting part is that the process is started with a user-account,
but the ulimits set via /etc/security/limits.conf on this account 
(respectively all, because of using "*" as domain there) are not used:


$ cat /proc/159204/limits
Limit Soft Limit   Hard Limit   Units
Max cpu time  unlimitedunlimitedseconds
Max file size unlimitedunlimitedbytes
Max data size 337920   389120   bytes
Max stack sizeunlimitedunlimitedbytes
Max core file size0unlimitedbytes
Max resident set  337920   399360   bytes
Max processes 127626   127626   
processes
Max open files1024 1048576  files
Max locked memory 4192755712   4192755712   bytes
Max address space 32768000 33792000 bytes
Max file locksunlimitedunlimitedlocks
Max pending signals   127626   127626   signals
Max msgqueue size 819200   819200   bytes
Max nice priority 00
Max realtime priority 95   95
Max realtime timeout  20   20   us

$ ulimit -aH
real-time non-blocking time  (microseconds, -R) unlimited
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) 380
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 127626
max locked memory   (kbytes, -l) 4094488
max memory size (kbytes, -m) 390
open files  (-n) 1048576
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 95
stack size  (kbytes, -s) unlimited
cpu time   (seconds, -t) unlimited
max user processes  (-u) 127626
virtual memory  (kbytes, -v) 33000
file locks  (-x) unlimited

Please have at least /usr/lib/systemd/user/pipewire.service use some
limits to avoid running-away memory allocations -- it's quite boring
to wait for the OOM kill.


The root cause isn't quite clear - I used qpwgraph to connect the 
microphone to the speaker output, but there's nothing in the logs
that would help diagnose any further.


Thanks!


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

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

Versions of packages pipewire depends on:
ii  adduser  3.137
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.80-2
ii  pipewire-bin 0.3.80-2

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: can't check pipewire:amd64 file /usr/share/doc/pipewire/NEWS.gz (Wide 
character in subroutine entry)
debsums: can't check pipewire:amd64 file 
/usr/share/doc/pipewire/README.Debian.gz (Wide character in subroutine entry)
debsums: can't check pipewire:amd64 file 
/usr/share/doc/pipewire/changelog.Debian.gz (Wide character in subroutine entry)

Bug#1052465: thin-provisioning-tools: New upstream version v1.0.6 available

[Michael Prokop]

Package: thin-provisioning-tools
Version: 0.9.0-2
Severity: wishlist

Hi,

version 1.0.6 is available since 2023-08-09:
https://github.com/jthornber/thin-provisioning-tools/tags

FTR: upstream seemed to have rewritten it in Rust (see
https://github.com/jthornber/thin-provisioning-tools/blob/main/CHANGES )

regards
-mika-

Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package

[Helmut Grohne]

Hello Jonathan,

On Fri, Sep 22, 2023 at 09:50:51AM -0400, Jonathan Kamens wrote:
> The current python3-selenium package does not include all of the
> components that the vendor expects to be included in the package, and
> as a result it does not work. This is a regression from previous
> versions of the package, i.e., it was working just fine and then
> stopped working at all in the new release. The workaround suggested by
> the maintainer of the package is inconsistent with the vendor's
> expectations and in my opinion inadequate. There is a straightforward
> fix which the package maintainer has declined, without explanation, to
> implement.

Let me observe that in quite some cases, Debian packages do not include
the full functionality that upstream provides. This can have various
reasons such as licensing, porting and other trade-offs. Such reduction
of functionality usually is left at the discretion of the maintainer.

> Additional details
> 
> The current version of the Selenium bindings for all supported
> programming languages relies on a Rust executable called Selenium
> Manager for managing the webdriver executables required for the
> various browsers that the bindings interact with. This Rust program is
> intended to be packaged and shipped with the Selenium bindings, as
> indicated by the facts that (a) it is included in the official PyPI
> packages for the Python bindings and (b) the maintainers of Selenium
> state this explicitly. Quoting from
> https://www.selenium.dev/documentation/selenium_manager/ :
> 
> "Selenium bindings use this tool by default, so you do not need to
> download it or add anything to your code or do anything else to use
> it. ... Selenium Manager is the official driver manager of the
> Selenium project, and it is shipped out of the box with every Selenium
> release."

Thank you for providing the background.

> While I don't much care for the fact that the maintainers of Selenium
> have opted to make all of the language bindings depend on a compiled
> executable written in a different language, this is the technical
> decision that they've made, and it's their prerogative.

In essence, this is an upstream decision. Debian may have a different
idea on this. Usually, deviating from upstream is not welcome, so there
should be good reasons for doing so.

> When Selenium Manager is not included with the language binding, it
> fails to find the webdriver executables it needs and stops working
> unless the developer modifies their code to explicitly say where the
> executable is located, the workaround suggested by the
> python3-selenium package maintainer in README.Debian. This makes the
> affected Selenium code non-portable, when the whole point of Selenium
> Manager is to increase code portability rather than decreasing it. In
> addition, the only way the developer has to know they need to do this
> on Debian is to find and read the README.Debian file, which (a) most
> developers aren't going to think to do and (b) due to a packaging
> error wasn't even included in the python3-selenium package.

Reading up the bug log indicates to me that Carsten refuses to do the
work to package the Selenium Manager. This is his constitutional right.
He suggested filing an RFP bug, which indicates that he is not opposed
to including the Selenium Manager in Debian and merely is opposed to
doing the necessary work.

> As I noted in ticket 1051368, building Selenium Manager so that it can
> be included in the package is straightforward. In particular, it
> requires just four steps:
> 
> 1. Download the Selenium source code from GitHub or somewhere else it
>is published
> 
> 2. Download a bazel binary from
>https://github.com/bazelbuild/bazelisk/releases and make it
>executable in your search path

This second step seems incompatible with established Debian processes
such as DFSG item 2.

> 3. Unpack the Selenium source code
> 
> 4. Run "bazel build //rust:selenium-manager" in the top directory of
>the Selenium source code
> 
> After these four steps, the Selenium Manager is available for
> packaging in bazel-bin/rust/selenium-manager.

It seems quite evident that the primary disagreement here is about what
it takes to package Selenium Manager rather than whether it should be
included. This is also evident from your previous bug not having been
closed by Carsten.

> It does not seem like this is too much work for Debian's
> python3-selenium package build scripts to do.

I think this and the question of who will be doing the work is the core
disagreement here.

In effect, you are asking the CTTE to overrule a maintainer. If
successful, that could authorize you to change the selenium package in
the way you would like to see.

Such a decision does not usually come about on vague terms. Quite to the
contrary, the CTTE is supposed to choose among available solutions. One
obviously available solution is the status quo that you dislike. The
other solution that you project is not 

Bug#1004070: linux-image-4.19.0-18-amd64: kernel crashes when accessing files via nfs

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo unreproducible

Hi,

On Mon, Jan 23, 2023 at 12:55:18PM +0100, Friedrich Beckmann wrote:
> Hi Salvatore,
> 
> thanks for asking! If I remember correctly later kernels did not
> work at the time when I tested this. But have not tried more recent
> 4.19.x kernel. At the moment I do not have that much time but I will
> share the results here once I test that.

Were you able to test current kernel in buster or even newer from a
regular Debian supported release? 

Regards,
Salvatore

Bug#1052464: x11-apps: [xwd] cannot capture Steam windows

[Simon Richter]

Package: x11-apps
Version: 7.7+9
Severity: normal
Tags: upstream

Hi,

Using

xwd -out steam.xwd

and clicking on any window opened by Steam gives

X Error of failed request:  BadColor (invalid Colormap parameter)
  Major opcode of failed request:  91 (X_QueryColors)
  Resource id in failed request:  0x0
  Serial number of failed request:  271
  Current serial number in output stream:  271

The resulting file is empty. This also happens when -icmap is specified.

   Simon

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages x11-apps depends on:
ii  libc62.36-9+deb12u1
ii  libpng16-16  1.6.39-2
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libx11-xcb1  2:1.8.4-2+deb12u1
ii  libxaw7  2:1.0.14-1
ii  libxcb-damage0   1.15-1
ii  libxcb-present0  1.15-1
ii  libxcb-xfixes0   1.15-1
ii  libxcb1  1.15-1
ii  libxcursor1  1:1.2.1-1
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxi6   2:1.8-1+b1
ii  libxkbfile1  1:1.1.0-1
ii  libxmu6  2:1.1.3-3
ii  libxmuu1 2:1.1.3-3
ii  libxrender1  1:0.9.10-1.1
ii  libxt6   1:1.2.1-1.1
ii  man-db   2.11.2-2

Versions of packages x11-apps recommends:
ii  xbitmaps  1.1.1-2.2

Versions of packages x11-apps suggests:
ii  mesa-utils  8.5.0-1

-- no debconf information

Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package

[Matthew Vernon]

Hi,

On 22/09/2023 14:50, Jonathan Kamens wrote:


The current version of the Selenium bindings for all supported
programming languages relies on a Rust executable called Selenium
Manager for managing the webdriver executables required for the
various browsers that the bindings interact with.


Selenium upstream has one git repository - 
https://github.com/SeleniumHQ/selenium


which contains bindings for python (packaged in Debian as 
python3-selenium), ruby (packaged in Debian as ruby-selenium-webdriver), 
and C#/Java/Javascript (not AFAICT packaged in Debian) as well as the 
Selenium Manager, which is a rust CLI tool.


I agree that having the Manager available in Debian would enhance the 
experience of python and ruby Selenium users.


From the upstream changelog, it seems that version 4.11 is where 
searching for drivers is done via the Manager:


* Use Selenium Manager to locate drivers on PATH
[ https://github.com/SeleniumHQ/selenium/pull/12356 ]

...and the Ruby bindings have a similar entry. But the latest version of 
ruby-selenium-webdriver in Debian is 4.4, so that issue hasn't bitten yet.


I'm afraid your analysis of how selenium manager might be made available 
in Debian is incorrect, however. It would need to be built like any 
other Rust program - with a source package and so on (Debian packages 
cannot download things from the internet during their build process); 
and the various rust dependencies would also need packaging if they're 
not already available in Debian.


This is quite a lot of work, and I can quite see that the (presumably) 
python specialists who have packaged python3-selenium would not feel 
able to take on that Rust work.


An alternative approach might be to patch python3-selenium to search 
PATH for drivers (as I think it did before that functionality was moved 
to the manager) - I'd be interested to hear if the maintainer would 
consider a patch do so if someone wrote one?


I see that python3-selenium now has a NEWS.Debian entry that points to 
README.Debian, which seems like a reasonable way to bring this to users' 
attention.


Regards,

Matthew

Bug#1051695: gdm3: 150% fractional scale not working after upgrade from gdm3 44 to 45

[Eni]

After upgrade gdm3 from 45~beta-1 to 45.0.1-1, this problem not showing 
again.

Thanks.

Bug#1052463: bookworm-pu: package debian-edu-doc/2.12.18~deb12u1

[Holger Levsen]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
x-debbugs-cc: debian-...@lists.debian.org

Hi,

please accept debian-edu-doc 2.12.18~deb12u1 into bookworm.

[ Reason ]
Updated documentation and translations.

[ Impact ]
Outdated documentation and translations for our users.

[ Tests ]
Build tests and manually confirmed the .debs are still the same size.

[ Risks ]
not really.

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

[ Changes ]
 debian-edu-doc (2.12.18~deb12u1) bookworm; urgency=medium
 .
   * Upload to bookworm.
 .
 debian-edu-doc (2.12.18) unstable; urgency=medium
 .
   [ Holger Levsen ]
   * Update Debian Edu Bookworm manual from the wiki, thanks to Guido 
Berhörster.
   * Update Debian Edu Bookworm manual from the wiki.
   * debian/copyright: Update after running 'make update-copyright'.
 .
   [ Frans Spiesschaert ]
   * Synchronize translations from weblate.org
 .
   [ Translation updates ]
   * Bookworm manual:
 - Brasilian Portuguese: Fred Maranhão and José Vieira.
 - Dutch: Frans Spiesschaert.
 - Portuguese: Fred Maranhão.
 - Romanian: Remus-Gabriel Chelu.
 - Spanish: Eulalio Barbero Espinosa and Francisco Javier Carro Orgeira.
 - Swedish: Luna Jernberg.
 .
   * Bullseye manual:
 - Brasilian Portuguese: Fred Maranhão and José Vieira.
 - Portuguese: Fred Maranhão.
 - Romanian: Remus-Gabriel Chelu.
 - Spanish: Eulalio Barbero Espinosa and Francisco Javier Carro Orgeira.
 - Swedish: Luna Jernberg.

[ Other info ]
$ debdiff debian-edu-doc_2.12.17.dsc debian-edu-doc_2.12.18~deb12u1.dsc|diffstat
 debian/changelog   
  |   34 +
 debian/copyright   
  |1 
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual-stripped.xml  
  |  121 +++-
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.da.po 
  |  369 +++---
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.de.po 
  |  361 +++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.es.po 
  |  740 +++-
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.fr.po 
  |  368 +++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.it.po 
  | 1560 +--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.ja.po 
  |  363 +++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.nb-no.po  
  |  362 +++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.nl.po 
  |  939 +++
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.pl.po 
  |  350 +++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.pot   
  |  289 +-
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.pt-br.po  
  |  983 +++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.pt-pt.add 
  |2 
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.pt-pt.po  
  | 1051 ++-
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.pt.add
  |1 
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.pt.po 
  | 2017 
++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.ro.po 
  |  714 ++-
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.sv.add
  |2 
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.sv.po 
  | 2187 
+++
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.xml   
  |  117 +++-
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.zh-cn.po  
  |  356 +++--
 documentation/debian-edu-bookworm/debian-edu-bookworm-manual.zh-tw.po  
  |  295 +--
 
documentation/debian-edu-bookworm/source/AllInOne-debian-edu-bookworm-manual.xml
 |3 
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.es.po 
  |  368 ++---
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pt-br.po  
  |   41 -
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pt-pt.add 
  |2 
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pt-pt.po  
  |  774 

Bug#1052318: lxd: Flags `--property` & `-f` and option `source.wipe` don't work

[Mathias Gibbens]

Control: forwarded -1 https://github.com/canonical/lxd/issues/12299


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

Bug#1052462: parted: libparted2 package dependencies (dmidecode) differ between arm64 and amd64

[Phil Roche]

Package: parted
X-Debbugs-Cc: phil.ro...@canonical.com
Version: 3.5-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Hi,

While working on new arm64 Ubuntu 23.10 Mantic minimal cloud images
(http://cloud-images.ubuntu.com/minimal/daily/mantic/) we discovered that
`dmidecode` was not being installed in the arm64 images.

In debugging, I found that the package dependencies of the libparted2
package
differ between arm64 and amd64. arm64 `libparted2` does not depend on
`dmidecode` but on amd64 it does.

 arm64
```
ubuntu@cloudimg:~$ apt show libparted2
Package: libparted2
Version: 3.6-3
Priority: standard
Section: libs
Source: parted
Origin: Ubuntu
Maintainer: Ubuntu Developers 
Original-Maintainer: Parted Maintainer Team 
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 397 kB
Provides: libparted
Depends: libblkid1 (>= 2.17.2), libc6 (>= 2.34), libdevmapper1.02.1 (>=
2:1.02.97), libuuid1 (>= 2.16)
Suggests: parted, libparted-dev, libparted-i18n (= 3.6-3)
Homepage: https://www.gnu.org/software/parted
Task: standard, cloud-minimal
Download-Size: 150 kB
APT-Manual-Installed: no
APT-Sources: http://ports.ubuntu.com/ubuntu-ports mantic/main arm64 Packages
Description: disk partition manipulator - shared library
 GNU Parted is a program that allows you to create, destroy, resize,
 move, and copy disk partitions. This is useful for creating space
 for new operating systems, reorganizing disk usage, and copying data
 to new hard disks.
 .
 This package contains the shared library.

```

 amd64
```
buntu@cloudimg:~$ apt show libparted2
Package: libparted2
Version: 3.6-3
Priority: standard
Section: libs
Source: parted
Origin: Ubuntu
Maintainer: Ubuntu Developers 
Original-Maintainer: Parted Maintainer Team 
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 385 kB
Provides: libparted
Depends: libblkid1 (>= 2.17.2), libc6 (>= 2.34), libdevmapper1.02.1 (>=
2:1.02.97), libuuid1 (>= 2.16), dmidecode
Suggests: parted, libparted-dev, libparted-i18n (= 3.6-3)
Homepage: https://www.gnu.org/software/parted
Task: standard, cloud-minimal
Download-Size: 151 kB
APT-Manual-Installed: no
APT-Sources: http://archive.ubuntu.com/ubuntu mantic/main amd64 Packages
Description: disk partition manipulator - shared library
 GNU Parted is a program that allows you to create, destroy, resize,
 move, and copy disk partitions. This is useful for creating space
 for new operating systems, reorganizing disk usage, and copying data
 to new hard disks.
 .
 This package contains the shared library.

```

Is this a bug, or is there reasoning why this is the case?

I note the change to dependencies `, dmidecode [amd64 i386]` was added as
part
of changes in version 3.2-21 in Apr 2018 to address bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840709

I have filed a bug against Ubuntu too @
https://bugs.launchpad.net/ubuntu/+source/parted/+bug/2036980

My concerns is the diff in dependencies but in the Ubuntu bug xnox points
out
why there might be a diff in arm64 and amd64

```
#if (defined(__i386__) || defined(__x86_64__)) && defined(__linux__)
# define USE_DMI
#endif

#define APPLE_DMI "Apple Computer, Inc."
#define APPLE_DMI_2 "Apple Inc."
static int is_apple = 0;

static char *
dmi_system_manufacturer (void)
{
#ifdef USE_DMI
  FILE *dmidecode;
  char *manufacturer = NULL;
  size_t manufacturer_len = 0;

  dmidecode = popen ("dmidecode -s system-manufacturer 2>/dev/null", "r");
  if (getline (, _len, dmidecode) < 0) {
/* ignore; will return NULL */
  }
  pclose (dmidecode);
  if (manufacturer) {
char *newline = strchr (manufacturer, '\n');
if (newline)
  *newline = '\0';
  }
  return manufacturer;
#else /* !USE_DMI */
  return NULL;
#endif /* USE_DMI */
}

```

As I understand it, dmi is available on other arches too to find the
manufacturer.

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

Installed parted2 on arm64 system

   * What was the outcome of this action?

parted2 was installed but dmidecode was not

   * What outcome did you expect instead?

I expected dmidecode to be installed as it is with amd64.



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

Kernel: Linux 6.2.0-32-generic (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages parted depends on:
ii  libc6 2.37-0ubuntu2
ii  libparted23.5-3
ii  libreadline8  8.2-1.3
ii  libtinfo6 6.4-2ubuntu0.1

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

-- no debconf information

Bug#1051695: gdm3: 150% fractional scale not working after upgrade from gdm3 44 to 45

[Eni]

 
  
  
  
After upgrade gdm3 from 45~beta-1 to 45.0.1-1, this problem not showing again. 
   
  
Thanks. 
   
   


 

Bug#1051901: 1.2.10 breaks ability to play audio using i386 binaries on amd64 host

[Dirk Griesbach]

Hi Antoine,

Am Do, 14. Sep 2023 um 02:11:25 +0200 schrieb Antoine Le Gonidec:
I think the problem might actually be related to trying to play sounds 
using any i386 binary (so the i386 libasound.so.2) on an amd64 host.


I'd go so far to think that this is not constrained to i386 binaries on 
amd64 hosts. `aplay /dev/zero` segfaults on a plain i386 host with 
asound 1.2.10. Downgrading to 1.2.9 helps.


,[ dmesg ]-
| [135665.812694] aplay[25480]: segfault at 10b ip b7efda1a sp bfd11860 error 4 
in libasound.so.2.0.0[b7e8a000+a4000] likely on CPU 0 (core 0, socket 0)
| [135665.812732] Code: 55 57 56 53 e8 17 f7 f8 ff 81 c3 7b 69 09 00 83 ec 0c 8b 6c 
24 20 8b 74 24 24 8b 85 08 01 00 00 8b 50 20 85 d2 74 11 8b 40 1c <8b> 80 08 01 
00 00 85 c0 0f 84 88 00 00 00 8d 7e 04 89 f1 31 c0 c7
`

Best regards,
Dirk

Bug#1051994: RFS: inkscape-textext/1.9.0-1 -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

On 2023-09-22 07:29, Boyuan Yang wrote:
> 
> You claimed that you are trying to validate upstream signatures, yet your 
> .dsc file as presented
> on mentors.debian.net does not include tarball signature at all. Lintian is 
> also complaining
> orig-tarball-missing-upstream-signature inkscape-textext_1.9.0.orig.tar.xz. 
> Do you want to try
> to fix this problem, or let us upload the current version as-is first?
> 
> Thanks,
> Boyuan Yang

Hello,

Thanks for looking at this!  Upstream does not release signed tarballs as far 
as I can tell.  They
sign git tags.  I am using pgpmode=git for uscan.  Is this the correct way to 
handle this?

I have confirmed that uscan fails if I change upstream/signing-key.asc to 
another key :

> gpgv: Signature made Wed Jul 26 03:24:55 2023 MDT
> gpgv:using RSA key 32746E27876C1E5418BBBF7F7A9964831E98EED5
> gpgv: Can't check signature: No public key
> uscan die: OpenPGP signature did not verify. at 
> /usr/share/perl5/Devscripts/Uscan/Output.pm line 77.

I assume that means it is actually verifying the signature.

Should I add a lintian override to capture this situation?

Best,
Antonio Russo

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052461: ITP: filecheck -- Attempt to reimplement LLVM's FileCheck using Python.

[Bo YU]

Package: wnpp
Severity: wishlist
Owner: Bo YU 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: filecheck
  Version : 0.0.23
  Upstream Contact: s.pankev...@gmail.com
* URL : https://github.com/mull-project/FileCheck.py
* License : Apache-2.0 license
  Programming Lang: Python
  Description : Attempt to reimplement LLVM's FileCheck using Python.

Many software projects could benefit from a suite of LLVM LIT integration
tests. The problem is that you have to build FileCheck from LLVM sources
which is not a trivial task for 1) people who are not familiar with the
LLVM infrastructure and 2) Python-based projects that would prefer to not
have to build anything from LLVM's source code in their CI process.

The option of having pre-compiled binaries is a workaround, but we don't
like to keep third-party binary artifacts in source code

This is a B-D for #1052439

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

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

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

[Vincent Lefevre]

Control: reassign -1 unison-2.53 2.53.3-2
Control: retitle -1 when receiving a SIGINT, unison should send it to the 
process group, not just to ssh

A summary of the issue: I'm using a wrapper to ssh in order to
call ssh-add before the real ssh, when needed. When I run unison
and type Ctrl-C when a passphrase is asked by ssh-add, this kills
unison and my wrapper, but not ssh-add.

BTW, I've noticed that with svn (which uses my ssh wrapper in the
same way as unison), everything is OK. So this issue is specific
to the execution via unison.

In my wrapper, I've replaced "ssh-add" by "strace -o ~/str.out ssh-add",
so that I can now see more about the issue: with svn, ssh-add receives
the SIGINT, but not with unison!

In the ssh-add strace output when using svn:

[...]
openat(AT_FDCWD, "/dev/tty", O_RDWR)= 4
ioctl(4, TCGETS, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(4, TCGETS, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(4, TCSETSF, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(4, TCGETS, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
rt_sigaction(SIGALRM, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGHUP, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_IGN, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTSTP, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTTIN, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTTOU, {sa_handler=0x55993f0238b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f305625a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
write(4, "Enter passphrase for /home/vlefe"..., 49) = 49
read(4, 0x7ffd198c78cf, 1)  = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
write(4, "\n", 1)   = 1
[...]

In the ssh-add strace output when using unison:

[...]
openat(AT_FDCWD, "/dev/tty", O_RDWR)= 4
ioctl(4, TCGETS, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(4, TCGETS, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(4, TCSETSF, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
ioctl(4, TCGETS, {c_iflag=ICRNL|IUTF8, 
c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, 
c_lflag=ISIG|ICANON|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
rt_sigaction(SIGALRM, {sa_handler=0x55e65c2078b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f77bb25a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGHUP, {sa_handler=0x55e65c2078b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f77bb25a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x55e65c2078b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f77bb25a510}, {sa_handler=SIG_DFL, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=0x55e65c2078b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f77bb25a510}, {sa_handler=SIG_IGN, 
sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=0x55e65c2078b0, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7f77bb25a510}, 

Bug#1051368: python3-selenium: Selenium Python still can't find chromedriver

[Jonathan Kamens]

I have escalated this issue to the technical committee. Ref: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052460

Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package

[Jonathan Kamens]

Package: tech-ctte
Severity: important

This referral to the technical committee concerns the issue identified
in ticket 1051368. I appear to be at an impassse in that ticket with
the maintainer of the python3-selenium package referenced in that
ticket, and they have stopped responding to my comments in the ticket.

Executive summary

The current python3-selenium package does not include all of the
components that the vendor expects to be included in the package, and
as a result it does not work. This is a regression from previous
versions of the package, i.e., it was working just fine and then
stopped working at all in the new release. The workaround suggested by
the maintainer of the package is inconsistent with the vendor's
expectations and in my opinion inadequate. There is a straightforward
fix which the package maintainer has declined, without explanation, to
implement.

Additional details

The current version of the Selenium bindings for all supported
programming languages relies on a Rust executable called Selenium
Manager for managing the webdriver executables required for the
various browsers that the bindings interact with. This Rust program is
intended to be packaged and shipped with the Selenium bindings, as
indicated by the facts that (a) it is included in the official PyPI
packages for the Python bindings and (b) the maintainers of Selenium
state this explicitly. Quoting from
https://www.selenium.dev/documentation/selenium_manager/ :

"Selenium bindings use this tool by default, so you do not need to
download it or add anything to your code or do anything else to use
it. ... Selenium Manager is the official driver manager of the
Selenium project, and it is shipped out of the box with every Selenium
release."

While I don't much care for the fact that the maintainers of Selenium
have opted to make all of the language bindings depend on a compiled
executable written in a different language, this is the technical
decision that they've made, and it's their prerogative.

When Selenium Manager is not included with the language binding, it
fails to find the webdriver executables it needs and stops working
unless the developer modifies their code to explicitly say where the
executable is located, the workaround suggested by the
python3-selenium package maintainer in README.Debian. This makes the
affected Selenium code non-portable, when the whole point of Selenium
Manager is to increase code portability rather than decreasing it. In
addition, the only way the developer has to know they need to do this
on Debian is to find and read the README.Debian file, which (a) most
developers aren't going to think to do and (b) due to a packaging
error wasn't even included in the python3-selenium package.

As I noted in ticket 1051368, building Selenium Manager so that it can
be included in the package is straightforward. In particular, it
requires just four steps:

1. Download the Selenium source code from GitHub or somewhere else it
   is published

2. Download a bazel binary from
   https://github.com/bazelbuild/bazelisk/releases and make it
   executable in your search path

3. Unpack the Selenium source code

4. Run "bazel build //rust:selenium-manager" in the top directory of
   the Selenium source code

After these four steps, the Selenium Manager is available for
packaging in bazel-bin/rust/selenium-manager.

It does not seem like this is too much work for Debian's
python3-selenium package build scripts to do.

To summarize, including Selenium Manager in the package (a) is
straightforward, (b) is what the upstream vendor intends, (c) would
make the package work like it's supposed to when it doesn't currently,
and (d) would eliminate the necessity for developers to use a
platform-specific hack to make their Python Selenium code work on
Debian.

Bug#1052459: mini-buildd: Problems with unnecessarily doubled slashes

[Magnus Holmgren]

Package: mini-buildd
Version: 2.0.7~bpo12+1

mini-buildd requires (in Archive.clean) that all archive URLs end in a slash. 
Yet it (always?) adds another slash before 'dists' (e.g. 
Archive.ReleaseFile(f"{archive.url}/dists/{self.codename}/") in 
Source.mbd_check). With behaving servers, this shouldn't be a problem, but I 
ran into deb.nodesource.com, which doesn't behave. Check the difference 
betweeen GETting

https://deb.nodesource.com/node_18.x/dists/bookworm/Release

and

https://deb.nodesource.com/node_18.x//dists/bookworm/Release

I guess the check for the trailing slash is a precaution in case you forget to 
use a slash when using the archive URL in the code, but maybe you could skip 
the joining slash when you have already ensured that the archive URL ends in 
one.

(Now, I tried getting around the check by updating the config database 
directly, but it still didn't work because nodesource.com have blocked the 
Python-urllib User-Agent, the bastards, but that's a separate issue.)

-- 
Magnus Holmgren
./¯\_/¯\. Milient
(also holmg...@debian.org)

Bug#1051994: RFS: inkscape-textext/1.9.0-1 -- Re-editable LaTeX graphics for Inkscape

[Boyuan Yang]

Control: tags -1 +moreinfo
X-Debbugs-CC: aeru...@aerusso.net

On Fri, 15 Sep 2023 08:09:01 -0600 Antonio Russo  wrote:
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-Cc: aeru...@aerusso.net
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "inkscape-textext"
> 
>  * Package name    : inkscape-textext
>    Version : 1.9.0-1
>    Upstream Author : Jan Winkler 
>  * URL : https://textext.github.io/textext
>  * License : BSD-3-clause
>  * Vcs : https://salsa.debian.org/aerusso-guest/textext
>    Section : graphics
>    Description : Re-editable LaTeX graphics for Inkscape
> 
> TexText is a Python plugin for the vector graphics editor Inkscape
> providing the possibility to add and re-edit LaTeX generated SVG
> elements to your drawing.
> 
>  Key features
>  . Windows/Linux/MacOS support
>  . LaTeX generated SVG elements can be re-edited later
>  . Multi-line editor with syntax highlighting
>  . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
>  . Interoperable scaling in TexText and Inkscape
>  . Font size match with Inkscape text
>  . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
>  . Colorization via TeX commands/Inkscape is kept after re-editing
>  . Alignment anchor of the produced output
>  . Preview images
> 
> It builds the binary packages:
> 
>   inkscape-textext - Re-editable LaTeX graphics for Inkscape
>   inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape 
>(documentation)
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/inkscape-textext/
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
>https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.9.0-1.dsc
> 
> Changes since the last upload:
> 
>  inkscape-textext (1.9.0-1) experimental; urgency=medium
>  .
>    * New upstream release
>    * Refresh patches
>    * Update debian/copyright
>    * Bump standards version (no changes required)
>    * Drop support for inkscape <1.3, matching upstream
>    * Simplify build scripts
>    * Validate upstream signatures
>    * Relax architecture dependencies
> 
> This upload is primarily to track upstream releases.  Most notably, upstream 
> has dropped support for

You claimed that you are trying to validate upstream signatures, yet your .dsc 
file as presented
on mentors.debian.net does not include tarball signature at all. Lintian is 
also complaining
orig-tarball-missing-upstream-signature inkscape-textext_1.9.0.orig.tar.xz. Do 
you want to try
to fix this problem, or let us upload the current version as-is first?

Thanks,
Boyuan Yang


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

Bug#1052298: metafun broken?

[Norbert Preining]

Hi all,

is metafun broken?

$ mpost
This is MetaPost, version 2.02 (TeX Live 2023) (kpathsea version 6.3.5)
**\relax
(/home/norbert/tl/2023/texmf-dist/metapost/base/mpost.mp
(/home/norbert/tl/2023/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) )
*input metafun.mp
(/home/norbert/tl/2023/texmf-dist/metapost/context/base/common/metafun.mp
! I can't open file `metafun.mpii'.
l.6 input metafun.mpii
  
Please type another input file name: 



There is only metafun.mpiv

Any ideas?

Thanks

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1052458: elpa-ess: ESS mode in Emacs fails with many errors on startup

[Hugh Pumphrey]

Package: elpa-ess
Version: 18.10.2+git20220915.f45542e-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: hugh.pumph...@gmail.com

Dear Maintainer,



   * What led up to the situation?

I (as a long time user of R and the Emacs ESS mode) upgraded from 
bullseye to bookworm. 
   * What exactly did you do (or not do)

Attempted to edit an R source file in Emacs. (I am using emacs-lucid on 
account of Bug#1043326 in emacs-gtk, but the bug I report here occurs
in both emacs-lucid and emacs-gtk.)

   * What was the outcome of this action?

ESS mode fails to start up and many error and warning messages are
emitted --- see below.

   * What outcome did you expect instead?

I expected ESS mode to start as normal, as it did for many debian releases
before bookworm. 

To check that this was not some oddity of upgrading from bullseye to 
bookworm I purged packages ess and elpa-ess and re-installed them; the 
problem did not go away.

The error message appeared to be:

File mode specification error: (error Loading file 
/usr/share/emacs/site-lisp/elpa/ess-18.10.3snapshot/ess-rd.el 
failed to provide feature 'essddr')

A buffer containing many warning messages appeared which I copy here:

Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-r-mode.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-mode.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess.elc Disable showing Disable 
logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-custom.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-utils.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-generics.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-inf.elc Disable showing Disable 
logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-tracebug.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-noweb-mode.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-help.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-s-lang.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/ess-18.10.2/ess-roxy.elc Disable showing 
Disable logging






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

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

Versions of packages elpa-ess depends on:
ii  dh-elpa-helper  2.0.16
ii  emacsen-common  3.0.5

Versions of packages elpa-ess recommends:
ii  r-base-core  4.2.2.20221110-2

Versions of packages elpa-ess suggests:
pn  jags  
pn  pspp  

-- no debconf information

Bug#1052216: plasma-mobile should depend on plasma-dialer

[Pirate Praveen]

On Thu, 21 Sep 2023 19:32:46 +0200 Marco Mattiolo 
 wrote:

Hi,

thank you for reporting.

For the point of plasma-mobile not depending on plasma-dialer, I'm sorry 
that's a "wontfix": there are usecases (e.g. tablet) where plasma-mobile 
can be used without plasma-dialer, then it makes no sense for 
plasma-mobile to depend on plasma-dialer and to force some user to 
install plasma-dialer even if not needed.


Thanks for the explanation, makes sense. I was not thinking about the 
tablet use case.


Your point will be addressed in the near future, as a metapackage is 
being worked on to bring something like plasma-mobile-phone (which will 
depend on plasma-dialer and many others) and plasma-mobile-tablet (which 
will not depend on plasma-dialer) to Debian. In the phone usecase, you 
will have to install plasma-mobile-phone to get a full plasma-mobile 
system for the phone usecase, including the dialer.


Thanks for this.



For the point of the plasma-dialer error, that's an error I've seen in 
two situations: inside a virtual machine (hence no modem available to 
route audio calls) or when something was crashing really bad. Just to be 
sure, have you installed plasma-dialer from the Debian repo with all its 
dependencies, right? 


yes installed via apt.
> Does this error still happen after reboot?

It seems to be fixed now and I can make calls with plasma dialer now, 
lso incoming calls are also handled via plasma dialer now.



Kind regards

Marco





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052457: ITP: r-cran-quickjsr -- GNU R Interface for the 'QuickJS' Lightweight 'JavaScript' Engine

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-quickjsr -- GNU R Interface for the 'QuickJS' Lightweight 
'JavaScript' Engine
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-quickjsr
  Version : 1.0.6
  Upstream Author : Andrew R. Johnson,
* URL : https://cran.r-project.org/package=QuickJSR
* License : MIT
  Programming Lang: GNU R
  Description : GNU R Interface for the 'QuickJS' Lightweight 'JavaScript' 
Engine
 An 'R' interface to the 'QuickJS' portable 'JavaScript' engine.
 The engine is bundled entirely within the package, requiring no external system
 dependencies beyond a 'C' compiler.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-quickjsr

Bug#1052298: metafun broken?

[Zdenek Wagner]

After fresh update of TL2023:
$ mpost metafun.mp
This is MetaPost, version 2.02 (TeX Live 2023) (kpathsea version 6.3.5)
(/usr/local/texlive/2023/texmf-dist/metapost/base/mpost.mp
(/usr/local/texlive/2023/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) )
(/usr/local/texlive/2023/texmf-dist/metapost/context/base/common/metafun.mp
! I can't open file `metafun.mpii'.
l.6 input metafun.mpii

Please type another input file name: ^C


With TL2022:
$ mpost metafun.mp
This is MetaPost, version 2.02 (TeX Live 2022) (kpathsea version 6.3.4)
(/usr/local/texlive/2022/texmf-dist/metapost/base/mpost.mp
(/usr/local/texlive/2022/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) )
(/usr/local/texlive/2022/texmf-dist/metapost/context/base/common/metafun.mp
(/usr/local/texlive/2022/texmf-dist/metapost/context/base/mpii/metafun.mpii
(/usr/local/texlive/2022/texmf-dist/metapost/context/base/mpii/mp-base.mpii
Preloading the plain mem file, version 1.004 for metafun ii
! Redundant equation.

  ;
l.331 mm=2.83464;
  pt=0.99626;dd=1.06601;  bp:=1;
?

... and many more redundant equations

TL2021: the same redundant equations
Zdeněk Wagner
https://www.zdenek-wagner.eu/

pá 22. 9. 2023 v 15:05 odesílatel Zdenek Wagner
 napsal:
>
> Hi,
>
> there is a conditional statement testing whether mplib is present,
> thus metafun will work if mpiv can be used and mpii is not needed.
> This means that it sometimes works and sometimes not. I have not tried
> on my computer.
>
> Zdeněk Wagner
> https://www.zdenek-wagner.eu/
>
> pá 22. 9. 2023 v 15:01 odesílatel Norbert Preining
>  napsal:
> >
> > On Fri, 22 Sep 2023, Zdenek Wagner wrote:
> > > identical. metafun.mpii is present in TL2022 but missing in TL2023.
> >
> > indeed, all of
> > texmf-dist/metapost/context/base/mpii/
> > is missing in TL 2023, which means metafun does not work.
> >
> > Best
> >
> > Norbert
> >
> > --
> > PREINING Norbert  https://www.preining.info
> > Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
> > GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1052298: metafun broken?

[Zdenek Wagner]

Hi,

there is a conditional statement testing whether mplib is present,
thus metafun will work if mpiv can be used and mpii is not needed.
This means that it sometimes works and sometimes not. I have not tried
on my computer.

Zdeněk Wagner
https://www.zdenek-wagner.eu/

pá 22. 9. 2023 v 15:01 odesílatel Norbert Preining
 napsal:
>
> On Fri, 22 Sep 2023, Zdenek Wagner wrote:
> > identical. metafun.mpii is present in TL2022 but missing in TL2023.
>
> indeed, all of
> texmf-dist/metapost/context/base/mpii/
> is missing in TL 2023, which means metafun does not work.
>
> Best
>
> Norbert
>
> --
> PREINING Norbert  https://www.preining.info
> Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1003192: debian-edu-config: /etc/login.defs not adjusted for Debian Edu like /etc/adduser.conf

[Guido Berhoerster]

On Fri, 22 Sep 2023 13:57:09 +0200 Guido Berhoerster  
wrote:
> In addition to systemd, polkitd now also uses a UID above 499, on a main
> server with MATE desktop I have the following UIDs above 499:
> 
> 995 polkitd
> 997 systemd-timesync
> 998 systemd-network

Regarding systemd, systemd-sysusers is the third mechanism how system 
users can be created.

So these users are created by systemd-sysusers either during 
installation by a postinst script (like e.g. polkitd) or during boot via
the systemd-sysusers.service. The UID/GID range in systemd-sysusers is
determined either per file, that is on a system level by each package,
or compiled-in default which is 0-999, there is no run-time 
configuration for system administrators and the documentation strongly
discourages changing that.

The actual allocation algorithm does not seem to be documented, (but in
best systemd tradition) it seems to be the opposite what other tools are
doing, allocating from highest to lowest which causes the problems for
us.

There is actually an escape hatch, systemd can be compiled with
-Dcompat-mutable-uid-boundaries=true which makes it obey /etc/login.defs
at runtime. Again the docs state that this is a compatibility feature
which should only be used for upgrading systems. So it is not clear how
much this can be relied on in the future.

So our options are to:

- try to convince the rest of Debian to limit the system UID/GID range
  to 0-499
- convince every package maintainer to explicitly specify a range 0-499
  in their systemd-sysuser config file
- try to get the systemd package maintainers to build the package with
  -Dcompat-mutable-uid-boundaries=true
- change the DebianEdu scheme giving LDAP users a UID/GIDs range
  2000-6 or similar

Suggestions?


References:
- https://systemd.io/UIDS-GIDS/
- https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html
- https://www.freedesktop.org/software/systemd/man/sysusers.d.html

-- 
Guido Berhoerster

Bug#1052298: metafun broken?

[Norbert Preining]

On Fri, 22 Sep 2023, Zdenek Wagner wrote:
> identical. metafun.mpii is present in TL2022 but missing in TL2023.

indeed, all of
texmf-dist/metapost/context/base/mpii/
is missing in TL 2023, which means metafun does not work.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13