Bug#1055864: Please recommend lowdown in addition to (or instead of) pandoc

[Faidon Liambotis]

Package: dh-make
Version: 2.202301
Severity: wishlist
X-Debbugs-Cc: ius...@debian.org

A few years ago, a bug was filed against one of my packages, #956041, to
report that build-depending on pandoc is a bit of a nuisance for ports
architectures and bootstrapping, as it has a long depends of B-Ds
itself, including the Haskell toolchain.

My package was merely using pandoc to generate a manpage from a Markdown
document, quite similar to dh-make's debian/manpage.md.ex template. The
bug reporter's suggestion to use Build-Depends-Indep was also not a
viable one, as the manpage had to be shipped with the binary itself, and
a separate -doc package did not make sense for this use case.

To resolve this request, I packaged "lowdown", which is a Markdown
translator, including to the man format. It is a very small binary,
depending only on libbsd (which is widely available). I've been
maintaining it since bullseye, for a couple of years now, and upstream
has been fairly responsive adding features such as Pandoc's metadata
header. There are other translators such as go-md2man etc., but none as
lightweight and comprehensive as lowdown, IMHO.

It seems that most are not familiar with Pandoc alternatives. For
example, from a recent thread on debian-devel:
  https://lists.debian.org/msgid-search/zswgm0nc9ax7u...@teal.hq.k1024.org

I think it'd be helpful if the dh-make templates recommended lowdown in
addition to, or even instead of, Pandoc. That way we'll be giving a
lightweight option to fellow developers interested in writing a manpage
using a modern markup language.

The corresponding command-line syntax is:
   lowdown -s -Tman -o output.1 input.md

Thanks,
Faidon

Bug#1055863: systemd has an undeclared file conflict

[Helmut Grohne]

Package: systemd
Version: 254.5-1~bpo12+1
Severity: normal
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + udev
Tags: bookworm

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

The files
 * /lib/systemd/system/sysinit.target.wants/systemd-hwdb-update.service
 * /lib/systemd/system/systemd-hwdb-update.service
are contained in the packages
 * systemd/254.5-1~bpo12+1 as present in bookworm-backports
 * udev/247.3-7+deb11u4 as present in bullseye|bullseye-updates

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

Given feedback from d-devel, we do not consider bullseye ->
bookworm-backports a valid upgrade path. However, removing this case
from dumat is very tricky. Hence, I file this bug anway though at normal
severity and ask you to add Breaks+Replaces for this unsupported case in
your next backport such that the diagnostic is removed from the dumat
output. Also a -sloppy backport would cause an rc bug here. Hope that
works for you.

Kind regards

The Debian Usr Merge Analysis Tool

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

Bug#1042356: rapid-photo-downloader: FTBFS: make: *** [debian/rules:8: clean] Error 25

[Antoine Beaupré]

Control: tags -1 +patch

There's a patch posted in this thread for this bug:

https://discuss.pixls.us/t/patch-for-newer-python-setuptools/36593

Actual link to the patch on Arch:

https://build.opensuse.org/request/show/1078462
-- 
The odds are greatly against you being immensely smarter than everyone
else in the field. If your analysis says your terminal velocity is
twice the speed of light, you may have invented warp drive, but the
chances are a lot better that you've screwed up.
- Akin's Laws of Spacecraft Design

Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy

[Osamu Aoki]

Hi,

Not quite.

On Sun, 2023-11-12 at 07:47 -0800, Ross Vandegrift wrote:
> On Sat, Nov 11, 2023 at 09:46:51PM +0900, Osamu Aoki wrote:
> > Package: cloud-init
> > Version: 22.4.2-1
> > Severity: normal
> > 
> > ## Background:
> > 
> > The problem and possible root cause fix are reported on upstream github
> > issue: https://github.com/canonical/cloud-init/issues/4603
> > 
> > ## Issue:
> > I noticed instance generated from Debian bookworm cloud image on
> > linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a
> > system group, this situation violates Debian policy.
> 
> Hi Osamu,
> 
> As Shengjing Zhu mentioned in [1], this issue was fixed in #1038691.  Is that
> incorrect?


This #1038691 is for Package: cloud.debian.org .

As I understand, the bug in cloud-init is worked around and only the resulting
image for cloud.debian.org is fixed via the image building code.

But not for LXD since it uses different images.  Image normally downloaded and
used by `lxc launch ...` becomes buggy once its instance is started because then
cloud-init starts system initialization with its default setting.

Of course, we can avoid this situation by fixing image manually by modifying its
default setting.

Here is how I get around this problem by removing toxic netdev out of installed
file /etc/cloud/cloud.cfg:
```
 $ cd path/to
 $ lxc init images:debian/bookworm/cloud dbc0
 $ lxc file pull dbc0/etc/cloud/cloud.cfg .
 $ sed -i -e 's/ netdev,//' cloud.cfg
 $ lxc file push cloud.cfg dbc0/etc/cloud/
 $ lxc publish dbc0 --alias dbc
Instance published with fingerprint:
379e858cc15808dbdf6a27a028a8b0098213656c0b4565bbc1b64b90b61d9dbd
 $ lxc start dbc0
 $ lxc launch dbc dbc1
```

Osamu


> [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055700#25

Bug#1055826: bullseye-pu: package crun/0.17+dfsg-1+deb11u2 (bullseye regression)

[Faidon Liambotis]

On Sun, Nov 12, 2023 at 03:06:34PM +, Adam D. Barratt wrote:
> On Sun, 2023-11-12 at 09:56 +0200, Faidon Liambotis wrote:
> > A change merged into Linux v6.6 broke crun. The change was backported
> > in the stable branch with v6.1.55, the version in bookworm. We fixed
> > crun last week crun 1.8.1-1+deb12u1 (unblock request: #1055241).
> > 
> > Salvatore Bonaccorso pointed out that the change was backported into
> > all the stable branches, including v5.10.197, the version now in
> > bullseye. bullseye's crun, v0.17, is also affected, therefore
> > bullseye crun + bullseye Linux (or bullseye crun+bullseye-backports
> > Linux etc.) are now broken as well.
> 
> I guess you'd like that pushed via bullseye-updates, once it's ready,
> as with the bookworm update?

Yes please :)

Thanks!
Faidon

Bug#1032207: libpam-modules: Drop pam_userdb

[Sam Hartman]

> "Bastian" == Bastian Germann  writes:

Bastian> X-Debbugs-Cc: vor...@debian.org Hi Sam and Steve,

Bastian> On Wed, 1 Mar 2023 18:34:50 +0100 Bastian Germann wrote:
Bastian> I would volunteer to provide a patch for this but only if
Bastian> it will be considered.

The patch isn't the hard part.
Honestly, I think splitting into a separate package is a lot lower risk
than  removing, but if we do that, we presumably need to have
libpam-modules depend on that package for a release cycle.

I'd definitely take a patch against the wip/debian_1.5.3 patch to split
out the module into its own package and to add a dependency from
libpam-modules to that new package. (and then we would want to remove
that dependency in the next release).

Anything more disruptive requires me to think a lot.
I'd rather not focus my energy on that, but I am open to being convinced.
I am not tracking your involvement in projects that want to reduce the
pseudo-essential set.
Is this a nice to have for you, or are you heavily involved in something
with broad consensus where this is important.

--Sam

Bug#1055862: node-http-proxy-agent: missing Breaks+Replaces: node-https-proxy-agent (<< 7)

[Andreas Beckmann]

Package: node-http-proxy-agent
Version: 7.0.0~0~2023071921-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../node-http-proxy-agent_7.0.0~0~2023071921-1_all.deb ...
  Unpacking node-http-proxy-agent (7.0.0~0~2023071921-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-http-proxy-agent_7.0.0~0~2023071921-1_all.deb 
(--unpack):
   trying to overwrite '/usr/share/nodejs/http-proxy-agent/dist/index.d.ts', 
which is also in package node-https-proxy-agent 5.0.1+~cs8.0.0-3
  Errors were encountered while processing:
   /var/cache/apt/archives/node-http-proxy-agent_7.0.0~0~2023071921-1_all.deb

The following files have moved to a new package:

usr/share/nodejs/http-proxy-agent/dist/index.d.ts
usr/share/nodejs/http-proxy-agent/dist/index.js
usr/share/nodejs/http-proxy-agent/dist/index.js.map
usr/share/nodejs/http-proxy-agent/package.json


cheers,

Andreas


node-https-proxy-agent=5.0.1+~cs8.0.0-3_node-http-proxy-agent=7.0.0~0~2023071921-1.log.gz
Description: application/gzip

Bug#1019096: bullseye-pu: package cifs-utils/2:6.11-3.1+deb11u2

[Santiago Vila]

El 25/7/23 a las 23:32, Jonathan Wiltshire escribió:

This request was approved but not uploaded in time for the previous point
release (11.7). Should it be included in 11.8 or should this request be
abandoned and closed?


Hi. Since the debdiff was already approved by you (RMs), I've just uploaded
(as if it was a "sponsored upload") the package which matches exactly the 
debdiff
provided by Michael in the bug report, since that was the intent.

Please include it in the next point release of bullseye (whenever that will be),
I'm trying to keep stable and oldstable free of FTBFS bugs like this one.

Thanks.

Bug#1055860: elpa-org-contrib: should not bind C-c j

[David Bremner]

Package: elpa-org-contrib
Version: 0.4.2-1
Severity: normal
Tags: upstream

According to (info "(elisp) Key Binding Conventions")

 Don’t define ‘C-c LETTER’ as a key in Lisp programs.  Sequences
 consisting of ‘C-c’ and a letter (either upper or lower case; ASCII
 or non-ASCII) are reserved for users; they are the *only* sequences
 reserved for users, so do not block them.


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

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

Versions of packages elpa-org-contrib depends on:
ii  dh-elpa-helper  2.0.17
ii  elpa-org9.6.10+dfsg-1
ii  emacsen-common  3.0.5

Versions of packages elpa-org-contrib recommends:
ii  emacs  1:29.1+1-5
ii  emacs-gtk [emacs]  1:29.1+1-5

elpa-org-contrib suggests no packages.

-- no debconf information

Bug#1053864: libdrm-amdgpu1: gpu crash on graphics start with Radeon 760M (both sway and gdm3)

[Simon Heath]

Oop, my bad.  I was wondering why I hadn't seen it go through on the bug 
report...


The issue is still present in apt package linux-image-6.5.0-3 (Kernel 
6.5.8-1) , and linux-image-6.5.0-4 (kernel 6.5.10-1). Same messages, as 
far as I can see, but here's the dmesg output from the 6.5.10-1 kernel 
in case there's something subtly different.


Thanks,
Simon





[    7.490078] ucsi_acpi USBC000:00: ucsi_handle_connector_change: 
GET_CONNECTOR_STATUS failed (-5)

[    7.605873] ucsi_acpi USBC000:00: possible UCSI driver bug 1
[    7.605903] ucsi_acpi USBC000:00: ucsi_handle_connector_change: 
GET_CONNECTOR_STATUS failed (-22)
[   13.555707] pipewire[1065]: memfd_create() called without MFD_EXEC or 
MFD_NOEXEC_SEAL set
[   23.808871] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 
timeout, signaled seq=23, emitted seq=25
[   23.809320] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process 
information: process  pid 0 thread  pid 0

[   23.809592] amdgpu :c1:00.0: amdgpu: GPU reset begin!
[   23.990678] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   23.990842] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.124228] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.124374] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.257754] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.257918] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.391326] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.391555] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.525068] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.525211] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.658617] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.658758] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.792155] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.792326] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.925815] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.925961] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   25.059344] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   25.059488] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue

[   25.061023] amdgpu :c1:00.0: amdgpu: MODE2 reset
[   25.090107] amdgpu :c1:00.0: amdgpu: GPU reset succeeded, trying 
to resume
[   25.090767] [drm] PCIE GART of 512M enabled (table at 
0x00801FD0).

[   25.090889] amdgpu :c1:00.0: amdgpu: SMU is resuming...
[   25.092526] amdgpu :c1:00.0: amdgpu: SMU is resumed successfully!
[   25.094267] [drm] DMUB hardware initialized: version=0x08000E00
[   25.101834] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:264
[   25.104428] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:272
[   25.107025] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:280
[   25.109617] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:288
[   25.117187] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:264
[   25.119782] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:272
[   25.122380] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:280
[   25.124993] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:288

[   25.534004] [drm] kiq ring mec 3 pipe 1 q 0
[   25.536314] [drm] VCN decode and encode initialized 
successfully(under DPG Mode).
[   25.536470] amdgpu :c1:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] 
JPEG decode initialized successfully.
[   25.537196] amdgpu :c1:00.0: amdgpu: ring gfx_0.0.0 uses VM inv 
eng 0 on hub 0
[   25.537200] amdgpu :c1:00.0: amdgpu: ring comp_1.0.0 uses VM inv 
eng 1 on hub 0
[   25.537202] amdgpu :c1:00.0: amdgpu: ring comp_1.1.0 uses VM inv 
eng 4 on hub 0
[   25.537204] amdgpu :c1:00.0: amdgpu: ring comp_1.2.0 uses VM inv 
eng 6 on hub 0
[   25.537206] amdgpu :c1:00.0: amdgpu: ring comp_1.3.0 uses VM inv 
eng 7 on hub 0
[   25.537208] amdgpu :c1:00.0: amdgpu: ring comp_1.0.1 uses VM inv 
eng 8 on hub 0
[   25.537210] amdgpu :c1:00.0: amdgpu: ring comp_1.1.1 uses VM inv 
eng 9 on hub 0
[   25.537212] 

