Bug#1053672: Apple copyright notices in test .xlsx files

[Paul Wise]

On Sun, 2023-10-08 at 15:04 +0100, Rebecca N. Palmer wrote:

> Given this, why is that copyright notice there, and what does it imply 
> that we should do?  (E.g. does Apple Numbers automatically copy 
> Apple-owned items (e.g. fonts) into files it creates?  If so, is there a 
> way to remove these items to get a Free file?)

*.xlsx files are actually just *.zip files containing XML and other
files. The Apple copyright for both of the files you mention comes from
the Apple copyright listed for the ICC profile embedded in the EXIF
data in the JPEG file that was saved as a thumbnail of the spreadsheet.

I am not sure what that means for the license of the test cases in
openpyxl and but it would be easy to fix by either deleting the
thumbnail, or removing the ICC profile, but that would alter the test
cases, probably that wouldn't affect the tests passing/failing though.

$ unzip conditional-formatting.xlsx 
Archive:  conditional-formatting.xlsx
  inflating: [Content_Types].xml 
  inflating: _rels/.rels 
  inflating: xl/_rels/workbook.xml.rels  
  inflating: xl/workbook.xml 
 extracting: docProps/thumbnail.jpeg  
  inflating: xl/theme/theme1.xml 
  inflating: xl/styles.xml   
  inflating: xl/worksheets/sheet1.xml  
  inflating: docProps/core.xml   
  inflating: docProps/app.xml

$ grep -ri apple
grep: conditional-formatting.xlsx: binary file matches
grep: docProps/thumbnail.jpeg: binary file matches

$ exiftool docProps/thumbnail.jpeg | grep -i apple
Profile CMM Type: Apple Computer Inc.
Primary Platform: Apple Computer Inc.
Device Manufacturer : Apple Computer Inc.
Profile Creator : Apple Computer Inc.
Profile Copyright   : Copyright 2007 Apple Inc., all rights 
reserved.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1053485: [debian-mysql] Bug#1053485: mariadb: FTBFS on sparc64: Post-build test suite fails on main.ctype_binary main.ctype_latin1

[Otto Kekäläinen]

I disabled these tests in
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/f3b99c24d2577b35530e6106cb527cc94cb1e061
and thus these failures are no longer visible in the 1:10.11.5-2
upload.

However several other tests now crashed: main.partition_order
main.func_str main.func_like main.func_math main.group_by
main.group_by_null main.features main.type_datetime main.xml

See detailed stack traces in
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A10.11.5-2=1696744591=0

Bug#1053486: [debian-mysql] Bug#1053486: mariadb: FTBFS on ppc64: Post-build test suite fails on main.mysql_upgrade

[Otto Kekäläinen]

I added main.mysql_upgrade to the skiplist for ppc64, thus the build
of 1:10.11.5-2 did not fail on it. That build did however fail on
Bug#1052838 and on sporadic crash/corruption in
main.xa_prepared_binlog_off.

Bug#1052838: [debian-mysql] Bug#1052838: Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1

[Otto Kekäläinen]

I saw this now after 1:10.11.5-2 upload on multiple builders.

Snippets from logs
https://buildd.debian.org/status/fetch.php?pkg=mariadb=powerpc=1%3A10.11.5-2=1696735216=0

main.failed_auth_unixsocket  w13 [ fail ]
Test ended at 2023-10-08 03:17:49
CURRENT_TEST: main.failed_auth_unixsocket
Failed to start mysqld.1
mysqltest failed but provided no output
 - saving 
'/<>/builddir/mysql-test/var/13/log/main.failed_auth_unixsocket/'
to '/<>/builddir/mysql-test/var/log/main.failed_auth_unixsocket/'
Retrying test main.failed_auth_unixsocket, attempt(2/3)...
worker[13] > Restart  - not started
***Warnings generated in error logs during shutdown after running
tests: main.failed_auth_unixsocket
2023-10-08  3:17:49 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:17:49 0 [ERROR] Do you already have another server
running on port: 16120 ?
2023-10-08  3:17:49 0 [ERROR] Aborting

main.password_expiration_unix_socket w13 [ fail ]
Test ended at 2023-10-08 03:18:16
CURRENT_TEST: main.password_expiration_unix_socket
Failed to start mysqld.1
mysqltest failed but provided no output
 - skipping 
'/<>/builddir/mysql-test/var/13/log/main.password_expiration_unix_socket/'
Retrying test main.password_expiration_unix_socket, attempt(2/3)...
main.order_byw14 [ pass ]   3306
worker[13] > Restart  - not started
***Warnings generated in error logs during shutdown after running
tests: main.password_expiration_unix_socket
2023-10-08  3:18:16 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:18:16 0 [ERROR] Do you already have another server
running on port: 16120 ?
2023-10-08  3:18:16 0 [ERROR] Aborting

main.ssl_cipher  w15 [ fail ]main.ssl_cipher
   w15 [ fail ]
...
2023-10-08  3:18:22 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:18:22 0 [ERROR] Do you already have another server
running on port: 16140 ?

main.func_intw13 [ fail ]main.func_int
   w13 [ fail ]
...
2023-10-08  3:18:42 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:18:42 0 [ERROR] Do you already have another server
running on port: 16120 ?

main.plugin_loaderr  w6 [ fail ]
...
2023-10-08  3:18:59 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:18:59 0 [ERROR] Do you already have another server
running on port: 16100 ?

etc

Failing test(s): main.failed_auth_unixsocket
main.password_expiration_unix_socket main.ssl_cipher main.func_int
main.grant_4332 main.plugin_loaderr main.func_isnull
main.grant_binlog_replay main.func_json main.grant_cache_no_prot



https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64=1%3A10.11.5-2=1696735349=0

main.connect w3 [ fail ]
Test ended at 2023-10-08 03:17:18
CURRENT_TEST: main.connect
Failed to start mysqld.1
mysqltest failed but provided no output
 - saving '/<>/builddir/mysql-test/var/3/log/main.connect/'
to '/<>/builddir/mysql-test/var/log/main.connect/'
Retrying test main.connect, attempt(2/3)...
worker[3] > Restart  - not started
***Warnings generated in error logs during shutdown after running
tests: main.connect
2023-10-08  3:17:18 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:17:18 0 [ERROR] Do you already have another server
running on port: 16140 ?
2023-10-08  3:17:18 0 [ERROR] Aborting

main.innodb_load_xa  w5 [ fail ]
..
2023-10-08  3:17:33 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:17:33 0 [ERROR] Do you already have another server
running on port: 16120 ?

main.flush_block_commit_notembedded 'innodb' w3 [ fail ]
...
2023-10-08  3:17:45 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:17:45 0 [ERROR] Do you already have another server
running on port: 16140 ?

main.long_unique_innodb 'innodb' w9 [ fail ]
...
2023-10-08  3:19:29 0 [ERROR] Can't start server: Bind on TCP/IP port.
Got error: 98: Address already in use
2023-10-08  3:19:29 0 [ERROR] Do you already have another server
running on port: 16260 ?

Both builds above ran on builder 'blaauw' with kernel Linux
6.5.0-1-powerpc64 #1 SMP Debian 6.5.3-1 (2023-09-13) ppc64 (ppc64)

I have not been able to reproduce this on any Salsa-CI builders or on Launchpad.

Bug#1053697: ITP: rsgain -- ReplayGain 2.0 loudness normalizer

[Hugh McMaster]

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

* Package name: rsgain
  Version : 3.4
  Upstream Contact: complexlogic
* URL : https://github.com/complexlogic/rsgain
* License : BSD-2-Clause, BSD-3-Clause
  Programming Lang: C++
  Description : ReplayGain 2.0 loudness normalizer

rsgain (really simple gain) is a loudness normalizer that scans digital
audio streams and calculates loudness-normalized gain and loudness peak
values according to the EBU R128/ITU-R BS.1770 standard (-18 LUFS).

rsgain applies ReplayGain 2.0 loudness metadata tags to audio and video files
but does not modify the audio stream.

rsgain supports the AIFF, FLAC, APE, MP2, MP3, M4A, Musepack, Ogg, Opus, TAK,
WAV, WavPack and WMA audio formats. Video files with compatible audio streams
are also supported.

rsgain comes with several scan presets based on the default, EBU R128 and
legacy 'loudgain' scan settings.

Bug#1053654: ITP: erc -- powerful, modular, and extensible IRC client for Emacs

[Amin Bandali]

X-Debbugs-CC: Tobias Frost , David Bremner 

Dear Tobi,

This is now ready for review and hopefully upload through NEW. :-)

https://mentors.debian.net/package/erc/
https://salsa.debian.org/emacsen-team/erc

Thanks in advance,
-a

P.S.  I checked with David about (re)using the existing 'erc' source
  package name for my packaging, especially considering it's been
  unused and not part of any releases for years.

Bug#953591: bash: colors should be enabled by default (force_color_prompt)

[Kevin Otte]

I wrote a patch to address #1026379 that I feel would be appropriate 
here too. As I noted there, using tput for detection basically means 
having ncurses-bin as a Recommends, so we may want a better way of doing 
this detection.
--- /etc/skel/.bashrc	2020-02-25 06:44:22.0 -0500
+++ .bashrc	2023-09-08 09:51:44.086826241 -0400
@@ -35,33 +35,23 @@
 debian_chroot=$(cat /etc/debian_chroot)
 fi
 
-# set a fancy prompt (non-color, unless we know we "want" color)
-case "$TERM" in
-xterm-color|*-256color) color_prompt=yes;;
-esac
-
-# uncomment for a colored prompt, if the terminal has the capability; turned
-# off by default to not distract the user: the focus in a terminal window
-# should be on the output of commands, not on the prompt
-#force_color_prompt=yes
-
-if [ -n "$force_color_prompt" ]; then
-if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
-	# We have color support; assume it's compliant with Ecma-48
-	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
-	# a case would tend to support setf rather than setaf.)
-	color_prompt=yes
-else
-	color_prompt=
-fi
+# Determine if terminal is color capable
+if [ -x /usr/bin/tput ] && [ $(tput colors) -ge 8 ];
+then
+color_prompt=yes
+else
+color_prompt=
 fi
 
+# Uncomment to force plain prompt
+#color_prompt=no
+
 if [ "$color_prompt" = yes ]; then
 PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
 else
 PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
 fi
-unset color_prompt force_color_prompt
+unset color_prompt
 
 # If this is an xterm set the title to user@host:dir
 case "$TERM" in

Bug#1053696: Upgrading Python packages showed numerous ancient changelog entries

[Jonathan Kamens]

You don't have to look into it anymore, I know what's happening. ;-)

Been working on it for a couple of hours. Will have an update in the 
morning, no time to write it up now.


Thanks for the report!

jik

On 10/8/23 22:23, Russ Allbery wrote:

Package: apt-listchanges
Version: 4.0
Followup-For: Bug #1053696
X-Debbugs-Cc:r...@debian.org

Same thing happened with the following upgrades:

Unpacking gcc-12 (12.3.0-10) over (12.3.0-9) ...
Unpacking libgcc-12-dev:amd64 (12.3.0-10) over (12.3.0-9) ...
Unpacking cpp-12 (12.3.0-10) over (12.3.0-9) ...
Unpacking gcc-12-base:amd64 (12.3.0-10) over (12.3.0-9) ...

apt-listchanges displayed what I think is the entire gcc changelog,
including the entries for 12.3.0-9 which were already installed.

It's not happening with every package, though. I'm not sure yet what the
common pattern is, unless it's packages that have multiple package names
in their changelog.

-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
email_address=none
confirm=0
save_seen=/var/lib/apt/listchanges
which=both
no_network=false
headers=false
reverse=false


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

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

Versions of packages apt-listchanges depends on:
ii  apt2.7.6
ii  debconf [debconf-2.0]  1.5.82
ii  python33.11.4-5+b1
ii  python3-apt2.6.0
ii  python3-debconf1.5.82
ii  sensible-utils 0.0.20
ii  ucf3.0043+nmu1

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  chromium [www-browser]  117.0.5938.149-1
ii  firefox [www-browser]   118.0-1+b1
ii  google-chrome-stable [www-browser]  117.0.5938.149-1
ii  links [www-browser] 2.29-1+b1
ii  lynx [www-browser]  2.9.0dev.12-1
ii  postfix [mail-transport-agent]  3.8.2-1
ii  python3-gi  3.46.0-1
ii  w3m [www-browser]   0.5.3+git20230121-2
ii  xterm [x-terminal-emulator] 385-1

-- debconf information:
* apt-listchanges/confirm: false
* apt-listchanges/headers: false
* apt-listchanges/which: both
* apt-listchanges/email-address:
* apt-listchanges/reverse: false
* apt-listchanges/save-seen: true
* apt-listchanges/frontend: pager
* apt-listchanges/no-network: false
   apt-listchanges/email-format: text

Bug#1053696: Upgrading Python packages showed numerous ancient changelog entries

[Russ Allbery]

Package: apt-listchanges
Version: 4.0
Followup-For: Bug #1053696
X-Debbugs-Cc: r...@debian.org

Same thing happened with the following upgrades:

Unpacking gcc-12 (12.3.0-10) over (12.3.0-9) ...
Unpacking libgcc-12-dev:amd64 (12.3.0-10) over (12.3.0-9) ...
Unpacking cpp-12 (12.3.0-10) over (12.3.0-9) ...
Unpacking gcc-12-base:amd64 (12.3.0-10) over (12.3.0-9) ...

apt-listchanges displayed what I think is the entire gcc changelog,
including the entries for 12.3.0-9 which were already installed.

It's not happening with every package, though. I'm not sure yet what the
common pattern is, unless it's packages that have multiple package names
in their changelog.

-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
email_address=none
confirm=0
save_seen=/var/lib/apt/listchanges
which=both
no_network=false
headers=false
reverse=false


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

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

Versions of packages apt-listchanges depends on:
ii  apt2.7.6
ii  debconf [debconf-2.0]  1.5.82
ii  python33.11.4-5+b1
ii  python3-apt2.6.0
ii  python3-debconf1.5.82
ii  sensible-utils 0.0.20
ii  ucf3.0043+nmu1

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  chromium [www-browser]  117.0.5938.149-1
ii  firefox [www-browser]   118.0-1+b1
ii  google-chrome-stable [www-browser]  117.0.5938.149-1
ii  links [www-browser] 2.29-1+b1
ii  lynx [www-browser]  2.9.0dev.12-1
ii  postfix [mail-transport-agent]  3.8.2-1
ii  python3-gi  3.46.0-1
ii  w3m [www-browser]   0.5.3+git20230121-2
ii  xterm [x-terminal-emulator] 385-1

-- debconf information:
* apt-listchanges/confirm: false
* apt-listchanges/headers: false
* apt-listchanges/which: both
* apt-listchanges/email-address:
* apt-listchanges/reverse: false
* apt-listchanges/save-seen: true
* apt-listchanges/frontend: pager
* apt-listchanges/no-network: false
  apt-listchanges/email-format: text

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Drew Parsons]

Nilesh explained most of the situation correctly.  I can give some more 
background.It made sense (to me) to have h5py built against 
hdf5-mpi, since I figured that if you need the complexity of the hdf5 
file format then you probably want to use it in an MPI environment.


There was a complaint from a user though, who wanted to make use of a 
massive ensemble of HDF5 (h5py) serial jobs, and the small cost of 
loading up MPI support was interfering with their throughput.


So the compromise solution was to provide both builds, with a custom 
__init__.py to select the serial or MPI build depending on runtime 
environment.  If an MPI environment is detected then the h5py MPI build 
is loaded, otherwise the serial build is loaded.


If you want to run h5py in a serial process, then one might say you'd 
normally want the serial build.  As Nilesh noted, I put in a mechanism 
to load the MPI build if you really want to access the mpi build in a 
serial process (mpirun -n 1 is not a "serial" process as such, it's 
still an MPI environment even though using only 1 process).


The mechanism to force MPI loading is NOT to set OMPI_COMM_WORLD_SIZE.  
I recommend NOT doing that. I couldn't promise it won't mess up other 
things, certainly it will get in the way of an MPICH environment.  No, 
the mechanism for handling this for h5py is described in 
/usr/share/doc/python3-h5py/README.Debian: set H5PY_ALWAYS_USE_MPI=1



Is there a way to force h5py to import _debian_h5py_serial instead of
_debian_h5py_mpi, via the generic h5py namespace?


It sounds like there is some confusion about how xmds2 should be used. 
Is it intended to be used as a serial process or MPI?  I noted in the 
bug report that xmds2 Depends: libhdf5-serial-dev.  Is it even using 
MPI?  If you want it to be using h5py-serial, then why does xmsd2 depend 
on python3-h5py-mpi?


It seems to me that xmds2's h5py dependency should be the same as its 
hdf5 dependency.  If it uses libhdf5-serial then should it be depending 
on just python3-h5py (implying python3-h5py-serial, make it explicit if 
needed) and not depend on python3-h5py-mpi?


If xmds2 is intended to be flexible, equally happy in serial and MPI 
environments (and can actually make use of h5py-mpi) then perhaps the 
dependency should cover all cases,

  Depends: python3-h5py, python3-h5py-serial, python3-h5py-mpi
all three explicitly, since otherwise one or the other of -serial or 
-mpi would be missed.


The problem raises interesting questions about h5py configuration. I set 
up it so you could choose how you want it to work, with or without MPI 
support.  But it looks like an edge case is missing: it's failing in 
serial jobs if you chose to set up your installation with 
python3-h5py-mpi and explicitly don't want python3-h5py-serial (unless 
you always set H5PY_ALWAYS_USE_MPI). Perhaps I should add an additional 
fallback to try h5py-mpi if h5py-serial is not found (in a serial job), 
the same way that h5py-serial is loaded as a fallback in an MPI job if 
h5py-mpi is not found. On the other hand maybe that just hides the real 
problem, that h5py-serial was not installed when actually it was wanted 
after all.  The ImportError correctly identifies that case.





