date:20230118

On Wed, Jan 18, 2023 at 12:50:15PM +0200, Graham Inggs wrote:
> Control: severity -1 serious
> Control: tags -1 + ftbfs
> 
> Hi Maintainer and i386, arm, mips porters
> 
> > As far as I can tell, the reason is that coreutils now uses a 64-bit
> > time_t and functions with a "64" suffix. Datefudge however does not
> > expose nor implement such functions.
> 
> As can be seen on reproducible builds [1], datefudge now FTBFS on at
> least i386 and armhf, and I was able to confirm the failure on the
> mipsel porterbox.
> 
> As datefudge is a build-dependency of gnutls28 and oath-toolkit, both
> key packages, how should this be resolved?

I'd start by asking how many implementations of this functionality we 
ship, and whether all of them have the same problem.

faketime has more users and an upstream, but the same problem.

Adding the missing functionality to one implementation (faketime?)
and ensuring there are RC bugs against all other implementations
(are there other ones apart from datefudge?) would be my suggestion.

Users of unfixed implementations could then migrated to fixed ones.

> Regards
> Graham
>...

cu
Adrian

Bug#1029178: vtk-dicom: autopkgtest failure

On Wed, Jan 18, 2023 at 11:29:35PM +0100, Sebastian Ramacher wrote:
> Source: vtk-dicom
> Version: 0.8.14-3
> Severity: serious
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtk-dicom/30492694/log.gz
> 
> autopkgtest [23:14:01]: test autodep8-python3: set -e ; for py in 
> $(py3versions -d 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with 
> $py:" ; $py -c "import vtkdicom; print(vtkdicom)" ; done
> autopkgtest [23:14:01]: test autodep8-python3: [---
> Testing with python3.10:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/vtkdicom/__init__.py", line 1, in 
> 
> from .vtkDICOM import *
> ModuleNotFoundError: No module named 'vtkdicom.vtkDICOM'

I don't see how this is the fault of the package,
or something the package could easily address.[1]

The package builds a Python C extension against the default Python3 
version only.

The autopkgtest tests this extension against the default Python3 version.

With python3/unstable the autopkgtest is passing:
https://ci.debian.net/packages/v/vtk-dicom/

Testing against a different python3 default fails for obvious reasons.

> Cheers

cu
Adrian

[1] Building a Python C extension against multiple Python3 versions is 
easy for packages that build nothing else, but usually hard (and 
rarely done) for packages that build Python bindings for a C/C++
library as part of their normal build process.

Bug#1029184: NTP server address provided during initial Debian installation is not used by the running system

2023-01-18 Thread Al Watts

Package: clock-setup
Version: 0.155
Severity: important

The user-provided NTP server address (in this case a 10(dot) IP address) 
provided during the initial Debian installation is not used by 
systemd-timesyncd in the running system. This has been noted on systems 
installed from Debian 11 NetInst images.

On systems with outbound network restrictions, this results in the clock never 
becoming synchronised, and log messages being reported in /var/log/syslog that 
requests to debian.pool.ntp.org servers are timing out.

/etc/systemd/timesyncd.conf appears to be unchanged from the default packaged 
config file, with all lines commented out.

A work around is to manually adjust the config after installation, however 
people unfamiliar with the bug (myself included until very recently) will 
likely not think to check, believing this has already been covered off during 
the Debian installation.

Bug#1029138: linux-image-6.1.0-1-amd64: refcount_t: underflow; use-after-free in nfsd on a NFS server

2023-01-18 Thread Salvatore Bonaccorso

Hi Laurent,

On Wed, Jan 18, 2023 at 04:59:45PM +0100, Laurent Bonnaud wrote:
> On 1/18/23 16:46, Salvatore Bonaccorso wrote:
> 
> > Would it be possible to test 6.1.7, which contains related nfs changes
> > with the nfsd filecache?
> 
> Yes, of course, as soon as it is available as a Debian package...

Ok! 6.1.7-1 has been uploaded now to unstable, so builds should be
triggered. If you can test it with that that would then be great to
know if the issue persist.

Regards,
Salvatore

Bug#1029183: python-pgspecial: Dependency and build dependency must be updated to python3-psycopg3 -> python3-psycopg

Source: python-pgspecial
Version: 2.0.1-1
Severity: serious
Tags: ftbfs
Control: affects -1 python3-pgspecial

python3-psycopg3 does not exist anymore, see #1016031.

Bug#921187: IRT: backports for Xen

2023-01-18 Thread Elliott Mitchell

>From looking, it doesn't appear necessary to remove the dependency of
QEMU on libxenmiscX.YY to make backports possible.  According to DPKG,
multiple versions of libxenmisc can be installed at the same time, so
the issue is simply whether multiple versions of QEMU can be installed
at the same time.

Last time I tried, it was /almost/ possible to install the testing
version of Xen on an otherwise stable system.  The only dependency issue
was the testing version of Xen needed an incompatible version of libc.

Backports already look 99% possible.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1029182: pgcli: Dependency needs updating python3-psycopg3 -> python3-psycopg

Package: pgcli
Version: 3.5.0-3
Severity: serious

python3-psycopg3 does not exist anymore, see #1016031.

Bug#1026499: rows: diff for NMU version 0.4.1-5.1

On Wed, Jan 18, 2023 at 10:44:23PM -0300, Antonio Terceiro wrote:
> On Wed, Jan 18, 2023 at 06:27:59PM +0200, Adrian Bunk wrote:
> > Control: tags 1026499 + patch
> > Control: tags 1026499 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for rows (versioned as 0.4.1-5.1) and uploaded
> > it to DELAYED/14. Please feel free to tell me if I should cancel it.
> 
> I'm about to upload a new upstream snapshot that will close this bug, so
> I think you can cancel it. Thanks for looking into the package, though.

Thanks, I've canceled mine.

cu
Adrian

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

2023-01-18 Thread Dominique Martinet

Hi Simon,

Dominique Martinet wrote on Mon, Nov 28, 2022 at 11:47:07AM +0900:
> > I've added it to .
> 
> Thank you!

Just a follow-up on this proposed updates mechanism -- it looks like
this wasn't included in the december 11.6 point update (as expected,
since we agreed to let it be tested for a bit), is there anything I
should/can do to make sure the next 11.7 gets gtk+3.0 3.24.34-5, or is
that still too early?

(there doesn't seem to be any plan for 11.7 yet, release.debian.org says
"maybe mid-February", but I assume it will be harder to justify adding
it once bookworm is released in a few more months and bullseye gets
branded oldstable so next release sounds optimal for me)


Thank you,
-- 
Dominique

Bug#1029181: mirror submission for mirror.yer.az

2023-01-18 Thread YER Hosting

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.yer.az
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: YER Hosting 
Country: AZ Azerbaijan
Location: Baku, Azerbaijan
Sponsor: YER Hosting https://yer.az
Comment: https://mirror.yer.az/debian/




Trace Url: http://mirror.yer.az/debian/project/trace/
Trace Url: http://mirror.yer.az/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.yer.az/debian/project/trace/mirror.yer.az

Bug#1028452: unblock: golang-1.19/1.19.5-1

2023-01-18 Thread Shengjing Zhu

Control: reopen -1
Control: retitle -1 [pre-approval] unblock: golang-1.19/1.19.5-1

Hi,

On Thu, Jan 19, 2023 at 3:45 AM Debian Bug Tracking System

> On Thu, 12 Jan 2023 16:28:51 +0100 Paul Gevers  wrote:
> > But golang-1.19 is in sync between unstable and testing.
>
> Closing.
>
> Paul

Sorry not to make it clear. It's a pre-approval request.

-- 
Shengjing Zhu

Bug#1026499: rows: diff for NMU version 0.4.1-5.1

2023-01-18 Thread Antonio Terceiro

On Wed, Jan 18, 2023 at 06:27:59PM +0200, Adrian Bunk wrote:
> Control: tags 1026499 + patch
> Control: tags 1026499 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for rows (versioned as 0.4.1-5.1) and uploaded
> it to DELAYED/14. Please feel free to tell me if I should cancel it.

I'm about to upload a new upstream snapshot that will close this bug, so
I think you can cancel it. Thanks for looking into the package, though.


signature.asc
Description: PGP signature

Bug#1026231: debian-policy: document droppage of support for legacy locales

2023-01-18 Thread Russ Allbery

Anthony Fok  writes:

> I'm not asking you to spend any time working on GB18030; that would be
> the job of Debian Chinese i18n/L10n team as well as the wider community
> (glibc, libiconv, Qt, etc.)  All I am asking you is to maintain the
> status quo, and don't discount anything other than UTF-8 as legacy.

This topic comes up a lot, and I'd love to put something in either Policy
or the Developer's Reference proactively to at least explain what we know
about what our users need and to point people at the right questions to
ask if it's been another decade and they want to standardize on UTF-8
again.  Do you have an idea of something suitable we should say?

I do think we probably should say more *somewhere* about making UTF-8 the
default choice in most situations if you otherwise have no reason to
choose anything specific.  For example, as you point out, files written in
Chinese for Chinese people may or may not want to use UTF-8, but at this
point I do think anything written in, say, French or German probably
should just use UTF-8.  Also, file names in the file system shipped in
Debian packages probably should use UTF-8 since there's no way to declare
the character set and there are some solid reasons for picking one and
sticking with it.  (Obviously, users can create files with any character
set they want.)

> Debian already supports GB 18030-2000 (or GB 18030-2005) rather well.

How do I configure a locale that uses this as the default character set?
I'd like to be able to test this configuration (at least for my own
packages), but since recent changes to locales it doesn't appear to be an
option in debconf and I was confused trying to figure out how I should
make it work.

-- 
Russ Allbery (r...@debian.org)

Bug#1028957: librocrand-dev: rocrand_INCLUDE_DIR does not exist

2023-01-18 Thread Cordell Bloor



On 1/18/23 15:03, Étienne Mollier wrote:

2. The symbol tracking needs to be reviewed by somebody more experienced
than me. I think that anything in the rocrand::detail or
rocrand_host::detail namespace should be marked optional, as those symbols
are not intended for use by library users.

Ideally they should not be exposed (by the mean the build flag
-fvisibility=hidden allows, but I'm not sure of implementation
details on upstream side to be honest).  If the symbols are not
part of the public interface but still referenced, but we are
sure they are unused by reverse dependencies, they probably can
be marked (optional).  The library soversion suggests the stable
part of the ABI should not have had a breakage, so I guess the
(optional) marker is fine.


After further thought, I've added a patch to hide the kernels by marking 
them as static and removed all optional symbols from the symbol 
tracking. The ABI is a lot easier to verify with all that junk hidden.



I wanted to take that opportunity to stabilize the test suite of
rocm-hipamd, but I'm currently failing on:

test 103
Start 103: directed_tests/ipc/hipMultiProcIpcMem--N4.tst

103: Test command: /<>/obj-x86_64-linux-gnu/directed_tests/ipc/hipMultiProcIpcMem " 
" "--N" "4"
103: Working Directory: /<>/obj-x86_64-linux-gnu
103: Environment variables:
103:  HIP_PATH=/<>/obj-x86_64-linux-gnu
103: Test timeout computed to be: 1500
103: KFD does not support xnack mode query.
103: ROCr must assume xnack is disabled.
103: error: 'hipErrorInvalidDevicePointer'(17) from hipIpcGetMemHandle(_handle, 
ipc_offset_dptr) at /<>/hip/tests/src/ipc/hipMultiProcIpcMem.cpp:55
103: error: API returned error code.
103: error: TEST FAILED
103:
103/414 Test #103: directed_tests/ipc/hipMultiProcIpcMem--N4.tst 
...Subprocess
 aborted***Exception: 792.07 sec

A later test then crashes:

test 126
Start 126: directed_tests/printf/hipPrintfManyWaves.tst