Bug#1025218: marked as pending in python-urllib3

[Daniele Tricoli]

Hello Stefano,

On 10/11/2023 09:12, stefa...@debian.org wrote:

There's one particularly slow test that is causing upstream issues at
the moment too. Cherry-picked this PR into a patch:
https://github.com/urllib3/urllib3/pull/3181

It should make a big difference.


Many thanks, it reduced my build time to about 4 minutes!

Just made the upload into experimental, thanks for your help!

Cheers,

--
Daniele Tricoli
https://mornie.org

Bug#1055859: bookworm-pu: package pyzoltan/1.0.1-5+deb12u1

[Santiago Vila]

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

[ Reason ]
This upload fixes Bug#1055625 FTBFS on single-cpu systems.

[ Impact ]
Anybody trying to build the package using a single-cpu
system will get an unexpected build error.

[ Tests ]
There are no real code changes. The package builds the same.

[ Risks ]
Very low risk.

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

[ Changes ]
The only change has been to change NPROCS=2 to NPROCS=1
in debian/rules.

[ Other info ]
The package is already uploaded.diff -Nru pyzoltan-1.0.1/debian/changelog pyzoltan-1.0.1/debian/changelog
--- pyzoltan-1.0.1/debian/changelog 2022-10-31 08:07:44.0 +0100
+++ pyzoltan-1.0.1/debian/changelog 2023-11-12 23:25:00.0 +0100
@@ -1,3 +1,11 @@
+pyzoltan (1.0.1-5+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * debian/rules: Set NPROC to 1 so that the package may be
+built on systems with a single core. Closes: #1055625.
+
+ -- Santiago Vila   Sun, 12 Nov 2023 23:25:00 +0100
+
 pyzoltan (1.0.1-5) unstable; urgency=medium
 
   * Standards version bumped to 4.6.1 (non changes).
diff -Nru pyzoltan-1.0.1/debian/rules pyzoltan-1.0.1/debian/rules
--- pyzoltan-1.0.1/debian/rules 2022-10-31 08:07:44.0 +0100
+++ pyzoltan-1.0.1/debian/rules 2023-11-12 23:20:43.0 +0100
@@ -4,7 +4,7 @@
 export USE_TRILINOS=1
 export ZOLTAN_INCLUDE=/usr/include/trilinos
 export ZOLTAN_LIBRARY=/usr/lib
-export NPROCS=2
+export NPROCS=1
 
 export PYBUILD_NAME=pyzoltan
 

Bug#1055858: Warnings from emacs 29.1

[Dan Jacobson]

Package: w3m-el-snapshot
Version: 1.4.632+0.20221206.2328.4f27810-1

I see:
⛔ Warning (comp): w3m-session.el:112:2: Warning: defvar 
`w3m-session-group-open' docstring has wrong usage of unescaped single quotes 
(use \= or different quoting)
⛔ Warning (comp): w3m-bookmark.el:208:25: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): w3m-bookmark.el:461:23: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): w3m-bookmark.el:467:33: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): w3m-form.el:2026:20: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): w3m-form.el:2026:58: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): w3m-form.el:2027:19: Warning: ‘point-at-eol’ is an obsolete 
function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): w3m-form.el:2028:37: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): w3m-form.el:2029:49: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
etc. many warnings.

Bug#1006193: Remove luit, now packaged separately

[Brendan O'Dea]

On Sun, Nov 12, 2023 at 04:39:30PM -0500, Thomas Dickey wrote:
>On Wed, Mar 02, 2022 at 03:09:37PM -0500, Thomas Dickey wrote:
>While this has been applied, it's not moving along because the related
>version x11-utils (7.7+6) has not gone into testing yet - more than a year.

It hasn't reached testing because it hasn't yet been uploaded to
unstable.

Sven, do you want me to upload?  There are a couple of other changes to
pick up as well.

I send an access requst to join https://salsa.debian.org/xorg-team some
time ago which is still pending, but for it shouldn't be needed for this
upload if I'm just pushing what's already been comitted to the default
branch.

--bod

Bug#1006193: Remove luit, now packaged separately

[Thomas Dickey]

On Wed, Mar 02, 2022 at 03:09:37PM -0500, Thomas Dickey wrote:
> On Wed, Mar 02, 2022 at 08:15:15PM +0100, Sven Joachim wrote:
> > On 2022-02-21 10:14 +1100, Brendan O'Dea wrote:
> > 
> > > Package: x11-utils
> > > Version: 7.7+5
> > > Severity: normal
> > > Tags: patch
> > > X-Debbugs-Cc: b...@debian.org
> > >
> > > Merge request to remove luit from x11-utils:
> > >
> > >   https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1
> > >
> > > now packaged separately, this commit removes luit and adds a recommends 
> > > for
> > > the new package.
> > 
> > Thanks, I have merged that now.  Are there any packages besides xterm
> > that use luit?  On codesearch.debian.net I found some 75 hits[1], but
> > they seem to be either completely unrelated or only commentaries.

While this has been applied, it's not moving along because the related
version x11-utils (7.7+6) has not gone into testing yet - more than a year.

What has to be done to make that happen?

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1054449: pesign: Missing Depends on passwd

[Steve McIntyre]

On Sun, Nov 12, 2023 at 10:16:01PM +0100, Santiago Vila wrote:
>found 1054449 116-1
>found 1054449 116-5
>affects 1054449 src:shim
>thanks
>
>Hi. In commit e38e2a8af632a660d3c01a936796622fce186020
>it looks that you added passwd to the Build-Depends.
>
>The bug (after preinst moved to postinst) was about adding it
>to the Depends field.
>
>In fact, the changelog was correct for what it had to be done,
>just not for what it was actually done.
>
>(note: shim FTBFS in a clean chroot because of this bug)

Oh, gah. :-/

Thanks for the prod, fixing now!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#1054449: pesign: Missing Depends on passwd

[Santiago Vila]

found 1054449 116-1
found 1054449 116-5
affects 1054449 src:shim
thanks

Hi. In commit e38e2a8af632a660d3c01a936796622fce186020
it looks that you added passwd to the Build-Depends.

The bug (after preinst moved to postinst) was about adding it
to the Depends field.

In fact, the changelog was correct for what it had to be done,
just not for what it was actually done.

(note: shim FTBFS in a clean chroot because of this bug)

Thanks.

Bug#1055857: transition: opm-common

[Markus Blatt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-scie...@lists.debian.org

Dear Debian release team,

A new upstream release of OPM is available. To ease migration to testing I am
requesting a mini-transition. Uploading to unstable would probably work even
without a transition, but I would like to play it safe.

This should only affect the OPM source packages opm-common, opm-grid, opm-
models, opm-simulators and opm-upscaling.

I have already uploaded new versions to experimental that seemed to have built
without any issues, see [1].
(please explain about the transition: impacted packages, reason, ...
 for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions)

Ben file:

title = "libopm-common-2023";
is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm-
common-2023.10";
is_good = .depends ~ "libopm-common-2023.10";
is_bad = .depends ~ "libopm-common-2023.04";

Thanks a lot.

Kind regards,

Markus

[1] https://qa.debian.org/developer.php?login=markus%40dr-blatt.de

Bug#1054919: kaccounts-providers: google authentication hang after username entry

[Dmitry Shachnev]

Hi Nicholas!

On Sun, Nov 12, 2023 at 03:36:20PM -0500, Nicholas D Steeves wrote:
> > Unlike Qt WebKit which is based on Apple WebKit, Qt WebEngine is based on
> > Chromium codebase.
> >
> > Qt WebEngine user agents will look the following:
> >
> > Qt 5.15:
> > Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
> > QtWebEngine/5.15.15 Chrome/87.0.4280.144 Safari/537.36
> 
> So if we backport signon-ui's future Webkit -> WebEngine fix to
> bookworm, Google might still blacklist bookworm kaccounts users for
> having a user agent string that advertises an ancient browser?

Yes, but I don't know Google's exact policy on this.

But Chrome 87 is from 2020, which is much better than WebKit from 2016.

> Chrome/87.0.4280.144 is pretty old.  That said, I assume there are
> security reasons why we should use WebEngine and not Webkit in bookworm?

Yes. Qt WebKit has no security support at all, so many vulnerabilities
discovered in WebKit since 2016 are likely present there.

Qt WebEngine, on the contrary, backports security fixes from Chromium:

https://sources.debian.org/src/qtwebengine-opensource-src/5.15.15%2Bdfsg-2/CHROMIUM_VERSION/

Unfortunately we do not have enough manpower to backport all these fixes
to Debian stable releases, but Debian unstable has the latest Qt WebEngine
most of the time (I'm speaking for 5.15 branch mostly, which I'm the
maintainer of).

That said, if signon-ui only loads one hardcoded website, and not random
content, I don't think you need to worry much about security.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1054919: kaccounts-providers: google authentication hang after username entry

[Nicholas D Steeves]

Hi Dmitry!

Dmitry Shachnev  writes:

> Hi everyone!
>
> Sorry for the late reply, but let me try to answer the questions which remain
> unanswered.

Thank you for finding the time to reply and to explain the Qt side of
things :)

> On Sun, Oct 29, 2023 at 07:43:51PM +0100, Alexis Murzeau wrote:
[snip background]
>
>> Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead.
>> I guess signon-ui should move to QtWebEngine instead but sadly upstream
>> seems rather dead :(, the previous signon-ui release was more than 5
>> years ago.
>
> Yes, Qt WebKit does not support Qt 6, so the only choice is to migrate to
> Qt WebEngine which is supported much better. I would recommend doing that
> even if you stay on Qt 5.

I've filed #1055855 for this purpose, with a link to a breadcrumb trail
from SUSE.

> Unlike Qt WebKit which is based on Apple WebKit, Qt WebEngine is based on
> Chromium codebase.
>
> Qt WebEngine user agents will look the following:
>
> Qt 5.15:
> Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
> QtWebEngine/5.15.15 Chrome/87.0.4280.144 Safari/537.36

So if we backport signon-ui's future Webkit -> WebEngine fix to
bookworm, Google might still blacklist bookworm kaccounts users for
having a user agent string that advertises an ancient browser?
Chrome/87.0.4280.144 is pretty old.  That said, I assume there are
security reasons why we should use WebEngine and not Webkit in bookworm?


Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1055237: does not conform to the standards for library packaging

[Matthias Geiger]

Control: -1 affects src:trompeloeil-cpp

On Wed, 8 Nov 2023 09:57:39 +0100 Pierre Gruet  wrote:

> Control: severity -1 important
>

> This seems like a good reason to keep a static library, at least for the
> moment.
>
> If there remains only the renaming of the package and its description to
> be changed, then downgrading the severity looks sensible.
>
> >
> > > As a side note, the upload of the major version 3.x came out with
> many breaking
> > > interface changes giving rise to RC bugs in e.g. genomicsdb,
> netgen, spdlog,
> > > therion just to name a few, also to failing autopkgtests in many
> rdeps. I would
> > > have been more comfortable with such a huge version change being
> advertised and
> > > more prepared, with some kind of a library transition process for

> instance.

Should there maybe a new src:catch2 package be provided ? This also 
broke tests for trompeloeil-cpp which I maintain.


This seems like a sensible solution for now. according to upstream notes 
catch/catch2.hpp is superseded by catch/catch2_all.hpp,


but liking against this header does not work for my package (see 
https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md).


I'd propose to check which packages work with the newer catch and patch 
if necessary; if it's inevitable I'd argue to create a semver catch2 
package.


best,

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



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1009259: nvidia-legacy-340xx-driver: Crash at start with linux 5.10

[Andreas Beckmann]

On 11/11/2023 14.51, Mike Mironov wrote:

Hello!

Problem solved. Error in conftest drm_device_has_pdev.

TL;DR; Just replace file in /usr/src/nvidia-legacy-340xx-340.108/patches 
with included in this mail and rebuild module.


Orig conftest try include #include  instead of 
#include  and not include #include 


So drm_device_has_pdev conf test fail. Modified file included in this 
mail. I hope maintainers release new version


Thanks for digging into this. The actual problem seems to be 
NV_DRM_DRM_DEVICE_H_PRESENT not being defined despite of the header 
actually existing ... I missed to backport the check for 
drm/drm_device.h which was introduced much earlier than 470.63.01 (where 
I took the drm_device_has_pdev patch from), could have been 390.138, but 
that did not exist in the 340xx series, yet.


Andreas

Bug#1055855: We need to switch to a version that uses Qt WebEngine

[Nicholas D Steeves]

Source: signon-ui
Version: 0.17+16.04.20151125-1
Severity: important
Control: tag -1 trixie

Continuing from Dmitry Shachnev (mitya57)'s message at the kaccounts-providers 
bug that is affected by this one:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#51

We need to switch to a signon-ui release that uses Qt WebEngine rather
than the dead Qt WebKit, and we need to do this before trixie.
Honestly, the sooner the better...

When I was searching for a living upstream for signon-ui, I found that
SUSE appears to use a version that has already switched to WebEngine:
  https://packagehub.suse.com/packages/signon-ui/0_17+20171022-bp155_3_16/

I didn't investigate more than that, but it looks like there is
already a resolution.  It might just be a question of switch to a more
alive upstream, and/or replicating a SUSE patch series (I didn't check).

Also, it might be a good idea import the changes as patches (whether
from upstream, new upstream, and/or SUSE) so that we can backport them
more easily to bookworm, because Google is not totally unreasonable to
experimented with blacklisting a web browser user agent string that
dates to 2016!

Regards,
Nicholas

Bug#1026164: ffprobe: "-of json" doesn't report anything

[Phil Wyett]

On Sun, 12 Nov 2023 20:17:03 +0100 Diederik de Haas  
wrote:
> On 15 Dec 2022 16:05:03 +0100 Matthias Urlichs  wrote:
> > Package: ffmpeg
> > Version: 7:5.1.2-1
> > 
> > $ ffprobe -of json ./01.ogg >/tmp/ff.stdout 2>/tmp/ff.stderr
> > $ cat /tmp/ff.stderr
> > [only header, but no json output]
> > $ cat /tmp/ff.stdout
> > {
> > 
> > }
> > 
> > I'm fairly sure that this is not the intended behavior.
> > 
> > Upstream says that this works for them.
> > https://trac.ffmpeg.org/ticket/10104
> 
> I can reproduce your findings, but ...
> 
> $ ffprobe -hide_banner -of json Critical.ogg 
> {
> Input #0, ogg, from 'Critical.ogg':
>   Duration: 00:00:00.63, start: 0.00, bitrate: 129 kb/s
>   Stream #0:0: Audio: vorbis, 48000 Hz, mono, fltp, 86 kb/s
> 
> }
> $ ffprobe -hide_banner -of json Critical.ogg 2>/dev/null
> {
> 
> }
> 
> So it looks like `2>/dev/null` 'hides' the output.
> I don't know if without it, is valid json though.
> Using 'xml' as output_format gives an interesting result ...

Hi,

Looking at the docs, you can use -of or -print_format like follows for a nice 
json file.

ffprobe -v quiet -of json -show_format -show_streams "Critical.ogg" > 
"Critical.ogg.json"

Your needs may require some changes.

Regards

Phil

-- 
Playing the game for the games sake.

* Debian Maintainer

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org

Social:

* Instagram: kathenasorg
* Threads: @kathenasorg





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

Bug#1055833: charliecloud: autopkgtest fails in unstable, blocks other packages migration

[Luca Boccassi]

Control: severity -1 serious

On Sun, 12 Nov 2023 13:54:56 + Peter Wienemann 
wrote:
> Dear Luca,
> 
> On 2023-11-12 13:20:16 +0100, Luca Boccassi wrote:
> > Source: charliecloud
> > Version: 0.35-4
> > Severity: important
> > 
> > charliecloud's autopkgtest is failing in unstable, and it is
blocking
> > iproute2's migration as they are tested together:
> > 
> >
https://ci.debian.net/data/autopkgtest/testing/s390x/c/charliecloud/39798421/log.gz
> 
> thanks for your bug report. I hope that this issue is fixed by 0.35-5
> which I uploaded shortly before your bug report:
> 
>
https://tracker.debian.org/news/1477982/accepted-charliecloud-035-5-source-into-unstable/
> 
> I will keep this bug open until we know for sure.

Unfortunately it looks like it's still failing. The Release Team asked
to bump the severity in order to unblock iproute2, proceeding as
requested.

-- 
Kind regards,
Luca Boccassi


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

Bug#1040084:

[Alexandre Detiste]

control: severity -1 minor
control: tag -1 +wontfix

Hi,

This is a false positive.

"typeshed" doesn't _do_ anything,
it's _mypy_ that does the type checking.

typeshed is merely hints data for mypy.

usage of asyncore and asynchat
will eventually fade away from type hints.

Greetings

Bug#1055345: git-buildpackage: Please document how to build against a package from experimental

[Guido Günther]

Hi,
On Sun, Nov 05, 2023 at 09:18:58PM +0100, Martin Quinson wrote:
> Le dimanche 05 novembre 2023 à 17:27 +0100, Guido Günther a écrit :
> > Hi Martin,
> > On Sat, Nov 04, 2023 at 04:43:10PM +0100, Martin Quinson wrote:
> > > Package: git-buildpackage
> > > Version: 0.9.32
> > > Severity: wishlist
> > > Tags: patch
> > > 
> > > Hello,
> > > 
> > > thanks a lot for this package, that very often saves my life when
> > > packaging.
> > > There is one thing however where gbp could be more helpful, it's when I
> > > have to
> > > build my package against a build-depend that comes from experimental.
> > > 
> > > I finally found a way to do it, and I propose the following patch for the
> > > documentation for the next person looking for this information. I fully
> > > acknowledge that this documentation is somehow suboptimal, and that the 
> > > gbp
> > > tool could be more helpful here, but the proposed documentation would
> > > already
> > > be great.
> > 
> > Thanks for taking the time to document this. Some minor nits below:
> > 
> > 
> > > ---
> > >  docs/chapters/special.xml |   25 +
> > >  1 file changed, 25 insertions(+)
> > > 
> > > Index: b/docs/chapters/special.xml
> > > ===
> > > --- a/docs/chapters/special.xml
> > > +++ b/docs/chapters/special.xml
> > > @@ -40,6 +40,31 @@
> > >  
> > >  
> > >  
> > > +    
> > > +    Using build-depends from experimental
> > > +    
> > 
> > This should mention that one ought to use `gbp buildpackage
> > --git-pbuilder` (as that is not the default).
> 
> Agreed.
> 
> > > +    To build your package against a build-depends taken from 
> > > experimental,
> > > you first need
> > > +    to configure your pbuilder. To that extend, add the following to
> > > +    ~/.pbuilderrc to instruct pbuilder to take build
> > > depends from
> > > +    experimental when they cannot be satisfied from unstable.
> > > +    
> > > +    
> > > +PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-
> > > experimental
> > > +    
> > 
> > Wouldn't we want to make that conditional like:
> > 
> > if [ "$GBP_DIST" = "experimental" ]; then
> >     echo "Using 'pbuilder-satisfydepends-experimental' for $GBP_DIST"
> >     PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-
> > experimental
> > fi
> 
> Nice addition, thanks.
> 
> > but I *think* this is even the default nowadays for building against
> > experimental.
> > 
> > > +    
> > > +    You then need to add experimental to the apt configuration within the
> > > chroot.
> > > +    The simplest for that is to edit the config file from outside of the
> > > chroot directly,
> > > +    as follows:
> > > +    
> > > +sudo bash -c "echo 'deb http://deb.debian.org/debian experimental main' 
> > > >>
> > > /var/cache/pbuilder/base.cow/etc/apt/sources.list"
> > > +    
> > 
> > What about suggesting to bootstrap a new environment instead via:
> > 
> >    DIST=experimental git-pbuilder create 
> > 
> > This also handles adding experimental to /etc/apt/sources.list (no extra
> > setup needed). Maybe we can streamline things that way a bit?
> 
> This has the drawback of taking all dependencies from experimental, which may
> not be what one wants.

Is that that the case? I didn't see where in the chroot that would be
configured. Can you point me to it?

Cheers,
 -- Guido

> 
> I agree that things could be streamlined in the tool, but documenting how to
> get around the corner with the current tools is already great, IMHO.
> 
> Thanks,
> Mt

Bug#1052069: ways to proceed?

[Andreas Beckmann]

On 12/11/2023 15.21, Adam Majer wrote:

On 2023-11-10 10:51, Andreas Beckmann wrote:

The module should continue to work on 6.1
The module should continue to work on 6.5 booted with ibt=off
The module should fail to load with an error message describing the 
issue on 6.5 with ibt enabled, but without a kernel BUG.


Did you find some time to test the package patched with my IBT related 
changes?


I've managed to add the patch today and recompile. Complete success and 
works as expected. It no longer crashes when ibt=on.


Initially I've had an idea to automatically set this kernel command line 
boot values when the module is installed, but having this informative 


Theoretically I could have patched the module to disable IBT at runtime 
while loading the incompatible module ... but I doubt that silently* 
lowering the system security level is a good idea ... that should rather 
be admin's choice. Also, this behavioral change wouldn't exist in any 
other distro.


*) silently includes kprint("LOWERING SECURITY LEVEL BY DISABLING IBT TO 
LOAD PROPRIETARY LEGACY KERNEL MODULE")


message is actually better. One nit-pick is that the kernel message is 
not clear as to what module it's talking about.


kernel: NVRM: This module is incompatible with IBT. Try booting with 
ibt=off.


A better message could be,

kernel: NVRM: This Nvidia driver is incompatible with IBT. Try booting 
with ibt=off.


Thanks for the feedback, I'll update the error message and apply this 
patch to all driver series up to 470. (This does not seem to be fixed in 
470.223.02, and maybe upstream will never provide an IBT-enabled build 
for the old driver series. The percentage of people running a modern cpu 
with a legacy gpu is probably very low.)


Andreas

Bug#1055613: Configuration files hidden in /usr/lib/

[Alexandre Detiste]

control: tag -1 +wontfix

Hi, if you ever want to overrides theses configs [1],
the proper way is to create a matching
file in /etc/tmpfiles.d/SOMETHING.conf

https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html

Greetings

[1]: but ... why ?

Bug#1026164: ffprobe: "-of json" doesn't report anything

[Diederik de Haas]

On 15 Dec 2022 16:05:03 +0100 Matthias Urlichs  wrote:
> Package: ffmpeg
> Version: 7:5.1.2-1
> 
> $ ffprobe -of json ./01.ogg >/tmp/ff.stdout 2>/tmp/ff.stderr
> $ cat /tmp/ff.stderr
> [only header, but no json output]
> $ cat /tmp/ff.stdout
> {
> 
> }
> 
> I'm fairly sure that this is not the intended behavior.
> 
> Upstream says that this works for them.
> https://trac.ffmpeg.org/ticket/10104

I can reproduce your findings, but ...

$ ffprobe -hide_banner -of json Critical.ogg 
{
Input #0, ogg, from 'Critical.ogg':
  Duration: 00:00:00.63, start: 0.00, bitrate: 129 kb/s
  Stream #0:0: Audio: vorbis, 48000 Hz, mono, fltp, 86 kb/s

}
$ ffprobe -hide_banner -of json Critical.ogg 2>/dev/null
{

}

So it looks like `2>/dev/null` 'hides' the output.
I don't know if without it, is valid json though.
Using 'xml' as output_format gives an interesting result ...

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

Bug#1054919: kaccounts-providers: google authentication hang after username entry

[Dmitry Shachnev]

Hi everyone!

Sorry for the late reply, but let me try to answer the questions which remain
unanswered.

On Sun, Oct 29, 2023 at 07:43:51PM +0100, Alexis Murzeau wrote:
> I'm not sure how Qt webkit works, but I guess it behaves like a old
> chrome browser. I don't know if it uses a different user agent, but
> maybe Google doesn't recognize that it doesn't support newer web stuff.

Qt WebKit does not identify itself like Chrome. It identifies itself like
AppleWebKit and Safari, which makes sense because Safari is the most known
browser based on WebKit engine.

The current Qt WebKit user agent is:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) 
Qt/5.15.10 Version/10.0 Safari/602.1

The Qt/5.15.10 component may be replaced with name and version of the
application.

Indeed, this is an ancient version. I think 602.1 branch is from 2016.
However, changing it to a newer version would be lying.

Qt WebKit is not supported by upstream Qt since Qt 5.6, and the first
community fork is also dead now. There is another fork, but I won't call it
alive either.

> Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead.
> I guess signon-ui should move to QtWebEngine instead but sadly upstream
> seems rather dead :(, the previous signon-ui release was more than 5
> years ago.

Yes, Qt WebKit does not support Qt 6, so the only choice is to migrate to
Qt WebEngine which is supported much better. I would recommend doing that
even if you stay on Qt 5.

Unlike Qt WebKit which is based on Apple WebKit, Qt WebEngine is based on
Chromium codebase.

Qt WebEngine user agents will look the following:

Qt 5.15:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
QtWebEngine/5.15.15 Chrome/87.0.4280.144 Safari/537.36

Qt 6.4:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
QtWebEngine/6.4.2 Chrome/102.0.5005.177 Safari/537.36

Qt 6.6:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
QtWebEngine/6.6.0 Chrome/112.0.5615.213 Safari/537.36

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1055854: radare2: CVE-2023-5686

[Moritz Mühlenhoff]

Source: radare2
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for radare2.

CVE-2023-5686[0]:
| Heap-based Buffer Overflow in GitHub repository radareorg/radare2
| prior to 5.9.0.

https://huntr.com/bounties/bbfe1f76-8fa1-4a8c-909d-65b16e970be0
https://github.com/radareorg/radare2/commit/1bdda93e348c160c84e30da3637acef26d0348de


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5686
https://www.cve.org/CVERecord?id=CVE-2023-5686

Please adjust the affected versions in the BTS as needed.

Bug#1055852: frr: CVE-2023-38407 CVE-2023-41361 CVE-2023-46752 CVE-2023-46753 CVE-2023-47234 CVE-2023-47235

[Moritz Mühlenhoff]

Source: frr
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for frr.

CVE-2023-38407[0]:
| bgpd/bgp_label.c in FRRouting (FRR) before 8.5 attempts to read
| beyond the end of the stream during labeled unicast parsing.

https://github.com/FRRouting/frr/pull/12951
https://github.com/FRRouting/frr/commit/7404a914b0cafe046703c8381903a80d3def8f8b
 (base_9.0)
https://github.com/FRRouting/frr/pull/12956
https://github.com/FRRouting/frr/commit/ab362eae68edec12c175d9bc488bcc3f8b73d36f
 (frr-8.5)

CVE-2023-41361[1]:
| An issue was discovered in FRRouting FRR 9.0. bgpd/bgp_open.c does
| not check for an overly large length of the rcv software version.

https://github.com/FRRouting/frr/pull/14241
Fixed by: 
https://github.com/FRRouting/frr/commit/b4d09af9194d20a7f9f16995a062f5d8e3d32840
Backport for 9.0 branch: https://github.com/FRRouting/frr/pull/14250
Fixed by: 
https://github.com/FRRouting/frr/commit/73ad93a83f18564bb7bff4659872f7ec1a64b05e

CVE-2023-46752[2]:
| An issue was discovered in FRRouting FRR through 9.0.1. It
| mishandles malformed MP_REACH_NLRI data, leading to a crash.

Fixed by: 
https://github.com/FRRouting/frr/commit/b08afc81c60607a4f736f418f2e3eb06087f1a35
 (master)
Fixed by: 
https://github.com/FRRouting/frr/commit/30b5c2a434d25981e16792f6f50162beb517ae4d
 (stable/8.5 branch)

CVE-2023-46753[3]:
| An issue was discovered in FRRouting FRR through 9.0.1. A crash can
| occur for a crafted BGP UPDATE message without mandatory attributes,
| e.g., one with only an unknown transit attribute.

Fixed by: 
https://github.com/FRRouting/frr/commit/d8482bf011cb2b173e85b65b4bf3d5061250cdb9
 (master)
Fixed by: 
https://github.com/FRRouting/frr/commit/21418d64af11553c402f932b0311c812d98ac3e4
 (stable/8.5 branch)

CVE-2023-47234[4]:
| An issue was discovered in FRRouting FRR through 9.0.1. A crash can
| occur when processing a crafted BGP UPDATE message with a
| MP_UNREACH_NLRI attribute and additional NLRI data (that lacks
| mandatory path attributes).

https://github.com/FRRouting/frr/commit/c37119df45bbf4ef713bc10475af2ee06e12f3bf

CVE-2023-47235[5]:
| An issue was discovered in FRRouting FRR through 9.0.1. A crash can
| occur when a malformed BGP UPDATE message with an EOR is processed,
| because the presence of EOR does not lead to a treat-as-withdraw
| outcome.

https://github.com/FRRouting/frr/commit/6814f2e0138a6ea5e1f83bdd9085d9a7700b

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-38407
https://www.cve.org/CVERecord?id=CVE-2023-38407
[1] https://security-tracker.debian.org/tracker/CVE-2023-41361
https://www.cve.org/CVERecord?id=CVE-2023-41361
[2] https://security-tracker.debian.org/tracker/CVE-2023-46752
https://www.cve.org/CVERecord?id=CVE-2023-46752
[3] https://security-tracker.debian.org/tracker/CVE-2023-46753
https://www.cve.org/CVERecord?id=CVE-2023-46753
[4] https://security-tracker.debian.org/tracker/CVE-2023-47234
https://www.cve.org/CVERecord?id=CVE-2023-47234
[5] https://security-tracker.debian.org/tracker/CVE-2023-47235
https://www.cve.org/CVERecord?id=CVE-2023-47235

Please adjust the affected versions in the BTS as needed.

Bug#1055853: jgit: CVE-2023-4759

[Moritz Mühlenhoff]

Source: jgit
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for jgit.

CVE-2023-4759[0]:
| Arbitrary File Overwrite in Eclipse JGit <= 6.6.0  In Eclipse JGit,
| all versions <= 6.6.0.202305301015-r, a symbolic link present in a
| specially crafted git repository can be used to write a file to
| locations outside the working tree when this repository is cloned
| with JGit to a case-insensitive filesystem, or when a checkout from
| a clone of such a repository is performed on a case-insensitive
| filesystem.  This can happen on checkout (DirCacheCheckout), merge
| (ResolveMerger via its WorkingTreeUpdater), pull (PullCommand using
| merge), and when applying a patch (PatchApplier). This can be
| exploited for remote code execution (RCE), for instance if the file
| written outside the working tree is a git filter that gets executed
| on a subsequent git command.  The issue occurs only on case-
| insensitive filesystems, like the default filesystems on Windows and
| macOS. The user performing the clone or checkout must have the
| rights to create symbolic links for the problem to occur, and
| symbolic links must be enabled in the git configuration.  Setting
| git configuration option core.symlinks = false before checking out
| avoids the problem.  The issue was fixed in Eclipse JGit version
| 6.6.1.202309021850-r and 6.7.0.202309050840-r, available via  Maven
| Central https://repo1.maven.org/maven2/org/eclipse/jgit/  and
| repo.eclipse.org https://repo.eclipse.org/content/repositories/jgit-
| releases/ .   The JGit maintainers would like to thank RyotaK for
| finding and reporting this issue.

https://git.eclipse.org/c/jgit/jgit.git/commit/?id=9072103f3b3cf64dd12ad2949836ab98f62dabf1
 (v6.6.1.202309021850-r)
https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/11


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-4759
https://www.cve.org/CVERecord?id=CVE-2023-4759

Please adjust the affected versions in the BTS as needed.

Bug#1031062: rclone: FTBFS randomly (autobuilder hangs)

[Santiago Vila]

Note: The build does not hang when using sbuild
with a chroot of type "file", like this:

[bookworm-file]
type=file
profile=sbuild
description=Debian bookworm
file=/chroot/bookworm.tar.gz
groups=sbuild
root-groups=sbuild
preserve-environment=true

Previously, I was using a chroot of type "directory".

This is probably a bug anyway, as there is not a debian/control
field to specify the kind of chroot that should be used, but
I'll need to investigate a little bit more before making an
upload for stable.

Thanks.

Bug#1055851: passenger: provide libnginx-mod-http-passenger package

[Felip]

Package: passenger
Version: 6.0.17+ds-1
Severity: wishlist

Dear Maintainer,

I tried to install Redmine (some management software written in Ruby)
with nginx and Passenger on Debian Bookworm.

These are installation instructions for Redmine:

https://www.redmine.org/projects/redmine/wiki/RedmineInstall

And, more importantly, specific instructions for nginx on a former
version of Debian:

https://www.danielgorbe.com/en/blog/redmine-on-debian/

The latter relies on a libnginx-mod-http-passenger package, which used
to be provided for debian by the Phusion Passenger team:

https://www.phusionpassenger.com/docs/advanced_guides/install_and_upgrade/nginx/install/oss/buster.html

Alas, their repository no longer provides packages for current versions
of Debian (particularly Bookworm), although they do have packages for
Ubuntu.

Now, it turns out that Debian official repositories provide its
counterpart for Apache: libapache2-mod-passenger. How about also
providing nginx integration?


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

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

Versions of packages passenger depends on:
ii  libc6   2.36-9+deb12u3
ii  libcurl47.88.1-10+deb12u4
ii  libev4  1:4.33-1
ii  libgcc-s1   12.2.0-14
ii  libruby 1:3.1
ii  libruby3.1  3.1.2-7
ii  libssl3 3.0.11-1~deb12u2
ii  libstdc++6  12.2.0-14
ii  libuv1  1.44.2-1
ii  ruby1:3.1
ii  ruby-rack   2.2.6.4-1

passenger recommends no packages.

Versions of packages passenger suggests:
pn  nodejs   
ii  python3  3.11.2-1+b1
pn  rails

-- no debconf information

Bug#1052498: Merge request

[tony mancill]

On Thu, Nov 09, 2023 at 12:25:17PM +0200, Pushkar Kulkarni wrote:
> Submitted https://salsa.debian.org/java-team/doctorj/-/merge_requests/2
> for this.

Hello Pushkar,

Thank you for the merge request.  It looks good, so I went ahead and
merged it.

However instead of preparing an upload, I propose that we remove doctorj
from Debian.  The upstream project has been inactive for 10 years, it
has a low popcon score, and developers have other tools to accomplish
the same goal - e.g, doclint + a spellchecker.

If anyone on-list disagrees, please prepare an upload.  Otherwise, I
will file the RM bug.

Thanks,
tony


signature.asc
Description: PGP signature

Bug#1029968: fixed in 6.6

[Dr. David Alan Gilbert]

This looks like it's fixed in 6.6, I think they had a major rewrite
in there.
It's a conversion to vb2 in the series starting with
d1846d72587e9241e73a18da14a325b43700013b

There are a couple of minor oddities with that
(they list the sequence cost the bttv had) but that's relatively minor.

Dave

-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Bug#1055826: crun 0.17+dfsg-1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055826 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: crun
Version: 0.17+dfsg-1+deb11u2

Explanation: fix containers with systemd as their init system, when using newer 
kernel versions

Bug#1036975: node-url-parse 1.5.3-1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1036975 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-url-parse
Version: 1.5.3-1+deb11u2

Explanation: fix authorisation bypass issue [CVE-2022-0512]

Bug#1055850: ITP: python-django-tree-queries -- Adjacency-list trees for Django

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-tree-queries
  Version : 0.15
  Upstream Contact: Matthias Kestenholz 
* URL : https://github.com/feincms/django-tree-queries
* License : BSD-3-clause
  Programming Lang: Python
  Description : Adjacency-list trees for Django

 Query Django model trees using adjacency lists and recursive common table
 expressions. Supports PostgreSQL, sqlite3 and MariaDB and MySQL.
 .
 Features and limitations:
  * Supports only integer and UUID primary keys (for now).
  * Allows specifying ordering among siblings.
  * Uses the correct definition of depth, where root nodes have a depth of
zero.
  * The parent foreign key must be named "parent" at the moment.
  * The fields added by the common table expression always are tree_depth,
tree_path and tree_ordering. The names cannot be changed. tree_depth is an
integer, tree_path an array of primary keys and tree_ordering an array of
values used for ordering nodes within their siblings.
  * Besides adding the fields mentioned above the package only adds queryset
methods for ordering siblings and filtering ancestors and descendants.
  * Little code, and relatively simple when compared to other tree management
solutions for Django. No redundant values so the only way to end up with
corrupt data is by introducing a loop in the tree structure (making it a
graph). The TreeNode abstract model class has some protection against this.
  * Supports only trees with max. 50 levels on MySQL/MariaDB, since those
databases do not support arrays and require a maximum length for the
tree_path and tree_ordering upfront.

This is a dependency for django-content-editor and I will maintain it as part of
the DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmVRCg0bHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqExoH/3X/gCg2xKOY6q8rJ3aB
+EA+MWwIZFgFmgYPTmO3HOF8u/2HCT8rYZ9WNGgJjjVyeC2ozezNFJaLHN3qEljj
rdCJ7wG6/qgSnH5W+olk99r9ZXFeifMa2D7zDE6cd0LMSYX1WUlMIy+Ywpi10Jmz
kJ+iBzGdH97kGIP5o5T4cR2+UfHIgv1Xf9qyTjPBHTQ94672Re1jYOms5T1QuDTg
Z+Tfaz8gQriCVaZJCxK2nytMzXk8slFMiS5qKWi1iTii2PORY7xhosy9iZvdqGqv
VwRgE8wPzDVgjB5xP83vuIUbTRzEnZ4bbUlOYZWEXq/4MdH7iRQgh30ZNlMlsg9K
ZwY=
=l/cw
-END PGP SIGNATURE-

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

Please start an interactive Perl session with:

perl -d -e 1

Then execute the following:

use Image::Sane ':all';
print SANE_NAME_PAGE_HEIGHT, "\n";

and report the response.

Afterwards, you can quit with q



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1020531: dia: creating a text element kills all GUI fonts

[Prof. Dr. Christian Baun]

Hello,

Today I did a fresh install of Debian 12.2 with dia
0.97.3+git20220525-5 on a different computer and the described issue
is present.

This version of dia is unusable.

Does anyone here have a workaround?

Can I do anything to support fixing this?

Best Regards
   Christian

Bug#1055581: libgeo-gdal-ffi-perl: FTBFS with GDAL 3.8.0

[Sebastiaan Couwenberg]

Control: tags -1 fixed-upstream

Upstream fix:


https://github.com/ajolma/Geo-GDAL-FFI/commit/8eee52009825a5897aecf8b1b18f79d1100fce21

Kind Regards,

Bas

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

Bug#1055849: /usr/bin/firefox: Excessive resource demand, tab unloading disabled

[Michael Below]

Package: Umleitung durch firefox-esr von
Severity: normal
File: /usr/bin/firefox
X-Debbugs-Cc: be...@judiz.de

Dear Maintainer,

I am using Debian for music production. The rendering of music is
time-critical: if the output is not provided in time, playback
will crackle and/or stutter.

When using firefox while working on music, there is often high system load
from firefox, especially if there are multiple tabs open. That limits
the amount of resources for music and makes crackles/stutters more
likely.

Chromium puts tabs to sleep that are not in use. Firefox has a similar
feature, browser.tabs.unloadOnLowMemory, but it seems to be disabled in
Linux by default. Please consider enabling this feature by default. 

It is a common workaround to renice firefox, e.g.:
pgrep -f -w "firefox" | xargs renice --relative 5 {}

If the unloading by default is not feasible, please consider making it
easier to limit resource usage in other ways, e.g. by renicing firefox.

Thank you for your work!

Cheers
Michael



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

Kernel: Linux 6.5.0-4-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy

[Ross Vandegrift]

On Sat, Nov 11, 2023 at 09:46:51PM +0900, Osamu Aoki wrote:
> Package: cloud-init
> Version: 22.4.2-1
> Severity: normal
> 
> ## Background:
> 
> The problem and possible root cause fix are reported on upstream github
> issue: https://github.com/canonical/cloud-init/issues/4603
> 
> ## Issue:
> I noticed instance generated from Debian bookworm cloud image on
> linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a
> system group, this situation violates Debian policy.

Hi Osamu,

As Shengjing Zhu mentioned in [1], this issue was fixed in #1038691.  Is that
incorrect?

Ross

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

Bug#1055806: installation-reports: Installer doesn't recognize laptop's SSD, but calamares does

[Pokoz Martinez]

Hi Cyril and Pascal,

Thank you both for the fast response.

Cyril, I have just tested the .iso you attached to the bug report you
referred to, and indeed that installer detects my UFS disk no problem!

Thank you again so much for the fast response and for all the work you do.
I will rest assured now that this problem is known, and hopefully this
report also contributed my small grain of sand to the Debian effort!!

I hope you have a great rest of day,

Jessie.

On Sat, Nov 11, 2023 at 10:42 PM Cyril Brulebois  wrote:

> Hi Pascal,
>
> Please use reply-all…
>
> Pascal Hambourg  (2023-11-11):
> > On 11/11/2023 à 21:43, Jessie wrote:
> > >
> > > However, when detecting disks, the only disk available for install
> > > was the usb drive I had the installer on - it did not detect the
> > > 256gb UFS SSD.
> >
> > It looks like UFS (Universal Flash Storage, not Unix filesystem) kernel
> > modules are not included in d-i initrd or udebs.
>
> Hi Jessie, and thanks for reporting.
>
> See , which I have yet to forward to
> kernel maintainers.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1053307: glib2.0 2.66.8-1+deb11u1 flagged for acceptance

[Simon McVittie]

On Sun, 12 Nov 2023 at 14:58:42 +, Adam D Barratt wrote:
> Package: glib2.0
> Version: 2.66.8-1+deb11u1
> 
> Explanation: align with upstream stable fixes; fix denial of service issues 
> [CVE-2023-32665 CVE-2023-32611 CVE-2023-29499 CVE-2023-32636]; fix buffer 
> overflow issue [CVE-2023-32643]

If you're able to adjust the release notes between now and the 11.9
point release, you might want to change this wording so it just mentions
the DoS issues and other stable-branch fixes, but excludes the buffer
overflow issue CVE-2023-32643 from the description of this update.

CVE-2023-32643 was a regression caused by errors in the initial fixes
for the DoS issues. It was important that we avoided introducing it
into Debian 11, but Debian 11.8 is not vulnerable (too old), and after
accepting 2.66.8-1+deb11u1, to the best of my knowledge Debian 11.9 will
not be vulnerable either (too new).

(For the record: I think 2.74.3-1 in unstable was briefly vulnerable to
CVE-2023-32643, but that version never migrated to testing, and a fix was
included in the next upload 2.74.4-1; so testing was never vulnerable,
and therefore neither was Debian 12.0.)

Thanks,
smcv

Bug#1055848: cfgrib: autopkgtest regression

[Graham Inggs]

Source: cfgrib
Version: 0.9.10.4-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The upload of cfgrib 0.9.10.4-2 is failing its own autopkgtest [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/c/cfgrib/testing/amd64/


 80s autopkgtest [21:14:56]: test tryload: [---
 80s Traceback (most recent call last):
 80s   File 
"/tmp/autopkgtest-lxc.uvkmlxxf/downtmp/build.Qw6/src/debian/tests/tryload",
line 3, in 
 80s import cfgrib
 80s   File "/usr/lib/python3/dist-packages/cfgrib/__init__.py", line
20, in 
 80s from .cfmessage import COMPUTED_KEYS
 80s   File "/usr/lib/python3/dist-packages/cfgrib/cfmessage.py", line
29, in 
 80s from . import abc, messages
 80s   File "/usr/lib/python3/dist-packages/cfgrib/messages.py", line
28, in 
 80s import eccodes  # type: ignore
 80s ^^
 80s   File "/usr/lib/python3/dist-packages/eccodes/__init__.py", line
13, in 
 80s from .eccodes import *  # noqa
 80s ^^
 80s   File "/usr/lib/python3/dist-packages/eccodes/eccodes.py", line
12, in 
 80s from gribapi import (
 80s   File "/usr/lib/python3/dist-packages/gribapi/__init__.py", line
13, in 
 80s from .gribapi import *  # noqa
 80s ^^
 80s   File "/usr/lib/python3/dist-packages/gribapi/gribapi.py", line
34, in 
 80s from gribapi.errors import GribInternalError
 80s   File "/usr/lib/python3/dist-packages/gribapi/errors.py", line
16, in 
 80s from .bindings import ENC, ffi, lib
 80s   File "/usr/lib/python3/dist-packages/gribapi/bindings.py", line
35, in 
 80s raise RuntimeError("Cannot find the ecCodes library")
 80s RuntimeError: Cannot find the ecCodes library

Bug#1055838: gnome: GNOME Text Editor not chosen or listed for text files

[Simon McVittie]

Control: reassign -1 gnome-session-common 45.0-1
Control: affects -1 + gnome-core

On Sun, 12 Nov 2023 at 14:12:25 +0100, Paul Menzel wrote:
> With Debian sid/unstable and *gnome* 1:44+1, text files, for example with
> the suffix .txt, are opened with LibreOffice Writer and not GNOME Text
> Editor (*gnome-text-editor* 45.0-1).

This seems to be because /usr/share/applications/gnome-mimeapps.list in
gnome-session-common lists gedit but not gnome-text-editor. It should
list both, with some appropriate default priority order (presumably
gnome-text-editor > gedit, since gnome-text-editor is the one that is
pulled in by the gnome-core metapackage).

You should be able to work around this by editing ~/.config/mimeapps.list
to add:

[Default Applications]
text/plain=org.gnome.TextEditor.desktop

This should be fixed by a change to gnome-session-common rather than gnome,
so I'm reassigning the bug.

> It’s not even listed in the application choices.

I'm surprised by that, because
/usr/share/applications/org.gnome.TextEditor.desktop does list text/plain
as a supported file type, but perhaps updating gnome-mimeapps.list would
fix that too.

smcv

Bug#1055847: python-sparse: autopkgtest regression on arm64 and s390x

[Graham Inggs]

Source: python-sparse
Version: 0.14.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The upload of python-sparse 0.14.0-1 is failing its own autopkgtest on
arm64 and s390x [1][2].  I've copied what I hope is the relevant part
of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-sparse/testing/arm64/
[2] https://ci.debian.net/packages/p/python-sparse/testing/s390x/


60s autopkgtest [15:18:15]: test command1: set -e ; cp -r sparse/tests
"$AUTOPKGTEST_TMP" ; for py in $(py3versions -r 2>/dev/null) ; do cd
"$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -m pytest -v ;
done
 60s autopkgtest [15:18:15]: test command1: [---
 60s Testing with python3.11:
 60s = test session starts
==
 60s platform linux -- Python 3.11.6, pytest-7.4.3, pluggy-1.3.0 --
/usr/bin/python3.11
 60s cachedir: .pytest_cache
 60s rootdir: /tmp/autopkgtest-lxc.ia_llwxf/downtmp/autopkgtest_tmp
 63s collecting ... collected 5496 items
 63s
 67s tests/test_array_function.py::test_unary[mean] Fatal Python
error: Segmentation fault

Bug#1055843: python-pyproj: Build-Depends on python3-xarray which is not in testing

[Sebastiaan Couwenberg]

On 11/12/23 15:46, Graham Inggs wrote:

python-pyproj has a build-dependency on python3-xarray which is no
longer in testing.


xarray is required for test/test_utils.py.


Please drop this build-dependency or help get python3-xarray back into testing.


I already provided a patch for python-xarray in #1050854, but I'm not 
willing to NMU the package. Alastair doesn't push his changes to Salsa 
far too often. I'd be willing to do a team upload if it was a properly 
team maintained package, but Alastair's packages aren't.


By providing the patch in #1050854, I've already done what I can to fix 
the xarray mess, now it's up to someone else to resolve the outstanding 
issues with that badly maintained package.


Kind Regards,

Bas

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

Bug#1055826: bullseye-pu: package crun/0.17+dfsg-1+deb11u2 (bullseye regression)

[Adam D. Barratt]

On Sun, 2023-11-12 at 09:56 +0200, Faidon Liambotis wrote:
> A change merged into Linux v6.6 broke crun. The change was backported
> in the stable branch with v6.1.55, the version in bookworm. We fixed
> crun last week crun 1.8.1-1+deb12u1 (unblock request: #1055241).
> 
> Salvatore Bonaccorso pointed out that the change was backported into
> all the stable branches, including v5.10.197, the version now in
> bullseye. bullseye's crun, v0.17, is also affected, therefore
> bullseye crun + bullseye Linux (or bullseye crun+bullseye-backports
> Linux etc.) are now broken as well.
> 

I guess you'd like that pushed via bullseye-updates, once it's ready,
as with the bookworm update?

Regards,

Adam

Bug#1055846: texlive-extra-utils: spix is listed in the package description but not installed in package files

[Vincent-Xavier JUMEL]

Package: texlive-extra-utils
Version: 2023.20231007-2
Severity: important

Dear Maintainer,

   While I wanted to give spix a try
   (https://spix.readthedocs.io/en/latest/install/) I've trusted Debian to
   package it in this specific package, which is reported by
   `apt show texlive-extra-utils | grep spix`

   Instead, my shell reported no `/usr/bin/spix` and
   `dpkg -L texlive-extra-utils | grep spix` shows that spix is installed
   but misses a link in `/usr/bin/`

  Could you please fix it ?



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2024 Nov  3 00:10 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12  2022 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Oct  8 22:00 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Oct  8 22:00 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Oct 20  2022 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Oct  8 22:00 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Oct  8 22:00 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3130 Oct 15 15:26 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Apr  1  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 20  2022 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-extra-utils depends on:
ii  libfile-homedir-perl   1.006-2
ii  libunicode-linebreak-perl  0.0.20190101-1+b5
ii  libyaml-tiny-perl  1.74-1
ii  python33.11.4-5+b1
ii  tex-common 6.18
ii  texlive-base   2023.20231007-1
ii  texlive-binaries   2023.20230311.66589-6
ii  texlive-latex-base 2023.20231007-1
ii  texlive-luatex 2023.20231007-1
ii  texlive-plain-generic  2023.20231007-2

Versions of packages texlive-extra-utils recommends:
ii  ghostscript10.02.1~dfsg-1
ii  liblog-log4perl-perl   1.57-1
ii  ruby   1:3.1
ii  texlive-latex-recommended  2023.20231007-1

Versions of packages texlive-extra-utils suggests:
ii  chktex1.7.8-1
ii  default-jre-headless  2:1.17-75
pn  dvidvi
ii  dvipng1.15-1.1+b1
pn  fragmaster
ii  lacheck   1.26-17
ii  latexdiff 1.3.2-1
ii  latexmk   1:4.80-1
pn  purifyeps 
pn  xindy 

Versions of packages 

Bug#1006292: plasma-discover 5.20.5-3+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1006292 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: plasma-discover
Version: 5.20.5-3+deb11u2

Explanation: fix build failure

Bug#1055022: distro-info-data 0.51+deb11u5 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055022 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: distro-info-data
Version: 0.51+deb11u5

Explanation: add Ubuntu 24.04 LTS Noble Numbat; fix several End Of Life dates

Bug#1055022: distro-info 1.0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055022 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: distro-info
Version: 1.0+deb11u1

Explanation: update tests for distro-info-data 0.58+deb12u1, which adjusted 
Debian 7's EoL date

Bug#1054121: axis 1.4-28+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1054121 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: axis
Version: 1.4-28+deb11u1

Explanation: filter out unsupported protocols in the client class 
ServiceFactory [CVE-2023-40743]

Bug#1053307: glib2.0 2.66.8-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1053307 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: glib2.0
Version: 2.66.8-1+deb11u1

Explanation: align with upstream stable fixes; fix denial of service issues 
[CVE-2023-32665 CVE-2023-32611 CVE-2023-29499 CVE-2023-32636]; fix buffer 
overflow issue [CVE-2023-32643]

Bug#1040679: node-dottie 2.0.2-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1040679 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-dottie
Version: 2.0.2-1+deb11u1

Explanation: fix prototype pollution issue [CVE-2023-26132]

Bug#1034665: node-xml2js 0.2.8-1.1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1034665 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: node-xml2js
Version: 0.2.8-1.1+deb11u1

Explanation: fix prototype pollution issue [CVE-2023-0842]

Bug#1036977: jqueryui 1.12.1+dfsg-8+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1036977 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: jqueryui
Version: 1.12.1+dfsg-8+deb11u2

Explanation: fix cross-site scripting issue [CVE-2022-31160]

Bug#1031097: conmon 2.0.25+ds1-1.1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1031097 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: conmon
Version: 2.0.25+ds1-1.1+deb11u1

Explanation: do not hang when forwarding container stdout/stderr with lots of 
output

Bug#1020303: modsecurity-apache 2.9.3-3+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1020303 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: modsecurity-apache
Version: 2.9.3-3+deb11u2

Explanation: fix protection bypass issues [CVE-2022-48279 CVE-2023-24021]

Bug#1055845: matplotlib: Build-Depends on python3-xarray which is not in testing

[Graham Inggs]

Source: matplotlib
Version: 3.6.3-1
Severity: serious
Tags: ftbfs

Hi Maintainer

matplotlib has a build-dependency on python3-xarray which is no longer
in testing.

Please drop this build-dependency or help get python3-xarray back into testing.

Regards
Graham

Bug#1055844: pandas: Build-Depends on python3-xarray which is not in testing

[Graham Inggs]

Source: pandas
Version: 1.5.3+dfsg-6
Severity: serious
Tags: ftbfs

Hi Maintainer

pandas has a build-dependency on python3-xarray which is no longer in testing.

Please drop this build-dependency or help get python3-xarray back into testing.

Regards
Graham

Bug#1055843: python-pyproj: Build-Depends on python3-xarray which is not in testing

[Graham Inggs]

Source: python-pyproj
Version: 3.6.1-1
Severity: serious
Tags: ftbfs

Hi Maintainer

python-pyproj has a build-dependency on python3-xarray which is no
longer in testing.

Please drop this build-dependency or help get python3-xarray back into testing.

Regards
Graham

Bug#1050496: Bug still present on v5.3-1

[YOSHINO Yoshihito]

Control: tags -1 + moreinfo

Hi Rock,

I am not a maintainer, but I can look into this if you provide more
details of the CSV file.
A similar CSV file to reproduce the behavior would be welcome.

Regards,
-- 
YOSHINO Yoshihito 

Bug#1039417: welcome2l: ships sysv-init script without systemd unit

[Luca Boccassi]

On Sun, 12 Nov 2023 at 14:26, Chris Hofstaedtler  wrote:
>
> * bl...@debian.org :
> > Package: welcome2l
> [..]
>
> > Dear Maintainer(s),
> >
> > welcome2l has been flagged by Lintian as shipping a sysv-init script
> > without a corresponding systemd unit file. The default init system in
> > Debian is systemd, and so far this worked because a transitional
> > sysv-init-to-unit generator was shipped by systemd. This is in the
> > process of being deprecated and will be removed by the time Trixie
> > ships, so the remaining packages that ship init scripts without
> > systemd units will stop working.
>
> It should be noted that in the current situation, welcome2l already
> does nothing on systemd systems (as it cannot write to the console).
>
> > In case this is a false positive, please add a Lintian override to
> > silence it and then close this bug.
>
> Might be the best option?

Then I'd suggest to make it depend on sysvinit-core and override the warning

Bug#1055842: RFS: astro/0.24.0-1 [ITP] -- Gemini web browser using shell script

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : astro
Version : 0.24.0-1
Upstream contact : Brian Mayer 
* URL : https://github.com/blmayer/astro
* License : Expat
* Vcs : https://salsa.debian.org/akashdoppalapudi/astro
Section : net

The source builds the following binary packages:

astro - Gemini web browser using shell script


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/a/astro/astro_0.24.0-1.dsc


Changes for the initial release:

astro (0.24.0-1) unstable; urgency=medium
.
* Initial release. (Closes: #1036734)

Regards,


OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039417: welcome2l: ships sysv-init script without systemd unit

[Chris Hofstaedtler]

* bl...@debian.org :
> Package: welcome2l
[..]

> Dear Maintainer(s),
> 
> welcome2l has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file. The default init system in
> Debian is systemd, and so far this worked because a transitional
> sysv-init-to-unit generator was shipped by systemd. This is in the
> process of being deprecated and will be removed by the time Trixie
> ships, so the remaining packages that ship init scripts without
> systemd units will stop working.

It should be noted that in the current situation, welcome2l already
does nothing on systemd systems (as it cannot write to the console).

> In case this is a false positive, please add a Lintian override to
> silence it and then close this bug.

Might be the best option?

Chris

Bug#1055841: spyder-kernels: Build-Depends on python3-xarray which is not in testing

[Graham Inggs]

Source: spyder-kernels
Version: 2.4.4-2
Severity: serious
Tags: ftbfs

Hi Maintainer

spyder-kernels has a build-dependency on python3-xarray which is no
longer in testing.

Please drop this build-dependency or help get python3-xarray back into testing.

Regards
Graham

Bug#1052069: ways to proceed?

[Adam Majer]

On 2023-11-10 10:51, Andreas Beckmann wrote:

The module should continue to work on 6.1
The module should continue to work on 6.5 booted with ibt=off
The module should fail to load with an error message describing the 
issue on 6.5 with ibt enabled, but without a kernel BUG.


Did you find some time to test the package patched with my IBT related 
changes?


I've managed to add the patch today and recompile. Complete success and 
works as expected. It no longer crashes when ibt=on.


Initially I've had an idea to automatically set this kernel command line 
boot values when the module is installed, but having this informative 
message is actually better. One nit-pick is that the kernel message is 
not clear as to what module it's talking about.


kernel: NVRM: This module is incompatible with IBT. Try booting with 
ibt=off.


A better message could be,

kernel: NVRM: This Nvidia driver is incompatible with IBT. Try booting 
with ibt=off.


Thanks!
- Adam

Bug#1055840: RM: dhis-client -- RoQA; dead upstream, orphaned

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: dhis-cli...@packages.debian.org
Control: affects -1 + src:dhis-client

Dear ftpmasters,

please remove dhis-client, which is the client component of "DHIS",
supposedly a dynamic DNS update service. Its orphaned in Debian and
unmaintained for a lot longer, and upstream is gone too. The homepage
apparently has been taken over by some other project doing something
similar.

After looking at the server source, I haven't inspected the client code
if it also would seem unwise to run on a network, but I'd suspect so...

Thanks,
Chris

Bug#1055839: RM: dhis-server -- RoQA; dead upstream, orphaned, replacements exists, probably security buggy

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: dhis-ser...@packages.debian.org
Control: affects -1 + src:dhis-server

Dear ftpmasters,

please remove dhis-server, which is the server component of "DHIS",
supposedly a dynamic DNS update service. Its orphaned in Debian and
unmaintained for a lot longer, and upstream is gone too. The homepage
apparently has been taken over by some other project doing something
similar.

A cursory glance at the code suggests that running this code on a
network is not a great idea, security-wise.

I'll file a separate bug about the client code in a moment.

Thanks,
Chris

Bug#1054051: openvpn: Please provide native NetworkManager hook scripts

[Michael Biebl]

Am 11.11.23 um 22:52 schrieb Bernhard Schmidt:


The hook is to start a VPN tunnel after an underlying network interface
comes up, see README.Debian

---
/etc/network/interfaces can be configured to start and stop openvpn when the
underlying network interface is brought up and down. To do so add a line such
as "openvpn vpn1" to the stanza for the underlying network interface, where
"vpn1" is the name of the vpn to start and stop.
---

I don't think this is portable to NetworkManager hooks (IIRC
NetworkManager has another mechanism to start VPN tunnels as early as
possible when a physical connection comes up)


Correct, NM has a builtin mechanism to activate VPN tunnels 
automatically if a certain base connection has become active (see the 
connection.secondaries mechanism documented in man nm-settings).


Thanks for the detailed reply!



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055833: charliecloud: autopkgtest fails in unstable, blocks other packages migration

[Peter Wienemann]

Dear Luca,

On 2023-11-12 13:20:16 +0100, Luca Boccassi wrote:

Source: charliecloud
Version: 0.35-4
Severity: important

charliecloud's autopkgtest is failing in unstable, and it is blocking
iproute2's migration as they are tested together:

https://ci.debian.net/data/autopkgtest/testing/s390x/c/charliecloud/39798421/log.gz


thanks for your bug report. I hope that this issue is fixed by 0.35-5 
which I uploaded shortly before your bug report:


https://tracker.debian.org/news/1477982/accepted-charliecloud-035-5-source-into-unstable/

I will keep this bug open until we know for sure.

Best regards,

Peter

Bug#1055838: gnome: GNOME Text Editor not chosen or listed for text files

[Paul Menzel]

package: gnome
version: 1:44+1
severity: normal


Dear Debian folks,


With Debian sid/unstable and *gnome* 1:44+1, text files, for example 
with the suffix .txt, are opened with LibreOffice Writer and not GNOME 
Text Editor (*gnome-text-editor* 45.0-1). It’s not even listed in the 
application choices. `xdg-open` also opens the text file with 
LibreOffice. In the past, *gedit was used by default, so it’d be great 
if now GNOME Text Editor could do the same.



Kind regards,

Paul

Bug#1039271: mumble: ships sysv-init script without systemd unit

[Chris Hofstaedtler]

Control: reassign -1 mumble-server

Hi,

* bl...@debian.org :
> Package: mumble
> Severity: important
> Usertags: missing-systemd-service
> 
[..]
> mumble has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file. The default init system in
> Debian is systemd, and so far this worked because a transitional
> sysv-init-to-unit generator was shipped by systemd. This is in the
> process of being deprecated and will be removed by the time Trixie
> ships, so the remaining packages that ship init scripts without
> systemd units will stop working.

Upstream actually includes a .service file in the source tree, as
can be seen here: 
https://sources.debian.org/src/mumble/1.3.4-4/scripts/murmur.service/

It seems like installing it with a small patch for the Debian path
derivation should hopefully do the job.

Best,
Chris

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

[Davide Prina]

Package: c-evo-dh-gtk2
Version: 1.9-1
Severity: normal
X-Debbugs-Cc: davide.pr...@null.net

Dear mainteiner,

the directory ~/.config/c-evo-dh/Saved is not created and the game is
unusable.

To solve the problem you must do:

$ mkdir ~/.config/c-evo-dh/Saved

Ciao
Davide


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

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

Versions of packages c-evo-dh-gtk2 depends on:
ii  c-evo-dh-data 1.9-1
ii  c-evo-dh-stdai [c-evo-dh-ai]  1.9-1
ii  ffmpeg7:6.0-9+b1
ii  libatk1.0-0   2.50.0-1
ii  libc6 2.37-12
ii  libcairo2 1.18.0-1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-2
ii  libglib2.0-0  2.78.1-2
ii  libgtk2.0-0   2.24.33-2
ii  libpango-1.0-01.51.0+ds-3
ii  libx11-6  2:1.8.7-1

c-evo-dh-gtk2 recommends no packages.

Versions of packages c-evo-dh-gtk2 suggests:
ii  sensible-utils  0.0.20

-- no debconf information

Bug#1055836: 2048-qt: wish this had support for touch displays

[Russell Coker]

Package: 2048-qt
Version: 0.1.6-2+b1
Severity: normal

To be usable on touch displays this would ideally have support for swipes.

But to get the minimum functionality needed to make the game playable it
would be sufficient to have buttons for up/down/left/right.

Please make this game usable on touch systems.


-- System Information:
Debian Release: trixie/sid
Architecture: arm64 (aarch64)

Kernel: Linux 6.6-rockchip (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages 2048-qt depends on:
ii  libc62.37-12
ii  libgcc-s1 [libgcc1]  13.2.0-6
ii  libqt5core5a 5.15.10+dfsg-4
ii  libqt5qml5   5.15.10+dfsg-2
ii  libqt5widgets5   5.15.10+dfsg-4
ii  libstdc++6   13.2.0-6
ii  qml-module-qtquick-controls  5.15.10-2
ii  qml-module-qtquick-dialogs   5.15.10-2

2048-qt recommends no packages.

2048-qt suggests no packages.

-- debconf-show failed

Bug#1055835: xscreensaver doesn't retain Quick Power-off setting

[Oleg Broytman]

Package: xscreensaver
Version: 6.06+dfsg1-3
Severity: normal

Dear Maintainer,

After upgrade to Debian 12 xscreensaver doesn't retain Quick Power-off
setting. I open the Demo/Settings dialog, open Settings tab, turn on the
checkbox "Quick Power-off in Blank Only Mode", close the dialog with
"Close" button at the bottom, reopen the dialog -- and the checkbox is
off.

I don't know if it's related to bug #1040948.

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

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

Versions of packages xscreensaver depends on:
ii  init-system-helpers1.65.2
ii  libatk1.0-02.46.0-5
ii  libc6  2.36-9+deb12u3
ii  libcrypt1  1:4.4.33-2
ii  libelogind0 [libsystemd0]  246.10-1debian1
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libpam0g   1.5.2-6+deb12u1
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxext6   2:1.3.4-1+b1
ii  libxft22.3.6-1
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxt6 1:1.2.1-1.1
ii  libxxf86vm11:1.1.4-1+b2
ii  xscreensaver-data  6.06+dfsg1-3

Versions of packages xscreensaver recommends:
ii  fonts-urw-base35  20200910-7
ii  libjpeg-turbo-progs   1:2.1.5-2
ii  perl  5.36.0-7
ii  wamerican [wordlist]  2020.12.07-2
ii  xfonts-100dpi 1:1.0.5

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]   119.0.6045.123-1~deb12u1
ii  elinks [www-browser] 0.13.2-1+b4
pn  fortune  
pn  gdm3 | kdm-gdmcompat 
ii  links2 [www-browser] 2.28-1+b2
pn  qcam | streamer  
ii  xdaliclock   2.46-1
ii  xfishtank2.5-1+b1
ii  xscreensaver-data-extra  6.06+dfsg1-3
ii  xscreensaver-gl  6.06+dfsg1-3
ii  xscreensaver-gl-extra6.06+dfsg1-3

-- debconf-show failed

Bug#1055834: 2048-qt: doesn't scale to lower resolution displays

[Russell Coker]

Package: 2048-qt
Version: 0.1.6-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: russ...@coker.com.au

When this is run on a PinePhonePro with 720*1440 display the window doesn't
show all the details (it barely shows the 16 cells).

I believe that the correct operation on such hardware is to scale the screen
down to show everything in that size.


-- System Information:
Debian Release: trixie/sid
Architecture: arm64 (aarch64)

Kernel: Linux 6.6-rockchip (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages 2048-qt depends on:
ii  libc62.37-12
ii  libgcc-s1 [libgcc1]  13.2.0-6
ii  libqt5core5a 5.15.10+dfsg-4
ii  libqt5qml5   5.15.10+dfsg-2
ii  libqt5widgets5   5.15.10+dfsg-4
ii  libstdc++6   13.2.0-6
ii  qml-module-qtquick-controls  5.15.10-2
ii  qml-module-qtquick-dialogs   5.15.10-2

2048-qt recommends no packages.

2048-qt suggests no packages.

-- debconf-show failed

Bug#946102: ghc: Please add unregisterised binary package

[Ilias Tsitsimpis]

Control: tags -1 wontfix
Control: notfound -1 8.8.1+dfsg2-1~exp1

Hi Asher,

On Tue, Dec 03, 2019 at 03:36PM, Asher Gordon wrote:
> The GHC packaged with Debian is registerised (or "not unregisterised"?),
> meaning that it cannot compile to C code (with the -C option). While
> being unregisterised is usually good (generates faster code), it is
> sometimes useful to generate C code. For example, to examine how Haskell
> programs work if you know C but are learning Haskell (my situation) or
> if you just want to understand Haskell better. It could also be useful
> for cross compilation and maybe other things too.

We don't really have a use for unregisterised GHC in Debian, to justify
the effort. If you need an unregisterised GHC, I believe the easiest way
to get one is to build your own, by modifying the Debian package and
passing '--enable-unregisterised' during configuration.

Best,

-- 
Ilias

Bug#1055833: charliecloud: autopkgtest fails in unstable, blocks other packages migration

[Luca Boccassi]

Source: charliecloud
Version: 0.35-4
Severity: important

charliecloud's autopkgtest is failing in unstable, and it is blocking
iproute2's migration as they are tested together:

https://ci.debian.net/data/autopkgtest/testing/s390x/c/charliecloud/39798421/log.gz

-- 
Kind regards,
Luca Boccassi


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

Bug#1042572: claws-mail: can't update claws-mail to v4.1.1 from bullseye-backports

[Andreas Rönnquist]

On Sun, 30 Jul 2023 15:41:15 +0100 no2spam  wrote:
> Package: claws-mail
> Version: 4.1.1-2~bpo11+1
> Severity: important
> 
> Dear Maintainer,
> 
> I'm using claws-mail on Debian Bullseye. Update fails because of a
> plugin version mismatch in bullseye-backports repository:
> 
>  * claws-mail-bsfilter-plugin is still on version 4.1.0-2~bpo11+1
>  * claws-mail-pgpcore is missing (dependency of claws-mail-pgpinline
>package)
> 
> Could you upload claws-mail-bsfilter-plugin (v4.1.1 amd64) to the
> bullseye-backports repository? That should fix it.
> 
> Thanks
> 
> 
> 

Finally the package has left the NEW queue - now you can install it,
but please notice that you'll need to install it from
bullseye-backports-sloppy. (Please see "The Old-stable-sloppy Suite" on
https://backports.debian.org/Instructions/#index4h2 )

-- Andreas Rönnquist
gus...@debian.org

Bug#989844: [Pkg-rust-maintainers] Bug#989844: Cross-compilation support (please package more libstd-rust-dev-*)

[chrysn]

> but without std, the topic of this bug.

I don't think that no-std targtets are off topic for this bug. Rust's
terminologiy is a bit weird in that "std" sometimes means the "std"
crate (which is the thing that does POSIX-style operations), but also
sometimes means std+alloc+core (for example in -Zbuild-std=core, which
replaces any shipped core with one freshly built -- something one might
use instead of having those packaged, except that it will stay a nightly
feature for the forseeable future).

Thus, it can be argued that even the built libraries would be
appropriately named as libstd-rust-dev-thumbv7em-none-eabihf etc -- and
even if not (going for libcore-rust-dev-thumbv7em-none-eabihf), the
implementation similarities to other platforms without host tools
probably warrant lumping them together.


signature.asc
Description: PGP signature

Bug#1008017: audiofile: CVE-2022-24599/CVE-2019-13147 Fix

[Bastien Roucariès]

Le samedi 11 novembre 2023, 18:22:41 UTC Bastien Roucariès a écrit :
> control: tags -1 + patch
> 
> Hi,
> 
> Could you apply the merge request 
> https://salsa.debian.org/multimedia-team/audiofile/-/merge_requests/5 and 
> made a release ?
> 
> It fix the two CVE
> 
> Bastien
Send fix to DELAYED/7

Thanks

Bastien


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

Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2

[Ben Finney]

On 12-Nov-2023, Sandro Tosi wrote:

> > The inconsistent constraints need to be resolved;
> 
> no they dont. debian uses apt not pip to install packages.

The ‘pip’ command-line tool can also query which packages Python knows are
installed, and that uses the database derived from Python package metadata.

So, the Python metadata installed by the Debian package needs to be
consistent with the dependencies.

> from a packaging perspective, what matter is "does rich work?" and since
> the answer is "yes"

In the aspect of Python giving the correct answer from a query using ‘pip’,
it isn't working. This is because the query is not of the Debian package
database, but the Python metadata.

This can be resolved by making the Debian dependencies and the Python
metadata declared dependencies, consistent.

Please address this so that the Python standard ‘pip’ tool can get the
correct information from the Python metadata installed by these Debian
packages.

-- 
 \ “Science is a way of trying not to fool yourself. The first |
  `\ principle is that you must not fool yourself, and you are the |
_o__)   easiest person to fool.” —Richard P. Feynman, 1964 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1050656: libqt5gui5: This was local to my system only