On 2023-10-08 17:38, Nilesh Patra wrote:

Hello,

On 10/8/23 17:22, Rafael Laboissière wrote:
Ok, I tried to fix the building problem by including python3-h5py, 
alongside with python3-h5py-mpi, into Build-Depends, as suggested by 
Drew, but the xmds2 package FTBFS.


Here is a way to reproduce the problem without building the package:

   $ dpkg -l python3-h5py\*
   Desired=Unknown/Install/Remove/Purge/Hold
   | 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

   |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
   ||/ Name    Version  Architecture Description
   
+++-===---===
   ii  python3-h5py    3.9.0-3  all  general-purpose 
Python interface to hdf5
   ii  python3-h5py-mpi    3.9.0-3  amd64    general-purpose 
Python interface to hdf5 (Python 3 MPI)
   un  python3-h5py-serial       (no description 
available)

   $ echo 'import h5py' | python3
   Traceback (most recent call last):
     File "", line 1, in 
     File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 21, 
in 

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


Is there a way to force h5py to import _debian_h5py_serial instead of 
_debian_h5py_mpi, via the generic h5py namespace?


Drew would probably answer that question better but from taking a
brief look, it seems to be on expected lines.
This should work if you run it explicitly with mpi.

$ mpirun -n 1 python3 -c "import h5py" && echo 

Bug#1040138: changelog-file-missing-explicit-entry needs exception for bookworm

[Cyril Brulebois]

Marc Haber  (2023-07-01):
> this is the bookworm edition of #1001651 which got fixed by adding an
> exception, judging from the changelog entry of lintian 2.115.0.

That exception only hides the root of the bug, which includes (at least)
a messed up version sorting.

Adding another exception for bookworm will only lead to more
whack-a-mole down the line (see #1051140).

> This issue happens again when preparing a successive upload to bookworm.
> I have aide 0.18.3-1, 0.18.3-1+deb12u1 and 0.18.3-1+deb12u2, the deb12u2
> gets this lintian tag.
> 
> See https://salsa.debian.org/debian/aide/-/blob/bookworm/debian/changelog

Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1051140: Bug #1051140: lintian in bookworm does not know about bookworm-backports

[Cyril Brulebois]

Control: retitle -1 lintian in bookworm does not know about any bookworm* suites

Lee Garrett  (2023-09-03):
> Indeed, however the bug is about fixing it in stable.

Yes please; adjusting the title to reflect the fact it's not limited to
the backports suite for bookworm. For example:

E: package-goes-here changes: bad-distribution-in-changes-file bookworm

It would be great if lintian could get distribution names once they're
announced.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1053677: base-files: /var/lock points to non-existing /run/lock

[Santiago Vila]

severity 1053677 normal
thanks

El 9/10/23 a las 0:34, Diederik de Haas escribió:

I did initially wonder to which package to file the bug against as next to
debootstrap I also considered to file it against aptitude.
But as the base-files package creates the symlink, I think it's therefor also
its responsibility to make sure it points to an existing directory.


I see your point, but the directory /run/lock is special, because
directory /run is usually a ramdisk. The base-files package may not be
responsible for creating it, because it would not survive a reboot.

According to Bug #1039979 (where I'm asked to make such symlink relative,
which I can't for now because it's against policy) such directory is
re-created by systemd if you accidentally remove it, but it's
considered "legacy".

This is a snippet from /usr/lib/tmpfiles.d/legacy.conf:

--
# These files are considered legacy and are unnecessary on legacy-free
# systems.

L /var/lock - - - - ../run/lock
L /var/log/README - - - - ../../usr/share/doc/systemd/README.logs
--

This suggests to me that any program trying to use /var/lock directly
instead of /run/lock is probably buggy and should be fixed.

Therefore I think you should report this (as a different bug)
against any package trying to use /var/lock directly.

As I said, I don't think we can make base-files responsible for the
existence of /run/lock. If this is a bug at all in base-files,
it would be to remove /var/lock altogether, but that's something
I would have to coordinate with systemd maintainers. I'm going
to keep this open for now until we know if we can do that or not.

Thanks.

Bug#1050678: rust-async-process - update for new rustix.

[Peter Green]

severity 1050678 serious
thanks

On 27/08/2023 23:19, Peter Michael Green wrote:

Package: rust-async-process
Version: 1.7.0-2

I'm preparing an update for rustix, it's a new semver but so-far everything
seems to build with just the dependency bumped. I've uploaded it to 
experimental.
and assuming no showstoppers show up I hope to re-upload it to experimental 
soon.

I have prepared a patch for this package, are you ok if I just NMU it at the 
same time
as I'm uploading the rest of the reverse dependencies or do you want to handle 
the
update yourself?


The new version of rustix is now in unstable.

Bug#1030341: nextcloud-desktop-cmd: nextcloudcmd contains em-dashes instead of double dashes

[Hefee]

Control: Forwarded -1 https://github.com/nextcloud/desktop/pull/6122

Hey,

thanks for your bugreport. I sad down to create a fix and hopefully upstream 
will accept it.

regards,

hefee

--
On Freitag, 3. Februar 2023 10:52:01 CEST you wrote:
> Package: nextcloud-desktop-cmd
> Version: 3.1.1-2+deb11u1
> Severity: normal
> X-Debbugs-Cc: nicolas.geo...@ens.fr
> 
> Hi. `man nextcloudcmd` says:
> 
>—user, -u [user]
>   Use user as the login name.
> 
> But:
> 
> $ nextcloudcmd —user george [snip]
> nextcloudcmd - command line Nextcloud client tool
> [snip usage info]
> 
> $ nextcloudcmd -user george [snip]
> nextcloudcmd - command line Nextcloud client tool
> [snip usage info]
> 
> $ nextcloudcmd --user george [snip]
> Password for user george:
> 
> The man page (including its source file) contains an em-dash character
> U+2014 instead of a double dash. It is not limited to the --user option.
> 
> 
> -- System Information:
> Debian Release: 11.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable') Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/12 CPU threads; PREEMPT)
> Locale: LANG=C, LC_CTYPE=fr_FR.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 nextcloud-desktop-cmd depends on:
> ii  libc6 2.31-13+deb11u5
> ii  libgcc-s1 10.2.1-6
> ii  libnextcloudsync0 3.1.1-2+deb11u1
> ii  libqt5core5a  5.15.2+dfsg-9
> ii  libqt5network55.15.2+dfsg-9
> ii  libqt5sql5-sqlite 5.15.2+dfsg-9
> ii  libstdc++610.2.1-6
> ii  nextcloud-desktop-common  3.1.1-2+deb11u1
> ii  nextcloud-desktop-l10n3.1.1-2+deb11u1
> 
> nextcloud-desktop-cmd recommends no packages.
> 
> nextcloud-desktop-cmd suggests no packages.
> 
> -- no debconf information



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

Bug#1053677: base-files: /var/lock points to non-existing /run/lock

[Diederik de Haas]

On Sunday, 8 October 2023 19:40:43 CEST Santiago Vila wrote:
> > So `/var/lock` points to `/run/lock` ... which doesn't exist.
> > And that results in errors and a warning from aptitude with potentially
> > some serious consequences.
> 
> Thanks for the report. I think this has never happened until now.

When I put "Could not open lock file /var/lock/aptitude" into a search engine, 
the first result was https://askubuntu.com/a/120757 from 2012-04-10
And the presented solution was "sudo mkdir /run/lock".
So it seems to me that nobody (apparently) never reported it before, but it 
isn't a new problem by any means.
It could be that 'aptitude' is important to reveal the issue.

It's also possible that another program which normally gets installed, would 
create that directory. I had not (yet) installed packages of priority 
important or normal when the issue occurred.

> If yes, I believe that we should reassign this report to debootstrap.

I did initially wonder to which package to file the bug against as next to 
debootstrap I also considered to file it against aptitude. 
But as the base-files package creates the symlink, I think it's therefor also 
its responsibility to make sure it points to an existing directory.

Cheers,
  Diederik

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

Bug#1053313: octavia-agent: please depends on "cron | cron-daemon"

[Alexandre Detiste]

Le jeu. 5 oct. 2023 à 23:28, Thomas Goirand  a écrit :
> Do you know what octavia-agent does?

No I don't know what it does.

I did a MBF to fix the packages with the same glitch in ... 2015
and for sure I didn't took the time to study every single package
in detail. And since I've been filing a few more bugs over the years.

The only thing special thing I noticed about octavia-agent
is the 1 popcon.

> Currently, I tweak anacron to run every hour, otherwise the
> haproxy logs can be too big, so really, there's only a single
> implementation that I care about.

/etc/crontab belongs to the shared cron-daemon-common
if that matters.

> Does it really still feel like we need multiple alternatives then?

It helps with the readability of the archive as a whole,
but you have the last word with your package.

Greetings

Bug#1053696: Upgrading Python packages showed numerous ancient changelog entries

[Russ Allbery]

Package: apt-listchanges
Version: 4.0
Severity: normal
X-Debbugs-Cc: r...@debian.org

An apt run that included the following upgrades:

Unpacking python3.11-dev (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11-dev:amd64 (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11:amd64 (3.11.6-3) over (3.11.6-2) ...
Unpacking python3.11-venv (3.11.6-3) over (3.11.6-2) ...
Unpacking python3.11 (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11-stdlib:amd64 (3.11.6-3) over (3.11.6-2) ...
Unpacking python3.11-minimal (3.11.6-3) over (3.11.6-2) ...
Unpacking libpython3.11-minimal:amd64 (3.11.6-3) over (3.11.6-2) ...
Unpacking python3.11-doc (3.11.6-3) over (3.11.6-2) ...

appears to have gotten confused about what entries I would have seen before
and showed me what appeared to be the entire python3.11 changelog. I thought
it may have only been because the package name in that changelog changes
over time, but it also showed me the entries for 3.11.6-2 and 3.11.6-1,
which have the same source and binary package names and were already
installed. That makes me think something more fundamental may have gone
wrong.

I'm not completely sure which package the changelog entries were pulled from.
I spot-checked a few of them on disk and they all seemed to be truncated at
python3.8, but apt-listchanges found and displayed changelog entries going
back to python2.* versions.

-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
email_address=none
confirm=0
save_seen=/var/lib/apt/listchanges
which=both
no_network=false
headers=false
reverse=false


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

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

Versions of packages apt-listchanges depends on:
ii  apt2.7.6
ii  debconf [debconf-2.0]  1.5.82
ii  python33.11.4-5+b1
ii  python3-apt2.6.0
ii  python3-debconf1.5.82
ii  sensible-utils 0.0.20
ii  ucf3.0043+nmu1

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  chromium [www-browser]  117.0.5938.149-1
ii  firefox [www-browser]   118.0-1+b1
ii  google-chrome-stable [www-browser]  117.0.5938.149-1
ii  links [www-browser] 2.29-1+b1
ii  lynx [www-browser]  2.9.0dev.12-1
ii  postfix [mail-transport-agent]  3.8.2-1
ii  python3-gi  3.46.0-1
ii  w3m [www-browser]   0.5.3+git20230121-2
ii  xterm [x-terminal-emulator] 385-1

-- debconf information:
* apt-listchanges/headers: false
  apt-listchanges/email-format: text
* apt-listchanges/frontend: pager
* apt-listchanges/email-address:
* apt-listchanges/reverse: false
* apt-listchanges/confirm: false
* apt-listchanges/which: both
* apt-listchanges/save-seen: true
* apt-listchanges/no-network: false

Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required

[Nicholas D Steeves]

Jonathan Hettwer  writes:

> Package: partman-crypto
> Version: 121
> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: j24...@gmail.com
>
> Dear Maintainer,
>
> The `crypto_check_mountpoints` script prevents you from setting up an
> encrypted root filesystem without an additional unencrypted /boot
> filesystem.
> While this may be a requirement for e.g. grub2, it is not
> necessarily required when not using grub2 but using UKIs to build EFI
> executables that can directly mount the encrypted root filesystem.
> While UKIs aren't currently supported, I would still expect partman-crypto
> to let me partition an encrypted root filesystem without separate /boot
> filesystem, at least after having ignored the warnings or in combination
> with the `nobootloader` udeb.

Quick note: systemd-boot works with kernel images + initramfs, without
UKI.  After the systemd-boot menu, the user is prompted for the master
LUKS password, as usual, and I use the derived key script to then
unlocks a couple LUKS volumes.  No LVM, no /boot.  It seems to work
well, but yeah, it's not possible to do this with fresh install (I
manually migrated an old installation to new hardware).

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1049700: texlive-extra: Fails to build binary packages again after successful build

[Preuße]

On 16.08.2023 09:42, Lucas Nussbaum wrote:

Hi Lucas,


This package fails to do build a binary-only build (not source) after a
successful build (dpkg-buildpackage ; dpkg-buildpackage -b).



I've put a new package here [1]. According to my testings, the issue 
should have been solved. Could you check? Many thanks!


Hilmar

[1] https://www.beckmann.pro/~hille42/tl_extra/
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1045828: texlive-extra: Fails to build source after successful build

[Preuße]

On 13.08.2023 21:21, Lucas Nussbaum wrote:

Hi Lucas,


This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).



I've put a new package here [1]. According to my testings, the issue 
should have been solved. Could you check? Many thanks!


Hilmar

[1] https://www.beckmann.pro/~hille42/tl_extra/
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053695: ITP: httpie-aws-authv4 -- AWS Signature v4 Signing Process authentication plugin for HTTPie

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: httpie-aws-authv4
  Version : 0.3.0-1
  Upstream Author : Aidan Rowe 
* URL : https://github.com/aidan-/httpie-aws-authv4
* License : MIT/Expat
  Programming Lang: Python
  Description : AWS Signature v4 Signing Process authentication plugin for 
HTTPie

 This is an HTTPie Python plugin for developers and system administrators
 engaged with Amazon Web Services (AWS).
 .
 Its primary function is to simplify the authentication process and facilitate
 requests to AWS services, all using the AWS Signature Version 4 authentication
 protocol.

Bug#1037957: nextcloud-desktop: XFCE sessions cause broken behavior after 11 -> 12 upgrade

[Hefee]

Hey,

Thanks fir your bugreport.
This is an issuse of the Nextcloud itself and not about the packaging. So 
please look into the upstream bugtracker:
https://github.com/nextcloud/desktop/issues
and report your bug there, if you don't find any matching one. Or even provide 
a bugfix/merge request ;)

If you found or open a bugreport that matches please send this url to this 
bugreport, so we can track the upstream status and may backport the fix, if 
there is any.

Best regards,

hefee

--

> After upgrading to Debian Bookworm from Bullseye, nextcloud-desktop
> erroneously opens it's main popup window in the dead center of the screen
> when a user logs in to an XFCE session.
> 
> Closing the window normally, by clicking outside of the window, does not
> work.
> 
> Instead the user must either input the Alt-F4 combination. Or click on the
> tray icon once to move the window back under the tray icon, (Where it
> should appear normally.) and again to close the window. This has to be done
> on every login regardless of reboots.
> 
> Also, if the user has configured items to be excluded from sync (such as
> files that are too big for the destination, server files on external
> storage, etc.) nextcloud-desktop will also start sending notifications
> about them prompting the user to configure the app despite having already
> made their configuration choice. This too happens on every login, but can
> be disabled by disabling notifications from the app.
> 
> As an additional note, when I upgraded from Bullseye, the nextcloud-desktop
> package was uninstalled due to a package conflict. I reinstalled it after
> the upgrade was complete without the conflict occuring again.

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

Bug#980025: nextcloud-desktop: Nextcloud-desktop starts but window doesn't display properly and disappears in GNOME

[Hefee]

Hey,

Is libqt5waylandclient is installed?

> I can reproduce it here under Gnome / wayland; (Under X, it works.)
> I've got a nvidia GPU with nvidia-drivers from non-free, maybe that's
> another nvidia issue?

that is quite possible. NVIDIA and wayland are not the best friends ;)

> 
> If I start using specifing some QT_OPA_PLATFROM value, eg
> 
> QT_QPA_PLATFORM=wayland nextcloud --logfile - --logdebug

Well I run wayland on a daily basis and I don't see the error for the KDE 
Plasma desktop with wayland .  Is libqt5waylandclient is installed? Maybe you 
can install kde-standard in parallel to your GMOME desktop, to make sure it is 
not a missing dependency?

regards,

hefee

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

Bug#1053531: [pkg-gnupg-maint] Bug#1053531: gnupg/gpg-agent/pinentry: timeout

[Thorsten Glaser]

Werner Koch dixit:

>> IMHO the pinentry form shouldn’t time out (or at least be reasonable
>> about it, e.g. time out after one hour, at the earliest, or so).
>
>Put a pinentry-timeout into gpg-agent.conf

Oh, okay.

>No timeout is not a good idea either
>because you will run into a related problem when you request a second
>action requiring a pinentry - that will then wait for the already open
>pinentry somewhere on another desktop.

Right, I remember running into that with pinentry-kwallet malfunctions,
but usually a pkill should suffice to fix that up (which I admit is not
something you’d tell “normal” users to do).

Thanks,
//mirabilos

Bug#1034184: [Pkg-owncloud-maintainers] Bug#1034184: Bug#1034184: nextcloud-desktop: CVE-2023-28999

[Hefee]

control: fixed -1 3.9.0-1

We can at least mark sid/trixie as fixed. As those two have a version > 3.8.0 
;)