126: Test command: 
/<>/obj-x86_64-linux-gnu/directed_tests/printf/hipPrintfManyWaves " 
"
126: Working Directory: /<>/obj-x86_64-linux-gnu
126: Environment variables:
126:  HIP_PATH=/<>/obj-x86_64-linux-gnu
126: Test timeout computed to be: 1500
126: KFD does not support xnack mode query.
126: ROCr must assume xnack is disabled.
126: Memory access fault by GPU node-1 (Agent handle: 0x562e8fbb1e00) 
on address (nil)(may not be exact address). Reason: DRAM ECC failure.
126: Nearby memory map:
126: 0x7f549780, 0x78c000, System
126: 0x7f549ac0, 0x10, VRAM
126: 0x7f549af0, 0x8, System
126:
126: PtrInfo:
126:Address: 
0x7f549780-0x7f5497f8c000/0x7f549780-0x7f5497f8c000
126:Size: 0x78c000
126:Type: 1
126:Owner: 0x562e8fbac4b0
126:CanAccess: 1
126:0x562e8fbb1e00
126:In block: 0x7f549780, 0x78c000
126: PtrInfo:
126:Address: 
0x7f549ac0-0x7f549ad0/0x7f549ac0-0x7f549ad0
126:Size: 0x10
126:Type: 1
126:Owner: 0x562e8fbb1e00
126:CanAccess: 1
126:0x562e8fbb1e00
126:In block: 0x7f549ac0, 0x20
126: PtrInfo:
126:Address: 
0x7f549af0-0x7f549af8/0x7f549af0-0x7f549af8
126:Size: 0x8
126:Type: 1
126:Owner: 0x562e8fbac4b0
126:CanAccess: 1
126:0x562e8fbb1e00
126:In block: 0x7f549af0, 0x8
126: hipPrintfManyWaves: ./src/core/runtime/runtime.cpp:1276: static bool 
rocr::core::Runtime::VMFaultHandler(hsa_signal_value_t, void*): Assertion `false && 
"GPU memory access fault."' failed.
126/414 Test #126: directed_tests/printf/hipPrintfManyWaves.tst 
Subprocess
 aborted***Exception:   0.64 sec

That's unfortunate. It can be quite difficult to tell why these things fail.

About at the same time as #126 I get a kernel NULL pointer
dereference:

amdgpu: sq_intr: error, se 2, data 0x25, sh 0, priv 0, wave_id 0, 
simd_id 0, cu_id 0, err_type 4
amdgpu :0b:00.0: amdgpu: RAS poison consumption, unmap queue flow 
succeeded: client id 10
BUG: kernel NULL pointer dereference, address: 01b0
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 206 Comm: kworker/7:1H Not tainted 6.1.0-1-amd64 #1  Debian 
6.1.4-1
Hardware name: Gigabyte Technology Co., Ltd. X570 UD/X570

Bug#1017487: ITP: sphinx-design -- sphinx extension for designing beautiful, screen-size responsive web components

2023-01-18 Thread Drew Parsons


Control: affects -1 src:scipy

scipy 1.10 has started using sphinx-design for its docs.  The scipy doc 
build is a bit crippled without this package.

Bug#1027143: openimageio: CVE-2022-43592 CVE-2022-43593 CVE-2022-43594 CVE-2022-43595 CVE-2022-43596 CVE-2022-43597 CVE-2022-43598 CVE-2022-43599 CVE-2022-43600 CVE-2022-43601 CVE-2022-43602 CVE-2022-


The direct reverse dependencies all build fine with 2.4.7.1+dfsg-1, so we can 
ask for the transition.

Bug#1027244: Are we still trying to do scipy 1.10, given transition freeze?

2023-01-18 Thread Drew Parsons


On 2023-01-18 22:31, Rebecca N. Palmer wrote:


This "broken by numpy 1.24" bug looks to me like 17033, not 17630.
This has what looks like a trivially-backportable patch, though I
haven't actually tried that:
https://github.com/scipy/scipy/pull/17035


We can try applying that patch to scipy 1.8 and see if it fixes test 
failures.



Given that the transition freeze was on 2023-01-12, it's too late to
move to scipy 1.10 if that's likely to cause significant breakage.
(Do we have a guess of whether it will, or do we need a package that
builds in experimental to test that?)


It's a good question. I figure it wouldn't be much worse than switching 
the default python to 3.11 two weeks before freeze.  A handful of 
deprecated functions got removed, likely some package will break but it 
is probably fixable. But best to upload to experimental first.




The scipy 1.10 FTBFS in salsa (
https://salsa.debian.org/python-team/packages/scipy/-/pipelines/486634
) is it trying to download test data, which isn't allowed for a
build-time test.  We could make those tests autopkgtest-only, or if
the data is reasonably sized, add it to the package: Pooch can use a
local cache.
https://sources.debian.org/src/pooch/1.6.0-2/README.rst/


pooch is used for scipy.datasets, which is a new scipy submodule. As 
such it's fair enough to just skip those new tests if necessary. 
Skipping at build-time is simpler than caching, though the cached 
dataset tests are light (the downloaded datasets are not so large, 3 
files 1.9M total) The default cache is ${HOME}/.cache/scipy-data, we'd 
need to learn how to point it at, say, debian/scipy-data instead.


The 3 files in question are defined in datasets/_registry.py,

registry_urls = {
"ascent.dat": 
"https://raw.githubusercontent.com/scipy/dataset-ascent/main/ascent.dat;,
"ecg.dat": 
"https://raw.githubusercontent.com/scipy/dataset-ecg/main/ecg.dat;,
"face.dat": 
"https://raw.githubusercontent.com/scipy/dataset-face/main/face.dat;

}

The test_data tests that break (with no internet or cache) are
  test_existence_all
  test_ascent
  test_face
  test_electrocardiogram

If we're in a rush because of the freeze then skipping these tests at 
build-time is reasonable.


Drew

Bug#909567: ITP: opensnitch -- Port of the Little Snitch application firewall

2023-01-18 Thread Petter Reinholdtsen

I would be happy to assist too, if you need help.  Ping me on IRC, for
example.

My sponsoring preferences are available from
http://www.hungry.com/~pere/debian-sponsoring.html >.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1029180: autodep8: generate openssl dependency for autopkgtest-pkg-dkms

2023-01-18 Thread Andreas Beckmann

Package: autodep8
Version: 0.28
Severity: normal
Tags: patch

Hi,

please generate a Depends: openssl for autopkgtest-pkg-dkms s.t. dkms
can generate a self signed certificate and sign the modules.


Andreas
>From f9141188083c506c2e27a21fe99ee1ba868a Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Wed, 18 Jan 2023 23:57:35 +0100
Subject: [PATCH] autopkgtest-pkg-dkms: generate Depends: openssl for signing
 modules

---
 support/dkms/generate | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/support/dkms/generate b/support/dkms/generate
index 16bbb3a..59e0584 100755
--- a/support/dkms/generate
+++ b/support/dkms/generate
@@ -3,7 +3,7 @@
 cat <

Bug#1026231: debian-policy: document droppage of support for legacy locales

2023-01-18 Thread Anthony Fok

Hello,

On Mon, Dec 19, 2022 at 2:48 PM Bill Allombert  wrote:
> Which raise the question: does the corresponding user group moved to UTF-8 ?
> Judging from ,
> neither Chinese nor Japanese users have overwhelmingly moved to UTF-8,
> so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP.

Bill, thank you, thank you, thank you!  You speak the voice of reason!

Adam, we living in the West may think of BIG5, GB18030 and EUC-JP as
legacy/obsolete encodings, but in Mainland China, GB18030 is anything
but legacy.  It is a mandatory national standard that has recently
been brought up to date in GB 18030-2022, synchronizing with ISO/IEC
10646:2017 (equivalent to Unicode version 11.0).

"GB 18030 is a national standard with stringent conformance
requirements that regulate eligibility for products or services to be
sold in China."  I personally went through this trying to get the now
defunct ThizLinux distro GB 18030-2000 conformant 20 years ago.  GB
18030-2022 will become mandatory on 2023-08-01.  Why the urgency?  To
add support 17000+ rarer CJK Han characters found in people's and
place names, as well as improving support for minor ethnic languages
in China.  And the GB18030 standard committee is really serious about
promoting GB18030 because they are eager to resolve some real issues
of "missing characters" that are negatively affecting the people
living in China.  To my pleasant surprise, they are putting out a
public lecture webinar series that explains the why and the how of
implementing GB 18030-2022, with the 3rd video published on
2022-12-30.  In their mind, GB 18030 encompasses a lot more than just
a character encoding mapping table.  It is the full support package
(including fonts, display, printing, input methods, etc.) for Han
Chinese and all other minority languages used in China.

See e.g. the following excellent articles for more information:

 * https://ken-lunde.medium.com/the-gb-18030-2022-standard-3d0ebaeb4132
 * https://www.unicode.org/L2/L2022/22274-disruptive-changes.pdf

Even though Debian is not proprietary/commercial software, the GB
18030 authority highly recommends that free/libre and open-source
software _do_ implement GB 18030-2022.  That's especially true
considering the fact that vendors in China may be offering Debian as a
solution for clients, but they would be prevented from doing so if
Debian Policy spells out "We support UTF-8 and UTF-8 only.  Think of
all the ARM and RISC-V single-board computers made in China where
Debian is the default OS image; Debian or derivatives (Ubuntu, Ubuntu
Kylin, etc.) that are pre-installed on PCs sold in China, etc.

As a matter of fact, I have been recently approached recently to
update the IANA charset technical summary for "GB18030" (i.e. the
original GB 18030-2000) in
https://www.iana.org/assignments/charset-reg/GB18030 with the latest
updates for GB 18030-2022.  (Haha, I am starting to fret about it
because I am no expert in GB18030, but many thanks to e.g. Dr. Ken
Lunde, the expert in CJKV information processing, who has kindly
allowed me to borrow any of his articles in updating the IANA charset
documentation for GB18030.

I'm not asking you to spend any time working on GB18030; that would be
the job of Debian Chinese i18n/L10n team as well as the wider
community (glibc, libiconv, Qt, etc.)  All I am asking you is to
maintain the status quo, and don't discount anything other than UTF-8
as legacy.  Debian already supports GB 18030-2000 (or GB 18030-2005)
rather well.  Don't let that existing support die!  If anything, we'd
need to improve GB18030 support to conform with GB 18030-2022, though
thankfully much of that work would likely come from upstream projects
or from Debian derivatives or other distros that are actually selling
their products in China.

Many thanks for your understanding!

Kind regards,

Anthony Fok

Bug#1007002: Update Documentation

2023-01-18 Thread Soren Stoutner

Thank you.

On Wednesday, January 18, 2023 2:47:01 PM MST Axel Beckert wrote:
> But I'll at least try to update doc/lintian.rst so that at least the
> content is ready once we can update the website again.

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1028372: ncat: Please lower alternative priority below nc.traditional

2023-01-18 Thread Hilko Bengen

* Arnaud Rebillout:

> We have users in Kali Linux who have been beaten by this. They use nc,
> they also need ncat for the extra options it provides, they install it,
> and then are very surprised that nc is now ncat. From their background
> (I'm talking about professional pentesters), nc and ncat are different
> tools, they really don't expect ncat to replace nc.

I'd like to see in what way people have been irritateed. Can you link to
specific bug reports or mailing list/form discussions?

Cheers,
-Hilko

Bug#819332: closed by Debian FTP Masters (reply to Helmar Gerloni ) (Bug#819332: fixed in tuxguitar 1.5.6+dfsg1-1)

2023-01-18 Thread Jérôme

Thank you so much, Helmar and Tony for taking care of this!

-- 
Jérôme

Bug#1029179: relion-cuda: rebuild for libtiff6 transition

2023-01-18 Thread Sebastian Ramacher

Source: relion-cuda
Version: 3.1.3-1
Severity: serious
Tag: sid bookworm

relion-cuda requires a rebuild for the libtiff5 -> libtiff6 transition.

Cheers
-- 
Sebastian Ramacher

Bug#1029127: context: manual has non-free files

2023-01-18 Thread Hilmar Preuße


Am 18.01.2023 um 20:29 teilte Bastian Germann mit:

Am 18.01.23 um 20:20 schrieb Hilmar Preuße:

Am 18.01.2023 um 11:52 teilte Bastian Germann mit:

Am 18.01.23 um 11:21 schrieb Hilmar Preuße:


Hi,


Do you have a list of these files or do you know how to generate one?


grep -r licence=cc-by-nc-sa


This gives a lot of TeX input files should I remove them?


Yes. But please make the repack reproducible. The easiest way is to convert
the debian/copyright file to the machine-readable format and use
Files-Excluded.


As we don't get tar balls from upstream, the most easy way would be to
edit the make-orig-tar and exclude the files there. I'll try to look
into that further ASAP.

Hilmar
--
sigfault

Bug#1029178: vtk-dicom: autopkgtest failure

2023-01-18 Thread Sebastian Ramacher

Source: vtk-dicom
Version: 0.8.14-3
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtk-dicom/30492694/log.gz

autopkgtest [23:14:01]: test autodep8-python3: set -e ; for py in $(py3versions 
-d 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import vtkdicom; print(vtkdicom)" ; done
autopkgtest [23:14:01]: test autodep8-python3: [---
Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/vtkdicom/__init__.py", line 1, in 

from .vtkDICOM import *
ModuleNotFoundError: No module named 'vtkdicom.vtkDICOM'

Cheers
-- 
Sebastian Ramacher

Bug#1028957: librocrand-dev: rocrand_INCLUDE_DIR does not exist

2023-01-18 Thread Étienne Mollier

Hi Cory,

Cordell Bloor, on 2023-01-18:
> I've updated the rocrand package sources on Salsa to rocrand 5.3.3 and
> transformed it into a MUT package. I've confirmed that the resulting library
> works correctly using it to configure rocfft 5.4.2 (which was how I
> discovered this bug originally).

Thanks for this, I begun doing the same yesterday, but shifted
my attention to rocm-hipamd for the reason you mention below.

> rocrand 5.3.3-1 just needs three things to be ready for upload:
> 
> 1. The d/copyright file needs to be updated for the new version.

Acknowledged, note for later: notably there is the inclusion of
the hipRAND directory to check.  (I'll be travelling this week
end so won't be much reactive until next week.)

> 2. The symbol tracking needs to be reviewed by somebody more experienced
> than me. I think that anything in the rocrand::detail or
> rocrand_host::detail namespace should be marked optional, as those symbols
> are not intended for use by library users.

Ideally they should not be exposed (by the mean the build flag
-fvisibility=hidden allows, but I'm not sure of implementation
details on upstream side to be honest).  If the symbols are not
part of the public interface but still referenced, but we are
sure they are unused by reverse dependencies, they probably can
be marked (optional).  The library soversion suggests the stable
part of the ABI should not have had a breakage, so I guess the
(optional) marker is fine.

> 3. The rocm-hipamd 5.2.3-3 package needs to be uploaded or
> libclang-rt-15-dev must be added to the rocrand build dependencies.

I wanted to take that opportunity to stabilize the test suite of
rocm-hipamd, but I'm currently failing on:

test 103
Start 103: directed_tests/ipc/hipMultiProcIpcMem--N4.tst

103: Test command: 
/<>/obj-x86_64-linux-gnu/directed_tests/ipc/hipMultiProcIpcMem " " 
"--N" "4"
103: Working Directory: /<>/obj-x86_64-linux-gnu
103: Environment variables: 
103:  HIP_PATH=/<>/obj-x86_64-linux-gnu
103: Test timeout computed to be: 1500
103: KFD does not support xnack mode query.
103: ROCr must assume xnack is disabled.
103: error: 'hipErrorInvalidDevicePointer'(17) from 
hipIpcGetMemHandle(_handle, ipc_offset_dptr) at 
/<>/hip/tests/src/ipc/hipMultiProcIpcMem.cpp:55
103: error: API returned error code.
103: error: TEST FAILED
103: 
103/414 Test #103: directed_tests/ipc/hipMultiProcIpcMem--N4.tst 
...Subprocess
 aborted***Exception: 792.07 sec

A later test then crashes:

test 126
Start 126: directed_tests/printf/hipPrintfManyWaves.tst

126: Test command: 
/<>/obj-x86_64-linux-gnu/directed_tests/printf/hipPrintfManyWaves 
" "
126: Working Directory: /<>/obj-x86_64-linux-gnu
126: Environment variables: 
126:  HIP_PATH=/<>/obj-x86_64-linux-gnu
126: Test timeout computed to be: 1500
126: KFD does not support xnack mode query.
126: ROCr must assume xnack is disabled.
126: Memory access fault by GPU node-1 (Agent handle: 0x562e8fbb1e00) 
on address (nil)(may not be exact address). Reason: DRAM ECC failure.
126: Nearby memory map:
126: 0x7f549780, 0x78c000, System
126: 0x7f549ac0, 0x10, VRAM
126: 0x7f549af0, 0x8, System
126: 
126: PtrInfo:
126:Address: 
0x7f549780-0x7f5497f8c000/0x7f549780-0x7f5497f8c000
126:Size: 0x78c000
126:Type: 1
126:Owner: 0x562e8fbac4b0
126:CanAccess: 1
126:0x562e8fbb1e00
126:In block: 0x7f549780, 0x78c000
126: PtrInfo:
126:Address: 
0x7f549ac0-0x7f549ad0/0x7f549ac0-0x7f549ad0
126:Size: 0x10
126:Type: 1
126:Owner: 0x562e8fbb1e00
126:CanAccess: 1
126:0x562e8fbb1e00
126:In block: 0x7f549ac0, 0x20
126: PtrInfo:
126:Address: 
0x7f549af0-0x7f549af8/0x7f549af0-0x7f549af8
126:Size: 0x8
126:Type: 1
126:Owner: 0x562e8fbac4b0
126:CanAccess: 1
126:0x562e8fbb1e00
126:In block: 0x7f549af0, 0x8
126: hipPrintfManyWaves: ./src/core/runtime/runtime.cpp:1276: static 
bool rocr::core::Runtime::VMFaultHandler(hsa_signal_value_t, void*): Assertion 
`false && "GPU memory access fault."' failed.
126/414 Test #126: directed_tests/printf/hipPrintfManyWaves.tst 
Subprocess
 aborted***Exception:   0.64 sec

About at the same time as #126 I get a kernel NULL pointer
dereference:

amdgpu: sq_intr: error, se 2, data 0x25, sh 0,

Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

2023-01-18 Thread Martin

Control: severity -1 grave

Justification for grave: Crashes Gajim for some users. RC, IMHO.

On 2023-01-17 21:56, Sebastian Reichel wrote:
> I just got the new package through testing and now gajim segfaults
> ony my system with stacktrace pointing to libproxy. So this is not
> magically solved.

:-(

Could you check, if a downgrade to libproxy 0.4.15-15 helps?
That certainly helps to find the bug!

Thank you!

Bug#1027244: Are we still trying to do scipy 1.10, given transition freeze?

2023-01-18 Thread Rebecca N. Palmer


Control: tags -1 fixed-upstream patch
Control: forwarded -1 https://github.com/scipy/scipy/pull/17033

This "broken by numpy 1.24" bug looks to me like 17033, not 17630.  This 
has what looks like a trivially-backportable patch, though I haven't 
actually tried that:

https://github.com/scipy/scipy/pull/17035

Given that the transition freeze was on 2023-01-12, it's too late to 
move to scipy 1.10 if that's likely to cause significant breakage.  (Do 
we have a guess of whether it will, or do we need a package that builds 
in experimental to test that?)


The scipy 1.10 FTBFS in salsa ( 
https://salsa.debian.org/python-team/packages/scipy/-/pipelines/486634 ) 
is it trying to download test data, which isn't allowed for a build-time 
test.  We could make those tests autopkgtest-only, or if the data is 
reasonably sized, add it to the package: Pooch can use a local cache.

https://sources.debian.org/src/pooch/1.6.0-2/README.rst/

Bug#1007002: Update Documentation

2023-01-18 Thread Axel Beckert

Control: clone -1 -2
Control: retitle -2 lintian: Update Lintian User's Manual wrt. to Pointed Hints 
format
Control: tags -2 - wontfix + confirmed

Hi Soren,

Soren Stoutner wrote:
> It would probably be helpful to update the documentation at 
> https://lintian.debian.org/manual/index.html#format-of-override-files[1] to 
> describe the new pointed hints format.

Indeed. We though have the issue that lintian.debian.org no more
updates. It's future is unclear, unfortunately. I do not have access
there. :-/

And it's also not yet my focus currently. After the freeeze maybe.

But I'll at least try to update doc/lintian.rst so that at least the
content is ready once we can update the website again.

This is also related to https://bugs.debian.org/1004234 (docs: give
advice how to debug overrides).

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

