date:20240104

Control: tags -1 + upstream

Closing this bug as too many days & versions have been passed.

There are multiple reports related to l2arc_feed stuck [1][2][3]. But none 
seems the same.
We have to admit that many similar issues exist in zfs. :-(

[1]: https://github.com/openzfs/zfs/issues/13435
[2]: https://github.com/openzfs/zfs/issues/14005
[3]: https://github.com/openzfs/zfs/issues/12679

Thanks,
Shengqi Chen

Bug#1060043: gpac: CVE-2023-46929

Source: gpac
Version: 2.2.1+dfsg1-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/2662
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gpac.

CVE-2023-46929[0]:
| An issue discovered in GPAC 2.3-DEV-rev605-gfc9e29089-master in
| MP4Box in gf_avc_change_vui
| /afltest/gpac/src/media_tools/av_parsers.c:6872:55 allows attackers
| to crash the application.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-46929
https://www.cve.org/CVERecord?id=CVE-2023-46929
[1] https://github.com/gpac/gpac/issues/2662
[2] https://github.com/gpac/gpac/commit/4248def5d24325aeb0e35cacde3d56c9411816a6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1012305: Close bug 1012305

Control: tags -1 + unreproducible

Closing legacy bugs.

Thanks,
Shengqi Chen

Bug#1060042: qemu-efi-aarch64: Saving OVMF configuration changes fail

2024-01-04 Thread Helge Konetzka

Package: qemu-efi-aarch64
Version: 2022.11-6
Severity: normal
X-Debbugs-Cc: d...@zapateado.de

Dear Maintainer,

* What led up to the situation?

In OVMF setup I am trying to change the display resolution to 1024x768.


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

I tested two different cases

A)
cp -r /usr/share/qemu-efi-aarch64 ./
qemu-system-aarch64 -M virt -cpu max -device ramfb -device qemu-xhci -device
usb-kbd \
-bios qemu-efi-aarch64/QEMU_EFI.fd

B)
cp -r /usr/share/AAVMF ./
qemu-system-aarch64 -M virt -cpu max -device ramfb -device qemu-xhci -device
usb-kbd \
-drive file=AAVMF/AAVMF_CODE.fd,format=raw,if=pflash,index=0,read-
only=on \
-drive file=AAVMF/AAVMF_VARS.fd,format=raw,if=pflash,index=1,read-
only=off

After starting in both cases the following steps led to the situation:
* Enter OVMF Setup with ESC
* Navigate Device Manager -> OVMF Platform Configuration
* Change Preferred Resolution to 1024x768
* Save with F10 and Y

The configuration was not saved. The following message was shown:
"Submit Fail For Form: OVMF Settings"

This issue seems to be similar to
https://bugzilla.proxmox.com/show_bug.cgi?id=4606


* What was the outcome of this action?

It was not possible to change the preferred resolution with the installed
firmware.

Changing the preferred resolution with an ovmf firmware from external sources
worked.


* What outcome did you expect instead?

Changing the preferred resolution with qemu-efi-aarch64 firmware works


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

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

-- no debconf information

Bug#1060041: Is the python3-objgraph dependency too much

2024-01-04 Thread Christian Ehrhardt

Package: cherrypy3
Version: 18.9.0-1
X-Debbugs-CC: Jeroen Ploemen 

Hi,
I'm clear that the Ubuntu issues around universe/main dependencies [1]
are not important to Debian, but that kind of checks at least made me
spot the impact of the recently added dependency to python3-objgraph
from cherryp3.

  cherrypy3 (18.9.0-1) unstable; urgency=medium
...
* Control: add recommended dep on python3-objgraph, optional
import in
  cherrypy/lib/gctools.py.

I only can see it used for testing (and in that context it is
correctly pulled in by d/t/control already).
AFAICS upstream itself only depends on it for tests [2] and for
further comparison also in fedora [3] there is no such dependency.

It pulls quite much as it is not only python3-objgraph but then
through further recommends even all of graphviz and xdot - and then in
turn even more like gtk.
That pulled in every place that cherryp3 is used seems too much
especially for a seemingly mostly test-only dependency.

I compared the behavior on bullseye, bookworm and trixie containers if
this is really as much as it feels. Even bullseye to bookworm grew a
bit, but not that much.

# bullseye
root@d11:~# apt install python3-cherrypy3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  ca-certificates javascript-common libjs-jquery libjs-sphinxdoc
libjs-underscore libmpdec3 libpython3-stdlib libpython3.9-minimal
libpython3.9-stdlib libreadline8 libsqlite3-0 media-types openssl
python3
  python3-cffi-backend python3-cryptography python3-minimal
python3-openssl python3-pkg-resources python3-repoze.lru
python3-routes python3-simplejson python3-six python3-webob python3.9
python3.9-minimal
  readline-common
Suggested packages:
  apache2 | lighttpd | httpd python3-doc python3-tk python3-venv
python-cryptography-doc python3-cryptography-vectors
python-openssl-doc python3-openssl-dbg python3-setuptools
python3-paste python-webob-doc
  python3.9-venv python3.9-doc binutils binfmt-support readline-doc
The following NEW packages will be installed:
  ca-certificates javascript-common libjs-jquery libjs-sphinxdoc
libjs-underscore libmpdec3 libpython3-stdlib libpython3.9-minimal
libpython3.9-stdlib libreadline8 libsqlite3-0 media-types openssl
python3
  python3-cffi-backend python3-cherrypy3 python3-cryptography
python3-minimal python3-openssl python3-pkg-resources
python3-repoze.lru python3-routes python3-simplejson python3-six
python3-webob python3.9
  python3.9-minimal readline-common
0 upgraded, 28 newly installed, 0 to remove and 0 not upgraded.
Need to get 8800 kB of archives.
After this operation, 30.7 MB of additional disk space will be used.

# bookworm
root@d12:~# apt install python3-cherrypy3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  ca-certificates javascript-common libjs-jquery libjs-sphinxdoc
libjs-underscore libnsl2 libpython3-stdlib libpython3.11-minimal
libpython3.11-stdlib libreadline8 libsqlite3-0 media-types openssl
python3
  python3-autocommand python3-cffi-backend python3-cheroot
python3-cryptography python3-inflect python3-jaraco.classes
python3-jaraco.collections python3-jaraco.context
python3-jaraco.functools
  python3-jaraco.text python3-minimal python3-more-itertools
python3-openssl python3-pkg-resources python3-portend
python3-repoze.lru python3-routes python3-simplejson python3-six
python3-tempora python3-tz
  python3-webob python3-zc.lockfile python3.11 python3.11-minimal
readline-common
Suggested packages:
  apache2 | lighttpd | httpd python3-doc python3-tk python3-venv
python-cryptography-doc python3-cryptography-vectors
python-openssl-doc python3-openssl-dbg python3-setuptools
python3-paste python-webob-doc
  python3.11-venv python3.11-doc binutils binfmt-support readline-doc
The following NEW packages will be installed:
  ca-certificates javascript-common libjs-jquery libjs-sphinxdoc
libjs-underscore libnsl2 libpython3-stdlib libpython3.11-minimal
libpython3.11-stdlib libreadline8 libsqlite3-0 media-types openssl
python3
  python3-autocommand python3-cffi-backend python3-cheroot
python3-cherrypy3 python3-cryptography python3-inflect
python3-jaraco.classes python3-jaraco.collections
python3-jaraco.context python3-jaraco.functools
  python3-jaraco.text python3-minimal python3-more-itertools
python3-openssl python3-pkg-resources python3-portend
python3-repoze.lru python3-routes python3-simplejson python3-six
python3-tempora python3-tz
  python3-webob python3-zc.lockfile python3.11 python3.11-minimal
readline-common
0 upgraded, 41 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.5 MB of archives.
After this operation, 36.8 MB of additional disk space will be used.

# trixie / sid
root@d13:~# apt install python3-cherrypy3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The

Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

2024-01-04 Thread Julian Gilbey

On Thu, Jan 04, 2024 at 08:28:53PM +, Julian Gilbey wrote:
> Hi all,
> 
> A quick update
> [...]
> 
> Updates:
> [...]
> 
> (2) It appears that all of the autopkgtests triggered by
> python3-werkzeug 2.3.8 have passed (though most are no longer showing
> on tracker.d.o).  The only package that is failing is flask-dance.  As
> you (Carsten) mentioned earlier, "the upstream package isn't really
> ready for the newer versions", so I suggest that we file an RC bug
> against it.  Perhaps we can ask the appropriate team (release team?)
> to drop it from testing for now so that python3-werkzeug can migrate.
> It has no reverse dependencies.

And upstream fixed it with version 7.0.1 within hours of it being
reported!  I've just uploaded that to unstable, so python3-werkzeug
will hopefully migrate in a couple of days' time.

Best wishes,

   Julian

Bug#1041857: Update bug 1041857

Control: tag -1 + upstream
Control: forwarded -1 https://github.com/openzfs/zfs/issues/11587

Thanks
Shengqi Chen

Bug#1051187: [Pkg-zfsonlinux-devel] Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed

Control: severity -1 wishlist
Control: tag -1 + wontfix