Regards,

hefee

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

Bug#1053694: vim: CVE-2023-5344

[Salvatore Bonaccorso]

Source: vim
Version: 2:9.0.1894-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for vim.

CVE-2023-5344[0]:
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to
| 9.0.1969.


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-5344
https://www.cve.org/CVERecord?id=CVE-2023-5344
[1] https://github.com/vim/vim/commit/3bd7fa12e146c6051490d048a4acbfba974eeb04
[2] https://huntr.dev/bounties/530cb762-899e-48d7-b50e-dad09eb775bf

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053693: ansible-core: CVE-2023-5115

[Salvatore Bonaccorso]

Source: ansible-core
Version: 2.14.10-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ansible/ansible/pull/81780
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ansible-core.

CVE-2023-5115[0]:
| malicious role archive can cause ansible-galaxy to overwrite
| arbitrary files


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-5115
https://www.cve.org/CVERecord?id=CVE-2023-5115
[1] https://github.com/ansible/ansible/pull/81780

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053692: [graphicsmagick:discussion] Re: Any plans to add HEIC format?

[GCS]

Control: forwarded -1 https://github.com/strukturag/libheif/issues/974

Hi,

On Sun, Oct 8, 2023 at 10:09 PM Dan Jacobson  wrote:
> Hello. The viewnior and gpicview packages support heic, so should gm.
> On 2023-10-08 08:08, Bob Friesenhahn wrote:
> > On Sat, 7 Oct 2023, Dan Jacobson wrote:
> >> $ gm convert -list formats |fgrep -i heif
> >> AVIF P  r--  HEIF Image Format (heif v16.2.0)
> >> HEIC P  r--  HEIF Image Format (heif v16.2.0)
> >> HEIF P  r--  HEIF Image Format (heif v16.2.0)
> >> $ gm convert -debug coder,exception C001.heic info:-
> >> 18:35:16 0:0.002526  0.000u 3249 constitute.c/ReadImage/1676/Coder:
> >>  Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0
> >> 18:35:16 0:0.010894  0.010u 3249 heif.c/ReadHEIFImage/571/Coder:
> >>  Geometry: 1280x720
> >> 18:35:16 0:0.011036  0.010u 3249 heif.c/ReadHEIFImage/573/Coder:
> >>  Matte: False
> >> 18:35:16 0:0.011135  0.010u 3249 heif.c/ReadHEIFImage/650/Coder:
> >>  heif_decode_image() reports error "Unsupported feature: Unsupported
> >> codec"
> >
> > From the above, I deduce that libheif from Debian Sid does not support
> > HEIC, or a sub-feature of HEIC.  It is possible that Debian Sid
> > binaries do not include support for HEIC at all.
 It's up to the new HEIF library which broke other packages including
GM, GIMP, etc. See the relevant bug report in Debian [1]. Its upstream
stated to solve this, but it seems not the case [2]. That's why GM and
others can't use the mentioned display formats.

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/1041242
[2] https://github.com/strukturag/libheif/issues/974

Bug#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

Am 07.10.23 um 13:14 schrieb Jonathan Wiltshire:

Hi,


On Sun, Sep 24, 2023 at 09:36:00PM +0200, Bernhard Schmidt wrote:

[ Other info ]
I did not attach the debdiff because it would be too large and only consist
of upstream changes. No changes to debian/ (except dropping a backported fix
already in 12.1) are necessary.


What does diffstat look like, possibly with translations and tests
excluded? Let's see what sort of scale we're talking here.


Plain debdiff

 185 files changed, 25810 insertions(+), 28068 deletions(-)

There are no translation changes and not many tests to exclude, but a 
few things stand out. Dropping quite a bit from m4 buildfiles as part of 
commits


https://github.com/phaag/nfdump/commit/488e2136bb97f5ae45900fd93e390e1be25cb91e
https://github.com/phaag/nfdump/commit/93f1af69d15dec0600d7ac311bd33c15556dee25

(remove autogen m4 files from repo)

 m4/libtool.m4  | 8400 
---

 m4/ltoptions.m4|  437 --
 m4/ltsugar.m4  |  124 --
 m4/ltversion.m4|   24 -
 m4/lt~obsolete.m4  |   99 --

a few renames

 src/lib/{ => compress}/lzoconf.h   |0
 src/lib/{ => compress}/lzodefs.h   |0
 src/lib/{ => compress}/minilzo.c   |0
 src/lib/{ => compress}/minilzo.h   |0
 src/{ => lib}/conf/nfconf.c|   38 +-
 src/{ => lib}/conf/nfconf.h|2 +
 src/{ => lib}/conf/nfdump.conf.dist|   19 +-
 src/{ => lib}/conf/toml.c  |2 +-
 src/{ => lib}/conf/toml.h  |0
 src/{nfcapd/netflow_pcapd.c => netflow/nfd_raw.c}  |   96 +-
 src/{include/netflow_pcapd.h => netflow/nfd_raw.h} |   18 +-

and the move and update of the embedded lz4 code

https://github.com/phaag/nfdump/commit/99dc96e8433637ef1d62edbf13f26655a3815982

 src/lib/compress/lz4.c | 2751 
++

 src/lib/compress/lz4.h |  862 
 src/lib/lz4.c  | 1564 
--

 src/lib/lz4.h  |  483 ---

and the addition of the High Compression Mode of LZ4

 src/lib/compress/lz4hc.c   | 1637 
+++

 src/lib/compress/lz4hc.h   |  413 ++

https://github.com/phaag/nfdump/commit/cb254b1730b3abc39627b16d4c04b97cdcd62de0

I'll reach out to upstream about those embedded lz4 copy, right now it 
does not look like one could build against an external library, in 
contrast to zstd and bz2 support.


If you exclude all

git diff upstream/1.7.1 upstream/1.7.3 --stat -- . ':!*.m4' 
':!src/lib/compress/lz4.*' ':!src/lib/compress/lz4hc.*' ':!src/lib/lz4.*'


that you get down to

 .github/FUNDING.yml|   1 +
 .github/workflows/c-cpp.yml|  23 +
 .gitignore |   1 +
 ChangeLog  | 171 ++
 Makefile.am|   2 +-
 README.md  | 112 +++-
 configure.ac   |  64 +-
 extra/CreateSubHierarchy.pl|   6 +-
 extra/docker/Dockerfile.alpine |   2 +-
 extra/docker/Dockerfile.ubuntu |   2 +-
 extra/nfsen/nfsen-1.6-stats-influxdb.patch |   2 +-
 extra/nfsen/nfsen-trunk-stats-influxdb.patch   |   2 +-
 man/geolookup.1|   2 +-
 man/nfanon.1   |   4 +-
 man/nfcapd.1   |  49 +-
 man/nfdump.1   |  97 ++-
 man/nfexpire.1 |   6 +-
 man/nfpcapd.1  |  32 +-
 man/nfreplay.1 |   5 +-
 man/sfcapd.1   |  35 +-
 src/collector/Makefile.am  |   5 +-
 src/collector/bookkeeper.c |  28 +-
 src/collector/bookkeeper.h |  15 +-
 src/collector/collector.c  |  74 ++-
 src/collector/collector.h  |  30 +-
 src/collector/expire.c |  23 +-
 src/collector/launch.c | 329 ++
 src/collector/launch.h |  11 +-
 src/collector/metric.c |   8 +-
 src/collector/nfnet.c  |  92 ++-
 src/collector/nfnet.h  |  26 +-
 

Bug#1053692: [graphicsmagick:discussion] Re: Any plans to add HEIC format?

[Dan Jacobson]

Package: graphicsmagick

Hello. The viewnior and gpicview packages support heic, so should gm.

---


On 2023-10-08 08:08, Bob Friesenhahn wrote:

On Sat, 7 Oct 2023, Dan Jacobson wrote:

I was using https://packages.debian.org/sid/graphicsmagick on a 
chromebook

$ gm convert -list formats |fgrep -i heif
AVIF P  r--  HEIF Image Format (heif v16.2.0)
HEIC P  r--  HEIF Image Format (heif v16.2.0)
HEIF P  r--  HEIF Image Format (heif v16.2.0)
$ gm convert -debug coder,exception C001.heic info:-
18:35:16 0:0.002526  0.000u 3249 constitute.c/ReadImage/1676/Coder:
 Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0
18:35:16 0:0.010894  0.010u 3249 heif.c/ReadHEIFImage/571/Coder:
 Geometry: 1280x720
18:35:16 0:0.011036  0.010u 3249 heif.c/ReadHEIFImage/573/Coder:
 Matte: False
18:35:16 0:0.011135  0.010u 3249 heif.c/ReadHEIFImage/650/Coder:
 heif_decode_image() reports error "Unsupported feature: Unsupported 
codec"


From the above, I deduce that libheif from Debian Sid does not support
HEIC, or a sub-feature of HEIC.  It is possible that Debian Sid
binaries do not include support for HEIC at all.

The nature of free software is that free software developers (and free
distributions) may not be willing to pay license fees, or legal fees,
or financial penalties, associated with patented algorithms.

At least Ubuntu 22.04 LTS does include HEIC support.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, 
http://www.simplesystems.org/users/bfriesen/

GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, 
http://www.simplesystems.org/users/bfriesen/public-key.txt



---

[Any plans to add HEIC
format?](https://sourceforge.net/p/graphicsmagick/discussion/250738/thread/3082583888/?limit=25#72bc/4107/9a40/a1c7)

Bug#1053691: pyreadstat: Update to v1.2.3+ when cython 3.x is ready

[Boyuan Yang]

Source: pyreadstat
Version: 1.2.2-1
Severity: normal
Tags: sid

To update package pyreadstat to v1.2.3 or later, we will need cython 3.x.

The packaging of cython 3.x is being tracked in https://bugs.debian.org/1028157 
.

Thanks,
Boyuan Yang


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

Bug#1042029: graph-tool: FTBFS: fatal error: ld terminated with signal 9 [Killed] [cannot reproduce]

[Santiago Vila]

found 1042029 2.45+ds-10
tags 1042029 + patch
thanks

El 26/7/23 a las 23:12, Jerome BENOIT escribió:

Hi Lucas, I could not reproduce the issue in the current Sid environment
(I tried twice) so I am closing the bug. It is highly probable that
your build encountered a resource issue as this software is really heavy to 
build.


Hello.

This is certainly heavy to build.

However, it is so needlessly.

For example, configure.ac unconditionally adds -O3 to CXXFLAGS.
This is already a bug, because packages should honor whatever comes
from dpkg-buildflags (usually -O2).

Trivial patch attached. While I have not tested specifically if it solves
the issue for me, I think it is a patch which should be applied in either case.

[ For the record, I also tried to build this package and it also failed for me.
Last time I tried it was using a machine with 16 GB of RAM and 4 GB of swap.
To put things in perspective, I can build *all* the 35208 source packages 
currently
in trixie with 16 GB of RAM. But not this one ].

Thanks.--- a/configure.ac
+++ b/configure.ac
@@ -65,7 +65,7 @@ dnl set default visibility
 [CXXFLAGS="-fvisibility=default -fvisibility-inlines-hidden ${CXXFLAGS}"]
 
 dnl set default optimizations
-[CXXFLAGS="-O3 ${CXXFLAGS}"]
+[CXXFLAGS="${CXXFLAGS}"]
 
 dnl disable annoying boost warnings
 [CPPFLAGS="-DBOOST_ALLOW_DEPRECATED_HEADERS ${CPPFLAGS}"]

Bug#1053690: ceph: CVE-2023-43040: Improperly verified POST keys

[Salvatore Bonaccorso]

Source: ceph
Version: 16.2.11+ds-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/ceph/ceph/pull/53714
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ceph.

CVE-2023-43040[0]:
| Improperly verified POST keys


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-43040
https://www.cve.org/CVERecord?id=CVE-2023-43040
[1] https://www.openwall.com/lists/oss-security/2023/09/26/10
[2] https://github.com/ceph/ceph/pull/53714

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053689: libnma-gtk4-0: Fix crash due to infinte loop in gnome-control-center ( Ask for this password every time )

[sidt]

Package: libnma-gtk4-0
Version: 1.10.6-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: sidto...@gmail.com

Dear Maintainer,

Request to patch libnma in Debian.

Refer https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2109 for
details of the crash, caused by infinite loop.

Fixed in libnma upstream:

Commit:
https://gitlab.gnome.org/GNOME/libnma/-/commit/d48911ca5f7ad4fbc44fef08df57e5fd844ba862

Merge request: https://gitlab.gnome.org/GNOME/libnma/-/merge_requests/52



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

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

Versions of packages libnma-gtk4-0 depends on:
ii  libc62.37-12
ii  libcairo21.18.0-1
ii  libgck-1-0   3.41.1-3
ii  libgcr-base-3-1  3.41.1-3
ii  libglib2.0-0 2.78.0-2
ii  libgtk-4-1   4.12.3+ds-1
ii  libnm0   1.44.2-1
ii  libnma-common1.10.6-1

libnma-gtk4-0 recommends no packages.

libnma-gtk4-0 suggests no packages.

-- no debconf information

Bug#1053688: wait(2) says si_status will contain the exit code "as given"

[Michael Gold]

Package: manpages-dev
Version: 6.03-2

Dear Maintainer,

I saw that the manual for exit(3) claimed "the least significant byte of
status (i.e., status & 0xFF) is returned to the parent".  This surprised
me because I was pretty sure that POSIX required the full status to made
available.  It does:
   "the full value shall be available from waitid() and in the siginfo_t
passed to a signal handler for SIGCHLD."
   https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html

And the wait(2) manual page documents it as such:
   "waitid()
…
si_status
Either the exit status of the child, as given  to  _exit(2)  (or
exit(3)),  or  the  signal  that  caused the child to terminate,
stop, or continue.  The si_code field can be used  to  determine
how to interpret this field."

However, this doesn't actually work on Linux.  Here's a test program:
#include 
#include 
#include 
#include 
int main() {
pid_t pid=fork();
if(pid<0){perror("fork"); exit(1);}
if(pid==0)_exit(12345);
siginfo_t si={0};
pid=waitid(P_PID,pid,,WEXITED);
if(pid<0)perror("waitid");
printf("pid=%d, status=%d\n",pid,si.si_status);
}

It prints status=57 (12345 & 255), which is not "as given".  Until Linux
is changed to follow the recent POSIX requirement, the manual should say
that si_status is the low 8 bits.  It might also be helpful to note this
as a deviation from the 2018 edition of POSIX.

By the way, running the test with "strace -f" shows that the child gives
the full status code to the kernel, and the waitid() syscall returns the
truncated version.

- Michael


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/32 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 manpages-dev depends on:
ii  manpages  6.03-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.12.0-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1053687: /usr/lib/nagios/plugins/utils.pm should set $PATH_TO_LMSTAT to /usr/local/bin/lmstat

[Christian]

Package: monitoring-plugins-standard
Version: 2.3.3-5+deb12u1

Any changes to $PATH_TO_LMSTAT in /usr/lib/nagios/plugins/utils.pm will 
be overwritten by the next package upgrade. It is therefore impossible 
to tell the package in a stable way where the lmstat binary is located. 
I assume lmstat is not provided by any standard debian package, so I 
suggest setting $PATH_TO_LMSTAT to /usr/local/bin/lmstat


The sysadmin could then create a symbolic link /usr/local/bin/lmstat and 
that would fix things.


Thanks for looking into this,

Christian

Bug#1053680: RFS: streamlink/6.2.1-1~bpo12+1 -- CLI for extracting video streams from various websites to a video player

[Boyuan Yang]

Hi,

在 2023-10-08星期日的 19:00 +0200，Alexis Murzeau写道：
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-CC: debian-backpo...@lists.debian.org
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "streamlink" into Debian
> bookworm-backports repository.
> 
>  * Package name    : streamlink
>    Version : 6.2.1-1~bpo12+1
>    Upstream Author : Streamlink Team
>  * URL : https://streamlink.github.io/
>  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
>    Section : python
> 
> It builds those binary packages:
> 
>   python3-streamlink - Python module for extracting video streams
> from various websites
>   streamlink - CLI for extracting video streams from various
> websites to a video player
> 
> To access further information about this package, please visit the
> following URL:
>   https://mentors.debian.net/package/streamlink
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.2.1-1~bpo12+1.dsc
> 
> 
> 
> Differences from testing package (6.2.1-1):
>    * d/control,rules: remove doc package because of missing dependencies
>  on bookworm.
>    * d/patches: remove webbrowser tests which require pytest-trio which
>  is not available on bookworm.

Package python3-pytest-trio is now available in bookworm-backports. Could you 
check and
try again?

Thanks,
Boyuan Yang


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

Bug#1053663: libraft2: Consider switching upstream to cowsql/raft

[Free Ekanayaka]

László Böszörményi (GCS)  writes:

> Hi Free,
>
> On Sun, Oct 8, 2023 at 12:09 PM Free Ekanayaka  wrote:
>> The canonical/dqlite and canonical/raft projects on GitHub have also
>> been forked into cowsql/cowsql and cowsql/raft respectively:
> [...]
>> I'm the original upstream author of dqlite and its C raft library, and
>> after having left Canonical I tried for quite some time to collaborate
>> with them on dqlite, but I always felt there was not much interest in
>> having it be a real "community" project, so after LXD was forked I
>> decided to fork dqlite too.
>  Bit strange, I heard good things about Canonical and I respect their work.

Fair enough, indeed this is just my experience in this specific
case. It's unclear in which direction they want to evolve dqlite and
raft (if at all), and they were not quite willing to discuss that in the
open or accept advice (at least from me).

I'd like to see and have a clear and sensible roadmap, but there's none
at the moment.

> OK, currently I can't build 'raft' on Debian, a bug is reported [1]
> and upstream working on it. Fedora has a patch, which I haven't tried
> yet.

I've notice that, I'll take a look as well.

>> While I could not keep the name "dqlite" (which is a trademark of
>> Canonical), the name "raft" is just the name of an algorithm, so it I
>> haven't changed it.
>>
>> I'm also a Debian Developer, and I'd like to propose to switch the
>> upstream of the libraft package from canonical/raft to cowsql/raft,
>> instead of having to upload a separate package with a different name or
>> alternatively vendoring cowsql/raft into cowsql/cowsql.
>  I would be happier if you two can join forces - software development
> is a long task, you need to take care of it for years to come.

That was my stance too, it didn't quite fly. I'm certainly here for the
long haul fwiw.

> I'm open to switching to cowsql/raft as you are the original upstream
> author. Hope you will find long term contributors to the project.

Thanks, the Incus team broadly is committed to cowsql and raft too,
although to a lesser extent than myself, since it's an important
dependency of Incus.

>> The cowsql/raft library is compatible with canonical/raft so there would
>> be no disruption for users and for reverse dependencies. I don't expect
>> this compatibilty to be an issue for the forseeble future (e.g. during
>> the Trixie cycle).
>  That's a good promise, I say let's go with it then.
>
>> I'd also like to help with maintainership of both src:dqlite and the
>> re-upstreamed src:raft in Debian, making sure that things work as
>> expected.
>  This is also accepted, you can open a project on Salsa and either
> start a project group or just make yourself the maintainer and me as
> an uploader. But the former might be better as I think Mathias might
> like to join.

Great, thanks! I'll start a new project group then, that you and Mathias
can join as well.

I'll follow-up this bug with the relevant updates.

Cheers,

Free

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Adrian Bunk]