Bug#1029055: Debian Expat and SPDX MIT License Text

2023-01-18 Thread Axel Beckert

Control: tag -1 + confirmed - moreinfo

Hi,

Richard Fontana wrote:
> > Just the point of what the meaning of _text colors_
> > *rollingeyes* in a license do mean. I just ignored them and then those
> > two licenses differ.
> >
> > > as to if the Debian MIT (Expat) License is
> > > the same as the SPDX MIT License.
> > […]
> > > Can somebody at Debian Legal please comment?
> >
> > Yes, thanks! I'd prefer to have a good explanation, too.
> >
> > Please also note that I didn't mark the bug report as wontfix, just as
> > moreinfo.
> 
> The SPDX definition of "MIT" is given in
> https://github.com/spdx/license-list-XML/blob/main/src/MIT.xml

Thanks a lot. The fact that what is blue in the rendering is caused
by an XML tag called  explains well its meaning

> Based on a lot of experience now, you really have to consult the XML
> files rather than rely on the convenience publication of license texts
> at https://spdx.org/licenses

Seems so. Wasn't aware of them either.

> Based on that, and https://www.debian.org/legal/licenses/mit, and
> https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/
> 
> I think the answer is that what Debian calls "MIT (Expat)" on that
> page matches what SPDX calls "MIT"

Ok. What I take away is that Debian's "MIT License (Expat)" is the
same as SPDX's "MIT License" without the optional parts.

> (I don't think they are "the same" because the underlying concepts
> of what a license is and so forth are not the same).

Interesting. But I don't want to go into that rabbit hole. :-)_

Soren Stoutner wrote:
> Thanks Richard.  I was unaware of the XML versions.

Me too.

> So, this would mean that SPDX considers what Debian calls the MIT (Expat) 
> license to match what SPDX calls MIT because the differences are all either 
> considered by SPDX to be omittable

Yes.

> or replaceable

Not really. :-)

> as demonstrated by the tags in the XML file and the text colors in
> the HTML version.

Yep, that XML version really helped to understand the semantics of the
colors in SPDX's HTML rendering.

But even if they're still not the same as such, it indeed makes no
sense that Lintian argues about them being different. So I'll fix this
bug report with the next upload. (Which likely happens once Lintian 2.116.0
has migrated to Testing.)

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

Bug#1029176: dhcpcd: "Main" process killed by systemd

2023-01-18 Thread Beat Bolli

Package: dhcpcd
Version: 9.4.1-13
Severity: important

Dear Maintainer,

Since the most recent update I'm no longer able to use dhcpcd. I'm not
sure if there's an interaction with systemd and/or seccomp.

dhcpcd is killed after an audit event regarding syscall #318:

2023-01-18T09:05:44.299064+01:00 zbox kernel: [10110.299013] audit: type=1326 
audit(1674029144.292:13): \
auid=4294967295 uid=120 gid=65534 ses=4294967295 subj=unconfined pid=16134 \
comm="dhcpcd" exe="/usr/sbin/dhcpcd" sig=31 arch=c03e syscall=318 
compat=0 ip=0x7fec5af9a045 code=0x0

According to /usr/include/x86_64-linux-gnu/asm/unistd_64.h, this syscall
number is getrandom(), which should be allowed by the @system-service
SystemCallFilter in /lib/systemd/system/dhcpcd.service. Disabling the
SystemCallFilter or changing it to @known doesn't improve the situation.

This is a complete syslog extract showing one failed start of dhcpcd:

2023-01-18T09:05:44.284259+01:00 zbox dhcpcd[16132]: dhcpcd-9.4.1 starting
2023-01-18T09:05:44.285906+01:00 zbox dhcpcd[16135]: dev: loaded udev
2023-01-18T09:05:44.286005+01:00 zbox dhcpcd[16135]: ps_dropprivs: chroot: 
/usr/lib/dhcpcd: Operation not permitted
2023-01-18T09:05:44.286278+01:00 zbox dhcpcd[16132]: ps_dropprivs: chroot: 
/usr/lib/dhcpcd: Operation not permitted
2023-01-18T09:05:44.286351+01:00 zbox dhcpcd[16132]: ps_dropprivs: chroot: 
/usr/lib/dhcpcd: Operation not permitted
2023-01-18T09:05:44.286400+01:00 zbox dhcpcd[16135]: ps_dropprivs: chroot: 
/usr/lib/dhcpcd: Operation not permitted
2023-01-18T09:05:44.286459+01:00 zbox dhcpcd[16135]: DUID 
00:04:03:00:02:00:04:00:05:00:00:06:00:07:00:08:00:09
2023-01-18T09:05:44.296952+01:00 zbox dhcpcd[16135]: eth0: IAID 2e:4e:fe:b6
2023-01-18T09:05:44.297026+01:00 zbox dhcpcd[16135]: ps_ctl_listen: read: 
Success
2023-01-18T09:05:44.297081+01:00 zbox dhcpcd[16135]: ps_ctl_recv: read: Success
2023-01-18T09:05:44.297172+01:00 zbox systemd[1]: dhcpcd.service: Main process 
exited, code=killed, status=31/SYS
2023-01-18T09:05:44.299064+01:00 zbox kernel: [10110.299013] audit: type=1326 
audit(1674029144.292:13): \
auid=4294967295 uid=120 gid=65534 ses=4294967295 subj=unconfined pid=16134 \
comm="dhcpcd" exe="/usr/sbin/dhcpcd" sig=31 arch=c03e syscall=318 
compat=0 ip=0x7fec5af9a045 code=0x0
2023-01-18T09:06:55.943107+01:00 zbox dhcpcd[16135]: ps_sendcmdmsg: Connection 
refused
2023-01-18T09:06:55.943407+01:00 zbox dhcpcd[16135]: ps_inet_recvra: Connection 
refused
2023-01-18T09:07:14.369135+01:00 zbox systemd[1]: dhcpcd.service: State 
'stop-sigterm' timed out. Killing.
2023-01-18T09:07:14.369676+01:00 zbox systemd[1]: dhcpcd.service: Killing 
process 16135 (dhcpcd) with signal SIGKILL.
2023-01-18T09:07:14.371498+01:00 zbox systemd[1]: dhcpcd.service: Failed with 
result 'signal'.

My workaround was to install udhcpc from busybox, but this package
doesn't provide IPv6 connectivity.

Thanks,

Beat Bolli


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

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

Versions of packages dhcpcd depends on:
ii  dhcpcd-base9.4.1-13
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

dhcpcd recommends no packages.

Versions of packages dhcpcd suggests:
pn  dhcpcd-gtk   
ii  openresolv [resolvconf]  3.12.0-3

-- no debconf information

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-18 Thread Paul Gevers


Hi Ondřej,

On 08-01-2023 22:41, Ondřej Surý wrote:

The Breaks have been added there since the last transition - there was a 
tendency for the apt dependency solver to pick one package (say php-imagick) 
from old PHP version and other one from new PHP version (say php-mysql). The 
Breaks was the only solution we came with that worked. I can dig up some old 
issues from the last transition.


I think we saw this pattern quite a bit in the autopkgtest failures too. 
It looks like the dependencies of the individual packages aren't perfect 
yet. I decided to ignore the autopkgest failures as the tests passed in 
a pure unstable environment (or otherwise got an RC bug about it), but 
it does hint that something is too lax on the dependency side; at least 
for tests.


I have rescheduled binNMU's of the last blockers in tpu and added a 
removal hint for uwsgi-plugin-php. If everything fares well, 
php-defaults could migrate tomorrow morning in the 7:52 dinstall run 
(maybe).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#961884: add init script / systemd unit for clamonacc background scanner

2023-01-18 Thread Sébastien Villemot

On Tue, 29 Jun 2021 22:08:31 +0200 Sebastian Andrzej Siewior 
 wrote:
> On 2020-05-30 19:53:49 [+], Patrick Schleizer wrote:
> > package clamav-daemon ships a file /usr/bin/clamonacc which is a
> > background virus scaning guard / real-time protection. It's currently
> > non-trivial to use.
> > 
> > sudo clamonacc
> > 
> > ERROR: Clamonacc: at least one of OnAccessExcludeUID,
> > OnAccessExcludeUname, or OnAccessExcludeRootUID must be specified ... it
> > is reccomended you exclude the clamd instance UID or uname to prevent
> > infinite event scanning loops
> > 
> > May I suggest adding an init script / systemd unit file which runs the
> > clamonacc background scanner?
> 
> The config file has to be touched manually to configure it properly. In
> the past this was part of clamd and people managed to lockup / deadlock
> their systems. Therefore I hesitate to add an initscript here.
> However I agree that even with proper configuration an initscript would
> be nice here since there is no need to over complicate it.
> 
> Feel free to post something (by someone who is actually using it),
> otherwise I try to add something later on.

As of clamav-daemon 1.0.0+dfsg-5, a systemd unit is provided for
clamonacc, so it looks like this issue has been addressed.

However, the unit is enabled by default. This looks like a bug, because
the service fails to start with the default configuration.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1029161: systemd: Inconsistent values for %j specifier across service and drop-in units

2023-01-18 Thread Michael Shaw

Apologies.
Systemd (
https://github.com/systemd/systemd/blob/f2af682cd6308f9b26035b83063e6aa8593e468c/docs/CONTRIBUTING.md)
says take the bug to Debian.
Debian (https://www.debian.org/Bugs/Reporting) says don't file bugs
upstream.

Using Systemd version 251.3-1~bpo11+1 produces identical results to those
previously described.

On Wed, 18 Jan 2023 at 17:30, Michael Biebl  wrote:

> Hi
>
> Am 18.01.23 um 18:21 schrieb Mike:
> > Package: systemd
> > Version: 247.3-7+deb11u1
> > Severity: normal
> > X-Debbugs-Cc: mike.shaw.nz+deb...@gmail.com
> >
> > Dear Maintainer,
> >
> > Under certain circumstances I'm seeing inconsistent values for the %j
> specifier used in service and drop-in units.
> > To reproduce:
> >
> > Create a systemd unit /lib/systemd/system/foo@.service as:
> >
> >  [Unit]
> >  Description=good old foo
> >
> >  [Service]
> >  Type=oneshot
> >  ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (foo@
> .service))"
> >
> > Create a drop-in unit /etc/systemd/system/foo@.service.d/additional.conf
> as:
> >
> >  [Service]
> >  ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n
> (additional.conf))"
> >
> > Reload the systemd units and run systemctl cat foo@.service.  The
> output shows the drop-in being correctly incorporated:
> >
> >  # /lib/systemd/system/foo@.service
> >  [Unit]
> >  Description=good old foo
> >
> >  [Service]
> >  Type=oneshot
> >  ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (foo@
> .service))"
> >
> >  # /etc/systemd/system/foo@.service.d/additional.conf
> >  [Service]
> >  ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n
> (additional.conf))"
> >
> > Now create a symlink which contains a %j specifier:
> >
> >  sudo ln -sv /lib/systemd/system/foo@.service
> /etc/systemd/system/foo-bar@.service
> >
> > Reload the systemd units and run systemctl cat foo-bar@.service.  The
> output is identical to that of systemctl cat foo@.service
> > Now start the service with a %i specifer:
> >
> >  systemctl start foo-bar@baz.service
> >
> > The output is:
> >
> >  ● foo@baz.service - good old foo
> >   Loaded: loaded (/lib/systemd/system/foo@.service; static)
> >   Drop-In: /etc/systemd/system/foo@.service.d
> >   └─additional.conf
> >   Active: inactive (dead)
> >
> >  Nov 01 12:10:31 Intel-NUC systemd[1]: Starting good old foo...
> >  Nov 01 12:10:31 Intel-NUC env[56108]: %i=[baz]   %j=[bar] (from
> foo-bar@baz.service (foo@.service))
> >  Nov 01 12:10:31 Intel-NUC env[56109]: %i=[baz]   %j=[foo] (from
> foo@baz.service (additional.conf))
> >  Nov 01 12:10:31 Intel-NUC systemd[1]: foo@baz.service: Succeeded.
> >  Nov 01 12:10:31 Intel-NUC systemd[1]: Finished good old foo.
> >
> > This shows that - in a single invocation - the value for %i is constant
> but the value for %j changes from 'bar' to 'foo'.  I would have expected
> the value of %j to be 'bar' throughout.  This may not be a bug, but - IMHO
> - this changing of values is unintuitive and I have been unable to find
> documentation that states the expected behaviour in this situation.  Happy
> to accept that I have confused/abused systemd with my custom
> /etc/systemd/system/foo-bar@.service symlink.
> >
>
> Ideally, such issues should be tested with the latest version of systemd
> (or at least v251) and then reported upstream.
>
>

Bug#1029055: Debian Expat and SPDX MIT License Text

2023-01-18 Thread Soren Stoutner

Thanks Richard.  I was unaware of the XML versions.

So, this would mean that SPDX considers what Debian calls the MIT (Expat) 
license to match what SPDX calls MIT because the differences are all either 
considered by SPDX to be omittable or replaceable as demonstrated by the tags 
in the XML file and the text colors in the HTML version.

On Wednesday, January 18, 2023 12:52:23 PM MST Richard Fontana wrote:
> The SPDX definition of "MIT" is given in
> https://github.com/spdx/license-list-XML/blob/main/src/MIT.xml
> Based on a lot of experience now, you really have to consult the XML
> files rather than rely on the convenience publication of license texts
> at https://spdx.org/licenses
> 
> Based on that, and https://www.debian.org/legal/licenses/mit, and
> https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templa
> tes/
> 
> I think the answer is that what Debian calls "MIT (Expat)" on that
> page matches what SPDX calls "MIT" (I don't think they are "the same"
> because the underlying concepts of what a license is and so forth are
> not the same).
> 
> Richard

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1029175: generate_firmware_patterns: automate extracting @sof_aliases from most recent linux-image

2023-01-18 Thread Cyril Brulebois

Package: debian-cd
Severity: normal

Hi,

tools/generate_firmware_patterns has a workaround for the firmware-sof-signed
package that doesn't ship appstream/dep-11 metadata. There, we list a bunch of
IDs manually extracted from linux-image--amd64, and that list can become
outdated over time.

It might be best to get the latest kernel at build time and generate e a fresh
list for each build.

Failing that, we really should update the list at least once for each major
Debian release.


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

Bug#1029174: dhcpcd-base: Brakes networking completely

2023-01-18 Thread Helge Kreutzmann

Package: dhcpcd-base
Version: 9.4.1-13
Severity: grave
Justification: renders package unusable

When this version is installed, all networking is broken, e.g. 
root@twentytwo:~# LC_ALL=C ping lwn.net
ping: lwn.net: Temporary failure in name resolution

I cannot access *any* outside resource. No IP, no ssh, no ping, ..

Additionally, comands involving network state take several minutes,
i.e. running into timeouts. E.g.
systemctl restart networking

Or shutdown takes several minutes (for each interface) before
completion.