> zfs-dkms is the failsafe in case the zfs-modules- package is 
> *not* installed
> (for example, because this is the first slow box I'm installing this kernel 
> or this version of
> zfs-dkms on and I don't yet have a corresponding zfs-modules package).

Let's imagine you install modules pkg first, then dkms pkg, which skips 
building because you have
"same" modules installed. After some days you accidentally uninstalled the 
modules pkg, then how
would the dkms pkg know and start the building? There is no such mechanism 
according to my knowledge.

Even though such mechanism can be implemented by dkms, let's dig deeper into 
details: how would dkms
know that your prebuilt version and dkms source files are "the exact same" and 
decide to skip? Designing
such a mechanism would be either cumbersome for developers, or confusing for 
users, I suppose.

Thanks,
Shengqi Chen

Bug#991373: Close bug 991373

Control: notfound -1 2.0.3-1~bpo10+1
Control: tag -1 + unreproducible

Thanks,
Shengqi Chen

Bug#1014197: Close bug 1014197

Control: notfound -1 2.1.5-1

Feel free to re-open if there are still problems.

Thanks,
Shengqi Chen

Bug#1060040: ITP: golang-github-antonini-golibjpegturbo -- libjpeg-turbo cgo bindings for Go (library)

2024-01-04 Thread Maytham Alsudany

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
Control: block 1059994 by -1

* Package name: golang-github-antonini-golibjpegturbo
  Version : 0.0~git20141208.c03a2fa
  Upstream Contact: 
* URL : https://github.com/antonini/golibjpegturbo
* License : Expat
  Programming Lang: Go
  Description : libjpeg-turbo cgo bindings for Go (library)

 This library is the fastest possible way to decode and encode JPEG images in
 Go. This is achieved via cgo bindings to libjpeg-turbo library.
 .
 Compared to the image/jpeg standard library, this library is 6x faster when
 decoding and 1.7x fatser when encoding at 90% quality level.

Dependency of cam2ip.

Will be maintained within the Go team, and will need a sponsor.

--
Kind regards,
Maytham Alsudany


signature.asc
Description: application/pgp-keys

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

2024-01-04 Thread Johannes Schauer Marin Rodrigues

Hi,

On Thu, 4 Jan 2024 21:04:57 +0100 Paul Gevers  wrote:
> [20:21:54]  agreed, but britney2 doesn't handle :any on virtual 
> packages in any way (neither binary dep nor build dep)
> [20:22:10]  (and I'm not sure whether that's legal in any way)
> [20:23:08]  agreed
> [20:23:28]  which I'm fixing right now
> [20:23:39]  apparently there's builds with :native
> [20:23:43]  so I'll support that
> [20:24:04]  but I wanted to know what happens with :any (and 
> virtual B-D)
> [20:25:07]  well, this is not something that existed in the 
> archive before gobject-introspection, so we're about to extend what is 
> defined
> [20:25:15]  according to smcv this is legal to dpkg and apt
> [20:25:35]  but we know that resolvers 
> (dpkg/apt/dose/britney2/...) disagree on corner cases
> [20:25:50]  and I'm guilty of having written yet another 
> resolver in dumat
> [20:26:26]  britney2 just has to follow what dpkg and apt happen 
> to agree on
> [20:26:45]  or maybe even, what apt says
> [20:27:01]  if that works

back in 2015 I wrote a small tool which is able to create artificial dependency
situations involving two real packages and (optionally) a third virtual
packages to make sure that the multi-arch implementations of apt, dpkg and
dose3 agree with each other in all cases (spoiler: they do not).

https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check/

The tool is meant to make mass comparisons (it generates 8624 test cases) and
thus its interface is a bit clunky but if what you want to do is to see whether
apt, dose3 and dpkg agree on a situation where one package depends on a virtual
package with :any which is provided by a real m-a: allowed package, then you
would write this:

./check.sh binary pkgc amd64 amd64 no allowed depends pkgc:any

It would generate the following two stubs (shortened here for brevity):

Package: pkga
Version: 1
Architecture: amd64
Depends: pkgc:any
Multi-Arch: no

Package: pkgb
Version: 1
Architecture: amd64
Provides: pkgc
Multi-Arch: allowed

And yes, all three tools agree on this situation: it is satisfiable. If you
make pkgb m-a:no, then all tools agree that the situation is unsatisfiable.

We can do the same checks for pkga being a source package:

./check.sh source pkgc none amd64 none allowed depends pkgc:any

Again, all three tools agree that this situation is satisfiable.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1023127: Update bug 1023127

Control: tag -1 + wontfix

The package is intended for normal users, for whom installing both dracut
and initramfs-tools seems really rare and weird. Also your patch will even 
render
the system not usable because now initramfs no more updates when zfs upgrades.

> Conversely, imagining (and being in) such a situation is very easy to me.
> This is the reason why they are made co-installable, and only the "bare"
> dracut/initramfs-tools packages aren't.

It is possible to further split packages into, e.g., zfs-{initramfs,dracut}-core
that depends on their corresponding underlying -core packages, and make
zfs-{initramfs,dracut} depend on them. However I haven't heard similar
use cases from any other users.

Thanks,
Shengqi Chen

Bug#983782: Update bug 983782

Control: forwarded -1 https://github.com/openzfs/zfs/issues/11587
Control: tags -1 + upstream

Seems it is caused by the same race condition.

Thanks,
Shengqi Chen

Bug#1039607: libjansi-java: causes maven to always output escape character

2024-01-04 Thread tony mancill

On Sun, Dec 31, 2023 at 03:27:53PM -0800, tony mancill wrote:
> On Fri, Dec 29, 2023 at 07:23:35AM -0800, tony mancill wrote:
> > On Fri, Dec 29, 2023 at 12:27:07PM +0100, Emmanuel Bourg wrote:
> > > On 28/12/2023 00:48, tony mancill wrote:
> > > 
> > > > - Maven output is colorized by default when invoked during Debian
> > > >package builds that depend on maven-debian-helper.
> > > 
> > > Good
> > > 
> > > > - Direct `mvn` Maven output is not colorized by default.
> > > 
> > > That's an issue, mvn output should be colorized on a terminal by default,
> > > that's the upstream behaviour.
> 
> My intuition is that it will be better to update the Debian jansi
> package to create the necessary arch-any packages so our version more
> closely resembles upstream, and we are better positioned if/when jansi
> merges into jline, as mentioned here [4].

After giving this some more thought, I don't think we want a jansi
source package that builds arch-any packages.  jansi (already) has a
circular build dependency on itself via maven, but there's no
bootstrapping problem because the packages are currently arch-all.

Since the native library is desired but optional, we could create a
separate source package and add a Recommends dependency to
libjansi-java.  It may even be possible leverage the existing
jansi-native, but I haven't looked into the question of compatibility
yet. 

However, for the short-term, I believe we can achieve the desired
behavior and fix the issue for most use cases by

1. Patching the mvn wrapper script in our maven package to set
jansi.mode=force (and thus colorize output) unless the --batch-mode
option is provided.

2. Moving forward with the current jansi package in experimental.

That restores the desired --batch-mode behavior but maintains
colorized output by default and during Debian package builds.

Would that be acceptable?

Bug#1059163: cpio: Path traversal vulnerability

Control: retitle -1 cpio: CVE-2023-7207: Path traversal vulnerability due to 
partial revert of fix for CVE-2015-1197

On Thu, Jan 04, 2024 at 08:01:18PM -0600, Mark Esler wrote:
> Please refer to this path traversal vulnerability as CVE-2023-7207.
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-7207

Thanks Mark. Added it as such to our tracker.

Anibal, the dates are not fixed yet, but the point releases are
exepcted around beginning of february. 

Regards,
Salvatore

Bug#1025046: Update bug 1025046

Control: fixed -1 2.1.7-1

You may also refer to #900656.

Thanks,
Shengqi Chen

Bug#900656: Update bug 900656

Hi,

> How about depending the dkms on kernel versions known to work with it?

We can add dependency on linux-libc-dev (which always has the same version as 
kernel).
This prevents:

1. kernel upgrade to versions that zfs does not **explicitly** say it supports 
in META,
  even it **might** actually build and work.
2. any user-compiled kernels. Users can create a fake package if needed.

> Furthermore, zfs-dkms should require on the same version of spl-dkms to 
ensure interoperability (rather than specifying a range).

Now spl has been merged into zfs-dkms. This is not a problem any more.

Thanks,
Shengqi Chen

Bug#370397: gs-common: Any chance of ps2pdf16?

On Sun, 04 Jun 2006 18:54:06 -0500 Ron Johnson  wrote:

> The PDF v1.6 spec has been out for 2 years, but ps2pdf is still "stuck"
> at v1.4.
> 
> Is this because there is nothing more to gain in the v1.5 & v1.6 specs
> in a blind ps-to-pdf converter?

I don't know the answer to that question.  I just wanted to provide one 
breadcrumb into the upstream bug tracker.  It's an unrelated issue, but one 
comment reads:

Ken Sharp 2017-03-20 08:14:30 UTC
(In reply to Ulrich Windl from comment #42)

> Wouldn't the user benefit from some warning being emitted?

My inclination is to scrap the script(s), frankly. They've always been a pain.

> From the man page (ps2pdf):

We don't produce or maintain man pages for Ghostscript.

https://bugs.ghostscript.com/show_bug.cgi?id=695847#c43

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

Bug#1059904: mariadb autopkgtest "upstream" is flaky, time sink

## arm64

All green at https://ci.debian.net/packages/m/mariadb/testing/arm64/
Latest log has "Completed: All 1049 tests were successful."

## i386

Likewise, all green at https://ci.debian.net/packages/m/mariadb/testing/i386/
Latest log has "Completed: All 1047 tests were successful.".

## armel

Flaky at https://ci.debian.net/packages/m/mariadb/testing/armel/
Last passing a couple days ago: Completed: All 1047 tests were successful.
All failing ones on main.subselect* for which I have a bugfix.

## armhf

Flaky at https://ci.debian.net/packages/m/mariadb/testing/armhf/
Latest passed: Completed: All 1046 tests were successful.
Likewise to armel, failures on main.subselect*

## s390x

Flaky at https://ci.debian.net/packages/m/mariadb/testing/s390x/
Last passed a couple days ago: All 1047 tests were successful.
Likewise to armel, failures on main.subselect*

## amd64

Finally, amd64 flaky at https://ci.debian.net/packages/m/mariadb/testing/amd64/
Last passed a couple days ago: Completed: All 1049 tests were successful.

All failures on subselect as well, which is an upstream regression in
10.11.6: https://jira.mariadb.org/browse/MDEV-32843
Fix is pending on
https://salsa.debian.org/otto/mariadb-server/-/commits/dev-otto but
still need to finalize a bit before upload.


Summary: the number of tests is not flaky on passed runs. The number
of attempted test runs is fluctuating only when failures happend and
tests re-run.

Bug#1059904: mariadb autopkgtest "upstream" is flaky, time sink

Summary of current status of https://ci.debian.net/packages/m/mariadb/

## ppc64el

Last passed in 
https://ci.debian.net/packages/m/mariadb/testing/ppc64el/40870773/
where 1048 tests were successful:
MariaDB: 1:10.6.11-1
kernel: Linux 6.5.0-0.deb12.4-powerpc64le

The log above includes 4 variants of main.innodb_ext_key passing.


Later we see:

Completed: Failed 8/1053 tests, 99.24% were successful.
Failing test(s): main.innodb_ext_key main.stat_tables_innodb
main.xa_prepared_binlog_off

Completed: Failed 11/1055 tests, 98.96% were successful.
Failing test(s): main.innodb_ext_key main.subselect_sj2_jcl6

Completed: Failed 3/1050 tests, 99.71% were successful.
Failing test(s): main.innodb_ext_key

Completed: Failed 2/1049 tests, 99.81% were successful.
Failing test(s): main.innodb_ext_key

Completed: Failed 3/1050 tests, 99.71% were successful.
Failing test(s): main.xa_prepared_binlog_off

Completed: Failed 10/1054 tests, 99.05% were successful.
Failing test(s): main.innodb_ext_key main.subselect

MariaDB: 1:10.6.11-1
kernel: Linux 6.5.0-0.deb12.4-powerpc64le

In https://ci.debian.net/packages/m/mariadb/testing/ppc64el/40894691/ we see:

Completed: All 1048 tests were successful.
Errors/warnings were found in logfiles during server shutdown after running the
following sequence(s) of tests:
main.long_unique_bugs
183 tests were skipped, 76 by the test itself.

The test emitted a MariaDB crash:

main.long_unique_bugs 'innodb' w1 [ pass ] 324
14:51:15 [ERROR] mysqld got signal 11 ;
Attempting backtrace. You can use the following information to find out

Since 2023-12-18 16:13:06 UTC the test has failed to even start.


The ppc64el logs have crashes and most likely due to
https://jira.mariadb.org/browse/MDEV-30728, in particular the
main.innodb_ext_key one.

Bug#1060039: lirc: atilibusb driver no longer present

2024-01-04 Thread Michael Gold

Package: lirc
Version: 0.10.2-0.2

Dear Maintainer,

My remote control wasn't working today, and I saw this error in my logs:
lircd[117053]: Driver `atilibusb' not found or not loadable (wrong or missing 
-U/--plugindir?).

I suspect this may be related to bug #810445; however, the package still
ships /usr/share/lirc/configs/atilibusb.conf, and the source package has
the driver code, so I'm not sure why the binary is missing.  I don't see
anything in the changelog about it.

- Michael


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

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

Versions of packages lirc depends on:
ii  libasound2   1.2.10-3
ii  libc62.37-13
ii  libftdi1-2   1.5-6+b3
ii  libgcc-s113.2.0-9
ii  liblirc-client0  0.10.2-0.2
ii  liblirc0 0.10.2-0.2
ii  libportaudio219.6.0-1.2
ii  libstdc++6   13.2.0-9
ii  libsystemd0  255.2-3
ii  libusb-1.0-0 2:1.0.26-1
ii  python3  3.11.6-1

Versions of packages lirc recommends:
pn  gir1.2-vte-2.91  
ii  python3-gi   3.46.0-3
pn  python3-yaml 
ii  systemd  255.2-3

Versions of packages lirc suggests:
pn  ir-keytable  
pn  lirc-compat-remotes  
ii  lirc-doc 0.10.2-0.2
pn  lirc-drv-irman   
pn  lirc-x   
pn  setserial


signature.asc
Description: PGP signature

Bug#1054086: lsm: let dh_installsystemd choose the location of units

2024-01-04 Thread Lucas Castro




Em 08/12/2023 18:09, Chris Hofstaedtler escreveu:

Hi Lucas,


Em 16 de outubro de 2023 15:11:55 BRT, Helmut Grohne  
escreveu:

Source: lsm

[..]

still is in effect there. debdiff cannot represent this patch:

rm debian/lsm.install
ln -s ../lsm.service debian/lsm.service

* Lucas Castro :

Sorry about delay for "fixing" that.

ASAP I'll work on that.

Are there any blockers I might be able to help you with, to move
this forward?


I was little busy working on myself workflow. In two week it'll be "fix it".

I just need to discuss about changing the package name.



Thanks,
Chris

Bug#829444: Use DEP14 branch layout by default

Hi and Happy New Year!

Using 'debian/latest' instead of 'master' by default in
git-buildpackage would still make sense.

I started drafting a PR at
https://github.com/agx/git-buildpackage/pull/93 to implement this, but
it takes a while to read through and understand all the 500+ mentions
of string 'master' and which of these refer to default Debian branch
and which not.

I have been using the debian/latest convention from DEP-14[1] in all
my packages for several years now. This is the scheme I follow based
on what I find most practical:

- debian/latest
- debian/12-bookworm
- debian/11-bullseye
- debian/11-bullseye-backports
- debian/10-buster
- ubuntu/23.10-mantis
- ubuntu/22.04-focal

Having the release number in addition to to code name makes it easier
for contributors to choose the correct branch for Merge Requests, and
also ensures they are nicely sorted in chronological order in branch
listings.

The upstream branch name is whatever upstream uses (typically master,
main or a version branch or tag, e.g. 10.11 or 5.5).

For reference these are the gbp.conf changes I use for maintenance branches:

± git diff debian/latest..ubuntu/23.10-mantic debian/gbp.conf
diff --git a/debian/gbp.conf b/debian/gbp.conf
index c82f832717a..bfdfe73742c 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -8,7 +8,9 @@ sign-tags = True
 upstream-signatures = on

 # DEP-14 format
-debian-branch = debian/latest
+debian-branch = ubuntu/23.10-mantic
+debian-tag = ubuntu/%(version)s
+debian-tag-msg = %(pkg)s Ubuntu release %(version)s
 upstream-branch = 10.11
 upstream-tag = mariadb-%(version)s

The proposal by Raphaël to support %(vendor) would help automate the
debian-tag and debian-tag-msg so they don't need to be customized per
branch.


[1] https://dep-team.pages.debian.net/deps/dep14/

Bug#1060007: [debian-mysql] Bug#1060007: mariadb: FTBFS on riscv64: tries to uses rdcycle, privileged since kernel 6.6

Hi!

I have been running riscv64 builds and test suite at
https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all
for several months and all known riscv64 issues have been fixed. This
is a new one - I will take a look and probably apply the patch from
upstream 
(https://patch-diff.githubusercontent.com/raw/MariaDB/server/pull/2980.patch,
authored by you - thanks!).

Bug#1060038: RFS: gtklock-userinfo-module/2.1.0-1 [ITP] -- user info module for gtklock

2024-01-04 Thread Maytham Alsudany

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net

Dear mentors,

I am looking for a sponsor for my package "gtklock-userinfo-module":

 * Package name : gtklock-userinfo-module
   Version  : 2.1.0-1
   Upstream contact : 
https://github.com/jovanlanik/gtklock-userinfo-module/issues
 * URL  : https://github.com/jovanlanik/gtklock-userinfo-module
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/Maytha8/gtklock-userinfo-module
   Section  : misc

The source builds the following binary packages:

  gtklock-userinfo-module - user info module for gtklock

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

  https://mentors.debian.net/package/gtklock-userinfo-module/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gtklock-userinfo-module/gtklock-userinfo-module_2.1.0-1.dsc

Changes for the initial release:

 gtklock-userinfo-module (2.1.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1059901)

Kind regards,
Maytham


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

Bug#1060037: RFS: gtklock-playerctl-module/2.0.1-1 [ITP] -- player control module for gtklock

2024-01-04 Thread Maytham Alsudany

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net

Dear mentors,

I am looking for a sponsor for my package "gtklock-playerctl-module":

 * Package name : gtklock-playerctl-module
   Version  : 2.0.1-1
   Upstream contact : 
https://github.com/jovanlanik/gtklock-playerctl-module/issues
 * URL  : https://github.com/jovanlanik/gtklock-playerctl-module
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/Maytha8/gtklock-playerctl-module
   Section  : misc

The source builds the following binary packages:

  gtklock-playerctl-module - player control module for gtklock

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

  https://mentors.debian.net/package/gtklock-playerctl-module/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gtklock-playerctl-module/gtklock-playerctl-module_2.0.1-1.dsc

Changes for the initial release:

 gtklock-playerctl-module (2.0.1-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1059902)

Kind regards,
Maytham



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

Bug#1059837: opencolorio： Please help fix circle dependence in Loongarch between openimageio and opencolorio

2024-01-04 Thread Guillem Jover

Hi!

On Fri, 2024-01-05 at 11:37:30 +0800, xiao sheng wen wrote:
> 在 2024/1/5 11:09, Guillem Jover 写道:
> > > So, my question is:
> > > 
> > > Can dpkg-checkbuilddeps  read
> > > 
> > > ||BuildProfileSpec "Registered profile names"pkg.$sourcepackage.$anything 
> > > in debian/control |Build-Depends section?|
> > > 
> > > Perhaps, it's a bug of dpkg-checkbuilddeps.
> > It can obviously parse the build profile, otherwise it would not have
> > succeeded when you passed the build profile to it. So, I don't understand
> > why this was cloned against dpkg-dev. So I'm closing this now.

> If build profile already exist in env variable like DEB_BUILD_PROFILES,
> 
> dpkg-checkbuilddeps can parse the build profile succeeded, that is right.
> 
> But if there is nobuild profile env variable exist before, can
> dpkg-checkbuilddeps  parse the debian/control Build-Depends section to
> getDEB_BUILD_PROFILES env variable? At present, Is dpkg-checkbuilddeps
> parse pkg.$sourcepackage.$anything in debian/control ?

I think there's some confusion on how build profiles work, I'd
recommend rereading the wiki pages, if there's something not clear
I guess the debian-cross list could clarify further. In any case
here follows a simplified view of how this works.

We mark dependencies (bust mostly build-dependencies) with specific
build-profiles. These dependencies will be in effect if the restriction
formula evaluates to true, which depends on whether specific build
profiles are active, and how the formula looks like. By default there
are no active build profile.

There's no such thing as a literal «pkg.$sourcepackage.$anything» being
parsed, the dpkg code simply parses the dependencies and the formulas,
matches the build profiles found in the formulas against active
profiles, that are specified via the environment or options such as -P,
and evaluates those formulas based on that.

> If dpkg-checkbuilddeps parse it, dpkg-checkbuilddeps  will pass, then the
> buildd will begin build these packages.

dpkg-checkbuilddeps always parses the formulas, they just evaluate
differently depending on whether the profiles are active or not. Which
means, if you want to make the specific profiles active you need to
tell the buildd to build that specific package like so, or build it
locally (just to bootstrap it), upload then retrigger a rebuild to
get a clean build.

Regards,
Guillem

Bug#1060036: ITP: python-czt -- Generalization of the discrete Fourier transform (DFT)

2024-01-04 Thread Yogeswaran Umasankar

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-czt
  Version : 0.0.7
  Upstream Contact: John Garrett 
* URL : https://github.com/garrettj403/CZT
* License : Expat
  Programming Lang: Python
  Description : Generalization of the discrete Fourier transform (DFT)

Chirp Z-transform (CZT) is a generalization of the discrete Fourier
transform (DFT). While the DFT samples the Z plane at uniformly-spaced
points along the unit circle, the chirp Z-transform samples along spiral
arcs in the Z-plane, corresponding to straight lines in the S plane. The
DFT, real DFT, and zoom DFT can be calculated as special cases of the
CZT. Useful for signal processing.

Bug#564546: ghostscript: inferior image scaling

tags 564546 + moreinfo
thanks

Hello,

Apologies for the massive delay in responding!

On Sat, 09 Jan 2010 23:45:30 -0500 John Lindgren  
wrote:
> Package: ghostscript
> Version: 8.70~dfsg-2
> Severity: wishlist

It's now 13 years on, so I have to first ask whether this issue still remains?

> A PDF file consisting of a 300 DPI page-size image, generated by
> printing from Open Office Draw to the CUPS PDF converter, is poorly
> rendered by both Evince and the GIMP, so I'm making a guess that the
> problem lies in Ghostscript.  It seems to be downsampling images by
> skipping pixels rather than averaging them.  I've attached snippets of
> the image (a) at its original 300 DPI, (b) scaled poorly to 100 DPI by
> Ghostscript, and (c) scaled well to 100 DPI by the GIMP.

If the issue does remain, can you provide a pdf file and command line that 
demonstrates the problem?

Thanks,
-Steve

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

Bug#379901: gs-gpl: `ps2pdf' fails to embed URW++ fonts from `gsfonts'

On Mon, 7 Feb 2011 13:09:45 -0600 Jonathan Nieder  wrote:
> reopen 379901
> submitter 379901 !
> severity 379901 normal
> tags 379901 = upstream moreinfo
> done
> 
> Ludovic Courtès wrote:
> 
> > This is a 5-year old bug report, I changed email addresses in the
> > meantime (congrats for finding a new one), and I even changed distros.
> > :-)
> 
> Thanks for an update.  I'll take the bug. :)

Can you attach an example file for this issue please?

Thanks,
-Steve



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

Bug#1059837: opencolorio： Please help fix circle dependence in Loongarch between openimageio and opencolorio

Hi,

Thanks for your quick reply!

在 2024/1/5 11:09, Guillem Jover 写道:

So, my question is:

Can dpkg-checkbuilddeps read

||BuildProfileSpec "Registered profile names"pkg.$sourcepackage.$anything in
debian/control |Build-Depends section?|

Perhaps, it's a bug of dpkg-checkbuilddeps.

It can obviously parse the build profile, otherwise it would not have
succeeded when you passed the build profile to it. So, I don't understand
why this was cloned against dpkg-dev. So I'm closing this now.

If build profile already exist in env variable like DEB_BUILD_PROFILES,

dpkg-checkbuilddeps can parse the build profile succeeded, that is right.

But if there is nobuild profile env variable exist before, can
dpkg-checkbuilddeps parse the debian/control Build-Depends section to
getDEB_BUILD_PROFILES env variable? At present, Is dpkg-checkbuilddeps parse
pkg.$sourcepackage.$anything in debian/control ?

If dpkg-checkbuilddeps parse it, dpkg-checkbuilddeps will pass, then the
buildd will begin build these packages.

The report against opencolorio should be closed too IMO, and the
loong64 porters need to deal with the circular dependency as any other
bootstrapping scenario.

Regards,
Guillem

Regards,

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa:https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB

OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060035: prison-kf5: update debian/libkf5prison5.symbols for loong64

2024-01-04 Thread Zhang Na

Source: prison-kf5
Version: 5.107.0-2
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please update debian/libkf5prison5.symbols for loong64, 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 f14c6fa0c27d50ac29696ec75717d81ecae0f7b7 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Fri, 5 Jan 2024 03:16:47 +
Subject: [PATCH] update debian/libkf5prison5.symbols for loong64

---
 debian/libkf5prison5.symbols | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libkf5prison5.symbols b/debian/libkf5prison5.symbols
index ac6aae6..187cf42 100644
--- a/debian/libkf5prison5.symbols
+++ b/debian/libkf5prison5.symbols
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 5.85.0 alpha amd64 arm64 armel armhf hurd-i386 i386 
ia64 m68k mips64el ppc64el riscv64 sh4 x32
+# SymbolsHelper-Confirmed: 5.85.0 alpha amd64 arm64 armel armhf hurd-i386 i386 
ia64 loong64 m68k mips64el ppc64el riscv64 sh4 x32
 libKF5Prison.so.5 libkf5prison5 #MINVER#
 * Build-Depends-Package: libkf5prison-dev
  _ZN6Prison13createBarcodeENS_11BarcodeTypeE@Base 5.25.0~
-- 
2.43.0

Bug#1057490: Additional information

2024-01-04 Thread Vladimir Petko

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this
issue?

 The crash is caused by ijar encountering an unnamed method parameter entry:
#0  0x5638318f5311 in devtools_ijar::Constant::slot() ()
#1  0x5638318f99b1 in
devtools_ijar::MethodParametersAttribute::Write(unsigned char*&) ()
#2  0x5638318fb021 in devtools_ijar::HasAttrs::WriteAttrs(unsigned
char*&) ()
#3  0x5638318fa160 in devtools_ijar::Member::Write(unsigned char*&) ()
#4  0x5638318fa614 in devtools_ijar::ClassFile::WriteBody(unsigned
char*&) ()
#5  0x5638318fcb09 in devtools_ijar::ClassFile::WriteClass(unsigned
char*&) ()
#6  0x5638318fcc9d in devtools_ijar::StripClass(unsigned char*&,
unsigned char const*, unsigned long) ()
#7  0x56383190e192 in devtools_ijar::JarStripperProcessor::Process(char
const*, unsigned int, unsigned char const*, unsigned long) ()
#8  0x5638319112dd in devtools_ijar::InputZipFile::ProcessFile(bool) ()
#9  0x563831910f39 in
devtools_ijar::InputZipFile::ProcessLocalFileEntry(unsigned long, unsigned
long) ()
#10 0x563831910bbb in devtools_ijar::InputZipFile::ProcessNext() ()
#11 0x563831911c52 in devtools_ijar::ZipExtractor::ProcessAll() ()
#12 0x56383190ef22 in devtools_ijar::OpenFilesAndProcessJar(char
const*, char const*, bool, char const*, char const*) ()
#13 0x56383190f5e1 in main ()