Source: pandoc
Version: 2.17.1.1-3
Severity: serious
Tags: ftbfs

 builddeps:pandoc : Depends: libghc-aeson-dev (< 2.1) but 2.1.2.1-4 is to be 
installed
Depends: libghc-doclayout-dev (< 0.4) but 0.4.0.1-1 is to 
be installed
Depends: libghc-haddock-library-dev (< 1.11) but 1.11.0-1 
is to be installed
Depends: libghc-hslua-aeson-dev (< 2.2) but 2.3.0.1-1 is to 
be installed
Depends: libghc-hslua-marshalling-dev (< 2.2) but 2.3.0-1 
is to be installed
Depends: libghc-jira-wiki-markup-dev (< 1.5) but 1.5.1-1 is 
to be installed
Depends: libghc-pandoc-types-dev (< 1.23) but 1.23.1-1 is 
to be installed

Bug#1053677: base-files: /var/lock points to non-existing /run/lock

[Diederik de Haas]

On Sunday, 8 October 2023 19:40:43 CEST Santiago Vila wrote:
> El 8/10/23 a las 18:03, Diederik de Haas escribió:
> > So `/var/lock` points to `/run/lock` ... which doesn't exist.
> > And that results in errors and a warning from aptitude with potentially
> > some serious consequences.
> 
> Thanks for the report. I think this has never happened until now.
> 
> Can you confirm that this happens only with the debootstrap version
> in trixie/sid and not with the bookworm version?
> 
> If yes, I believe that we should reassign this report to debootstrap.

I'm building the image using 'debos' on a Debian Bookworm system/VM:
diederik@debos-builder-deb12:~/pineian-images$ aptitude versions debootstrap
i A 1.0.128+nmu2stable  
 500

But I'm building a Trixie system/image.

I reported the issue from my main PC assuming it wouldn't matter as
I thought the problem was a missing '-p' argument in debian/postinst.in/#L30
and that hadn't changed between Bookworm and Trixie/Sid.



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

Bug#1053663: libraft2: Consider switching upstream to cowsql/raft

[GCS]

Hi Free,

On Sun, Oct 8, 2023 at 12:09 PM Free Ekanayaka  wrote:
> The canonical/dqlite and canonical/raft projects on GitHub have also
> been forked into cowsql/cowsql and cowsql/raft respectively:
[...]
> I'm the original upstream author of dqlite and its C raft library, and
> after having left Canonical I tried for quite some time to collaborate
> with them on dqlite, but I always felt there was not much interest in
> having it be a real "community" project, so after LXD was forked I
> decided to fork dqlite too.
 Bit strange, I heard good things about Canonical and I respect their work.
OK, currently I can't build 'raft' on Debian, a bug is reported [1]
and upstream working on it. Fedora has a patch, which I haven't tried
yet.

> While I could not keep the name "dqlite" (which is a trademark of
> Canonical), the name "raft" is just the name of an algorithm, so it I
> haven't changed it.
>
> I'm also a Debian Developer, and I'd like to propose to switch the
> upstream of the libraft package from canonical/raft to cowsql/raft,
> instead of having to upload a separate package with a different name or
> alternatively vendoring cowsql/raft into cowsql/cowsql.
 I would be happier if you two can join forces - software development
is a long task, you need to take care of it for years to come.
I'm open to switching to cowsql/raft as you are the original upstream
author. Hope you will find long term contributors to the project.

> The cowsql/raft library is compatible with canonical/raft so there would
> be no disruption for users and for reverse dependencies. I don't expect
> this compatibilty to be an issue for the forseeble future (e.g. during
> the Trixie cycle).
 That's a good promise, I say let's go with it then.

> I'd also like to help with maintainership of both src:dqlite and the
> re-upstreamed src:raft in Debian, making sure that things work as
> expected.
 This is also accepted, you can open a project on Salsa and either
start a project group or just make yourself the maintainer and me as
an uploader. But the former might be better as I think Mathias might
like to join.

Cheers,
Laszlo/GCS

Bug#1053685: fcoe-utils FTBFS on 32-bit archs with gcc-13, successful with gcc-12

[tony mancill]

Source: fcoe-utils
Severity: important

With the most recent upload, the auto-builders detected a build failure
on 32-bit architectures that appears to be a regression between gcc-12
and gcc-13.  I'm starting the bug report here but will reassign or merge
and add an affects once I am able to pin down the root cause or a case
that reproduces it outside of fcoe-utils.

Builds on i386, armhf, and armel fail with:

> fcoemon.c:1347:9: error: ‘__builtin_strncpy’ output may be truncated copying 
> between 0 and 15 bytes from a string of length 15 
> [-Werror=stringop-truncation]
>  1347 | strncpy(msg.ifname, ff->ifname, iflen);
>   | ^ 
> cc1: all warnings being treated as errors

The same build succeeds on 64-bit architectures, and on 32-bit
architectures if you set CC=gcc-12.

The only current bug against gcc-13 that looks plausibly related is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050589, but it's not
clear to me that they are the same.

Bug#1053684: src:procps: fails to migrate to testing for too long: FTBFS on amd64/i386 and autopkgtest elsewhere

[Paul Gevers]

Source: procps
Version: 2:4.0.3-1
Severity: serious
Control: close -1 2:4.0.4-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1052034

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:procps has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable fails to 
build from source on amd64 and i386 as reported in bug 1052034. It fails 
it's own autopkgtest on all architectures where it runs.


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053677: base-files: /var/lock points to non-existing /run/lock

[Santiago Vila]

El 8/10/23 a las 18:03, Diederik de Haas escribió:

So `/var/lock` points to `/run/lock` ... which doesn't exist.
And that results in errors and a warning from aptitude with potentially
some serious consequences.


Thanks for the report. I think this has never happened until now.

Can you confirm that this happens only with the debootstrap version
in trixie/sid and not with the bookworm version?

If yes, I believe that we should reassign this report to debootstrap.

Thanks.

Bug#1053683: libsdbus-c++-dev: missing dependency on libsystemd-dev

[Oliver Kästner]

Package: libsdbus-c++-dev
Version: 1.1.0-3
Severity: normal

Dear Maintainer,

libsystemd-dev is a hard requirement for libsdbus-c++-dev, please add it to the
package dependencies. Thanks!

~oliver


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

Kernel: Linux 6.2.0-34-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 libsdbus-c++-dev depends on:
ii  libsdbus-c++1  1.1.0-3

libsdbus-c++-dev recommends no packages.

Versions of packages libsdbus-c++-dev suggests:
pn  libsdbus-c++-bin  

-- no debconf information

Bug#1053682: RFS: qnetload/1.3.6-1 [ITP] -- Graphically display network speed and usage

[Carles Pina i Estany]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : qnetload
   Version  : 1.3.6-1
   Upstream contact : Carles Pina i Estany 
 * URL  : https://github.com/cpina/qnetload
 * License  : GPL-3, CC-BY-3.0
 * Vcs  : https://salsa.debian.org/carlespina/qnetload
   Section  : net

The source builds the following binary packages:

  qnetload - Graphically display network speed and usage

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qnetload/qnetload_1.3.6-1.dsc

Changes for the initial release:

 qnetload (1.3.6-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1053480)

Regards,

-- 
Carles Pina i Estany
https://carles.pina.cat


signature.asc
Description: PGP signature

Bug#1053681: bookworm-pu: package systemd/252.18-1~deb12u1

[Luca Boccassi]

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

Dear Release Team,

We would like to upload the latest stable point release of systemd 252
to bookworm-p-u. Stable release branches are maintained upstream with
the intention of providing bug fixes only and no compatibility
breakages, and with automated non-trivial CI jobs that also cover
Debian and Ubuntu. I have already uploaded to p-u.

Debdiff attached. No packaging changes besides refreshing patches.

-- 
Kind regards,
Luca Boccassi
diff -Nru systemd-252.17/debian/changelog systemd-252.18/debian/changelog
--- systemd-252.17/debian/changelog	2023-09-20 13:15:14.0 +0100
+++ systemd-252.18/debian/changelog	2023-10-08 16:14:12.0 +0100
@@ -1,3 +1,10 @@
+systemd (252.18-1~deb12u1) bookworm; urgency=medium
+
+  * New upstream version 252.18
+  * Refresh patches
+
+ -- Luca Boccassi   Sun, 08 Oct 2023 16:14:12 +0100
+
 systemd (252.17-1~deb12u1) bookworm; urgency=medium
 
   * New upstream version 252.17. Fixes minor security issue in arm64
diff -Nru systemd-252.17/debian/patches/debian/Don-t-enable-audit-by-default.patch systemd-252.18/debian/patches/debian/Don-t-enable-audit-by-default.patch
--- systemd-252.17/debian/patches/debian/Don-t-enable-audit-by-default.patch	2023-09-20 13:15:08.0 +0100
+++ systemd-252.18/debian/patches/debian/Don-t-enable-audit-by-default.patch	2023-10-08 16:14:01.0 +0100
@@ -29,10 +29,10 @@
  

 diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index bced165..6356be2 100644
+index 3e55795..314f684 100644
 --- a/src/journal/journald-server.c
 +++ b/src/journal/journald-server.c