If I strace such a command, I see:
access("/run/network/ifstate.enp3s0", R_OK) = 0
openat(AT_FDCWD, "/run/network/ifstate.enp3s0", 
O_RDWR|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = 3
fcntl(3, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = -1 
EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
write(2, "ifdown: ", 8ifdown: ) = 8
write(2, "waiting for lock on /run/network"..., 47waiting for lock on 
/run/network/ifstate.enp3s0) = 47
write(2, "\n", 1
)   = 1
fcntl(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

And there it hangs. (I did not search if this is the only place for
hangs, but it was the first).

Downgrading to 9.4.1-11 fixes the problem, i.e. the machine behaves
normally after reboot.

This is reproducible, i.e. upgrading to -13 and rebooting and the
broken network is back; downgrading and rebooting and the network is
fine again.

Please tell me which data you need to further boil this down and I can
provide it.

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dhcpcd-base depends on:
ii  adduser   3.130
ii  libc6 2.36-8
ii  libudev1  252.4-1

dhcpcd-base recommends no packages.

dhcpcd-base suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1029173: /usr/share/doc/clamav/NEWS.gz is a dangling symlink

2023-01-18 Thread Sébastien Villemot

Package: clamav
Version: 1.0.0+dfsg-5
Severity: normal

Dear Maintainer,

On my system, /usr/share/doc/clamav/NEWS.gz is a dangling symlink.

And actually the same applies to
/usr/share/doc/clamav-{daemon,freshclam,milter}/NEWS.gz

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#1007002: Update Documentation

2023-01-18 Thread Soren Stoutner

It would probably be helpful to update the documentation at 
https://lintian.debian.org/manual/index.html#format-of-override-files[1] to 
describe the new pointed hints format.

-- 
Soren Stoutner
so...@stoutner.com


[1] https://lintian.debian.org/manual/index.html#format-of-override-files


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

Bug#1029172: ncdu: new upstream version 1.18

2023-01-18 Thread Christian Göttsche

Package: ncdu
Version: 1.17-0.1

Dear Maintainer,

please consider packaging the newest (C written) release 1.18.

Regards,
   Christian Göttsche

Bug#1029171: RM: muon -- ROM; Abandoned upstream

2023-01-18 Thread Aurélien COUDERC

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: m...@packages.debian.org, Debian Qt/KDE Maintainers 

Control: affects -1 + src:muon

Dear FTP Masters,

Muon, the KDE graphical frontend for apt-based distros has been
abandoned upstream with no activity for some years and the source
repository now being archived (= read-only) on their GitLab [0].

It’s been superseded by Plasma Discover, using packagekit as a backend,
which is actively maintained.

Also another project named muon has sprung up [1] as a
reimplementation of the meson build system in pure C99, and the
maintainer would like to reuse the /user/bin/muon path for bookworm+1
which makes sense for a command line tool.

So I hereby request the removal of src:muon from unstable.


[0] https://invent.kde.org/system/muon
[1] https://sr.ht/~lattis/muon/


Thanks,
--
Aurélien

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

2023-01-18 Thread Leo Antunes

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-sigstore-sigstore
  Version : 1.5.1-1
  Upstream Author : The Sigstore Authors 
* URL : https://github.com/sigstore/sigstore
* License : Apache-2.0
  Programming Lang: Go
  Description : Common go library shared across sigstore services and 
clients

 sigstore/sigstore contains common Sigstore code: that is, code shared
 by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g.
 Cosign and Gitsign.

Bug#1027097: xfwm4: taskbar is visible, when using borderless fullscreen

2023-01-18 Thread Beta Version

On Wed, 18 Jan 2023 20:53:48 +0100 Yves-Alexis Perez 
wrote:
> Hi, so I just checked locally and I can't reproduce, at least when using
mpv
> and using F it correctly cover the whole screen; same with Firefox and a
> youtube video. Could you elaborate a bit on what exactly you're doing?
>
> Regards,
> - --
> Yves-Alexis
>

Hi. This problem has already been solved by updating lxqt-panel to 1.2.1-1.
So if you have lxqt-panel 1.2.1-1 installed, I guess you won't be able to
reproduce this bug. Anyway, the problem is solved and this bugreport can be
closed. Thank you for your time.

Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1

2023-01-18 Thread Oliver Freyermuth

Hi,

I observe the very same issue on a Dell Latitude 3590, but it only started to
affect the laptop running Bullseye all of a sudden after one of many
reinstallations.
19 other laptops (same model, same date of purchase, same hardware) with
exactly the same installation (preseed + configuration management via Puppet)
are (as of yet) unaffected.

I believe the described issue matches this one observed on various Dell laptops:
https://github.com/rhboot/efibootmgr/issues/86

To be more explicit, using:
efibootmgr -c -e 3 -v -L debian -l "\EFI\debian\shimx64.efi"
creates a working boot entry, using an EDD 3.0 path similar to the one created if an
entry is created via the UEFI firmware "by hand".

Using:
efibootmgr -c -v -L debian -l "\EFI\debian\shimx64.efi"
creates a boot entry invisible in the UEFI firmware.

This matches the observation of Gábor Gombás ("Debian" in the "efibootmgr -v" output for
an EDD 3.0 entry vs. "debian", an EDD 1.0 entry).

As of the fix for #891434 , grub-install does not leverage efibootmgr anymore,
but implements part of its functionality to reduce writes (and always seems to
use EDD 1.0).

From my observation and the one in the linked GitHub issue, I deduce the
following:

- There's actually a firmware bug on these Dell laptops (and maybe more
devices), causing the UEFI firmware to start ignoring EDD 1.0 entries after
some event (a number of write cycles? some corruption?).
- EDD 3.0 entries still work.
- Since grub-install always uses EDD 1.0 entries, it overwrites the entry with
an EDD 1.0 entry during each reinstall, causing such devices not to be bootable
anymore.

Workarounds appear to be:
- Create an EDD 3.0 entry (either via firmware, or via efibootmgr), name it
differently and inject it first in the boot order.
- Use --force-extra-removable to install to the fallback loader path (if this
is the only bootloader on the system).

Notably, the workaround described by ArchLinux at:

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Boot_entries_created_with_efibootmgr_fail_to_show_up_in_UEFI
does not work on Debian, since efibootmgr is not called by grub-install.

While the GitHub issue describes a user who could make EDD 1.0 entries work
again on an affected system by purging all entries, in my tests neither that
nor an UEFI update nor loading of firmware defaults nor a full RTC reset could
make the firmware accept EDD 1.0 entries again on the affected device.

A potential solution could be to probe whether the firmware accepts EDD 3.0
entries and preferrably create those over EDD 1.0, or allow to configure this.

Cheers and hope this helps,
Oliver

Bug#1027097: xfwm4: taskbar is visible, when using borderless fullscreen

2023-01-18 Thread Mattia Piron

How to remove these mailing list?

Il mer 18 gen 2023, 20:57 Yves-Alexis Perez  ha scritto:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> control
> On Wed, 2023-01-18 at 08:42 +0100, Yves-Alexis Perez wrote:
> > On Tue, 2022-12-27 at 20:46 +0300, Beta Version wrote:
> > > after updating xfwm4 from 4.16.1-1 to 4.18.0-1 taskbar now is always
> > > visible,
> > > when using borderless fullscreen, like when watching video fullscreen
> in
> > > MPV
> > > or
> > > on youtube in browser, or playing games with borderless fullscreen. If
> > > game
> > > uses exclusive fullscreen, taskbar is not visible.
> > >
> > > I tried using Openbox instead of xfwm4 and with Openbox taskbar works
> as
> > > expected: not visible in borderless fullsreen.
> > >
> > > DE is LXQt.
> >
> > Hi, thanks for the report. Along with #1026884 it seems with have some
> > behavior changes regarding struts (reserved spaces). I'll try to ping
> > upstream
> > about that.
>
> Hi, so I just checked locally and I can't reproduce, at least when using
> mpv
> and using F it correctly cover the whole screen; same with Firefox and a
> youtube video. Could you elaborate a bit on what exactly you're doing?
>
> Regards,
> - --
> Yves-Alexis
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmPITkwACgkQ3rYcyPpX
> RFsKyQgAzzGtH1cUtQRmCdbQikVrH6oJ1po9X6VQ/Tlp/m/NWG8M/1e40ZlonOh1
> pcnoE7NeBX3Rcy/h3xchvybxHPjJTux5WONkfHEx6Cd/8NpkxsJahZSTm5p0L25x
> nGzd0BZpG63xGOD9YUgWl/+4yQArOB6UWciCVfqqv3RclsTJQeRsNm6yevKIiSzh
> HPGS2Heah3+H1qnjAkB/IMc3Hmxu8HjOW1hbVeW15oZTTtHf7htzEUf13IDq9VsV
> FqPVcqp1Bd19hmFuD9yuAN826cztsDCv7cAbyGh8TqZRzq4jomZCz9jvist1fGAC
> JV5VfzS/+s+Rr2UYIz0+H41o9n2a+g==
> =7n/7
> -END PGP SIGNATURE-
>
>

Bug#1029055: Debian Expat and SPDX MIT License Text

2023-01-18 Thread Richard Fontana

On Tue, Jan 17, 2023 at 2:06 AM Axel Beckert  wrote:
>
> Hi,
>
> Soren Stoutner wrote:
> > There appears to be some question of opinion
>
> Not opinion. Just the point of what the meaning of _text colors_
> *rollingeyes* in a license do mean. I just ignored them and then those
> two licenses differ.
>
> > as to if the Debian MIT (Expat) License is
> > the same as the SPDX MIT License.
> […]
> > Can somebody at Debian Legal please comment?
>
> Yes, thanks! I'd prefer to have a good explanation, too.
>
> Please also note that I didn't mark the bug report as wontfix, just as
> moreinfo.

The SPDX definition of "MIT" is given in
https://github.com/spdx/license-list-XML/blob/main/src/MIT.xml
Based on a lot of experience now, you really have to consult the XML
files rather than rely on the convenience publication of license texts
at https://spdx.org/licenses

Based on that, and https://www.debian.org/legal/licenses/mit, and
https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/

I think the answer is that what Debian calls "MIT (Expat)" on that
page matches what SPDX calls "MIT" (I don't think they are "the same"
because the underlying concepts of what a license is and so forth are
not the same).

Richard

Bug#766863: Intent to NMU darkstat to fix longstanding l10n bug

2023-01-18 Thread Rene Mayorga

On Sat, Jan 14, 2023 at 03:47:57PM +0100, Helge Kreutzmann wrote:
> Hello Rene,
> hello Emil,
> I intend to NMU darkstat end around 2023-01-28 next week to fix 
> a longstanding l10n bug. 

Please go ahead, thanks a lot for your contribution.

Regards

--
René

Bug#1027097: xfwm4: taskbar is visible, when using borderless fullscreen

2023-01-18 Thread Yves-Alexis Perez

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control
On Wed, 2023-01-18 at 08:42 +0100, Yves-Alexis Perez wrote:
> On Tue, 2022-12-27 at 20:46 +0300, Beta Version wrote:
> > after updating xfwm4 from 4.16.1-1 to 4.18.0-1 taskbar now is always
> > visible,
> > when using borderless fullscreen, like when watching video fullscreen in
> > MPV
> > or
> > on youtube in browser, or playing games with borderless fullscreen. If
> > game
> > uses exclusive fullscreen, taskbar is not visible.
> > 
> > I tried using Openbox instead of xfwm4 and with Openbox taskbar works as
> > expected: not visible in borderless fullsreen.
> > 
> > DE is LXQt.
> 
> Hi, thanks for the report. Along with #1026884 it seems with have some
> behavior changes regarding struts (reserved spaces). I'll try to ping
> upstream
> about that.

Hi, so I just checked locally and I can't reproduce, at least when using mpv
and using F it correctly cover the whole screen; same with Firefox and a
youtube video. Could you elaborate a bit on what exactly you're doing?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmPITkwACgkQ3rYcyPpX
RFsKyQgAzzGtH1cUtQRmCdbQikVrH6oJ1po9X6VQ/Tlp/m/NWG8M/1e40ZlonOh1
pcnoE7NeBX3Rcy/h3xchvybxHPjJTux5WONkfHEx6Cd/8NpkxsJahZSTm5p0L25x
nGzd0BZpG63xGOD9YUgWl/+4yQArOB6UWciCVfqqv3RclsTJQeRsNm6yevKIiSzh
HPGS2Heah3+H1qnjAkB/IMc3Hmxu8HjOW1hbVeW15oZTTtHf7htzEUf13IDq9VsV
FqPVcqp1Bd19hmFuD9yuAN826cztsDCv7cAbyGh8TqZRzq4jomZCz9jvist1fGAC
JV5VfzS/+s+Rr2UYIz0+H41o9n2a+g==
=7n/7
-END PGP SIGNATURE-

Bug#1014885: lintian wrongly complains about XS-Go-Import-Path

2023-01-18 Thread Holger Levsen

Hi,

I can confirm this issue for lintian 2.116.0 against src:piuparts
as it is in git or unstable.


-- 
cheers,
Holger

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

First they came for the journalists, we don't know what happened after that.


signature.asc
Description: PGP signature

Bug#1023540: snapshot.debian.org: 504 Gateway Time-out

2023-01-18 Thread Baptiste Beauplat

Hi,

The observed 504 errors are coming from either haproxy or varnish,
stopping the request because snapshot take too much time to reply
(typically a query on gcc or linux take over a minute to complete).

While investigating this issue, I discovered that snapshot is doing way
too much SQL queries to reply to /packages/{package}/{version}
requests, especially on packages with a lot of binary files.

I've optimized the code and got very promising results (down from ~2000
SQL queries to 4 and from over a minute to 2s).

I've created an MR here:

https://salsa.debian.org/snapshot-team/snapshot/-/merge_requests/9

I'll let you know when this is merged and deployed.

-- 
Baptiste Beauplat



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

Bug#1029169: ITP: node-isbinaryfile -- Detects if a file is binary in Node.js. Similar to Perl’s -B

2023-01-18 Thread Nkwuda Sunday

Package: wnpp
X-Debbugs-Cc:debian-de...@lists.debian.org
Owner: Sandra Uwah 
X-Debbugs-Cc:sonniet...@disroot.org 
Severity: wishlist
 
* Package name: node-isbinaryfile
  Version : 5.0.0
  Upstream Author : Garen J. Torikian
* URL : https://github.com/gjtorikian/isBinaryFile 
* License : MIT
  Programming Lang: Javascript
  Description : Detects if a file is binary in Node.js. Similar to  Perl’s 
-B

Bug#1029167: mozjs78: Fails to build on armhf and armel

2023-01-18 Thread Simon McVittie

On Wed, 18 Jan 2023 at 19:08:22 +, Joshua Peisach wrote:
> CJS ported to mozjs78 in October 2020, and Cinnamon is still finishing their 
> 5.6x releases/making cleanups.
> 
> Considering upstream uses Ubuntu Jammy, mozjs102 isn’t an option unless they 
> are willing to build it for their main development target. I think Cjs should 
> rebase for mozjs91,
> Especially if mozjs78 is EOL.

Firefox 91 (and therefore mozjs91) is already EOL, and has been since
September 2022, so porting to mozjs91 doesn't seem like a great solution
this year.

Even if Cinnamon upstream has a version of Linux Mint that is based on
Ubuntu jammy (22.04) as its primary development target, the version of
Cinnamon in Ubuntu jammy is constant (5.2.x) and is unlikely to change
(not making major changes is part of the point of a LTS distribution);
so if Linux Mint wants to provide newer versions of Cinnamon for a
jammy-based OS, they already need their own apt repository that provides
those packages. Since that repository needs to exist anyway, it would
be straightforward for it to also be used to ship updated versions of
dependencies where necessary, such as a suitable version of mozjs102
for cjs' benefit.

(Of course, that can only happen if someone in Cinnamon/Mint takes
responsibility for uploading that version of mozjs102.)

smcv

Bug#1029167: mozjs78: Fails to build on armhf and armel

2023-01-18 Thread Jeremy Bicha

On Wed, Jan 18, 2023 at 2:08 PM Joshua Peisach
 wrote:
> CJS ported to mozjs78 in October 2020, and Cinnamon is still finishing their 
> 5.6x releases/making cleanups.
>
> Considering upstream uses Ubuntu Jammy, mozjs102 isn’t an option unless they 
> are willing to build it for their main development target. I think Cjs should 
> rebase for mozjs91,
> Especially if mozjs78 is EOL.

Cinnamon upstream is more than welcome to add a backported mozjs* to
the list of custom packages they provide. The absence of the latest
mozjs on Debian Stable or Ubuntu LTS does not need to be a blocker at
all.

But I have news: Ubuntu 22.04 LTS now has mozjs102 in jammy-proposed.
The intent is to release this as a security update there soon. See
https://launchpad.net/bugs/1993214 for more details.

If that works well, we may continue to backport new major mozjs
releases in the future for Ubuntu LTS. Perhaps for Debian 12 too.

Thank you,
Jeremy Bicha

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

2023-01-18 Thread Jorge Moraleda

Package: fonts-urw-base35
Version: 20200910-6
Severity: important
X-Debbugs-Cc: jorge.moral...@gmail.com

Dear Maintainer,

I use fonts as part of a java application I develop. I recently upgraded my
system (to an up-to-date debian bookworm).

After this upgrade all fonts packaged in this packet are unloadable by apache
pdfbox (but fonts in the many other font packages that I have installed all
load fine). This is the relevant portion of the logs showing the error (I am
including logs for the error when loading font "NimbusSans-BoldItalic.pfb" but
logs for other fonts in the package are the same)

[2023-01-18 13:15:26] [info] 2023-01-18 13:15:26.561  WARN 228307 --- [alina-
utility-1] o.a.p.p.f.FileSystemFontProvider : Could not load font file:
/usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb
[2023-01-18 13:15:26] [info] java.io.IOException: Start marker missing
[2023-01-18 13:15:26] [info] #011at
org.apache.fontbox.pfb.PfbParser.parsePfb(PfbParser.java:147)
[2023-01-18 13:15:26] [info] #011at
org.apache.fontbox.pfb.PfbParser.(PfbParser.java:115)
[2023-01-18 13:15:26] [info] #011at
org.apache.fontbox.type1.Type1Font.createWithPFB(Type1Font.java:54)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addType1Font(FileSystemFontProvider.java:790)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:391)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:361)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:141)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:160)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:430)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:393)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:367)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:146)
[2023-01-18 13:15:26] [info] #011at
org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:79)


