Bug#1058998: discosnp: add loong64 support

2023-12-18 Thread Zhang Na
Source: discosnp
Version: 1:2.6.2-2
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loong64 support, fix debian/contorl.
  Dependent package libgatbcore-dev, similar questions have been submitted 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058714)



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 29960adf5bd9e0598c6625d4e884dec8a3bd6b55 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Tue, 19 Dec 2023 07:36:18 +
Subject: [PATCH] add loong64 support

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index f7a7afd..d0a9ddc 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Homepage: http://colibread.inria.fr/discosnp/
 Rules-Requires-Root: no
 
 Package: discosnp
-Architecture: any-amd64 arm64 mips64el ppc64el ia64 ppc64 riscv64 sparc64 alpha
+Architecture: any-amd64 arm64 mips64el ppc64el ia64 ppc64 riscv64 sparc64 
alpha loong64
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  ${python3:Depends},
-- 
2.43.0



Bug#1058868: [Debichem-devel] Bug#1058868: gemmi: Please build shared library

2023-12-18 Thread Andrius Merkys

Control: owner -1 !
Control: tags -1 - moreinfo

Hi,

On 2023-12-18 09:47, Yadd wrote:
yas I'm going to package ovito which depends on it. If shared library 
isn't provided, cmake automatically uses libgemmi_cpp.a which then embed 
gemmi into ovito 


I see. OK, let me apply your patch and build the shared library for 
gemmi, and let's see what happens.


Best wishes,
Andrius



Bug#1058572: [pkg-gnupg-maint] Bug#1058572: Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd

2023-12-18 Thread NIIBE Yutaka
Hello, again,

YunQiang Su  wrote:
> gpg: error writing public keyring '[keyboxd]': Attempt to write a
> readonly SQL database
> Key generation failed: Attempt to write a readonly SQL database

NIIBE Yutaka  wrote:
> I can't replicate this issue on my system.  With a new user I created
> for the test, I had no problem; The directory ~/.gnupg is created,
> ~/.gnupg/public-keys.d is created, and ~/.gnupg/public-keys.d/pubring.db
> is created.  Note that keyboxd just works with systemd by socket
> activation.

For your information, I managed to replicate the error by doing
following:

# For the user having no .gnupg directory, run gpg at the first
# time.  It creates .gnupg directory by gpg and .gnupg/public-keys.d
# by keyboxd
$ gpg -k
gpg: directory '/home/u/.gnupg' created
gpg: /home/u/.gnupg/trustdb.gpg: trustdb created

# Move the ~/.gnupg/public-keys.d while it is in-use by keyboxd
$ mv ~/.gnupg/public-keys.d ~/.gnupg/public-keys.d.bak

# In this situation, creat a key, to be stored by keyboxd
# Then, we see the error
$ gpg --pinentry-mode=loopback --debug ipc --quick-gen-key "a user 
"
[...]
gpg: writing public key to '[keyboxd]'
gpg: error writing public keyring '[keyboxd]': Attempt to write a readonly 
SQL database
Key generation failed: Attempt to write a readonly SQL database

The error may occur, when the database is moved and some data is to be written.

I don't think your case was same, but when someone encounters similar,
this would be an information to investigate the cause.
-- 



Bug#1058997: flask-autoindex is incompatible with Py3.12

2023-12-18 Thread Alexandre Detiste
Source: flask-autoindex
Version: 0.6.6-3
Severity: important
Forwarded: https://github.com/general03/flask-autoindex/issues/71

Dear Maintainer,

by using python3-future, your project is not compatible with Python3.12.

This issue is already tracked upstream at:

https://github.com/general03/flask-autoindex/issues/71

There's not too much to patch out:

$ grep future -r

Lines to simply remove altogether:

  tests/__init__.py:from __future__ import absolute_import   (not related to 
python3-future)
  tests/__init__.py:from future.builtins import bytes
  flask_autoindex/icons.py:from __future__ import absolute_import  (not related 
to python3-future)
  flask_autoindex/entry.py:from future import standard_library
  flask_autoindex/entry.py:standard_library.install_hooks()
  flask_autoindex/__init__.py:from __future__ import absolute_import  (not 
related to python3-future)
  flask_autoindex/__init__.py:from future.builtins import object, str
  debian/control: python3-future ,
  Flask_AutoIndex.egg-info/requires.txt:future>=0.13.0

Tiny patching needed:

  setup.py:install_requires=['Flask>=1.1', 'Flask-Silk>=0.2', 
'future>=0.13.0'],
  flask_autoindex/entry.py:from future.utils import with_metaclass
  flask_autoindex/entry.py:from future.moves.urllib.parse import urljoin


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

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



Bug#1058996: libzypp: add loongarch64 support

2023-12-18 Thread zhangdandan

Source: libzypp
Version: 17.31.23-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The libzypp source package lacks LoongArch architecture support.
Please consider the patch I have attached.
The libzypp source package was compiled successfully on my local loong64 
rootfs environment, and the test results are as follows,

```
The following tests passed:
    Capabilities_test
    Deltarpm_test
    InstanceId_test
    Resolver_test
..
    KeyRing_test
    PluginFrame_test
    ExternalProgram_test
    Fetcher_test
100% tests passed, 0 tests failed out of 86
Total Test time (real) =  17.11 sec
```
At the same time, I have submitted the patch(for loongarch64) to the 
upstream of libzypp software, and the submitted pull request link is 
https://github.com/openSUSE/libzypp/pull/504.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

Description: Add loongarch64 support 
Last-Update: 2023-12-18

--- libzypp-17.31.23.orig/zypp/Arch.cc
+++ libzypp-17.31.23/zypp/Arch.cc
@@ -227,6 +227,8 @@ namespace zypp
   DEF_BUILTIN( mipsel );
   DEF_BUILTIN( mips64 );
   DEF_BUILTIN( mips64el );
+
+  DEF_BUILTIN( loong64 );
 #undef DEF_BUILTIN
 
   ///
@@ -382,6 +384,8 @@ namespace zypp
 defCompatibleWith( a_mipsel(),		a_noarch() );
 defCompatibleWith( a_mips64(),		a_noarch() );
 defCompatibleWith( a_mips64el(),	a_noarch() );
+
+defCompatibleWith( a_loong64(),		a_noarch() );
 //
 ///
 // dumpOn( USR ) << endl;
--- libzypp-17.31.23.orig/zypp/Arch.h
+++ libzypp-17.31.23/zypp/Arch.h
@@ -295,6 +295,9 @@ namespace zypp
   extern const Arch Arch_mips64;
   /** \relates Arch */
   extern const Arch Arch_mips64el;
+
+  /** \relates Arch */
+  extern const Arch Arch_loong64;
   //@}
 
   ///
--- libzypp-17.31.23.orig/zypp/parser/yum/schema/common-inc.rnc
+++ libzypp-17.31.23/zypp/parser/yum/schema/common-inc.rnc
@@ -67,6 +67,7 @@ private.archenum = "noarch"
 | "armv4l"
 | "armv3l"
 | "riscv64"
+| "loong64"
 | "sh3"
 | "sh4"
 | "sh4a"
--- libzypp-17.31.23.orig/zypp/parser/yum/schema/common-inc.rng
+++ libzypp-17.31.23/zypp/parser/yum/schema/common-inc.rng
@@ -130,6 +130,7 @@
   armv4l
   armv3l
   riscv64
+  loong64
   sh3
   sh4
   sh4a


Bug#1058995: pyhamtools: please remove usage of python3-future

2023-12-18 Thread Alexandre Detiste
Source: pyhamtools
Severity: normal

Dear Maintainer,

python3-future is buggy with Python 3.12 and is being
removed from Debian.

Upstream website states they want to drop Py2.7 support "in 2023".

I've created an issue to activate this plan.
https://github.com/dh1tw/pyhamtools/issues/26

Even if they publish a new release quickly,
make sure to remove references to "python3-future" in debian/control.

Alternatively I'll provide a patch in January.

Greetings,

Alexandre


pyhamtools $ grep past -r
test/execfile.py:# While the package 'past.builtins' provide a python2 / 
python3 compatible version of 'execfile', 
test/execfile.py:# the import of 'past.builtins' keeps on throwing a 
deprecation warning about 'imp'.
test/execfile.py:# Therefore the version of 'execfile' from 'past/builtins' has 
been replaced by this alternative
--> nothig to do

pyhamtools $ grep future -r
test/test_lotw.py:from future.utils import iteritems
test/test_clublog.py:from future.utils import iteritems
setup.py:  "future>=0.18.2",
pyhamtools/qsl.py:from future.utils import iteritems
debian/control: python3-future,
debian/control: python3-future,


# this is not about python3-future, it's harmless:

test/test_lookuplib_gettersetter_api.py:from __future__ import unicode_literals
test/test_lookuplib.py:from __future__ import unicode_literals
pyhamtools/lookuplib.py:from __future__ import unicode_literals
pyhamtools/locator.py:from __future__ import division



Bug#1058994: debian-installer: fakeroot is pseudo-required

2023-12-18 Thread Roland Clobus
Source: debian-installer
Version: 20230217
Severity: normal
Tags: d-i

Hello Debian-installer team,

Recently the dependency tree of the packages that are required for building the
Debian Installer (using mk-build-deps) has changed, now fakeroot is no longer
installed per default in chroot environments.
However, the 'daily-build' script still has the default value for 'ROOTCMD' as
'fakeroot'.

This issue was seen on Jenkins, where the installer is rebuilt from git for the
sid images (as part of the live image build) [1]

I've built 2 variants of the bookworm image, one with additionally installing
fakeroot in my chroot environment and one with 'ROOTCMD=" "'. Both are
identical, so fakeroot is indeed not required for a proper build.

Can the default value for ROOTCMD be changed to an empty value (and the
corresponding check be removed)? [3]

With kind regards,
Roland Clobus

---
[1]
https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_standard_sid/671/console
P: building the debian-installer
./daily-build: line 117: fakeroot: command not found
E: An unexpected failure occurred, exiting...

[2] /home/roland/git.nobackup/live-build/test/rebuild.sh --configuration
standard --debian-version bookworm --timestamp archive --installer-origin git

[3] https://sources.debian.org/src/debian-
installer/20230607%2Bdeb12u4/build/daily-build/#L52


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

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



Bug#1058993: ITP: golang-github-cloudsoda-go-smb2 -- client implementation of the SMB 2 & 3 protocols

2023-12-18 Thread Maytham Alsudany
Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1057067 by -1

* Package name: golang-github-cloudsoda-go-smb2
  Version : 0.0~git20231124.f3ec8ae
  Upstream Contact: https://github.com/cloudsoda/go-smb2/issues
* URL : https://github.com/cloudsoda/go-smb2
* License : BSD-2-Clause
  Programming Lang: Go
  Description : client implementation of the SMB 2 & 3 protocols

 SMB2/3 client implementation.
Dependency of new upstream release (1.65) of rclone.

Is a fork of and will supersede the existing package 
golang-github-hirochachacha-go-smb2.

- Will need a sponsor
- Will be maintained in Debian Go Packaging Team

Kind regards,
Maytham





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


Bug#1058992: odil: add loong64 support

2023-12-18 Thread Zhang Na
Source: odil
Version: 0.12.2-3
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loong64 support, please! Thanks.

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 6c23feb87e751cae8de5661a2f343f538c3f6b48 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Tue, 19 Dec 2023 06:24:05 +
Subject: [PATCH] add loong64 support

---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 2204f1c..8ae7434 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,7 @@ Homepage: https://github.com/lamyj/odil
 Rules-Requires-Root: no
 
 Package: libodil0
-Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x alpha ia64 
powerpc ppc64 riscv64 x32
+Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x alpha ia64 
powerpc ppc64 riscv64 x32 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
@@ -55,7 +55,7 @@ Description: C++11 library for the DICOM standard
  This package contains the shared library.
 
 Package: libodil-dev
-Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x
+Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x loong64
 Multi-Arch: same
 Section: libdevel
 Depends: libodil0 (= ${binary:Version}),
@@ -94,7 +94,7 @@ Description: C++11 library for the DICOM standard 
(documentation)
  This package contains the documentation files.
 
 Package: python3-odil
-Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x
+Architecture: amd64 arm64 armel armhf i386 mipsel ppc64el s390x loong64
 Multi-Arch: foreign
 Section: python
 Depends: libodil0 (= ${binary:Version}),
-- 
2.43.0



Bug#1057708: mariadb-plugin-provider-bzip2: It looks like mariadb-plugin-provider-bzip2 should have a strong version depencene on mariadb-server

2023-12-18 Thread Otto Kekäläinen
Hi!

Currently in 
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/control?ref_type=heads
we have

Package: mariadb-server
Architecture: any
Suggests: mailx,
  mariadb-test,
  netcat-openbsd
Recommends: libhtml-template-perl,
mariadb-plugin-provider-bzip2,
mariadb-plugin-provider-lz4,
mariadb-plugin-provider-lzma,
mariadb-plugin-provider-lzo,
mariadb-plugin-provider-snappy,
pv

and

Package: mariadb-plugin-provider-bzip2
Architecture: any
Depends: mariadb-server (>= 1:10.11.1-1),
 ${misc:Depends},
 ${shlibs:Depends}


The server recommending the plugins is a result of
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/36.

The plugin 'depends' on the server has existed from the start, and
thus the title of this bug report is misleading. You probably did
indeed run into a bug, the question is just what that bug actually
was.

In your bug report, please be specific of what was the actual bug
symptoms you encountered and what triggered it. If possible, attach a
copy-paste of the command you ran and the output.

Even better if you can provide a reproducible test case that can be
run for example in a container to prove that a specific upgrade
scenario is broken.

Keep in mind that Debian is open source and we do not provide support.
In the spirit of open source you need to participate in debugging the
issues you encounter yourself and provide detailed bug reports. If you
want somebody else to do the debugging work on behalf of you, please
contract a service provider (e.g. one listed at
https://mariadb.org/about/#service-providers).

Thanks!



Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.

2023-12-18 Thread Otto Kekäläinen
Thanks Daniel Lewart!

I filed your submission at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61
for review/testing/feedback.



Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

2023-12-18 Thread Gayathri Berli
Hi @Simon McVittie

With the help of cargo build environment setup inside the docker environment, 
we are finally able to reproduce the issue in Debian on s390x.
After a lot of trails, we were able to figure out the working and non-working 
debian unstable releases. Please find the details below..

Working docker setup: 
debian:unstable-20221114-librsvg2-dev_2.54.5+dfsg-1_s390x.deb
Non-Working docker setup: 
debian:unstable-20221024-librsvg2-dev_2.54.5+dfsg-1_s390x.deb.

We are suspecting that the dependency packages might be causing the issue. Here 
is the list of dependency packages. By keeping the working setup as a base, we 
are now trying to upgrade each of these packages one by one, run the cargo test 
to see if we can reproduce the issue…


  *
libxml (2.9.14+dfsg-1.1+b2)
  *
gi-docgen (2022.2+ds-1)
  *
gobject (5.2.0-2+b1)
  *
python (3.10.6-2)
  *
rust (1.62.1+dfsg1-1)
  *
harfbuzz (5.2.0-2+b1)

Out of the packages listed above, I tried upgrading libxml, libharfbuzz and 
libglib packages. So far, I have not been able to reproduce the issue. I will 
try upgrading the remaining packages and see if I can reproduce the issue. I 
will update more on this sooner.

 Please note that I am working on upgrading the dependency package according to 
the https://snapshot.debian.org/


Thanks,
Gayathri.

From: Gayathri Berli
Sent: Wednesday, September 20, 2023 10:42 AM
To: 1038...@bugs.debian.org <1038...@bugs.debian.org>
Cc: Vishwanatha H.D ; Simon McVittie 
Subject: RE: Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple 
test regressions since September 2022


Gentle Reminder..!

Thanks,

Gayathri



From: Gayathri Berli
Sent: Monday, August 28, 2023 11:36 AM
To: 1038...@bugs.debian.org
Cc: Vishwanatha H.D ; Simon McVittie 
Subject: Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test 
regressions since September 2022



Hi Debian folks,



We are looking into a Debian Bug#1038447: librsvg: FTBFS on big-endian 
architectures: multiple test regressions since September 2022.



Simon has helped us to reproduce the issue by the following way. Thanks, simon 
for your kind support. We are trying these steps on our s390x machine of Debian 
kernel version 6.3.7-1.



  *   Have a Debian unstable chroot, container or machine with 
build-dependencies for the package. I used schroot on the Debian s390x
  *   porterbox zelenka:



 *   schroot -n librsvg -c sid --begin
 *   s=librsvg; p=librsvg; dd-schroot-cmd -c $s apt-get -y update && 
dd-schroot-cmd -c $s apt-get -y dist-upgrade && dd-schroot-cmd -c $s apt-get -y 
install ccache git quilt git-buildpackage && dd-schroot-cmd -c $s apt-get -y 
build-dep $p



  *   but any chroot/container/machine with the build-dependencies should 
behave the same.
  *   gbp clone https://salsa.debian.org/gnome-team/librsvg.git
  *   cd librsvg
  *   git reset --hard debian/2.54.7+dfsg-2 (or skip this step to build the 
latest version)
  *   gbp pq import
  *   Edit debian/rules to remove the workaround: delete the lines from
  *   "ifeq ($(DEB_HOST_ARCH_ENDIAN),big)" until the next "endif"
  *   Build the package in the chroot
  *   schroot -c librsvg -r -- debuild -eCCACHE_DIR=$HOME/.cache/ccache 
-ePATH=/usr/lib/ccache:$PATH -uc -us -b

 *   Or you can enter the appropriate environment interactively and use:

  *   debuild -us -uc -b
  *   Expected result: a successful build.
  *   Actual result: multiple test failures, as reported previously.



These are "reftests" which render a reference SVG and compare it with a 
reference rendering. You can find the SVGs and reference renderings in

tests/fixtures/reftests/: for example, one failing test is 
coords-viewattr-02-b, which has its SVG at 
tests/fixtures/reftests/svg1.1/coords-viewattr-02-b.svg

and its reference rendering at

tests/fixtures/reftests/svg1.1/coords-viewattr-02-b.svg.

After the build finishes, each failed test will have the actual output in a 
file named like target/release/build/librsvg-*/out/coords-viewattr-02-b-out.png,

and a highlighted/emphasized visual diff in a file like 
target/release/build/librsvg-*/out/coords-viewattr-02-b-diff.png.

Those are the files that I attached to the upstream issues.

  *   Building librsvg using its upstream build procedure without Debian 
patches/packaging might also result in failed tests, but I haven't verified 
this.





Unfortunately, we are encountering an issue with the chroot as followed. We 
tried the best to resolve it, but nothing helped us move forward. Could anyone 
has faced the same issue/solution of it please let us know. If any other steps 
might be needed to reproduce the same, please confirm.



 [cid:image001.png@01D9EBAF.1462BE40]



Thanks in Advance..!





Thanks,

Gayathri.




Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

2023-12-18 Thread Gayathri Berli
Please note that the working and non-working debian docker version that I 
provided earlier was swapped.. Sorry for that..
Please find the correct versions below:


  *
Non-Working docker setup: 
debian:unstable-20221114-librsvg2-dev_2.54.5+dfsg-1_s390x.deb
  *
Working docker setup: 
debian:unstable-20221024-librsvg2-dev_2.54.5+dfsg-1_s390x.deb.

Thanks,
Gayathri.


Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr

2023-12-18 Thread Cyril Brulebois
Hi,

Chris Hofstaedtler  (2023-12-19):
> If you can reasonably expect that the package in question will not
> change name, or split out or move the systemd unit files in any
> other way, than strictly from /lib to /usr/lib, then this is safe to
> do now.

That's very safe to assume, yes. If that's enough to guarantee that I
won't actually be generating another problem down the line, I'm happy to
implement this change.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature


Bug#996832: xpdf: segmentation fault in case of incorrect Xpdf*font X resource

2023-12-18 Thread Vincent Lefevre
On 2023-12-18 23:58:24 +0100, Florian Schlichting wrote:
> I'm wondering if there's anything left to do in xpdf here, or if I can
> close this bug now? The original segfault is fixed and the font setting
> much improved. In my testing it's still possible to confuse Motif with
> using different charsets in LANG and LC_CTYPE together with an X core
> font, but not with Xft fonts...

I think that the bug can be closed.

I've changed my settings to have LANG=C.UTF-8 (I suppose that this
is better, and at least consistent with /etc/default/locale, which
already contains LANG=C.UTF-8). And indeed, this avoids the problem.

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



Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

2023-12-18 Thread Vincent Lefevre
Package: firmware-misc-nonfree
Version: 20230625-1
Severity: grave
Justification: renders package unusable

firmware-misc-nonfree triggers the following warnings:

update-initramfs: Generating /boot/initrd.img-6.5.0-5-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for module 
r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for module 
r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for module 
r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for module 
r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for module 
r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for module 
r8152
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for module 
r8152
W: Possible missing firmware /lib/firmware/i915/mtl_huc_gsc.bin for module i915
W: Possible missing firmware /lib/firmware/i915/mtl_guc_70.bin for module i915
W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_ahesasc.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_ahesasc.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_ahesasc.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_asb.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_asb.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_asb.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_asb.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_unload.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_unload.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_unload.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_unload.bin 
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga107/nvdec/scrubber.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/nvdec/scrubber.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/nvdec/scrubber.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/nvdec/scrubber.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/hs_bl_sig.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/sig.bin for module 
nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/image.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/desc.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/hs_bl_sig.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/sig.bin for module 
nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/image.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/desc.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/hs_bl_sig.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/sig.bin for module 
nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/image.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/desc.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/hs_bl_sig.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/sig.bin for module 
nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/image.bin for 
module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/desc.bin for 
module nouveau

while https://forums.debian.net/viewtopic.php?t=155793 says that
the solution is to install firmware-misc-nonfree!

And I get in the journalctl output:

Dec 19 04:02:54 qaa kernel: [ cut here ]
Dec 19 04:02:54 qaa kernel: nouveau :01:00.0: timeout
Dec 19 04:02:54 qaa kernel: WARNING: CPU: 7 PID: 1347 at 
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1792 
gf100_gr_init_ctxctl_ext+0x555/0x570 [nouveau]
Dec 19 04:02:54 qaa kernel: Modules linked in: cmac algif_hash algif_skcipher 
af_alg snd_hda_codec_hdmi qrtr bnep binfmt_misc snd_sof_pci_intel_tgl 
snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation 
snd_sof_intel_hda_mlink soundwire_cadence snd_sof_intel_hda snd_sof_pci 
snd_sof_xtensa_dsp intel_uncore_frequency snd_sof intel_uncore_frequency_common 
snd_sof_utils snd_soc_hdac_hda x86_pkg_temp_thermal snd_hda_ext_core 
intel_powerclamp snd_soc_acpi_intel_match btusb snd_soc_acpi coretemp 
snd_ctl_led btrtl snd_soc_core iwlmvm snd_hda_codec_realtek btbcm snd_compress 
btintel 

Bug#1058990: rnahybrid: add build support for loongarch64

2023-12-18 Thread zhangdandan

Source: rnahybrid
Version: 2.1.2-7
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The rnahybrid source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control.
Please consider the patch I have attached.
If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru rnahybrid-2.1.2/debian/control rnahybrid-2.1.2/debian/control
--- rnahybrid-2.1.2/debian/control  2023-01-07 17:32:46.0 +
+++ rnahybrid-2.1.2/debian/control  2023-01-07 17:32:46.0 +
@@ -13,7 +13,7 @@
 Rules-Requires-Root: no
 
 Package: rnahybrid
-Architecture: any-amd64 arm64 armhf any-i386 mips mips64el mipsel ppc64el 
s390x alpha hppa m68k powerpc powerpcspe ppc64 sh4 sparc64 x32 riscv64
+Architecture: any-amd64 arm64 armhf any-i386 loong64 mips mips64el mipsel 
ppc64el s390x alpha hppa m68k powerpc powerpcspe ppc64 sh4 sparc64 x32 riscv64
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Description: Fast and effective prediction of microRNA/target duplexes


Bug#1058989: appstream: Please add support for loong64