[Shai Berger]

Package: libqt5gui5
Followup-For: Bug #1050656

Dear Maintainer,

Looking again at some tracebacks and coredumps, I realized the
problem was really with libjpeg62-turbo -- but that didn't make
sense to me, as that library hasn't changed in a long time.

Except, apparently, on my system, it has.

Reinstalling it solved the problem.

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

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

Versions of packages libqt5gui5 depends on:
ii  fontconfig 2.14.2-6
ii  libc6  2.37-12
ii  libdrm22.4.117-1
ii  libegl11.7.0-1
ii  libfontconfig1 2.14.2-6
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.2.1-1
ii  libgcc-s1  13.2.0-5
ii  libgl1 1.7.0-1
ii  libglib2.0-0   2.78.1-2
ii  libharfbuzz0b  8.0.1-1
ii  libice62:1.0.10-1
ii  libinput10 1.23.0-2
ii  libjpeg62-turbo1:2.1.5-2
ii  libmd4c0   0.4.8-1
ii  libmtdev1  1.1.6-1
ii  libpng16-161.6.40-2
ii  libqt5core5a [qtbase-abi-5-15-10]  5.15.10+dfsg-4
ii  libqt5dbus55.15.10+dfsg-4
ii  libqt5network5 5.15.10+dfsg-4
ii  libsm6 2:1.2.3-1
ii  libstdc++6 13.2.0-5
ii  libudev1   254.5-1
ii  libx11-6   2:1.8.7-1
ii  libx11-xcb12:1.8.7-1
ii  libxcb-glx01.15-1
ii  libxcb-icccm4  0.4.1-1.1
ii  libxcb-image0  0.4.0-2
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.15-1
ii  libxcb-render-util00.3.9-1+b1
ii  libxcb-render0 1.15-1
ii  libxcb-shape0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-sync1   1.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb-xinput0 1.15-1
ii  libxcb-xkb11.15-1
ii  libxcb11.15-1
ii  libxkbcommon-x11-0 1.6.0-1
ii  libxkbcommon0  1.6.0-1
ii  libxrender11:0.9.10-1.1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5 5.15.10-2
ii  qt5-gtk-platformtheme  5.15.10+dfsg-4
ii  qtwayland5 5.15.10-2