I am using apache pdfbox version 2.0.27
(https://mvnrepository.com/artifact/org.apache.pdfbox/pdfbox)

I am not familiar with fonts, but according to the source code
(https://github.com/apache/pdfbox/blob/trunk/fontbox/src/main/java/org/apache/fontbox/pfb/PfbParser.java)
it appears that pdfbox expects the font files in pfb format to start with
character 0x80 but they do not.


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

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

Versions of packages fonts-urw-base35 depends on:
ii  xfonts-utils  1:7.7+6

fonts-urw-base35 recommends no packages.

Versions of packages fonts-urw-base35 suggests:
ii  fonts-freefont-otf  20120503-10
ii  fonts-freefont-ttf  20120503-10
ii  fonts-texgyre   20180621-6

-- no debconf information

Bug#1026803: chiaki: FTBFS (ModuleNotFoundError: No module named 'pkg_resources')

Control: reassign -1 nanopb 0.4.7-1
Control: retitle -1 nanopb: Missing dependency on python3-pkg-resources
Control: affects -1 src:chiaki

On Wed, Dec 21, 2022 at 11:47:49AM +, Eric Long wrote:
>...
> cd /<>/obj-riscv64-linux-gnu/lib/protobuf && /usr/bin/python3 
> /usr/bin/nanopb_generator.py 
> /<>/obj-riscv64-linux-gnu/lib/protobuf/takion.pb
> Traceback (most recent call last):
>   File "/usr/bin/nanopb_generator.py", line 53, in 
> import proto
>   File "/usr/lib/python3/dist-packages/proto/__init__.py", line 10, in 
> 
> import pkg_resources
> ModuleNotFoundError: No module named 'pkg_resources'
>...

This is a bug in nanopb that should be fixed there.

cu
Adrian

Bug#1029127: context: manual has non-free files


Am 18.01.23 um 20:20 schrieb Hilmar Preuße:

Am 18.01.2023 um 11:52 teilte Bastian Germann mit:

Am 18.01.23 um 11:21 schrieb Hilmar Preuße:


Hi,


Do you have a list of these files or do you know how to generate one?


grep -r licence=cc-by-nc-sa


This gives a lot of TeX input files should I remove them?


Yes. But please make the repack reproducible. The easiest way is to convert
the debian/copyright file to the machine-readable format and use Files-Excluded.

Bug#1029127: context: manual has non-free files

2023-01-18 Thread Hilmar Preuße


Am 18.01.2023 um 11:52 teilte Bastian Germann mit:

Am 18.01.23 um 11:21 schrieb Hilmar Preuße:


Hi,


Do you have a list of these files or do you know how to generate one?


grep -r licence=cc-by-nc-sa


This gives a lot of TeX input files should I remove them?

Hilmar
--
sigfault

Bug#625758: 'adduser --disabled-login' does not behave as documented

2023-01-18 Thread Timo Lindfors

Jan 18, 2023 11:35:43 Marc Haber :
> Yes, that's the UI's error, it just gets what it asks for: A user that
> cannot login.

That's what I expected too but I was actually able to login. The only problem 
was that the gnome-terminal wasn't usable.

Bug#1029167: mozjs78: Fails to build on armhf and armel

2023-01-18 Thread Joshua Peisach

CJS ported to mozjs78 in October 2020, and Cinnamon is still finishing their 
5.6x releases/making cleanups.

Considering upstream uses Ubuntu Jammy, mozjs102 isn’t an option unless they 
are willing to build it for their main development target. I think Cjs should 
rebase for mozjs91,
Especially if mozjs78 is EOL.

> On Jan 18, 2023, at 1:59 PM, Jeremy Bicha  wrote:
> 
> Source: mozjs78
> Version: 78.15.0-6
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: debian-...@lists.debian.org, c...@packages.debian.org
> User: debian-...@lists.debian.org
> Usertags: armel armhf
> 
> mozjs78 fails to build on armhf & armel.
> 
> I have little interest in working on this bug myself. I only stumbled
> across this bug because I applied a build fix needed by Debian's
> switch to Python 3.11. mozjs78 has been End of Life since October 2021
> and is only still in Debian because Cinnamon hasn't switched to
> mozjs102 yet.
> 
> By the way, 0ad has an embedded copy of mozjs78 and still builds on
> armhf so maybe it includes a fix or a workaround for this build
> failure.
> 
> I'm pasting the end of the build log below, but the actual build error
> may have been earlier in the log.
> 
> /usr/bin/arm-linux-gnueabihf-g++ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
> -fstack-protector-strong -Wdate-time -D_FORTIFY_SOURCE=2 -Wall
> -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
> -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
> -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond
> -Wimplicit-fallthrough -Wunused-function -Wunused-variable
> -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
> -Wno-error=array-bounds -Wno-error=coverage-mismatch
> -Wno-error=free-nonheap-object -Wno-multistatement-macros
> -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat
> -Wformat-overflow=2 -Wno-noexcept-type -fno-sized-deallocation
> -fno-aligned-new -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -fno-rtti
> -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
> -pthread -pipe -g -freorder-blocks -O3 -fomit-frame-pointer
> -funwind-tables  -fPIC -shared -Wl,-z,defs -Wl,--gc-sections
> -Wl,-h,libmozjs-78.so -o libmozjs-78.so
> /<>/debian/build/js/src/build/libmozjs-78_so.list
> -lpthread -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro
> -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1
> -fstack-protector-strong
> -Wl,-rpath-link,/<>/debian/build/dist/bin
> -Wl,-rpath-link,/usr/lib
> /<>/debian/build/armv7-unknown-linux-gnueabihf/release/libjsrust.a
> -Wl,--version-script,symverscript -Wl,-soname,libmozjs-78.so.0  -lm
> -lz -lm -ldl
> /usr/bin/ld: 
> /<>/debian/build/js/src/build/../../../config/external/icu/common/rbbi.o:
> in function `std::type_info::operator!=(std::type_info const&) const':
> /usr/include/c++/12/typeinfo:115: undefined reference to
> `std::type_info::operator==(std::type_info const&) const'
> /usr/bin/ld: 
> /<>/debian/build/js/src/build/../../../config/external/icu/common/schriter.o:
> in function `std::type_info::operator!=(std::type_info const&) const':
> /usr/include/c++/12/typeinfo:115: undefined reference to
> `std::type_info::operator==(std::type_info const&) const'
> /usr/bin/ld: 
> /<>/debian/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o:
> in function 
> `icu_67::StringTrieBuilder::Node::operator==(icu_67::StringTrieBuilder::Node
> const&) const':
> ./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
> undefined reference to `std::type_info::operator==(std::type_info
> const&) const'
> /usr/bin/ld: 
> ./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
> undefined reference to `std::type_info::operator==(std::type_info
> const&) const'
> /usr/bin/ld: 
> ./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
> undefined reference to `std::type_info::operator==(std::type_info
> const&) const'
> /usr/bin/ld: 
> /<>/debian/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o:./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
> more undefined references to
> `std::type_info::operator==(std::type_info const&) const' follow
> collect2: error: ld returned 1 exit status
> make[4]: *** [/<>/config/rules.mk:608: libmozjs-78.so] Error 1
> make[4]: Leaving directory '/<>/debian/build/js/src/build'
> make[3]: *** [/<>/config/recurse.mk:74:
> js/src/build/target] Error 2
> make[3]: Leaving directory '/<>/debian/build'
> make[2]: *** [/<>/config/recurse.mk:34: compile] Error 2
> make[2]: Leaving directory '/<>/debian/build'
> make[1]: *** [/<>/config/rules.mk:392: default] Error 2
> make[1]: Leaving directory '/<>/debian/build'
> dh_auto_build: error: cd debian/build && make -j8 returned

Bug#1029167: mozjs78: Fails to build on armhf and armel

2023-01-18 Thread Jeremy Bicha

Source: mozjs78
Version: 78.15.0-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org, c...@packages.debian.org
User: debian-...@lists.debian.org
Usertags: armel armhf

mozjs78 fails to build on armhf & armel.

I have little interest in working on this bug myself. I only stumbled
across this bug because I applied a build fix needed by Debian's
switch to Python 3.11. mozjs78 has been End of Life since October 2021
and is only still in Debian because Cinnamon hasn't switched to
mozjs102 yet.

By the way, 0ad has an embedded copy of mozjs78 and still builds on
armhf so maybe it includes a fix or a workaround for this build
failure.

I'm pasting the end of the build log below, but the actual build error
may have been earlier in the log.

/usr/bin/arm-linux-gnueabihf-g++ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-fstack-protector-strong -Wdate-time -D_FORTIFY_SOURCE=2 -Wall
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond
-Wimplicit-fallthrough -Wunused-function -Wunused-variable
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
-Wno-error=array-bounds -Wno-error=coverage-mismatch
-Wno-error=free-nonheap-object -Wno-multistatement-macros
-Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat
-Wformat-overflow=2 -Wno-noexcept-type -fno-sized-deallocation
-fno-aligned-new -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-pthread -pipe -g -freorder-blocks -O3 -fomit-frame-pointer
-funwind-tables  -fPIC -shared -Wl,-z,defs -Wl,--gc-sections
-Wl,-h,libmozjs-78.so -o libmozjs-78.so
/<>/debian/build/js/src/build/libmozjs-78_so.list
-lpthread -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro
-Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1
-fstack-protector-strong
-Wl,-rpath-link,/<>/debian/build/dist/bin
-Wl,-rpath-link,/usr/lib
/<>/debian/build/armv7-unknown-linux-gnueabihf/release/libjsrust.a
 -Wl,--version-script,symverscript -Wl,-soname,libmozjs-78.so.0  -lm
-lz -lm -ldl
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/rbbi.o:
in function `std::type_info::operator!=(std::type_info const&) const':
/usr/include/c++/12/typeinfo:115: undefined reference to
`std::type_info::operator==(std::type_info const&) const'
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/schriter.o:
in function `std::type_info::operator!=(std::type_info const&) const':
/usr/include/c++/12/typeinfo:115: undefined reference to
`std::type_info::operator==(std::type_info const&) const'
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o:
in function 
`icu_67::StringTrieBuilder::Node::operator==(icu_67::StringTrieBuilder::Node
const&) const':
./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
undefined reference to `std::type_info::operator==(std::type_info
const&) const'
/usr/bin/ld: 
./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
undefined reference to `std::type_info::operator==(std::type_info
const&) const'
/usr/bin/ld: 
./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
undefined reference to `std::type_info::operator==(std::type_info
const&) const'
/usr/bin/ld: 
/<>/debian/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o:./debian/build/config/external/icu/common/./intl/icu/source/common/stringtriebuilder.cpp:388:
more undefined references to
`std::type_info::operator==(std::type_info const&) const' follow
collect2: error: ld returned 1 exit status
make[4]: *** [/<>/config/rules.mk:608: libmozjs-78.so] Error 1
make[4]: Leaving directory '/<>/debian/build/js/src/build'
make[3]: *** [/<>/config/recurse.mk:74:
js/src/build/target] Error 2
make[3]: Leaving directory '/<>/debian/build'
make[2]: *** [/<>/config/recurse.mk:34: compile] Error 2
make[2]: Leaving directory '/<>/debian/build'
make[1]: *** [/<>/config/rules.mk:392: default] Error 2
make[1]: Leaving directory '/<>/debian/build'
dh_auto_build: error: cd debian/build && make -j8 returned exit code 2


Thank you,
Jeremy Bicha

Bug#1029166: rhino: Dead Homepage link

Source: rhino
Version: 1.7.7.2-3
Severity: minor

debian/control:Homepage: http://www.mozilla.org/rhino/

This is a dead link, one option would be
  Homepage: https://github.com/mozilla/rhino

Bug#1026639: ckeditor: FTBFS: make[1]: *** [debian/rules:38: override_dh_auto_build] Error 1

Control: reassign -1 librhino-java 1.7.7.2-3
Control: retitle -1 librhino-java: IllegalAccessException With OpenJDK 17
Control: affects -1 ckbuilder src:ckeditor

On Tue, Dec 20, 2022 at 06:33:52PM +0100, Lucas Nussbaum wrote:
> Source: ckeditor
> Version: 4.19.1+dfsg-1
> Severity: serious
> Justification: FTBFS
>...
> > Exception in thread "main" org.mozilla.javascript.WrappedException: Wrapped 
> > java.lang.IllegalAccessException: class org.mozilla.javascript.MemberBox 
> > cannot access class sun.java2d.SunGraphics2D (in module java.desktop) 
> > because module java.desktop does not export sun.java2d to unnamed module 
> > @614635c2 
> > (/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/image.js#282)
> > at 
> > org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1914)
> > at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:134)
> > at 
> > org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:225)
> > at org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:52)
> > at 
> > ckbuilder.lib.image._c_anonymous_7(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/image.js:282)
> > at 
> > ckbuilder.lib.image.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/image.js)
> > at org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:52)
> > at 
> > ckbuilder.lib.image._c_anonymous_4(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/image.js:144)
> > at 
> > ckbuilder.lib.image.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/image.js)
> > at org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:52)
> > at 
> > ckbuilder.lib.builder._c_createPluginsSpriteImage_16(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/builder.js:499)
> > at 
> > ckbuilder.lib.builder.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/builder.js)
> > at 
> > org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:74)
> > at 
> > ckbuilder.lib.builder._c_anonymous_21(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/builder.js:726)
> > at 
> > ckbuilder.lib.builder.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/builder.js)
> > at 
> > org.mozilla.javascript.optimizer.OptRuntime.callProp0(OptRuntime.java:85)
> > at 
> > ckbuilder.lib.controller._c_anonymous_5(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/controller.js:80)
> > at 
> > ckbuilder.lib.controller.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/controller.js)
> > at 
> > org.mozilla.javascript.ScriptRuntime.applyOrCall(ScriptRuntime.java:2697)
> > at org.mozilla.javascript.BaseFunction.execIdCall(BaseFunction.java:287)
> > at 
> > org.mozilla.javascript.IdFunctionObject.call(IdFunctionObject.java:101)
> > at org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:52)
> > at 
> > ckbuilder.lib.controller._c_anonymous_14(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/controller.js:243)
> > at 
> > ckbuilder.lib.controller.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/lib/controller.js)
> > at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:32)
> > at 
> > ckbuilder.ckbuilder._c_script_0(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/ckbuilder.js:119)
> > at 
> > ckbuilder.ckbuilder.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/ckbuilder.js)
> > at 
> > org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:399)
> > at 
> > org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3452)
> > at 
> > ckbuilder.ckbuilder.call(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/ckbuilder.js)
> > at 
> > ckbuilder.ckbuilder.exec(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/ckbuilder.js)
> > at 
> > org.mozilla.javascript.optimizer.OptRuntime$1.run(OptRuntime.java:234)
> > at org.mozilla.javascript.Context.call(Context.java:526)
> > at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:509)
> > at org.mozilla.javascript.optimizer.OptRuntime.main(OptRuntime.java:222)
> > at 
> > ckbuilder.ckbuilder.main(/build/ckbuilder-Vz2B26/ckbuilder-2.4.3+dfsg/src/ckbuilder.js)
>...