-@@ -2275,7 +2275,7 @@ int server_init(Server *s, const char *namespace) {
+@@ -2273,7 +2273,7 @@ int server_init(Server *s, const char *namespace) {
  .compress.threshold_bytes = UINT64_MAX,
  .seal = true,
  
diff -Nru systemd-252.17/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch systemd-252.18/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
--- systemd-252.17/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch	2023-09-20 13:15:08.0 +0100
+++ systemd-252.18/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch	2023-10-08 16:14:01.0 +0100
@@ -30,10 +30,10 @@
  systemd.journald.forward_to_kmsg,
  systemd.journald.forward_to_console, and
 diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index 6faf48d..bced165 100644
+index 4c5eadc..3e55795 100644
 --- a/src/journal/journald-server.c
 +++ b/src/journal/journald-server.c
-@@ -2285,6 +2285,7 @@ int server_init(Server *s, const char *namespace) {
+@@ -2283,6 +2283,7 @@ int server_init(Server *s, const char *namespace) {
  .ratelimit_interval = DEFAULT_RATE_LIMIT_INTERVAL,
  .ratelimit_burst = DEFAULT_RATE_LIMIT_BURST,
  
diff -Nru systemd-252.17/debian/patches/debian/Revert-core-set-RLIMIT_CORE-to-unlimited-by-default.patch systemd-252.18/debian/patches/debian/Revert-core-set-RLIMIT_CORE-to-unlimited-by-default.patch
--- systemd-252.17/debian/patches/debian/Revert-core-set-RLIMIT_CORE-to-unlimited-by-default.patch	2023-09-20 13:15:08.0 +0100
+++ systemd-252.18/debian/patches/debian/Revert-core-set-RLIMIT_CORE-to-unlimited-by-default.patch	2023-10-08 16:14:01.0 +0100
@@ -19,7 +19,7 @@
  2 files changed, 1 insertion(+), 21 deletions(-)
 
 diff --git a/src/core/main.c b/src/core/main.c
-index a84fafa..5e61df8 100644
+index c3b1a35..59ea0c6 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1650,24 +1650,6 @@ static void cmdline_take_random_seed(void) {
diff -Nru systemd-252.17/debian/patches/p11kit-switch-to-dlopen.patch systemd-252.18/debian/patches/p11kit-switch-to-dlopen.patch
--- systemd-252.17/debian/patches/p11kit-switch-to-dlopen.patch	2023-09-20 13:15:08.0 +0100
+++ systemd-252.18/debian/patches/p11kit-switch-to-dlopen.patch	2023-10-08 16:14:01.0 +0100
@@ -718,10 +718,10 @@
  }
  
 diff --git a/test/test-functions b/test/test-functions
-index 4bdd2a9..f0423dd 100644
+index f801d49..9b9ddcb 100644
 --- a/test/test-functions
 +++ b/test/test-functions
-@@ -1356,7 +1356,7 @@ install_missing_libraries() {
+@@ -1360,7 +1360,7 @@ install_missing_libraries() {
  local lib path
  # A number of dependencies is now optional via dlopen, so the install
  # script will not pick them up, since it looks at linkage.
@@ -730,7 +730,7 @@
  ddebug "Searching for $lib via pkg-config"
  if pkg-config --exists "$lib"; then
  path="$(pkg-config --variable=libdir "$lib")"
-@@ -1368,6 +1368,10 @@ install_missing_libraries() {
+@@ -1372,6 +1372,10 @@ install_missing_libraries() {
  if ! [[ ${lib} =~ ^lib ]]; then
  lib="lib${lib}"
   

Bug#738839: Upstream link dead

[Raúl Sánchez Siles]

  Hello:

  I wanted to state that upstream link [1] is no longer valid.

[1] https://github.com/np1/mps[1]

  May this one be closed?

  Best Regards,
-- 
Rául Sánchez Siles


[1] https://github.com/np1/mps


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

Bug#1053680: RFS: streamlink/6.2.1-1~bpo12+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bookworm-backports repository.

* Package name: streamlink
  Version : 6.2.1-1~bpo12+1
  Upstream Author : Streamlink Team
* URL : https://streamlink.github.io/
* License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  Section : python

It builds those binary packages:

 python3-streamlink - Python module for extracting video streams
from various websites
 streamlink - CLI for extracting video streams from various
websites to a video player

To access further information about this package, please visit the
following URL:
 https://mentors.debian.net/package/streamlink


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

 dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.2.1-1~bpo12+1.dsc



Differences from testing package (6.2.1-1):
  * d/control,rules: remove doc package because of missing dependencies
on bookworm.
  * d/patches: remove webbrowser tests which require pytest-trio which
is not available on bookworm.



Changes since the previous backported version in bookworm:
streamlink (6.2.1-1~bpo12+1) bookworm-backports; urgency=medium

  * Rebuild for bookworm-backports.

 -- Alexis Murzeau   Wed, 04 Oct 2023 22:57:03 +0200

streamlink (6.2.1-1) unstable; urgency=medium

  * d/README.source: update license check and patches update instructions
  * New upstream version 6.2.1
  * d/patches: update and remove useless patch about furo

 -- Alexis Murzeau   Wed, 04 Oct 2023 22:35:26 +0200


Regards,
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|

Bug#1053480: Reopening

[Carles Pina i Estany]

I'm reopening the bug because I'm just going to do the upload to
mentors.debian.org. If the bug is closed it shows a warning.

If this is not the correct procedure apologies, send me a link please
with the correct steps.

Thanks!

-- 
Carles Pina i Estany
https://carles.pina.cat


signature.asc
Description: PGP signature

Bug#1052973: marked as done (octave-image: FTBFS: make: *** [debian/rules:12: binary] Error 1)

[Rafael Laboissière]

* Sébastien Villemot  [2023-10-07 08:23]:


Hi Rafael,

Le samedi 07 octobre 2023 à 14:15 +0200, Rafael Laboissière a écrit :

I have a question for the Debian Octave Group, related to Bug#1052973,
which has been fixed in version 8.3.0-3 of octave-dev. This bug was
preventing the building of the octave-image package. Should we include
octave-dev >= 8.3.0-3 in Build-Depends of the otave-image package ?


I would say no.

If every time that a bug is fixed in a dependency, we were to bump the 
version requirement, then we would basically always depend on the 
latest version of every package.


Ok, thanks for the advise.

Also, it may be possible that octave-image builds against an old 
version of octave-dev that was not affected by the bug.


Apparently (but I did not check it thoroughly) , the “bug” in mkoctifle 
was always there, but has only been exposed when the Debian build tools 
started injecting some new -f* options into CFLAGS that was propagated 
into the call of mkoctfile. This confuses mkoctfile's options parser, 
resulting into a wrong behavior.


Best,

Rafael Laboissière

Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required

[Jonathan Hettwer]

Package: partman-crypto
Version: 121
Severity: normal
Tags: d-i
X-Debbugs-Cc: j24...@gmail.com

Dear Maintainer,

The `crypto_check_mountpoints` script prevents you from setting up an
encrypted root filesystem without an additional unencrypted /boot
filesystem.
While this may be a requirement for e.g. grub2, it is not
necessarily required when not using grub2 but using UKIs to build EFI
executables that can directly mount the encrypted root filesystem.
While UKIs aren't currently supported, I would still expect partman-crypto
to let me partition an encrypted root filesystem without separate /boot
filesystem, at least after having ignored the warnings or in combination
with the `nobootloader` udeb.

I would suggest letting users ignore the warning and continue if they
really want to, similar to the warning by LVM2.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy

Bug#1053677: base-files: /var/lock points to non-existing /run/lock

[Diederik de Haas]

Package: base-files
Version: 13
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm creating a script to build an image where I essentially do this:
- - Create base system with debootstrap (minbase variant)
- - Install aptitude
- - Use aptitude to install more packages

And then I noticed the following in the log file:
```sh
E: Could not open lock file /var/lock/aptitude - open (2: No such file or 
directory)
E: Could not initialize dependency cache
...
W: Could not lock the cache file; this usually means that dpkg or another apt
tool is already installing packages. Opening in read-only mode; any changes you
make to the states of packages will NOT be preserved!
```

So I modified my script to first list the contents of `/run` and `/var`:

```sh
ls -lh /run:
total 0
drwxr-xr-x 4 root root 160 Oct  8 13:16 host
ls -lh /var:
total 36K
drwxr-xr-x 2 root root  4.0K Jun 11 15:00 backups
drwxr-xr-x 5 root root  4.0K Oct  8 13:11 cache
drwxr-xr-x 8 root root  4.0K Oct  8 13:16 lib
drwxrwsr-x 2 root staff 4.0K Jun 11 15:00 local
lrwxrwxrwx 1 root root 9 Oct  8 13:12 lock -> /run/lock
drwxr-xr-x 4 root root  4.0K Oct  8 13:15 log
drwxrwsr-x 2 root mail  4.0K Oct  8 13:12 mail
drwxr-xr-x 2 root root  4.0K Oct  8 13:12 opt
lrwxrwxrwx 1 root root 4 Oct  8 13:12 run -> /run
drwxr-xr-x 2 root root  4.0K Oct  8 13:12 spool
drwxrwxrwt 2 root root  4.0K Jun 11 15:00 tmp
```

So `/var/lock` points to `/run/lock` ... which doesn't exist.
And that results in errors and a warning from aptitude with potentially
some serious consequences.


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 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 base-files depends on:
ii  gawk [awk]  1:5.2.1-2
ii  mawk [awk]  1.3.4.20230808-1

base-files recommends no packages.

base-files suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZSLSxQAKCRDXblvOeH7b
bjVhAQDi4c3eNjc46q5SwyUGAEOw2GYNeDCv8YaQQNzd8DJQvgEAkrLv9MZT7Poi
wNMhu8033wGVsGwn4RvoVhA509y8VwA=
=jW5K
-END PGP SIGNATURE-

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Nilesh Patra]

Hello,

On 10/8/23 17:22, Rafael Laboissière wrote:

Ok, I tried to fix the building problem by including python3-h5py, alongside 
with python3-h5py-mpi, into Build-Depends, as suggested by Drew, but the xmds2 
package FTBFS.

Here is a way to reproduce the problem without building the package:

   $ dpkg -l python3-h5py\*
   Desired=Unknown/Install/Remove/Purge/Hold
   | 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
   |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
   ||/ Name    Version  Architecture Description
   
+++-===---===
   ii  python3-h5py    3.9.0-3  all  general-purpose Python 
interface to hdf5
   ii  python3-h5py-mpi    3.9.0-3  amd64    general-purpose Python 
interface to hdf5 (Python 3 MPI)
   un  python3-h5py-serial       (no description available)
   $ echo 'import h5py' | python3
   Traceback (most recent call last):
     File "", line 1, in 
     File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 21, in 

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

Is there a way to force h5py to import _debian_h5py_serial instead of 
_debian_h5py_mpi, via the generic h5py namespace?


Drew would probably answer that question better but from taking a brief look, 
it seems to be on expected lines.
This should work if you run it explicitly with mpi.

$ mpirun -n 1 python3 -c "import h5py" && echo "true"
true

or with setting the MPI var manually.

$ OMPI_COMM_WORLD_SIZE=1 python3 -c "import h5py" && echo "true"
true

If you want the _debian_h5py_serial interface then you need python3-h5py-serial 
and the B-D (and Depends) on h5py-mpi
should be dropped which would mean this package does not need the -mpi package.

Otherwise, a (unreliable) hack that you could do it that add a B-D on h5py 
*before* mpi and then -serial should also be installed (at least on my env).

If the code really needs h5py-mpi, then it should be running the build/tests 
with mpi enabled (via openmpi).
At least that's the impression I get from reading.

https://sources.debian.org/src/h5py/3.9.0-3/debian/README.Debian/

This patch gets the package building for me with h5py-mpi+h5py, but not sure if 
it is the right thing to do -- please verify for yourself as package maintainer 
:)

--- a/xpdeint/XSILFile.py
+++ b/xpdeint/XSILFile.py
@@ -31,6 +31,9 @@
 
 numpy = None
 
+# Set env var to use h5py-mpi

+os.environ['OMPI_COMM_WORLD_SIZE'] = '1'
+
 def require_h5py():
   global h5py
   if not h5py:

Bug#1051204: O: urlview -- Extracts URLs from text

[наб]

Control: retitle -1 ITA: urlview -- Extracts URLs from text

Version 1b-1 uploaded to https://mentors.debian.net/package/urlview/,
with thanks to Emanuele for process clarification.


signature.asc
Description: PGP signature

Bug#1053676: Error is script: /usr/bin/ucf: 444: [: missing ]

[Volker Theile]

Package: ucf
Version: 3.0043

Today i realized this error while upgrading my Debian 11 system with the 
latest packages:


Setting up openssh-sftp-server (1:8.4p1-5+deb11u2) ...
Setting up openssh-server (1:8.4p1-5+deb11u2) ...
grep: ]: No such file or directory
/usr/bin/ucf: 444: [: missing ]

Creating config file /etc/ssh/sshd_config.distrib with new version
rescue-ssh.target is a disabled or a static unit, not starting it.

===

# dpkg -l | grep ucf
ii  ucf 3.0043   all  Update 
Configuration File(s): preserve user changes to config files


The issue looks like 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979354


Regards
Volker


OpenPGP_0x01D5A46183265B8C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052429: snapd-glib: FTBFS on riscv64

[Bo YU]

Source: snapd-glib
Version: 1.63-5
Followup-For: Bug #1052429
Tags: patch

Dear Maintainer,

I have updated the libsnapd-qt-2-1.symbols and I can confirm the patch
to fix the ftbfs issue on riscv64. Given that blocks many packages for
riscv64 official rebootstrap, could you consider apply it on next
upload? thanks.

BR,
Bo

-- 
Regards,
--
  Bo YU

diff -Nru snapd-glib-1.63/debian/changelog snapd-glib-1.63/debian/changelog
--- snapd-glib-1.63/debian/changelog2023-01-28 03:50:10.0 +0800
+++ snapd-glib-1.63/debian/changelog2023-10-08 15:54:38.0 +0800
@@ -1,3 +1,10 @@
+snapd-glib (1.63-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update libsnapd-qt-2-1.symbols. (Closes: #1052429)
+
+ -- Bo YU   Sun, 08 Oct 2023 15:54:38 +0800
+
 snapd-glib (1.63-5) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff -Nru snapd-glib-1.63/debian/libsnapd-qt-2-1.symbols 
snapd-glib-1.63/debian/libsnapd-qt-2-1.symbols
--- snapd-glib-1.63/debian/libsnapd-qt-2-1.symbols  2022-12-09 
04:45:52.0 +0800
+++ snapd-glib-1.63/debian/libsnapd-qt-2-1.symbols  2023-10-08 
15:21:09.0 +0800
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 1.63 amd64 arm64 armel armhf hppa i386 ia64 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
+# SymbolsHelper-Confirmed: 1.63 alpha amd64 arm64 armel armhf hppa i386 ia64 
loong64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
 libsnapd-qt-2.so.1 libsnapd-qt-2-1 #MINVER#
 * Build-Depends-Package: libsnapd-qt-dev
  _Z17callback_data_newPv@Base 1.60
@@ -901,8 +901,8 @@
  (optional=templinst)_ZN5QListI8QVariantE6appendERKS0_@Base 1.58
  (optional=templinst)_ZN5QListI8QVariantED1Ev@Base 1.58
  (optional=templinst)_ZN5QListI8QVariantED2Ev@Base 1.58
- (arch=!amd64 !arm64 !armel !armhf !hppa !i386 !ia64 !mips64el !powerpc !ppc64 
!ppc64el !riscv64 !s390x !sh4 !sparc64 !x32)_ZN7QStringC1ERKS_@Base 1.63
- (arch=!amd64 !arm64 !armel !armhf !hppa !i386 !ia64 !mips64el !powerpc !ppc64 
!ppc64el !riscv64 !s390x !sh4 !sparc64 !x32)_ZN7QStringC2ERKS_@Base 1.63
+ (arch=!alpha !amd64 !arm64 !armel !armhf !hppa !i386 !ia64 !m68k !mips64el 
!powerpc !ppc64 !ppc64el !s390x !sh4 !sparc64 !x32)_ZN7QStringC1ERKS_@Base 1.63
+ (arch=!alpha !amd64 !arm64 !armel !armhf !hppa !i386 !ia64 !m68k !mips64el 
!powerpc !ppc64 !ppc64el !s390x !sh4 !sparc64 !x32)_ZN7QStringC2ERKS_@Base 1.63
  _ZN7QStringD1Ev@Base 1.58
  _ZN7QStringD2Ev@Base 1.58
  (optional=templinst)_ZN8QMapNodeI7QString8QVariantE14destroySubTreeEv@Base 
1.58


signature.asc
Description: PGP signature

Bug#1053675: mirage: EDIT-function 'ROTATE' and 'FLIP' not working

[karl-heinz.kuenzel]

Package: mirage
Version: 0.11.1-1+b6
Severity: important
X-Debbugs-Cc: karl-heinz.kuen...@web.de

Dear Maintainer,

updating from bullseye to bookworm on two machines here the
EDIT-function 'ROTATE' and 'FLIP' are not not working anymore.



-- 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/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 mirage depends on:
ii  gir1.2-gexiv2-0.10  0.14.0-1+b1
ii  gir1.2-gtk-3.0  3.24.38-2~deb12u1
ii  libc6   2.36-9+deb12u3
ii  libx11-62:1.8.4-2+deb12u2
ii  python3 3.11.2-1+b1
ii  python3-cairo   1.20.1-5+b1
ii  python3-gi  3.42.2-3+b1
ii  python3-gi-cairo3.42.2-3+b1

mirage recommends no packages.

Versions of packages mirage suggests:
ii  gimp 2.10.34-1
pn  imagemagick  

-- no debconf information

Bug#1053589: RFP: rust-matchit -- high performance, zero-copy URL router

[Reinhard Tartler]

Indeed, allow prerelease does seem to help. Debcargo still produces the same 
message but carries on with generating the package

Thanks 

On October 8, 2023 9:41:44 AM EDT, Jonas Smedegaard  wrote:
>Quoting Reinhard Tartler (2023-10-08 15:24:26)
>> On 10/7/23 2:25 AM, Jonas Smedegaard wrote:
>> > Package: wnpp
>> > Severity: wishlist
>> > X-Debbugs-Cc: Reinhard Tartler 
>> > 
>> > * Package name: rust-matchit
>> >Version : 0.7.3
>> >Upstream Contact: Ibraheem Ahmed 
>> > * URL : https://github.com/ibraheemdev/matchit
>> > * License : BSD-3-Clause and Expat
>> >Programming Lang: Rust
>> >Description : high performance, zero-copy URL router
>> > 
>> >   matchit is a high performance, zero-copy URL router,
>> >   taking advantage of the fact
>> >   that URL routes generally follow a hierarchical structure,
>> >   allowing to reduce the route search to a small number of branches.
>> > 
>> > This package is needed for rust-axum (bug#1052404).
>> > 
>> 
>> while trying to package this with debcargo, I'm seeing this error message:
>> 
>> $ REALVER=0.7.3 ./update.sh matchit
>>  Updating crates.io index
>> debcargo failed: Cannot represent prerelease part of dependency: gonzales 
>> Comparator { op: Caret, major: 0, minor: Some(0), patch: Some(3), pre: 
>> Prerelease("beta") }
>> Command failed. If the patches failed to apply, to rebase them, run:
>> cd /srv/scratch/packages/rust/debcargo-conf/build/matchit
>> quilt pop -a -f
>> rm -rf .pc
>> ln -s /srv/scratch/packages/rust/debcargo-conf/src/matchit/debian/patches
>> quilt push --fuzz=0 -a -f
>> emacsclient 
>> quilt refresh
>> 
>> I guess this is because of this line:
>> 
>> https://github.com/ibraheemdev/matchit/blob/64af4bd02757c7d12412d871c3143b18de60e9df/Cargo.toml#L21
>> 
>> gonzales = "0.0.3-beta"
>> 
>> 
>> How to package this? Does 'debcargo' need a fix?
>
>It seems from the error message that debcargo is well aware of its
>inability to handle crates containing a prerelease component.
>
>It seems from notes in source that you can gamble and hope for the best
>by somehow setting some "allow_prerelease_deps" flag:
>https://sources.debian.org/src/rust-debcargo/2.6.0-3/src/debian/dependency.rs/?hl=187#L187
>
>
> - Jonas
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#1053674: RM: g3dviewer -- ROM; abandoned upstream; depends on gtk2

[Sven Eckelmann]

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

g3dviewer is dead upstream. It depends on gtk2 + libglade2 + libgtkglext1 - 
which are all deprecated.

g3dviewer has no reverse dependencies and a low popcon.


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

Bug#1040679: bullseye-pu: package node-dottie/2.0.2-4+deb11u1

[Yadd]

On 10/8/23 16:10, Jonathan Wiltshire wrote:

Hi,

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


Sorry, I was travelling. I just pushed the update

Thanks!

Bug#1036977: bullseye-pu: package jqueryui/1.12.1+dfsg-8+deb11u2

[Yadd]

On 10/8/23 16:04, Jonathan Wiltshire wrote:

Hi,

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


Sorry, I was travelling. I just pushed the update

Thanks!

Bug#1036975: bullseye-pu: package node-url-parse/1.5.3-1+deb11u2

[Yadd]

On 10/8/23 16:03, Jonathan Wiltshire wrote:

Hi,

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


Sorry, I was travelling. I just pushed the update

Thanks!

Bug#1034665: bullseye-pu: package node-xml2js/0.2.8-1+deb11u1

[Yadd]

On 10/8/23 15:55, Jonathan Wiltshire wrote:

Hi,

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


Sorry, I was travelling. I just pushed the update

Thanks!

Bug#1053673: RM: libwnck -- RoQA; leaf library; depends on gtk2

[Bastian Germann]

Source: libwnck
Severity: serious
Version: 2.30.7-6

Please remove libwnck. It does not have any reverse dependencies anymore and 
depends on the obsolete gtk2.
I am going to file a RM bug when this is autoremoved from testing.

Bug#1052055: Webkit output fully white

[R Pi]

Hello Berto,

Yes I am using WebKitGTK 2.42.1-2!

apt-cache policy libwebkit2gtk-4.0-dev
libwebkit2gtk-4.0-dev:
  Installed: 2.42.1-2+b1
  Candidate: 2.42.1-2+b1

Here's the output from webkit://gpu

{
"Version Information": {
"WebKit version": "WebKitGTK 2.42.1 (tarball)",
"Operating system": "Linux 6.5.0-1-amd64 #1 SMP
PREEMPT_DYNAMIC Debian 6.5.3-1 (2023-09-13) x86_64",
"Desktop": "GNOME",
"Cairo version": "1.18.0 (build) 1.18.0 (runtime)",
"GStreamer version": "1.22.6 (build) GStreamer 1.22.6 (runtime)",
"GTK version": "3.24.38 (build) 3.24.38 (runtime)"
},
"Display Information": {
"Type": "X11",
"Screen geometry": "0,0 3840x1080",
"Screen work area": "0,32 3840x1016",
"Depth": "24",
"Bits per color component": "8",
"DPI": "96",
"DRM Device": "/dev/dri/card0",
"DRM Render Node": "/dev/dri/renderD128"
},
"API": "OpenGL (libepoxy)",
"Hardware Acceleration Information": {
"Policy": "always",
"WebGL enabled": "Yes",
"Renderer": "XWindow",
"Native interface": "None"
},
"Hardware Acceleration Information (Render process)": {
"GL_RENDERER": "NVIDIA GeForce GTX 1070/PCIe/SSE2",
"GL_VENDOR": "NVIDIA Corporation",
"GL_VERSION": "OpenGL ES 3.2 NVIDIA 525.125.06",
"GL_SHADING_LANGUAGE_VERSION": "OpenGL ES GLSL ES 3.20",
"GL_EXTENSIONS": "GL_EXT_base_instance
GL_EXT_blend_func_extended GL_EXT_blend_minmax GL_EXT_buffer_storage
GL_EXT_clear_texture GL_EXT_clip_control GL_EXT_clip_cull_distance
GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float
GL_EXT_conservative_depth GL_EXT_copy_image GL_EXT_depth_clamp
GL_EXT_debug_label GL_EXT_discard_framebuffer
GL_EXT_disjoint_timer_query GL_EXT_draw_buffers_indexed
GL_EXT_draw_elements_base_vertex GL_EXT_EGL_image_array
GL_EXT_EGL_image_storage GL_EXT_EGL_image_external_wrap_modes
GL_EXT_float_blend GL_EXT_frag_depth GL_EXT_geometry_point_size
GL_EXT_geometry_shader GL_EXT_gpu_shader5 GL_EXT_map_buffer_range
GL_EXT_multi_draw_indirect GL_EXT_multisample_compatibility
GL_EXT_multisampled_render_to_texture
GL_EXT_multisampled_render_to_texture2
GL_EXT_multiview_texture_multisample GL_EXT_multiview_timer_query
GL_EXT_occlusion_query_boolean GL_EXT_polygon_offset_clamp
GL_EXT_post_depth_coverage GL_EXT_primitive_bounding_box
GL_EXT_raster_multisample GL_EXT_render_snorm GL_EXT_robustness
GL_EXT_separate_shader_objects GL_EXT_shader_group_vote
GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix
GL_EXT_shader_io_blocks GL_EXT_shader_non_constant_global_initializers
GL_EXT_shader_texture_lod GL_EXT_shadow_samplers GL_EXT_sparse_texture
GL_EXT_sparse_texture2 GL_EXT_sRGB GL_EXT_sRGB_write_control
GL_EXT_tessellation_point_size GL_EXT_tessellation_shader
GL_EXT_texture_border_clamp GL_EXT_texture_buffer
GL_EXT_texture_compression_bptc GL_EXT_texture_compression_dxt1
GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map_array GL_EXT_texture_filter_anisotropic
GL_EXT_texture_filter_minmax GL_EXT_texture_format_BGRA
GL_EXT_texture_mirror_clamp_to_edge GL_EXT_texture_norm16
GL_EXT_texture_query_lod GL_EXT_texture_rg GL_EXT_texture_shadow_lod
GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode
GL_EXT_texture_storage GL_EXT_texture_view
GL_EXT_draw_transform_feedback GL_EXT_unpack_subimage
GL_EXT_window_rectangles GL_KHR_context_flush_control GL_KHR_debug
GL_EXT_memory_object GL_EXT_memory_object_fd
GL_NV_memory_object_sparse GL_KHR_parallel_shader_compile
GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness
GL_EXT_semaphore GL_EXT_semaphore_fd GL_NV_timeline_semaphore
GL_KHR_shader_subgroup GL_KHR_texture_compression_astc_ldr
GL_KHR_texture_compression_astc_sliced_3d
GL_KHR_texture_compression_astc_hdr GL_NV_bgr GL_NV_bindless_texture
GL_NV_blend_equation_advanced GL_NV_blend_equation_advanced_coherent
GL_NVX_blend_equation_advanced_multi_draw_buffers
GL_NV_blend_minmax_factor GL_NV_clip_space_w_scaling
GL_NV_conditional_render GL_NV_conservative_raster
GL_NV_conservative_raster_pre_snap_triangles GL_NV_copy_buffer
GL_NV_copy_image GL_NV_draw_buffers GL_NV_draw_instanced
GL_NV_draw_texture GL_NV_draw_vulkan_image
GL_NV_EGL_stream_consumer_external GL_NV_explicit_attrib_location
GL_NV_fbo_color_attachments GL_NV_fill_rectangle
GL_NV_fragment_coverage_to_color GL_NV_fragment_shader_interlock
GL_NV_framebuffer_blit GL_NV_framebuffer_mixed_samples
GL_NV_framebuffer_multisample GL_NV_generate_mipmap_sRGB
GL_NV_geometry_shader_passthrough GL_NV_instanced_arrays
GL_NV_internalformat_sample_query GL_NV_gpu_shader5
GL_NV_image_formats GL_NV_memory_attachment
GL_NV_occlusion_query_samples GL_NV_non_square_matrices
GL_NV_pack_subimage GL_NV_packed_float GL_NV_packed_float_linear
GL_NV_path_rendering GL_NV_path_rendering_shared_edge
GL_NV_pixel_buffer_object GL_NV_polygon_mode GL_NV_read_buffer
GL_NV_read_depth 

Bug#1053657: please retain bug metadata

[Helmut Grohne]

Control: reassign -1 dhcpcd-base
Control: found -1 9.4.1-24~deb12u2
Control: severity -1 serious
Control: tags -1 + bookworm

Please do not break the bug metadata. As you reassigned the bug, dumat
will no longer associate it and will file a duplicate. That's not what
you want.

I don't like playing severity pingpong, but this bug really is
explicitly release-critical as has been stated in
https://lists.debian.org/e1ocdqk-0005ge...@respighi.debian.org.

I have added a bookworm tag such that it does not affect any other
release and should not cause any testing removal or similar.

Helmut

Bug#1041765: nextcloud-desktop: Tray icon no longer works with gnome + indicator extension

[Hefee]

Control: reassign -1 gnome-shell-extension-appindicator
Control: affects -1 nextcloud-desktop
Control: forwarded -1 
https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/232

The problem is inside the AppIdicator extension than in Nextcloud.
I found several issues pointing to gnome shell extension.

Regards,

hefee

--


On Sonntag, 23. Juli 2023 10:59:42 CEST you wrote:
> Package: nextcloud-desktop
> Version: 3.9.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> since installing nextcloud-desktop 3.9, the systray icon no longer works as
> expected in Gnome (with the AppIndicator extension): it shows shows three
> white dots instead of the nextcloud icon.
> Nextcloud shows everything as fully synced, so I am fairly sure that these
> are the three dots Gnome shows when it cannot find the icon. However, I am
> not sure why the icon can no longer be found -- it used to work fine before
> I did a big "apt upgrade" yesterday.
> 
> Here's another report of the same problem, with a screenshot:
> https://forum.manjaro.org/t/nextcloud-client-icon-is-not-showing-correctly/1
> 38545
> 
> Kind regards,
> Ralf
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_DIE, TAINT_WARN
> 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 nextcloud-desktop depends on:
> ii  libc6  2.37-5
> ii  libcloudproviders0 0.3.1-2
> ii  libgcc-s1  13.1.0-6
> ii  libglib2.0-0   2.74.6-2
> ii  libkf5archive5 5.107.0-1
> ii  libnextcloudsync0  3.9.0-1
> ii  libqt5core5a   5.15.8+dfsg-12
> ii  libqt5dbus55.15.8+dfsg-12
> ii  libqt5gui5 5.15.8+dfsg-12
> ii  libqt5keychain10.14.1-1
> ii  libqt5network5 5.15.8+dfsg-12
> ii  libqt5qml5 5.15.8+dfsg-3
> ii  libqt5quick5   5.15.8+dfsg-3
> ii  libqt5quickcontrols2-5 5.15.8+dfsg-2
> ii  libqt5sql5-sqlite  5.15.8+dfsg-12
> ii  libqt5svg5 5.15.8-3
> ii  libqt5webenginecore5   5.15.13+dfsg-1~deb12u1
> ii  libqt5webenginewidgets55.15.13+dfsg-1~deb12u1
> ii  libqt5widgets5 5.15.8+dfsg-12
> ii  libstdc++6 13.1.0-6
> ii  nextcloud-desktop-common   3.9.0-1
> ii  nextcloud-desktop-l10n 3.9.0-1
> ii  qml-module-qt-labs-platform5.15.8+dfsg-2
> ii  qml-module-qtgraphicaleffects  5.15.8-2
> ii  qml-module-qtqml   5.15.8+dfsg-3
> ii  qml-module-qtqml-models2   5.15.8+dfsg-3
> ii  qml-module-qtquick-controls2   5.15.8+dfsg-2
> ii  qml-module-qtquick-dialogs 5.15.8-2
> ii  qml-module-qtquick-layouts 5.15.8+dfsg-3
> ii  qml-module-qtquick-window2 5.15.8+dfsg-3
> ii  qml-module-qtquick25.15.8+dfsg-3
> 
> Versions of packages nextcloud-desktop recommends:
> ii  nextcloud-desktop-doc  3.9.0-1
> 
> nextcloud-desktop suggests no packages.
> 
> -- no debconf information



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

Bug#967358: g3dviewer: depends on deprecated GTK 2

[Bastian Germann]

Hi Sven,

I suggest to remove g3dviewer from Debian. It is one of a few applications that 
depends on gtkglext.
It also has a low popcon.

Thanks for the consideration,
Bastian

Bug#1053589: RFP: rust-matchit -- high performance, zero-copy URL router

[Reinhard Tartler]

On 10/7/23 2:25 AM, Jonas Smedegaard wrote:

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Reinhard Tartler 

* Package name: rust-matchit
   Version : 0.7.3
   Upstream Contact: Ibraheem Ahmed 
* URL : https://github.com/ibraheemdev/matchit
* License : BSD-3-Clause and Expat
   Programming Lang: Rust
   Description : high performance, zero-copy URL router

  matchit is a high performance, zero-copy URL router,
  taking advantage of the fact
  that URL routes generally follow a hierarchical structure,
  allowing to reduce the route search to a small number of branches.

This package is needed for rust-axum (bug#1052404).



while trying to package this with debcargo, I'm seeing this error message:

$ REALVER=0.7.3 ./update.sh matchit
Updating crates.io index
debcargo failed: Cannot represent prerelease part of dependency: gonzales Comparator { 
op: Caret, major: 0, minor: Some(0), patch: Some(3), pre: Prerelease("beta") }
Command failed. If the patches failed to apply, to rebase them, run:
cd /srv/scratch/packages/rust/debcargo-conf/build/matchit
quilt pop -a -f
rm -rf .pc
ln -s /srv/scratch/packages/rust/debcargo-conf/src/matchit/debian/patches
quilt push --fuzz=0 -a -f
emacsclient 
quilt refresh

I guess this is because of this line:

https://github.com/ibraheemdev/matchit/blob/64af4bd02757c7d12412d871c3143b18de60e9df/Cargo.toml#L21

gonzales = "0.0.3-beta"


How to package this? Does 'debcargo' need a fix?

-rt

Bug#1052690: grub2: post-install script overrides manual changes to GRUB_DISABLE_OS_PROBER

[Jordi Bosveld]

Hello all,

It seems that the debconf setting 'grub2/enable_os_prober' gets reset to 
false every time the package is reconfigured, possibly as part of a 
package upgrade or reinstallation. When one invokes 'dpkg-reconfigure 
grub-efi-amd64' (or grub-pc etc.) the previously chosen answer to the 
'enable_os_prober' query is forgotten and the preselected answer is now 
'No'. When dpkg-reconfigure is run with the '-phigh' option this happens 
silently and os-prober is once again disabled. The same occurs when 
reinstalling or upgrading the corresponding grub package.



Additional information: It turns out that the post-install script
patches /etc/default/grub here:
Yes, but by the time this postinst script is executed, debconf will have 
already been misconfigured and the 'db_get grub2/enable_os_prober' 
command as seen on line 401 will receive a possibly incorrect 'false'.


The double negative used in the configuration is a bit confusing, 
especially once you deal with a commented line (meaning its contents are 
disabled) declaring that the variable that dictates whether or not to 
disable a certain setting should be set to disabled. The package script 
'config' warns the reader 'Watch for the inverted logic here', and 
ironically this is where the bug is at. I have attached a patch that 
will rectify this issue. For simplicity I decided to compare the config 
variable GRUB_DISABLE_OS_PROBER from /etc/default/grub to 'false', i.e. 
a value of exactly 'false' will set the 'grub2/enable_os_prober' debconf 
setting to 'true' and all other contents will result in 
'grub2/enable_os_prober = false'. One could possibly expand the check to 
include 0, no, False, FALSE and whatnot, but that is ultimately up to 
the maintainers and I wanted to keep things simple. With this patch 
applied the previously chosen answer is remembered and a 
(re)installation or reconfiguration no longer changes the setting. Also, 
manually uncommenting the line with GRUB_DISABLE_OS_PROBER=false (as 
mentioned in the package changelog) will now result in debconf properly 
changing the 'grub2/enable_os_prober' setting to 'true' the next time it 
is invoked, so on upgrades and such that line will no longer be 
rewritten into something that disables os-prober. Changing it to 
anything other than 'false' will result in 'grub2/enable_os_prober' to 
be set to 'false', and consequently the line containing 
GRUB_DISABLE_OS_PROBER=whatever in /etc/default/grub will get rewritten 
to the default commented '#GRUB_DISABLE_OS_PROBER=false', which means 
the setting will now default to 'true', as before.


--
Kind regards,

Jordi Bosveld
diff -ur grub2-2.12~rc1.orig/debian/config.in grub2-2.12~rc1/debian/config.in
--- grub2-2.12~rc1.orig/debian/config.in	2023-10-08 13:31:00.421268494 +0200
+++ grub2-2.12~rc1/debian/config.in	2023-10-08 13:31:49.889261283 +0200
@@ -60,7 +60,11 @@
 fi
 # Watch for the inverted logic here...
 if [ "${GRUB_DISABLE_OS_PROBER+set}" = set ]; then
-  db_set grub2/enable_os_prober "false"
+  if [ "${GRUB_DISABLE_OS_PROBER}" = "false" ]; then
+db_set grub2/enable_os_prober "true"
+  else
+db_set grub2/enable_os_prober "false"
+  fi
 fi
 
 case @PACKAGE@ in

Bug#1053672: Apple copyright notices in test .xlsx files

[Rebecca N. Palmer]

Source: openpyxl
Version: 3.0.9-2
Severity: serious

licensecheck -r --copyright . on openpyxl finds these:

./openpyxl/formatting/tests/data/conditional-formatting.xlsx: UNKNOWN
  [Copyright: 2007 Apple Inc.]
./openpyxl/reader/tests/data/complex-styles.xlsx: UNKNOWN
  [Copyright: 2007 Apple Inc.]

If opened in 'less' these files do contain the text "Copyright 2007 
Apple Inc., all rights reserved.", marked as 'etext'.


However, if opened in LibreOffice, no _obvious_ command displays this 
text.  File > Properties instead displays creation and modification 
dates/authors that match the openpyxl upstream commit dates/authors 
(2012-4), which suggests that these are *not* straightforward copies of 
Apple-owned example files.


Their actual contents are mostly formatting, i.e. they look like 
something created specifically to be a test case for reading formatting, 
or possibly a documentation example for formatting but the above makes 
that less likely, not something copied from real-world use.


Given this, why is that copyright notice there, and what does it imply 
that we should do?  (E.g. does Apple Numbers automatically copy 
Apple-owned items (e.g. fonts) into files it creates?  If so, is there a 
way to remove these items to get a Free file?)

Bug#927228: the file rotation works

[Stéphane Blondon]

After running the loop much more time, the log file has been rotated:

$ ls -lh /var/log/supervisor/
total 53M
-rw-r--r--  1 root root 3,0M  8 oct.  14:33 supervisord.log
-rw-rw-rw-  1 root root  51M 26 sept. 16:55 supervisord.log.1
$ ls -l /var/log/supervisor/
total 54184
-rw-r--r-- 1 root root  3041778  8 oct.  14:33 supervisord.log
-rw-rw-rw- 1 root root 52428822 26 sept. 16:55 supervisord.log.1

It seems the rotation occurs when the size goes from 50 to 51M.

The file rotation works so I think this bug report can be closed with
a 'unreproducible' tag.

-- 
Stéphane

Bug#1053589: RFP: rust-matchit -- high performance, zero-copy URL router

[Jonas Smedegaard]

Quoting Reinhard Tartler (2023-10-08 15:24:26)
> On 10/7/23 2:25 AM, Jonas Smedegaard wrote:
> > Package: wnpp
> > Severity: wishlist
> > X-Debbugs-Cc: Reinhard Tartler 
> > 
> > * Package name: rust-matchit
> >Version : 0.7.3
> >Upstream Contact: Ibraheem Ahmed 
> > * URL : https://github.com/ibraheemdev/matchit
> > * License : BSD-3-Clause and Expat
> >Programming Lang: Rust
> >Description : high performance, zero-copy URL router
> > 
> >   matchit is a high performance, zero-copy URL router,
> >   taking advantage of the fact
> >   that URL routes generally follow a hierarchical structure,
> >   allowing to reduce the route search to a small number of branches.
> > 
> > This package is needed for rust-axum (bug#1052404).
> > 
> 
> while trying to package this with debcargo, I'm seeing this error message:
> 
> $ REALVER=0.7.3 ./update.sh matchit
>  Updating crates.io index
> debcargo failed: Cannot represent prerelease part of dependency: gonzales 
> Comparator { op: Caret, major: 0, minor: Some(0), patch: Some(3), pre: 
> Prerelease("beta") }
> Command failed. If the patches failed to apply, to rebase them, run:
> cd /srv/scratch/packages/rust/debcargo-conf/build/matchit
> quilt pop -a -f
> rm -rf .pc
> ln -s /srv/scratch/packages/rust/debcargo-conf/src/matchit/debian/patches
> quilt push --fuzz=0 -a -f
> emacsclient 
> quilt refresh
> 
> I guess this is because of this line:
> 
> https://github.com/ibraheemdev/matchit/blob/64af4bd02757c7d12412d871c3143b18de60e9df/Cargo.toml#L21
> 
> gonzales = "0.0.3-beta"
> 
> 
> How to package this? Does 'debcargo' need a fix?

It seems from the error message that debcargo is well aware of its
inability to handle crates containing a prerelease component.

It seems from notes in source that you can gamble and hope for the best
by somehow setting some "allow_prerelease_deps" flag:
https://sources.debian.org/src/rust-debcargo/2.6.0-3/src/debian/dependency.rs/?hl=187#L187


 - Jonas

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

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

signature.asc
Description: signature

Bug#1053531: [pkg-gnupg-maint] Bug#1053531: gnupg/gpg-agent/pinentry: timeout

[Werner Koch]

Hi Thorsten,

> distracted by being asked a question, and it had terminated the
> pinentry and agent, asking me for a password on stderr/tty without
> pinentry, but as soon as I went to type it there, it ended up with:

The second one is the usual ssh prompt in a failed ssh-agent.

> IMHO the pinentry form shouldn’t time out (or at least be reasonable
> about it, e.g. time out after one hour, at the earliest, or so).

Put a pinentry-timeout into gpg-agent.conf

--pinentry-timeout n

   This option asks the Pinentry to timeout after n seconds with no user
   input.  The default value of 0 does not ask the pinentry to timeout,
   however a Pinentry may use its own default timeout value in this
   case.  A Pinentry may or may not honor this request.

The default is 60 seconds, iirc. No timeout is not a good idea either
because you will run into a related problem when you request a second
action requiring a pinentry - that will then wait for the already open
pinentry somewhere on another desktop.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature

Bug#1014030: Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1

[Reinhard Tartler]

On 10/8/23 8:01 AM, Jonathan Wiltshire wrote:

Hi,

This request was approved but not uploaded in time for the previous point
release (11.8). Should it be included in 11.9, or should this request be
abandoned and closed?
 
Apologies for dropping the ball here. I've just uploaded conmon 2.0.25+ds1-1.1 to bullseye.


Looking forward to seeing it accepted for 11.9.

-rt

Bug#1053671: usrmerge: drop skip flag, no longer needed

[Luca Boccassi]

Source: usrmerge
X-Debbugs-Cc: hel...@subdivi.de

The buildds are now building on supported chroots, so the flag can be
dropped from the usrmerge/usr-is-merged preinst scripts.

https://lists.debian.org/debian-devel/2023/10/msg00019.html

-- 
Kind regards,
Luca Boccassi


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

Bug#1053670: libreoffice-gtk3: Color changes in Libreoffice Draw stopped working with libreoffice-gtk3 installed

[Kerstin Hoef-Emden]

Package: libreoffice-gtk3
Version: 4:7.4.7-1
Severity: important

Dear Maintainer,


   * What led up to the situation?

Probably an update of libreoffice and its components. I wanted to prepare a
single picture for a presentation with Libreoffice Draw and realized that
changes of text color stopped working. Also filled areas of e.g. circles did
not show the chosen color. Instead all fillings appeared white, colored text
remained black. When scaling the circle or a text box, the color becomes
visible, but after stopping the action, white filling or black text was shown
again. These effects concern only the display on screen. In printouts the
colors are present. In Libreoffice Writer changing the color of texts worked,
but it also does not work in Libreoffice Impress. Also I realized that input
becomes extremely slow, with libreoffice-gtk3 installed. The fan of my cpu
speeds up and letters appear with a long delay while typing in.

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

I purged libreoffice with "apt purge libreoffice*" from the system and
reinstalled it. Thereafter the problem was gone, but the windows and menus had
tiny hardly readable text and low contrast due to a gray background. By
internet search I found the proposal to install libreoffice-gtk3 to solve this
problem. It resulted in readable menus with better contrast, i.e. it looked
like the Libreoffice that I had purged from the system before, but the color
problem returned.

Deinstallation of libreoffice-gtk3 solved the problem, but now the surface of
Libreoffice again is hardly readable.

   * What was the outcome of this action?
   * What outcome did you expect instead?

For sure, that coloring of rectangle or circle areas works again as well as
choosing a color for text different than black.


-- 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/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-gtk3 depends on:
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libepoxy01.5.10-1
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libreoffice-core 4:7.4.7-1
ii  libstdc++6   12.2.0-14
ii  libuno-cppu3 4:7.4.7-1
ii  libuno-cppuhelpergcc3-3  4:7.4.7-1
ii  libuno-sal3  4:7.4.7-1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  uno-libs-private 4:7.4.7-1

Versions of packages libreoffice-gtk3 recommends:
ii  gstreamer1.0-gtk3  1.22.0-5+deb12u1

Versions of packages libreoffice-gtk3 suggests:
pn  libreofficekit-data  

-- no debconf information

Bug#1051070: RM: gtimer -- RoQA; low popcon; depends on gtk2

[Bastian Germann]

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

Please remove gtimer, which does not seem to be used a lot and is unmaintained 
upstream.

Bug#1050359: RM: gpr -- RoQA; dead upstream; depends on gtk2

[Bastian Germann]

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

Please remove gpr. It is dead upstream. The Debian version is essentially a 
fork that is also not updated since 2011.

Bug#1053657: dhcpcd-base has ineffective Replaces due to /usr-merge and looses files in upgrade

[Helmut Grohne]

On Sun, Oct 08, 2023 at 01:42:05PM +0300, Martin-Éric Racine wrote:
> On Sun, 8 Oct 2023 08:15:40 +0200 Helmut Grohne  wrote:
> > Unfortunately, the stable update of dhcpcd5 introduced a regression
> > relevant to upgrades from bullseye. The bullseye dhcpcd5 package
> > contained the files
> >  - /lib/dhcpcd/dhcpcd-hooks/01-test
> >  - /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf
> >  - /lib/dhcpcd/dhcpcd-hooks/30-hostname
> >  - /lib/dhcpcd/dhcpcd-hooks/60-ntp-common.conf
> >  - /lib/dhcpcd/dhcpcd-hooks/62-chrony.conf
> >  - /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
> >  - /lib/dhcpcd/dhcpcd-hooks/68-openntpd.conf
> >  - /lib/dhcpcd/dhcpcd-run-hooks
> > and these have been moved into dhcpcd-base in that particular stable
> > update. The update correctly declares Replaces for this. Unfortunately,
> > it also moves these files from /lib to /usr/lib. Therefore, the declared
> > Replaces have no effect (regarding these files) and as a consequence, an
> > upgrade may delete the affected files.
> 
> That doesn't hold water. Moving files to the base package doesn't delete them.

This issue is specific to /usr-merged systems (and this is mandatory in
bookworm). It cannot be experienced on unmerged installations. In
particular, if you delete the usrmerge package installation from my
reproducer, it no longer reproduces. The problem arises from dpkg not
being aware of wlog /lib/dhcpcd/dhcpcd-run-hooks and
/usr/lib/dhcpcd/dhcpcd-run-hooks being the same file on disk. So when
you unpack the updated dhcpcd-base, it'll replace the affected file, but
not take it over from dhcpcd5 (because it is recorded with a different
name there). As you remove (or upgrade) dhcpcd5, dpkg will delete it -
not realizing that it is deleting a file (with a different name) from
dhcpcd-base.

We have violated a core assumption of dpkg and this is why Replaces have
become insufficient.

> Thus changing fields from what to what?

-Replaces: dhcpcd5 (<< 9.4.1-2)
-Breaks: dhcpcd5 (<< 9.4.1-2)
+Conflicts: dhcpcd5 (<< 9.4.1-2)

The conflict implies a break and since it also prevents concurrent
unpack, no replacement can ever happen.

Helmut

Bug#1039063: Additional stacktrace

[epp]

Attached is an additional stacktrace, occurred a few days prior.



Application: Plasma (plasmashell), signal: Segmentation fault

   PID: 1372 (plasmashell)
   UID: 1000 (epp)
   GID: 1000 (epp)
Signal: 11 (SEGV)
 Timestamp: Tue 2023-10-03 07:32:58 EDT (23s ago)
  Command Line: /usr/bin/plasmashell --no-respawn
Executable: /usr/bin/plasmashell
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service
  Unit: user@1000.service
 User Unit: plasma-plasmashell.service
 Slice: user-1000.slice
 Owner UID: 1000 (epp)
   Boot ID: edb0f13c5cbe4bc08a82da292253faaf
Machine ID: d01c54dc30b84287b2ca7f867d54bb71
  Hostname: upstairs
   Storage: 
/var/lib/systemd/coredump/core.plasmashell.1000.edb0f13c5cbe4bc08a82da292253faaf.1372.169633277800.zst
 (present)
  Size on Disk: 9.7M
   Message: Process 1372 (plasmashell) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-252.12-1~deb12u1.amd64
Module libudev.so.1 from deb systemd-252.12-1~deb12u1.amd64
Stack trace of thread 1808:
#0  0x7f6b40ea9d3c n/a (libc.so.6 + 0x8ad3c)
#1  0x7f6b40e5af32 raise (libc.so.6 + 0x3bf32)
#2  0x7f6b434ecb46 _ZN6KCrash19defaultCrashHandlerEi 
(libKF5Crash.so.5 + 0x5b46)
#3  0x7f6b40e5afd0 n/a (libc.so.6 + 0x3bfd0)
#4  0x7f6b40ea9d3c n/a (libc.so.6 + 0x8ad3c)
#5  0x7f6b40e5af32 raise (libc.so.6 + 0x3bf32)
#6  0x7f6b40e5afd0 n/a (libc.so.6 + 0x3bfd0)
#7  0x7f6b40f1b03f __poll (libc.so.6 + 0xfc03f)
#8  0x7f6b3fd019ae n/a (libglib-2.0.so.0 + 0x549ae)
#9  0x7f6b3fd01acc g_main_context_iteration 
(libglib-2.0.so.0 + 0x54acc)
#10 0x7f6b41309836 
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 (libQt5Core.so.5 + 0x309836)
#11 0x7f6b412b017b 
_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 
0x2b017b)
#12 0x7f6b410cab87 _ZN7QThread4execEv (libQt5Core.so.5 + 
0xcab87)
#13 0x7f6b410cbd43 n/a (libQt5Core.so.5 + 0xcbd43)
#14 0x7f6b40ea8044 n/a (libc.so.6 + 0x89044)
#15 0x7f6b40f285fc n/a (libc.so.6 + 0x1095fc)

Stack trace of thread 1372:
#0  0x7f6b40ea4da6 n/a (libc.so.6 + 0x85da6)
#1  0x7f6b40ea7468 pthread_cond_wait (libc.so.6 + 0x88468)
#2  0x7f6b410d1a2b 
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xd1a2b)
#3  0x7f6b42b28c45 n/a (libQt5Qml.so.5 + 0x328c45)
#4  0x7f6b42aaf841 
_ZN14QQmlTypeLoader4loadEP12QQmlDataBlobNS_4ModeE (libQt5Qml.so.5 + 0x2af841)
#5  0x7f6b42ab0180 
_ZN14QQmlTypeLoader7getTypeERK4QUrlNS_4ModeE (libQt5Qml.so.5 + 0x2b0180)
#6  0x7f6b42a88b34 
_ZN20QQmlComponentPrivate7loadUrlERK4QUrlN13QQmlComponent15CompilationModeE 
(libQt5Qml.so.5 + 0x288b34)
#7  0x7f6b4360634d n/a (libKF5Declarative.so.5 + 0xc34d)
#8  0x7f6b43970c77 _ZN11PlasmaQuick15AppletQuickItem4initEv 
(libKF5PlasmaQuick.so.5 + 0x21c77)
#9  0x7f6b386de29c n/a (plasma_appletscript_declarative.so 
+ 0x1929c)
#10 0x7f6b43972aa1 
_ZN11PlasmaQuick15AppletQuickItem10itemChangeEN10QQuickItem10ItemChangeERKNS1_14ItemChangeDataE
 (libKF5PlasmaQuick.so.5 + 0x23aa1)
#11 0x7f6b43055bed 
_ZN17QQuickItemPrivate9refWindowEP12QQuickWindow (libQt5Quick.so.5 + 0x255bed)
#12 0x7f6b43055baa 
_ZN17QQuickItemPrivate9refWindowEP12QQuickWindow (libQt5Quick.so.5 + 0x255baa)
#13 0x7f6b43055fc4 _ZN10QQuickItem13setParentItemEPS_ 
(libQt5Quick.so.5 + 0x255fc4)
#14 0x7f6b4397fd71 n/a (libKF5PlasmaQuick.so.5 + 0x30d71)
#15 0x5617df413fe6 n/a (plasmashell + 0x53fe6)
#16 0x7f6b412e8f4f n/a (libQt5Core.so.5 + 0x2e8f4f)
#17 0x7f6b412ecd6a _ZN6QTimer7timeoutENS_14QPrivateSignalE 
(libQt5Core.so.5 + 0x2ecd6a)
#18 0x7f6b412dd50d _ZN7QObject5eventEP6QEvent 
(libQt5Core.so.5 + 0x2dd50d)
#19 0x7f6b42162fae 
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 
0x162fae)
#20 0x7f6b412b16f8 
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 
0x2b16f8)
#21 0x7f6b41308c31 _ZN14QTimerInfoList14activateTimersEv 
(libQt5Core.so.5 + 0x308c31)
#22 0x7f6b413094c4 n/a (libQt5Core.so.5 + 0x3094c4)
#23 0x7f6b3fd017a9 g_main_context_dispatch 
(libglib-2.0.so.0 + 0x547a9)
#24 

Bug#1039063: Plasmashell segfaulting upon startup under X11

[edwardp]

I am having a similar issue where plasmashell occasionally segfaults upon
logging into an X11 session under Debian 12. The KDE desktop may or may not
appear first, then displaying the KDE crash reporter, indicating the
stacktraces are not useful and it would not report the crash to KDE.

Attached is a recent stacktrace.






Application: Plasma (plasmashell), signal: Segmentation fault

   PID: 1395 (plasmashell)
   UID: 1000 (epp)
   GID: 1000 (epp)
Signal: 11 (SEGV)
 Timestamp: Sat 2023-10-07 20:16:42 EDT (36s ago)
  Command Line: /usr/bin/plasmashell --no-respawn
Executable: /usr/bin/plasmashell
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service
  Unit: user@1000.service
 User Unit: plasma-plasmashell.service
 Slice: user-1000.slice
 Owner UID: 1000 (epp)
   Boot ID: 847aa52a494d44d9bd644e4bd90078a5
Machine ID: d01c54dc30b84287b2ca7f867d54bb71
  Hostname: upstairs
   Storage: 
/var/lib/systemd/coredump/core.plasmashell.1000.847aa52a494d44d9bd644e4bd90078a5.1395.169672420200.zst
 (present)
  Size on Disk: 7.6M
   Message: Process 1395 (plasmashell) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-252.17-1~deb12u1.amd64
Module libudev.so.1 from deb systemd-252.17-1~deb12u1.amd64
Stack trace of thread 1829:
#0  0x7f232f0a9d3c n/a (libc.so.6 + 0x8ad3c)
#1  0x7f232f05af32 raise (libc.so.6 + 0x3bf32)
#2  0x7f233169db46 _ZN6KCrash19defaultCrashHandlerEi 
(libKF5Crash.so.5 + 0x5b46)
#3  0x7f232f05afd0 n/a (libc.so.6 + 0x3bfd0)
#4  0x7f232f0a9d3c n/a (libc.so.6 + 0x8ad3c)
#5  0x7f232f05af32 raise (libc.so.6 + 0x3bf32)
#6  0x7f232f05afd0 n/a (libc.so.6 + 0x3bfd0)
#7  0x7f232f11d941 pselect (libc.so.6 + 0xfe941)
#8  0x7f232d077a62 n/a (libusbmuxd-2.0.so.6 + 0x2a62)
#9  0x7f232d078e60 n/a (libusbmuxd-2.0.so.6 + 0x3e60)
#10 0x7f232f0a8044 n/a (libc.so.6 + 0x89044)
#11 0x7f232f12861c n/a (libc.so.6 + 0x10961c)

Stack trace of thread 1790:
#0  0x7f232f11b05f __poll (libc.so.6 + 0xfc05f)
#1  0x7f232ded29ae n/a (libglib-2.0.so.0 + 0x549ae)
#2  0x7f232ded2acc g_main_context_iteration 
(libglib-2.0.so.0 + 0x54acc)
#3  0x7f232f509836 
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 (libQt5Core.so.5 + 0x309836)
#4  0x7f232f4b017b 
_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 
0x2b017b)
#5  0x7f232f2cab87 _ZN7QThread4execEv (libQt5Core.so.5 + 
0xcab87)
#6  0x7f23311566d6 n/a (libQt5Quick.so.5 + 0x1566d6)
#7  0x7f232f2cbd43 n/a (libQt5Core.so.5 + 0xcbd43)
#8  0x7f232f0a8044 n/a (libc.so.6 + 0x89044)
#9  0x7f232f12861c n/a (libc.so.6 + 0x10961c)

Stack trace of thread 1410:
#0  0x7f232f11b05f __poll (libc.so.6 + 0xfc05f)
#1  0x7f23318fed12 n/a (libxcb.so.1 + 0xcd12)
#2  0x7f233190107a xcb_wait_for_event (libxcb.so.1 + 0xf07a)
#3  0x7f232a2faf00 n/a (libQt5XcbQpa.so.5 + 0x6cf00)
#4  0x7f232f2cbd43 n/a (libQt5Core.so.5 + 0xcbd43)
#5  0x7f232f0a8044 n/a (libc.so.6 + 0x89044)
#6  0x7f232f12861c n/a (libc.so.6 + 0x10961c)

Stack trace of thread 1799:
#0  0x7f232f0a4da6 n/a (libc.so.6 + 0x85da6)
#1  0x7f232f0a7468 pthread_cond_wait (libc.so.6 + 0x88468)
#2  0x7f232f2d1a2b 
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xd1a2b)
#3  0x7f2331208085 n/a (libQt5Quick.so.5 + 0x208085)
#4  0x7f233120a4b1 n/a (libQt5Quick.so.5 + 0x20a4b1)
#5  0x7f232f2cbd43 n/a (libQt5Core.so.5 + 0xcbd43)
#6  0x7f232f0a8044 n/a (libc.so.6 + 0x89044)
#7  0x7f232f12861c n/a (libc.so.6 + 0x10961c)

Stack trace of thread 1791:
#0  0x7f232f0a4da6 n/a (libc.so.6 + 0x85da6)
#1  0x7f232f0a774c pthread_cond_timedwait (libc.so.6 + 
0x8874c)
#2  0x7f232f2d19bc 
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xd19bc)
#3  0x7f232f2cf0a5 n/a (libQt5Core.so.5 + 0xcf0a5)
#4  0x7f232f2cbd43 n/a (libQt5Core.so.5 + 0xcbd43)
#5  0x7f232f0a8044 n/a (libc.so.6 + 0x89044)
  

Bug#1040679: bullseye-pu: package node-dottie/2.0.2-4+deb11u1

[Jonathan Wiltshire]

Hi,

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

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1053669: thunderbird: primary password not ask on startup - only in safe-mode it works

[Andreas Matthus]

Package: thunderbird
Version: 1:115.3.1-1~deb12u1
Severity: important

Dear Maintainer,

after upgrade to 115.3.1-1~deb12u1 from 102 I have problems by starting
thunderbird: It ask not for primary password but the passwords for all accounts
and calenders. No stored passwords found and not stored private certificates.
All accounts and old mails are seen.
Restart thunderbird shows he same behavior. Disable all plugins the same.

Start in safe-mode an "continue in Troubleshoot Mode" show the question for
primary password first and all works fine (only I can't set the language). Next
start I need this way too. Start in normal mode have the problems above every
time.

with regards



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

Kernel: Linux 6.1.0-12-amd64 (SMP w/12 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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  kdialog  4:22.12.3-1
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u3
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.8-2~deb12u1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1+deb12u2
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libx11-xcb1  2:1.8.4-2+deb12u2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.44.0-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-de-at [hunspell-dictionary]  20161207-11
ii  hunspell-de-ch [hunspell-dictionary]  20161207-11
ii  hunspell-de-de [hunspell-dictionary]  20161207-11
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.8-3
ii  fonts-lyx 2.3.7-1
ii  libgssapi-krb5-2  1.20.1-2

-- Configuration Files:
/etc/apparmor.d/usr.bin.thunderbird changed [not included]

-- debconf-show failed

Bug#1037188: bullseye-pu: package git/2.30.2-1+deb11u3

[Jonathan Wiltshire]

On Thu, Jul 27, 2023 at 03:52:52PM +0200, Andreas Beckmann wrote:
> Control: tag -1 - moreinfo
> 
> On 08/07/2023 19.25, Adam D. Barratt wrote:
> > It looks like not all of the postinst was removed - was that
> > intentional? It's presumably harmless, but now leads to a lintian
> > warning, which is why I noticed. :-)
> 
> That git-el.postinst code was already removed by
>   c4b054cf0e debian: drop support for upgrades from pre-1.7.9.5 versions
> (Mon Dec 28 20:13:48 2020 -0800)
> and I missed the opportunity to simply delete the whole file when I
> backported
>   67b73aadeb debian: remove git-el package (Mon May 31 15:03:12 2021 -0700).
> The remaining bits should be harmless (it's a postinst script for a package
> no longer in d/control), but if you prefer, I can reupload with the cruft
> bits removed, too. Should save a few brain cycles on future updates ;-)

Yes please; I'll reject the existing upload in a moment so you can re-use
the version.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1036977: bullseye-pu: package jqueryui/1.12.1+dfsg-8+deb11u2

[Jonathan Wiltshire]

Hi,

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

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1036975: bullseye-pu: package node-url-parse/1.5.3-1+deb11u2

[Jonathan Wiltshire]

Hi,

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


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1020303: Ping

[Jonathan Wiltshire]

Hi,

On Mon, Jun 26, 2023 at 06:42:18PM +0100, Jonathan Wiltshire wrote:
> On Tue, Mar 21, 2023 at 12:58:31PM +0100, Alberto Gonzalez Iniesta wrote:
> > Hi, all. We're looking forward to uploading the latest CRS package to
> > bullseye-backports, but this will require this pending update to
> > bullseye. Any news on this front?
> 
> Please go ahead.

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

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1

[Jonathan Wiltshire]

Hi,

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


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1023740: bullseye-pu: package python-scciclient/0.8.0-2

[Jonathan Wiltshire]

Hi,

On Tue, Jul 25, 2023 at 09:50:35PM +0100, Jonathan Wiltshire wrote:
> On Wed, Nov 09, 2022 at 01:00:15PM +0100, Thomas Goirand wrote:
> > diff -Nru python-scciclient-0.8.0/debian/changelog 
> > python-scciclient-0.8.0/debian/changelog
> > --- python-scciclient-0.8.0/debian/changelog2019-07-18 
> > 23:52:05.0 +0200
> > +++ python-scciclient-0.8.0/debian/changelog2022-11-09 
> > 12:46:11.0 +0100
> > @@ -1,3 +1,11 @@
> > +python-scciclient (0.8.0-2+deb11u1) buster; urgency=medium
> 
> You want to target bullseye there; otherwise, go ahead.


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


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1029008: Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?

[Jonathan Wiltshire]

On Tue, Jul 25, 2023 at 10:26:06PM +0100, Jonathan Wiltshire wrote:
> On Mon, Jan 16, 2023 at 07:41:21AM +0100, László Böszörményi wrote:
> > On Mon, Jan 16, 2023 at 6:38 AM Salvatore Bonaccorso  
> > wrote:
> > > On Sun, Jan 15, 2023 at 04:57:24PM -0500, Daniel Kahn Gillmor wrote:
> > > > I was looking into CVE-2022-24859 and pypdf2, and trying to figure out
> > > > whether the version in bullseye is still vulnerable, as it appears to be
> > > > according to the security tracker:
> > [...]
> > > It is still unfixed in bullseye TTBOMK, but would not warrant a DSA.
> >  Indeed, it's not yet fixed for Bullseye and doesn't warrant a DSA as
> > the max impact is an infinite loop in the user's own process.
> > 
> > > Can you propose a fix for it with cherry-picking the pull request
> > > changes for the next bullseye point release?
> >  Correct, it needs to go via Bullseye point update. I attached the
> > short change which has the original commit as Salvatore noted.
> 
> Either of the proposed diffs is fine; please go ahead.

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

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1038687: radicale's autopkg tests fail with Python 3.11.4

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/Kozea/Radicale/issues/1336

I told upstream about this.  I suspect the problem is in the server, not
the tests.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034665: bullseye-pu: package node-xml2js/0.2.8-1+deb11u1

[Jonathan Wiltshire]

Hi,

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


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Rafael Laboissière]