This was already fixed upstream[2], I have cherry-picked the commit and
validated that the package builds successfully both in default Java 21 and
normal sid chroot.

Best Regards,
 Vladimir.

[1] https://salsa.debian.org/bazel-team/bazel-bootstrap/-/merge_requests/2
[2]
https://github.com/bazelbuild/bazel/commit/3954a18fa6b0e3d1a1005cc3409ebc95f6adf3af

Bug#1059837: opencolorio： Please help fix circle dependence in Loongarch between openimageio and opencolorio

2024-01-04 Thread Guillem Jover

Hi!

On Fri, 2024-01-05 at 09:27:29 +0800, xiao sheng wen wrote:
>     IMHO, it's not a bug of opencolorio, even is not a bug of Loongarch.

Well, the circular dependency is problematic for bootstrapping,
ideally opencolorio and openimageio would not depend on each other,
but that can be handled by the build profiles already present, which
is something the porters need to do. This is not something for the
maintainers to do.

> In opencolorio debian/control, |Build-Depends|[1] already used:
> 
> |libopenimageio-dev (>= 2.3.9.0) ,|
> 
> 
> | is a |BuildProfileSpec "Registered profile 
> names"pkg.$sourcepackage.$anything[2]
> 
> After I installed other |Build-Depends packages of |opencolorio, then run:
> 
> dpkg-checkbuilddeps
> dpkg-checkbuilddeps: error: Unmet build dependencies: libopenimageio-dev (>=
> 2.3.9.0)
> 
> But after I export DEB_BUILD_PROFILES, dpkg-checkbuilddeps run success:
> 
> export
> DEB_BUILD_PROFILES="pkg.opencolorio.noopenimageio";dpkg-checkbuilddeps
> atzlinux@nlx:~/opencolorio$ echo $?
> 0
> 
> So, my question is:
> 
> Can dpkg-checkbuilddeps  read
> 
> ||BuildProfileSpec "Registered profile names"pkg.$sourcepackage.$anything in 
> debian/control |Build-Depends section?|
> 
> Perhaps, it's a bug of dpkg-checkbuilddeps.