Versions of packages libqt5gui5 suggests:
pn  qgnomeplatform-qt5 
ii  qt5-image-formats-plugins  5.15.10-2

-- no debconf information

Bug#1055567: Error: gscan2pdf fails to compile

[Soumyanath Chatterjee]

Tried running it  but no log file is generated. Here is the console output:

soumyanath@ganak-desktop:~$ gscan2pdf --log=log
Bareword "SANE_NAME_SCAN_TL_X" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 128.
Bareword "SANE_NAME_SCAN_TL_Y" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 143.
Bareword "SANE_NAME_SCAN_TL_Y" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 145.
Bareword "SANE_NAME_SCAN_BR_Y" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 146.
Bareword "SANE_NAME_SCAN_BR_Y" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 149.
Bareword "SANE_NAME_SCAN_TL_X" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 130.
Bareword "SANE_NAME_SCAN_BR_X" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 131.
Bareword "SANE_NAME_SCAN_BR_X" not allowed while "strict subs" in use at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 134.
Bareword "SANE_NAME_PAGE_HEIGHT" not allowed while "strict subs" in use 
at /usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 116.
Bareword "SANE_NAME_PAGE_WIDTH" not allowed while "strict subs" in use 
at /usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 122.
Compilation failed in require at /usr/share/perl5/Gscan2pdf/Document.pm 
line 12.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Document.pm line 12.
Compilation failed in require at 
/usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7.