Ok, I tried to fix the building problem by including python3-h5py, 
alongside with python3-h5py-mpi, into Build-Depends, as suggested by 
Drew, but the xmds2 package FTBFS.


Here is a way to reproduce the problem without building the package:

  $ dpkg -l python3-h5py\*
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ NameVersion  Architecture Description
  
+++-===---===
  ii  python3-h5py3.9.0-3  all  general-purpose Python 
interface to hdf5
  ii  python3-h5py-mpi3.9.0-3  amd64general-purpose Python 
interface to hdf5 (Python 3 MPI)
  un  python3-h5py-serial   (no description available)
  $ echo 'import h5py' | python3
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 21, in 
  from . import _debian_h5py_serial as _h5py
  ImportError: cannot import name '_debian_h5py_serial' from partially 
initialized module 'h5py' (most likely due to a circular import) 
(/usr/lib/python3/dist-packages/h5py/__init__.py)

Is there a way to force h5py to import _debian_h5py_serial instead of 
_debian_h5py_mpi, via the generic h5py namespace?


Best,

Rafael

* Rafael Laboissière  [2023-10-08 10:27]:


* Nilesh Patra  [2023-10-04 02:24]:


On Sun, 01 Oct 2023 15:25:43 +0200 Drew Parsons  wrote:

Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci

xmds2 Depends: python3-h5py-mpi without depending on python3-h5py

python3-h5py-mpi only provides the h5py._debian_h5py_mpi 
namespace, not h5py.  Hence tests using h5py without specifying 
_debian_h5py_mpi fail.  This is the case with h5py 3.9.0. (Marking 
Severity: serious due to debci failure)


python3-h5py provides the h5py namespace, so if xmds2 strictly 
needs the mpi build, but accessing via the generic h5py namespace, 
then the Depends should specify both packages  Depends: 
python3-h5py python3-h5py-mpi Note there seems to be an 
inconsistency in the xmds2 package configuration. It has MPI 
dependencies (python3-h5py-mpi, also mpi-default-dev, 
libfftw3-mpi-dev), but with respect to hdf5 it has Depends: 
libhdf5-serial-dev Should that instead be Depends: libhdf5-mpi-dev 
?


Seems you're right, taking a brief look at it. I've CC'ed Rafael to further 
comment/upload a fix.

@Rafael, this seems to be the last blocker on h5py transition to 
testing, so prompt action would be really cool!


Thanks to Drew for the bug report and Nilesh for the remainder. I was 
out of town these last days and could not react to your messages. I am 
taking a look at the issue right now.


Best,

Rafael

Bug#1053668: diffoscope: Consider using `file -i` as fallback for unknown file output