It can obviously parse the build profile, otherwise it would not have
succeeded when you passed the build profile to it. So, I don't understand
why this was cloned against dpkg-dev. So I'm closing this now.

The report against opencolorio should be closed too IMO, and the
loong64 porters need to deal with the circular dependency as any other
bootstrapping scenario.

Regards,
Guillem

Bug#469761: epstool: crashes

On Tue, 16 Sep 2014 01:06:55 +0200 Philip Rinn  wrote:
> reassign 469761 ghostscript
> retitle 469761 file crashes ps2pdf/epstool/ghostscript
> 
> thanks
> 
> Hi,
> 
> I think it's actually a bug in ghostscript as ps2pdf throws the same error 
as epstool.

Tested with ghostscript 10.02.1 and the issue remains:

$ ps2pdf tmp.eps 
Error: /typecheck in --aload--
Operand stack:   --nostringval--
Execution stack:   %interp_exit   .runexec2   --nostringval--   --
nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --
nostringval--   --nostringval--   false   1   %stopped_push   1944   1   3   
%oparray_pop   1943   1   3   %oparray_pop   1942   1   3   %oparray_pop   --
nostringval--   1928   1   3   %oparray_pop   1801   1   3   %oparray_pop   --
nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--  
 
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:   --dict:748/1123(ro)(G)--   --dict:0/20(G)--   --dict:
111/200(L)--
Current allocation mode is local
Current file position is 291380
GPL Ghostscript 10.02.1: Unrecoverable error, exit code 1



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

Bug#1059890: [Pkg-electronics-devel] Bug#1059890: lepton-eda: weird short description: "metapackage" ?

2024-01-04 Thread Bdale Garbee

tags 1059890 +pending
thanks

Alexandre Detiste  writes:

> This does not looks like a metapackage.
> Maybe this is an holdover from ancient times.

That's entirely possible.  Thanks for the report, I've removed the
errant word from the short description in git, will be fixed in the next
upload.

Bdale
>
> Greetings,
>
> Alexandre
>
> ___
> Pkg-electronics-devel mailing list
> pkg-electronics-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-electronics-devel

signature.asc
Description: PGP signature

Bug#1060034: ITP: python-openai -- OpenAI Python API library

2024-01-04 Thread Mo Zhou


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

* Package name    : python-openai
  Version : 1.6.1
* URL : https://github.com/openai/openai-python
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenAI Python API library

Dependency of DebGPT. Will be maintained by deep learning team.
It will go to the contrib section based on policy section 2.2.2,
because this API client requires either
(1) paied access to the proprietary backend
(2) compatible open-source backend implementations are not yet
    available in the archive.

Thank you for using reportbug

Bug#1059837: there is no patch for this bug now


Control: -1 tags - patch


There is no patch for this bug now.

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059163: cpio: Path traversal vulnerability

2024-01-04 Thread Mark Esler


Please refer to this path traversal vulnerability as CVE-2023-7207.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-7207

Bug#1060032: libcircle-fe-term-perl: test failures with libtickit-widgets-perl 0.39-1

2024-01-04 Thread gregor herrmann

Source: libcircle-fe-term-perl
Version: 0.232470-1
Severity: serious
Tags: upstream ftbfs trixie sid
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libcircle-fe-term-perl has test failures with libtickit-widgets-perl 0.39-1

   dh_auto_test
/usr/bin/perl Build test --verbose 1

#   Failed test 'use Circle::FE::Term::Widget::Entry;'
#   at t/00use.t line 15.
# Tried to use 'Circle::FE::Term::Widget::Entry'.
# Error:  Cannot add a new method to an already-sealed class at 
/usr/share/perl5/Tickit/Style.pm line 246.
# BEGIN failed--compilation aborted at 
/build/libcircle-fe-term-perl-0.232470/blib/lib/Circle/FE/Term/Widget/Entry.pm 
line 174.
# Compilation failed in require at t/00use.t line 15.
# BEGIN failed--compilation aborted at t/00use.t line 15.
# Looks like you failed 1 test of 7.
t/00use.t .. 
ok 1 - use Circle::FE::Term;
ok 2 - use Circle::FE::Term::Tab;
ok 3 - use Circle::FE::Term::Ribbon;
ok 4 - use Circle::FE::Term::Widget::Box;
ok 5 - use Circle::FE::Term::Widget::Scroller;
ok 6 - use Circle::FE::Term::Widget::Label;
not ok 7 - use Circle::FE::Term::Widget::Entry;
1..7
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests 

Test Summary Report
- ---
t/00use.t (Wstat: 256 (exited 1) Tests: 7 Failed: 1)
  Failed test:  7
  Non-zero exit status: 1
Files=1, Tests=7,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.17 cusr  0.02 
csys =  0.21 CPU)
Result: FAIL


Cf. 
https://ci.debian.net/packages/libc/libcircle-fe-term-perl/testing/amd64/41469556/


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmWXZPJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYkiQ/7BWudMEVMYzyVW8KyC18XzVOioQ+8h++5b8rG/FLdX+bcPZUfKr4S9NAX
iaC4M9xoRmdPKSmDW4XG6AiJMcDGzwIjoMmogEEcjmV4UmkksFcMtZXTdZ3D8zkz
Nwsod/ZGt4/gnSBFkNw5rcxApFlrWQKcUHF68yoQh+p6JbExyyIFOL/5+Hr38I+e
CEOYRWe5NPZxcMrd1BI4ab/T2N5TnnWSVUN7qTjVozbS7sy9RW5xeH4PwEkJxJB7
VzTmc/iRzxWWkel8XLIfQpmx/MXTuKqB9A/UJsdhoS+WKQ4bivsEy9QBSDz2lAVB
N6nPJixJFq7VOjJqWBFmCNJr/WhYNllVccxh4pmzdpIip7Tf7Weqvu0PKE/8JisT
gnN25f9o2+doEy6gkW3LdjxR9jGFcBcXotGAg1jbh5rk5x/qgU2jA8BEhxBIRKgb
dOGPz/sSuJYdhhXzH3yOs+4n1LZi17eChChMSfsv5DytS63j5xvqyYx/51YWrMgQ
AfdMQUfHKrQo4ezwnt3I+QY4nOtGjtgAI7F88UzbxPkxtehCGiHHWX+MmYs4Wd2n
X6vTDsAQIdDZsq1V3PPW5MzsA83QIu3NRwuxRSf5HjQSG/mPrLO2TD6U2aXIhM3+
WU8d91C692S3uQ7UuKh2govUN+SDvPlDniMyUm+YN1LSkdG81iM=
=qvl2
-END PGP SIGNATURE-

Bug#1060031: efitools: please add support for loong64

2024-01-04 Thread wuruilong

Source: efitools
Version: 1.9.2-3
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Please support the loong64 arch. 
The patch is provided in the attachment for your reference.

wuruilong

-- 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=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 efitools (1.9.2-3) unstable; urgency=medium
 .
   [ Bo YU ]
   * Add patch to allow building on riscv64. Closes: #1012849
 .
   * Team upload
Author: Steve McIntyre <93...@debian.org>
Bug-Debian: https://bugs.debian.org/1012849

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-01-05

--- efitools-1.9.2.orig/Make.rules
+++ efitools-1.9.2/Make.rules
@@ -12,6 +12,8 @@ else ifeq ($(ARCH),riscv64)
 ARCH3264 =
 else ifeq ($(ARCH),arm)
 ARCH3264 =
+else ifeq ($(ARCH),loongarch64)
+ARCH3264 =
 else
 $(error unknown architecture $(ARCH))
 endif
@@ -62,6 +64,11 @@ ifeq ($(ARCH),riscv64)
   LDFLAGS += --defsym=EFI_SUBSYSTEM=0x0a
   FORMAT = -O binary
 endif
+
+ifeq ($(ARCH),loongarch64)
+  LDFLAGS += --defsym=EFI_SUBSYSTEM=0x0a
+  FORMAT = -O binary
+endif
 
 %.efi: %.so
$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic -j .dynsym \

Bug#1059837: Can dpkg-checkbuilddeps read,BuildProfileSpec "Registered profile names" pkg.$sourcepackage.$anything,in debian/control Build-Depends section?


clone 1059837 -1
reassign -1 dpkg-dev
retitle -1 dpkg-dev: dpkg-checkbuilddeps not read BuildProfileSpec "Registered 
profile names" pkg.$sourcepackage.$anything,in debian/control Build-Depends section
Severity: -1|important|



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059837: opencolorio： Please help fix circle dependence in Loongarch between openimageio and opencolorio


Hi,

    IMHO, it's not a bug of opencolorio, even is not a bug of Loongarch.

In opencolorio debian/control, |Build-Depends|[1] already used:

|libopenimageio-dev (>= 2.3.9.0) ,|


| is a |BuildProfileSpec "Registered profile 
names"pkg.$sourcepackage.$anything[2]

After I installed other |Build-Depends packages of |opencolorio, then run:

dpkg-checkbuilddeps
dpkg-checkbuilddeps: error: Unmet build dependencies: libopenimageio-dev 
(>= 2.3.9.0)


But after I export DEB_BUILD_PROFILES, dpkg-checkbuilddeps run success:

export 
DEB_BUILD_PROFILES="pkg.opencolorio.noopenimageio";dpkg-checkbuilddeps

atzlinux@nlx:~/opencolorio$ echo $?
0

So, my question is:

Can dpkg-checkbuilddeps  read

||BuildProfileSpec "Registered profile names"pkg.$sourcepackage.$anything in 
debian/control |Build-Depends section?|

Perhaps, it's a bug of dpkg-checkbuilddeps.


[1] 
https://sources.debian.org/src/opencolorio/2.1.3%2Bdfsg-1/debian/control/#L16

[2] https://wiki.debian.org/BuildProfileSpec#Registered_profile_names

在 2024/1/2 17:58, yalingfang 写道:

Source: opencolorio
Version: 2.1.3+dfsg-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64


Dear Maintainer,

     Currently when I built opencolorio in Loongarch env, I  
found there is circle dependence between openimageio and opencolorio

The buildd link is following:

https://buildd.debian.org/status/package.php?p=opencolorio=sid

https://buildd.debian.org/status/package.php?p=openimageio=sid


But the initial version of opencolorio can build pass by using 
DEB_BUILD_PROFILE="pkg.opencolorio.noopenimageio" when 
dpkg-buildpackage running.


and then we  can  use this first binary output to compile 
the openimageio to fix the circle dependence.


I have verified and passed  in my local env.

Please help fix the issue for some other application waiting the 
opencolorio and openimageio binary.


Any question, contact me!



--
肖盛文 xiao sheng wen
https://www.atzlinux.com  《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa:https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060030: xsar: Please drop python-setuptools-scm-git-archive from b-deps

Source: xsar
Severity: normal
Control: block 1060027 with -1
Forwarded: https://github.com/umr-lops/xsar/issues/191

Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7
has everything, so I would like to get it out of Debian.

Upstream doesn't have a patch yet. But you should just be able to patch
it out of setup.py and remove it from build-deps.

Stefano

Bug#1060029: satpy: Please drop python-setuptools-scm-git-archive from b-deps

Source: satpy
Severity: normal
Control: block 1060027 with -1

Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7
has everything, so I would like to get it out of Debian.

It doesn't look like it's being used any more, so you can just drop it
from debian/control.

Stefano

Bug#1060028: python-cheroot: Please drop python-setuptools-scm-git-archive from b-deps

Source: python-cheroot
Severity: normal
Tags: upstream, patch
Control: block 1060027 with -1

Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7
has everything, so I would like to get it out of Debian.

Upstream has applied a patch in https://github.com/cherrypy/cheroot/pull/628

Stefano

Bug#1060027: RM: setuptools-scm-git-archive -- ROM; obsoleted by setuptools-scm 7

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: setuptools-scm-git-arch...@packages.debian.org, jpu...@debian.org
Control: affects -1 + src:setuptools-scm-git-archive

setuptools-scm-git-archive is broken by setuptools-scm 8.

It was obsoleted by setuptools-scm 7, so there is no reason to keep it
in the archive.

Stefano

Bug#1060008: sioyek: segmentation fault with LANG=pt_BR.UTF-8

2024-01-04 Thread Victor Westerhuis


Thanks for the report.

On 04/01/2024 17:35, Hermógenes Oliveira wrote:

Package: sioyek
Version: 2.0.0+dfsg-4
Severity: normal
X-Debbugs-Cc: olive...@daad-alumni.de

Dear Maintainer,

Sioyek segfaults under some locales. The following is a core dump when sioyek 
was run with LANG=pt_BR.UTF-8.