2023-12-18 Thread yalingfang

Source: appstream
Version: 1.0.1-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64




Dear Maintainer,


     Currently lack of some loong64 binary outputs for appstream in 
Loongarch platform.

Such as appstream-compose, libappstream-compose0 etc .

I have verified by Add loong64 to debian/control and rules file, All 
test cases are passed in my local env.

Attach the  patch.

Please add support for it. Thanks!
Any question, contact me!


add-support-for-loong64.patch
Description: Binary data


Bug#1058919: pktanon: add loong64 support

2023-12-18 Thread Zhang Na

On Mon, 18 Dec 2023 10:20:19 + Zhang Na wrote:
> Source: pktanon
> Version: 2~git20160407.0.2bde4f2+dfsg-11
> Severity: normal
> X-Debbugs-Cc: zhan...@loongson.cn
>
> Dear Maintainer,
>
> Add loong64 support, please.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unreleased
> APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: loong64 (loongarch64)
>
> Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU 
threads)
> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 
(charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set

> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
>

diff --git a/debian/control b/debian/control
index 1d1c793..9612928 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Vcs-Git: https://salsa.debian.org/debian/pktanon.git
 Vcs-Browser: https://salsa.debian.org/debian/pktanon

 Package: pktanon
-Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 
m68k powerpc ppc64 riscv64 sh4 sparc64 x32
+Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 
m68k powerpc ppc64 riscv64 sh4 sparc64 x32 loong64

 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: profile-based traffic anonymizer
  PKtAnon performs network trace anonymization, e.g. on pcap files.
--
2.43.0

>From 99e9175ab4a768f66958c7aae32d3e2accb61102 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Mon, 18 Dec 2023 10:17:07 +
Subject: [PATCH] add loong64 support

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 1d1c793..9612928 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Vcs-Git: https://salsa.debian.org/debian/pktanon.git
 Vcs-Browser: https://salsa.debian.org/debian/pktanon
 
 Package: pktanon
-Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
+Architecture: amd64 arm64 i386 mips64el mipsel ppc64el alpha hppa ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32 loong64
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: profile-based traffic anonymizer
  PKtAnon performs network trace anonymization, e.g. on pcap files.
-- 
2.43.0



Bug#1058988: grapefruit: please remove extraneous dependency on python3-future

2023-12-18 Thread Alexandre Detiste
Source: grapefruit
Severity: normal

python3-future is an old Python2 -> 3 translation layer.

It does not build with Python 3.12

90% of the packages dependy on it are like this one:
one just need to remove one or two lines from d/control;
(or maybe also patch setup.py).

So that's what I ask you to do too.

I'll do a follow up in 2024.

Greetings,

Alexandre



Bug#1058987: turing: please remove extraneous dependency on python3-future

2023-12-18 Thread Alexandre Detiste
Source: turing
Severity: normal

Dear Maintainter,

Please remove "python3-future" from debian/control;
your package will cope just fine.


python3-future is an old python2>3 transaltion layer
that is now being removed from Debian.


>try:
>from future.builtins import str, super
>except:
># not availabe on python 3.2 (but not needed)
>pass

Greetings,

Alexandre



Bug#1058986: scikit-rf: please package 0.30.0 and provide a d/watch file

2023-12-18 Thread Alexandre Detiste
Source: scikit-rf
Version: 0.15.4-2.1
Severity: normal

Hi,

v0.15 requires python3-future which is now being removed
from the archive, please package v0.30.0

https://github.com/scikit-rf/scikit-rf/releases/tag/v0.30.0

Greetings,

Alexandre



Bug#1052939: marked as done (lsp-mode: FTBFS: make: *** [debian/rules:4: binary] Error 25)

2023-12-18 Thread Xiyue Deng
Control: reopen -1
Control: found -1 8.0.0-6

It looks like the attempted fix in 8.0.0-6 is not reliable and still
fails in ppc64el[1] and s390x[2].  I'm working on a better fix which
is also forwarded upstream.

[1] https://ci.debian.net/packages/l/lsp-mode/testing/ppc64el/40221847/
[2] https://ci.debian.net/packages/l/lsp-mode/testing/s390x/40222364/

-- 
Xiyue Deng


signature.asc
Description: PGP signature


Bug#1058985: radon: please remove extraneous dependency on python3-future

2023-12-18 Thread Alexandre Detiste
Source: radon
Version: 5.1.0-2
Severity: normal

Dear Maintainer,

The library python3-future is buggy/unmaintained and is being
removed from Debian. Luckily your project don't really need it:

It seems packaging v6 is enough to solve this:

https://github.com/rubik/radon/pull/234

Greetings

Alexandre



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

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



Bug#1053138: unittest2: RM unittest2

2023-12-18 Thread Alexandre Detiste
I've filled 20-something bugs to task to remove extraneous Build-Dependency.

Follow up next year :-)



Bug#1058984: blockdiag: please remove old extraneous dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: blockdiag
Severity: normal

Dear Maintainer,

python3-unittest2 is being removed from the archive.

It was a port of Python3's "unittest" to Python2.

Your package hasn't required it for a long time.

Please remove it from debian/control.

Greetings



Bug#1058983: flake8-noqa: please remove old extraneous dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: flake8-noqa
Severity: normal

Dear Maintainer,

python3-unittest2 is being removed from the archive.

It was a backport of Python3's "unittest" to Python2.

Upstream is already using the real 'unittest'.

Greetings,


flake8-noqa $ grep unittest -r
  test.py:import unittest
  test.py:class TestFileScope(unittest.TestCase):
  test.py:class TestInline(unittest.TestCase):
  test.py:unittest.main()
x debian/control:   python3-unittest2 



Bug#1058982: gitinspector: please port this package to stdlib:unittest

2023-12-18 Thread Alexandre Detiste
Source: gitinspector
Severity: normal

Dear Maintainer,

I see that the whole Python3 port is carried as a patch
"port-to-python3.patch".

Could this patch be reworked to use plain 'unittest' from
the standard library instead of old fork
'python3-unittest2' ?

The goal is to remove python3-unittest2 from the archive.
This package is one of the handfull most complex one.

Greetings,



Bug#1058981: h5py: please remove old extraneous dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: h5py
Severity: normal

Dear Maintainer,

python3-unittest2 is obsolete: it was an
old backport of Python3's "unittest" to Python2.

Upstream does not use at all it anymore.

Please remove it from "debian/control" & "debian/tests/control",
so this library can be removed from Debian.

Greetings


   $ grep unittest -r
   h5py/tests/test_h5p.py:import unittest as ut
   h5py/tests/test_file.py:# unittest doesn't work with pytest fixtures (and 
possibly other features),
   h5py/tests/common.py:import unittest as ut
   docs/whatsnew/2.8.rst:* Use lazy-loading of run_tests to avoid strong 
dependency on unittest2
   docs/whatsnew/2.0.rst:* On Python 2.6, unittest2 is now required to run the 
test suite.
   docs/contributing.rst:implemented as methods on custom ``unittest.UnitTest`` 
subclasses;
X  debian/tests/control: python3-unittest2,
X  debian/tests/control: python3-unittest2,
X  debian/tests/control: python3-unittest2,
X  debian/tests/control: python3-unittest2,
X  debian/control:   python3-unittest2,
   debian/changelog:  * Add the missing B-D python-unittest2 for python2 tests



Bug#1058980: nwdiag: please remove extraneous dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: nwdiag
Version: 2.0.0+dfsg-1.1
Severity: normal

Dear Maintainer,

python3-unittest2 is being removed from Debian.
It was a backport of Python3 "unittest" to Python2

It may have been used by Upstream project ... before.

It can now safely be removed from debian/control.

Greetings



$ grep unittest -r
src/rackdiag/tests/test_rst_directives.py:import unittest
src/rackdiag/tests/test_rst_directives.py:class 
TestRstDirectives(unittest.TestCase):
src/rackdiag/tests/test_builder.py:import unittest
src/rackdiag/tests/test_builder.py:class TestBuildDiagram(unittest.TestCase):
src/packetdiag/tests/test_rst_directives.py:import unittest
src/packetdiag/tests/test_rst_directives.py:class 
TestRstDirectives(unittest.TestCase):
src/nwdiag/tests/test_rst_directives.py:import unittest
src/nwdiag/tests/test_rst_directives.py:class 
TestRstDirectives(unittest.TestCase):

debian/control:   python3-unittest2,
debian/changelog:  pep8, python-nose, python-unittest2, python-docutils, 
python-reportlab,



Bug#1058979: pyclipper: please remove extraneous dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: pyclipper
Severity: normal

Dear Maintainer,

python3-unittest2 is being removed from Debian
it was a backport of "unittest" to Python2.

Upstream source will handle this just fine,
one only need to tweak debian/control.

Upstream (old but ok):
>try:
>  from unittest2 import TestCase, main
>except ImportError:
>  from unittest import TestCase, main

Greetings



Bug#1058978: python-ciso8601: please remove old dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-ciso8601
Severity: normal

Dear Maintainer,

python3-unittest2 was a port of Python3 "unittest" to Python2.

It has now no purpose and it's being removed from Debian.

Please remove it from debian/control.

Upstream has moved away a long time ago.

Greetings



Bug#1058977: python-googleapi: please package 2.111.0 and remove outdated dependencies

2023-12-18 Thread Alexandre Detiste
Source: python-googleapi
Version: 1.7.12-1
Severity: normal


Dear Maintainer,

The libraries python3-six & python3-unittest2 once helped
to maintain Python2+3 billingual codebases but are now EOL.

Can you please consider consider the new 2.x release
and see if these can be removed from debian/control.

Greetings,



Bug#1058976: python-jedi: please remove old stale dependency python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-jedi
Severity: important

Dear Maintainer,

python3-unittest2 was a backport of Python3 "unittest" to Python2.

Upstream now uses the real thing.

Please drop the old stale dependency from your package:

$ grep unittest2 -r
debian/control: python3-unittest2,


Greetings



Bug#1054485: postfix: diff for NMU version 3.8.2-1.1

2023-12-18 Thread Chris Hofstaedtler
Control: tags 1054485 + patch
Control: tags 1054485 + pending

Dear maintainer,

I've prepared an NMU for postfix (versioned as 3.8.2-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer. Better, upload yourself in the meantime.

Best,
Chris

