Bug#1013227: pipewire sound system is the future

[didier]

Hello,

I have also switch to a pipewire only sound system on my machines.

I am using pavucontrol to manage the interfaces and qpwgraph for 
connections.


But I also need qjackctl for functionality like buffer size management, 
script launch 


Please unlock the dependency of qjackctl to jack only.

pipewire is the future of the sound on linux system, please do not keep 
stuck in the past.


Regards,

Didier

Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)

[Renato Gallo]

Linux ghost 6.1.0-rc5 #1 SMP PREEMPT_DYNAMIC Mon Nov 21 10:45:11 CET 2022
x86_64 GNU/Linux

 dmesg|grep -i firmware
[0.083868] Spectre V2 : Enabling Restricted Speculation for firmware
calls
[0.588920] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[0.599850] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 
[bus 00-7f] only partially covers this bridge
[1.770657] ACPI: video: [Firmware Bug]: ACPI(PEGP) defines _DOD but not
_DOS
[5.333711] platform regulatory.0: firmware: direct-loading firmware
regulatory.db
[5.334476] platform regulatory.0: firmware: direct-loading firmware
regulatory.db.p7s
[5.350952] iwlwifi :04:00.0: firmware: direct-loading firmware
iwlwifi-cc-a0-72.ucode
[5.351201] iwlwifi :04:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)



[5.351218] firmware_class: See https://wiki.debian.org/Firmware for
information about missing firmware
[5.351338] iwlwifi :04:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)





[5.351351] iwlwifi :04:00.0: loaded firmware version 72.daa05125.0
cc-a0-72.ucode op_mode iwlmvm
[5.617756] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[5.619356] bluetooth hci0: firmware: direct-loading firmware
intel/ibt-20-1-3.sfi
[5.619359] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi
[5.619367] Bluetooth: hci0: Firmware Version: 106-39.22
[7.043546] Bluetooth: hci0: Waiting for firmware download to complete
[7.043737] Bluetooth: hci0: Firmware loaded in 1390992 usecs
[7.064205] bluetooth hci0: firmware: direct-loading firmware
intel/ibt-20-1-3.ddc
[7.072839] Bluetooth: hci0: Firmware revision 0.3 build 106 week 39 2022
[7.518824] r8169 :02:00.0: firmware: direct-loading firmware
rtl_nic/rtl8125b-2.fw

Bug#1024680: pydevd: ftbfs on riscv64(failed test)

[Bo YU]

Source: pydevd
Version: 2.9.2+ds-4
Followup-For: Bug #1024680
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Becasue some packages due to missing the package is in dep-wait status[1].
So I think it is valuable to send this patch.

[1]: https://buildd.debian.org/status/architecture.php?a=riscv64=sid
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1024224: openscap-utils: FTBFS with libproc2

[Håvard F . Aasen]

Control: tags -1 + patch pending


I've pushed a fix to salsa [1], where I remove libprocps as a
dependency. We are now depending on a local file called
'compat/dev_to_tty.c'. This was how it was done before version
1.3.5-0.1.

As a side-note. It is the header 'proc/devname.h' we used, which
isn't included in the development package anymore.


Regards,
Håvard

[1] 
https://salsa.debian.org/debian/openscap/-/commit/e21814a6a2c6d124659346650e8b9100710686a5

Bug#1024681: RFS: libnss-gw-name/0.3-5 [QA] -- nss module that names the current gateway’s IP address

[Gioele Barabucci]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libnss-gw-name":

 * Package name : libnss-gw-name
   Version  : 0.3-5
 * Vcs  : https://salsa.debian.org/debian/libnss-gw-name
   Section  : admin

The source builds the following binary packages:

  libnss-gw-name - nss module that names the current gateway’s IP address

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


  https://mentors.debian.net/package/libnss-gw-name/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libn/libnss-gw-name/libnss-gw-name_0.3-5.dsc


Changes since the last upload:

 libnss-gw-name (0.3-5) unstable; urgency=medium
 .
   * QA upload.
   * d/gbp.conf: Use DEP-14 layout
   * d/patches: Cherry-pick PR#1 from upstream
   * d/control: Bump Standards-Version to 4.6.1 (no changes needed)
   * d/control: Point Vcs-* to salsa.d.o
   * d/salsa-ci: Add standard pipeline
   * d/nss: Instal NSS service via dh_installnss (Closes: #1011515)

Additionally, could you please copy the repository 
https://salsa.debian.org/gioele/libnss-gw-name/ to the debian/ namespace?


Regards,

--
Gioele Barabucci

Bug#1024680: pydevd: ftbfs on riscv64(failed test)

[Bo YU]

Source: pydevd
Version: 2.9.2+ds-4
Severity: wishlist

Dear Maintainer,

The package has a ftbfs issue on riscv64 due to failed test；
```
pydevd:
FAILED tests_python/test_debugger.py::test_case_django_b - AssertionError: Ti...
FAILED 
tests_python/test_debugger.py::test_case_django_template_inherits_no_exception
FAILED tests_python/test_debugger.py::test_case_django_no_var_error - Asserti...
FAILED 
tests_python/test_debugger.py::test_case_django_no_attribute_exception_breakpoint[False]
FAILED 
tests_python/test_debugger.py::test_case_django_no_attribute_exception_breakpoint[True]
FAILED 
tests_python/test_debugger.py::test_case_django_no_attribute_exception_breakpoint_and_regular_exceptions
FAILED 
tests_python/test_debugger.py::test_case_django_invalid_template_exception_breakpoint[False]
FAILED 
tests_python/test_debugger.py::test_case_django_invalid_template_exception_breakpoint[True]
FAILED tests_python/test_debugger.py::test_attach_to_pid_no_threads[True] - A...
FAILED tests_python/test_debugger.py::test_attach_to_pid_no_threads[False] - ...
FAILED tests_python/test_debugger.py::test_attach_to_pid_halted - AssertionEr...
FAILED tests_python/test_debugger.py::test_gevent - AssertionError: TimeoutEr...
FAILED tests_python/test_debugger.py::test_gevent_show_paused_greenlets[False]
FAILED tests_python/test_debugger.py::test_gevent_remote - AssertionError: Ti...
FAILED tests_python/test_debugger_json.py::test_wait_for_attach_gevent - Asse...
FAILED 
tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[True]
FAILED 
tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[False]
FAILED tests_python/test_debugger_json.py::test_gevent_subprocess_not_python
FAILED tests_python/test_debugger_json.py::test_gevent_subprocess_python - As...
FAILED tests_python/test_debugger_json.py::test_notify_gevent - AssertionErro...
FAILED 
tests_python/test_debugger_json.py::test_case_django_no_attribute_exception_breakpoint[False]
FAILED 
tests_python/test_debugger_json.py::test_case_django_no_attribute_exception_breakpoint[True]
FAILED tests_python/test_debugger_json.py::test_case_django_line_validation
FAILED tests_python/test_debugger_json.py::test_attach_to_pid[True] - Asserti...
FAILED tests_python/test_debugger_json.py::test_attach_to_pid[False] - Assert...
FAILED tests_python/test_utilities.py::test_gevent_notify - subprocess.Called...
```

The full buildd log is here：
https://buildd.debian.org/status/fetch.php?pkg=pydevd=riscv64=2.9.2%2Bds-4=1669171281=0

Although disable test to fix the issue is not better solution, but as
you said[0], the upstream only support amd64 and i386. And thanks to 
your packaging scripts it is easy to disable these cases on riscv64.:)

I have tested the patch on riscv64 hardware, so could you upload it in
next release?

Please let me know if there are any issues.

[0]: https://lists.debian.org/debian-python/2022/11/msg00060.html

-- 
Regards,
--
  Bo YU

diff -Nru pydevd-2.9.2+ds/debian/get_test_exclusions 
pydevd-2.9.2+ds/debian/get_test_exclusions
--- pydevd-2.9.2+ds/debian/get_test_exclusions  2022-11-20 19:25:23.0 
+
+++ pydevd-2.9.2+ds/debian/get_test_exclusions  2022-11-20 19:25:23.0 
+
@@ -118,6 +118,39 @@
 )
 fi
 