PID: 8174 (sioyek)
UID: 1000 (hermogenes)
GID: 1000 (hermogenes)
 Signal: 11 (SEGV)
  Timestamp: Thu 2024-01-04 13:30:59 -03 (1min 41s ago)
   Command Line: sioyek
 Executable: /usr/bin/sioyek
  Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-7af031153e93402b9548172a76b1384f.scope
   Unit: user@1000.service
  User Unit: app-org.kde.konsole-7af031153e93402b9548172a76b1384f.scope
  Slice: user-1000.slice
  Owner UID: 1000 (hermogenes)
Boot ID: 6d9433832ef7458a96f4f520c2844573
 Machine ID: c9d323a2ff7f4ff9b40e8b5ca282777d
   Hostname: avalon
Storage: 
/var/lib/systemd/coredump/core.sioyek.1000.6d9433832ef7458a96f4f520c2844573.8174.170438585900.zst
 (present)
   Size on Disk: 29.8M
Message: Process 8174 (sioyek) of user 1000 dumped core.
 
 Module libudev.so.1 from deb systemd-255.2-3.amd64

 Module libsystemd.so.0 from deb systemd-255.2-3.amd64
 Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
 Stack trace of thread 8174:
 #0  0x7f9c5755e773 
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_assignERKS4_ 
(libstdc++.so.6 + 0x15e773)
 #1  0x55fff30c0f40 n/a (sioyek + 0xd4f40)
This location in the sioyek binary points to line 1589 or 1590 in 
pdf_viewer/main_widget.cpp in the function 
MainWidget::update_current_history_index, but I'm unable to recreate the 
crash myself.


Does the crash happen after a specific sequence of events? Or at random? 
Are you able to reproduce it yourself?

 #2  0x7f9c589a63aa _ZN7QWidget5eventEP6QEvent 
(libQt5Widgets.so.5 + 0x1a63aa)
 #3  0x7f9c58962f32 
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 
0x162f32)
 #4  0x7f9c57acc748 
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 
0x2cc748)
 #5  0x7f9c589be70e n/a (libQt5Widgets.so.5 + 0x1be70e)
 #6  0x7f9c589c2572 n/a (libQt5Widgets.so.5 + 0x1c2572)
 #7  0x7f9c58962f32 
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 
0x162f32)
 #8  0x7f9c57acc748 
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 
0x2cc748)
 #9  0x7f9c5813bd84 
_ZN22QGuiApplicationPrivate26processGeometryChangeEventEPN29QWindowSystemInterfacePrivate19GeometryChangeEventE
 (libQt5Gui.so.5 + 0x13bd84)
 #10 0x7f9c581131ac 
_ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 (libQt5Gui.so.5 + 0x1131ac)
 #11 0x7f9c54165550 n/a (libQt5WaylandClient.so.5 + 0xb1550)
 #12 0x7f9c577111f4 n/a (libglib-2.0.so.0 + 0x571f4)
 #13 0x7f9c57714317 n/a (libglib-2.0.so.0 + 0x5a317)
 #14 0x7f9c57714930 g_main_context_iteration 
(libglib-2.0.so.0 + 0x5a930)
 #15 0x7f9c57b27d4a 
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 (libQt5Core.so.5 + 0x327d4a)
 #16 0x7f9c57acb0fb 
_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 
0x2cb0fb)
 #17 0x7f9c57ad38a4 _ZN16QCoreApplication4execEv 
(libQt5Core.so.5 + 0x2d38a4)
 #18 0x55fff305b9d1 n/a (sioyek + 0x6f9d1)
 #19 0x7f9c572456ca n/a (libc.so.6 + 0x276ca)
 #20 0x7f9c57245785 __libc_start_main (libc.so.6 + 0x27785)
 #21 0x55fff305c2e1 n/a (sioyek + 0x702e1)
 
 Stack trace of thread 8183:

 #0  0x7f9c572a3156 n/a (libc.so.6 + 0x85156)
 #1  0x7f9c572a5818 pthread_cond_wait (libc.so.6 + 0x87818)
 #2  0x7f9c49f198fd n/a (iris_dri.so + 0x1198fd)
 #3  0x7f9c49ef96db n/a (iris_dri.so + 0xf96db)
 #4  0x7f9c49f1982b n/a (iris_dri.so + 0x11982b)
 #5  0x7f9c572a63ec n/a (libc.so.6 + 0x883ec)
 #6  0x7f9c57326a5c n/a (libc.so.6 + 0x108a5c)
 
 Stack trace of thread 8186:

 #0  0x7f9c572a3156 n/a (libc.so.6 + 0x85156)
 #1  0x7f9c572a5818 pthread_cond_wait (libc.so.6 + 0x87818)
 #2  0x7f9c49f198fd n/a (iris_dri.so + 0x1198fd)
 #3  0x7f9c49ef96db n/a (iris_dri.so + 0xf96db)

Bug#974220: #974220 libreoffice-writer: Double paste in Writer

2024-01-04 Thread Mario J


I just installed Debian 12 and bug still happens.

Bug#999989: poco 1.2 uses PCRE2, Mumble 1.5 depends on poco

2024-01-04 Thread Chris Knadle


Hello Jochen.

On 1/4/24 02:44, Jochen Sprickerhof wrote:

Hi Chris,

* Chris Knadle  [2024-01-02 03:06]:

Can the poco library be updated? Can I help in some way?


poco is basically orphaned, as I dropped myself from Uploaders in git 
and did not hear from the other maintainers for some time. The best 
way to help is to step up as a maintainer and update it ;).


The way to orphan a package is to do an upload and setting the 
maintainer to be . Until that's done the package 
ends up in maintainership limbo. See the bottom of Policy 3.3, and 
Developer's Reference section 5.9.4.


https://www.debian.org/doc/debian-policy/ch-binary.html#the-maintainer-of-a-package

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package

    https://wiki.debian.org/Orphaning

I may be able to prepare an updated version to upload as an NMU (i.e. it 
would be Debian version 1.13.0-0.1), but I can't take over maintaining 
this package long-term because I don't use it and am not familiar with 
it -- I only maintain a package that has it as a required build 
dependency. I also haven't maintained a library yet, but I've been in 
this situation of needing to upload a newer version of a library before 
so I might be able to figure out what's required to prepare an upload. 
It would be interesting to upload a new version as an NMU with the 
maintainer marked as  but strangely that seems 
to be what's called for here.


Unless the Poco library can be updated the only way to save Mumble 
will be to introduce an epoch in the package version to upload the 
now well outdated mumble 1.3.4 again which upstream cannot support 
anymore.


Nit: please don't use epochs for that, also see Policy 5.6.12.1.


Hah ... okay so if absolutely required I could upload mumble 
"1.5.517+really1.3.4-2". As crazy a version scheme as that is it beats 
having to introduce an epoch that I'd have to live with forever, so I'm 
glad to know that trick. Thanks.


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

Bug#1060026: yade: please move away from python3-future

2024-01-04 Thread Alexandre Detiste

Source: yade
Severity: important

Dear Maintainers,

python3-future is RC buggy and being removed from the archive.

please remove it's usage from you package


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#1060025: cfgrib: please remove extraneous build-dep on python3-future

2024-01-04 Thread Alexandre Detiste

Source: cfgrib
Version: 0.9.10.4-2
Severity: important


python3-future is RC buggy and being removed from the archive.

Please remove the stale references from your packaging.

debian/control: 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#1060024: python-pymodbus-doc: Documentation's changelog page is gzipped, breaking links

2024-01-04 Thread Jean-Paul Larocque

Package: python-pymodbus-doc
Version: 3.0.0-7
Severity: normal

Dear Maintainer,

Since upgrading to Bookworm, I discovered that one of my programs which used
python3-pymodbus broke, so I installed this package to look for incompatible
changes to the API between pymodbus versions 2.1.0 (the version from Buster)
and 3.0.0.

When I open /usr/share/doc/python-pymodbus-doc/html/index.html with my web
browser and click one of the links under "CHANGELOGS", my browser reports that
it cannot find /usr/share/doc/python-pymodbus-doc/html/changelog.html.  It
looks like .../changelog.html.gz is included in the package, so some part of
the packaging process is compressing this file, which breaks links from the
documentation pages.

A mediocre workaround for end-users is to decompress the page after
installation:

sudo gzip -dk /usr/share/doc/python-pymodbus-doc/html/changelog.html.gz

(Sadly, I can't use a local dpkg diversion, because my browser doesn't
transparently decompress gzipped HTML.)

Thanks for looking into this!
-Jean-Paul

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

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

Versions of packages python-pymodbus-doc depends on:
ii  libjs-sphinxdoc  5.3.0-4
ii  sphinx-rtd-theme-common  1.2.0+dfsg-1

python-pymodbus-doc recommends no packages.

python-pymodbus-doc suggests no packages.

-- no debconf information

Bug#1060023: ITP: keyd -- Keyboard key remapping daemon for Linux

2024-01-04 Thread Richard Hansen

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

* Package name: keyd
  Version : 2.4.3
  Upstream Contact: Raheman Vaiya 
* URL : https://github.com/rvaiya/keyd
* License : Expat
  Programming Lang: C
  Description : Keyboard key remapping daemon for Linux

keyd is a system-wide key remapping daemon which supports features like
layering, oneshot modifiers, and macros. In its most basic form it can be used
to define a custom key layout that persists across display server boundaries
(e.g wayland/X/tty).


Why I'm packaging this: I converted my Chromebook to a normal laptop running
Debian, and use keyd to work around the device's limited keyboard (no Home, End,
PageUp, PageDown, or Del keys, among others).

Unlike tools like xmodmap, keyd works at a low level (via Linux kernel
interfaces evdev and uinput), so it works with X11, Wayland, and VTs without
needing any environment-specific support.  As far as I know, no existing Debian
package provides similar low-level functionality.

keyd's feature set overlaps with kmonad (https://github.com/kmonad/kmonad) which
also merits packaging.  I'm packaging keyd instead of kmonad because keyd is
considerably simpler, and I'm unfamiliar with the Haskell ecosystem (kmonad is
written in Haskell).