diff -Nru postfix-3.8.2/debian/changelog postfix-3.8.2/debian/changelog
--- postfix-3.8.2/debian/changelog	2023-09-14 20:08:10.0 +0200
+++ postfix-3.8.2/debian/changelog	2023-12-19 01:24:10.0 +0100
@@ -1,3 +1,13 @@
+postfix (3.8.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [Helmut Grohne]
+
+  * Install units using dh_installsystemd only. (Closes: #1054485)
+
+ -- Chris Hofstaedtler   Tue, 19 Dec 2023 01:24:10 +0100
+
 postfix (3.8.2-1) unstable; urgency=medium
 
   [Scott Kitterman]
diff -Nru postfix-3.8.2/debian/postfix.dirs postfix-3.8.2/debian/postfix.dirs
--- postfix-3.8.2/debian/postfix.dirs	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/postfix.dirs	2023-12-19 01:23:16.0 +0100
@@ -34,5 +34,4 @@
 var/spool/postfix/usr/lib/sasl2
 var/log
 var/lib/postfix
-lib/systemd/system
 lib/systemd/system-generators
diff -Nru postfix-3.8.2/debian/postfix.postfix-resolvconf.path postfix-3.8.2/debian/postfix.postfix-resolvconf.path
--- postfix-3.8.2/debian/postfix.postfix-resolvconf.path	1970-01-01 01:00:00.0 +0100
+++ postfix-3.8.2/debian/postfix.postfix-resolvconf.path	2023-12-19 01:23:16.0 +0100
@@ -0,0 +1,11 @@
+[Unit]
+Description=Watch for resolv.conf updates and restart postfix
+ConditionPathExists=/etc/resolv.conf
+
+[Path]
+PathChanged=/etc/resolv.conf
+Unit=postfix-resolvconf.service
+
+[Install]
+WantedBy=multi-user.target
+
diff -Nru postfix-3.8.2/debian/postfix.postfix-resolvconf.service postfix-3.8.2/debian/postfix.postfix-resolvconf.service
--- postfix-3.8.2/debian/postfix.postfix-resolvconf.service	1970-01-01 01:00:00.0 +0100
+++ postfix-3.8.2/debian/postfix.postfix-resolvconf.service	2023-12-19 01:23:16.0 +0100
@@ -0,0 +1,9 @@
+[Unit]
+Description=Copies updated resolv.conf to postfix chroot and restarts postfix.
+
+[Service]
+Type=simple
+ExecStart=/etc/resolvconf/update-libc.d/postfix
+
+[Install]
+WantedBy=multi-user.target
diff -Nru postfix-3.8.2/debian/postfix-resolvconf.path postfix-3.8.2/debian/postfix-resolvconf.path
--- postfix-3.8.2/debian/postfix-resolvconf.path	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/postfix-resolvconf.path	1970-01-01 01:00:00.0 +0100
@@ -1,11 +0,0 @@
-[Unit]
-Description=Watch for resolv.conf updates and restart postfix
-ConditionPathExists=/etc/resolv.conf
-
-[Path]
-PathChanged=/etc/resolv.conf
-Unit=postfix-resolvconf.service
-
-[Install]
-WantedBy=multi-user.target
-
diff -Nru postfix-3.8.2/debian/postfix-resolvconf.service postfix-3.8.2/debian/postfix-resolvconf.service
--- postfix-3.8.2/debian/postfix-resolvconf.service	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/postfix-resolvconf.service	1970-01-01 01:00:00.0 +0100
@@ -1,9 +0,0 @@
-[Unit]
-Description=Copies updated resolv.conf to postfix chroot and restarts postfix.
-
-[Service]
-Type=simple
-ExecStart=/etc/resolvconf/update-libc.d/postfix
-
-[Install]
-WantedBy=multi-user.target
diff -Nru postfix-3.8.2/debian/rules postfix-3.8.2/debian/rules
--- postfix-3.8.2/debian/rules	2023-09-14 19:53:19.0 +0200
+++ postfix-3.8.2/debian/rules	2023-12-19 01:23:16.0 +0100
@@ -193,8 +193,6 @@
 
 	install debian/configure-instance.sh $(libdir)
 	install debian/postfix-instance-generator ${base}/lib/systemd/system-generators/
-	install -m 644 debian/postfix@.service ${base}/lib/systemd/system/
-	install -m 644 debian/postfix-resolvconf.* ${base}/lib/systemd/system/
 	install debian/ip-up.d ${base}/etc/ppp/ip-up.d/postfix
 	install debian/ip-down.d ${base}/etc/ppp/ip-down.d/postfix
 	install debian/ip-up.d ${base}/etc/network/if-up.d/postfix
@@ -209,8 +207,7 @@
 	fi
 
 override_dh_installsystemd:
-	dh_installsystemd -p postfix --no-enable --no-start postfix-resolvconf.path
-	dh_installsystemd -p postfix --no-enable --no-start postfix-resolvconf.service
+	dh_installsystemd -p postfix --no-enable --no-start --name postfix-resolvconf
 	dh_installsystemd -p postfix --no-restart-after-upgrade postfix.service
 
 execute_before_dh_gencontrol:


Bug#1058975: python-unicodecsv: the Python2>3 migration is mostly over and this package should be removed from Trixie

2023-12-18 Thread Alexandre Detiste
Source: python-unicodecsv
Version: 0.14.1-7
Severity: normal

Dear Maintainers,

First thanks I use this package a lot on my Wheezy ... computers at work.

It is now almost not needed anymore on Debian,
but it's only of removal of other outdated package "python3-unittest2".

More generaly users may mistakenly be using these
old deprecated packages/backports instead of what they really need.

I already filled a trivial patch against 'recon-ng' and for python3-rows
it seems beeing worked up upstream.

>  Reverse Depends:
>Depends: recon-ng  --> patch sent
>Depends: python3-rows  https://github.com/turicas/rows/pull/367

This bug can later be raised in severity to remove package
from testing in a first step.



Greetings

Alexandre



Bug#1058974: python-pyftpdlib: please package 1.5.9 and see what remains of python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-pyftpdlib
Version: 1.5.7-3
Severity: important

Dear Maintainer,

python3-unittest2 is/was a backport of Python3 standard library "unittest" to 
Python2.

There are still some 'crumbs' of it floating in the repository,
but nothing unpatchable.

Hopefully Upstream would have cleaned up for you
and only thing to handle is debian/control.

Greetings,



$ grep unittest2 -r

pyftpdlib/test/__init__.py:import unittest2 as unittest  # requires "pip 
install unittest2"
debian/control:   python3-unittest2,
Makefile:   unittest2


Looks harmless ("winmake", "python.exe"):

appveyor.yml:  - "%WITH_COMPILER% %PYTHON%/python.exe -m pip install --upgrade 
unittest2 mock ipaddress pypiwin32 wmi pyopenssl psutil"
scripts/internal/winmake.py:DEPS.append('unittest2')
HISTORY.rst:- #285: test suite requires unittest2 module on python < 2.7.



Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr

2023-12-18 Thread Chris Hofstaedtler
Hi Cyril,

On Fri, Dec 08, 2023 at 10:48:59PM +0100, Cyril Brulebois wrote:
> Chris Hofstaedtler  (2023-12-08):
> > Can we help you out in any way to get the systemd units moved? It's
> > not so "early stage" anymore and the systemd units can certainly
> > move now.
> 
> I haven't been able to keep up with the state of this transition (having
> been busy with other topics that have been a blocker for it).

I hear you.

> If it's safe to move things around, I can handle that. At least that
> particular subject line from last week didn't seem encouraging:
> Subject: Pause /usr-merge moves
> See https://lists.debian.org/20231201210412.ga1344...@subdivi.de

Indeed, the concerns around these parts are a worry.

If you can reasonably expect that the package in question will not
change name, or split out or move the systemd unit files in any
other way, than strictly from /lib to /usr/lib, then this is safe to
do now.

Conversely, if you expect the package to change name, split out the
systemd unit files into another package, or otherwise move them
around, please do not move them now.

If the only things 'blocking' this bug is your time and/or
uncertainty about the situation right now, then this is also a good
to know datapoint.

I'm sorry that there are no easy (to read or otherwise) answers now,
and I also don't expect them to show up in the future :-/

Best,
Chris



Bug#1058973: python-rsa: please remove old stale dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-rsa
Severity: normal

Dear Maintainer,

python3-unittest2 is an old backport of Python3 code to Python2.

It is being removed from Debian.

Please remove it from you debian/control.

Upstream has already moved away:

$ grep
debian/control:  , python3-unittest2
CHANGELOG.md:- Removed obsolete unittest so all tests run fine on Python 3.2


Greetings

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

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



Bug#1058972: recon-ng: please move away from old, unmaintained python3-unicodecsv

2023-12-18 Thread Alexandre Detiste
Source: recon-ng
Severity: normal

Hi,

"unicodecsv" is a remnant of the Python2 era.

It should eventualy be removed from Debian.

It is also holding off the removal
of other old module "unittest2".

Please consider this patch:


diff --git a/debian/control b/debian/control
index e3fccf0..c87f5f1 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,6 @@ Depends:
  python3-flask,
  python3-lxml,
  python3-requests,
- python3-unicodecsv,
  python3-xlsxwriter,
  python3-yaml,
  python3-mechanize,
diff --git a/recon/core/web/exports.py b/recon/core/web/exports.py
index e17a907..77b774b 100644
--- a/recon/core/web/exports.py
+++ b/recon/core/web/exports.py
@@ -5,7 +5,7 @@ from io import BytesIO
 from recon.core.web.utils import add_worksheet, is_url
 import os
 import requests
-import unicodecsv as csv
+import csv
 import xlsxwriter
 
 def _jsonify(rows):


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

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



Bug#1058586: python-cogent 2020.12.21a+dfsg-4+deb11u1 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1058586 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: python-cogent
Version: 2020.12.21a+dfsg-4+deb11u1

Explanation: skip parallel tests on single-CPU systems



Bug#1058971: python-yarg: please remove extraneous old Build-Dep on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-yarg
Severity: normal

Dear Maintainer,

"unittest2" was a backport of Python 3's "unittest" to Python2.

It was usefull a long time ago.

Now upstream is using the real thing from the standard library.

Please remove it from d/control.

Greetings,


(PS: please also check python3-mock)



Bug#1058970: pgxnclient: please remove extraneous stale dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: pgxnclient
Severity: normal

Dear Maintainer,

python3-unittest2 was a backport of Python3's "unittest"
module to Python2.

Upstream is now using the real "unittest".

Please remove the reference from debian/control.

Greetings



Bug#1058969: xrayutilities: please drop extraneous build dependency on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: xrayutilities
Severity: normal


python3-unittest2 was a backport to Python2 of the standard "unittest" Python3.

Please remove if from the Build-Depedencies of your package
so it can late be removed from the archive.

Greetings



Bug#1058968: python-graphviz: please remove obsolete extraneous Build-Dep on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-graphviz
Severity: normal

Dear Maintainer,

python3-unittest2 was a backport of Python3's "unittest" to Python2.

Upstream has switched to use the real thing.

Can you please remove the references in:

  d/control
  d/test/control

Greetings



Bug#1058967: python-biopython: please remove extraneous Build-Dep on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-biopython
Severity: normal

Dear Maintainer,

python3-unittest2 was a backport of Python3's standard "unittest" to Python2.

Upstream is now using the real thing.

Please remove the override from debian/control.

Greetings,



Bug#1058926: evolution: best charset for korean

2023-12-18 Thread Simon McVittie
> Nowdays most Koreans prefer UTF-8 over EUC-KR in Email:
...
> -   { "EUC-KR", E_CHARSET_KOREAN, NULL },
> +   { "UTF-8", E_CHARSET_KOREAN, NULL },

> This is a more complicated issue than i might think.
> I will try again later.

If possible, I think this sort of change is better
discussed with the upstream maintainers of Evolution via
https://gitlab.gnome.org/GNOME/evolution/-/issues, rather than with
its Debian maintainers.

Thanks,
smcv



Bug#996832: xpdf: segmentation fault in case of incorrect Xpdf*font X resource

2023-12-18 Thread Florian Schlichting
Hi Vincent and Adam,

On Wed, Dec 01, 2021 at 08:23:07PM +, Adam Sampson wrote:
> (in the original report)
> > Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> 
> On Fri, Oct 22, 2021 at 02:34:44AM +0200, Vincent Lefevre wrote:
> > And if I give an explicit UTF-8 font such as
> >   Xpdf*font: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
> > I get complete garbage (lots of white squares).
> 
> After some investigation, this appears to be the result of a fault in
> Motif that makes it fail to understand your locale settings.
> It looks like _XmStringGetCurrentCharset detects the charset in use by
> looking at LANG, and doesn't know about LC_CTYPE. (I'm not sure why it
> doesn't use nl_langinfo(CODESET).) So this probably needs filing
> separately against the motif package...
> 
> > I'm also wondering how Xft fonts can be used. Syntax like
> > xft:Bitstream:size=9 (as used by fvwm) doesn't work.
> 
> I've just made some changes to the xpdf man page to document this
> better (and I've also made the -font argument map to the font resource,
> rather than fontList, since the latter doesn't always override the
> default styling in Motif).

On Thu, Dec 02, 2021 at 01:15:13AM +0100, Vincent Lefevre wrote:
> This seems fine and would actually solve bug 996831.


I'm wondering if there's anything left to do in xpdf here, or if I can
close this bug now? The original segfault is fixed and the font setting
much improved. In my testing it's still possible to confuse Motif with
using different charsets in LANG and LC_CTYPE together with an X core
font, but not with Xft fonts...

Florian



Bug#1058966: pynwb: please remove old extraneous build dep on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: pynwb
Version: 1.2.1-2
Severity: normal

Unittest2 was a backport of Python3's standard "unittest" to Python2.

Upstream is now using the real thing,
please remove this overide from debian/control.

Greetings,



Bug#1058965: hdmf: has a stale Build-Dep on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: hdmf
Severity: normal

Dear Maintainer,

You package has an obsolete Build-Dep on "python3-unittest2"
which was a backport of Python3's unittest to Python2.

Please remove it.

Upstream is now using the real thing.

Greetings,



Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?

2023-12-18 Thread Don Armstrong
On Sat, 16 Dec 2023, Cord Beermann wrote:
> However: if we implement this, i'd consider this as a workaround as
> mails that should not be distributed, should not be sent out in the
> first place.

That works for me; there's a missing feature in the BTS currently to
turn off e-mails to maintainers, so when that is in place, this
workaround can be removed.

-- 
Don Armstrong  https://www.donarmstrong.com

For a moment, nothing happened. Then, after a second or so, nothing
continued to happen.
 -- Douglas Adams



Bug#1058964: neo has a stale Build-Dep: on python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: neo
Severity: normal

python3-unittest2 was a backport of Python3's unittest to python.

"neo" is now using the real thing.

Please remove the override from debian/control.

Greetings



Bug#998073: wireplumber: fails to automatically switch to headphones when connected

2023-12-18 Thread Vincent Lefevre
Hi,

On 2022-10-09 02:48:27 +0200, Vincent Lefevre wrote:
> On 2022-10-05 09:45:03 +0200, Dylan Aïssi wrote:
> > Control: fixed -1 0.4.12-1
> [...]
> > I just uploaded the new wireplumber version with this feature in sid.
> > I wait your feedback to close (or not) this bug.
> 
> It is not fixed (same issue as previously), and worse, it appears
> to be rather broken: in VLC, when stopping and playing again, I get
> "Unknown output" and no sound at all! And each time I try, I get a
> new VLC instance in pavucontrol! I've attached a screenshot.
> 
> To reproduce:
>   1. In pavucontrol, while VLC is playing, select the headphones.
>   2. Switch off the headphones.
>  -> The output is now the speakers. OK.
>   3. Switch on the headphones.
>  -> The output is still the speakers. Bad (this is this bug).
>   4. Stop in VLC.
>   5. Play in VLC.
>  -> pavucontrol shows "Unknown output" for VLC. No sound.
>  Still no sound if I select the speakers or the headphones.

FYI, I have a new laptop, where I use wireplumber 0.4.13-1
(Debian stable) with the same Bluetooth devices (speakers and
headphones), and there are no such problems with it.

So either the bug has been fixed in wireplumber 0.4.13-1 or there
has been something else on the old laptop that broke wireplumber.

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



Bug#1058963: ITP: libioth -- Unified API for the Internet of Threads

2023-12-18 Thread capriott
Package: wnpp
Severity: wishlist
Owner: Andrea Capriotti 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libioth
  Version : 0.1
  Upstream Contact: VirtualSquare (Renzo Davoli )
* URL : http://www.virtualsquare.org
* License : LGPL2.1+ and GPL-2+
  Programming Lang: C
  Description : Unified API for the Internet of Threads

  libioth main goal is to provide a convenient API
  to interoperate with different network stack implementations.
  Libioth is also an infrastructure where the actual
  implementations can be loaded as plug-ins.
  Libioth's API is minimal: it includes the complete set of 
  Berkeley Sockets functions, some functions to add or delete
  a stack and 'msocket', an extended version of 'socket' providing
  one more leading argument to select which stack should
  manage the communication.

New upstream library for the Debian Virtualsquare project:

https://salsa.debian.org/virtualsquare-team



Bug#1058962: O: speedcrunch -- High precision calculator

2023-12-18 Thread Felix Krull

Package: wnpp

Severity: normal


For personal reasons I am orphaning the speedcrunch package.

The broken package that caused speedcrunch's removal from testing,
python3-quark-sphinx-theme, is currently broken because of a Sphinx
update. I was also maintaining the upstream of that package and packaged
it as a build dependency for speedcrunch, but won't be maintaining it
any more either. I have proposed to add the relevant bits directly into
the speedcrunch repo so they can be maintained there at least:
https://bitbucket.org/heldercorreia/speedcrunch/pull-requests/125

FWIW I'm sorry to leave speedcrunch broken like that, but evidently not
sorry enough to do something about it at this point.



Description: High precision calculator
 SpeedCrunch is a high precision and high speed calculator.
 .
 It's optimized for keyboard use and has advanced features: use of
functions,
 use of variables, result history, and syntax highlighting. It also
shows the
 result as you type.
 .
 SpeedCrunch has a very simple interface, so you can start to use it very
 quickly.



Bug#1055065: doesnt find useradd

2023-12-18 Thread Johannes Schauer Marin Rodrigues
Hi,

I'm the author of the change that removed Priority:Required packages from
build-essential. Since there has been no other input to this bug I thought I
just weigh in with my two cents.

On Tue, 5 Dec 2023 22:39:51 + Harlan Lieberman-Berg  
wrote:
> On Mon, 30 Oct 2023 17:14:57 +0100 Marc Haber
>  wrote:
> > debspawn create sid errors out because the tool cannot find useradd. I
> > have added adduser manually to "include_pkgs" in osbase.py and this
> > allows debspawn create sid to finish.
> 
> I've done a bit of digging, and I traced this problem back to a change
> in the way debootstrap works when installing the buildd variant, which
> is what debspawn uses.  In bug 837060, debootstrap stopped installing
> packages which were Priority: Required but not essential.

You CC-ed that bug in your last message but since the bug is archived I don't
think that had the effect you intended.

> Specifically, the passwd package is the cause here; failure to install
> passwd means that the `useradd` command is not available.  The reason
> that installing the adduser package fixed this is that adduser depends
> on passwd, so it was indirectly pulled in.

> It's certainly easy enough for us to fix on the debspawn side -- we can just
> unilaterally add the passwd package -- but it is a bit...  strange for us to
> have to fix.  It seems, to me, like this is something we should be able to
> rely on debootstrap for.  I've copied the relevant bug; hopefully we can get
> some input from the bootstrap folx.  (Maybe we should be using the minbase
> variant instead? Except we're always building packages... should we be using
> a specific user?  I'm not sure!)

My main motivation for this change in debootstrap was to prevent source
packages from missing to declare build dependencies because the buildd
debootstrap variant automatically pulls in Priority:required packages and thus
missing B-Ds on mount or tzdata or similar would go unnoticed.

I think my change had a similar effect here. Your code requires a package that
is not Essential:yes (passwd) and you did not explicitly install it but relied
on it getting installed implicitly. In my opinion, the correct way forward
would be to explicitly pull in all the packages your code needs (except of
course if they are Essential:yes). I'm sorry that my change has caused you more
work but in the end I think it helped discover a dependency of your code that
you did not make explicit.

Thanks!

cheers, josch

P.S.: Funny side note: missing passwd in the buildd profile is actually only
possible due to *two* changes that I triggered. One is the change in
debootstrap that you found but the other is apt no longer depending on adduser.
If it still did, you would not have a problem even with the current handling of
the buildd variant. See
https://salsa.debian.org/apt-team/apt/-/merge_requests/260/diffs

signature.asc
Description: signature


Bug#1040891: [Pkg-pascal-devel] Bug#1040891: fp-compiler-3.2.0:arm64 configure failure: EInvalidOp: Invalid floating point operation

2023-12-18 Thread Abou Al Montacir
Hi Mollusk,
> fp-compiler-3.2.0:arm64 completely fails on my system and has never worked.
Is it possible to try upgrading your system to latest Debian release and try
again?

> See below following error: 
> 
> sudo dpkg --configure fp-compiler-3.2.0:arm64
> 
> Setting up fp-compiler-3.2.0:arm64 (3.2.0+dfsg-12) ...
> An unhandled exception occurred at $00470960:
> EInvalidOp: Invalid floating point operation
>   $00470960
>   $00472FC0
>   $00472F04
>   $00470FA8
>   $00400EEC
>   $00402ACC
>   $99446E18
>   $00400668
This looks like your FPU is not supporting some opcode generated by FPC.
It would be good to try to find which tool was running when the issue happened.
You can try to edit the /var/lib/dpkg/info/fp-compiler-3.2.0\:amd64.postinst and
add set -x at the beginning to help debugging this.
-- 
Cheers,
Abou Al Montacir


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


Bug#1058961: ntpsec: postinst should check for user:group before adding them

2023-12-18 Thread Bob Proulx
Package: ntpsec
Version: 1.2.2+dfsg1-3
Severity: normal
Tags: patch

Every time the ntpsec package upgrades it attempts to unconditionally
add the ntpsec user and group as per the following postinst snippet.

addgroup --system --quiet ntpsec
adduser --system --quiet --ingroup ntpsec \
--no-create-home --home /nonexistent ntpsec

This logs errors because the user and group already exists.  Here is a
sample from the most recent update.

Dec 12 11:49:47 clash addgroup[4100]: The group `ntpsec' already exists as 
a system group. Exiting.
Dec 12 11:49:47 clash adduser[4113]: The home dir /nonexistent you 
specified can't be accessed: No such file or directory
Dec 12 11:49:47 clash adduser[4113]: The system user `ntpsec' already 
exists. Exiting.

Please test for the existence of those groups before creating them as
other packages such as apt and others do.  Adding the following "if"
and "getent" checking fixes this using the same method the apt package
and others do.

if ! getent passwd ntpsec > /dev/null; then
addgroup --system --quiet ntpsec
fi
if ! getent group ntpsec > /dev/null; then
adduser --system --quiet --ingroup ntpsec \
--no-create-home --home /nonexistent ntpsec
fi

Thank you for maintaining ntpsec in Debian.

Bob


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

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

Versions of packages ntpsec depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66
ii  libbsd0  0.11.7-4
ii  libc62.37-13
ii  libcap2  1:2.66-4
ii  libssl3  3.1.4-2
ii  netbase  6.4
ii  python3  3.11.2-1+b1
ii  python3-ntp  1.2.2+dfsg1-3
ii  tzdata   2023c-11

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-181

Versions of packages ntpsec suggests:
pn  apparmor   
pn  certbot
pn  ntpsec-doc 
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/ntpsec/ntp.conf changed [not included]

-- no debconf information



Bug#1052557: [Pkg-pascal-devel] Bug#1052557: fpc: Compiler bootstrap for more release architectures

2023-12-18 Thread Abou Al Montacir
On Tue, 2023-11-14 at 11:24 +0800, Bo YU wrote:
> Hi!
> On Sun, Sep 24, 2023 at 07:59:41PM +0200, Paul Gevers wrote:
> > Hi,
> > 
> > On 24-09-2023 19:38, Bastian Germann wrote:
> > > How is the bootstrap done and is it planned?
> > 
> > I recall that bug 551400 and/or 784569 give quite some insight in what 
> > needs to be done.
> > 
> > I don't have any plans of bootstrapping fpc ever again. If anything, 
> > I'd like to see the glibc 'arch' of fpc actually working, then we 
> > could support all Debian architectures *and* cross building would 
> > probably be easier. But it all has been a while.
> 
> I would like to add riscv64 and mips64el support for fpc here.
I also would like to add mips64el, and why not riscv64, but maybe we need to
wait for a new release (that was planned for last year already).
> 
> But there are some unknown field for me about glibc to support cross
> build on fpc. Could you share some links where I should to start?
> 
> Just follow this one?
> https://wiki.lazarus.freepascal.org/Cross_compiling
Let me check this after new Lazarus 3.0 is packaged.
-- 
Cheers,
Abou Al Montacir


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


Bug#1058960: dpkg: warning: unable to delete old directory '/usr/share/debian-reference': Directory not empty

2023-12-18 Thread Christoph Anton Mitterer
Package: debian-reference
Version: 2.109
Severity: normal


Hey.

Something looks odd with the package’s files registration in Debian.
On upgrade from 2.108 to 2.109 I got:
Unpacking debian-reference-common (2.109) over (2.108) ...
dpkg: warning: unable to delete old directory 
'/usr/share/debian-reference/images': Directory not empty
Preparing to unpack .../01-debian-reference-en_2.109_all.deb ...
Unpacking debian-reference-en (2.109) over (2.108) ...
dpkg: warning: unable to delete old directory '/usr/share/debian-reference': 
Directory not empty


And indeed, none of these files seem to belong to a Debian package:
$ dpkg -S /usr/share/debian-reference/images/*
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/caution.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/home.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/important.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/next.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/note.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/prev.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/tip.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/up.gif
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/warning.png
$ dpkg -S /usr/share/debian-reference/*
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/apa.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch01.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch02.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch03.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch04.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch05.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch06.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch07.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch08.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch09.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch10.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch11.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch12.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/debian-reference.css
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/debian-reference.en.pdf
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/debian-reference.en.txt.gz
dpkg-query: no path found matching pattern /usr/share/debian-reference/images
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/index.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/index.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/pr01.en.html

These files do however seem to exist in the package, though registered as:
$ grep /usr/share/doc/debian-reference-common/docs 
/var/lib/dpkg/info/debian-reference-common.list
/usr/share/doc/debian-reference-common/docs
/usr/share/doc/debian-reference-common/docs/.htaccess
/usr/share/doc/debian-reference-common/docs/debian-reference.css
/usr/share/doc/debian-reference-common/docs/images
/usr/share/doc/debian-reference-common/docs/images/caution.png
/usr/share/doc/debian-reference-common/docs/images/home.png
/usr/share/doc/debian-reference-common/docs/images/important.png
/usr/share/doc/debian-reference-common/docs/images/next.png
/usr/share/doc/debian-reference-common/docs/images/note.png
/usr/share/doc/debian-reference-common/docs/images/prev.png
/usr/share/doc/debian-reference-common/docs/images/tip.png
/usr/share/doc/debian-reference-common/docs/images/up.gif
/usr/share/doc/debian-reference-common/docs/images/warning.png
/var/lib/dpkg/info$ grep /usr/share/doc/debian-reference-common/docs 
/var/lib/dpkg/info/debian-reference-en.list
/usr/share/doc/debian-reference-common/docs
/usr/share/doc/debian-reference-common/docs/apa.en.html
/usr/share/doc/debian-reference-common/docs/ch01.en.html
/usr/share/doc/debian-reference-common/docs/ch02.en.html
/usr/share/doc/debian-reference-common/docs/ch03.en.html
/usr/share/doc/debian-reference-common/docs/ch04.en.html
/usr/share/doc/debian-reference-common/docs/ch05.en.html
/usr/share/doc/debian-reference-common/docs/ch06.en.html
/usr/share/doc/debian-reference-common/docs/ch07.en.html
/usr/share/doc/debian-reference-common/docs/ch08.en.html
/usr/share/doc/debian-reference-common/docs/ch09.en.html
/usr/share/doc/debian-reference-common/docs/ch10.en.html

Bug#1058959: python-quantities: please removed old suggestion for python3-unittest2

2023-12-18 Thread Alexandre Detiste
Source: python-quantities
Severity: normal


python3-unittest2 was a backport of Python3's unittest to Python2.

It has very littles usage left.

It will be removed soon from Debian.

Greetings,

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

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



Bug#1058958: ITP: laszip -- Lossless LiDAR compression

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: laszip
  Version : 3.5.0
  Upstream Author : Rapidlasso GmbH
* URL : https://laszip.org/
* License : BSD-2-clause, BSD-3-clause, Apache-2.0, BSL-1.0
  Programming Lang: Python, C, C++
  Description : Lossless LiDAR compression

LASzip quickly turns bulky LAS files into compact LAZ files without
information loss.

The package is reintroduced by the Science Team, with consent of the GIS team,
the previous maintainers. Among other things, it is needed for the Python
LASzip bindings, which in turn enable the optional LASzip support in LASpy.



-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmWAvtAACgkQ+C8H+466
LVkcqwwAwetn4chREePE+wrc171arleRn8sVAD6+BH5TKTVDhkwQdqc6p/9Yad3n
yZSmZv8oI59pSDqx/7iVtD3KL0y86x/UQL75nC2nfhDAMJ3VDQbcOIhD7G0RxTzE
vqE2EsRhogydUlwQdUTaDbZVpdexInww3rXrRpkptczQ4PxwFZZR8frduqHwFO7F
pCfWITZb4eA3zavw7DrkGqLv0hojdYLXcth+jtQwuvzqLaJQZdHGA79oSFJV65YL
nhxyyVtgImDf8LcogM+KEJ+3Joa+Er8MfE+CQjLep8nwzTwFiPOcLo0GyQaixGNV
Wy9+JfFGM0QirQ3zQPFMxO3k0+OqNw3CVyZV5GIISLuoUCAl5a5Bh1KDPCNRDsZU
bPeDYwrAr2zjgPY3OZfJH67eyIfVsz0w2hPqV1MsnB2qDUm+LsWrRkdb5kbWh3+0
hILlsyYNrbgdazJs3AL1eqIO/IMyXHQbPgqKNRNDuplTJoMaiHEmo4dY+qHSTuM6
otwGKu9D
=2IoO
-END PGP SIGNATURE-


Bug#1058957: RM: libxrdcephposix0, xrootd-ceph-plugins [armel, armhf] -- RoM; ANAIS

2023-12-18 Thread Mattias Ellert
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Control: affects -1 + src:xrootd

At the request of the maintainers of src:ceph I dropped the ceph
depending binary packages libxrdcephposix0 and xrootd-ceph-plugins from
src:xrootd for 32 bit architectures.

The packages seem to have been removed from unstable for all relevant
architectures, except armel and armhf where there still are present old
packages from before this change (version 5.6.2-2).

Mattias Ellert
Maintainer



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


Bug#1055316: heimdal: fails to build against glibc 2.38

2023-12-18 Thread Samuel Thibault
Brian May, le lun. 11 déc. 2023 17:54:42 +1100, a ecrit:
> Samuel Thibault  writes:
> >> Whaat is the process for a breaks transition?
> >
> > Some details examples are discussed in Bug#1043184 in the case of krb5.
> 
> Thinking if I just drop the symbols, this is going to break
> libafsauthent2 while we still have glibc 2.37 in unstable. Does this
> sound correct?

Indeed.

> Although maybe this does not matter, I see that there is already a
> serious bug against openafs anyway since
> August... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043131

It made the package out of testing, so in practice breaking
libafsauthent2 would not break testing, only unstable, and the kernel
module can't be built at the moment, so that could be just ignored.

Another way would be to change heimdal to always keep the rk_strlcpy
and rk_strlcat symbols for now, even when glibc provides strlcpy
and strlcat. That way glibc 2.38 can be uploaded fine, and dropping
rk_strlcpy and rk_strlcat can be done later on, once glibc 2.38 is
settled (and when we know that openafs can migrate again to testing).

Samuel



Bug#1057959: dhcpcd gets stopped during upgrade but never started again

2023-12-18 Thread Maximilian Engelhardt
On Mittwoch, 13. Dezember 2023 22:20:40 CET Martin-Éric Racine wrote:
> I've uploaded the fix to unstable.
> 
> Since this is not the sort of urgent issue that would warrant a
> separate update to Bookworm, I won't upload it there for now. However,
> I'll definitely include it if there ever is a security issue that
> requires an upload to Bookworm.
> 
> Martin-Éric

Hi Martin-Éric,

Thanks for the quick response and fix. I agree it does not make sense to fix 
the bug on it's own in bookworm as one won't run into this problem without the 
release of a new version.

Maxi

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


Bug#1058956: logilab-common: please make sure python3-import-metadata is not pulled in

2023-12-18 Thread Alexandre Detiste
Source: logilab-common
Version: please make sure python3-import-metadata is not pulled in
Severity: 1.9.8-1

Dear Maintainer,

Your package is pulling in python3-importlib-metadata
that has no real purpose anymore since release of Python 3.8.

Please ensure this dependency is removed.

Shipping 2.0.0 might be an easy fix.


logilab/common/deprecation.py-if sys.version_info >= (3, 8):
logilab/common/deprecation.py:from importlib import metadata as 
importlib_metadata
logilab/common/deprecation.py-else:
logilab/common/deprecation.py:import importlib_metadata


Greetings,

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

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



Bug#1058955: pre-commit: please remove extraneous dependency on old python3-importlib-metadata

2023-12-18 Thread Alexandre Detiste
Package: pre-commit
Version: 3.6.0-1
Severity: normal


Dear Maintainer,

python3-importlib-metadata provides "importlib_metadata"
which is a backport of "importlib.metadata" from the standard library.

pre-commit is modern, fast moving tool, it only uses "importlib.metadata".



"importlib_metadata" is now completely useless and should be
removed from Debian some day.

Thanks for you consideration


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

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

Versions of packages pre-commit depends on:
ii  nodeenv 0.13.4-1.1
ii  python3 3.11.4-5+b1
ii  python3-cfgv3.4.0-1
ii  python3-identify2.5.33-1
ii  python3-importlib-metadata  4.12.0-1
ii  python3-virtualenv  20.25.0+ds-1
ii  python3-yaml6.0.1-1+b1

pre-commit recommends no packages.

pre-commit suggests no packages.

-- no debconf information



Bug#1058954: libjpeg-dev: New upstream version libjpegturbo 3.0.1 available

2023-12-18 Thread Even Rouault

Package: libjpeg-dev
Version: 2.1.5-2
Severity: wishlist

Dear Maintainer,

New upstream version libjpegturbo 3.0.1 is available:
https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/3.0.1. It 
would be

good to update the package to it. Version 3 brings in particular support for
12-bit JPEG, while keeping backwards API and ABI compatibility

Best regards

Even

--
http://www.spatialys.com
My software is free, but my time generally not.



Bug#1058933: cubemap: introduced new file in /lib

2023-12-18 Thread Chris Hofstaedtler
* Steinar H. Gunderson  [231218 17:19]:
> On Mon, Dec 18, 2023 at 04:33:26PM +0100, Chris Hofstaedtler wrote:
> > I don't think there is anything you can "ask" about this.
> > 
> > Generally the idea is that in trixie and later, --prefix=/usr really
> > means that. Anything that excluded subdirs from ${prefix} should be
> > a thing of the past. If the upstream build system ignores ${prefix}
> > for a certain location, you'll need to override it :-(
> 
> Well, it's pretty straight-up autoconf (no automake). Makefile.in contains
> 
>   PREFIX=@prefix@
>   SYSCONFDIR=@sysconfdir@
>   LOCALSTATEDIR=@localstatedir@
>   LIBDIR=@libdir@
> 
> and installs into $(LIBDIR).
> 
> dh_auto_configure runs configure with (among others)
> 
>   --prefix=/usr --libdir=\${prefix}/lib/x86_64-linux-gnu 
> 
> But nothing ever defines lowercase ${prefix}. It's possible that it expects
> the upstream Makefile to do
> 
>   prefix=$(PREFIX)

I think thats what dh expects it to contain for everything to work,
yes. You could check out the "hello" source package, which has a bog
standard autoconf/automake setup and has, in Makefile.in:

...
libdir = @libdir@
...
prefix = @prefix@
...

and thus in Makefile:

...
libdir = ${prefix}/lib/x86_64-linux-gnu
...
prefix = /usr
...

> or something similar? But it's unclear to my why it doesn't just do
> 
>   --libdir=/usr/lib/x86_64-linux-gnu

Good question, don't know. There is no comment explaining this in
the debhelper source; maybe it was to avoid duplication there.
Maybe the easiest is to add --libdir=/usr/lib/${DEB_HOST_MULTIARCH}
to dh_auto_configure?

Best,
Chris



Bug#1058953: python-ldapdomaindump: please package a snaphot of upstream and remove dependency on python3-future

2023-12-18 Thread Alexandre Detiste
Source: python-ldapdomaindump
Version: 0.9.4-1
Severity: important

Dear Maintainer,

python3-future breaks with Python3.12 and is now being removed from Debian.


As of today, the top commit on upstream git fixes it:

https://github.com/dirkjanm/ldapdomaindump/commit/f77193450b6e69584163cd151fc4e21ec31e9cd7


Please also remove this dependency from the debian/control.

> Build-Depends: python3-future

Greetings,


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

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



Bug#1053791: Acknowledgement (tbsync: Please provide a backport for bookworm)

2023-12-18 Thread Martin
Control: notfound -1 4.7-1~deb12u1

Thanks for the new package, Mechtilde! Even better than a backport!

Now there is already upstream version 4.8 waiting to be packaged :-)



Bug#1056486: Info received (python-mpegdash's autopkg tests fail with Python 3.12)

2023-12-18 Thread Alexandre Detiste
The patch submitted upstream also removes extraneous unittest2

https://github.com/sangwonl/python-mpegdash/pull/61/files



Bug#1056486: python-mpegdash's autopkg tests fail with Python 3.12

2023-12-18 Thread Alexandre Detiste
here is a patch that removes extraneous import of future library
& most likely solves this bug
diff --git a/debian/control b/debian/control
index c3fa5b6..12b2535 100644
--- a/debian/control
+++ b/debian/control
@@ -8,8 +8,7 @@ Build-Depends: debhelper-compat (= 13),
dh-python,
python3-all,
python3-setuptools,
-Build-Depends-Indep: python3-future,
- python3-unittest2,
+Build-Depends-Indep: python3-unittest2,
 Standards-Version: 4.6.0
 Homepage: https://github.com/sangwonl/python-mpegdash
 Vcs-Browser: https://salsa.debian.org/python-team/packages/python-mpegdash
diff --git a/mpegdash/utils.py b/mpegdash/utils.py
index 4d7b828..7a08a91 100644
--- a/mpegdash/utils.py
+++ b/mpegdash/utils.py
@@ -1,4 +1,3 @@
-from past.builtins import unicode   # python3 compat
 from xml.dom import minidom
 
 import re
@@ -19,7 +18,7 @@ def parse_child_nodes(xmlnode, tag_name, node_type):
 
 nodes = []
 for elem in elements:
-if node_type in (unicode, str):
+if node_type is str:
 node = xmlnode.firstChild.nodeValue
 else:
 node = node_type()
diff --git a/requirements.txt b/requirements.txt
index 2c6edea..e69de29 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1 +0,0 @@
-future
diff --git a/setup.py b/setup.py
index 20b593d..2db676d 100644
--- a/setup.py
+++ b/setup.py
@@ -17,7 +17,6 @@ setup(
   license="MIT",
   zip_safe=False,
   include_package_data=True,
-  install_requires=["future"],
   url="https://github.com/sangwonl/python-mpegdash;,
   tests_require=["unittest2"],
   test_suite="tests.my_module_suite",


Bug#1058952: python-x2go: please package 0.6.1.4 so the dependency on python3-future can be removed

2023-12-18 Thread Alexandre Detiste
Source: python-x2go
Version: 0.6.1.3-3
Severity: normal


Dear Maintainer,

python3-future has outlived it's usefullness, is unmaintained
and is incompatible with Python 3.12.


Please make sure it is removed from d/control too.

debian/control: python3-future,


A patch with further cleanup has been submit to upstream DebBugs instance.

https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1619

Greetings,

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

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



Bug#1058951: libboost-all-dev is lacking dependencies on boost-json and boost-url

2023-12-18 Thread Matthias Klose

Package: src:boost-defaults
Version: 1.83.0.1
Severity: important
Tags: sid trixie

libboost-all-dev is lacking dependencies on boost-json and boost-url.



Bug#1058950: Target Threads::Threads not found by CMake

2023-12-18 Thread Nikolay Kyx
Package: libnanoflann-dev
Version: 1.5.3+ds-1
Severity: normal

cmake version 3.27.9-1, gcc (Debian 13.2.0-7)

Step to reproduce:
Add line
target_link_libraries(my_shiny_program PRIVATE nanoflann::nanoflann)
into CMakeLists.txt

Actual behaviour:
CMake Error at /usr/share/nanoflann/cmake/nanoflannTargets.cmake:61
(set_target_properties):
  The link interface of target "nanoflann::nanoflann" contains:
Threads::Threads
  but the target was not found.  Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.

Why not use find_package() like upstream?
https://github.com/jlblancoc/nanoflann/commit/5af493978bb74f755f0629b79601be9cf5920f11



Bug#1058949: RFS: dmidecode/3.5-3 -- SMBIOS/DMI table decoder

2023-12-18 Thread Jörg Frings-Fürst
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : dmidecode
   Version  : 3.5-3
   Upstream contact : dmidecode-de...@nongnu.org
   URL  : https://nongnu.org/dmidecode/
   License  : GPL-2+
   Vcs  : https://git.jff.email/cgit/dmidecode.git/
   Section  : utils

The source builds the following binary packages:

  dmidecode - SMBIOS/DMI table decoder
  dmidecode-udeb - SMBIOS/DMI table decoder (udeb)

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

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

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

 dget -x
https://mentors.debian.net/debian/pool/main/d/dmidecode/dmidecode_3.5-3.dsc


or from 

 git https://git.jff.email/cgit/dmidecode.git/?h=release%2Fdebian%2F3.5-3

or 

git (old) https://jff.email/cgit/dmidecode.git/?h=release%2Fdebian%2F3.5-3



Changes since the last upload:

 dmidecode (3.5-3) unstable; urgency=medium
 .
   * Add loong64 to architecture list (Closes: #1050154).


CU

Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






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


Bug#1058948: missing dependency on boost-url

2023-12-18 Thread Matthias Klose

Package: src:boost1.83
Version: 1.83.0-1
Severity: important
Tags: sid trixie

libboost1.83-all-dev is lacking a dependency on libboost-url1.83-dev.

what is the rationale for add the new deps to libboost1.83-all-dev, and 
not libboost1.83-dev?




Bug#1058947: RM: icinga2 [i386] -- ROM; FTBFS

2023-12-18 Thread Bas Couwenberg
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: icin...@packages.debian.org
Control: affects -1 + src:icinga2
Control: block 1028489 by -1

Please remove icinga2 from i386 where it FTBFS as part of the boost-1.83 
transition.

Kind Regards,

Bas



Bug#1058946: RM: python-twitter -- ROM; broken, obsolete, associated service doesn't exist anymore

2023-12-18 Thread Alexandre Detiste
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-twit...@packages.debian.org, 
debian-devel-ga...@lists.debian.org
Control: affects -1 + src:python-twitter


I'm lazy at time so I just copied the text from #1056614:

>This package and all Twitter related packages should be removed from the 
>archive.
>
>Twitter API access is broken, so there is no point keeping this in the archive.


Package is Team Maintained without any uplaoder listed =~ semi-orphaned.



As an added extra personnal nithpick:
this one also hinders python3-future removal.


Having this bug open ease triaging on the Tracker.

Greetings,



Bug#1052597: RFS: libkysdk-base/2.2.0.1-1 -- common files for kylin sdk base library

2023-12-18 Thread Tobias Frost
Control: tags -1 moreinfo

Hi xibowen,
On Mon, Oct 30, 2023 at 11:23:33AM +0800, xibowen wrote:
> Hi. thanks for reply.
> 
> >
> > I'm curious if libkysdk-base-common is really needed? This will also
> > require a NEW processing btw.
> >
> 
> I have removed the libkysdk-base-common and uploaded to mentors.
> 
> Lastest upload: https://mentors.debian.net/package/libkysdk-base/
> 
>  libkysdk-base (2.2.0.1-1) unstable; urgency=medium
>  .
>* Update libs soname version.
>* Fix compile error on armhf and ppc64el.
>* d/control:
>  - Add Multi-Arch.

(this is a partial review, as I ran out of time.)

- Updating the SONAME of a library requires this procedure to be followed:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions
  Comparing the symbols file does not make it obvious why you are
  bumping SONAME, but I did not check with abi-complicance-checker...
  Can you fill me in why you bump the soname?

- the breaks/replaces version seems odd, as it is a binnmu version.
  You likely want (<< 2.2.0.1-1~), though I am not sure why you think
  you'll need the Break/Replace? Can you exand?

- you could use d/clean instead of overriding dh_clean

- for the install files, for multiarch, a cleaner way would be to write
  /usr/lib/${DEB_HOST_MULTIARCH}/… instead of /usr/lib/*/…

-- 
Cheers,
tobi


signature.asc
Description: PGP signature


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

2023-12-18 Thread Ansgar
Package: python3-secretstorage
Version: 3.3.3-2
Severity: normal

Please do not depend on dbus.

Currently installing anything depending on python3-secretstorage will
install dbus-user-session and with it systemd-sysv, for example:
python3-poetry -> python3-keyring -> poetry3-secretstorage -> dbus

This is pretty useless in containers. So please do not force to
install it: it should be fine to just return an error in case the
secret storage service is not reachable, for example because there is
no dbus bus to use.

If anything, only applications should require specific interfaces. A
library like python3-secretstorage cannot know whether its use is
essential (in which case dbus should probably be a dependency) or
totally optional (in which case dbus should be suggested/recommended).

Ansgar



Bug#1057295: bcachefs-tools: breaks "mount" if the package is installed

2023-12-18 Thread Martin Steigerwald
Hi Jonathan, hi Adam!

Confirmed.

Moving "mount.bcachefs" out of the way fixes mounting via "fstab" and 
"mount" command. It also makes mounting work on boot with Devuan with 
Runit as init.

Help output of "bcachefs" command from self-compiled bcachefs-tools 1.3.3 
shows:

Mount:
  mountMount a filesystem

This is missing from the help output of "bcachefs" command, version 1.3.4, 
from the package.

Best,
-- 
Martin



Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))