Compilation failed in require at /usr/bin/gscan2pdf line 61.
BEGIN failed--compilation aborted at /usr/bin/gscan2pdf line 61.


Regards

Soumyanath Chatterjee /  FIE, FIIE/
Prod. Dev & SCM coach
Former TVS Motors Chair Professor, IIT Kharagpur, INDIA


*URL:* http://www.soumyanath.in *Ph:* +91 33 46004248(R)    +91 98318 
04223(M) *ORCiD:* -0003-4411-0669 






On 12/11/23 15:16, Jeff wrote:

gscan2pdf --log=log 

Bug#1055832: goplay: uninformative errors about Xapian

[Russell Coker]

Package: goplay
Version: 0.9.1+nmu1+b2
Severity: normal

$ goplay
Xapian DatabaseOpeningError: Couldn't stat '/var/cache/apt-xapian-index/index.1'

When I run goplay and the Xapian database is not available I get the above
error which isn't very helpful.  I think that an error about this should have
a mention of the apt-xapian-index package to point the user in the right
direction towards solving it.

Also why do we suddenly need this?  It used to run without the xapian
database, why can't it do so now?

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

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

Versions of packages goplay depends on:
ii  apt-xapian-index 0.53
ii  debtags  2.1.5
ii  libapt-pkg5.01.8.2.2
ii  libc62.37-12
ii  libcurl3-gnutls  8.4.0-2
ii  libept1.5.0  1.1+nmu3+b1
ii  libfltk-images1.31.3.8-5
ii  libfltk1.3   1.3.8-5
ii  libgcc-s1 [libgcc1]  13.2.0-6
ii  libstdc++6   13.2.0-6
ii  libx11-6 2:1.8.7-1
ii  libxapian30  1.4.22-1
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages goplay recommends:
pn  games-thumbnails  