[Niels Thykier]

Package: diffoscope
Version: 250
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net

Hi,

I noticed that `diffoscope` used `hexdump -C` based diffs for the 
debian/changelog in the `mscgen` package.


My first bet was that `file` would produce incorrect output and indeed, 
`file` classifies that changelog as a `Message Sequence Chart` rather 
than text.  This is now filed as 1053666.


Digging a bit deeper, it turns out that `file -i` correctly classifies 
the changelog as `text/plain; charset=utf-8`.  That is, `file` knows it 
is text and I suspect `diffoscope` should try `file -i` as well when it 
gets an unknown result from `file`.


This bug report obviously assumes that the `hexdump -C` like output is 
triggered because `diffoscope` uses `file` for determining how to 
analyze the changelog.  If it uses something else, then there is some 
other bug in play that makes `diffoscope` treat the `mscgen` changelog 
as a binary file.


Here are two samples files that `file` considers to be `Message Sequence 
Chart (chart)` and `text/plain; charset=us-ascii` with -i, in case it is 
useful for a test:


```
msc {
  a, b;
}
```
```
msc {
  c, d;
}
```



Best regards,
Niels

Bug#1053667: file: Misclassifies d/changelog of the mscgen package as a "Message Sequence Chart"

[Niels Thykier]

Package: file
Version: 1:5.45-2
Severity: minor
X-Debbugs-Cc: ni...@thykier.net

Hi,

I get `Message Sequence Chart (chart)` when applying `file` to the 
changelog of the `mscgen` package.


$ file mscgen/debian/changelog 
mscgen/debian/changelog: Message Sequence Chart (chart)
$ head mscgen/debian/changelog 
mscgen (0.20-14) unstable; urgency=medium


  * Apply patch from Steve Langasek to avoid using negative
widths for text sizes in PNG files, which lead to crashes.
(Closes: #960405)
  * Add patch to give more height to PNG text.  The original
rendering no longer gave adequate space between lines or
the entity the text was a part of.
  * Remove -Wl,--as-needed as linker flag since it is now the
default.
 
For other Debian changelogs, `file` seems to have a much more reasonable 
output saying it is UTF-8 text.


"""
$ file debhelper/debian/changelog
debhelper/debian/changelog: Unicode text, UTF-8 text
"""

I suspect this is why `diffoscope` uses a `hexdump -C` based diff when 
doing delta's for the `mscgen` changelog.


Best regards,
Niels

-- System Information:
Versions of packages file depends on:
ii  libc6  2.37-12
ii  libmagic1  1:5.45-2

Bug#1053666: file: mscgen's examples are not classified as Message Sequence Charts

[Niels Thykier]

Package: file
Version: 1:5.45-2
Severity: minor
X-Debbugs-Cc: ni...@thykier.net

Hi,

Another MSC related bug report for file.

It seems that `file` uses `msc {` to detect a Message Sequence Chart per 
the following mini test:


```
$ echo 'msc {' | file -
/dev/stdin: Message Sequence Chart (chart)
```

So it would seem reasonable that the mscgen's examples would be 
classified as a `Message Sequence Chart` as they contain this phrase:


```
$ grep 'msc {' examples/client_server.mscin
msc {
```

However, `file` considers them to be `ASCII` text:

```
$ file examples/*.mscin
examples/boxes_example.mscin:ASCII text
examples/client_server.mscin:ASCII text
examples/colour_sample.mscin:ASCII text
examples/msg_types.mscin:ASCII text
examples/simple_prog_desc.mscin: ASCII text
```

I suspect the "problem" is that the examples starts with comments 
covering the license of the example and some context about the example.



All examples here are from the `mscgen/0.20-14` Debian source package. I 
have not tried `file` on the installed examples. The installed examples 
has a #!-line, which could affect the outcome in a different direction.


-- System Information:
Versions of packages file depends on:
ii  libc6  2.37-12
ii  libmagic1  1:5.45-2

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

[Free Ekanayaka]

Mathias Gibbens  writes:

> Control: reassign -1 wnpp
> Control: retitle -1 ITP: Incus -- Powerful system container and virtual 
> machine manager
> Control: severity -1 wishlist
> Control: block -1 by 1052536 1001989
>
>   I'm converting this bug to an ITP, as there's clearly sufficient
> interest in the packaging of Incus. Plus, it will help track any
> dependencies that need to be packaged/updated for Debian.

+1, thanks.

> On Tue, 2023-09-19 at 08:44 +0100, Free Ekanayaka wrote:
>> The dependencies should be pretty much the same as LXD 5.16, except for
>> cowsql, and for a few dependencies that actually got dropped wrt LXD. So
>> that part should be relatively straightforward if you have already done
>> some work for LXD 5.16.
>
>   There are two dependencies still in progress that are needed to
> properly build the latest feature release of LXD in Debian: golang-
> github-grafana-dskit (ITP#1001989; it has one dependency [golang-
> github-uber-jaeger-client-go] currently in NEW before I can package it)
> and updating golang-github-checkpoint-restore-go-criu to v6 (currently
> on v5, with a patch to undo its use in the current LXD packaging).

It seems that v6 of golang-github-checkpoint-restore-go-criu is in
experimental:

https://packages.debian.org/experimental/golang-github-checkpoint-restore-go-criu-dev

Not sure if there are blockers for it to move to unstable (maybe we'd
need to drop the patch currently applied to the LXD package?).

>> We were thinking more or less the same, but with a difference: what
>> about uploading to Debian only the LTS updates of LXD for now (that
>> means the 5.0.x releases) and start uploading the Incus development
>> releases (once the first is out)?
>
>   That seems reasonable to me. I know people occasionally ask for the
> latest version of LXD, which someday I might upload to experimental on
> a "best effort" basis, but the main packaging for LXD will follow the
> LTS releases. Prior to Incus' 1.0 LTS release, I think it would be
> great to upload development releases to facilitate testing by
> interested users.

Yes, agrred. Incus 0.1 has now been released, and I've updated the salsa
repository accordingly.

I've also switched the packaging branch from debian/experimental to
debian/unstable, as actually I don't see a reason for not uploading to
unstable at this stage.

Once Incus 1.0 LTS is out we could opt for uploading only LTS updates to
unstable and development releases to experimental.

>> Once trixie gets released it would contain the latest LXD 5.0.x release
>> (which upstream supports until June 2027), and the latest Incus LTS
>> release. Bookworm users can upgrade to trixie and then migrate their
>> deployments to Incus using the lxd-to-incus tool, if they wish to.
>
>   Just a minor note -- if LXD keeps its established release schedule,
> I'm expecting LXD 6.0.x to ship in trixie.

Yes, although I would personally keep Debian's LXD at version 5.0.x for
trixie and point users to the lxd-to-incus migration tool, to migrate
from LXD 5.0.x to Incus 1.0.x, which should be be a superset of LXD
6.0.x.

That's of course just might take, I understand that there might be
interest from other DDs/users (e.g. you) to update the Debian's package
to LXD 6.0.x.

>   We will definitely want test the transition path and ensure there's
> good documentation in place for the trixie release.

+1

>> As for now cowsql's raft is compatible with dqlite's raft, and I plan to
>> maintain that compatibility, at least as far as the LXD+dqlite stack is
>> concerned (which is what matters for Debian).
>> 
>> What I'd propose would be to change the upstream of the libraft package
>> in Debian from canonical/raft to cowsql/raft, and I could (co-?)maintain
>> the libraft package as well as the dqlite one, making sure they work
>> together (that might help Laszlo too, taking some work off his plate, I
>> can reach out to him and ask).
>
>   Currently in unstable there are only three rdeps of src:raft: dqlite,
> golang-github-canonical-go-dqlite, and lxd. So it would certainly be
> doable to switch the upstream of src:raft -- if Laszlo is open to doing
> so, it should be a pretty easy transition. Probably the trickiest thing
> would be the versions: I'd like to avoid a package epoch bump if
> possible, and we'd also have to consider the .so versioning.

Why do think an epoch is needed? I believe it can be done without
epochs. Anyway, if the idea gets consenus I'll coordinate with Laszlo
about that.

>> It's still very early on and it's not working yet (I've mostly rebranded
>> the debian/ directory of the lxd Debian source package), but it's a
>> start, so perhaps we might already have something kind of working by the
>> time the first Incus release is out.
>
>   At least initially, I'd like to keep the packaging for LXD and Incus
> as similar as possible. I know over time things will diverge, but for
> now I think keeping the delta between packages small will be
> beneficial.

Yes,