2023-12-18 Thread Paul Gevers

Hi

On 18-12-2023 10:07, Andreas Tille wrote:

https://tracker.debian.org/pkg/r-bioc-megadepth


d/tests/control has

Architecture: !s390x

Why is it considered failing on s390x anyway?


The log has this at the end:
127s run-unit-testSKIP Test declares architecture as not 
supported: s390x
127s run-unit-testSKIP Test declares architecture as not 
supported: s390x

127s pkg-r-autopkgtestFAIL non-zero exit status 1

pkg-r-autopkgtest comes from autodep8. You didn't tell autodep8 that you 
wanted s390x to be excluded also from that test.



https://tracker.debian.org/pkg/r-bioc-scater


While this is an Architecture:all package it Depends from r-bioc-densvis
which exists only on amd64 and arm64 due to the Build-Depends:
r-bioc-basiklisk.  Thus tests on other architectures are failing since
r-bioc-densvis is not installable.  What solution do you suggest in this
case?


Well, mark the test as amd64 and arm64 only? Were this due to Depends 
(and thus the package not installable) the test would *automatically* 
not be scheduled if I'm correct, but it works differently for test 
dependencies.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1055493: [Emc-developers] Bug#1055493: linuxcnc-uspace, linuxcnc-uspace-dev: both packages ship the manpages