goplay suggests no packages.

-- debconf-show failed

Bug#956095: ghc panics when building ghc-lib-parser on armhf (raspberry)

[Ilias Tsitsimpis]

Control: tags -1 moreinfo

Hi!

On Tue, Apr 07, 2020 at 11:22AM, Andrew Maier wrote:
>I get the following output:
> 
> 
>2020-04-07 00:04:35.509894: [info] ghc-lib-parser> [143 of 205] Compiling 
> PatSyn
>2020-04-07 00:04:39.625117: [info] ghc-lib-parser> [144 of 205] Compiling 
> Literal
>2020-04-07 00:05:11.953843: [info] ghc-lib-parser> [145 of 205] Compiling 
> TrieMap
>2020-04-07 00:05:16.701428: [info] ghc-lib-parser> [146 of 205] Compiling 
> HsLit
>2020-04-07 00:05:17.243414: [warn] ghc-lib-parser> ghc: panic! (the 
> 'impossible' happened)
>2020-04-07 00:05:17.243723: [warn] ghc-lib-parser>   (GHC version 8.6.5 
> for arm-unknown-linux):
>2020-04-07 00:05:17.243985: [warn] ghc-lib-parser>  idInfo 2020-04-07 
> 00:05:17.244208: [warn] ghc-lib-parser>   p_a1om
>2020-04-07 00:05:17.244405: [warn] ghc-lib-parser>   Call stack: 
> 2020-04-07 00:05:17.244607: [warn] ghc-lib-parser>   CallStack
>(from HasCallStack): 2020-04-07 00:05:17.244827: [warn] ghc-lib-parser> 
> callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
>2020-04-07 00:05:17.245074: [warn] ghc-lib-parser> pprPanic, 
> called at compiler/basicTypes/Var.hs:541:34 in ghc:Var
>2020-04-07 00:05:17.245449: [warn] ghc-lib-parser> 
>2020-04-07 00:05:17.245914: [warn] ghc-lib-parser> Please report this as a 
> GHC bug:  http://www.haskell.org/ghc/reportabug
>2020-04-07 00:05:17.246348: [warn] ghc-lib-parser> 
>2020-04-07 00:05:18.101968: [error] 
>--  While building package ghc-lib-parser-8.8.0.20190424 using:
>  
> /home/andrew/.stack/setup-exe-cache/arm-linux/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5
>  --builddir=.stack-work/dist/arm-linux/Cabal-2.4.0.1 build
>  --ghc-options " -fdiagnostics-color=always"
>  Process exited with code: ExitFailure 1