This is a bug in Rhino, fixed in 1.7.14.

cu
Adrian

Bug#1029164: mariadb: FTBFS on mipsel, mips64el: builds, but test suite in main.order_by_innodb 'innodb' mismatches ('ref' instead of 'range')

2023-01-18 Thread Otto Kekäläinen

Source: mariadb
Version: 1:10.11.1-1
Tags: upstream, confirmed, ftbfs
User: debian-m...@lists.debian.org
Usertags: mipsel, mips64el
X-Debbugs-CC: debian-m...@lists.debian.org

After upload of MariaDB 11.10 to Debian (this is a regression from
10.6) the following test started to fail:

main.order_by_innodb 'innodb'w2 [ fail ]
Test ended at 2023-01-16 18:25:43

CURRENT_TEST: main.order_by_innodb
--- /<>/mysql-test/main/order_by_innodb.result 2022-11-14
18:10:21.0 +
+++ /<>/mysql-test/main/order_by_innodb.reject 2023-01-16
18:25:42.932126514 +
@@ -250,7 +250,7 @@
 id select_type table type possible_keys key key_len ref rows Extra
 1 PRIMARY t1 index NULL PRIMARY 4 NULL # Using index
 1 PRIMARY t2 eq_ref PRIMARY,id2 PRIMARY 4 func # Using where
-2 DEPENDENT SUBQUERY dd range id2,for_latest_sort for_latest_sort 6
NULL # Using where
+2 DEPENDENT SUBQUERY dd ref id2,for_latest_sort id2 4 test.t1.id #
Using where; Using filesort
 drop table t1,t2,t3;
 # End of 10.2 tests


Merge requests welcome!

https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1029165: mariadb: failed to cross-compile

2023-01-18 Thread Otto Kekäläinen

Source: mariadb
Version: 1:10.11.1-1
Tags: help

Hi!

I tested to cross-compile MariaDB 10.11.1-1 on
http://crossqa.debian.net/src/mariadb on multiple architectures but
they all failed with:

[  1%] Linking C executable uca-dump
cd /<>/builddir/strings && /usr/bin/cmake -E
cmake_link_script CMakeFiles/uca-dump.dir/link.txt --verbose=1
/usr/bin/x86_64-linux-gnu-gcc -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
-D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
--param=ssp-buffer-size=4 -O2 -g -static-libgcc
-fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
-Wdeclaration-after-statement -Wenum-compare -Wenum-conversion -Wextra
-Wformat-security -Wmissing-braces -Wno-format-truncation
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Wvla
-Wwrite-strings -Wl,-z,relro -Wl,-z,now -Wl,-z,relro,-z,now
"CMakeFiles/uca-dump.dir/uca-dump.c.o" -o uca-dump
make[4]: Leaving directory '/<>/builddir'
[  1%] Built target uca-dump
/usr/bin/make  -f
strings/CMakeFiles/GenUnicodeDataSource.dir/build.make
strings/CMakeFiles/GenUnicodeDataSource.dir/depend
make[4]: Entering directory '/<>/builddir'
cd /<>/builddir && /usr/bin/cmake -E cmake_depends "Unix
Makefiles" /<> /<>/strings
/<>/builddir /<>/builddir/strings
/<>/builddir/strings/CMakeFiles/GenUnicodeDataSource.dir/DependInfo.cmake
--color=
make[4]: Leaving directory '/<>/builddir'
/usr/bin/make  -f
strings/CMakeFiles/GenUnicodeDataSource.dir/build.make
strings/CMakeFiles/GenUnicodeDataSource.dir/build
make[4]: Entering directory '/<>/builddir'
[  1%] Generating ctype-uca1400data.h
cd /<>/builddir/strings && uca-dump --name-prefix=uca1400
--levels=3 /<>/mysql-test/std_data/unicode/allkeys1400.txt
> ctype-uca1400data.h
/bin/sh: 1: uca-dump: not found

Example: 
http://crossqa.debian.net/build/mariadb_1:10.11.1-1_amd64_20230117013022.log


Contributions to fix this welcome!

https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1029163: mariadb: FTBFS on armel, armhf, mipsel, mips64el: builds, but test suite fails in main.explain_json_format mismatches

2023-01-18 Thread Otto Kekäläinen

Source: mariadb
Version: 1:10.11.1-1
Tags: upstream, confirmed, ftbfs
User: debian-...@lists.debian.org
Usertags: eabi, mipsel, mips64el, armhf, armel
X-Debbugs-CC: debian-...@lists.debian.org, debian-m...@lists.debian.org
Forwarded: https://jira.mariadb.org/browse/MDEV-30411

Several tests that use ANALYZE format=json fail with mismatched output
after upload of MariaDB 11.10 to Debian (this is a regression from
10.6).

Example:

CURRENT_TEST: main.except_all
--- /<>/mysql-test/main/except_all.result 2022-11-14
18:10:21.0 +
+++ /<>/mysql-test/main/except_all.reject 2023-01-12
20:20:18.132443098 +
@@ -115,13 +115,9 @@
 ANALYZE format=json select * from ((select a,b from t1) except all
(select c,d from t2)) a;
 ANALYZE
 {
-  "query_optimization": {
-"r_total_time_ms": "REPLACED"
-  },
   "query_block": {
 "select_id": 1,
 "r_loops": 1,
-"r_total_time_ms": "REPLACED",
 "nested_loop": [


The likely fix would go into
https://github.com/MariaDB/server/tree/10.11/include/my_rdtsc.h

Several people already suggested various ways to do it:

* 
https://alioth-lists.debian.net/pipermail/pkg-mysql-maint/2023-January/016183.html
* https://lists.debian.org/debian-arm/2023/01/msg7.html
* https://lists.debian.org/debian-arm/2023/01/msg8.html

What is missing is for somebody to do an optimal change and validate
that it works.


Merge requests welcome!

https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1027143: openimageio: CVE-2022-43592 CVE-2022-43593 CVE-2022-43594 CVE-2022-43595 CVE-2022-43596 CVE-2022-43597 CVE-2022-43598 CVE-2022-43599 CVE-2022-43600 CVE-2022-43601 CVE-2022-43602 CVE-2022-


I have uploaded the latest 2.3 release to unstable and the latest 2.4 release 
to experimental (NEW).
I have not yet updated d/copyright, so that is a TODO for any unstable 2.4 
version.

Transitions are not allowed anymore but if the reverse deps build fine with the experimental package I suggest to ask 
the release team for an exception. Else, someone has to grind through all the CVEs and check if they are applicable for 
2.3.21. I do not think any volunteer steps up for that.

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

2023-01-18 Thread Christoph Martin


I've build an initial package and will upload it soon for review.

Am 17.01.23 um 18:02 schrieb Christoph Martin:

I have created a repository on salsa:

https://salsa.debian.org/python-team/packages/yq





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011346: Enabling V4L2 Driver in Chromium Builds

2023-01-18 Thread Andres Salomon





On Wed, Jan 18 2023 at 06:40:25 PM +0100, Bastian Germann 
 wrote:

Am 18.01.23 um 17:29 schrieb Andres Salomon:

Thanks for reopening!

Unfortunately it fails to build on all arm architectures including 
arm64:


https://buildd.debian.org/status/fetch.php?pkg=chromium=arm64=107.0.5304.68-1=1666793161=0

linux/media/av1-ctrls.h is some weirdo header that's only available 
in a chromeos environment. Since upstream only builds arm on that, 
they don't seem to have noticed. Someone needs to test a build on 
arm* with that inclusion removed; I suspect they also included 
stuff from that header.


The current Debian source has moved the inclusion of the failing 
files to a place protected by
if (is_chromeos): 
https://chromium-review.googlesource.com/c/chromium/src/+/3982602


I am going to run a test build.



Ah great, I hadn't noticed!  If the build works, let me know and I'll 
reenable v4l2.

Bug#1028959: lintian: Weird very-long-line-length-in-source-file false positve due no long line in file

2023-01-18 Thread Sven Joachim

Hi Axel,

On 2023-01-15 11:12 +0100, Axel Beckert wrote:

> When running against BackupPC, lintian emits this tag:
>
> X: backuppc source: very-long-line-length-in-source-file 535 > 512 
> [lib/BackupPC/CGI/GeneralInfo.pm:52]
>
> But there is no such long line in that file:
>
> $ cat -n lib/BackupPC/CGI/GeneralInfo.pm | egrep '^\s*52\s' | wc -c
> 77
> $ cut -c512- lib/BackupPC/CGI/GeneralInfo.pm | egrep -v '^$'
> $ file lib/BackupPC/CGI/GeneralInfo.pm
> lib/BackupPC/CGI/GeneralInfo.pm: Perl5 module source, ASCII text
> $
>
> So "file" also doesn't mention any long line stuff (which it usually
> does, I just don't know its limits).
>
> Line 52 looks like this:
>
>if ( $Jobs{$host}{type} eq "" && defined($Status{$host}) );
>
> Not yet debugged, so not sure why lintian thinks that this file has any
> long line. According to my statistics the two longes lines in there are
> two lines which each 99 characters.

I have found the explanation:

,
| $ apt source backuppc
| [...]
| $ debcheckout backuppc
| [...]
| $ file backuppc/lib/BackupPC/CGI/GeneralInfo.pm
| backuppc/lib/BackupPC/CGI/GeneralInfo.pm: Perl5 module source, ASCII text
| $ file backuppc-4.4.0/lib/BackupPC/CGI/GeneralInfo.pm
| backuppc-4.4.0/lib/BackupPC/CGI/GeneralInfo.pm: Perl5 module source, ASCII 
text, with very long lines (534)
`

The long line is generated by a Debian patch, and you do not have
patches applied in git.  But lintian is smart enough to check the
_patched_ sources.

Thanks for maintaining lintian!

Cheers,
   Sven

Bug#1011346: Enabling V4L2 Driver in Chromium Builds


Am 18.01.23 um 17:29 schrieb Andres Salomon:

Thanks for reopening!

Unfortunately it fails to build on all arm architectures including arm64:

https://buildd.debian.org/status/fetch.php?pkg=chromium=arm64=107.0.5304.68-1=1666793161=0

linux/media/av1-ctrls.h is some weirdo header that's only available in a chromeos environment. Since upstream only 
builds arm on that, they don't seem to have noticed. Someone needs to test a build on arm* with that inclusion removed; 
I suspect they also included stuff from that header.


The current Debian source has moved the inclusion of the failing files to a 
place protected by
if (is_chromeos): 
https://chromium-review.googlesource.com/c/chromium/src/+/3982602

I am going to run a test build.

Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd

2023-01-18 Thread Martina Ferrari

Package: transmission-daemon
Version: 3.00-1
Severity: normal
X-Debbugs-Cc: t...@debian.org

Today I noticed transmission-daemon being down after a reboot, and saw it is
crashing with a malloc error. After some debugging, I found out that this only
happens if I am using the `--portmap` option *and* a local minissdpd is
running.

$ /usr/bin/transmission-daemon -f --log-debug --portmap
malloc(): invalid next size (unsorted)
Aborted

A GDB backtrace does not show anything interesting:

Starting program: /usr/bin/transmission-daemon -f --log-debug --portmap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb60fa1d0 (LWP 3885)]
[New Thread 0xb58f91d0 (LWP 3886)]
[New Thread 0xb4eff1d0 (LWP 3887)]
malloc(): invalid next size (unsorted)

Thread 3 "transmission-da" received signal SIGABRT, Aborted.
[Switching to Thread 0xb58f91d0 (LWP 3886)]
0xb6b047e6 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0  0xb6b047e6 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0xb6b13a20 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0xb6b04322 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#3  0xb6b3c8ae in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


OTOH, Valgrind shows a possible culprit being libminiupnpc, even though that
package has not been updated at all (and the program does not crash when run
with Valgrind):

==4082== Thread 3:
==4082== Invalid write of size 2
==4082==at 0x4846474: memcpy (in 
/usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so)
==4082==  Address 0x57d016c is 0 bytes after a block of size 204 alloc'd
==4082==at 0x484063C: malloc (in 
/usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so)
==4082== 
==4082== Invalid write of size 1
==4082==at 0x4862092: receiveDevicesFromMiniSSDPD (in 
/usr/lib/arm-linux-gnueabihf/libminiupnpc.so.17)
==4082==  Address 0x57d016e is 2 bytes after a block of size 204 alloc'd
==4082==at 0x484063C: malloc (in 
/usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so)
==4082== 
==4082== Invalid write of size 1
==4082==at 0x48464A8: memcpy (in 
/usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so)
==4082==  Address 0x57d0328 is 0 bytes after a block of size 200 alloc'd
==4082==at 0x484063C: malloc (in 
/usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so)
==4082== 

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable'), (99, 'testing'), (10, 'unstable'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.0-20-armmp (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages transmission-daemon depends on:
ii  adduser  3.118
ii  libc62.31-13+deb11u5
ii  libcurl4 7.74.0-1.3+deb11u3
ii  libevent-2.1-7   2.1.12-stable-1
ii  libminiupnpc17   2.2.1-1
ii  libnatpmp1   20150609-7.1
ii  libssl1.11.1.1n-0+deb11u3
ii  libsystemd0  247.3-7+deb11u1
ii  lsb-base 11.1.0
ii  transmission-common  3.00-1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages transmission-daemon recommends:
pn  transmission-cli  

transmission-daemon suggests no packages.

-- Configuration Files:
/etc/transmission-daemon/settings.json [Errno 13] Permission denied: 
'/etc/transmission-daemon/settings.json'

-- no debconf information

Bug#1029161: systemd: Inconsistent values for %j specifier across service and drop-in units

2023-01-18 Thread Michael Biebl


Hi

Am 18.01.23 um 18:21 schrieb Mike:

Package: systemd
Version: 247.3-7+deb11u1
Severity: normal
X-Debbugs-Cc: mike.shaw.nz+deb...@gmail.com

Dear Maintainer,

Under certain circumstances I'm seeing inconsistent values for the %j specifier 
used in service and drop-in units.
To reproduce:

Create a systemd unit /lib/systemd/system/foo@.service as:

 [Unit]
 Description=good old foo

 [Service]
 Type=oneshot
 ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (foo@.service))"

Create a drop-in unit /etc/systemd/system/foo@.service.d/additional.conf as:

 [Service]
 ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (additional.conf))"

Reload the systemd units and run systemctl cat foo@.service.  The output shows 
the drop-in being correctly incorporated:

 # /lib/systemd/system/foo@.service
 [Unit]
 Description=good old foo

 [Service]
 Type=oneshot
 ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (foo@.service))"

 # /etc/systemd/system/foo@.service.d/additional.conf
 [Service]
 ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (additional.conf))"

Now create a symlink which contains a %j specifier:

 sudo ln -sv /lib/systemd/system/foo@.service 
/etc/systemd/system/foo-bar@.service

Reload the systemd units and run systemctl cat foo-bar@.service.  The output is 
identical to that of systemctl cat foo@.service
Now start the service with a %i specifer:

 systemctl start foo-bar@baz.service

The output is:

 ● foo@baz.service - good old foo
  Loaded: loaded (/lib/systemd/system/foo@.service; static)
  Drop-In: /etc/systemd/system/foo@.service.d
  └─additional.conf
  Active: inactive (dead)

 Nov 01 12:10:31 Intel-NUC systemd[1]: Starting good old foo...
 Nov 01 12:10:31 Intel-NUC env[56108]: %i=[baz]   %j=[bar] (from 
foo-bar@baz.service (foo@.service))
 Nov 01 12:10:31 Intel-NUC env[56109]: %i=[baz]   %j=[foo] (from 
foo@baz.service (additional.conf))
 Nov 01 12:10:31 Intel-NUC systemd[1]: foo@baz.service: Succeeded.
 Nov 01 12:10:31 Intel-NUC systemd[1]: Finished good old foo.

This shows that - in a single invocation - the value for %i is constant but the 
value for %j changes from 'bar' to 'foo'.  I would have expected the value of 
%j to be 'bar' throughout.  This may not be a bug, but - IMHO - this changing 
of values is unintuitive and I have been unable to find documentation that 
states the expected behaviour in this situation.  Happy to accept that I have 
confused/abused systemd with my custom /etc/systemd/system/foo-bar@.service 
symlink.



Ideally, such issues should be tested with the latest version of systemd 
(or at least v251) and then reported upstream.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029160: pwmconfig: hangs indefintely if "no correlation" for FAN<->PWM on "minimum PWM value" test

2023-01-18 Thread Linus Lüssing

Package: fancontrol
Version: 1:3.6.0-7.1
Severity: normal
X-Debbugs-Cc: linus.luess...@c0d3.blue

Dear Maintainer,

If pwmconfig detects "no correlation" between the configured pwm1
speed and the resulting output value in fan1_input in my case (due to
the too low DELAY value, as reported in another ticket) and if I then
choose to perform the auto-detection for the "minimum PWM value" then
this hangs indefinitly on:

```
function TestMinStop()
{
[...]
fanspeed=$(cat $faninput)
```

Because $faninput is an empty string. See more detailed output below.

Regards, Linus





*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages fancontrol depends on:
ii  init-system-helpers1.65.2
ii  sysvinit-utils [lsb-base]  3.06-2

fancontrol recommends no packages.

fancontrol suggests no packages.

-- no debconf information


```
$ sudo pwmconfig
# pwmconfig version 3.6.0
This program will search your sensors for pulse width modulation (pwm)
controls, and test each one to see if it controls a fan on
your motherboard. Note that many motherboards do not have pwm
circuitry installed, even if your sensor chip supports pwm.

We will attempt to briefly stop each fan using the pwm controls.
The program will attempt to restore each fan to full speed
after testing. However, it is ** very important ** that you
physically verify that the fans have been to full speed
after the program has completed.

Found the following devices:
   hwmon0 is acpitz
   hwmon1 is BAT0
   hwmon2 is nvme
   hwmon3 is amdgpu
   hwmon4 is AC
   hwmon5 is k10temp
   hwmon6 is thinkpad
   hwmon7 is ath11k_hwmon

Found the following PWM controls:
   hwmon6/pwm1   current value: 0

Giving the fans some time to reach full speed...
Found the following fan sensors:
   hwmon6/fan1_input current speed: 4926 RPM

Warning!!! This program will stop your fans, one at a time,
for approximately 5 seconds each!!!
This may cause your processor temperature to rise!!!
If you do not want to do this hit control-C now!!!
Hit return to continue: 

Testing pwm control hwmon6/pwm1 ...
~~~ i: hwmon6/pwm1, calling: pwmset hwmon6/pwm1 0 (fan1_input: 65535, pwm1: 255)
~~~ i: hwmon6/pwm1, after calling: pwmset hwmon6/pwm1 0 (fan1_input: 65535, 0)
~~~ i: hwmon6/pwm1, after calling: pwmset hwmon6/pwm1 0; sleep 5 (fan1_input: 
4918, 0)
~~~ CURRENT_SPEED: 4918, SPEEDS: 4926
~~~ j in GOODFAN: hwmon6/fan1_input in hwmon6/fan1_input
  hwmon6/fan1_input ... speed was 4926 now 4918
~~~ S: 4918, threshold: 3694, OS: 4926
no correlation

No correlations were detected.
There is either no fan connected to the output of hwmon6/pwm1,
or the connected fan has no rpm-signal connected to one of
the tested fan sensors. (Note: not all motherboards have
the pwm outputs connected to the fan connectors,
check out the hardware database on http://www.almico.com/forumindex.php)

Did you see/hear a fan stopping during the above test (n)? y

Testing is complete.
Please verify that all fans have returned to their normal speed.

The fancontrol script can automatically respond to temperature changes
of your system by changing fanspeeds.
Do you want to set up its configuration file now (y)? y
What should be the path to your fancontrol config file (/etc/fancontrol)? 
Loading configuration from /etc/fancontrol ...

Select fan output to configure, or other action:
1) hwmon6/pwm1
2) Change INTERVAL
3) Just quit
4) Save and quit
5) Show configuration
select (1-n): 1