+# as above stated, test cases below fail on riscv64
+if [ $arch = riscv64 ]
+then
+EXCLUDES+=(
+tests_python/test_debugger.py::test_case_django_b
+
tests_python/test_debugger.py::test_case_django_template_inherits_no_exception
+tests_python/test_debugger.py::test_case_django_no_var_error
+
tests_python/test_debugger.py::test_case_django_no_attribute_exception_breakpoint[False]
+
tests_python/test_debugger.py::test_case_django_no_attribute_exception_breakpoint[True]
+
tests_python/test_debugger.py::test_case_django_no_attribute_exception_breakpoint_and_regular_exceptions
+
tests_python/test_debugger.py::test_case_django_invalid_template_exception_breakpoint[False]
+
tests_python/test_debugger.py::test_case_django_invalid_template_exception_breakpoint[True]
+tests_python/test_debugger.py::test_attach_to_pid_no_threads[True]
+tests_python/test_debugger.py::test_attach_to_pid_no_threads[False]
+tests_python/test_debugger.py::test_attach_to_pid_halted
+tests_python/test_debugger.py::test_gevent
+tests_python/test_debugger.py::test_gevent_show_paused_greenlets[False]
+tests_python/test_debugger.py::test_gevent_remote
+tests_python/test_debugger_json.py::test_wait_for_attach_gevent
+
tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[True]
+
tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[False]
+tests_python/test_debugger_json.py::test_gevent_subprocess_not_python
+tests_python/test_debugger_json.py::test_gevent_subprocess_python
+tests_python/test_debugger_json.py::test_notify_gevent
+

Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files

[Roland Clobus]

Hello Jelmer,

On 22/11/2022 00:49, Jelmer Vernooij wrote:

On Mon, Nov 21, 2022 at 09:19:41PM +0100, Roland Clobus wrote:

On 19/11/2022 18:20, Jelmer Vernooij wrote:

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

* Package name: setuptools-gettext
Version : 0.0.1
Upstream Author : Breezy Team 
* URL : https://github.com/jelmer/setuptools-gettext
* License : GPL
Programming Lang: Python
Description : Compile .po files into .mo files

This extension for setuptools compiles gettext .po files
found in the source directory into .mo files and installs them.


How does this tool differ from 'msgfmt' from 'gettext'?


It's a wrapper around msgfmt, but making it convenient to run from setuptools.
I'll clarify that in the final description.


Sorry to bother you again.

Today I found the following post:
https://www.redhat.com/sysadmin/python-subprocess-module

Wouldn't this package effectively be 'subprocess.run("msgfmt")'?
Or would the package name 'python3-gettext' be more suitable?

With kind regards,
Roland Clobus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024679: dxf2gcode: Clean more generated files before and after build

[Petter Reinholdtsen]

Package: dxf2gcode
Version: 20170925-4
Tags: patch

To make it easier to rebuild the source package, I suggest to do some
more cleaning after build:

diff --git a/debian/rules b/debian/rules
index c86b1a6..6d787c1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,8 @@ override_dh_auto_clean:
rm -rf dxf2gcode_images5_rc.py \
   dxf2gcode_ui5.py \
   dxf2gcode.egg-info/ \
+  dxf2gcode/globals/__pycache__/ \
+  dxf2gcode/__pycache__/ \
   globals/__pycache__/ \
   i18n/*.qm
 
-- 
Happy hacking
Petter Reinholdtsen

Bug#908543: dxf2gcode: Please provide a way to specify a file contains inches

[Petter Reinholdtsen]

[Paul "LeoNerd" Evans]
> While this can be corrected by applying a "Scale All" factor of 25.4,
> it would be nicer if the units could be specified; e.g.
> 
>   $ dxf2code --inches output.dxf

This sound like a useful proposal.  It might be better to direct it to
upstream.  Note, I am not the package maintainer, just a drive-by
debian user. :)

My personal favorite would of course be to switch to millimeter in the
drawing, but realise it might take a while before we are there. :)

-- 
Happy hacking
Peter Reinholdtsen

Bug#1024674: libphonenumber8: breaks Evolution

[Michael Ott]

I did the same and it works. This mail will be send from Evolution

> This issue goes away for me after a rebuild of src:evolution-data-
server
> and installing the freshly rebuilt libebook-contacts-1.2-4.
> 
> Maybe we can kick off a rebuild via the transition.  If not that,
would
> you be willing to do a sourceful upload Jeremy?

Bug#1022387: dxf2gcode: FTBFS: dh_usrlocal: error: debian/dxf2gcode/usr/local/bin/dxf2gcode is not a directory

[Petter Reinholdtsen]

Control: tags -1 + patch

Look like setuptool changed behaviour, and now require --install-data=/usr
and --install-scripts=/usr/bin to function properly.  This patch should
fix the issue:

diff --git a/debian/rules b/debian/rules
index c86b1a6..2d5dbe3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,4 +17,4 @@ override_dh_auto_build:
python3 ./st-setup.py build
 
 override_dh_auto_install:
-   python3 ./st-setup.py install --prefix=usr --install-lib 
usr/lib/python3/dist-packages --root=debian/dxf2gcode
+   python3 ./st-setup.py install --root=debian/dxf2gcode --prefix=/usr 
--install-lib /usr/lib/python3/dist-packages --install-data=/usr 
--install-scripts=/usr/bin

I lack commit rights, so I can not push the fix to git myself.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1011500: tuxcmd-modules: reproducible-builds: embedded build paths in various binaries

[Chris Lamb]

Hi Vagrant,

> This hasn't yet landed in the archive, was it actually uploaded to
> DELAYED/3?

Somewhat unclear. I am pretty sure it was uploaded as I can find an
.upload file for it:

  $ cat tuxcmd-modules_0.6.70+ds-5.1_amd64.ssh-upload.upload
  Successfully uploaded tuxcmd-modules_0.6.70+ds-5.1.dsc to 
ssh.upload.debian.org for ssh-upload.
  Successfully uploaded tuxcmd-modules_0.6.70+ds.orig.tar.gz to 
ssh.upload.debian.org for ssh-upload.
  Successfully uploaded tuxcmd-modules_0.6.70+ds-5.1.debian.tar.xz to 
ssh.upload.debian.org for ssh-upload.
  Successfully uploaded tuxcmd-modules-dbgsym_0.6.70+ds-5.1_amd64.deb to 
ssh.upload.debian.org for ssh-upload.
  Successfully uploaded tuxcmd-modules_0.6.70+ds-5.1_amd64.buildinfo to 
ssh.upload.debian.org for ssh-upload.
  Successfully uploaded tuxcmd-modules_0.6.70+ds-5.1_amd64.deb to 
ssh.upload.debian.org for ssh-upload.
  Successfully uploaded tuxcmd-modules_0.6.70+ds-5.1_amd64.changes to 
ssh.upload.debian.org for ssh-upload.

> It could have been uploaded to DELAYED/0 (e.g. without delay) as a QA
> upload rather than as an NMU...

Oh sure, but 3 days delay easily allows issues to be caught...

However, in lieu of working out what has happened here, I'll re-upload
now without any DELAYED value. Thanks. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1024674: libphonenumber8: breaks Evolution

[tony mancill]

On Wed, Nov 23, 2022 at 06:28:04AM +0100, Christoph Anton Mitterer wrote:
> On Tue, 2022-11-22 at 21:11 -0800, tony mancill wrote:
> 
> I guess it must be doing some kind of dynamic loading stuff? OTOH, it
> seems to be just linked as a plain shared lib:
> $ libtree /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4.0.0
> libebook-contacts-1.2.so.4 
> ├── libedataserver-1.2.so.27 [ld.so.conf]
> ...
> ├── libphonenumber.so.8 [ld.so.conf]
> │   ├── libprotobuf.so.23 [ld.so.conf]
> │   │   └── libz.so.1 [ld.so.conf]
> │   ├── libabsl_throw_delegate.so.20220623 [ld.so.conf]
> │   ├── libabsl_strings.so.20220623 [ld.so.conf]
> │   │   ├── libabsl_strings_internal.so.20220623 [ld.so.conf]
> │   │   │   └── libabsl_raw_logging_internal.so.20220623 [ld.so.conf]
> │   │   ├── libabsl_raw_logging_internal.so.20220623 [ld.so.conf]
> │   │   └── libabsl_throw_delegate.so.20220623 [ld.so.conf]
> │   ├── libabsl_raw_hash_set.so.20220623 [ld.so.conf]
> │   ├── libabsl_hash.so.20220623 [ld.so.conf]
> │   │   ├── libabsl_city.so.20220623 [ld.so.conf]
> │   │   └── libabsl_low_level_hash.so.20220623 [ld.so.conf]
> │   ├── libicui18n.so.72 [ld.so.conf]
> │   └── libicuuc.so.72 [ld.so.conf]
> ...
> 
>  
> Yes... at least evolution, but that's the only thing I have, which
> depends on it.

I notice that libebook-contacts wasn't part of of the protobuf
transition [1], but it seems like it should have been a level 3
dependency.

I'm not sure whether that's an issue with the transition tooling or if
we're missing sufficient linkage between the packages.

[1] https://release.debian.org/transitions/html/auto-protobuf.html

> Maybe we should increase the severity, so that people will see it at
> least via apt-listbugs?

Ah, that's a good idea if we want to notify folks not to install
libphonenumber8.  Perhaps I shouldn't have reassigned the bug to
evolution-data-server.  Maybe we should create a new bug (or clone this
one) and assign it to libphonenumber8?

Bug#1024678: dxf2gcode: New upstream version available

[Petter Reinholdtsen]

Package: dxf2gcode
Version: 20170925-4
Severity: wishlist

A new upstream version 20220226_RC1 is available from
https://sourceforge.net/p/dxf2gcode/wiki/Home/ >.  Perhaps time to
update?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1010648: marked as pending in golang-github-pierrec-lz4.v4

[Shengjing Zhu]

On Mon, Nov 21, 2022 at 02:49:28PM -0500, Nicholas D Steeves wrote:
> Control: retitle -1 RFP: golang-github-pierrec-lz4.v4 -- LZ4 compression and 
> decompression in pure Go (v4)
> Control: noowner -1
> 
> TLDR: this missing package is blocking updates for syncthing as well as
> golang-github-gocql-gocql.

FWIW, I just notice golang-github-gocql-gocql 1.2.1-2 has migrated to testing.

Bug#1017621: seahorse-nautilus: Fails to build with Nautilus 43

[Andreas Metzler]

On 2022-08-18 Jeremy Bicha  wrote:
> Source: seahorse-nautilus
[...]
> The newest release of Nautilus, version 43, has switched to GTK4 and
> includes major changes in the extensions API.

> seahorse-nautilus will need to be converted to GTK4 and make other changes
> for the new version.

> Nautilus 43 is available in Debian Experimental. When we upload
> nautilus 43 to Debian Unstable, we will need to remove
> seahorse-nautilus from Testing unless this bug is fixed, because the
> package will no longer build from source.

Hello,

as of today seahorse-nautilus actually FTBFS. It fails to locate gpgme
(gpgme-config was dropped, superseded by pkg-config). Find attached
a patch to fix this. Even with this change it later fails with
checking for libnautilus-extension >= 2.12.0 glib-2.0 >= 2.10.0... no

(There is now a libnautilus-extension-4.pc).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--- seahorse-nautilus-3.11.92.orig/configure.ac
+++ seahorse-nautilus-3.11.92/configure.ac
@@ -87,41 +87,7 @@ if test	"$DO_CHECK" = "yes"; then
 	fi
 fi
 
-ok="no"
-min_gpgme_version=1.0.0
-AC_PATH_PROG(GPGME_CONFIG, gpgme-config, "failed")
-if test $GPGME_CONFIG != "failed" ; then
-	AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
-	req_major=`echo $min_gpgme_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
-	req_minor=`echo $min_gpgme_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
-	req_micro=`echo $min_gpgme_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
-	gpgme_config_version=`$GPGME_CONFIG --version`
-	major=`echo $gpgme_config_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
-	minor=`echo $gpgme_config_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
-	micro=`echo $gpgme_config_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
-
-	if test "$major" -eq "$req_major"; then
-		if test "$minor" -ge "$req_minor"; then
-			if test "$micro" -ge "$req_micro"; then
-ok="yes"
-			fi
-		fi
-	fi
-fi
-
-if test $ok = "yes"; then
-	GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
-	GPGME_LIBS=`$GPGME_CONFIG --libs`
-	AC_MSG_RESULT(yes)
-else
-	AC_MSG_ERROR(GPGME $min_gpgme_version or later needed)
-fi
+PKG_CHECK_MODULES(GPGME, [gpgme >= 1.0.0])
 
 SEAHORSE_CFLAGS="$SEAHORSE_CFLAGS $GPGME_CFLAGS"
 SEAHORSE_LIBS="$SEAHORSE_LIBS $GPGME_LIBS"
@@ -298,6 +264,6 @@ nautilus-ext/Makefile
 
 echo "
 GnuPG Version:   $gnupg_version
-GPGME Version:   $gpgme_config_version
+GPGME Version:   $GPGME_VERSION
 Notification Support:$enable_libnotify
 "

Bug#1024677: protobuf: autopkgtest failure (error: file not found: com/example/tutorial/AddressBookProtos.java)

[Bas Couwenberg]

Source: protobuf
Version: 3.21.9-3
Severity: serious
Tags: upstream patch
Control: block 1023535 by -1

Dear Maintainer,

The autopkgtest for your package is failing:

 autopkgtest [02:27:53]: test simple: [---
 *** Building example programs
 protoc $PROTO_PATH --cpp_out=. --java_out=. --python_out=. addressbook.proto
 pkg-config --cflags protobuf  # fails if protobuf is not installed
 
 c++ -std=c++11 add_person.cc addressbook.pb.cc -o add_person_cpp `pkg-config 
--cflags --libs protobuf`
 pkg-config --cflags protobuf  # fails if protobuf is not installed
 
 c++ -std=c++11 list_people.cc addressbook.pb.cc -o list_people_cpp `pkg-config 
--cflags --libs protobuf`
 javac -cp $CLASSPATH AddPerson.java ListPeople.java 
com/example/tutorial/AddressBookProtos.java
 error: file not found: com/example/tutorial/AddressBookProtos.java
 Usage: javac  
 use --help for a list of possible options
 make: *** [Makefile:66: javac_middleman] Error 2

https://ci.debian.net/data/autopkgtest/unstable/amd64/p/protobuf/28586956/log.gz

The attached patch fixes the issue by correcting the paths in the Makefile.

Kind Regards,

Bas
--- a/examples/Makefile 2022-10-26 19:50:48.0 +0200
+++ b/examples/Makefile 2022-11-23 07:07:29.963242439 +0100
@@ -13,8 +13,8 @@
 
 clean:
rm -f add_person_cpp list_people_cpp add_person_java list_people_java 
add_person_python list_people_python
-   rm -f javac_middleman AddPerson*.class ListPeople*.class 
com/example/tutorial/*.class
-   rm -f protoc_middleman addressbook.pb.cc addressbook.pb.h 
addressbook_pb2.py com/example/tutorial/AddressBookProtos.java
+   rm -f javac_middleman AddPerson*.class ListPeople*.class 
com/example/tutorial/protos/*.class
+   rm -f protoc_middleman addressbook.pb.cc addressbook.pb.h 
addressbook_pb2.py com/example/tutorial/protos/*.java
rm -f *.pyc
rm -f go/tutorialpb/*.pb.go add_person_go list_people_go
rm -f protoc_middleman_dart dart_tutorial/*.pb*.dart
@@ -63,7 +63,7 @@
cd go && go test ./cmd/list_people
 
 javac_middleman: AddPerson.java ListPeople.java protoc_middleman
-   javac -cp $$CLASSPATH AddPerson.java ListPeople.java 
com/example/tutorial/AddressBookProtos.java
+   javac -cp $$CLASSPATH AddPerson.java ListPeople.java 
com/example/tutorial/protos/*.java
@touch javac_middleman
 
 add_person_java: javac_middleman

Bug#1024674: libphonenumber8: breaks Evolution

[tony mancill]

On Wed, Nov 23, 2022 at 05:02:16AM +0100, Christoph Anton Mitterer wrote:
> Package: libphonenumber8
> Version: 8.12.57+ds-1+b2
> Severity: serious
> 
> After the upgrade, evolution crashes when started:
> $ evolution
> evolution: symbol lookup error: 
> /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: 
> _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE

This issue goes away for me after a rebuild of src:evolution-data-server
and installing the freshly rebuilt libebook-contacts-1.2-4.

Maybe we can kick off a rebuild via the transition.  If not that, would
you be willing to do a sourceful upload Jeremy?


signature.asc
Description: PGP signature

Bug#974868: samba-vfs-modules: Still causing issues - at least on armv5tel/armel

[Michael Tokarev]

23.11.2022 00:23, ArtMG wrote:
..

Attachments:
* fruit-disable-useless-size_t-overflow-check.patch


Thanks for the patch Michael, I compiled and ran and although it got out of the 
disk size functions this time, it still slipped up with


I pushed this patch to debian samba package now.
The check there (which this patch removes) makes no sense on 64bits
(since the value is capped elsewhere) and is obviously wrong on
32bits, - for some reason it tries to calculate capacity in apples
when dealing with oranges all the way, and when sizes of apples and
oranges are entirely different on this platform, this test obviously
doe not do any good.  Also, this is a very specific issue affecting
only very specific use cases (with MacOS operability on 32bit), so
there should be no big harm done this way to make samba upstream
unhappy (if it were for something more widespread, I'd not push this
change to debian package).


../../source3/smbd/service.c:787(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service 
TimeMachineBackup, path /mnt/HDD/TimeMachine


So this particular issue is gone now.  It might have other issues,
maybe due to size of size_t on 32bit in some other place, maybe due
to disk size limits, maybe something entirely different, but this
particular issue is gone.


I do appreciate you cutting this patch for this issue, however I feel like I've 
been down this road before with these issues. Push a fix here, and if a new 
issue doesn't pop up over there straight away, give it a version or three and 
it will eventually. Hence my reference to whack-a-mole.


It's not whack-a-mole really.  Whack-a-mole assumes there's just one
mole out there, which shows in different holes. But here, we have
many moles collected over the years of no testing.  You whack one
for good, but another dozen are chewing stuff somewhere else nearby,
ready to meet you.  This issue already whacked two which was in
the same place.


As Andrew points out, this is somewhat outlying as test-cases go. There are few 
people wanting to rebuild a 32-bit instance of their backup mechanism for each 
point revision of a large and actively-developed service like samba.


Well, once it's in debian, 32bit packages are provided automatically,
there's no need to rebuild them ;)


I see no reason, personally, to push for developer attention when the solution 
is as simple as 'switch to 64-bit OS', and then even OLD versions in all the 
repos work just fine. Although I do not have statistics to hand, I feel that we 
must be far enough along the migration curve on the journey from 32- to 64-bit 
systems, especially when it comes to a core-yet-commodity infrastructure 
service like samba, to warrant letting go of legacy.


It is not that simple, but can be viewed like this anyway.
Yes, 32bit world is dying, and the future is 64+bits, this is
not question whatsoever.  However, the question is *when* to
declare the death of 32bit world.  We either declare it dead
and stop building/providing samba on any 32bit platform entirely,
or we do not declare 32bit world dead, and provide a good service
there. What we do have now is neither one nor another, 32bit
world is not dead and samba is being provided for it, but the
quality of it on 32bits is, well, questionable.  So we either
should draw this line or fix bugs.

I dunno if it's good idea to push the change upstream though:
history tells me this is nearly hopeless to perform changes
in samba code even if the changes are small and obvious.. but
this is entirely different story.


Thanks for your good will and effort, nonetheless.


You're welcome.

Thanks!

/mjt

Bug#1024674: libphonenumber8: breaks Evolution

[Christoph Anton Mitterer]

On Tue, 2022-11-22 at 21:11 -0800, tony mancill wrote:
> Yes, totally.  I didn't mean to imply that the bug shouldn't be here.

Sure... just wanted to point out, that I don't consider it your fault
or so :-)



> > I had evolution running, while I've upgraded. And didn't restart it
> > afterwards (at least not immediately).
> > 
> > I then noticed some weird things... when replying to a mail, there
> > was
> > no quoting of the mail I replied to (i.e. I got a new compose
> > window,
> > but no text in it).
> > Also I couldn't save my composed mail as draft (some strange error
> > popup within evolution itself).
> 
> Interesting...

Interesting word for weird ;-)

I guess it must be doing some kind of dynamic loading stuff? OTOH, it
seems to be just linked as a plain shared lib:
$ libtree /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4.0.0
libebook-contacts-1.2.so.4 
├── libedataserver-1.2.so.27 [ld.so.conf]
...
├── libphonenumber.so.8 [ld.so.conf]
│   ├── libprotobuf.so.23 [ld.so.conf]
│   │   └── libz.so.1 [ld.so.conf]
│   ├── libabsl_throw_delegate.so.20220623 [ld.so.conf]
│   ├── libabsl_strings.so.20220623 [ld.so.conf]
│   │   ├── libabsl_strings_internal.so.20220623 [ld.so.conf]
│   │   │   └── libabsl_raw_logging_internal.so.20220623 [ld.so.conf]
│   │   ├── libabsl_raw_logging_internal.so.20220623 [ld.so.conf]
│   │   └── libabsl_throw_delegate.so.20220623 [ld.so.conf]
│   ├── libabsl_raw_hash_set.so.20220623 [ld.so.conf]
│   ├── libabsl_hash.so.20220623 [ld.so.conf]
│   │   ├── libabsl_city.so.20220623 [ld.so.conf]
│   │   └── libabsl_low_level_hash.so.20220623 [ld.so.conf]
│   ├── libicui18n.so.72 [ld.so.conf]
│   └── libicuuc.so.72 [ld.so.conf]
...

 
> > Since I suspected some issues, I restarted evolution, and only then
> > I've noticed the libphonenumber related error I've mentioned in the
> > initial mail.
> 
> Ugh, so it's completely broken for you now.

Yes... at least evolution, but that's the only thing I have, which
depends on it.

Maybe we should increase the severity, so that people will see it at
least via apt-listbugs?


Thanks :-)
Chris.
> 

Bug#1024674: libphonenumber8: breaks Evolution

[tony mancill]

On Wed, Nov 23, 2022 at 05:02:16AM +0100, Christoph Anton Mitterer wrote:
> After the upgrade, evolution crashes when started:
> $ evolution
> evolution: symbol lookup error: 
> /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: 
> _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE

Weird that it didn't fail the first time, but I'm seeing the same
failure now, both with the auto-transition build and with a rebuild on
my local system.

Bug#1024676: gdm3: Insecure default configuration lets unauthenticated users turn off my wifi

[Ronny Rentner]

Package: gdm3
Version: 43.0-1
Severity: normal
X-Debbugs-Cc: debian-b...@ronny-rentner.de

Dear Maintainer,

from the GDM3 login screen, any unauthenticated user can change central system
settings like turn off my wifi. This is causing trouble because my computer
suddenly becomes unreachable from the internet. Also any background processes
requiring network will stop working.

By default, this shouldn't be possible.

For a comparison: On Android, there is also a quick setting for wifi, but it
requires you to authenticate if you want to change it.

Thanks in advance!

Ronny


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (400, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdm3 depends on:
ii  accountsservice  22.08.8-1+b1
ii  adduser  3.129
ii  dbus [default-dbus-system-bus]   1.14.4-1
ii  dbus-bin 1.14.4-1
ii  dbus-daemon  1.14.4-1
ii  dconf-cli0.40.0-3
ii  dconf-gsettings-backend  0.40.0-3
ii  debconf [debconf-2.0]1.5.79
ii  gir1.2-gdm-1.0   43.0-1
ii  gnome-session [x-session-manager]43.0-1
ii  gnome-session-bin43.0-1
ii  gnome-session-common 43.0-1
ii  gnome-session-flashback [x-session-manager]  3.46.0-1
ii  gnome-settings-daemon43.0-3
ii  gnome-shell  43.1-2
ii  gnome-terminal [x-terminal-emulator] 3.46.2-1
ii  gsettings-desktop-schemas43.0-1
ii  kitty [x-terminal-emulator]  0.21.2-2
ii  konsole [x-terminal-emulator]4:22.08.1-1
ii  libaccountsservice0  22.08.8-1+b1
ii  libaudit11:3.0.7-1.1+b2
ii  libc62.36-5
ii  libcanberra-gtk3-0   0.30-10
ii  libcanberra0 0.30-10
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libgdm1  43.0-1
ii  libglib2.0-0 2.74.1-2
ii  libglib2.0-bin   2.74.1-2
ii  libgtk-3-0   3.24.34-5
ii  libgudev-1.0-0   237-2
ii  libkeyutils1 1.6.3-1
ii  libpam-modules   1.5.2-5
ii  libpam-runtime   1.5.2-5
ii  libpam-systemd [logind]  252.1-1
ii  libpam0g 1.5.2-5
ii  librsvg2-common  2.54.5+dfsg-1
ii  libselinux1  3.4-1+b3
ii  libsystemd0  252.1-1
ii  libx11-6 2:1.8.1-2
ii  libxau6  1:1.0.9-1
ii  libxcb1  1.15-1
ii  libxdmcp61:1.1.2-3
ii  lsb-base 11.5
ii  marco [x-window-manager] 1.26.1-1
ii  mate-session-manager [x-session-manager] 1.26.0-1
ii  mate-terminal [x-terminal-emulator]  1.26.0-1
ii  metacity [x-window-manager]  1:3.46.0-1
ii  mutter [x-window-manager]43.0-2
ii  polkitd  122-1
ii  procps   2:3.3.17-7.1
ii  systemd-sysv 252.1-1
ii  sysvinit-utils [lsb-base]3.05-7
ii  ucf  3.0043
ii  x11-common   1:7.7+23
ii  x11-xserver-utils7.7+9+b1
ii  xfce4-terminal [x-terminal-emulator] 1.0.4-1
ii  xfwm4 [x-window-manager] 4.16.1-1

Versions of packages gdm3 recommends:
ii  at-spi2-core 2.46.0-4
ii  desktop-base 11.0.3
ii  gnome-session [x-session-manager]43.0-1
ii  gnome-session-flashback [x-session-manager]  3.46.0-1
ii  mate-session-manager [x-session-manager] 1.26.0-1
ii  x11-xkb-utils7.7+7
ii  xserver-xephyr   2:21.1.4-3
ii  xserver-xorg 1:7.7+23
ii  zenity   3.43.0-1

Versions of packages gdm3 suggests:
pn  

Bug#1024674: libphonenumber8: breaks Evolution

[tony mancill]

On Wed, Nov 23, 2022 at 05:51:50AM +0100, Christoph Anton Mitterer wrote:
> Hey Tony.
> 
> On Tue, 2022-11-22 at 20:40 -0800, tony mancill wrote:
> > Thank you for the bug report.  libphonenumber 8.12.57+ds-1 has been
> > in
> > testing for longer than a month at this point [1].  Has it been
> > broken
> > all of this time?  If not, I suspect this is related the protobuf
> > transition [2].
> 
> No, it was fine all the time with 8.12.57+ds-1+b1 (and backporting to
> it fixes the issue, too). Only 8.12.57+ds-1+b2 introduced the problem.

Good to know.  I will start by picking through the build logs here:

https://buildd.debian.org/status/fetch.php?pkg=libphonenumber=amd64=8.12.57%2Bds-1%2Bb2=1669158118=0

> But given that the dependency for evolution (or rather libebook-
> contacts-1.2-4) I thought the starting point of "responsibility" (in
> terms of package dependencies) should be there.

Yes, totally.  I didn't mean to imply that the bug shouldn't be here.

> > I'm not seeing the crash here, but I'm running vanilla unstable and
> > not
> > unstable-debug
> 
> I don't think this makes a difference... the unstable-debug is just
> there because I have the debug repo enabled, but the packages are from
> unstable:
> >   APT policy: (500, 'unstable-debug'), (500, 'unstable')

(nodding)

> I had evolution running, while I've upgraded. And didn't restart it
> afterwards (at least not immediately).
> 
> I then noticed some weird things... when replying to a mail, there was
> no quoting of the mail I replied to (i.e. I got a new compose window,
> but no text in it).
> Also I couldn't save my composed mail as draft (some strange error
> popup within evolution itself).

Interesting...
 
> Since I suspected some issues, I restarted evolution, and only then
> I've noticed the libphonenumber related error I've mentioned in the
> initial mail.

Ugh, so it's completely broken for you now.
 
> Perhaps we should get the protobuf people on board in this issue?

I have added Laszlo to the cc:  I'm rebuilding locally against the
3.21.9-4 protobuf sources to attempt to reproduce the bug.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1024675: transition: openturns

[Pierre Gruet]

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

Dear Release Team,

I would like to do the transition of openturns due to ABI changes. The new
version is in experimental and builds on all relevant architectures. There is
one rdep, persalys, which also builds well.

The autogenerated ben file is fine.

So I am ready to proceed when you tell me.

Cheers,

-- 
Pierre Gruet

Bug#1024674: libphonenumber8: breaks Evolution

[Christoph Anton Mitterer]

Hey Tony.

On Tue, 2022-11-22 at 20:40 -0800, tony mancill wrote:
> Thank you for the bug report.  libphonenumber 8.12.57+ds-1 has been
> in
> testing for longer than a month at this point [1].  Has it been
> broken
> all of this time?  If not, I suspect this is related the protobuf
> transition [2].

No, it was fine all the time with 8.12.57+ds-1+b1 (and backporting to
it fixes the issue, too). Only 8.12.57+ds-1+b2 introduced the problem.

So yes, it may be related to the transition.

But given that the dependency for evolution (or rather libebook-
contacts-1.2-4) I thought the starting point of "responsibility" (in
terms of package dependencies) should be there.



> I'm not seeing the crash here, but I'm running vanilla unstable and
> not
> unstable-debug

I don't think this makes a difference... the unstable-debug is just
there because I have the debug repo enabled, but the packages are from
unstable:
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
^
|

> You mention that it crashes
> and that it ends up in a weird state while it's running.  Does that
> mean
> it crashes and exits sometimes?  Or that logs an error and continues
> running?

No,... sorry for not describing it clearly.

I had evolution running, while I've upgraded. And didn't restart it
afterwards (at least not immediately).

I then noticed some weird things... when replying to a mail, there was
no quoting of the mail I replied to (i.e. I got a new compose window,
but no text in it).
Also I couldn't save my composed mail as draft (some strange error
popup within evolution itself).

Since I suspected some issues, I restarted evolution, and only then
I've noticed the libphonenumber related error I've mentioned in the
initial mail.


Perhaps we should get the protobuf people on board in this issue?


Thanks,
Chris.

Bug#1024674: libphonenumber8: breaks Evolution

[tony mancill]

On Wed, Nov 23, 2022 at 05:02:16AM +0100, Christoph Anton Mitterer wrote:
> Package: libphonenumber8
> Version: 8.12.57+ds-1+b2
> Severity: serious
> 
> 
> Hey.
> 
> After the upgrade, evolution crashes when started:
> $ evolution
> evolution: symbol lookup error: 
> /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: 
> _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE
> 
> and it even ended up in a weird state while it was still running.

Hi Chris,

Thank you for the bug report.  libphonenumber 8.12.57+ds-1 has been in
testing for longer than a month at this point [1].  Has it been broken
all of this time?  If not, I suspect this is related the protobuf
transition [2].

I'm not seeing the crash here, but I'm running vanilla unstable and not
unstable-debug, so perhaps that's a clue.  You mention that it crashes
and that it ends up in a weird state while it's running.  Does that mean
it crashes and exits sometimes?  Or that logs an error and continues
running?

Thank you,
tony

P.S.  Not directly related, but I have a package for 8.13.0 ready to upload,
but have been waiting for the transition to complete.

[1] https://tracker.debian.org/pkg/libphonenumber
[2] https://release.debian.org/transitions/html/auto-protobuf.html


signature.asc
Description: PGP signature

Bug#1023846: transition: gdal

[Sebastiaan Couwenberg]

On 11/22/22 21:56, Paul Gevers wrote:

On 22-11-2022 11:26, Sebastiaan Couwenberg wrote:
How can we schedule autopkgtest runs for testing with gdal & 
libgdal-grass from unstable?


Most of the time britney and autopkgtest handle it automatically if 
dependencies are rightly versioned (although not ideally during 
transitions). If you see issues more than a day after a binNMU, please 
be specific and let us know, then we can check and if needed schedule 
manually.


The libgdal-grass autopkgtest in testing is failing because it requires 
gdal, grass, and libgdal-grass from unstable.


 https://qa.debian.org/excuses.php?package=gdal

This combination needs to be tested to fix the regressions shown and 
unblock testing migration of gdal and the related rebuilt packages.


Kind Regards,

Bas

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

Bug#1024674: libphonenumber8: breaks Evolution

[Christoph Anton Mitterer]

Package: libphonenumber8
Version: 8.12.57+ds-1+b2
Severity: serious


Hey.

After the upgrade, evolution crashes when started:
$ evolution
evolution: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: 
_ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE

and it even ended up in a weird state while it was still running.

Cheers,
Chris.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages libphonenumber8 depends on:
ii  libabsl20220623  20220623.1-1
ii  libc62.36-5
ii  libgcc-s112.2.0-9
ii  libicu72 72.1-2
ii  libprotobuf323.21.9-4
ii  libstdc++6   12.2.0-9

libphonenumber8 recommends no packages.

libphonenumber8 suggests no packages.

-- no debconf information

Bug#1024673: Fix violations.ignore.d/logcheck-sudo (too precise)

[Trent W. Buck]

Package: logcheck-database
Version: 1.3.23
Severity: wishlist

This line is wrong in sudo 1.9.4+ (Debian 11+):


https://salsa.debian.org/debian/logcheck/-/blob/master/rulefiles/linux/violations.ignore.d/logcheck-sudo#L2

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

For example this real-world log event (compare "ssh X sudo Y" and "ssh X -t 
sudo Y", I think):

2022-11-23T03:27:25.170510+11:00 obese sudo: zfs-receive : 
PWD=/etc/zfs-receive ; USER=root ; COMMAND=/sbin/zfs receive -F -o 
mountpoint=/srv/backup/light -o canmount=noauto -o readonly=on obese/light

To fix the regexp, *AT LEAST* this change is needed (making TTY= optional):

-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
(TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; )?PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

However, if you look at the actual source code:


https://github.com/sudo-project/sudo/blob/SUDO_1_9_5p2/lib/eventlog/eventlog.c#L60-L68

https://github.com/sudo-project/sudo/blob/SUDO_1_9_5p2/lib/eventlog/eventlog.c#L204-L284

You can see that ALL these fields are only included if they are actually set 
("if (details->⋯ != NULL)").

At which point we might as well have something like this:

-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
((HOST|TTY|CHROOT|PWD|USER|GROUP|ENV|TSID)=[^ ;]+ ; 
)?COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

What do you think?

Note that if you want to target Debian 12+, you need to handle 2 more fields, 
"EXIT" and "SIGNAL":

-^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
TTY=(unknown|console|(pts/|tty|vc/)[[:digit:]]+) ; PWD=[^;]+ ; 
USER=[._[:alnum:]-]+( ; GROUP=[._[:alnum:]-]+)? ; 
COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sudo:[[:space:]]+[_[:alnum:].-]+ : 
((HOST|TTY|CHROOT|PWD|USER|GROUP|ENV|TSID|EXIT|SIGNAL)=[^ ;]+ ; 
)?COMMAND=((/(usr|etc|bin|sbin)/|sudoedit ).*|list)$

PS: another trivial way to confuse existing logcheck is this (missing "ENV="):

sudo HOME=/nonexistent id  # logcheck considers this a 
"Security Event"
sudo env HOME=/nonexistent id  # logcheck considers this harmless

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

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

Bug#428367: ssh-askpass-fullscreen doesn't always occupy the full screen

[Axel Beckert]

Control: tag -1 + upstream wontfix

Hi Magnus,

thanks for the bug report and sorry for the very late (~ after 15
years) reply. I just took over this package and went through the list
of open bug reports.

Magnus Therning wrote back in 2007:
> On a dual-screen setup up it only occupies one of the screens.

This is still the case with the most recent upstream version (1.2,
soon to be uploaded).

But it seems to be by design. At least in the upstream changelog is
mentioned that the handling, which screen is chosen for that, has
changed with some release.

As far as I understood the main issue is that if you have two or
more screens with different resolutions, that if you do a fullscreen
window over all screens, the main content might be hidden in a not
shown area.

Some (a bit extrem) example how I imagine this could happen with two
fictive widescreen monitors, of which one is setup vertically:

++--+
||  |
|1920x800| 800x1920 |
||  |
++  |
 |  |
 Prompt here |  |
 |  |
 |  |
 |  |
 |  |
 +--+

So marking this as "won't fix", at least from Debian's side. Feel free
to ask the current upstream about this, e.g. via
https://github.com/atj/ssh-askpass-fullscreen/issues/new

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1024549: espeakup: crashes during speech synthesis installation, snd_pcm_area_copy assertion failed

[Arnaud Rebillout]

On 23/11/2022 04:11, Samuel Thibault wrote:

Arnaud Rebillout, le lun. 21 nov. 2022 15:52:47 +0700, a ecrit:

It's fairly easy to reproduce, for me it crashes every time, although it
doesn't always crash at the same moment of the installation. The exact
moment when it crashes seems quite unpredictable.

Note that I'm running the iso in a QEMU VM on an up-to-date Debian Sid,
so that's qemu-system-x86 7.1+dfsg-2+b2 and linux-image-amd64 6.0.8-1,
in case it matters.

Every detail can matter. Since it's in a vm, normally one should be able
to reproduce it, but it seems I can't. So please provide all details:

- how exactly you start the VM, notably which audio device do you use


My command is:

kvm -m 4G -cpu host \
-device e1000,netdev=net0 \
-netdev user,id=net0,hostfwd=tcp::10022-:22,hostfwd=tcp::3389-:3389 \
-device intel-hda \
-device hda-duplex \
-spice port=5930,disable-ticketing=on \
-device virtio-serial \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-chardev spicevmc,debug=0,id=vdagent,name=vdagent \
-vga qxl \
-virtfs local,mount_tag=home,path=/home/arno,security_model=none \
-drive file=debian-testing-amd64-netinst.img,format=raw \
-boot d -cdrom debian-testing-amd64-netinst.iso

I use remote-viewer and SPICE protocol to interact with the VM.



- during installation, which choices do you make that depart from the
   default value (language, tasks, etc.)


No choices, I just press Enter and stick with the defaults.

Maybe of interest, I see some errror messages in /var/log/syslog, after 
I confirm the second screen. Here's a good chunk of logs for context, 
the actual errors are the lines with "main-menu[527]: (process:):":


Nov 23 00:55:38 debconf: Setting debconf/language to en
Nov 23 00:55:38 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb

Nov 23 00:55:38 main-menu[527]: INFO: Menu item 'localechooser' selected
Nov 23 00:55:40 debconf: Setting debconf/language to en
Nov 23 00:55:47 init: starting pid 507, tty '/dev/tty2': '-/bin/sh'
Nov 23 00:56:05 localechooser: info: Language = 'en'
Nov 23 00:56:05 localechooser: info: line=en;0;US;en_US.UTF-8;;console-setup
Nov 23 00:56:05 localechooser: info: Set debian-installer/language = 'en'
Nov 23 00:56:05 localechooser: info: Default country = 'US'
Nov 23 00:56:05 localechooser: info: Default locale = 'en_US.UTF-8'
Nov 23 00:56:05 localechooser: info: Set debian-installer/consoledisplay 
= 'console-setup'

Nov 23 00:56:05 debconf: Setting debconf/language to en
Nov 23 00:56:08 localechooser: info: Set debian-installer/country = 'US'
Nov 23 00:56:08 localechooser: info: Set debian-installer/locale = 
'en_US.UTF-8'
Nov 23 00:56:08 localechooser: info: System locale 
(debian-installer/locale) = 'en_US.UTF-8'
Nov 23 00:56:08 main-menu[527]: (process:538): ls: 
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory

Nov 23 00:56:08 main-menu[527]: (process:538): sh: missing ]
Nov 23 00:56:08 main-menu[527]: (process:538): ls: 
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory

Nov 23 00:56:08 main-menu[527]: (process:538): sh: missing ]
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb

Nov 23 00:56:08 main-menu[527]: INFO: Menu item 'brltty-udeb' selected
Nov 23 00:56:08 main-menu[527]: WARNING **: Unable to set title for 
brltty-udeb.
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb

Nov 23 00:56:08 main-menu[527]: INFO: Menu item 'espeakup-udeb' selected
Nov 23 00:56:10 main-menu[527]: (process:1753): ls: 
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory

Nov 23 00:56:10 main-menu[527]: (process:1753): sh: missing ]
Nov 23 00:56:10 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:10 main-menu[527]: INFO: Falling back to the package 
description for brltty-udeb
Nov 23 00:56:10 main-menu[527]: INFO: Menu item 'console-setup-udeb' 
selected


The errors related to mbrola and sh come from 
debian/espeakup-udeb.restart in src:espeakup. I don't know if it's 
relevant to the issue at hand though.




Yes, I really doubt the bug is in espeakup (or pcaudiolib) itself since
these functions are really deep inside alsa, but we have to investigate
to be sure about it.


Just to confirm, I grabbed the debian-testing-amd64-netinst.iso from 
today (2022-11-22) and I can confirm that I can still reproduce the issue.


Another interesting detail is that restarting espeakup makes it speaks 
again, like if nothing happens. So I think it could be useful to have 
something monitor the daemon and restart it in case it crashes. Would 
make it more reliable overall, I suppose. 

Bug#1022307: [Debian-med-packaging] Bug#1022307: status on t_coffee causing biopython ftbfs

[Charles Plessy]

Le Tue, Nov 22, 2022 at 11:54:48PM +0100, Étienne Mollier a écrit :
> 
> Hi, mostly retitling the open entry against biopython for the
> sake of clarity, and also pinging both bugs to reset auto-
> removal counters.  We don't have much news from t_coffee
> upstream to day unfortunately.  Maybe it will be necessary to
> revert the t-coffee version bump for the upcoming Debian release
> or do people see other options?

Hi Étienne,

I think that we do not have enough evidence that t_coffee was properly
tested on other architectures than amd64.  Even though a particular
version may build fine, and let biophython pass its tests, we do not
know if t_coffee produces sound results on these architectures.  Unless
we know or hear from an ARM user, I would recommend to play safe and
only distribute it on amd64 for this release.

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1017881: ITA: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes

[Sean Whitton]

Hello,

On Sat 15 Oct 2022 at 05:36PM GMT, Stefan Kangas wrote:

> retitle 1017881 ITA: unclutter-xfixes -- hide the X mouse cursor after
> a period of inactivity, using XFixes
> owner 1017881 !
> thanks
>
> Hi,
>
> Thanks for your work on the unclutter-xfixes package. I intend to adopt
> it, and work on getting the new upstream release into bookworm.
>
> You will be able to track my progress at:
> https://salsa.debian.org/skangas/unclutter-xfixes

May I ask if you'll be ready with this one soon?  The freeze is coming.

Thanks.

-- 
Sean Whitton

Bug#1020851: elpa-ement: fails to install along emacs

[Sean Whitton]

Hello,

On Tue 22 Nov 2022 at 05:39PM +01, Andreas Beckmann wrote:

> On 28/09/2022 16.55, Sean Whitton wrote:
>> transient is included in Emacs 28 so I'm inclined to leave this to fix
>> itself when Emacs 28 migrates.
>
> Can't this be expressed as a package relationship?
> e.g. Depends: emacs-el (>= 1:28)

It's against the Emacsen Team policy to have a hard dependency on Emacs
-- instead, it's in Recommends.  So I'd prefer not to add a dependency
that I'm only going to have to remove in a few weeks when Emacs
migrates.  But if you think this bug is getting in the way then I can
add it.

-- 
Sean Whitton

Bug#1024672: slim: New upstream

[David (Plasma) Paul]

Source: slim
Version: 1.3.6-5.3
Severity: wishlist

Dear Maintainer,

Please consider switching the slim package's upstream to the new
development being done by Rob Pearce at
.

To quote him on that page:

"The SLiM project used to be hosted on Berlios.de with a mirror on
SourceForge. Then the code got moved to Github. Then all the
maintainers lost interest and it died. Nine years later, I'm still
using it as I find it the most easily configurable, most lightweight
option for the small Linux systems I build. But with upstream being
dead and Gentoo needing 13 patch files to make it work, there was a
risk it would vanish from the repository. So I've forked it, applied
all the patches, plus some of my own, and started my own spin-off here."


-- 
Plasma

Bug#1024671: poke: SEGFAULT when writing array of arrays to buffer

[Agathe Porte]

Package: poke
Version: 2.4+dfsg-1
Severity: important
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

When "poking" with the tutorial of GNU poke and its SBM image format,
the program fails to write arrays of arrays into ios and fails:


 _
 ---'   __\___
__)  GNU poke 2.4
__)
   __)
 ---.___)

Copyright (C) 2019-2022 The poke authors.
License GPLv3+: GNU GPL version 3 or later.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Powered by Jitter 0.9.284.
Perpetrated by Jose E. Marchesi.

For help, type ".help".
Type ".exit" to leave the program.
(poke) .mem img
The current IOS is now `*img*'.
(poke) dump
76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
:          
0010:          
0020:          
0030:          
0040:          
0050:          
0060:          
0070:          
(poke) string @ 0#B = "SBM"
(poke) dump
76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
: 5342 4d00        SBM.
0010:          
0020:          
0030:          
0040:          
0050:          
0060:          
0070:          
(poke) byte @ 3#B = 5
(poke) byte @ 4#B = 7
(poke) dump
76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
: 5342 4d05 0700       SBM.
0010:          
0020:          
0030:          
0040:          
0050:          
0060:          
0070:          
(poke) var c = [0xffUB,0x42UB,0x13UB]
(poke) var l = [c,c,c,c,c]
(poke) var i = [l,l,l,l,l,l,l]
(poke) byte[3][5][7] @ 5#B = i
(poke) dump
76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
: 5342 4d05 0700       SBM.
0010:          
0020:          
0030:          
0040:          
0050:          
0060:      00ff 4213   B...
0070:          
(poke) c
[1]11989 segmentation fault  poke

As you can see, the memory is not correctly written, and attempting to
print a value after attempting to write to the memory results in a
SEGFAULT.

I suspect that the error starts when the request to write the array of
arrays is initiated, but does not result in the memory buffer being
modified. I guess the interpreter is writing the content somewhere else
than in the buffer.

This issue was already reported upstream by another user in 2021:
https://sourceware.org/bugzilla/show_bug.cgi?id=28380

However I am not able to know if this bug is from upstream, or if the
user that reported the upstream bug was also using the Debian package.

If one can reproduce this error, eventually on another distro, we should
notify upstream that the error is still happening.

Thanks,

Agathe.

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

Kernel: Linux 6.0.0-4-amd64 (SMP 

Bug#1024275: [Pkg-utopia-maintainers] Bug#1024275: network-manager-openvpn: can't connect to vpn after last update: can't set proper cipher.

[Daniel Serpell]

Hi Michael,

I don't know what changed, but now I can set the cypher option back to
"default" and the connection works fine, so this means this bug was
fixed. Please, you can close this bug.

Thank you, and regards.

Daniel.

On Tue, Nov 22, 2022 at 2:44 PM Michael Biebl  wrote:
>
> Control: severity -1 normal
> Control: notforwarded -1
>
> Am 16.11.22 um 22:54 schrieb Daniel Serpell:
> > Package: network-manager-openvpn
> > Version: 1.10.2-1
> > Severity: normal
> >
> > Dear maintainer,
> >
> > After upgrading to 1.10.2-1, I can't connect to the VPN anymore.
> >
> > This is the logs from NetworkManager:
> >
> >nm-openvpn[]: [] Peer Connection Initiated with 
> > [AF_INET]:
> >nm-openvpn[]: OPTIONS ERROR: failed to negotiate cipher with server.  
> > Add the server's cipher ('AES-256-CBC') to --data-ciphers (currently 
> > 'AES-256-GCM') if you want to connect to this server.
> >nm-openvpn[]: ERROR: Failed to apply push options
> >nm-openvpn[]: Failed to open tun/tap interface
> >nm-openvpn[]: SIGUSR1[soft,process-push-msg-failed] received, process 
> > restarting
> >
> > Trying to change the cipher to AES-256-CBC in network properties does not 
> > work, it reverts back to AES-256-GCM.
>
> I recreated the failing OpenVPN connection and I can't reproduce the
> problem anymore.
> I thus closed the upstream issue and dropped the forwarded meta data.
>
> My recommendation, if you can still reproduce the issue, is to file the
> issue upstream [1] yourself. It's likely that upstream has further question.
>
> Regards,
> Michael
> [1] https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/
>

Bug#1012950: itk-4.y buildability status

[Étienne Mollier]

Hi,

I've been reviewing whether it would be feasible at t time to
fallback to gcc-11 for insighttoolkit4, but I hit another build
problem.  I ended up disabling python3 bindings, at last.

The itk-4.y branch on salsa currently builds properly on Debian
sid amd64, but I stopped producing the insighttoolkit4-python3
package, as it is now empty; I left a note in d/NEWS about that.
Unless there are objections, I consider uploading ITK4 in
unstable; we'll see whether it manages to make it to testing
actually.

insighttoolkit4-python3 does not seem to have much reverse
dependencies, so I guess this binary package can be safely
removed, if the rest were to stay around.

In hope this helps,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/6, please excuse my verbosity.
On air: Stratovarius - A Million Light Years Away


signature.asc
Description: PGP signature

Bug#1011500: tuxcmd-modules: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

On 2022-11-18, Chris Lamb wrote:
> I've just uploaded an updated version of tuxcmd-modules 0.6.70+ds-5.1
> to DELAYED/3. This variant of the upload actually includes the fix for
> #941296 which was missed when preparing the upload.

This hasn't yet landed in the archive, was it actually uploaded to
DELAYED/3?

It could have been uploaded to DELAYED/0 (e.g. without delay) as a QA
upload rather than as an NMU...

>   tuxcmd-modules (0.6.70+ds-5.1) unstable; urgency=medium
>   .
> * Non-maintainer upload.
> * Apply a patch by Vagrant Cascadian to ensure that tuxcmd-modules does 
> not
>   embed build paths in various binaries. (Closes: #1011500)
> * Apply a patch by Helmut Grohne to make it possible to cross-build
>   tuxcmd-modules. (Closes: #941296)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1022307: status on t_coffee causing biopython ftbfs

[Étienne Mollier]

Control: retitle 1022307 python-biopython: FTBFS: tests choke on t_coffee

Hi, mostly retitling the open entry against biopython for the
sake of clarity, and also pinging both bugs to reset auto-
removal counters.  We don't have much news from t_coffee
upstream to day unfortunately.  Maybe it will be necessary to
revert the t-coffee version bump for the upcoming Debian release
or do people see other options?

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Frost* - Hyperventilate


signature.asc
Description: PGP signature

Bug#1023446: libhdf5-openmpi-dev: h5pcc configured as static build

[Gilles Filippini]

Hi Drew,

Drew Parsons a écrit le 15/11/2022 à 16:28 :
h5py is building fine against the shared libraries with 
HDF5_USE_SHLIB=yes, but leaves a question about rpath.


Notice that `h5pcc --showconfig -shlib` includes
"-L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -lhdf5_hl -lhdf5 -Wl,-rpath 
-Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi"


The h5py python extensions get linked with this, such the h5py .so files 
are generated with

   NEEDED   libhdf5_openmpi.so.103
   RUNPATH  /usr/lib/x86_64-linux-gnu/hdf5/openmpi

In normal package policy we try to remove RUNPATH, and in the case of 
the hdf5 libraries libhdf5_openmpi.so.103 is available in the standard 
library path at /usr/lib/x86_64-linux-gnu/.  In fact 
libhdf5_openmpi.so.103 is not even found in 
/usr/lib/x86_64-linux-gnu/hdf5/openmpi (instead libhdf5.so is found 
there as a symlink to ../../libhdf5_openmpi.so).


As far as I can tell, the -rpath entry in the h5pcc configuration is 
redundant, possibly even wrong (since the linked library is 
libhdf5_openmpi.so.103, not the more general libhdf5.so)


Should rpath be removed from the h5pcc shlib configuration?


I've just uploaded hdf5 1.10.8+repack-2 which should fix this issue.

Best,

_g.

Bug#1024648: elpa-snakemake: fails to install with emacs 27: misses 'transient'

[Andreas Beckmann]

On 22/11/2022 18.40, Diane Trout wrote:

On Tue, 2022-11-22 at 18:24 +0100, Andreas Beckmann wrote:


There needs to be either a
   Depends: emacs-el (>= 1:28)
or an equivaent
   Breaks: (emacs-el (<< 1:28)
or the installation must be skipped if emacs is too old.


So it looks like elpa-snakemake depends on the transient package which
is currently elpa-transient and in included in emacs 28.

So what do you think of this instead?

Depends: emacs-el (>= 1:28) | elpa-transient,


Good question. Hmm, well, I know nothing about emacs or its packaging. ;-)

But if emacs-el (or -common?) bundles extensions (or however you call 
them), especially ones that were previously packaged separately, it 
should probably have versioned Provides (and maybe versioned Breaks, 
too) for them. (Cf. perl, perl-base which does the same.)

Not sure whether these should be in -el or -common ...

If these Provides were available, elpa-snakemake wouldn't need to know 
about the packaging details of other packages and could just use

  Depends: elpa-transient


Andreas

Bug#1024670: tiff: CVE-2022-2519 CVE-2022-2520 CVE-2022-2521 CVE-2022-2953

[Amin Bandali]

Source: tiff
Version: 4.4.0-5
Severity: important
Tags: security

Hello,

The following vulnerabilities had been published for tiff:

CVE-2022-2519[0]:
| There is a double free or corruption in rotateImage() at
| tiffcrop.c:8839 found in libtiff 4.4.0rc1

https://gitlab.com/libtiff/libtiff/-/issues/423
https://gitlab.com/libtiff/libtiff/-/merge_requests/378
https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf
https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba

CVE-2022-2520[1]:
| A flaw was found in libtiff 4.4.0rc1. There is a sysmalloc assertion
| fail in rotateImage() at tiffcrop.c:8621 that can cause program crash
| when reading a crafted input.

https://gitlab.com/libtiff/libtiff/-/issues/424
https://gitlab.com/libtiff/libtiff/-/merge_requests/378
https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf
https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba

CVE-2022-2521[2]:
| It was found in libtiff 4.4.0rc1 that there is an invalid pointer free
| operation in TIFFClose() at tif_close.c:131 called by tiffcrop.c:2522
| that can cause a program crash and denial of service while processing
| crafted input.

https://gitlab.com/libtiff/libtiff/-/issues/422
https://gitlab.com/libtiff/libtiff/-/merge_requests/378
https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf
https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba

CVE-2022-2953[3]:
| LibTIFF 4.4.0 has an out-of-bounds read in extractImageSection in
| tools/tiffcrop.c:6905, allowing attackers to cause a denial-of-service
| via a crafted tiff file. For users that compile libtiff from sources,
| the fix is available with commit 48d6ece8.

https://gitlab.com/libtiff/libtiff/-/issues/414
https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf
https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba

I saw they are marked as "unimportant" in Debian's security tracker,
but I thought I would file this bug report anyway.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2519
https://www.cve.org/CVERecord?id=CVE-2022-2519
[1] https://security-tracker.debian.org/tracker/CVE-2022-2520
https://www.cve.org/CVERecord?id=CVE-2022-2520
[2] https://security-tracker.debian.org/tracker/CVE-2022-2521
https://www.cve.org/CVERecord?id=CVE-2022-2521
[3] https://security-tracker.debian.org/tracker/CVE-2022-2953
https://www.cve.org/CVERecord?id=CVE-2022-2953

Please adjust the affected versions in the BTS as needed.

Best,
amin

Bug#1023495: transition: ruby3.1

[Sebastian Ramacher]

On 2022-11-22 21:53:31 +0100, Paul Gevers wrote:
> Hi Lucas,
> 
> On 22-11-2022 17:03, Lucas Kanashiro wrote:
> > After discussing with Antonio, since our deadline to finish the
> > transition is approaching, we decided to already enable ruby3.1 as the
> > default and remove ruby3.0 in a single step.
> 
> I may be remembering wrong (it's a bit late), but isn't the change of the
> default a forward rebuild, while removal is a backward rebuild (I mean in
> the dependency tree)? If that's true, I think doing it in two steps is
> easier to manage, as packages can then migrate on their own and don't need a
> lock step migration.

That's correct. I'd prefer to handle this with two trackers.

Cheers
-- 
Sebastian Ramacher

Bug#1023550: transition: qcustomplot

[Sebastian Ramacher]

On 2022-11-22 21:41:15 +0100, Filippo Rusconi wrote:
> Greetings Sebastian,
> 
> On Sat, Nov 19, 2022 at 08:17:41PM +0100, Sebastian Ramacher wrote:
> > Hi Filippo
> > 
> > On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote:
> > > Greetings Sebastian,
> > > 
> > > Thank your for your message.
> > > 
> > > On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote:
> > > > Control: tags -1 moreinfo
> > > > Control: forwarded -1 
> > > > https://release.debian.org/transitions/html/auto-qcustomplot.html
> > > >
> > > > Hi Filippo
> > > >
> > > > On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote:
> > > > > Package: release.debian.org
> > > > > Severity: normal
> > > > > User: release.debian@packages.debian.org
> > > > > Usertags: transition
> > > > > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, 
> > > > > debian-science-maintain...@lists.alioth.debian.org
> > > > >
> > > > > (please explain about the transition: impacted packages, reason, ...
> > > > >  for more info see: 
> > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions)
> > > > >
> > > > > Greetings,
> > > > >
> > > > > Fundamental reason: Qt5 and Qt6 are in the archive.
> > > > >
> > > > > I am requesting a transition from package libqcustomplot2.0 to
> > > > > libqcustomplot2.1. Source package is qcustomplot. The change involves 
> > > > > a change
> > > > > in the library name itself, from libqcustomplot2.0 to both 
> > > > > libQCustomPlot2.1 and
> > > > > libQCustomPlotQt6.so.2.1.0 (see below).
> > > > >
> > > > > I have prepared the packaging in the following git repos branch:
> > > > >
> > > > > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6
> > > 
> > > [...]
> > > 
> > > > > For the libs under my control, the transition is already prepared and 
> > > > > these
> > > > > projects are going to be linking against the Qt6-built library, 
> > > > > contrary to all
> > > > > the other packages detailed below.
> > > > >
> > > > > For the other libs listed above, I have already checked that they 
> > > > > would build if
> > > > > some modifications were performed. I have already git branches ready 
> > > > > for the
> > > > > packages under git VCS. For the others (source deb), I have patches 
> > > > > available.
> > > > >
> > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot for 
> > > > > many and
> > > > > also sometimes use the CMake-based configuration involving first
> > > > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot 
> > > > > formalism for
> > > > > the linker.
> > > > >
> > > > > That is: almost one- or two-liner patches.
> > > >
> > > > Could you please file bugs for those so that maintainers are aware?
> > > 
> > > Yes, I'll do that. I have already informed them individually of the 
> > > process and
> > > provided them with the relevant patch.
> > 
> > Thanks! Please go ahead with the transition.
> 
> I just uploaded the package to unstable. I have not closed the bug yet, 
> waiting
> to check that everything goes fine.

Transition bugs are usually closedonce all old binary packages got
removed from testing.

Cheers
-- 
Sebastian Ramacher

Bug#1024669: libarchive: CVE-2022-36227: Null pointer dereference in archive_write.c

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.6.0-1
Severity: normal
Tags: security upstream
Forwarded: https://github.com/libarchive/libarchive/issues/1754
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libarchive, filling
downstream for tracking.

CVE-2022-36227[0]:
| In libarchive 3.6.1, the software does not check for an error after
| calling calloc function that can return with a NULL pointer if the
| function fails, which leads to a resultant NULL pointer dereference
| or, in some cases, even arbitrary code execution.


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-2022-36227
https://www.cve.org/CVERecord?id=CVE-2022-36227

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1024607: update

[yin846]

I installed qemu and virt-manager from bullseye-backports and the issue went 
away. I did not try to replicate this issue on bookworm or sid but I think it's 
okay to assume that this issue doesn't affect them because their qemu version 
is newer.

$ qemu-system-x86_64 --version
QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2~bpo11+3)

Bug#1024668: curl: -dev packages are no longer Multi-Arch: same

[Simon McVittie]

Control: tags -1 + patch

On Tue, 22 Nov 2022 at 21:28:48 +, Simon McVittie wrote:
> The various curl -dev packages are no longer Multi-Arch: same
...
> I'm currently testing patches that I'm hoping will resolve this and allow
> reverting the recent change that dropped the Multi-Arch: same field.

Please consider the attached.

build-Divide-mit-krb5-gssapi-link-flags-between-LDFLAGS-a.patch could
be sent upstream if you want (it seems to be going in the direction of
what upstream intended, and is coincidentally also useful for resolving
this downstream bug).

Thanks,
smcv
>From db11b28ac74bc201b2e8429fd6d834afdd343f8a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 22 Nov 2022 21:21:48 +
Subject: [PATCH 1/2] Add patches to make curl-config Multi-Arch co-installable
 again

Signed-off-by: Simon McVittie 
---
 ...LDFLAGS-from-curl-config-static-libs.patch | 42 +++
 ...-gssapi-link-flags-between-LDFLAGS-a.patch | 32 ++
 debian/patches/series |  2 +
 3 files changed, 76 insertions(+)
 create mode 100644 debian/patches/Remove-curl-s-LDFLAGS-from-curl-config-static-libs.patch
 create mode 100644 debian/patches/build-Divide-mit-krb5-gssapi-link-flags-between-LDFLAGS-a.patch

diff --git a/debian/patches/Remove-curl-s-LDFLAGS-from-curl-config-static-libs.patch b/debian/patches/Remove-curl-s-LDFLAGS-from-curl-config-static-libs.patch
new file mode 100644
index 0..721a6b103
--- /dev/null
+++ b/debian/patches/Remove-curl-s-LDFLAGS-from-curl-config-static-libs.patch
@@ -0,0 +1,42 @@
+From: Simon McVittie 
+Date: Tue, 22 Nov 2022 21:20:51 +
+Subject: Remove curl's LDFLAGS from curl-config --static-libs
+
+On current Debian bookworm, the LDFLAGS consist of
+-L/usr/lib/${triplet}/mit-krb5 originating from
+`pkg-config --libs-only-L mit-krb5-gssapi` from krb5-multidev, plus
+some linker options that are intended for curl itself rather than for
+dependent packages. None of these are really desirable, and they create
+divergence between architectures that would prevent libcurl-*-dev from
+being Multi-Arch: same.
+
+The -L flag is not really needed, for the same reason that -L@libdir@
+isn't. curl Build-Depends on libkrb5-dev, which doesn't need a special
+-L flag to find libgssapi_krb5, and the various libcurl-*-dev packages
+have Suggests on libkrb5-dev rather than on krb5-multidev for static
+linking.
+
+The other options (currently `-Wl,-z-relro -Wl,-z,now`) are intended
+for libcurl itself, and if dependent packages want those options then
+they should set them from their own packaging.
+
+Bug-Debian: https://bugs.debian.org/1024668
+Forwarded: not-needed
+Signed-off-by: Simon McVittie 
+---
+ curl-config.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/curl-config.in b/curl-config.in
+index 5bf4256..620bff6 100644
+--- a/curl-config.in
 b/curl-config.in
+@@ -165,7 +165,7 @@ while test $# -gt 0; do
+ 
+ --static-libs)
+ if test "X@ENABLE_STATIC@" != "Xno" ; then
+-  echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic @LDFLAGS@ @LIBCURL_LIBS@
++  echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic @LIBCURL_LIBS@
+ else
+   echo "curl was built with static libraries disabled" >&2
+   exit 1
diff --git a/debian/patches/build-Divide-mit-krb5-gssapi-link-flags-between-LDFLAGS-a.patch b/debian/patches/build-Divide-mit-krb5-gssapi-link-flags-between-LDFLAGS-a.patch
new file mode 100644
index 0..6a16f0589
--- /dev/null
+++ b/debian/patches/build-Divide-mit-krb5-gssapi-link-flags-between-LDFLAGS-a.patch
@@ -0,0 +1,32 @@
+From: Simon McVittie 
+Date: Tue, 22 Nov 2022 20:43:41 +
+Subject: build: Divide mit-krb5-gssapi link flags between LDFLAGS and LIBS
+
+From the comments nearby about not having --libs-only-L, it looks as
+though the intention was to apply a split like this to all dependency
+libraries where possible, and the only reason it was not done for
+Kerberos is that krb5-config doesn't have that feature and pkg-config
+was originally not supported here. For example, zlib, libssh and librtmp
+all have their flags from pkg-config split in this way.
+
+Now that pkg-config is supported here, we can do the intended split.
+
+Signed-off-by: Simon McVittie 
+---
+ configure.ac | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 445b3f9..b5408d2 100644
+--- a/configure.ac
 b/configure.ac
+@@ -1853,7 +1853,8 @@ if test x"$want_gss" = xyes; then
+gss_libs=`$GSSAPI_ROOT/bin/$host_alias-krb5-config --libs gssapi`
+LIBS="$gss_libs $LIBS"
+ elif test "$PKGCONFIG" != "no" ; then
+-   gss_libs=`$PKGCONFIG --libs mit-krb5-gssapi`
++   LDFLAGS="$LDFLAGS `$PKGCONFIG --libs-only-L mit-krb5-gssapi`"
++   gss_libs=`$PKGCONFIG --libs-only-l mit-krb5-gssapi`
+LIBS="$gss_libs $LIBS"
+ elif test -f "$KRB5CONFIG"; then
+dnl krb5-config doesn't have 

Bug#1024660: ITP: ranges -- Command line program to extract ranges from various types of lists, e.g. integer numbers, dates, IP and MAC addresses.

[Sandro-Alessio Gierens]

On 11/22/22 21:48, Sandro-Alessio Gierens wrote:
> I mean it is probably also possible to write a Python script version of
> most other pipe tools like wc, uniq, ... but it's still massively
> helpful to have those tools on hand everywhere you go. Don't get me
> wrong I'm not saying my program would be as useful as any of the
> coreutils. Compiling lists into ranges is a rarer use-case, but I had to
> implement these kinds of scripts often enough to be convinced, that I
> will be helpful for more than one person :)
ups, typo: ... that *it* will be helpful for more than one person :)

Bug#1024668: curl: -dev packages are no longer Multi-Arch: same

[Simon McVittie]

Source: curl
Version: 7.86.0-2
Severity: normal

This is essentially a continuation of https://bugs.debian.org/731998,
which was fixed back in 2017 (thanks!) but has recently regressed.

The various curl -dev packages are no longer Multi-Arch: same, which is
annoying when setting up a build environment where it should be possible
to compile libcurl-dependent projects for both amd64 and i386 (or other
pairs of architectures). In particular, the Steam Runtime's SDK includes
both libcurl4-gnutls-dev:amd64 and libcurl4-gnutls-dev:i386 in versions
based on Debian 10 and 11, and I'd like to be able to continue to do that
with Debian 12.

>From comparing the binary package contents, it looks as though the only
difference is that /usr/bin/curl-config contains

-L/usr/lib/x86_64-linux-gnu/mit-krb5

(or the equivalent for i386 or whatever other architecture) in a list of
libraries used for static linking.

This seems unnecessary: curl Build-Depends on libkrb5-dev, which allows
-lgssapi_krb5 to be found without any special LDFLAGS, and similarly
libcurl-*-dev Suggests libkrb5-dev.

I'm currently testing patches that I'm hoping will resolve this and allow
reverting the recent change that dropped the Multi-Arch: same field.

smcv

Bug#974868: samba-vfs-modules: Still causing issues - at least on armv5tel/armel

[ArtMG]

On 17 November 2022 8:38 PM, Michael Tokarev  wrote:
> Do you have ability to compile samba?  If yes (maybe with a debian package),
> can you please try the attached patch?  It removes the useless and actually
> wrong check for the off_t overflowing size_t.
> Attachments:
> * fruit-disable-useless-size_t-overflow-check.patch

Thanks for the patch Michael, I compiled and ran and although it got out of the 
disk size functions this time, it still slipped up with 

../../source3/smbd/service.c:787(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service 
TimeMachineBackup, path /mnt/HDD/TimeMachine

I do appreciate you cutting this patch for this issue, however I feel like I've 
been down this road before with these issues. Push a fix here, and if a new 
issue doesn't pop up over there straight away, give it a version or three and 
it will eventually. Hence my reference to whack-a-mole. 

As Andrew points out, this is somewhat outlying as test-cases go. There are few 
people wanting to rebuild a 32-bit instance of their backup mechanism for each 
point revision of a large and actively-developed service like samba.

I see no reason, personally, to push for developer attention when the solution 
is as simple as 'switch to 64-bit OS', and then even OLD versions in all the 
repos work just fine. Although I do not have statistics to hand, I feel that we 
must be far enough along the migration curve on the journey from 32- to 64-bit 
systems, especially when it comes to a core-yet-commodity infrastructure 
service like samba, to warrant letting go of legacy.

Thanks for your good will and effort, nonetheless.

Bug#1024613: GCstar versions

[Kerenoc Kerenoc]

Hello,

As the upstream maintainer of GCstar and preparing a 1.8.0 version, I
support updating the GCstar packages for Debian.

Using the Debian packaging rules from
https://gitlab.com/GCstar/GCstar/-/tree/main/gcstar/packages/debian , I
used Gitlab CI to generate a .deb package
https://gitlab.com/GCstar/GCstar/-/packages/10814845 that I successfully
tested on Devuan, Ubuntu and Debian (with a warning on a proprietary
license). I can modify the rules to comply to the requirements necessary to
revive GCstar on Debian.

Regards

   Kérénoc

Bug#1024549: espeakup: crashes during speech synthesis installation, snd_pcm_area_copy assertion failed

[Samuel Thibault]

Hello,

Arnaud Rebillout, le lun. 21 nov. 2022 15:52:47 +0700, a ecrit:
>   espeakup: pcm.c:3237: snd_pcm_area_copy: Assertion `dst < src || dst >= src 
> + bytes' failed.
>   Aborted

Ouch!

> It's fairly easy to reproduce, for me it crashes every time, although it
> doesn't always crash at the same moment of the installation. The exact
> moment when it crashes seems quite unpredictable.
> 
> Note that I'm running the iso in a QEMU VM on an up-to-date Debian Sid,
> so that's qemu-system-x86 7.1+dfsg-2+b2 and linux-image-amd64 6.0.8-1,
> in case it matters.

Every detail can matter. Since it's in a vm, normally one should be able
to reproduce it, but it seems I can't. So please provide all details:

- how exactly you start the VM, notably which audio device do you use
- during installation, which choices do you make that depart from the
  default value (language, tasks, etc.)

> I'l try to debug further, but I'm not familiar with these low-level
> bits. The assertion error happens in the alsa-lib source package (binary
> package libasound2 is my guess), as you might have noticed.

Yes, I really doubt the bug is in espeakup (or pcaudiolib) itself since
these functions are really deep inside alsa, but we have to investigate
to be sure about it.

Samuel

Bug#1024667: ITP: libzonemaster-ldns-perl -- Perl interface to the ldns library

[Étienne Mollier]

Package: wnpp
Severity: wishlist
Owner: Étienne Mollier 
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-p...@lists.debian.org

* Package name: libzonemaster-ldns-perl
  Version : 2.2.2
  Upstream Author : The Swedish Internet Foundation and AFNIC
* URL : https://github.com/zonemaster/zonemaster-ldns
* License : BSD-2-Clause
  Programming Lang: Perl
  Description : Perl interface to the ldns library

 This module provides a Perl interface to the ldns library from
 NLnet Labs and depends on it being available. The module can
 either compile and use those libraries internally or link to
 already available ldns library given that the version is high
 enough. In both cases it relies on a sufficiently recent version
 of OpenSSL being present.
 .
 This module is written as part of the Zonemaster project, and
 therefore primarily exposes the functionality needed for
 that. Since Zonemaster is a diagnostic tool, that means the
 functions most used are those for looking things up and
 inspecting them.
 .
 If you want a module that specifically aims to be a complete and
 transparent interface to ldns, DNS::LDNS is a better fit than
 this module.

This package came up while re-establishing contact with
Zonemaster upstream developpers[1].  Other Zonemaster related
packages will likely need it with their newer versions.

It should be maintained under Debian Perl team[2,3] umbrella.

[1]: https://github.com/zonemaster/zonemaster-engine/issues/1149
[2]: https://lists.debian.org/debian-perl/
[3]: https://salsa.debian.org/perl-team/modules/packages

(Mail resent after the original one didn't raise an entry
yesterday.  Hope this won't cause a duplicate.)

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Transatlantic - Black as the Sky


signature.asc
Description: PGP signature

Bug#1024611: rocminfo FTCBFS: confused architecture terminology

[Étienne Mollier]

Control: tag -1 confirmed pending
Control: forwarded -1 https://github.com/RadeonOpenCompute/rocminfo/issues/60

Hi Helmut,

Helmut Grohne, on 2022-11-22:
> rocminfo fails to cross build from source, because it passes invalid
> compiler flags. The detection is broken due to confusing architecture
> terminologies. The system we are building on is called "build" in Debian
> and GNU, but for cmake it is called "host". The system we are building
> for is called "host" in Debian and GNU, but for cmake it is empty (it
> doesn't have a name). I'm attaching a patch for your convenience and
> hope to not leave too much confusion.

After a small adjustment to the original patch, I could get
rocminfo to cross build from amd64 to aarch64 host; the -m64 was
still around without adjustment.  I applied your patch and it
should make it to the next upload of rocminfo.

Thank you for your analysis, always a pleasure to learn
something new and greatly improve packaging in a same move.
Please continue.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Monomyth - Collision


signature.asc
Description: PGP signature

Bug#1023846: transition: gdal

[Paul Gevers]

Hi Bas,

On 22-11-2022 11:26, Sebastiaan Couwenberg wrote:
How can we schedule autopkgtest runs for testing with gdal & 
libgdal-grass from unstable?


Most of the time britney and autopkgtest handle it automatically if 
dependencies are rightly versioned (although not ideally during 
transitions). If you see issues more than a day after a binNMU, please 
be specific and let us know, then we can check and if needed schedule 
manually.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023787: transition: liblxqt

[Paul Gevers]

Hi,

On 21-11-2022 01:05, ChangZhuo Chen (陳昌倬) wrote:

All affected packages have been uploaded to unstable. Sorry for the
mess.


Thanks. Let's see if they can migrate on their own to testing in the 
following days.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023495: transition: ruby3.1

[Paul Gevers]

Hi Lucas,

On 22-11-2022 17:03, Lucas Kanashiro wrote:
After discussing with Antonio, since our deadline to finish the 
transition is approaching, we decided to already enable ruby3.1 as the 
default and remove ruby3.0 in a single step.


I may be remembering wrong (it's a bit late), but isn't the change of 
the default a forward rebuild, while removal is a backward rebuild (I 
mean in the dependency tree)? If that's true, I think doing it in two 
steps is easier to manage, as packages can then migrate on their own and 
don't need a lock step migration.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024660: ITP: ranges -- Command line program to extract ranges from various types of lists, e.g. integer numbers, dates, IP and MAC addresses.

[Sandro-Alessio Gierens]

Hi Scott,

On 11/22/22 20:48, Scott Kitterman wrote:
> The package name is very generic.  I would pick something more specific.

Any suggestions? Since it's mostly supposed to be used in Bash pipes I
aimed for something short, and since that name doesn't appear to be used
on any unix like system: https://command-not-found.com/ranges I though I
go for it :)

> Also, I suspect the speed advantage would be less significant if you used 
> SubnetTree 
> (python3-subnettree), which does all the hard work in C.
Good to know that such a package exists! From looking at the README I
don't immediately see that one could write such a script with it, but I
suppose it is possible. That would only solve the problem for IPs though.
> Is this really needed?

But the thing with the Python module is exactly my point. Sure, it is
possible to write a Python script when you stumble across a use-case,
and that is what everybody seems to be doing. But I think compiling
lists into ranges is a generic enough problem, that a ready to use CLI
tool makes sense. Nobody should waste their time re-implementing the
same thing again and again.

I mean it is probably also possible to write a Python script version of
most other pipe tools like wc, uniq, ... but it's still massively
helpful to have those tools on hand everywhere you go. Don't get me
wrong I'm not saying my program would be as useful as any of the
coreutils. Compiling lists into ranges is a rarer use-case, but I had to
implement these kinds of scripts often enough to be convinced, that I
will be helpful for more than one person :)

Bug#1023550: transition: qcustomplot

[Filippo Rusconi]

Greetings Sebastian,

On Sat, Nov 19, 2022 at 08:17:41PM +0100, Sebastian Ramacher wrote:

Hi Filippo

On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote:

Greetings Sebastian,

Thank your for your message.

On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> Control: forwarded -1 
https://release.debian.org/transitions/html/auto-qcustomplot.html
>
> Hi Filippo
>
> On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, 
debian-science-maintain...@lists.alioth.debian.org
> >
> > (please explain about the transition: impacted packages, reason, ...
> >  for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions)
> >
> > Greetings,
> >
> > Fundamental reason: Qt5 and Qt6 are in the archive.
> >
> > I am requesting a transition from package libqcustomplot2.0 to
> > libqcustomplot2.1. Source package is qcustomplot. The change involves a 
change
> > in the library name itself, from libqcustomplot2.0 to both 
libQCustomPlot2.1 and
> > libQCustomPlotQt6.so.2.1.0 (see below).
> >
> > I have prepared the packaging in the following git repos branch:
> >
> > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6

[...]

> > For the libs under my control, the transition is already prepared and these
> > projects are going to be linking against the Qt6-built library, contrary to 
all
> > the other packages detailed below.
> >
> > For the other libs listed above, I have already checked that they would 
build if
> > some modifications were performed. I have already git branches ready for the
> > packages under git VCS. For the others (source deb), I have patches 
available.
> >
> > The modifications are lean: change -lqcustomplot to -lQCustomPlot for many 
and
> > also sometimes use the CMake-based configuration involving first
> > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot formalism 
for
> > the linker.
> >
> > That is: almost one- or two-liner patches.
>
> Could you please file bugs for those so that maintainers are aware?

Yes, I'll do that. I have already informed them individually of the process and
provided them with the relevant patch.


Thanks! Please go ahead with the transition.


I just uploaded the package to unstable. I have not closed the bug yet, waiting
to check that everything goes fine.

Sincerely
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#1024519: ITP: golang-github-keybase-go-ps -- find, list, and inspect processes from Go

[Shengjing Zhu]

On Tue, Nov 22, 2022 at 4:18 AM Ryan Kavanagh  wrote:
>
> On Mon, Nov 21, 2022 at 11:11:07AM +0800, Shengjing Zhu wrote:
> > Besides, which package needs it? I checked #1012721, which is for
> > chezmoi. But I can't any use of the go-ps.
>
> chezmoi imports from golang-github-google-gops (NEW), which depends on
> golang-github-keybase-go-ps.
>

FWIW, chezmoi doesn't need golang-github-google-gops since v2.24.0
https://github.com/twpayne/chezmoi/commit/72d9846a7ae51fd3398727d48815fc2f13a681f9

I've submitted a PR to gops to drop keybase-go-ps.
https://github.com/google/gops/pull/187

-- 
Shengjing Zhu

Bug#1024666: supertuxkart: New version 1.4 available

[david]

Package: supertuxkart
Version: 1.3+dfsg1-3
Severity: wishlist

Dear Maintainer,

When it will be in Debian?

Thank you :)

-- 
David

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

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

Versions of packages supertuxkart depends on:
ii  libbluetooth3  5.65-1+b1
ii  libc6  2.36-5
ii  libcurl3-gnutls7.86.0-2
ii  libfreetype6   2.12.1+dfsg-3
ii  libgcc-s1  12.2.0-9
ii  libharfbuzz0b  5.2.0-2+b1
ii  libjpeg62-turbo1:2.1.2-1+b1
ii  libmbedcrypto7 2.28.1-1
ii  libmcpp0   2.7.2-5
ii  libopenal1 1:1.19.1-2
ii  libpng16-161.6.38-2
ii  libsdl2-2.0-0  2.24.2+dfsg-1
ii  libsqlite3-0   3.40.0-1
ii  libsquish0 1.15-1+b11
ii  libstdc++6 12.2.0-9
ii  libvorbisfile3 1.3.7-1
ii  supertuxkart-data  1.3+dfsg1-3
ii  zlib1g 1:1.2.11.dfsg-4.1

supertuxkart recommends no packages.

supertuxkart suggests no packages.

-- no debconf information

Bug#1024665: ITP: python-scpi -- Pure-python SCPI interface

[Martin]

Package: wnpp
Owner: deba...@debian.org
Severity: wishlist

* Package name: python-scpi
  Version : 2.4.0
  Upstream Author : Eero af Heurlin 
* URL or Web page : https://github.com/rambo/python-scpi/
* License : LGPL2.1+
  Programming Lang: Python
  Description : Pure-python SCPI interface

Basic idea here is to make transport-independent command sender/parser
and a device baseclass that implements the common SCPI (Standard
Commands for Programmable Instruments) commands.

Bug#1024664: src:filezilla: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: filezilla
Version: 3.60.2-1
Severity: serious
Control: close -1 3.61.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1020327

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:filezilla has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package failed to build 
from source on i386, which was reported in bug #1020327.


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 bookworm, 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/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=filezilla



OpenPGP_signature
Description: OpenPGP digital signature

Bug#953630: [Debichem-devel] Bug#953630: openbabel autopkg tests fail on non-amd64 architectures

[Paul Gevers]

Hi all,

On 21-11-2022 21:36, Paul Gevers wrote:

On 21-11-2022 16:01, Andrius Merkys wrote:

On 2022-11-20 18:18, Paul Gevers wrote:
 From the BSP in Tilburg, I uploaded the attached NMU to DELAYED/5. 
Please let me know if I should delay more or cancel.


Thanks, IMO this NMU is fine. Similar logic should be applied to the 
build time tests in future, since now their failures are plainly ignored.


It seems this needs another round and I'll take care of it.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Santiago Vila]

El 22/11/22 a las 0:40, Jeremy Bicha escribió:

On Mon, Nov 21, 2022 at 7:54 AM Santiago Vila  wrote:

Not exactly. As explained, I am intentionally measuring the allocated
memory as a completely safe upper bound for the required memory, and I
am aware that they are not the same. Nevertheless, I try to report
anomalies like this one when I find them.


Another example is webkitgtk. It uses overcommit as a security feature
codenamed Gigacage. The webkitgtk maintainers would close this kind of
bug as NOTABUG. Perhaps, gjs is doing something similar.

https://blogs.gnome.org/mcatanzaro/2018/11/02/on-webkit-build-options-also-how-to-accidentally-disable-important-security-features/


No. The most memory consuming webkit package in Debian allocates 6 GB or 
7 GB of RAM during build. Compared with 237 GB, it's not similar.


Thanks.

Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Marco Trevisan]

Oh, yes... So I agree that seems to be a problem.

We should probably try to run the tests alone to figure out which ones
are causing the issue.

Bug#1024663: heimdal: KDC: TGS-REQ problem with Windows 11 22H2 client

[Salvatore Bonaccorso]

Source: heimdal
Version: 7.7.0+dfsg-2
Severity: normal
Tags: upstream
Forwarded: https://github.com/heimdal/heimdal/issues/1011
X-Debbugs-Cc: car...@debian.org

Hi Brian, Dominik,

While reviewing patches in the heimdal-7-7-1 branch due to regression
in the recent CVE fixes I noticed there was added another commit,
addressing the upstream issue:

https://github.com/heimdal/heimdal/issues/1011
> KDC: TGS-REQ problem with Windows 11 22H2 client

Filling it here as it might cause logon on Windows 11 22H2 under
certain setup configurations and might be worth fixing in a bullseye
point release.

Regards,
Salvatore

Bug#1023731: BioC Transition blocked by new dependencies

[Andreas Tille]

Control: block -1 by 1024582

Am Mon, Nov 21, 2022 at 07:16:14PM +0100 schrieb Sebastian Ramacher:
> > However, to make us understand your suggestion better:  Is there any
> > drawback on your side if the transition of a closed set of packages if
> > the transition is delayed by new processing?
> 
> Some packages are also involved in other transitions. For example,
> currently a hdf5 transition is prepared in experimental. While we could
> now also start the hdf5 transition, completing hdf5 would not be
> possible until this one is done.

Thanks a lot for making me understand the problem.
 
> Now replace the hdf5 transition with another lock-step transition such
> as this one. Then we suddenly have two set of packages that can only
> migrate together. Especially for lock-step transition a quick turn
> around is thus greatly appreciated.

If I understood that BioConductor packages should not block other
transitions.  I've just pinged ftpmaster on IRC to check packages
r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr.
The following packages are blocked by the packages in new:

   r-bioc-bitseq - should be removed from testing immediately bug just filed)
   r-bioc-multiassayexperiment
   r-bioc-demixt (bug #1024597 was just filed)
   r-bioc-scater
   r-bioc-mofa (just due dependencies)

Do you want me to file RC bugs against r-bioc-multiassayexperiment,
r-bioc-scater and r-bioc-mofa.

> I will remember for the next time that I'll ask you to stage everything
> in experimental or to give me a list of packages that require NEW
> dependencies so that we can get those removed early in the transition to
> not hold of the transition by NEW delay.

I agree that the BioC transition should not habe a negative effect
on other transitions.  If RC bugs against the blockers are a valid
solution to prevent this I'd fully support this.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1024660: ITP: ranges -- Command line program to extract ranges from various types of lists, e.g. integer numbers, dates, IP and MAC addresses.

[Scott Kitterman]

On Tuesday, November 22, 2022 2:32:11 PM EST Sandro-Alessio Gierens wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sandro-Alessio Gierens 
> 
> * Package name: ranges
>   Version : 1.0.0
>   Upstream Author : Sandro-Alessio Gierens 
> * URL : https://github.com/gierens/ranges
> * License : GPLv3
>   Programming Lang: C
>   Description : Command line program to extract ranges from various
> types of lists, e.g. integer numbers, dates, IP and MAC addresses.
> 
> ranges is a command line program written in C that extracts ranges from
> various types of lists. By default it parses signed decimal integer
> lists, but given the right argument it can work with unsigned
> hexadecimal, octal and binary numbers, dates, IPv4, IPv6 and MAC
> addresses. The list input is given over the standard input, so by pipe,
> and is assumed to be sorted, but can have duplicates.
> 
> Relevance
> 
> I work in a data center and recently had the problem that I needed to
> find out which IP addresses of a subnet were not yet assigned in
> a /etc/hosts file. Because there were already too many addresses to
> get a good overview, I began to wonder if there was any command line
> tool that would allow me to compile the list of IPs into a list of
> IP ranges, so the gaps and their size would be obvious. Unfortunately
> I only found stack overflow discussions suggesting writing a script,
> and this is what I did to back then too. While this usually doesn't
> take more than a couple of minutes, ranges has too advantages:
> It already implements a bunch of different list types including
> nasty things like dates for example, and therefore would spare
> people from replementing such scripts over and over again. Aside
> from that it is written in C and therefore fast. According to my
> tests it is, depending on the machine, 20 to 40 times faster than
> a comparable Python3 script. It can crunch 130 MB of IPv4 addresses
> in a second.
> 
> Eventhough I just published the initial release I've been working on
> this for a couple of weeks now and extensively checked that it is
> stable and secure. My test suite consists of 185 tests that verify
> the correct functionality of each mode and argument. Each test is
> first run without and then with valgrind memcheck, so there should
> not be any leaks or other memory errors.
> 
> Maintainance
> 
> As the upstream author of the software I would also maintain the
> package. This would be my first package, but I already have a make
> rules to build a deb package and check it with lintian, so I'm
> not unprepared :)

The package name is very generic.  I would pick something more specific.  Also, 
I suspect the speed advantage would be less significant if you used SubnetTree 
(python3-subnettree), which does all the hard work in C.  Is this really 
needed?

Scott K

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

Bug#1024662: network-manager-gnome: nm-applet crashes after entering password due to settings object schema problem

[Jamie McClelland]

Package: network-manager-gnome
Version: 1.30.0-2
Severity: normal

Dear Maintainer,

When using nm-applet to connect to a new network, I am properly prompted
for a password, but, after entering the password (either the right one
or the wrong one), nm-applet crashes with the following error:

(nm-applet:9524): GLib-GIO-ERROR **: 09:42:23.667: settings object created with 
schema 'org.gnome.nm-applet.eap' and path 
'/org/gnome/nm-applet/eap/03995f27-b071-412b-b787-908a32a1fac0/', but path 
'/org/gnome/nm-applet/eap/' is specified by schema

Thanks for any help you can provide.


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

Kernel: Linux 6.0.0-4-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 network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.4-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  libatk1.0-0   2.46.0-3
ii  libayatana-appindicator3-10.5.91-1
ii  libc6 2.36-4
ii  libcairo2 1.16.0-6
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libglib2.0-0  2.74.1-2
ii  libgtk-3-03.24.34-3
ii  libjansson4   2.14-2
ii  libmm-glib0   1.20.0-1
ii  libnm01.40.2-1
ii  libnma0   1.10.4-1
ii  libpango-1.0-01.50.10+ds-1
ii  libpangocairo-1.0-0   1.50.10+ds-1
ii  libsecret-1-0 0.20.5-3
ii  libselinux1   3.4-1+b3
ii  network-manager   1.40.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7+b1

Versions of packages network-manager-gnome recommends:
ii  gnome-icon-theme 3.12.0-5
ii  gnome-keyring42.1-1+b1
ii  iso-codes4.12.0-1
ii  mako-notifier [notification-daemon]  1.7.1-1+b1
ii  mobile-broadband-provider-info   20220725-1
ii  notification-daemon  3.20.0-4+b1

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

-- debconf-show failed

Bug#1024661: r-bioc-bitseq: orphaned upstream and blocking BioC 3.16 transition

[Andreas Tille]

Source: r-bioc-bitseq
Version: 1.40.0+dfsg-1
Severity: critical
Tags: ftbfs
Justification: breaks unrelated software
X-Debbugs-Cc: 1023...@bugs.debian.org, debia...@lists.debian.org

As per upstream

   https://lists.debian.org/debian-r/2022/11/msg00058.html

r-bioc-bitseq is not supported any more.  It does not build against the
packages that are part of the BioC 3.16 release (namely r-bioc-rhtslib
which does not contain the header file bam.h any more)

Before we might remove r-bioc-bitseq finally from Debian we want to give
interested people a chance to fix the code but this bug should remove the
package from testing to not block the BioC 3.16 transition.

Kind regards

  Andreas.


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

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

Bug#1024660: ITP: ranges -- Command line program to extract ranges from various types of lists, e.g. integer numbers, dates, IP and MAC addresses.

[Sandro-Alessio Gierens]

Package: wnpp
Severity: wishlist
Owner: Sandro-Alessio Gierens 

* Package name: ranges
  Version : 1.0.0
  Upstream Author : Sandro-Alessio Gierens 
* URL : https://github.com/gierens/ranges
* License : GPLv3
  Programming Lang: C
  Description : Command line program to extract ranges from various types 
of lists, e.g. integer numbers, dates, IP and MAC addresses.

ranges is a command line program written in C that extracts ranges from
various types of lists. By default it parses signed decimal integer
lists, but given the right argument it can work with unsigned
hexadecimal, octal and binary numbers, dates, IPv4, IPv6 and MAC
addresses. The list input is given over the standard input, so by pipe,
and is assumed to be sorted, but can have duplicates.

Relevance

I work in a data center and recently had the problem that I needed to
find out which IP addresses of a subnet were not yet assigned in
a /etc/hosts file. Because there were already too many addresses to
get a good overview, I began to wonder if there was any command line
tool that would allow me to compile the list of IPs into a list of
IP ranges, so the gaps and their size would be obvious. Unfortunately
I only found stack overflow discussions suggesting writing a script,
and this is what I did to back then too. While this usually doesn't
take more than a couple of minutes, ranges has too advantages:
It already implements a bunch of different list types including
nasty things like dates for example, and therefore would spare
people from replementing such scripts over and over again. Aside
from that it is written in C and therefore fast. According to my
tests it is, depending on the machine, 20 to 40 times faster than
a comparable Python3 script. It can crunch 130 MB of IPv4 addresses
in a second.

Eventhough I just published the initial release I've been working on
this for a couple of weeks now and extensively checked that it is
stable and secure. My test suite consists of 185 tests that verify
the correct functionality of each mode and argument. Each test is
first run without and then with valgrind memcheck, so there should
not be any leaks or other memory errors.

Maintainance

As the upstream author of the software I would also maintain the
package. This would be my first package, but I already have a make
rules to build a deb package and check it with lintian, so I'm
not unprepared :)

Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Santiago Vila]

Hi.

I confirm that the huge memory allocation happens during the 
override_dh_auto_test target of debian/rules, not during the build itself.


This is at least double the amount of *any other* of the 33785 source 
packages in Debian bookworm, so yes, I think it is more than fair to 
call it an anomaly.


Thanks.

Bug#1024659: python3-pypandoc: spurious dependency on python3-pip

[Jakub Wilk]

Package: python3-pypandoc
Version: 1.7.4+ds0-1

python3-pypandoc depends on python3-pip.
I don't think that's right.

--
Jakub Wilk

Bug#1024658: mkdocs: Please provide dh-sequence-mkdocs

[Andrea Pappacoda]

Package: mkdocs
Version: 1.4.2+dfsg-1
Severity: wishlist

Hi, as mkdocs ships the dh_mkdocs addon, could you please make the package
provide dh-sequence-mkdocs? This would allow users of the addon to put
`Depends-Indep: dh-sequence-mkdocs` in d/control, without having to also add
`--with=mkdocs` to d/rules.

Thanks!


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 mkdocs depends on:
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1
ii  ghp-import 2.1.0-3
ii  libjs-bootstrap4   4.6.1+dfsg1-3
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-lunr 2.3.9~dfsg-1
ii  libjs-modernizr2.6.2+ds1-4
ii  python33.10.6-1
ii  python3-click  8.0.3-1
ii  python3-jinja2 3.0.3-2
ii  python3-livereload 2.6.3-2
ii  python3-lunr   0.6.2-2
ii  python3-markdown   3.4.1-2
ii  python3-mergedeep  1.3.4-3
ii  python3-packaging  21.3-1.1
ii  python3-pkg-resources  65.5.0-1
ii  python3-pyyaml-env-tag 0.1-3
ii  python3-typing-extensions  4.3.0-2
ii  python3-watchdog   2.1.9-1
ii  python3-yaml   6.0-3+b1
ii  sphinx-rtd-theme-common1.1.1+dfsg-1

mkdocs recommends no packages.

Versions of packages mkdocs suggests:
pn  mkdocs-doc 
pn  nodejs 
pn  python3-babel  

-- no debconf information

Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Santiago Vila]

El 22/11/22 a las 18:44, Marco Trevisan escribió:

On nov 21 2022, at 1:51 pm, Santiago Vila  wrote:

I am reporting this as an anomaly (a very big anomaly indeed).


With the gjs upstream hat, I have sadly to say that this is probably
something expected: gjs eavily uses complex templates to generate code
all over the places, and such generated code is all kept in memory by
g++ (and any other c++ compiler at the date I think), thus I don't think
it's an anomaly. I suppose compilers could do some local caching but I'm
not aware of a way of doing that.
By "anomaly" I meant "anomaly compared with other Debian packages". It 
would very strange if this was the only package in Debian making such 
heavy use of templates.


I'm not sure, but I believe the memory thing happens at the end of the 
build process, probably during the dh_auto_test stage of the package 
build, not during the build itself. So the fact that gjs build makes 
heavy use of complex templates would not be a good explanation for the 
memory usage.


I think we should do tests to see what happens.

Thanks.

Bug#1024638: opencv: embeds build path in Python extension

[Vagrant Cascadian]

On 2022-11-22, Victor Westerhuis wrote:
> Stripping the rpath from the Python extension makes its BuildId
> reproducible. The extension still works and both arch:all and arch:any
> builds succeed locally.
...
> diff --git a/debian/rules b/debian/rules
> index b4d654102..6bd845023 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -151,6 +151,7 @@ override_dh_auto_configure:
>   -- --name=opencv --system=custom --configure-args "\
>   dh_auto_configure -S cmake -D modules/python -B 
> {build_dir} -- \
>   -GNinja \
> + -DCMAKE_SKIP_RPATH=ON \
>   -DOpenCV_BINARY_DIR=$(CURDIR)/$(BUILDDIR) \
>   
> -DOPENCV_PYTHON_STANDALONE_INSTALL_PATH={install_dir} \
>   -DOPENCV_SKIP_PYTHON_LOADER=ON \

I would recommend using -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON instead of
-DCMAKE_SKIP_RPATH=ON.

This is the default behavior with (the currently experimental) debhelper
compat level 14. A little more detail on the issue is available here:

  
https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html

The main advantage of CMAKE_BUILD_RPATH_USE_ORIGIN is it is more likely
to work with test suites that depend on the full path.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1024657: nvidia-libopencl1: Inconsistency between changelog and package description regarding supported OpenCL versions

[Ben Morris]

Package: nvidia-libopencl1
Severity: minor

Dear Maintainer,

The package description states "This library supports OpenCL 1.x and 2.0
only".

However, the changelog says "nvidia-libopencl1 now supports up to OpenCL
3.0." as of 460.27.04-1.

I do not have an nvidia card and am unable to check what actually works,
but nvidia's website seems to suggest that the changelog is correct.

The description for nvidia-opencl-icd may have a similar problem.

Ben Morris

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

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

Versions of packages nvidia-libopencl1 depends on:
ii  libc6  2.36-5

Versions of packages nvidia-libopencl1 recommends:
pn  nvidia-opencl-icd | opencl-icd  

nvidia-libopencl1 suggests no packages.

Bug#1024656: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: open-infrastructure-compute-tools
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# Spanish debconf translation of open-infrastructure-container-tools
# Copyright (C) 2021-2022 Camaleón 
# This file is distributed under the same license as the 
open-infrastructure-container-tools package.
#
msgid ""
msgstr ""
"Project-Id-Version: open-infrastructure-compute-tools 202210023-1\n"
"Report-Msgid-Bugs-To: open-infrastructure-compute-to...@packages.debian.org\n"
"POT-Creation-Date: 2022-10-02 15:20+0200\n"
"PO-Revision-Date: 2022-11-22 19:28+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: title
#. Description
#: ../open-infrastructure-container-tools.templates:1001
msgid "container-tools: Setup"
msgstr "container-tools: Configuración"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid "machines directory:"
msgstr "directorio de máquinas virtuales:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid "Please specify the directory that will be used to store the containers."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los "
"contenedores."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid ""
"If unsure, use /var/lib/machines (default) or /srv/container/system when "
"using shared storage."
msgstr ""
"Si no está seguro, utilice «/var/lib/machines» (predeterminado) o «/srv/"
"container/system» si usa un almacenamiento compartido."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid "config directory:"
msgstr "directorio de configuración:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid ""
"Please specify the directory that will be used to store the container "
"configuration files."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los archivos de "
"configuración del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid ""
"If unsure, use /etc/compute-tools/config (default) or /srv/container/config "
"when using shared storage."
msgstr ""
"Si no está seguro, utilice «/etc/compute-tools/config/"
"config» (predeterminado) o «/srv/container/config» si usa un almacenamiento "
"compartido."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
msgid "debconf directory:"
msgstr "directorio para debconf:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
msgid ""
"Please specify the directory that will be used to store the container "
"preseed files."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los archivos de "
"preconfiguración (preseed) del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
msgid ""
"If unsure, use /etc/compute-tools/debconf (default) or /srv/container/"
"debconf when using shared storage."
msgstr ""
"Si no está seguro, utilice «/etc/compute-tools/debconf» (predeterminado) o «/"
"srv/container/debconf» si usa un almacenamiento compartido."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:5001
msgid "hooks directory:"
msgstr "directorio de archivos de órdenes (hooks):"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:5001
msgid ""
"Please specify the directory that will be used to store the container hooks."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los archivos de "
"órdenes (hooks) del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:5001
msgid ""
"If unsure, use /etc/compute-tools/hooks (default) or /srv/container/hooks "
"when using shared storage."
msgstr ""
"Si no está seguro, utilice «/etc/compute-tools/hooks» (predeterminado) o «/"
"srv/container/hooks» si usa un almacenamiento compartido."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:6001
msgid "keys directory:"
msgstr "directorio de claves:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:6001
msgid ""
"Please specify the directory that will be used to store the container keys "
"for verifying container image downloads."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar las claves del "
"contenedor para verificar las descargas de imágenes del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:6001
msgid ""
"If unsure, use /etc/compute-tools/keys (default) or /srv/container/keys 

Bug#1024655: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: msmtp
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# msmtp translation to spanish
# Copyright (C) 2008 Software in the Public Interest
# This file is distributed under the same license as the msmtp package.
# Changes:
# - Initial translation
# Ignacio Mondino , 2008
# Traductores, si no conoce el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/coordinacion
# especialmente las notas de traducción en
# http://www.debian.org/intl/spanish/notas
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#
msgid ""
msgstr ""
"Project-Id-Version: msmtp 1.8.22-1\n"
"Report-Msgid-Bugs-To: ms...@packages.debian.org\n"
"POT-Creation-Date: 2022-10-27 23:33+\n"
"PO-Revision-Date: 2022-11-22 19:14+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish team \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: boolean
#. Description
#: ../msmtp.templates:1001
msgid "Enable AppArmor support?"
msgstr "¿Activar el soporte para AppArmor?"

#. Type: boolean
#. Description
#: ../msmtp.templates:1001
msgid ""
" Apparmor is a kernel security mechanism to restrict programs capabilities\n"
" with per-program profiles.\n"
" .\n"
" The AppArmor profile for msmtp covers a lot of common usecases but there "
"are\n"
" still corner cases with some options which breaks msmtp with "
"incomprehensible\n"
" permissions denied errors."
msgstr ""
" AppArmor es un mecanismo de seguridad del núcleo que permite restringir "
"las\n"
" capacidades de los programas mediante el uso de perfiles individuales para\n"
" cada programa.\n"
" .\n"
" El perfil de AppArmor de msmtp cubre la mayoría de las situaciones más\n"
" comunes, pero en algunos casos concretos, algunas opciones pueden romper\n"
" msmtp con errores incompresibles de denegación de permisos."

#. Type: error
#. Description
#: ../msmtp.templates:2001
msgid "Remove SetGID bit on msmtp"
msgstr "Eliminar el bit SetGID en msmtp"

#. Type: error
#. Description
#: ../msmtp.templates:2001
msgid ""
" Starting from version 1.8.22, msmtp will no longer be SetGID. Hence the\n"
" creation of the system-wide configuration (/etc/msmtprc) using debconf is\n"
" removed.\n"
" .\n"
" From one side, using the system wide configuration implied msmtp to be "
"SetGID\n"
" but recent security hardening changes in GLib prevent SetGID binaries "
"built\n"
" against libsecret to talk to the D-Bus session, and therefore prevent it "
"from\n"
" being able to retrieve passwords from gnome-keyring or KWallet.\n"
" .\n"
" On another side, it was easy for a local user to obtain the credentials\n"
" stored in /etc/msmtprc even if the file was not readable for this user "
"when\n"
" msmtp was SetGid.\n"
" .\n"
" More information in the following bug reports:\n"
"   - https://bugs.debian.org/944188\n;
"   - https://bugs.debian.org/995012;
msgstr ""
" Desde la versión 1.8.22, msmtp ya no se configura con permisos SetGID.\n"
" Por lo tanto, se ha eliminado la creación de la configuración global\n"
" a través de debconf («/etc/msmtprc»).\n"
" .\n"
" Por una parte, utilizar un archivo de configuración global implicaba que\n"
" msmtp se configurara con permisos SetGID, pero cambios recientes para\n"
" fortalecer la seguridad de GLib impiden que los binarios compilados con\n"
" libsecret puedan dialogar con una sesión D-Bus, impidiéndole obtener\n"
" contraseñas almacenadas en gnome-keyring o KWallet.\n"
" .\n"
" Por otra parte, resultaba muy sencillo para un usuario local obtener las\n"
" credenciales almacenadas en «/etc/msmtprc» aunque el archivo no fuera\n"
" legible para este usuario cuando msmtp estaba configurado con permisos\n"
" SetGID.\n"
" .\n"
" Puede obtener más información en los siguientes informes de error:\n"
"   - https://bugs.debian.org/944188\n;
"   - https://bugs.debian.org/995012;

#~ msgid "Create a system wide configuration file?"
#~ msgstr ""
#~ "¿Crear un archivo de configuración por omisión para todo el sistema?"

#~ msgid ""
#~ "msmtp has a sendmail emulation mode which allow to create a default "
#~ "system account that can be used by any user."
#~ msgstr ""
#~ "msmtp provee un modo de emulación de sendmail el cual permite crear una "
#~ "cuenta por omisión que puede ser utilizada por cualquier usuario."

#~ msgid "SMTP server hostname:"
#~ msgstr "Nombre del servidor SMTP:"

#~ msgid "SMTP port number:"
#~ msgstr 

Bug#1024654: i2masschroq: A new source-only upload needed

[Boyuan Yang]

Source: i2masschroq
Version: 0.4.54-1
Tags: sid  bookworm
Severity: important
X-Debbugs-CC: debichem-de...@alioth-lists.debian.net lopi...@debian.org

Dear Debian i2masschroq package maintainer,

According to https://tracker.debian.org/pkg/i2masschroq , your package needs
another source-only upload in order to migrate to Debian Testing. Please
have it fixed before next Testing freeze to ensure that the package could
enter next Debian 12. For more information, please see
https://wiki.debian.org/SourceOnlyUpload . Thanks!

Best,
Boyuan Yang


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

Bug#1024641: Aptly does not support zstd compression

[Kyle Edwards]

On 11/22/22 12:12, Sébastien Delafond wrote:

This was fixed in 1.4.0+ds1-7, as per #1010465[fn:1]. Are you actually
saying this version, currently in sid, doesn't properly support zstd for
you? If so, how does it fail?


Now I see what happened. I tried to do this in Ubuntu 22.04, which 
failed due to being stuck at 1.4.0+ds1-6. I came to Sid to check the 
version, saw 1.4.0, and assumed the feature was still not present. It 
had not occurred to me that the feature might have been backported to 
1.4.0+ds1-7.


Either upgrading to Ubuntu 22.10 or manually backporting 1.4.0+ds1-7 to 
Ubuntu 22.04 should be sufficient for my needs. Thanks.



As for packaging 1.5.x, please see #1022720[fn:2].


Thanks for the info.

Kyle

Bug#1024652: ruby3.0: Segmentation fault from irb when performing a simple multiplication

[Gunnar Wolf]

Package: ruby3.0
Version: 3.0.4-8
Severity: normal

I often use irb for many quick checks in my system. I was quite amazed
to find the segfault I am attaching; I was unable to reproduce it, but
still, I believe it to be worth reporting. It seems to come from
_something_ in the call to the C function for readline.

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

Kernel: Linux 6.0.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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby3.1 depends on:
ii  libc6 2.36-5
ii  libcrypt1 1:4.4.30-1
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libruby3.13.1.2-3
ii  rubygems-integration  1.18
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages ruby3.1 recommends:
ii  fonts-lato2.0-2.1
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1

ruby3.1 suggests no packages.

-- no debconf information
$ irb
Ignoring nokogiri-1.10.1 because its extensions are not built. Try: gem 
pristine nokogiri --version 1.10.1
>> 2 * 1.03
=> 20600.0
/usr/lib/ruby/3.0.0/irb/input-method.rb:215: [BUG] Segmentation fault at 
0x55ae1400
ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-linux-gnu]

-- Control frame information ---
c:0020 p: s:0091 e:90 CFUNC  :readline
c:0019 p:0038 s:0085 e:84 METHOD /usr/lib/ruby/3.0.0/irb/input-method.rb:215
c:0018 p:0008 s:0080 e:79 BLOCK  /usr/lib/ruby/3.0.0/irb.rb:529
c:0017 p:0024 s:0076 e:75 METHOD /usr/lib/ruby/3.0.0/irb.rb:751
c:0016 p:0007 s:0070 e:69 BLOCK  /usr/lib/ruby/3.0.0/irb.rb:528
c:0015 p:0005 s:0067 e:66 METHOD /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:267
c:0014 p:0008 s:0061 e:60 BLOCK  /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:236 
[FINISH]
c:0013 p: s:0057 e:56 CFUNC  :loop
c:0012 p:0005 s:0053 e:52 BLOCK  /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:233 
[FINISH]
c:0011 p: s:0050 e:49 CFUNC  :catch
c:0010 p:0010 s:0045 e:44 METHOD /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:232
c:0009 p:0046 s:0041 E:0020e8 METHOD /usr/lib/ruby/3.0.0/irb.rb:547
c:0008 p:0004 s:0036 e:35 BLOCK  /usr/lib/ruby/3.0.0/irb.rb:481 [FINISH]
c:0007 p: s:0033 e:32 CFUNC  :catch
c:0006 p:0058 s:0028 E:000f40 METHOD /usr/lib/ruby/3.0.0/irb.rb:480
c:0005 p:0104 s:0022 e:21 METHOD /usr/lib/ruby/3.0.0/irb.rb:409
c:0004 p:0019 s:0016 e:15 TOP
/usr/lib/ruby/gems/3.0.0/gems/irb-1.3.5/exe/irb:11 [FINISH]
c:0003 p: s:0013 e:12 CFUNC  :load
c:0002 p:0112 s:0008 E:30 EVAL   /usr/bin/irb:23 [FINISH]
c:0001 p: s:0003 E:001fe0 (none) [FINISH]

-- Ruby level backtrace information 
/usr/bin/irb:23:in `'
/usr/bin/irb:23:in `load'
/usr/lib/ruby/gems/3.0.0/gems/irb-1.3.5/exe/irb:11:in `'
/usr/lib/ruby/3.0.0/irb.rb:409:in `start'
/usr/lib/ruby/3.0.0/irb.rb:480:in `run'
/usr/lib/ruby/3.0.0/irb.rb:480:in `catch'
/usr/lib/ruby/3.0.0/irb.rb:481:in `block in run'
/usr/lib/ruby/3.0.0/irb.rb:547:in `eval_input'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:232:in `each_top_level_statement'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:232:in `catch'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:233:in `block in each_top_level_statement'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:233:in `loop'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:236:in `block (2 levels) in 
each_top_level_statement'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:267:in `lex'
/usr/lib/ruby/3.0.0/irb.rb:528:in `block in eval_input'
/usr/lib/ruby/3.0.0/irb.rb:751:in `signal_status'
/usr/lib/ruby/3.0.0/irb.rb:529:in `block (2 levels) in eval_input'
/usr/lib/ruby/3.0.0/irb/input-method.rb:215:in `gets'
/usr/lib/ruby/3.0.0/irb/input-method.rb:215:in `readline'

-- Machine register context 
 RIP: 0x7fbfd7192d25 RBP: 0x RSP: 0x7ffebfb23100
 RAX: 0x55ae1400 RBX: 0xff70 RCX: 0x0c00
 RDX: 0xfc00 RDI: 0x7fbfd72ccc60 RSI: 0x55ae14ed34b3
  R8: 0x  R9: 0x7ffebfb230e0 R10: 0x0004
 R11: 0x0001 R12: 0x R13: 0x7fbfd72c95e0
 R14: 0x0001 R15: 0x55ae15040220 EFL: 0x00010206

-- C level backtrace information ---
/lib/x86_64-linux-gnu/libruby-3.0.so.3.0(0x7fbfd76ec47c) [0x7fbfd76ec47c]
/lib/x86_64-linux-gnu/libruby-3.0.so.3.0(0x7fbfd7543280) [0x7fbfd7543280]
/lib/x86_64-linux-gnu/libruby-3.0.so.3.0(0x7fbfd7662e8b) [0x7fbfd7662e8b]
/lib/x86_64-linux-gnu/libc.so.6(__restore_rt+0x0) [0x7fbfd7135f90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_free+0x65) [0x7fbfd7192d25]
/lib/x86_64-linux-gnu/libc.so.6(_IO_free_backup_area+0x15) [0x7fbfd717cb75]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_overflow+0x1c7) 

Bug#1024653: git: FTBFS on s390x due to test failure, incorrect /proc/cpuinfo parsing

[Andreas Hasenack]

Package: git
Version: 1:2.38.1-1
Severity: normal

Dear Maintainer,

git commit 29fb2ec384a867ca577335a12f4b45c184e7b642, present in 2.38.0
and later, introduced a function that gets the number of cores from
/proc/cpuinfo. It essentially does this:

do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor\s*:/, <>)); } if -r '/proc/cpuinfo';

On s390x, the ^processor lines are like this:

processor 0: version = FF, identification = 148F67, machine = 2964

In other arches (I checked amd64, armhf and arm64), they are like this instead:

processor : 0

As a result, that function is returning 0 on s390x, and that value is
used for the number of jobs the script should execute. Since it's
zero, it exits without doing anything, and that breaks the test and
the build[3] on s390x.

The failure can also be seen in debian's s390x build[4].

I suggest this simple regexp change in t/chainlint.pl:

- do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor\s*:/, <>)); } if -r '/proc/cpuinfo';
+ do { local @ARGV='/proc/cpuinfo'; return
scalar(grep(/^processor[\s\d]*:/, <>)); } if -r '/proc/cpuinfo';


1. https://github.com/git/git/commit/29fb2ec384a867ca577335a12f4b45c184e7b642
2. 
https://github.com/git/git/commit/29fb2ec384a867ca577335a12f4b45c184e7b642#diff-e7042d714d4be11a06d153e6f2daeb3c3a9766b972522baab8ba113b962086cfR574
3. 
https://launchpadlibrarian.net/635348769/buildlog_ubuntu-lunar-s390x.git_1%3A2.38.1-1ubuntu1_BUILDING.txt.gz
4. 
https://buildd.debian.org/status/fetch.php?pkg=git=s390x=1%3A2.38.1-1=1668068969=0

Bug#1024651: ruby-gpgme: FTBFS against libgpgme-dev >= 1.18.0-2

[Andreas Metzler]

Source: ruby-gpgme
Version: 2.0.20-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition^

The package relies on gpgme-config to detect gpgme. gpgme-config has been
dropped and replaced by pkg-config pc files.

cu Andreas

--
checking for gpgme-config... no
gpgme-config not found
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Marco Trevisan]

Hi,

On nov 21 2022, at 1:51 pm, Santiago Vila  wrote:

> El 21/11/22 a las 11:20, Simon McVittie escribió:
>> In case there's a kernel difference, I've just tried it in a bookworm
>> VM containing bookworm's sbuild and schroot, again with 2G of RAM. That
>> was also successful.
>  
> The package builds fine for me, I never said otherwise, and this is
> not  
> a FTBFS bug.
>  
> I am reporting this as an anomaly (a very big anomaly indeed).

With the gjs upstream hat, I have sadly to say that this is probably
something expected: gjs eavily uses complex templates to generate code
all over the places, and such generated code is all kept in memory by
g++ (and any other c++ compiler at the date I think), thus I don't think
it's an anomaly. I suppose compilers could do some local caching but I'm
not aware of a way of doing that.

Bug#1024275: [Pkg-utopia-maintainers] Bug#1024275: network-manager-openvpn: can't connect to vpn after last update: can't set proper cipher.

[Michael Biebl]

Control: severity -1 normal
Control: notforwarded -1

Am 16.11.22 um 22:54 schrieb Daniel Serpell:

Package: network-manager-openvpn
Version: 1.10.2-1
Severity: normal

Dear maintainer,

After upgrading to 1.10.2-1, I can't connect to the VPN anymore.

This is the logs from NetworkManager:

   nm-openvpn[]: [] Peer Connection Initiated with 
[AF_INET]:
   nm-openvpn[]: OPTIONS ERROR: failed to negotiate cipher with server.  Add 
the server's cipher ('AES-256-CBC') to --data-ciphers (currently 'AES-256-GCM') 
if you want to connect to this server.
   nm-openvpn[]: ERROR: Failed to apply push options
   nm-openvpn[]: Failed to open tun/tap interface
   nm-openvpn[]: SIGUSR1[soft,process-push-msg-failed] received, process 
restarting

Trying to change the cipher to AES-256-CBC in network properties does not work, 
it reverts back to AES-256-GCM.


I recreated the failing OpenVPN connection and I can't reproduce the 
problem anymore.

I thus closed the upstream issue and dropped the forwarded meta data.

My recommendation, if you can still reproduce the issue, is to file the 
issue upstream [1] yourself. It's likely that upstream has further question.


Regards,
Michael
[1] https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024650: gmp: please include changes from 6.2.1+dfsg1-1.1 NMU

[Holger Levsen]

Package: gmp
Version: 6.2.1+dfsg1-1.1
Severity: normal

Dear Maintainer,

please include the attached changes from my 6.2.1+dfsg1-1 NMU.

Thank you for maintaining gmp!


-- 
cheers,
Holger

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

Be careful when you follow the masses. Sometimes the "m" is silent.
diff -Nru gmp-6.2.1+dfsg1/debian/changelog gmp-6.2.1+dfsg1/debian/changelog
--- gmp-6.2.1+dfsg1/debian/changelog	2022-06-12 22:56:17.0 +0200
+++ gmp-6.2.1+dfsg1/debian/changelog	2022-09-22 20:43:57.0 +0200
@@ -1,3 +1,13 @@
+gmp (2:6.2.1+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload by the Reproducible Builds team.
+  * debian/rules changes by Vagrant Cascadian:
+- pass ASMFLAGS with debug-prefix-map to configure.
+- replace embedded build path in gmp.h with a placeholder string.
+Closes: #1009931
+
+ -- Holger Levsen   Thu, 22 Sep 2022 20:43:57 +0200
+
 gmp (2:6.2.1+dfsg1-1) unstable; urgency=medium
 
   [ Bastian Germann ]
diff -Nru gmp-6.2.1+dfsg1/debian/rules gmp-6.2.1+dfsg1/debian/rules
--- gmp-6.2.1+dfsg1/debian/rules	2022-06-12 22:55:58.0 +0200
+++ gmp-6.2.1+dfsg1/debian/rules	2022-09-22 20:31:51.0 +0200
@@ -72,7 +72,7 @@
 	mkdir -p build
 	cd build && ../configure $(confflags_ma) \
 	AR=$(AR) CC="$(CC)" CFLAGS="$(CFLAGS)" \
-	CXX="$(CXX)" CXXFLAGS="$(CXXFLAGS)"
+	CXX="$(CXX)" CXXFLAGS="$(CXXFLAGS)" ASMFLAGS="--debug-prefix-map=$(CURDIR)=."
 	touch $@
 
 build: build-stamp
@@ -100,6 +100,9 @@
 	# so override it at install.
 	$(MAKE) DESTDIR=`pwd`/debian/tmp includeexecdir=/usr/include/$(DEB_HOST_MULTIARCH) -C build install
 
+	# Replace embedded build path with a placeholder string
+	sed -i -e "s,$(CURDIR),BUILDPATH,g" debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/gmp.h
+
 	dh_install -plibgmp10 usr/lib/*/libgmp.so.*
 	dh_install -plibgmpxx4ldbl usr/lib/*/libgmpxx.so.*
 


signature.asc
Description: PGP signature

Bug#1024648: elpa-snakemake: fails to install with emacs 27: misses 'transient'

[Diane Trout]

On Tue, 2022-11-22 at 18:24 +0100, Andreas Beckmann wrote:
> 
> There needs to be either a
>   Depends: emacs-el (>= 1:28)
> or an equivaent
>   Breaks: (emacs-el (<< 1:28)
> or the installation must be skipped if emacs is too old.

So it looks like elpa-snakemake depends on the transient package which
is currently elpa-transient and in included in emacs 28.

So what do you think of this instead?

Depends: emacs-el (>= 1:28) | elpa-transient,

Diane

Bug#1024649: libtheora: please include changes from 1.1.1+dfsg.1-16.1 NMU

[Holger Levsen]

Package: libtheora
Version: 1.1.1+dfsg.1-16.1
Severity: normal

Dear Maintainer,

please include the attached changes from my 1.1.1+dfsg.1-16.1 NMU.

Thank you for maintaining libtheora!


-- 
cheers,
Holger

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

Be careful when you follow the masses. Sometimes the "m" is silent.
diff -Nru libtheora-1.1.1+dfsg.1/debian/changelog libtheora-1.1.1+dfsg.1/debian/changelog
--- libtheora-1.1.1+dfsg.1/debian/changelog	2022-06-01 15:41:32.0 +0200
+++ libtheora-1.1.1+dfsg.1/debian/changelog	2022-10-06 19:18:29.0 +0200
@@ -1,3 +1,14 @@
+libtheora (1.1.1+dfsg.1-16.1) unstable; urgency=medium
+
+  * Non-maintainer upload by the Reproducible Builds team.
+  * debian/libtheora-doc.examples: do not install example Makefile as it leaks
+the build path. Closes: #990843 - thanks to Vagrant Cascadian for the
+patch.
+  * debian/rules: ensure texlive respects SOURCE_DATE_EPOCH, thanks again to
+Vagrant for the patch. Closes: #990844
+
+ -- Holger Levsen   Thu, 06 Oct 2022 19:18:29 +0200
+
 libtheora (1.1.1+dfsg.1-16) unstable; urgency=medium
 
   * Team upload.
diff -Nru libtheora-1.1.1+dfsg.1/debian/libtheora-doc.examples libtheora-1.1.1+dfsg.1/debian/libtheora-doc.examples
--- libtheora-1.1.1+dfsg.1/debian/libtheora-doc.examples	2022-06-01 15:28:52.0 +0200
+++ libtheora-1.1.1+dfsg.1/debian/libtheora-doc.examples	2022-10-06 18:33:01.0 +0200
@@ -1,4 +1,3 @@
 examples/*.am
 examples/*.c
 examples/*.h
-examples/Makefile
diff -Nru libtheora-1.1.1+dfsg.1/debian/rules libtheora-1.1.1+dfsg.1/debian/rules
--- libtheora-1.1.1+dfsg.1/debian/rules	2022-06-01 15:26:36.0 +0200
+++ libtheora-1.1.1+dfsg.1/debian/rules	2022-10-06 18:32:42.0 +0200
@@ -4,6 +4,9 @@
 export CONFIG_SHELL
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@
 


signature.asc
Description: PGP signature

Bug#1024631: gitlab: preinst: invalid number 9.1

[Kurt Roeckx]

On Tue, Nov 22, 2022 at 06:13:30PM +0100, Kurt Roeckx wrote:
> In any case, the default cluster points to 14, it's just not on port 5432.

That doesn't seem to be true. Commands like createdb, psql default to
port 5432 if there is nothing overriding it, like PGPORT env variable.


Kurt

Bug#1024648: elpa-snakemake: fails to install with emacs 27: misses 'transient'

[Andreas Beckmann]

Package: elpa-snakemake
Version: 2.0.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install if
emacs 27 (currently still in bookworm) is already installed. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up elpa-snakemake (2.0.0-2) ...
  Install emacsen-common for emacs
  emacsen-common: Handling install of emacsen flavor emacs
  Install elpa-snakemake for emacs
  install/snakemake-2.0.0: Handling install of emacsen flavor emacs
  install/snakemake-2.0.0: byte-compiling for emacs
  
  In toplevel form:
  snakemake.el:94:1:Error: Cannot open load file: No such file or directory, 
transient
  ERROR: install script from elpa-snakemake package failed
  dpkg: error processing package elpa-snakemake (--configure):
   installed elpa-snakemake package post-installation script subprocess 
returned error exit status 1
  Errors were encountered while processing:
   elpa-snakemake

There needs to be either a
  Depends: emacs-el (>= 1:28)
or an equivaent
  Breaks: (emacs-el (<< 1:28)
or the installation must be skipped if emacs is too old.


cheers,

Andreas


elpa-snakemake=2.0.0-2_emacs.log.gz
Description: application/gzip

Bug#1024631: gitlab: preinst: invalid number 9.1

[Kurt Roeckx]

On Tue, Nov 22, 2022 at 10:20:06PM +0530, Pirate Praveen wrote:
> 
> 
> On Tue, Nov 22 2022 at 02:27:05 PM +01:00:00 +01:00:00, Kurt Roeckx
>  wrote:
> > Package: gitlab
> > Version: 15.4.2+ds1-1~fto11+3
> > 
> > On install I get:
> > /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1
> > 
> > I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them
> > are used. 9.1 is using port 5432.
> > 
> 
> Do you have another recommendation on how to make sure we use at least
> postgresql 12?
> 
> Does adding a configuration option to skip this check
> "gitlab_pg_version_check" which can be set to "false" in
> /etc/gitlab/gitlab-debian.conf suffice?

Note that it just continues the installation because it ignores
the error.

To be able to install things, I had to edit the database.yml to set the
port number. I also had to manually create the user and database.

I think it asks for a hostname, but not for a port number. I at least
assume it supports a remote database. The check should be for that
combination, which is probably harder. In any case, the default cluster
points to 14, it's just not on port 5432.


Kurt

Bug#1024641: Aptly does not support zstd compression

[Sébastien Delafond]

On 22/11 11:01, Kyle Edwards wrote:
> Package: aptly
> Version: 1.4.0+ds1-7
> 
> Aptly 1.4.0 does not support the zstd compression found in Ubuntu 22.04
> packages. Please upgrade Aptly to 1.5.0 to support the new zstd compression.

This was fixed in 1.4.0+ds1-7, as per #1010465[fn:1]. Are you actually
saying this version, currently in sid, doesn't properly support zstd for
you? If so, how does it fail?

As for packaging 1.5.x, please see #1022720[fn:2].

Cheers,

-- 
Seb

* Footnotes

[fn:1] https://bugs.debian.org/1010465

[fn:2] https://bugs.debian.org/1022720

Bug#1024627: gitlab: Fails to install

[Fabien (Debian)]

I've encountered this problem, here is a workaround:

apt install omniauth-oauth2=1.7.1

Bug#1024647: trac: The versiuon packaged by debian contain a bug fixed upstream that prevent it to work with python3

[Eric Valette]

Package: trac
Version: 1.5.3+dfsg-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Afterupgrading and oldoldstable distrib to stable 11.5, becaue of the move to 
python3
I had to update trac to the sid version as there is not stable version yet.

It did not work at all inside apache2/cgi (old install)because of a bug already 
fixed
upstream (reload not defined)

See : https://trac.edgewall.org/changeset/17571 for the fix.




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

Kernel: Linux 5.10.155 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages trac depends on:
pn  libjs-excanvas   
ii  libjs-jquery 3.6.1+dfsg+~3.5.14-1
pn  libjs-jquery-timepicker  
ii  libjs-jquery-ui  1.13.2+dfsg-1
ii  python3  3.10.6-3
ii  python3-jinja2   3.0.3-2
ii  python3-pkg-resources65.5.0-1
ii  python3-setuptools   65.5.0-1

Versions of packages trac recommends:
pn  apache2 | httpd 
ii  python3-babel   2.10.3-1
ii  python3-docutils0.19+dfsg-2
ii  python3-pygments2.13.0+dfsg-1
pn  python3-subversion  
ii  python3-tz  2022.6-1

Versions of packages trac suggests:
pn  libapache2-mod-wsgi
pn  python3-psycopg2   
pn  python3-textile
pn  trac-accountmanager
pn  trac-authopenid
pn  trac-bitten
pn  trac-bzr   
pn  trac-customfieldadmin  
pn  trac-email2trac
pn  trac-graphviz  
pn  trac-ja-resource   
pn  trac-mastertickets 
pn  trac-mercurial 
pn  trac-spamfilter
pn  trac-wikiprint 
pn  trac-wikirename
pn  trac-wysiwyg   
pn  trac-xmlrpc

Bug#1024646: systemd: explicitly build depend on libcrypt-dev

[Helmut Grohne]

Source: systemd
Version: 252.1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

In order to facilitate architecture bootstrap, we need to move
libcrypt-dev out of build-essential thus breaking dependency cycles.
Since systemd uses it, it should depend on it explicitly. I'm attaching
a patch for your convenience.

Helmut
diff --minimal -Nru systemd-252.1/debian/changelog 
systemd-252.1/debian/changelog
--- systemd-252.1/debian/changelog  2022-11-08 15:23:22.0 +0100
+++ systemd-252.1/debian/changelog  2022-11-22 17:43:32.0 +0100
@@ -1,3 +1,10 @@
+systemd (252.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly B-D on libcrypt-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 22 Nov 2022 17:43:32 +0100
+
 systemd (252.1-1) unstable; urgency=medium
 
   * d/watch: switch back to stable repository
diff --minimal -Nru systemd-252.1/debian/control systemd-252.1/debian/control
--- systemd-252.1/debian/control2022-11-08 15:23:22.0 +0100
+++ systemd-252.1/debian/control2022-11-22 17:43:23.0 +0100
@@ -27,6 +27,7 @@
gperf,
gnu-efi [amd64 i386 arm64 armhf riscv64],
libcap-dev,
+   libcrypt-dev,
libpam0g-dev,
libapparmor-dev (>= 2.13) ,
libidn2-dev ,

Bug#1024627: Acknowledgement (gitlab: Fails to install)

[Pirate Praveen]

On Tue, Nov 22 2022 at 02:39:40 PM +01:00:00 +01:00:00, Kurt Roeckx 
 wrote:
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 
version

from backports is too new it seems, and it what gets installed when
you just do: apt install gitlab



Some of the version requirements for omniauth-oauth2 is too strict, 
which should be fixed. But as a workaround, you can install 1.7.3 
version, till we fix this properly.

Bug#1024645: pam: explicitly build depend on libcrypt-dev

[Helmut Grohne]

Source: pam
Version: 1.5.2-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

In order to facilitate architecture bootstrap, we need to move
libcrypt-dev out of build-essential thus breaking dependency cycles.
Since pam uses it, it should depend on it explicitly. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru pam-1.5.2/debian/changelog pam-1.5.2/debian/changelog
--- pam-1.5.2/debian/changelog  2022-10-06 20:56:06.0 +0200
+++ pam-1.5.2/debian/changelog  2022-11-22 17:51:14.0 +0100
@@ -1,3 +1,10 @@
+pam (1.5.2-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly B-D on libcrypt-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 22 Nov 2022 17:51:14 +0100
+
 pam (1.5.2-5) unstable; urgency=medium
 
   * pam_namespace_helper manpage *wasn't* missing, it was just being
diff --minimal -Nru pam-1.5.2/debian/control pam-1.5.2/debian/control
--- pam-1.5.2/debian/control2022-10-06 20:56:06.0 +0200
+++ pam-1.5.2/debian/control2022-11-22 17:51:13.0 +0100
@@ -4,7 +4,7 @@
 Uploaders: Sam Hartman 
 Maintainer: Steve Langasek 
 Standards-Version: 4.6.0
-Build-Depends: debhelper-compat (= 13), dh-exec, quilt, flex, libdb-dev, 
libselinux1-dev [linux-any], po-debconf, dh-autoreconf, autopoint, libaudit-dev 
[linux-any] , pkg-config, libfl-dev, libfl-dev:native, docbook-xsl, 
docbook-xml, xsltproc, libxml2-utils, w3m
+Build-Depends: debhelper-compat (= 13), dh-exec, quilt, flex, libdb-dev, 
libcrypt-dev, libselinux1-dev [linux-any], po-debconf, dh-autoreconf, 
autopoint, libaudit-dev [linux-any] , pkg-config, libfl-dev, 
libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m
 Build-Conflicts-Indep: fop
 Build-Conflicts: libdb4.2-dev, libxcrypt-dev
 Vcs-Browser: https://salsa.debian.org/vorlon/pam