Can you please try with the latest version of GHC available in unstable 
(9.4.7-1)?
The Debian package for ghc-lib-parser builds fine on armhf (see
https://buildd.debian.org/status/package.php?p=haskell-ghc-lib-parser=sid),
so I believe this bug has been resolved.

Thanks,

-- 
Ilias

Bug#864846: ghc: on armhf should have load address of at least 0x10000

[Ilias Tsitsimpis]

Control: tags -1 moreinfo

Hi!

On Thu, Jun 15, 2017 at 10:32PM, Edmund Grimley Evans wrote:
> If I try to run "ghc" in one of my armhf chroots, it does not work very well:
> 
> $ ghc
> Segmentation fault

Can you please try with the latest version of GHC available in unstable 
(9.4.7-1)?

Thanks,

-- 
Ilias

Bug#1055830: systemd in a container fails to set up mount namespacing

[Christian Horn]

Package: systemd
Version: 252.17-1~deb12u1
Severity: important

Dear Maintainer,

* What led up to the situation?

Fedora39 running as host, Debian Bookworm container is started via podman.
Packages systemd and redis get installed in the container, then trying to
start redis via 'systemctl start redis fails'.
'journalctl -xeu redis-server.service' says:
(s-server)[66]: Failed to mount /run/systemd/inaccessible/reg to 
/run/systemd/unit-root/proc/kallsyms: Permission denied
(s-server)[66]: redis-server.service: Failed to set up mount namespacing: 
/run/systemd/unit-root/proc/kallsyms: Permission denied
(s-server)[66]: redis-server.service: Failed at step NAMESPACE spawning 
/usr/bin/redis-server: Permission denied

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

Using a Debian trixie container, the issue does not appear.
I see this on both amd64 and aarch64 architecture.
I think everybody trying to run redis in a Bookworm 
container will hit this issue.

* Reproducer
To be executed on a Fedora39 system, as user:
```
sudo dnf -y install podman
mkdir -p ~/repro/build-bookworm
cat >~/repro/build-bookworm/Containerfile<
pn  libtss2-esys-3.0.2-0   
pn  libtss2-mu0
pn  libtss2-rc0
pn  polkitd | policykit-1  
pn  systemd-boot   
pn  systemd-container  
pn  systemd-homed  
pn  systemd-resolved   
pn  systemd-userdbd

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

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/system.conf changed [not included]

-- no debconf information

Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector

[Tobias Frost]

Control: tags -1 moreinfo

Hi Jan,

Thanks for your RFS!
as you are listed as upstream contact, let me, as I always do, point you to
https://wiki.debian.org/UpstreamGuide

As this is your first package your are maintaining, please also read
https://mentors.debian.net/intro-maintainers/

This part of the CONTRIBUTING.md concerns me:
  We are sorry, but at the moment, we do not accept external contributions until
  wehave established a contribution process. We're working behind the scenes to
  get this ready in the future. Until then, we would kindly ask you to not open 
pull
  requests.

This stanca is older than a year (Aug 2022), so when will this happen?

Sorry to be blunt, but putting a DFSG license on a piece of software and
then saying we do not accept contributions, is (IMHO) not within the
spirit of the Open Source Community, even if it might on paper fullfil
the DFSG.

This is also problematic for maintaining the package, as how should we,
as Debian, upstream patches, for example if you are go missing for
whatever reasons? Effectively, we would need to maintain a fork, and
that is certainly nothing Vector could want.

I'd say this brings the RFS very close to the "wontfix" territory,
certainly I will not sponsor this upload, but other sponsors might.
(The review below is partial, done until I saw the README.)

In Debian we do not package every software. So maybe I'll need a salse
pitch here:
- Why does Vector want it in the Debian archives?
- Why would Debian want it to be in the Debian archives?
- Are there other projects using the library that you intend to package
  for Debian?

On Mon, Nov 06, 2023 at 12:57:23PM +, 
=?UTF-8?Q?Kr=C3=a4...@buxtehude.debian.org wrote:
 
>  * Package name   : libsilkit 
>     Version    : 4.0.37-1 
>     Upstream contact : jan.krae...@vector.com 
>  * URL    : https://github.com/vectorgrp/sil-kit 
>  * License   : MIT 
>  * Vcs  : https://github.com/vectorgrp/sil-kit
>    Section    : libs 
> 
> The source builds the following binary packages: 
> 
>   libsilkit-dev - Development packages for libsilkit 
>   libsilkit4 - Simulation in the loop kit by Vector 
> 
> To access further information about this package, please visit the following 
> URL: 
> 
>   https://mentors.debian.net/package/libsilkit/ 
> 
> Alternatively, you can download the package with 'dget' using this command: 
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/libs/libsilkit/libsilkit_4.0.37-1.dsc
>  
> 
> Changes for the initial release: 
>  libsilkit (4.0.37-1) unstable; urgency=medium 
>  . 
>    * Reworked the documentation on Virtual Time Synchronization 
>    * The documentation of the demo section now refers to the pre built Vector 
>  SIL Kit packages and not to a source build. 
> 
> An ITP bug for the wnpp package can be found here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055064

Here's a short review on your package: As the build fails, it is likely
to be incomplete.

- d/changelog: An initial upload has no changes, so it would just say
  "Initial upload. Closes: #your-itp-bug."
  
  (As there is a lots of history in d/changelog: This file is not the
  upstream changelog, is about recording changes to the packaging.)

  However, as said, your only entry for the initial upload is as I
  described above, delete the rest.

- d/control:
  - cmake >= 3.20 is aready fulfiled in stable, you can drop the
 versioned part.
  - you have a -dev package and a library package - good!
However, I see that you are installing a systemd service file, that
means you also need a non-library binary package so that multi-arch
will work. (something like a -tools package

- manpage: It says it is autogenerated, so you need to generate it
  during build. As you are upstream, include the manpages upstream, so
  other distributions will benefit too.

- src/ThirdPArty (most of the directories are empty, possibly this is
  the reason for the FTBFS)
  You cannot vendor libraries in Debian, you must use packaged versions.
  If it is not packaged, you have to package it.

- It FTBFS in a clean pbuilder enviornment. (asio not found) Likely
  missing dependencies Checkout sbuilder or pbuilder to make sure to
  build in a clean enviornment.

- d/copyright claims that *EVERY* file is Copyright: 2023 Vector Informatik GmbH
  despite ThirdParty/LICENSES.rst is contradicting it.
  The year is not correct either, I saw at least one file with the year
  2022. 
  Please review every file and record the copyright information
  appropiatly. 
  I did not do a complete copyright review.

- There is no watchfile

- d/control VCS-* needs to point where the *packaging* resides,
  not to the upstream repo. see Policy for details.
  (Due to CONTRIBUTING.md any other location than salsa.d.o is
  IMHO inacceptable.) 

- Stopping here after seeing CONTRIBUTING.md.

-- 
Cheers from Regensburg,

Bug#1055064: ITP: libsilkit4 -- library for connecting software-in-the-loop environments

[Tobias Frost]

Package: wnpp
Followup-For: Bug #1055064

Hi Jan,

(recycling parts of the answer to the RFS, as this is relevant here
too:)

This part of the CONTRIBUTING.md concerns me:
  We are sorry, but at the moment, we do not accept external contributions until
  wehave established a contribution process. We're working behind the scenes to
  get this ready in the future. Until then, we would kindly ask you to not open 
pull
  requests.

This stanca is older than a year (Aug 2022), so when will this happen?

Sorry to be blunt, but putting a DFSG license on a piece of software and
then saying we do not accept contributions, is IMHO not within the
spirit of the Open Source Community, even if it might on paper fullfil
the DFSG.

This is also problematic for maintaining the package, as how should we,
as Debian, upstream patches, for example if you are go missing for
whatever reasons? Effectively, everyone with a need for changes  would
need to maintain a fork, and that is certainly nothing Vector could
want.

In Debian we do not package every software. So maybe I'll need a salse
pitch here:
- Why does Vector want it in the Debian archives?
- Why would Debian want it to be in the Debian archives?
- Are there other projects using the library that you intend to package
  for Debian?

-- 
tobi

Bug#1055516: python3-jsonschema: New upstream version available

[Antonio Valentino]

Hi,

On Tue, 07 Nov 2023 18:27:49 +0100 Roland Mas  wrote:

Package: python3-jsonschema
Version: 4.10.3-1
Severity: wishlist

Dear Maintainer,

There's a new upstream version (4.19) available, with at least one
change in API (in the Draft*Validator constructors); jupyter-events, a
package I'm working on, uses the new API, and therefore fails to run
with the current 4.10 version.

Could you provide an updated package?

Thanks,

Roland.



I'm also interested in having and updated version of jsonschema to 
Support validation in pystack.


Please not that the "referencing" package, a dependency on new 
jsonschema versions, is now available in Debian:


https://tracker.debian.org/pkg/referencing


kind regards
--
Antonio Valentino

Bug#1055829: ITP: nanobind -- Tiny and efficient C++/Python bindings

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: nanobind
  Version : 1.8.0
  Upstream Author : Wenzel Jakob 
* URL : https://github.com/wjakob/nanobind
* License : BSD-3-clause
  Programming Lang: Python, C++
  Description : Tiny and efficient C++/Python bindings

nanobind is a small binding library that exposes C++ types in Python and vice
versa. It is reminiscent of Boost.Python and pybind11 and uses near-identical
syntax. In contrast to these existing tools, nanobind is more efficient:
bindings compile in a shorter amount of time, produce smaller binaries, and
have better runtime performance.

The package will be team-maintained under the umbrella of the
Debian Python Team 
at https://salsa.debian.org/python-team/packages/nanobind


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVQpFMACgkQ+C8H+466
LVk6/wwAtd3RjzQiYoBeO2WwquWnQWwrNTJj2/IXs+J1GO1u3yoSJjm1fTTNmyGi
iYU5zFcMuUizZ2gEChOHUQ+50xcAtTBUAIMYPgDRD6D+vZrtcFTAGk5DbotCZ8i+
+ER+jCdBMJa3et+Cpz2ryhgqM9ZyFRRkNQfya26aOBiacCsR3B0XxBjOg6eiXlQ3
J/hbi2le+7ukp84cwphWVchqXgeEEkyc5IFfBm3P2sTLIr2K8WazcRhOvnc7NczL
zdIldu1k8lQ82GyTsUIyBLBbt7yjZeg+8xvj5ww2IWi1kWxIJZI6S4ac8LT03lfV
ezpmoNNY0REsvT2ASa03RO+C9wIxCLZ4rnkK/R2CvOXLb0COszfRVowxXsY3tIMm
qcq8yz4z4elHGeFkKjeCq7+Ype5F2NLXQ3hHP44DKBzrECdrPC45KNXzX5zigdnU
9Vi2YDdWR8ZWm3M3NF1FMz/XNwIKdPjPLaKuXsh7jFfxeirhbRDQrQ2moSrDMuYW
H1boyhwy
=tka6
-END PGP SIGNATURE-

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

Please start gscan2pdf from the command line with the --log option:

gscan2pdf --log=log

then quit, and post the log file, which gscan2pdf should have compressed 
with xz.




OpenPGP_signature.asc
Description: OpenPGP digital signature