Devices:
hwmon0 is acpitz
hwmon1 is BAT0
hwmon2 is nvme
hwmon3 is amdgpu
hwmon4 is AC
hwmon5 is k10temp
hwmon6 is thinkpad
hwmon7 is ath11k_hwmon

Current temperature readings are as follows:
hwmon0/temp1_input  20
hwmon2/temp1_input  38
hwmon2/temp2_input  38
hwmon2/temp3_input  38
hwmon3/temp1_input  32
hwmon5/temp1_input  32
hwmon6/temp1_input  32
cat: hwmon6/temp2_input: No such device or address
/usr/sbin/pwmconfig: line 908: let: S= / 1000: syntax error: operand expected 
(error token is "/ 1000")
hwmon6/temp2_input  
hwmon6/temp3_input  32
hwmon6/temp4_input  0
hwmon6/temp5_input  32
hwmon6/temp6_input  32
hwmon6/temp7_input  32
cat: hwmon6/temp8_input: No such device or address
/usr/sbin/pwmconfig: line 908: let: S= / 1000: syntax error: operand expected

Bug#1028691: dask.distributed: FTBFS: unsatisfiable build-dependencies: python3-dask (>= 2022.02.0), python-numpy-doc

2023-01-18 Thread Diane Trout

On Wed, 2023-01-18 at 10:49 +0100, Sebastiaan Couwenberg wrote:
> On 1/18/23 08:38, Sebastiaan Couwenberg wrote:
> > python-numpy-doc has been dropped from the build dependencies in
> > git, 
> > but the package FTBFS due to test failures. Those might be fixed in
> > a 
> > new upstream release, but that may introduce regressions in its
> > rdeps.
> To workaround the two failing tests a patch has been added to mark
> them 
> as xfail.
> 
> The package now builds successfully, but needs more work before I'd
> be 
> comfortable uploading it. Anyone else is free to upload it instead.
> 
> Kind Regards,
> 
> Bas
> 


I've been working on updating dask.distributed to 2022.12.1 to match
the dask version of dask and almost have an version where the tests
pass (or are disabled). I'll probably have it uploaded in 10 - 30
hours.

Diane

Bug#1029049: [PATCH] Backport patch-9.0.1080 to fix keyprotocol option

2023-01-18 Thread Andrea Pappacoda

This fixes the keyprotocol option when using terminals supporting the
kitty keyboard protocol and modifyOtherKeys2 like foot and wezterm.

Closes: #1029049
---
Hi, I can confirm that patch 9.0.1080 fixes the issue described at
.

I've submitted a patch on Salsa at
, if you could
merge it it'd be great!

I'm also emailing the patch with git send-email for your convenience.

Bye :)

 ...sing-xterm-kitty-for-term-causes-pro.patch | 145 +++
 ...he-kitty-terminfo-entry-is-not-wides.patch | 169 ++
 ...087-autocommand-test-sometimes-fails.patch |   2 +-
 debian/patches/series |   2 +
 4 files changed, 317 insertions(+), 1 deletion(-)
 create mode 100644 
debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch
 create mode 100644 
debian/patches/patch-9.0.1080-the-kitty-terminfo-entry-is-not-wides.patch

diff --git 
a/debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch 
b/debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch
new file mode 100644
index 0..899a90815
--- /dev/null
+++ b/debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch
@@ -0,0 +1,145 @@
+From 731d00770d9006e7dab6a66e2ea86603ed5ef212 Mon Sep 17 00:00:00 2001
+From: Bram Moolenaar 
+Date: Sun, 18 Dec 2022 17:47:18 +
+Subject: [PATCH] patch 9.0.1073: using "xterm-kitty" for 'term' causes
+ problems
+
+Problem:Using "xterm-kitty" for 'term' causes problems.
+Solution:   Remove the "xterm-" part when 'term' is set from $TERM.  Detect a
+few kitty-specific properties based on the version response
+instead of the terminal name.
+---
+ runtime/doc/term.txt | 20 
+ src/term.c   | 44 +---
+ src/version.c|  2 ++
+ 3 files changed, 59 insertions(+), 7 deletions(-)
+
+diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
+index f7b65ea74..50ba187ab 100644
+--- a/runtime/doc/term.txt
 b/runtime/doc/term.txt
+@@ -294,6 +294,26 @@ When Vim receives a response to the |t_RV| (request 
version) sequence and it
+ starts with CSI, it assumes that the terminal is in 8-bit mode and will
+ convert all key sequences to their 8-bit variants.
+ 
++  *xterm-kitty* *kitty-terminal*
++The Kitty terminal is a special case.  Mainly because it works different from
++most other terminals, but also because, instead of trying the fit in and make
++it behave like other terminals by default, it dictates how applications need
++to work when using Kitty.  This makes it very difficult for Vim to work in a
++Kitty terminal.  Some exceptions have been hard coded, but it is not at all
++nice to have to make exceptions for one specific terminal.
++
++One of the problems is that the value for $TERM is set to "xterm-kitty".  For
++Vim this is an indication that the terminal is xterm-compatible and the
++builtin xterm termcap entries should be used.  Many other terminals depend on
++this.  However, Kitty is not fully xterm compatible.  The author suggested to
++ignore the "xterm-" prefix and use the terminfo entry anyway, but that
++conflicts with what is needed for other terminals.  Therefore Vim removes the
++"xterm-" prefix from "xterm-kitty" when it comes from $TERM.
++
++Note that using the kitty keyboard protocol is a separate feature, see
++|kitty-keyboard-protocol|.
++
++
+ ==
+ 2. Terminal options   *terminal-options* *termcap-options* *E436*
+ 
+diff --git a/src/term.c b/src/term.c
+index 7483974ac..7a70af450 100644
+--- a/src/term.c
 b/src/term.c