2023-12-18 Thread Sudip Mukherjee
On Tue, Nov 07, 2023 at 11:06:01AM +, andy pugh wrote:
> On Tue, 7 Nov 2023 at 10:45, Andreas Beckmann  wrote:
> >
> > Package: linuxcnc-uspace,linuxcnc-uspace-dev
> > Version: 2.9.1-2
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> >
> > Hi,
> >
> > during a test with piuparts I noticed your package failed to install
> > because it tries to overwrite other packages files:
> 
> I assume that this could be fixed by deleting the last line here:
> https://github.com/LinuxCNC/linuxcnc/blob/2.9/debian/linuxcnc-uspace-dev.install
> 
> However I haven't so far worked out why the man3 sections are being
> included in the main package installer.
> (the commands in man3 are only of interest to developers)

>From 
>https://sources.debian.org/src/linuxcnc/2.9.1-2/debian/linuxcnc-uspace.manpages/#L2

-- 
Regards
Sudip



Bug#1034649: 7kaa: Unplugging USB headset hangs 7kaa

2023-12-18 Thread P. J. McDermott
Hi Nils,

On Thu, 20 Apr 2023 22:20:34 +0200 Nils Dagsson Moskopp 
 wrote:
> whenever I unplug the USB headset while 7kaa is running, it hangs.
> 7kaa prints a single line of output to the terminal, quoted below:
> 
> > AL lib: (EE) ALCpulsePlayback_streamStateCallback: Received stream failure!