I am not a DD or DM, so I would like some team or DD to volunteer to co-maintain
and sponsor uploads.  I'm not sure which team would be the best match;
suggestions would be appreciated.  Maybe the input method team
(https://wiki.debian.org/Teams/IMEPackagingTeam) would be interested; I'll ping
them if nobody has an alternative suggestion.

Bug#1060022: acl FTBFS with newer hardening flags

2024-01-04 Thread Steve Langasek

Package: acl
Version: 2.3.1-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hi Guillem,

It appears that something in the latest update of hardening flags in Ubuntu
noble now causes the package to fail to build, with both a compiler warning
about a buffer overflow, and runtime failures of getfacl because it trips
glibc's buffer overflow detection:

[...]
In function 'strcpy',
inlined from '__acl_to_any_text' at libacl/__acl_to_any_text.c:90:3:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:79:10: warning: 
'__builtin___strcpy_chk' writing 1 or more bytes into a region of size 0 
overflows the destination [-Wstringop-overflow=]
   79 |   return __builtin___strcpy_chk (__dest, __src, __glibc_objsize 
(__dest));
  |  ^
[...]
FAIL: test/cp
=
[...]
[28] $ getfacl --omit-header h/x -- failed
*** buffer overflow detected ***: terminated != user::rw-
~ != user:bin:rwx
~ != group::r--
~ != mask::rwx
~ != other::r--
~ != 
[...]

  (https://launchpad.net/ubuntu/+source/acl/2.3.1-4/+build/27588829)

This traces back to a use of a 0-length array in a struct as a flexible
variable-length array, which confuses the compiler's + glibc's string
hardening and results in a false-positive detection of a buffer overflow.

While this false-positive could be avoided by downgrading from
_FORTIFY_SOURCE=3 back to _FORTIFY_SOURCE=2, that would also weaken our
ability to detect actual bugs, so instead I've prepared the attached patch
to make the flexible array implementation compatible with the gcc hardening
implementation, as described at
.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru acl-2.3.1/debian/patches/flexible-array-bounds.patch 
acl-2.3.1/debian/patches/flexible-array-bounds.patch
--- acl-2.3.1/debian/patches/flexible-array-bounds.patch1969-12-31 
16:00:00.0 -0800
+++ acl-2.3.1/debian/patches/flexible-array-bounds.patch2024-01-04 
13:52:50.0 -0800
@@ -0,0 +1,22 @@
+Description: Fix use of flexible array to allow proper bounds checking
+ As described at https://people.kernel.org/kees/bounded-flexible-arrays-in-c
+ we should not define flexible arrays as being an array with 0 members; this
+ prevents the compiler from doing proper bounds checking and build time, and
+ in our case with gcc-13 in Ubuntu results in a getfacl command that aborts
+ claiming that a buffer overflow has been detected.
+Author: Steve Langasek 
+Forwarded: no
+Last-Update: 2024-01-04
+
+--- acl-2.3.1.orig/libacl/libobj.h
 acl-2.3.1/libacl/libobj.h
+@@ -77,7 +77,8 @@ typedef struct string_obj_tag string_obj
+ 
+ /* string object */
+ struct __string_ext {
+-  chars_str[0];
++  struct { } __unused_member1;
++  chars_str[];
+ };
+ struct string_obj_tag {
+   obj_prefix  o_prefix;
diff -Nru acl-2.3.1/debian/patches/series acl-2.3.1/debian/patches/series
--- acl-2.3.1/debian/patches/series 2021-04-08 17:43:29.0 -0700
+++ acl-2.3.1/debian/patches/series 2024-01-04 13:50:12.0 -0800
@@ -7,3 +7,4 @@
 man-setfacl-restore-stdin.patch
 getfacl-fix-uninitialized-variable.patch
 l10n-update-fr.patch
+flexible-array-bounds.patch

Bug#1060000: e2fsprogs: move files to /usr for DEP17

2024-01-04 Thread Chris Hofstaedtler

On Thu, Jan 04, 2024 at 03:24:01PM +0100, Helmut Grohne wrote:
> [..] If you
> rather prefer a patch that is not backportable, please let me know.

Attached is a patch of that form, that I was working on yesterday.

diff -Nru e2fsprogs-1.47.0/debian/changelog e2fsprogs-1.47.0/debian/changelog
--- e2fsprogs-1.47.0/debian/changelog	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/changelog	2024-01-04 22:42:48.0 +0100
@@ -1,3 +1,10 @@
+e2fsprogs (1.47.0-2.2) UNRELEASED; urgency=medium
+
+  * Install files into /usr instead of aliased locations.
+Not backportable to bookworm or earlier.
+
+ -- Chris Hofstaedtler   Thu, 04 Jan 2024 22:42:48 +0100
+
 e2fsprogs (1.47.0-2) unstable; urgency=medium
 
   * Don't enable metadata_csum_seed and orhpan_file by default (Closes:
diff -Nru e2fsprogs-1.47.0/debian/e2fsck-static.install e2fsprogs-1.47.0/debian/e2fsck-static.install
--- e2fsprogs-1.47.0/debian/e2fsck-static.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/e2fsck-static.install	2024-01-03 13:26:38.0 +0100
@@ -1,2 +1,2 @@
-/sbin/e2fsck.static
+/usr/sbin/e2fsck.static
 /usr/share/man/man8/e2fsck.static*
diff -Nru e2fsprogs-1.47.0/debian/e2fsprogs.install e2fsprogs-1.47.0/debian/e2fsprogs.install
--- e2fsprogs-1.47.0/debian/e2fsprogs.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/e2fsprogs.install	2024-01-04 22:42:48.0 +0100
@@ -1,19 +1,19 @@
 #!/usr/bin/dh-exec
-sbin/badblocks
-sbin/debugfs
-sbin/dumpe2fs
-sbin/e2fsck
-sbin/e2image
-sbin/e2label
-sbin/e2mmpstatus
-[linux-any] sbin/e2scrub
-[linux-any] sbin/e2scrub_all
-sbin/e2undo
-sbin/fsck.ext?
-sbin/mke2fs
-sbin/mkfs.ext?
-sbin/resize2fs
-sbin/tune2fs
+usr/sbin/badblocks
+usr/sbin/debugfs
+usr/sbin/dumpe2fs
+usr/sbin/e2fsck
+usr/sbin/e2image
+usr/sbin/e2label
+usr/sbin/e2mmpstatus
+[linux-any] usr/sbin/e2scrub
+[linux-any] usr/sbin/e2scrub_all
+usr/sbin/e2undo
+usr/sbin/fsck.ext?
+usr/sbin/mke2fs
+usr/sbin/mkfs.ext?
+usr/sbin/resize2fs
+usr/sbin/tune2fs
 usr/bin/chattr
 usr/bin/lsattr
 [linux-any] usr/lib/*/e2fsprogs/e2scrub_all_cron
@@ -49,5 +49,5 @@
 usr/share/man/man8/resize2fs.8
 usr/share/man/man8/tune2fs.8
 etc
-[linux-any] lib/udev/rules.d
-[linux-any] lib/systemd/system
+[linux-any] usr/lib/udev/rules.d
+[linux-any] usr/lib/systemd/system
diff -Nru e2fsprogs-1.47.0/debian/e2fsprogs-udeb.install e2fsprogs-1.47.0/debian/e2fsprogs-udeb.install
--- e2fsprogs-1.47.0/debian/e2fsprogs-udeb.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/e2fsprogs-udeb.install	2024-01-03 13:33:29.0 +0100
@@ -1,11 +1,11 @@
 etc/mke2fs.conf
-lib/*/lib*.so.*
-sbin/badblocks
-sbin/e2fsck
-sbin/mke2fs
-sbin/resize2fs
-sbin/tune2fs
-sbin/e2label
-sbin/e2mmpstatus
-sbin/fsck.ext?
-sbin/mkfs.ext?
+usr/lib/*/lib*.so.*
+usr/sbin/badblocks
+usr/sbin/e2fsck
+usr/sbin/mke2fs
+usr/sbin/resize2fs
+usr/sbin/tune2fs
+usr/sbin/e2label
+usr/sbin/e2mmpstatus
+usr/sbin/fsck.ext?
+usr/sbin/mkfs.ext?
diff -Nru e2fsprogs-1.47.0/debian/.gitignore e2fsprogs-1.47.0/debian/.gitignore
--- e2fsprogs-1.47.0/debian/.gitignore	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/.gitignore	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-!patches
diff -Nru e2fsprogs-1.47.0/debian/libblkid1.install e2fsprogs-1.47.0/debian/libblkid1.install
--- e2fsprogs-1.47.0/debian/libblkid1.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/libblkid1.install	2024-01-03 13:26:43.0 +0100
@@ -1 +1 @@
-lib/*/libblkid*.so.*
+usr/lib/*/libblkid*.so.*
diff -Nru e2fsprogs-1.47.0/debian/libcom-err2.install e2fsprogs-1.47.0/debian/libcom-err2.install
--- e2fsprogs-1.47.0/debian/libcom-err2.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/libcom-err2.install	2024-01-03 13:28:30.0 +0100
@@ -1 +1 @@
-lib/*/libcom_err*.so.*
+usr/lib/*/libcom_err*.so.*
diff -Nru e2fsprogs-1.47.0/debian/libext2fs2.install e2fsprogs-1.47.0/debian/libext2fs2.install
--- e2fsprogs-1.47.0/debian/libext2fs2.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/libext2fs2.install	2024-01-03 13:26:50.0 +0100
@@ -1,2 +1,2 @@
-lib/*/libext2fs*.so.*
-lib/*/libe2p*.so.*
+usr/lib/*/libext2fs*.so.*
+usr/lib/*/libe2p*.so.*
diff -Nru e2fsprogs-1.47.0/debian/libss2.install e2fsprogs-1.47.0/debian/libss2.install
--- e2fsprogs-1.47.0/debian/libss2.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/libss2.install	2024-01-03 13:26:55.0 +0100
@@ -1 +1 @@
-lib/*/libss*.so.*
+usr/lib/*/libss*.so.*
diff -Nru e2fsprogs-1.47.0/debian/libuuid1.install e2fsprogs-1.47.0/debian/libuuid1.install
--- e2fsprogs-1.47.0/debian/libuuid1.install	2023-03-05 04:16:08.0 +0100
+++ e2fsprogs-1.47.0/debian/libuuid1.install	2024-01-03 13:26:58.0 +0100
@@ -1 +1 @@
-lib/*/libuuid*.so.*
+usr/lib/*/libuuid*.so.*
diff -Nru e2fsprogs-1.47.0/debian/logsave.install e2fsprogs-1.47.0/debian/logsave.install
---

Bug#1055655: rebuild fails with node-typescript 4.9.5 in experimental

2024-01-04 Thread Ying-Chun Liu (PaulLiu)


Hi weepingclown,

I think 4.1.4-3 fixes the problem.

I tried to build 4.1.4-3 in experimental. The build log is as attachment.
Seems fixed.

Yours,
Paul


node-js-sdsl_4.1.4-3_amd64.build.gz
Description: application/gzip


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060016: packagekit: CVE-2024-0217

Hi Matthias,

On Thu, Jan 04, 2024 at 09:30:44PM +0100, Matthias Klumpp wrote:
> Hi!
> 
> Am Do., 4. Jan. 2024 um 20:51 Uhr schrieb Salvatore Bonaccorso
> :
> >
> > Source: packagekit
> > Version: 1.2.6-5
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> >
> > Hi,
> >
> > The following vulnerability was published for packagekit.
> >
> > CVE-2024-0217[0]:
> > | A use-after-free flaw was found in PackageKitd. In some conditions,
> > | the order of cleanup mechanics for a transaction could be impacted.
> > | As a result, some memory access could occur on memory regions that
> > | were previously freed. Once freed, a memory region can be reused for
> > | other allocations and any previously stored data in this memory
> > | region is considered lost.
> >
> > The only reference know so far is [1] which say as well that the issue
> > should be fixed in 1.2.7 upstream. Do you happen to know more on it?
> 
> This might be the worst CVE I've seen in a while... PackageKit has
> backends, so at the very least this CVE should state whether this
> affects a backend only (in which case we might even be fine if we
> don't ship it) or the daemon core, or a library. Judging from how this
> is worded, it's likely one of the latter, which would be worse.
> On the bug report, it is stated that "It was observed that under some
> conditions, the order of cleanup mechanics for a transaction could be
> impacted.", but there are no details given what these circumstances
> even are.
> Furthermore, Philip Withnall did quite a bit of larger rework on
> PackageKit's transaction logic for 1.2.7, so whatever the issue is it
> might have been accidentally fixed in a larger commit of that series.
> 
> But tbh, this CVE is so vague that I have no idea where I'd even look
> for this (unless I wanted to repeat the work that went into finding
> this and create random transaction states while running with address
> sanitizer on).
> Let's hope the reporter replies to the request in RH bugzilla.

Thanks for the very quick reply! 

Ok let's see if the reporter in the Red Hat bugzilla replies to the
'needinfo' request. Will update the bug here in case I notice earlier
than you.

I had  expected that packagekit upstream get some information as well
from Red Hat, so you as well :-)

Thanks a lot for your work!

Regards,
Salvatore

Bug#1059005: libssh2: CVE-2023-48795

Hi Nicolas,

On Thu, Jan 04, 2024 at 03:38:29PM -0500, Nicolas Mora wrote:
> Hello,
> 
> I've uploaded a new package with the patch for unstable, instead of
> waiting for the new upstream release. I didn't want the holidays and
> the new release process to delay the fix too much...

Thanks, have seen it! (security-tracker metadata is already updated).

Regards,
Salvatore

Bug#1051428: Update

2024-01-04 Thread Marcos Garcia Ochoa

Tested again on 12.4 on Gnome: the remote control window shows up, it
allows for moving/resizing once and then stop responding to the decoration.
I can close the window from the taskbar both in LXDE and Gnome, which is
something.

-- 
Ta otro mail...
Marcos (cualquier parecido con la coincidencia es pura realidad)

Bug#1060021: fscrypt: New upstream version available (0.3.4)

Source: fscrypt
Version: 0.3.3-1
Severity: normal
X-Debbugs-Cc: car...@debian.org

Hi

Last year a new upsteam version 0.3.4 was released which might be
worth having packaged in trixie. The NEWS notes mention:

* fscrypt now requires Go 1.16 or later to build.

* pam_fscrypt now supports the option unlock_only to disable locking of
  directories on logout.

* Fixed a bug where the number of CPUs used in the passphrase hash would
  be calculated incorrectly on systems with more than 255 CPUs.

* Added support for AES-256-HCTR2 filenames encryption.

* Directories are now synced immediately after an encryption policy is
  applied, reducing the chance of an inconsistency after a sudden crash.

* Added Lustre to the list of allowed filesystems.

* Added a NEWS.md file that contains the release notes, and backfilled
  it from the GitHub release notes.


Thanks for considering it.

Regards,
Salvatore

Bug#1059533: DEP17: handle /usr-move for gzip and its diversions by zutils

2024-01-04 Thread Helmut Grohne

Thanks to Chris for testing my patch and discovering that it was broken.

On Wed, Dec 27, 2023 at 10:27:08PM +0100, Helmut Grohne wrote:
> > So I've developed these patches (both attached). Since piuparts doesn't
> > deal well with testing essential packages, I've developed test cases
> > using mmdebstrap (also attached) and performed the --set-selections test
> > manually. Everything looks fine, but I keep the fingers crossed.
> 
> Tests rerun successfully.

The fundamental mistake on my side was with testing. I managed to
comment out the installation of the actual packages. :-(

Then, I didn't see the obvious failure from zutils.preinst which was
setting up one of the diversions incorrectly.


> Sorry for the initially broken gzip patch.

Also sorry for the initially broken zutils patch.

Attached:
 * Fixed testcase.sh
 * Fixed zutils patch (changes 1 line in zutils.preinst)

Helmut


testcase.sh
Description: Bourne shell script
diff -Nru zutils-1.12/debian/changelog zutils-1.12/debian/changelog
--- zutils-1.12/debian/changelog2023-06-16 11:37:05.0 +0200
+++ zutils-1.12/debian/changelog2023-12-23 07:46:00.0 +0100
@@ -1,3 +1,10 @@
+zutils (1.12-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17 M18: Duplicate aliased diversions (Closes: #-1).
+
+ -- Helmut Grohne   Sat, 23 Dec 2023 07:46:00 +0100
+
 zutils (1.12-3) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru zutils-1.12/debian/rules zutils-1.12/debian/rules
--- zutils-1.12/debian/rules2023-06-13 08:08:48.0 +0200
+++ zutils-1.12/debian/rules2023-12-23 07:46:00.0 +0100
@@ -6,7 +6,7 @@
dh ${@}
 
 override_dh_auto_configure:
-   dh_auto_configure -- --exec-prefix=/ CXX=$(CXX)
+   dh_auto_configure -- CXX=$(CXX)
 
 override_dh_auto_install:
dh_auto_install -- DESTDIR=$(CURDIR)/debian/zutils
diff -Nru zutils-1.12/debian/zutils.postrm zutils-1.12/debian/zutils.postrm
--- zutils-1.12/debian/zutils.postrm2023-06-13 08:08:48.0 +0200
+++ zutils-1.12/debian/zutils.postrm2023-12-23 07:45:29.0 +0100
@@ -6,7 +6,8 @@
remove)
for FILE in zcat zcmp zdiff zegrep zfgrep zgrep
do
-   dpkg-divert --package zutils --quiet --remove --rename 
--divert /bin/${FILE}.gzip /bin/${FILE}
+   dpkg-divert --package zutils --quiet --remove --rename 
--divert "/usr/bin/$FILE.gzip" "/usr/bin/$FILE"
+   dpkg-divert --package zutils --quiet --remove --rename 
--divert "/bin/$FILE.gzip.usr-is-merged" "/bin/$FILE"
dpkg-divert --package zutils --quiet --remove --rename 
--divert /usr/share/man/man1/${FILE}.gzip.1.gz /usr/share/man/man1/${FILE}.1.gz
done
;;
diff -Nru zutils-1.12/debian/zutils.preinst zutils-1.12/debian/zutils.preinst
--- zutils-1.12/debian/zutils.preinst   2023-06-13 08:08:48.0 +0200
+++ zutils-1.12/debian/zutils.preinst   2023-12-23 07:46:00.0 +0100
@@ -2,15 +2,32 @@
 
 set -e
 
+# DEP17 M18: Duplicate diversion in aliased location /bin.
+
 case "${1}" in
install)
for FILE in zcat zcmp zdiff zegrep zfgrep zgrep
do
-   dpkg-divert --package zutils --quiet --add --rename 
--divert /bin/${FILE}.gzip /bin/${FILE}
+   dpkg-divert --package zutils --quiet --add --rename 
--divert "/usr/bin/$FILE.gzip" "/usr/bin/$FILE"
+   dpkg-divert --package zutils --quiet --add --rename 
--divert "/bin/$FILE.gzip.usr-is-merged" "/bin/$FILE"
dpkg-divert --package zutils --quiet --add --rename 
--divert /usr/share/man/man1/${FILE}.gzip.1.gz /usr/share/man/man1/${FILE}.1.gz
done
;;
 
+   upgrade)
+   for FILE in zcat zcmp zdiff zegrep zfgrep zgrep
+   do
+   TRUENAME=$(dpkg-divert --truename "/bin/$FILE")
+   dpkg-divert --package zutils --quiet --add --no-rename 
--divert "/usr/bin/$FILE.gzip" "/usr/bin/$FILE"
+   if test "$TRUENAME" != "/bin/$FILE.gzip.usr-is-merged"; 
then
+   dpkg-divert --package zutils --quiet --remove 
--no-rename "/bin/$FILE"
+   dpkg-divert --package zutils --quiet --add 
--no-rename --divert "/bin/$FILE.gzip.usr-is-merged" "/bin/$FILE"
+   if test -e "$DPKG_ROOT$TRUENAME" -o -h 
"$DPKG_ROOT$TRUENAME"; then
+   mv "$DPKG_ROOT$TRUENAME" 
"$DPKG_ROOT/bin/$FILE.gzip.usr-is-merged"
+   fi
+   fi
+   done
+   ;;
abort-upgrade|upgrade)
 
;;

Bug#1060002: usrmerge: support working with a moved coreutils and policycoreutils

2024-01-04 Thread Helmut Grohne

Hi Marco,

On Thu, Jan 04, 2024 at 05:27:39PM +0100, Marco d'Itri wrote:
> Please just describe in detail why these changes will be needed.

The bootstrap protocol is to unpack all relevant packages and then
configure them. deboostrap currently deviates from the bootstrap
protocol in performing a merge, but DEP17 will revert eventually.

Let us assume that coreutils moves /bin/cp to /usr/bin/cp. Then a
bootstrapping tool unpacks all relevant binary packages, but does not
perform any kind of merging. The init-system-helpers dependency on
usrmerge | usr-is-merge causes usrmerge to be installed.
usrmerge.postinst runs convert-usrmerge on an unmerged tree. This will
call "ldd /bin/cp", but "/bin/cp" does not exist and convert-usrmerge
fails. This is bad.

The patch makes usrmerge work in a scenario where cp has been moved to
/usr/bin/cp already.

This change is only useful very temporarily. The plan goes on to change
base-files to install the aliasing symbolic links. Then, base-files will
provide usr-is-merged and usrmerge will no longer be installed by
bootstrapping tools. For changing base-files we need to do a coordinated
upload of involved packages. In adding this change to convert-usrmerge,
we reduce the packages involved and can convert coreutils at an earlier
time.

The change about restorecon is cautious and not strictly necessary. I do
not see a scenario where this should practically make a difference.

Helmut

Bug#1060020: flask-dance: FTBFS with python3-werkzeug >= 2.3.8

2024-01-04 Thread Julian Gilbey

Source: flask-dance
Version: 7.0.0-1
Severity: serious

flask-dance fails its tests when built with python3-werkzeug 2.3.8-1
(and also with version 3.0.x in experimental as well), and needs
updating to handle this.

Also reported upstream to
https://github.com/singingwolfboy/flask-dance/issues/425

Best wishes,

   Julian

Bug#1027876: Missing cmake files

2024-01-04 Thread Thomas Braun

I'm also hitting a wall here as the cmake files are not present.

Bug#1060019: transition: poppler 23.12

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: popp...@packages.debain.org

Poppler is on a monthly release cycle. I request that we do the
poppler 23.12 transition with the December 2023 version.

We have completed the Poppler 23.12 transition in Ubuntu except for an
issue with octave-dicom which doesn't appear to affect Debian and was
only involved because its autopkgtest was triggered by gdcm.

I believe everything should be binNMUable without issue.

This tracker is good:
https://release.debian.org/transitions/html/auto-poppler.html

Thank you,
Jeremy Bicha

Bug#1059005: libssh2: CVE-2023-48795

2024-01-04 Thread Nicolas Mora

Hello,

I've uploaded a new package with the patch for unstable, instead of waiting for 
the new upstream release. I didn't want the holidays and the new release 
process to delay the fix too much...

Bug#1060016: packagekit: CVE-2024-0217

2024-01-04 Thread Matthias Klumpp

Hi!

Am Do., 4. Jan. 2024 um 20:51 Uhr schrieb Salvatore Bonaccorso
:
>
> Source: packagekit
> Version: 1.2.6-5
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
>
> Hi,
>
> The following vulnerability was published for packagekit.
>
> CVE-2024-0217[0]:
> | A use-after-free flaw was found in PackageKitd. In some conditions,
> | the order of cleanup mechanics for a transaction could be impacted.
> | As a result, some memory access could occur on memory regions that
> | were previously freed. Once freed, a memory region can be reused for
> | other allocations and any previously stored data in this memory
> | region is considered lost.
>
> The only reference know so far is [1] which say as well that the issue
> should be fixed in 1.2.7 upstream. Do you happen to know more on it?

This might be the worst CVE I've seen in a while... PackageKit has
backends, so at the very least this CVE should state whether this
affects a backend only (in which case we might even be fine if we
don't ship it) or the daemon core, or a library. Judging from how this
is worded, it's likely one of the latter, which would be worse.
On the bug report, it is stated that "It was observed that under some
conditions, the order of cleanup mechanics for a transaction could be
impacted.", but there are no details given what these circumstances
even are.
Furthermore, Philip Withnall did quite a bit of larger rework on
PackageKit's transaction logic for 1.2.7, so whatever the issue is it
might have been accidentally fixed in a larger commit of that series.

But tbh, this CVE is so vague that I have no idea where I'd even look
for this (unless I wanted to repeat the work that went into finding
this and create random transaction states while running with address
sanitizer on).
Let's hope the reporter replies to the request in RH bugzilla.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

2024-01-04 Thread Julian Gilbey

Hi all,

A quick update

On Thu, Jan 04, 2024 at 12:13:19PM +0100, Thomas Goirand wrote:
> On 1/3/24 22:22, Julian Gilbey wrote:
> > On Fri, Dec 22, 2023 at 12:04:48AM +0100, Gregor Riepl wrote:
> > > Hi Carsten,
> > > [...]
> > > 
> > > My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit 
> > > for
> > > release, it should be enough to upgrade to 2.3.5 to address these unit 
> > > test
> > > failures.
> > > [...]

Updates:

(1) I've added python3-markupsafe to the Build-Depends and pushed to
debian/experimental (though not uploaded it to experimental)

(2) It appears that all of the autopkgtests triggered by
python3-werkzeug 2.3.8 have passed (though most are no longer showing
on tracker.d.o).  The only package that is failing is flask-dance.  As
you (Carsten) mentioned earlier, "the upstream package isn't really
ready for the newer versions", so I suggest that we file an RC bug
against it.  Perhaps we can ask the appropriate team (release team?)
to drop it from testing for now so that python3-werkzeug can migrate.
It has no reverse dependencies.

Best wishes,

   Julian

Bug#1059986: dpkg: Please add hurd-arm64 case

2024-01-04 Thread Samuel Thibault

Hello,

Guillem Jover, le jeu. 04 janv. 2024 20:23:02 +0100, a ecrit:
> but even though I've seen already some toolchain patches flying by,
> AFAIUI there's still no GNU Mach support, so I think I'd prefer to
> wait until that materializes,

Ok.

> as per the FAQ entry on new ports. I don't think this would block
> anything right now anyway, no?

I've hacked by chroot to add the arch to be able to build packages
already ;)

I was mostly anticipating this piece of the port which is needed for
proper set up of most of the rest :)

Samuel

Bug#915583: Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

2024-01-04 Thread Stéphane Blondon

> Holger Wansing  wrote (Sun, 31 Dec 2023 10:02:29 +0100):
> They look really good indeed.
> Especially how the menu/sidebar is shown/not shown on small screens
> (smartphones) is fine, that was an open point in my proposal :-)

Thanks you but it's more a good work by readthedoc theme than me. ^^


> BTW: I think it would be good to have the 'Next'/'Previous' buttons
> at the top additionally to those at the bottom.
> The theme supports this via a config option. Simply set
>
> html_theme_options = {
> # To get previous/next buttons at the top and the bottom:
> 'prev_next_buttons_location': 'both'
> }
>
> in conf.py.in.

It's a good idea.
The interface is visible in the screenshot attached to this message.


-- 
Stéphane

Bug#1057493: Additional information

2024-01-04 Thread Vladimir Petko

Dear Maintainers,

Would it be possible to consider  merge requests[1][2] that address this
issue?

The byte-buddy upgrade should also resolve[3].

This is a package upgrade so I am not quite sure of the exact procedure - I
have raised MRs with commits containing the upstream sources in the master
branch.
Should I also push and raise MRs for upstream/pristine-tar branches?

Best Regards,
 Vladimir.

[1] https://salsa.debian.org/java-team/byte-buddy/-/merge_requests/1
[2] https://salsa.debian.org/java-team/asm/-/merge_requests/2
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057518

Bug#1060017: xvfb: Failed to start

Package: xvfb
Version: 2:21.1.10-1
Severity: critical
Tags: ftbfs
Control: affects -1 src: rhythmbox

xvfb is failing to start in Debian Unstable. This is making many
packages fail to build from source.

See for instance https://buildd.debian.org/status/package.php?p=rhythmbox

Build log excerpt:

xvfb-run: error: Xvfb failed to start

Thank you,
Jeremy Bícha

Bug#1059873: glibc-doc-reference: 12.14.5 String Input Conversions: The ‘%[’ conversion requires 1 match

2024-01-04 Thread Aurelien Jarno

Hi,

On 2024-01-04 17:38, Krzysztof Żelechowski wrote:
>I was trying to read up to 7 characters, including blanks.  I assumed that
>the specifier "%[^]" would mean any character except an empty set, i.e.
>any character whatsoever.  I can see now that it can also be an incomplete

Your definition of "empty set" is quite vague. What you want is clearly
defined in the section 12.14.3, that is %7s or %7S.

>format specifier excluding the character ']'.  This is my misunderstanding
>but I think the documentation could be improved to prevent such mistakes
>in future.

I don't see how things can be improved further. But if you have a
wording suggestion, please submit one. Otherwise, I'll just close the
bug.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1060016: packagekit: CVE-2024-0217

Source: packagekit
Version: 1.2.6-5
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for packagekit.

CVE-2024-0217[0]:
| A use-after-free flaw was found in PackageKitd. In some conditions,
| the order of cleanup mechanics for a transaction could be impacted.
| As a result, some memory access could occur on memory regions that
| were previously freed. Once freed, a memory region can be reused for
| other allocations and any previously stored data in this memory
| region is considered lost.

The only reference know so far is [1] which say as well that the issue
should be fixed in 1.2.7 upstream. Do you happen to know more on it?


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-0217
https://www.cve.org/CVERecord?id=CVE-2024-0217
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2256624

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1059873: 12.14.5 String Input Conversions: The meaning of ‘%[\0abut]’ conversion is unclear

2024-01-04 Thread Aurelien Jarno

Hi,

On 2024-01-04 17:59, Krzysztof Żelechowski wrote:
>The fact that the NUL character ends a string data structure is a library
>convention rather than a language feature, except for the "" literal
>syntactic sugar. 

We are here talking about *string* functions of the C standard. String
functions in this context are defined as NULL terminated. The beginning
of section 12.14 makes clear that the argument of the fscanf function is
a format *string*.

> But it is not a programming error to have a string
>literal with embedded NULs; in fact, if your narrowing interpretation were
>universally correct, the argz API would not be possible.  You can write

The argz functions do not operate on strings. They operate on *vector of
strings*. See section 5.15.

>valid programs in C without using this convention, e.g. using BSTR
>everywhere.  You were even supposed to do that when programming in C for
>Apple Macintosh, to the extent that their C compiler used to provide an
>alternative string literal syntax for this purpose as an extension.

Indeed you are allow to use your own convention for a library, but But a
string is well defined in the C standard in the context of the string
functions.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#953091: RFA: colorhug-client -- Tools for the Hughski Colorimeter

Hi,

Can I proceed with orphaning this package?

Thank you,
Jeremy Bícha

Bug#1060006: ITP: brpc -- Apache's brpc - Industrial-grade RPC framework

2024-01-04 Thread RL

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.general as well.

Didier 'OdyX' Raboud  writes:

> * Package name: brpc
>   Version : 1.7.0
>   Upstream Contact: d...@brpc.apache.org
> * URL : https://brpc.apache.org/
> * License : Apache-2.0
>   Programming Lang: C++
>   Description : Industrial-grade RPC
>  Apache bRPC is often used in high performance systems such as Search,
>  Storage, Machine learning, Advertisement, Recommendation, etc
>
> (the short and long descriptions' are really bad; suggestions welcome!

suggestions:
- say what it is for - why would i install it?
- See also guide at http://jbr.me.uk/linux/esl.html (section F)

specifics:
- avoid hyperbole like "industrial-grade", "high performance" - if it means 
something
specific - fast? reliable? follows some standard? - say that, else avoid.

I dont think "high performance systems such as X, Y, Z" with "such as"
works unless "X, Y, Z" are the names of "high-performance systems" ---
perhaps "Search" is (bad) shorthand for "systems for searching ",
but "machine learning" is not really a "system". "Advertisement" could
mean several things - is this software for producing adverts?  (maybe
"such as for" is better, but I think how people have used something is
much less interesting that what features the something provides. And is
"often" based on any data?)

- avoid jargon - or at least explain what "RPC" means

- unless it's to do with the apache web-server, or part of the name, the
  word "Apache" may be confusing. (if it's a module try and copy their
  descriptions).

Bug#1059805: clucene-core: please apply LibreOffice patch to alllow not writing random timestamps into generated files, making them unreproducible

2024-01-04 Thread James Addison

On Wed, 3 Jan 2024 at 20:32, James Addison  wrote:
>
> (with apologies for forgetting to cc Rene on my previous message)
>
> On Wed, 3 Jan 2024 at 19:45, James Addison  wrote:
> >
> > On Wed, 3 Jan 2024 at 16:59, Thorsten Behrens  wrote:
> > >
> > > Source: clucene-core
> > > Followup-For: Bug #1059805
> > > X-Debbugs-Cc: r...@debian.org, t...@libreoffice.org
> > >
> > > James Addison wrote:
> > > > And so a question: could the fix be achieved by changing the default
> > > > value of the version field from millis-timestamp to zero -- meaning:
> > > > without needing to adjust the API?
> > > >
> > > Note that we _only_ need this during build time (so another option
> > > would be using the custom clucene during build, but still link the
> > > system clucene for runtime).
> > >
> > > I simply don't know enough about the motivations to have this
> > > pseudo-random value there in the first place, to opine on whether the
> > > default can/should be changed...
> >
> > Agreed.  I'm trying to trace the origins of that behaviour.
> [ ... snip ... ]
> > This timestamping was introduced[1] in Lucene 1.9RC1 back in Y2005 -
> > the changelog entry[2] doesn't tell us much more, although we can
> > imply that it was for a timing/refreshness related fix, because the
> > change adds an isCurrent method (described as useful to check whether
> > an IndexReader has an up-to-date object reference to an index/segment)
> > and test coverage.  There is a subsequent race-condition fixup[3].
> [ ... snip ... ]
>
> Squinting more at the test coverage, a hypothetical explanation I can
> think of is this:
>
> If two index writer processes were likely to recreate an index file
> near the same time, or in the presence of long-lived index reader
> processes, then with a zero-based counter, a reader could easily
> mistake two independently-created index segments (created with segment
> version zero) as being 'current'.
>
> I don't know for certain that this is the scenario that the timestamp
> is intended to mitigate against -- it's certainly also possible that
> Solr replication (noted elsewhere in the LUCENE-3607 JIRA thread) was
> just as important, or maybe moreso.
>
> However: libreoffice is, as I understand it, using this during
> one-time build processes, and does not require replication of those
> indexes.
>
> I think the safe middle-ground rather than resetting to zero during a
> reproducible build would be to use the value of SOURCE_DATE_EPOCH[1].
> That should mean no API changes, and we're still using a timestamp,
> keeping us close to the current behaviour -- but in a more
> reproducible way.
[ ... snip ... ]

The attached patch for clucene-core-2.3.3.4+dfsg-1.1 compiles and
implements SOURCE_DATE_EPOCH time retrieval -- but only in the context
of the segment info version fields.

Running a help build with SOURCE_DATE_EPOCH=0 should, with this patch,
be more-or-less equivalent to calling the proposed additional API
method to reset the segment version to zero.

The reason it doesn't override system time retrieval globally in the
codebase is that RAMDirectory objects are initialized[1] using the
system current time, and contain a while loop[2] that compares the
lastmodified on those objects to the output of another, subsequent
call to retrieve the system time -- so I thought it'd be sensible to
avoid the risk of an infinite loop there (while ts1 == ts2).

Please note: I haven't tested the patch yet, hence not adding a
'patch' tag to this bug yet - I'm building libreoffice locally after
installing the patched+compiled clucene package, and will inspect the
help indexes constructed by the build.  Feedback / review /
alternative approach suggestions are welcome.

[1] - 
https://sources.debian.org/src/clucene-core/2.3.3.4%2Bdfsg-1.1/src/core/CLucene/store/RAMDirectory.cpp/#L45

[2] - 
https://sources.debian.org/src/clucene-core/2.3.3.4%2Bdfsg-1.1/src/core/CLucene/store/RAMDirectory.cpp/#L523
Description: Read default index segment version from SOURCE_DATE_EPOCH when set
Author: James Addison 
Bug-Debian: https://bugs.debian.org/1059805

---
--- clucene-core-2.3.3.4+dfsg.orig/src/core/CLucene/index/SegmentInfos.cpp
+++ clucene-core-2.3.3.4+dfsg/src/core/CLucene/index/SegmentInfos.cpp
@@ -560,7 +560,7 @@ string SegmentInfo::segString(Directory*
 
   //initialize counter to 0
   counter = 0;
-  version = Misc::currentTimeMillis();
+  version = Misc::currentTimeMillis(true /* checkSourceDateEpoch */);
 	  if (reserveCount > 1)
 		  infos.reserve(reserveCount);
   }
@@ -762,7 +762,7 @@ string SegmentInfo::segString(Directory*
 
 		  if(format >= 0){// in old format the version number may be at the end of the file
 			  if (input->getFilePointer() >= input->length())
-  version = CL_NS(util)::Misc::currentTimeMillis(); // old file format without version number
+  version = CL_NS(util)::Misc::currentTimeMillis(true /* checkSourceDateEpoch */); // old file format without version number
 			  else
   version

Bug#1037113: Patch implementing this

2024-01-04 Thread Josh Triplett

tags 1037113 + patch
thanks

Submitted an MR on Salsa implementing this:
https://salsa.debian.org/debian/sm/-/merge_requests/3

Bug#1059986: dpkg: Please add hurd-arm64 case

2024-01-04 Thread Guillem Jover

Control: tag -1 moreinfo

Hi!

On Thu, 2024-01-04 at 12:35:58 +0100, Samuel Thibault wrote:
> Package: dpkg
> Version: 1.22.2
> Severity: normal
> User: debian-h...@lists.debian.org
> Usertags: hurd

> aarch64-gnu support is coming too :)

Yes, I noticed! :)

> Could you add a hurd-amd64 case in dpkg?

I've added hurd-arm64 support into the following branch:

https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/arch-hurd-arm64

but even though I've seen already some toolchain patches flying by,
AFAIUI there's still no GNU Mach support, so I think I'd prefer to
wait until that materializes, as per the FAQ entry on new ports. I
don't think this would block anything right now anyway, no?

BTW, I've assumed that port would also enable PIE by default in the
toolchain, if not, let me know and I can fix that up in the branch.

Thanks,
Guillem

Bug#1059860: ITP: golang-github-quic-go-quic-go -- A QUIC implementation in pure go

2024-01-04 Thread Jérémy Lal

Le mar. 2 janv. 2024 à 16:06, Jérémy Lal  a écrit :

>
>
> Le mar. 2 janv. 2024 à 15:27, Félix Sipma  a écrit :
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Félix Sipma 
>>
>> * Package name: golang-github-quic-go-quic-go
>>   Version : 0.40.0-1
>>   Upstream Author :
>> * URL : https://github.com/quic-go/quic-go
>> * License : Expat
>>   Programming Lang: Go
>>   Description : A QUIC implementation in pure go
>>
>>  A QUIC implementation in pure Go
>
>
> Already in debian.
> The upgrade will require more work, though.
>

Someone needs to deal with
https://github.com/golang/mock
being superseded by
https://github.com/uber-go/mock

Not sure of the right approach, asked on debian-go@lists.d.o

Bug#1060015: isenkram: Don't link to abandoned website

Source: isenkram
Version: 0.55

Please replace the URL at
https://salsa.debian.org/debian/isenkram/-/blob/master/NOTES#L12

A domain squatter has taken over the old site and their intentions may
be malicious.

Perhaps https://github.com/hughski could be used instead. Sadly, the
product is no longer sold or supported by its manufacturer.

Thank you,
Jeremy Bícha

Bug#1060014: RFS: logrotate/3.21.0-2 -- Log rotation utility

2024-01-04 Thread Christian Göttsche

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : logrotate
   Version  : 3.21.0-2
   Upstream contact : https://github.com/logrotate/logrotate/issues
 * URL  : https://github.com/logrotate/logrotate
 * License  : GPL-2, BSD-3-Clause, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/logrotate
   Section  : admin

The source builds the following binary packages:

  logrotate - Log rotation utility

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.21.0-2.dsc

Changes since the last upload:

 logrotate (3.21.0-2) unstable; urgency=medium
 .
   * d/control: bump to std version 4.6.2 (no further changes)
   * d/copyright: bump year
   * d/patches: set Forwarded header
   * debian: install systemd units via dh_installsystemd (Closes: #105)

Regards,
   Christian Göttsche

Bug#1059953: libceres3: ceres-solver built without CUDA support

2024-01-04 Thread Kip Warner

On Thu, 2024-01-04 at 16:17 +0100, Francois Mazen wrote:
> The nvidia-cuda-dev package is part of the non-free area in the
> Debian archive [1] because if does not comply with the DFSG [2].
> If we set it as a build dependency of ceres-solver (and also the
> nvidia runtime as a package dependency), it would move ceres-solver
> from the "main" area to the "contrib" area of the Debian archive [3]
> which is likely unwanted.

Perhaps another option is having a libceres-cuda-dev / libceres3-cuda
packages that are built with CUDA?

-- 
Kip Warner
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1052000: logrotate systemd timer should run hourly rather than daily

2024-01-04 Thread Christian Göttsche

control: tags 1052000 wontfix

For the default interval daily seems to be in my opinion the right choice.
I am not aware of other distributions using different intervals.
Also there might be conflicts with third party configuration snippets
(causing unwanted load, too short retention period).
Users are always free to override the systemd unit or cronjob to
adjust to their specific use case.

Bug#1060013: apktool: CVE-2024-21633