+@@ -2071,6 +2071,12 @@ set_termname(char_u *term)
+ else
+   T_CCS = empty_option;
+ 
++// Special case: "kitty" does not normally have a "RV" entry in terminfo,
++// but we need to request the version for several other things to work.
++if (strstr((char *)term, "kitty") != NULL
++ && (T_CRV == NULL || *T_CRV == NUL))
++  T_CRV = (char_u *)"\033[>c";
++
+ #ifdef UNIX
+ /*
+  * Any "stty" settings override the default for t_kb from the termcap.
+@@ -2599,15 +2605,34 @@ tgoto(char *cm, int x, int y)
+ void
+ termcapinit(char_u *name)
+ {
+-char_u*term;
++char_u*term = name;
+ 
+-if (name != NULL && *name == NUL)
+-  name = NULL;// empty name is equal to no name
+-term = name;
++if (term != NULL && *term == NUL)
++  term = NULL;// empty name is equal to no name
+ 
+ #ifndef MSWIN
++char_u*tofree = NULL;
+ if (term == NULL)
++{
+   term = mch_getenv((char_u *)"TERM");
++
++  // "xterm-kitty" is used for Kitty, but it is not actually compatible
++  // with xterm.  Remove the "xterm-" part to avoid trouble.
++  if

Bug#1029159: linux-headers: dpkg-buildpackage -us -uc crashes while trying to create rt packages

2023-01-18 Thread xevilstar

Package: linux-headers-6.2.0-rc4
Version: 6.2.0-rc4-2
Severity: important
File: linux-headers
X-Debbugs-Cc: vmxevils...@gmail.com

Dear Maintainer,

I am trying to dpkg-buildpackage -us -uc linux-6.2-rc4.tar.gz
Because I strongly want to learn how to contribute.

problems begin on patches

 * Patch debian/dfsg/vs6624-disable.patch does not apply (enforce with -f)
  * Patch debian/dfsg/video-remove-nvidiafb-and-rivafb.patch does not apply 
(enforce with -f)
  * Patch debian/dfsg/video-remove-nvidiafb-and-rivafb.patch does not apply 
(enforce with -f)
  * Patch debian/ia64-hardcode-arch-script-output.patch does not apply (enforce 
with -f)
  * Patch debian/tools-perf-perf-read-vdso-in-libexec.patch does not apply 
(enforce with -f)
  * Patch debian/documentation-drop-sphinx-version-check.patch does not apply 
(enforce with -f)
  * Patch debian/perf-traceevent-support-asciidoctor-for-documentatio.patch 
does not apply (enforce with -f)
  * Patch debian/kbuild-look-for-module.lds-under-arch-directory-too.patch does 
not apply (enforce with -f)
  * Patch 
bugfix/all/radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch
 does not apply (enforce with -f)
  * Patch debian/firmware_class-refer-to-debian-wiki-firmware-page.patch does 
not apply (enforce with -f)
  * Patch 
features/x86/intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch 
does not apply (enforce with -f)
  * Patch debian/btrfs-warn-about-raid5-6-being-experimental-at-mount.patch 
does not apply (enforce with -f)
  * Patch 
features/arm64/dt-bindings-rockchip-Add-Hardkernel-ODROID-M1-board.patch does 
not apply (enforce with -f)
  * Patch 
features/arm64/arm64-dts-rockchip-Add-Hardkernel-ODROID-M1-board.patch does not 
apply (enforce with -f)
  * Patch features/arm64/arm64-dts-rockchip-Add-NOR-flash-to-ODROID-M1.patch 
does not apply (enforce with -f)
  * Patch 
features/arm64/arm64-dts-rockchip-Enable-vop2-and-hdmi-tx-on-ODROID.patch does 
not apply (enforce with -f)
  * Patch 
features/arm64/arm64-dts-rockchip-Enable-HDMI-audio-on-ODROID-M1.patch can be 
reverse-applied
  * Patch features/arm64/arm64-dts-rockchip-Enable-the-GPU-on-ODROID-M1.patch 
can be reverse-applied
  * Patch 
features/arm64/arm64-dts-rockchip-Enable-the-USB-2.0-ports-on-ODROI.patch does 
not apply (enforce with -f)
  * Patch 
features/arm64/arm64-dts-rockchip-Enable-the-USB-3.0-ports-on-ODROI.patch does 
not apply (enforce with -f)
  * Patch 
features/arm64/arm64-dts-rockchip-Add-PCIEe-v3-nodes-to-ODROID-M1.patch can be 
reverse-applied
  * Patch 
features/arm64/arm64-dts-rockchip-Add-IR-receiver-node-to-ODROID-M1.patch can 
be reverse-applied
  * Patch features/x86/x86-make-x32-syscall-support-conditional.patch does not 
apply (enforce with -f)
  * Patch 
features/arm64/quartz64/arm64-dts-rockchip-Enable-GPU-on-SOQuartz-CM4.patch 
does not apply (enforce with -f)
  * Patch 
features/arm64/quartz64/arm64-dts-rockchip-Enable-video-output-and-HDMI-on-S.patch
 does not apply (enforce with -f)
  * Patch 
features/arm64/quartz64/arm64-dts-rockchip-Enable-HDMI-sound-on-SOQuartz.patch 
can be reverse-applied
  * Patch 
features/arm64/quartz64/arm64-dts-rockchip-Enable-PCIe-2-on-SOQuartz-CM4IO.patch
 can be reverse-applied
  * Patch 
features/arm64/quartz64/dt-bindings-arm-rockchip-Add-SOQuartz-Blade.patch does 
not apply (enforce with -f)
  * Patch 
features/arm64/quartz64/arm64-dts-rockchip-Add-SOQuartz-blade-board.patch does 
not apply (enforce with -f)
  * Patch 
features/arm64/quartz64/dt-bindings-arm-rockchip-Add-SOQuartz-Model-A.patch can 
be reverse-applied
  * Patch 
features/arm64/quartz64/arm64-dts-rockchip-Add-SOQuartz-Model-A-baseboard.patch 
does not apply (enforce with -f)
  * Patch 0001-spi-Remove-the-obsolte-u64_stats_fetch_-_irq-users.patch can be 
reverse-applied
  * Patch 0002-net-Remove-the-obsolte-u64_stats_fetch_-_irq-users-d.patch can 
be reverse-applied
  * Patch printk-Bring-back-the-RT-bits.patch does not apply (enforce with -f)
  * Patch 0016-printk-add-infrastucture-for-atomic-consoles.patch does not 
apply (enforce with -f)
  * Patch 0018-printk-avoid-preempt_disable-for-PREEMPT_RT.patch does not apply 
(enforce with -f)
  * Patch x86__Support_for_lazy_preemption.patch does not apply (enforce with 
-f)
  * Patch ARM__Allow_to_enable_RT.patch does not apply (enforce with -f)
  * Patch 
powerpc_stackprotector__work_around_stack-guard_init_from_atomic.patch does not 
apply (enforce with -f)
  * Patch POWERPC__Allow_to_enable_RT.patch does not apply (enforce with -f)

then comes the asciidoctor crash

  * asciidoctor 2.0.18  now has unsafe as default and no -f option
asciidoctor --help
Usage: asciidoctor [OPTION]... FILE...
Convert the AsciiDoc input FILE(s) to the backend output format (e.g., HTML 5, 
DocBook 5, etc.)
Unless specified otherwise, the output is written to a file whose name is 
derived from the input file.
Application log messages are printed to STDERR.
Example: asciidoctor input.adoc

-b, --backend BACKEND

Bug#1029158: rust-bzip2: CVE-2023-22895

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

Hi,

The following vulnerability was published for rust-bzip2.

CVE-2023-22895[0]:
| The bzip2 crate before 0.4.4 for Rust allow attackers to cause a
| denial of service via a large file that triggers an integer overflow
| in mem.rs. NOTE: this is unrelated to the
| https://crates.io/crates/bzip2-rs product.

https://github.com/alexcrichton/bzip2-rs/pull/86
https://github.com/alexcrichton/bzip2-rs/commit/90c9c182cd5a5ebc75810aebd89b347a7bdf590b
 (0.4.4)


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

Please adjust the affected versions in the BTS as needed.

Bug#1029157: rust-tokio: CVE-2023-22466

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

Hi,

The following vulnerability was published for rust-tokio.

I haven't checked this is a Windows-specific issue or whether rust-tokio
as packaged in Debian would also be affected if e.g. operating on a
Samba share:

CVE-2023-22466[0]:
| Tokio is a runtime for writing applications with Rust. Starting with
| version 1.7.0 and prior to versions 1.18.4, 1.20.3, and 1.23.1, when
| configuring a Windows named pipe server, setting `pipe_mode` will
| reset `reject_remote_clients` to `false`. If the application has
| previously configured `reject_remote_clients` to `true`, this
| effectively undoes the configuration. Remote clients may only access
| the named pipe if the named pipe's associated path is accessible via a
| publicly shared folder (SMB). Versions 1.23.1, 1.20.3, and 1.18.4 have
| been patched. The fix will also be present in all releases starting
| from version 1.24.0. Named pipes were introduced to Tokio in version
| 1.7.0, so releases older than 1.7.0 are not affected. As a workaround,
| ensure that `pipe_mode` is set first after initializing a
| `ServerOptions`.

https://rustsec.org/advisories/RUSTSEC-2023-0001.html
https://github.com/tokio-rs/tokio/security/advisories/GHSA-7rrj-xr53-82p7


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

Please adjust the affected versions in the BTS as needed.

Bug#1029156: python3-poetry: ImportError: cannot import name 'CleoError'

2023-01-18 Thread Alex Pyrgiotis

Package: python3-poetry
Version: 1.3.2+dfsg-2
Severity: normal

Dear Maintainer,

Running `poetry install`, I encounter the following error:

Traceback (most recent call last):
  File "/usr/bin/poetry", line 5, in 
from poetry.console.application import main
  File "/usr/lib/python3/dist-packages/poetry/console/application.py",
line 15, in 
from cleo.exceptions import CleoError
ImportError: cannot import name 'CleoError' from 'cleo.exceptions'
(/usr/lib/python3/dist-packages/cleo/exceptions/__init__.py)

The missing class was introduced on python3-cleo >= 1.0.0, whereas the system
has python3-cleo == 1.0.0a5-3. Ideally, by bumping python3-cleo on Debian
Bookworm, Poetry should work again.

Thanks,
Alex

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

Kernel: Linux 6.1.1-arch1-1 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-poetry depends on:
ii  python3 3.10.6-3+b1
ii  python3-cachecontrol0.12.12-2
ii  python3-cleo1.0.0a5-3
ii  python3-crashtest   0.4.1-1
ii  python3-dulwich 0.20.50-1+b1
ii  python3-filelock3.9.0-1
ii  python3-html5lib1.1-3
ii  python3-importlib-metadata  4.12.0-1
ii  python3-jsonschema  4.9.1-3
ii  python3-keyring 23.9.3-2
ii  python3-lockfile1:0.12.2-2.2
ii  python3-packaging   22.0-2
ii  python3-pexpect 4.8.0-4
ii  python3-pkginfo 1.8.2-2
ii  python3-platformdirs2.6.0-1
ii  python3-poetry-core 1.3.2-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-requests-toolbelt   0.10.1-1
ii  python3-shellingham 1.5.0-1
ii  python3-tomli   2.0.1-2
ii  python3-tomlkit 0.11.6-1
ii  python3-urllib3 1.26.12-1
ii  python3-virtualenv  20.17.1+ds-1

python3-poetry recommends no packages.

python3-poetry suggests no packages.

-- no debconf information

Bug#1029155: qemu: CVE-2023-0330

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

Hi,

The following vulnerability was published for qemu.

CVE-2023-0330[0]:
https://bugzilla.redhat.com/show_bug.cgi?id=2160151
Proposed patch: 
https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg03411.html

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

Please adjust the affected versions in the BTS as needed.

Bug#1029154: swift: CVE-2022-47950

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

Hi,

The following vulnerability was published for swift.

CVE-2022-47950:
OSSA-2023-001: Arbitrary file access through custom S3 XML entities

Sébastien Meriot (OVH) reported a vulnerability in Swift's S3 XML
parser. By supplying specially crafted XML files an authenticated user
may coerce the S3 API into returning arbitrary file contents from the
host server resulting in unauthorized read access to potentially
sensitive data; this impacts both s3api deployments (Rocky or later),
and swift3 deployments (Queens and earlier, no longer actively
developed). Only deployments with S3 compatibility enabled are
affected.

https://www.openwall.com/lists/oss-security/2023/01/17/1




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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1011346: Enabling V4L2 Driver in Chromium Builds

2023-01-18 Thread Andres Salomon


Thanks for reopening!

Unfortunately it fails to build on all arm architectures including 
arm64:


https://buildd.debian.org/status/fetch.php?pkg=chromium=arm64=107.0.5304.68-1=1666793161=0

linux/media/av1-ctrls.h is some weirdo header that's only available in 
a chromeos environment. Since upstream only builds arm on that, they 
don't seem to have noticed. Someone needs to test a build on arm* with 
that inclusion removed; I suspect they also included stuff from that 
header.


For my reference, the commit that added that header is this one - 
bbde6817bd3105d7fffa29f704cb0a8a4185317c

https://chromium-review.googlesource.com/c/chromium/src/+/3880774

On Wed, Jan 18 2023 at 04:14:38 PM +0100, Bastian Germann 
 wrote:

Control: found -1 107.0.5304.87-1

On Tue, 06 Sep 2022 16:47:13 -0400 Andres Salomon wrote:

This is enabled in 105.0.5195.102-1.
This was disabled again. Can we reenable it at least for arm64 if it 
only fails on armel/armhf?

Bug#1029153: virtualbox: CVE-2023-21884 CVE-2023-21885 CVE-2023-21886 CVE-2023-21889 CVE-2023-21898 CVE-2023-21899

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

Hi,

The following vulnerabilities were published for virtualbox.

Fixed in 7.0.6

CVE-2023-21884[0]:
| Vulnerability in the Oracle VM VirtualBox product of Oracle
| Virtualization (component: Core). Supported versions that are affected
| are Prior to 6.1.42 and prior to 7.0.6. Easily exploitable
| vulnerability allows high privileged attacker with logon to the
| infrastructure where Oracle VM VirtualBox executes to compromise
| Oracle VM VirtualBox. Successful attacks of this vulnerability can
| result in unauthorized ability to cause a hang or frequently
| repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base
| Score 4.4 (Availability impacts). CVSS Vector:
| (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).


CVE-2023-21885[1]:
| Vulnerability in the Oracle VM VirtualBox product of Oracle
| Virtualization (component: Core). Supported versions that are affected
| are Prior to 6.1.42 and prior to 7.0.6. Easily exploitable
| vulnerability allows low privileged attacker with logon to the
| infrastructure where Oracle VM VirtualBox executes to compromise
| Oracle VM VirtualBox. While the vulnerability is in Oracle VM
| VirtualBox, attacks may significantly impact additional products
| (scope change). Successful attacks of this vulnerability can result in
| unauthorized read access to a subset of Oracle VM VirtualBox
| accessible data. Note: Applies to Windows only. CVSS 3.1 Base Score
| 3.8 (Confidentiality impacts). CVSS Vector:
| (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N).


CVE-2023-21886[2]:
| Vulnerability in the Oracle VM VirtualBox product of Oracle
| Virtualization (component: Core). Supported versions that are affected
| are Prior to 6.1.42 and prior to 7.0.6. Difficult to exploit
| vulnerability allows unauthenticated attacker with network access via
| multiple protocols to compromise Oracle VM VirtualBox. Successful
| attacks of this vulnerability can result in takeover of Oracle VM
| VirtualBox. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and
| Availability impacts). CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).


CVE-2023-21889[3]:
| Vulnerability in the Oracle VM VirtualBox product of Oracle
| Virtualization (component: Core). Supported versions that are affected
| are Prior to 6.1.42 and prior to 7.0.6. Easily exploitable
| vulnerability allows low privileged attacker with logon to the
| infrastructure where Oracle VM VirtualBox executes to compromise
| Oracle VM VirtualBox. While the vulnerability is in Oracle VM
| VirtualBox, attacks may significantly impact additional products
| (scope change). Successful attacks of this vulnerability can result in
| unauthorized read access to a subset of Oracle VM VirtualBox
| accessible data. CVSS 3.1 Base Score 3.8 (Confidentiality impacts).
| CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N).


CVE-2023-21898[4]:
| Vulnerability in the Oracle VM VirtualBox product of Oracle
| Virtualization (component: Core). Supported versions that are affected
| are Prior to 6.1.42 and prior to 7.0.6. Easily exploitable
| vulnerability allows low privileged attacker with logon to the
| infrastructure where Oracle VM VirtualBox executes to compromise
| Oracle VM VirtualBox. Successful attacks of this vulnerability can
| result in unauthorized ability to cause a hang or frequently
| repeatable crash (complete DOS) of Oracle VM VirtualBox. Note: Applies
| to VirtualBox VMs running Windows 7 and later. CVSS 3.1 Base Score 5.5
| (Availability impacts). CVSS Vector:
| (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).


CVE-2023-21899[5]:
| Vulnerability in the Oracle VM VirtualBox product of Oracle
| Virtualization (component: Core). Supported versions that are affected
| are Prior to 6.1.42 and prior to 7.0.6. Easily exploitable
| vulnerability allows low privileged attacker with logon to the
| infrastructure where Oracle VM VirtualBox executes to compromise
| Oracle VM VirtualBox. Successful attacks of this vulnerability can
| result in unauthorized ability to cause a hang or frequently
| repeatable crash (complete DOS) of Oracle VM VirtualBox. Note: Applies
| to VirtualBox VMs running Windows 7 and later. CVSS 3.1 Base Score 5.5
| (Availability impacts). CVSS Vector:
| (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-21884
https://www.cve.org/CVERecord?id=CVE-2023-21884
[1] https://security-tracker.debian.org/tracker/CVE-2023-21885
https://www.cve.org/CVERecord?id=CVE-2023-21885
[2] https://security-tracker.debian.org/tracker/CVE-2023-21886
https://www.cve.org/CVERecord?id=CVE-2023-21886
[3] https://security-tracker.debian.org/tracker/CVE-2023-21889

Bug#1026499: rows: diff for NMU version 0.4.1-5.1

Control: tags 1026499 + patch
Control: tags 1026499 + pending

Dear maintainer,

I've prepared an NMU for rows (versioned as 0.4.1-5.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru rows-0.4.1/debian/changelog rows-0.4.1/debian/changelog
--- rows-0.4.1/debian/changelog	2022-01-09 16:14:00.0 +0200
+++ rows-0.4.1/debian/changelog	2023-01-18 18:19:46.0 +0200
@@ -1,3 +1,10 @@
+rows (0.4.1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build and test depend on python3-magic. (Closes: #1026499)
+
+ -- Adrian Bunk   Wed, 18 Jan 2023 18:19:46 +0200
+
 rows (0.4.1-5) unstable; urgency=medium
 
   * debian/control: Remove XB-Python-Version field.
diff -Nru rows-0.4.1/debian/control rows-0.4.1/debian/control
--- rows-0.4.1/debian/control	2022-01-09 15:36:28.0 +0200
+++ rows-0.4.1/debian/control	2023-01-18 18:18:48.0 +0200
@@ -13,6 +13,7 @@
python3-coverage,
python3-ipdb,
python3-lxml,
+   python3-magic,
python3-mock,
python3-nose,
python3-nose-yanc,
diff -Nru rows-0.4.1/debian/tests/control rows-0.4.1/debian/tests/control
--- rows-0.4.1/debian/tests/control	2021-10-11 19:12:59.0 +0300
+++ rows-0.4.1/debian/tests/control	2023-01-18 18:19:41.0 +0200
@@ -1,6 +1,7 @@
 Test-Command: excludes=$(cat debian/tests/excludes) && cp -r tests/ ${AUTOPKGTEST_TMP} && cd ${AUTOPKGTEST_TMP} && python3 -m nose --verbose $excludes
 Depends: locales-all,
  python3-lxml,
+ python3-magic,
  python3-mock,
  python3-nose,
  python3-openpyxl,

Bug#1029152: systemd: Revisit disabling of bump fs.nr_open, bump-proc-sys-fs-nr-open=false

2023-01-18 Thread Jesse Hathaway

Package: systemd
Version: 252.4-1
Severity: normal
X-Debbugs-Cc: je...@mbuki-mvuki.org

Dear Maintainer,

Would it be possible to revisit the decision to disable
bump-proc-sys-fs-nr-open, from commit,
084e84e33a403868b7f84159da745689e2ff0ba9 ^[1]?

This recently caused me trouble when running a minikube instance on my
laptop which used a bunch of file descriptors. It would be nice to not
need to write sysctl values to bump it higher. Are there any paths to
reverting this patch? Thanks for maintaining systemd!!

[1]: 
https://salsa.debian.org/systemd-team/systemd/-/commit/084e84e33a403868b7f84159da745689e2ff0ba9.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.7-1.1+b2
ii  libblkid1  2.38.1-4
ii  libc6  2.36-8
ii  libcap21:2.66-3
ii  libcryptsetup122:2.6.0-2
ii  libfdisk1  2.38.1-4
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.0
ii  libmount1  2.38.1-4
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b2
ii  libselinux13.4-1+b4
ii  libssl33.0.7-1
ii  libsystemd-shared  252.4-1
ii  libsystemd0252.4-1
ii  libzstd1   1.5.2+dfsg2-3
ii  mount  2.38.1-4

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.4-1
ii  systemd-timesyncd [time-daemon]  252.4-1

Versions of packages systemd suggests:
ii  libfido2-11.12.0-2
ii  libqrencode4  4.1.1-1
ii  libtss2-esys-3.0.2-0  3.2.1-2
ii  libtss2-mu0   3.2.1-2
pn  libtss2-rc0   
ii  policykit-1   122-1
ii  polkitd   122-1
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
ii  systemd-resolved  252.4-1
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.4-1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252.4-1
ii  libpam-systemd 252.4-1
ii  udev   252.4-1

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

-- no debconf information

Bug#1029151: mysql-8.0: CVE-2023-21863 CVE-2023-21867 CVE-2023-21868 CVE-2023-21869 CVE-2023-21870 CVE-2023-21871 CVE-2023-21873 CVE-2023-21875 CVE-2023-21876 CVE-2023-21877 CVE-2023-21878 CVE-2023-21