This looks like one of (many[1][2][3][4]) bugs in OpenAL's PulseAudio
backend (apparently OpenAL's upstream maintainer doesn't use PulseAudio,
which I don't either).  I found reports of it affecting at least one
other game.  If we can't solve it here, I'll reassign.

An apparent solution is to edit "/etc/openal/alsoft.conf" and under
"[pulse]" change "allow-moves" to "true".  Can you try this and report
whether that solves the issue?

It's also possible that there's an infinite loop somewhere in 7kaa's
src/openal/openal_audio.cpp triggered by this OpenAL error.  Could you
please install 7kaa-dbgsym, run 7kaa under gdb, reproduce the hang, and
get a backtrace?

$ apt install 7kaa-dbgsym gdb
$ gdb 7kaa
(gdb) run
^C
(gdb) backtrace
(gdb) quit

> Versions of packages 7kaa depends on:
[...]
> ii  libopenal1   1:1.19.1-2

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548373
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551018
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562524
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566634
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/



Bug#1058066: RFS ping

2023-12-18 Thread Alexandru Mihail
Uploaded, thanks !
https://mentors.debian.net/package/mini-httpd/
https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-6.dsc
> 
> Please upload your package to mentors. Thanks.
> 
> 



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


Bug#1058849: linphone: diff for NMU version 5.2.0-4.1

2023-12-18 Thread Dennis Filder
X-Debbugs-CC: Boyuan Yang 

On Sun, Dec 17, 2023 at 11:50:11AM -0500, Boyuan Yang wrote:
> I've prepared an NMU for linphone (versioned as 5.2.0-4.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer or cancel it.

No, it's okay.



Bug#1042967: nheko: diff for NMU version 0.11.3-2.1

2023-12-18 Thread Boyuan Yang
Control: tags 1042967 + patch
Control: tags 1042967 + pending

Dear maintainer,

I've prepared an NMU for nheko (versioned as 0.11.3-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru nheko-0.11.3/debian/changelog nheko-0.11.3/debian/changelog
--- nheko-0.11.3/debian/changelog   2023-03-23 12:17:45.0 -0400
+++ nheko-0.11.3/debian/changelog   2023-12-18 12:54:11.0 -0500
@@ -1,3 +1,14 @@
+nheko (0.11.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Force non-parallel build, hopefully fix OOM with
+armhf buildd build.
+  * debian/patches/:
++ 0003-Fix-voip-defaults-being-incorrect-because-OS-constan.patch:
+  Apply upstream fix on launch crashes with arm64. (Closes: #1042967)
+
+ -- Boyuan Yang   Mon, 18 Dec 2023 12:54:11 -0500
+
 nheko (0.11.3-2) unstable; urgency=medium
 
   * debian/control: Downgrade gstreamer1.0-vaapi to a Suggests.
diff -Nru 
nheko-0.11.3/debian/patches/0003-Fix-voip-defaults-being-incorrect-because-OS-constan.patch
 nheko-0.11.3/debian/patches/0003-Fix-voip-defaults-being-incorrect-
because-OS-constan.patch
--- 
nheko-0.11.3/debian/patches/0003-Fix-voip-defaults-being-incorrect-because-OS-constan.patch
 1969-12-31 19:00:00.0 -0500
+++ 
nheko-0.11.3/debian/patches/0003-Fix-voip-defaults-being-incorrect-because-OS-constan.patch
 2023-12-18 12:53:44.0 -0500
@@ -0,0 +1,34 @@
+From: Boyuan Yang 
+Date: Mon, 18 Dec 2023 12:52:42 -0500
+Subject: Fix voip defaults being incorrect because OS constants are not
+ defined
+
+Bug-Debian: https://bugs.debian.org/1042967
+Bug: https://github.com/Nheko-Reborn/nheko/issues/1574
+Applied-Upstream: 
https://github.com/Nheko-Reborn/nheko/commit/159493351313223ee88a7f34c8550c0b7af6b3e6
+---
+ CMakeLists.txt | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 41b01c8..648e8f8 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -47,6 +47,8 @@ macro(hunter_add_package_safe)
+   message("pkg_conf_path: '$ENV{PKG_CONFIG_PATH}', pkg_conf_libdir: 
'$ENV{PKG_CONFIG_LIBDIR}'")
+ endmacro()
+ 
++project(nheko LANGUAGES CXX C)
++
+ option(USE_BUNDLED_SPDLOG "Use the bundled version of spdlog." 
${HUNTER_ENABLED})
+ option(USE_BUNDLED_OLM "Use the bundled version of libolm." ${HUNTER_ENABLED})
+ option(USE_BUNDLED_GTEST "Use the bundled version of Google Test." 
${HUNTER_ENABLED})
+@@ -104,8 +106,6 @@ endif()
+ # Include Qt basic functions
+ include(QtCommon)
+ 
+-project(nheko LANGUAGES CXX C)
+-
+ include(GNUInstallDirs)
+ 
+ set(CPACK_PACKAGE_VERSION_MAJOR "0")
diff -Nru nheko-0.11.3/debian/patches/series nheko-0.11.3/debian/patches/series
--- nheko-0.11.3/debian/patches/series  2023-02-21 21:32:44.0 -0500
+++ nheko-0.11.3/debian/patches/series  2023-12-18 12:53:44.0 -0500
@@ -1,2 +1,3 @@
 cmake_coeurl
 httplib-pkgconfig
+0003-Fix-voip-defaults-being-incorrect-because-OS-constan.patch
diff -Nru nheko-0.11.3/debian/rules nheko-0.11.3/debian/rules
--- nheko-0.11.3/debian/rules   2023-02-21 21:03:58.0 -0500
+++ nheko-0.11.3/debian/rules   2023-12-18 12:50:25.0 -0500
@@ -15,7 +15,7 @@
 endif
 
 %:
-   dh $@
+   dh $@ --no-parallel
 
 # set $HOME to a dummy directory, because cmake tries to write stuff to $HOME
 override_dh_auto_build: FAKEHOME = HOME=$(CURDIR)/fakehome


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


Bug#1017780: 1.5.517 in salsa repository [was: Version bump: 1.4.230]

2023-12-18 Thread Chris Knadle

Hello Sven, thank you for your quick response.

On 12/18/23 03:57, Sven Hartge wrote:

On 18.12.23 07:37, Chris Knadle wrote:


Thank you very much for your efforts on this bug.

Most the changes the patches make and offhand look reasonable, and 
for the moment I've pulled them from the 'improvement' branch your 
mumble Git repo.
However I'm wondering about the permissions change to /etc/mumble as 
to why that's desired:


 chown root:mumble-server /etc/mumble/

What is the benefit of updating the /etc/mumble/ directory to have 
group ownership by mumble-server? Is the intent for allowing a number 
of users that are added to the mumble-server group to be allowed to 
update the mumble-server.ini file?


Let me know so I can explain it. ;-)


The problem is access to the configuration. If /etc/mumble is 
root:root and 750, then the daemon, running as 
mumble-server:mumble-server can't read its configuration file and 
fails to start.
Okay, right, because there are no "other" read or execute permissions to 
allow traversing the directory.
So /etc/mumble needs to be readable by the group, either 755 (which is 
worse security-wise) or owned by the group, which is the change I 
implemented.


The configuration file itself is 640 and root:mumble-server, so the 
group can't change it.

Accepted.

Grüße,
Sven. 


Grüße.

Thanks

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



Bug#1058559: vlfeat 0.9.21+dfsg0-6+deb11u1 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1058559 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: vlfeat
Version: 0.9.21+dfsg0-6+deb11u1

Explanation: fix FTBFS with newer ImageMagick



Bug#1056918: perl 5.32.1-4+deb11u3 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1056918 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: perl
Version: 5.32.1-4+deb11u3

Explanation: prevent buffer overflow via illegal Unicode property 
[CVE-2023-47038]



Bug#1056715: nvidia-graphics-drivers-tesla-470 470.223.02-2~deb11u1 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1056715 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-tesla-470
Version: 470.223.02-2~deb11u1

Explanation: new upstream release [CVE-2023-31022]



Bug#1056105: libsolv 0.7.17-1+deb11u1 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1056105 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libsolv
Version: 0.7.17-1+deb11u1

Explanation: enable zstd compression support



Bug#1056138: nvidia-graphics-drivers 470.223.02-1 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1056138 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 470.223.02-1

Explanation: new upstream release [CVE-2023-31022]



Bug#1056123: conda-package-handling 1.7.2-2+deb11u1 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1056123 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: conda-package-handling
Version: 1.7.2-2+deb11u1

Explanation: skip unreliable tests



Bug#1019096: cifs-utils 6.11-3.1+deb11u2 flagged for acceptance

2023-12-18 Thread Jonathan Wiltshire
package release.debian.org
tags 1019096 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cifs-utils
Version: 6.11-3.1+deb11u2

Explanation: fix non-parallel builds



Bug#1058944: transition: petsc

2023-12-18 Thread Drew Parsons
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pe...@packages.debian.org
Control: affects -1 + src:petsc

I'd like to upgrade PETSc (and SLEPc, and their python packages)
from 3.18 to 3.19.  This is expected to fix the python 3.12 build
error in slepc4py, Bug#1057863. dolfin has now been patched to work
with petsc 3.19.

We can't yet upgrade hypre to 2.29 since it is not compatible with
petsc 3.19:
/projects/petsc/build/petsc/src/ksp/pc/impls/hypre/hypre.c: In function 
‘PCApply_HYPRE’:
/projects/petsc/build/petsc/src/ksp/pc/impls/hypre/hypre.c:446:31: error: 
incompatible types when assigning to type ‘hypre_Error’ from type ‘int’
  446 | hypre__global_error = 0;

hypre upgrades will have to wait for petsc 3.20 next time.


auto-transition:
https://release.debian.org/transitions/html/auto-petsc.html


Ben file:

title = "petsc";
is_affected = .depends ~ "libpetsc-real3.18" | .depends ~ "libpetsc-real3.19";
is_good = .depends ~ "libpetsc-real3.19";
is_bad = .depends ~ "libpetsc-real3.18";


Bug#1058066: RFS ping

2023-12-18 Thread Tobias Frost
On Mon, Dec 18, 2023 at 05:30:46PM +0200, Alexandru Mihail wrote:
> Gently pinging about the current RFS;
> This contains an important fix for a problem which also affects stable
> (#1057842)

Please upload your package to mentors. Thanks.

> Thanks,
> Alexandru Mihail
> mini-httpd maintainer
> 



Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities

2023-12-18 Thread Tobias Frost
Control: tags -1 moreinfo

Hi Phil,

Thanks for planing to adopt nanomsg!

(I've granted you access rights to the salsa repository, you should be
able to commit your changes - a recommendation here is to ask for this
in the RFS, not only as a comment on mentors.d.n)

The package seems to be gone from mentors, so the bot auto-closed this RFS.
However, based on below changelog information, some feedback.

On Sun, Dec 10, 2023 at 10:11:29PM +, Phil Wyett wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "nanomsg":
> 
>  * Package name : nanomsg
>Version  : 1.2+dfsg-1
>Upstream contact : Martin Sústrik 
>  * URL  : https://nanomsg.org/
>  * License  : Expat
>  * Vcs  : https://salsa.debian.org/debian/nanomsg
>Section  : libs
> 
> The source builds the following binary packages:
> 
>   libnanomsg6 - high-performance implementation of scalability libraries
>   libnanomsg-dev - nanomsg development files
>   nanomsg-utils - nanomsg utilities
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/nanomsg/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/n/nanomsg/nanomsg_1.2+dfsg-1.dsc
> 
> Changes since the last upload:
> 
>  nanomsg (1.2+dfsg-1) unstable; urgency=medium
>  .
>* New upstream version 1.2.
>* Soname bump rename package to libnanomsg6.

Please note that there is a mandotory procedure to be followed when
there is a SO-NAME bump. You can find the details here:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions (for example you
need to target experimental first, this was the glue for me that it
seems not to be followed.)

>* New maintainer (Closes: #871443).
>* d/control: Use debhelper-compat 13.
>  - Update paths for missing files.
>* d/control: Use HTTPS homepage URL.
>* d/control: Remove unneeded '${shlibs:Depends}'.
>* d/control: Update 'Standards-Version' to 4.6.2.0 - No Changes required

Cheers, 
--
tobi



  1   2   >