Bug#1050060: src:pd-iemmatrix: fails to migrate to testing for too long: autopkgtest regression on i386

[Paul Gevers]

Source: pd-iemmatrix
Version: 0.3.2-4
Severity: serious
Control: close -1 0.3.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050059: src:libconfig-model-perl: fails to migrate to testing for too long: autopgktest regression

[Paul Gevers]

Source: libconfig-model-perl
Version: 2.152-1
Severity: serious
Control: close -1 2.153-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:libconfig-model-perl has been trying to 
migrate for 31 days [2]. Hence, I am filing this bug. The version in 
unstable doesn't pass it's own autopkgtest.


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

[Ansgar]

On Fri, 2023-08-18 at 22:45 +0200, Vincent Lefevre wrote:
> On 2023-08-18 07:35:33 +0200, Ansgar wrote:
> > Please investigate why "usrmerge" is not installed (I assume this is an
> > upgraded system).  Or, if it is installed, why /bin, /sbin, /lib* are
> > not symlinks to their respective counterparts in /usr.
> 
> I've not upgraded init-system-helpers to 1.65.2 yet

Please don't file RC bugs if you intentionally break your system.
Probably not non-RC bugs either.

Ansgar

Bug#1043058: libesmtp6: missing Breaks: libesmtp5

[Salvatore Bonaccorso]

Hi 

Disclaimer, not the maintainer here, but maintainer of a package which
would get autoremoved.

On Sat, Aug 05, 2023 at 02:17:53PM +0200, Andreas Beckmann wrote:
> Package: libesmtp6
> Version: 1.1.0-3
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts replaces-without-breaks
> 
> Hi,
> 
> during a test with piuparts and DOSE tools I noticed your package causes
> removal of files that also belong to another package.
> This is caused by using Replaces without corresponding Breaks.
> 
> This leaves a crippled libesmtp5 package installed on certain upgrade
> paths.
> 
> This is a serious bug violating policy 7.6, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
> and also see the footnote that describes this incorrect behavior:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#id13
> 
> The libesmtp6 package has the following relationships with libesmtp5:
> 
>   Conflicts: n/a
>   Breaks:n/a
>   Replaces:  libesmtp5
> 
> >From the attached log (scroll to the bottom...):
> 
> 3m29.5s ERROR: FAIL: debsums reports modifications inside the chroot:
>   debsums: missing file /usr/lib/esmtp/sasl-cram-md5.so (from libesmtp5 
> package)
>   debsums: missing file /usr/lib/esmtp/sasl-login.so (from libesmtp5 package)
>   debsums: missing file /usr/lib/esmtp/sasl-plain.so (from libesmtp5 package)
> 
> This wasn't noticed as long as libesmtp6 still provided the files, but
> that no longer seems to be the case.

AFAICS, libesmtp5 is very long gone already from Debian, and the check
you are doing is from stretch to weeezy, as well for a very long time
obsoleted now.

Usually one would drop constraints which are not anymore relevant for
suites in Debian, so I wonder if we here not simply can drop the
Replaces relation which is irrelevant in any supported suites. 

Regards,
Salvatore

Bug#1050051: openstreetmap-carto: depends on obsolete package fonts-noto-hinted

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 8/19/23 01:46, daijohn.bes...@allfreemail.net wrote:

The package openstreetmap-carto-common depends on the obsolete metapackage 
fonts-noto-hinted.


This is fixed in git.

Kind Regards,

Bas

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

Bug#1050058: libgnutls28-dev: broken symlink: libgnutlsxx.so -> libgnutlsxx.so.30.0.0

[Paul Wise]

Package: libgnutls28-dev
Version: 3.8.1-3
Severity: normal
File: /usr/lib/x86_64-linux-gnu/libgnutlsxx.so
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

libgnutls28-dev 3.8.1-3 introduced a broken symlink:
   
   /usr/lib/x86_64-linux-gnu/libgnutlsxx.so -> libgnutlsxx.so.30.0.0

This appears to be because the libgnutlsxx functionality switched
to a header-only library and removing the symlink was forgotten.

Here is some information about the symlink:

   $ adequate libgnutls28-dev
   libgnutls28-dev:amd64: broken-symlink 
/usr/lib/x86_64-linux-gnu/libgnutlsxx.so -> libgnutlsxx.so.30.0.0
   $ readlink /usr/lib/x86_64-linux-gnu/libgnutlsxx.so
   libgnutlsxx.so.30.0.0
   $ chase /usr/lib/x86_64-linux-gnu/libgnutlsxx.so
   chase: /usr/lib/x86_64-linux-gnu/libgnutlsxx.so.30.0.0: No such file or 
directory
   $ apt-file search gnutlsxx
   libgnutls28-dev: /usr/include/gnutls/gnutlsxx.h
   libgnutls28-dev: /usr/lib/x86_64-linux-gnu/libgnutlsxx.a
   libgnutls28-dev: /usr/lib/x86_64-linux-gnu/libgnutlsxx.so

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libgnutls28-dev depends on:
ii  libc6-dev [libc-dev]  2.37-7
ii  libgnutls-dane0   3.8.1-3
ii  libgnutls-openssl27   3.8.1-3
ii  libgnutls30   3.8.1-3
ii  libidn2-dev   2.3.4-1
ii  libp11-kit-dev0.25.0-4
ii  libtasn1-6-dev4.19.0-3
ii  nettle-dev3.9.1-2

libgnutls28-dev recommends no packages.

Versions of packages libgnutls28-dev suggests:
ii  gnutls-bin  3.8.1-3
pn  gnutls-doc  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1049999: vagrant: the future of packaging vagrant in Debian

[Lucas Nussbaum]

Hi,

This license change is so disappointing...

On 18/08/23 at 08:07 -0300, Antonio Terceiro wrote:
> > Plan B.
> > 
> > - Drop vagrant because of that changed licence and no need to
> >   keep older vagrant.
> > - No vagrant avaiable in Debian. Just use upstream's package.
> 
> I think keeping a stale version of vagrant in the archive is worse than
> telling people to just use upstream packages.

A follow-up question, especially in the case of Plan B, is: what do we
do about Debian Vagrant images provided on Vagrant Cloud
(https://app.vagrantup.com/debian/) ?

A/ continue to maintain them. But as the main uploader of those images
   in the recent times, I might not continue to maintain them, especially
   if I move to another tool for my own uses, so we might need to look
   for other volunteers.
B/ stop maintaining them
   B.1/ ... and remove existing images from the 'debian' Vagrant Cloud
   account
   B.2/ ... and leave the 'debian' Vagrant Cloud account as it is
   currently

I don't think B.2 is a good idea.

> Hopefully, being burned a second time will teach me to not put my
> volunteer time in non-copyleft packages provided by a single
> corporation.

Note that the fact that Vagrant was using a non-copyleft license is not
entirely relevant. The same relicensing could be achieved by
organizations using a copyleft licence with a copyright transfer
agreement for external contributions. (I suspect that this is how it was
achieved for other Hashicorp products, but I haven't checked).

Lucas


signature.asc
Description: PGP signature

Bug#913997: hi

[Luna Jernberg]

hi?

Den fre 18 aug. 2023 kl 23:00 skrev Kenza :
>
> hi

Bug#1050057: clamav: CVE-2023-20197 CVE-2023-20212

[Salvatore Bonaccorso]

Source: clamav
Version: 1.0.1+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.103.8+dfsg-0+deb11u1

Hi,

The following vulnerabilities were published for clamav.

CVE-2023-20197[0]:
| A vulnerability in the filesystem image parser for Hierarchical File
| System Plus (HFS+) of ClamAV could allow an unauthenticated, remote
| attacker to cause a denial of service (DoS) condition on an affected
| device.This vulnerability is due to an incorrect check for
| completion when a file is decompressed, which may result in a loop
| condition that could cause the affected software to stop responding.
| An attacker could exploit this vulnerability by submitting a crafted
| HFS+ filesystem image to be scanned by ClamAV on an affected device.
| A successful exploit could allow the attacker to cause the ClamAV
| scanning process to stop responding, resulting in a DoS condition on
| the affected software and consuming available system resources.
| For a description of this vulnerability, see the ClamAV blog .


CVE-2023-20212[1]:
| A vulnerability in the AutoIt module of ClamAV could allow an
| unauthenticated, remote attacker to cause a denial of service (DoS)
| condition on an affected device. This vulnerability is due to a
| logic error in the memory management of an affected device. An
| attacker could exploit this vulnerability by submitting a crafted
| AutoIt file to be scanned by ClamAV on the affected device. A
| successful exploit could allow the attacker to cause the ClamAV
| scanning process to restart unexpectedly, resulting in a DoS
| condition.


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-20197
https://www.cve.org/CVERecord?id=CVE-2023-20197
[1] https://security-tracker.debian.org/tracker/CVE-2023-20212
https://www.cve.org/CVERecord?id=CVE-2023-20212
[1] https://blog.clamav.net/2023/07/2023-08-16-releases.html

Regards,
Salvatore

Bug#986707: rt4-db-mysql: should declare an incompatibility with mysql 8

[Andrew Ruthven]

The problem I can see with conflicting with mysql-server-8.0 is that a user
could have both MySQL and MariaDB installed on the same server, as they
should be able to co-exist (listen on different ports).

If we conflict, then we prevent that.

The issue is that in Debian default-mysql-client and virtual-mysql-client
(and -server) depend on mariadb, but in Ubuntu they depend on mysql.

Perhaps we should explicitly depend on the mariadb packages. Thinking about
this is a bit further, this does seem the best option.

RT 5.0.4 supports MySQL 8, which is now in Debian Unstable, so this'd only
apply to the RT4 packages now.

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Marcelo Gondim]

Hi Bernhard,

Em 18/08/2023 19:19, Bernhard Schmidt escreveu:

Control: tags -1 confirmed upstream
Control: forward -1 https://github.com/phaag/nfsen/issues/19
Control: found -1 1.7.1-1

On 31/07/23 08:16 AM, Marcelo Gondim wrote:

Hi,


The commit you mention is quite intrusive (a lot of source cleanup mixed
with the bugfix) and does not apply to 1.7.1

So, I tested some more.

With my installation (still on Bullseye) the official backport of 1.7.1
somewhat works. A few random channels in a profile sometimes show 0 and
throw errors like

Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-BER-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-MUC-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
ptr error - elementHeader > eor

when running a query against it, but it mostly works.

The patch you mentioned can be applied with just a single manually fixed
reject, it builds cleanly and the testsuite also works. But with this
patch it actually is worse, no data is ever created by nfprofile. No
error in the logs.

Plain 1.7.2 does not work either, same issue.

On 1.7.2 the patch you mentioned does not apply either, it has other
rejects. Looking at the changes src/lib/nffile.c had since 1.7.2 has
been released I would not be comfortable to do this.

The current git head appears to work fine, but that's not an option for
stable.

Looking at the commits I think it's virtually impossible to get a clean
"this minimally intrusive commit fixes the bug on top of the 1.7.1 in
stable", so I believe the only viable option would be

- upload current snapshot to unstable fixing this bug
- as soon as there is a 1.7.3 release, upload that and provide a
   bookworm-backport for people using nfsen


I agree with you. The best thing would be to wait for the release of 
version 1.7.3 and make it available in the Bookworm backport.






Bernhard

Bug#993905: lxc-create fails GPG checkserver due to keyserver depreciation

[Mathias Gibbens]

Control: fixed -1 1:4.0.6-2+deb11u1

  The bullseye package was fixed in bug #991615.

  At the time this bug was opened, oldstable was buster -- is there any
interest in trying to backport the fix to now oldoldstable, or shall we
close out this bug?

Mathias


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

Bug#1050056: libz-mingw-w64 build-depends on pev

[David da Silva Polverari]

Source: libz-mingw-w64
Version: 1.2.13+dfsg-1
Severity: normal

Dear Maintainer(s),

Your package build-depends on pev, but it has been renamed to readpe due
to upstream changes.

readpe is still in experimental. I will wait 15 days before uploading it
to unstable. Please let me know if you need more time, or if you had any
problems with it. Any feedback/testing is appreciated.

Regards,

David.

Bug#1050055: forensics-extra depends on pev

[David da Silva Polverari]

Source: forensics-extra
Version: 2.44
Severity: normal

Dear Maintainer(s),

Your package depends on pev, but it has been renamed to readpe due to
upstream changes.

readpe is still in experimental. I will wait 15 days before uploading it
to unstable. If you need more time, please let me know.

Regards,

David.

Bug#1042194: netavark: FTBFS: unsatisfiable build-dependencies: librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~), librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~)

[Reinhard Tartler]

Thank you so much for these patches.

May I ask you to NMU this and and potentially aardvark-dns as necessary? -- I'm 
about to start traveling, and will have very limited internet access. No need 
to wait for NMU delays or things. Your diff looks great to me!

best,
-rt

On 8/10/23 8:37 PM, Peter Green wrote:

tags 1042194 +patch
thanks


During a rebuild of all packages in sid, your package failed to build
on amd64.


The attached patch makes netavark build again (note: some of the packages
it depends on have only just been accepted, so it may be a little time
before binaries are available in sid).

Bug#993380: lxc FTCBFS: compilation error in non-default code path

[Mathias Gibbens]

  Looking at http://crossqa.debian.net/src/lxc, it appears that this
was fixed in version 4.0.11. Helmut, can you confirm? If so, let's
close this bug.

Mathias


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

Bug#1050054: fonts-noto-unhinted: is empty package, remove it from debian if not needed for anything anymore

[Daijohn . Bester]

Package: fonts-noto-unhinted
Severity: normal

Dear Maintainer,

the package fonts-noto-unhinted is an empty package that does not appear
to serve any purpose anymore. Please remove it from debian if that is
the case.

Bug#1042399: I confirm there is a problem

[Владимир]

When is the fix planned to be rolled out. The bug is critical, on some 
systems the file growth reaches about 10GB per day, and at the moment it 
can only be cleaned by recreating the database and files. I tried 
downloading and uploading the /usr/sbin/mariadbd binary, but it looks 
like it's not just about it, since it doesn't even start, you probably 
need to re-upload all related binaries. This procedure does not inspire 
confidence.

Bug#1050053: xml2rfc: recommends empty package fonts-noto-unhinted

[Daijohn . Bester]

Source: xml2rfc
Severity: normal

Dear Maintainer,

The package xml2rfc recommends an empty package fonts-noto-unhinted.

Please change the dependency to the appropriate package instead. Thank you.

Bug#1050048: [request-tracker-maintainers] Bug#1050048: request-tracker5: depends on obsolete package fonts-noto-hinted

[Andrew Ruthven]

Control: tag -1 + pending

Upload currently blocked while I try and find the dependency that is causing
our tests to fail.

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Bug#355635: Separator

[Be RheaL]

“Bug” is due to operational issues related to lack of oversight, inadequate 
guidance (on my part sorry devs) disagreements with certain projects especially 
ones that automatically inferred a “unified minds” going against my very core 
principles of integrity boosting regulatory compliance strategy that has goals 
of creating a network of several SSO API hard shell secure conclaves with 
multifunctional extensions designed to maximize efficiency and limit external 
interference/ vulnerabilities 
{R-o-R cores} iPhone

Bug#1046733: lxc: Fails to build source after successful build

[Mathias Gibbens]

Control: tags -1 + pending

  Fix pushed to salsa, and will be included in the next upload.

Mathias


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

Bug#1050052: kodi-data: recommends obsolete package fonts-noto-hinted

[Daijohn . Bester]

Package: kodi-data
Severity: normal

Dear Maintainer,

The package kodi-data recommends the obsolete metapackage fonts-noto-hinted.

Please change the dependency to the appropriate package instead. Thank you.

Bug#1050051: openstreetmap-carto: depends on obsolete package fonts-noto-hinted

[Daijohn . Bester]

Source: openstreetmap-carto
Severity: normal

Dear Maintainer,

The package openstreetmap-carto-common depends on the obsolete metapackage 
fonts-noto-hinted.

Please change the dependency to the appropriate package instead. Thank you.

Bug#1027864: dh-python: use pyproject by default instead of deprecated setup.py

[Andres Salomon]

On Mon, 30 Jan 2023 12:12:48 -0400 Stefano Rivera  
wrote:

> Hi Drew (2023.01.07_07:56:43_-0400)
>
> I think this is something worth a try in early trixie.
> It'll likely be a change of default mode, and require packages to
> explicitly the request the setuptools mode.
>
> > It matters in particular for python modules which are rebuilt with
> > different configurations, for different debian python packages from
> > the same source.  For instance petsc4py provides separate real and 
complex

> > number builds of its python module.
>
> Does that matter? They get built once, each. Both temporary 
directories

> don't need to exist at the same time.


I'm just curious if switching to pyproject will require packagers (that 
is, users of dh-python) to change anything in their python packages, or 
if this change will be completely isolated inside of dh-python?

Bug#1050050: plasma-integration: recommends obsolete package fonts-noto-hinted

[Daijohn . Bester]

Source: plasma-integration
Severity: normal

Dear Maintainer,

The package plasma-integration recommends the obsolete metapackage 
fonts-noto-hinted.

Please change the dependency to the appropriate package instead. Thank you.

Bug#1050049: lldb: Lldb stars with the error "ModuleNotFoundError: No module named 'lldb.embedded_interpreter'"

[ramon]

Package: lldb
Version: 1:14.0-55.6
Severity: important

Dear Maintainer,

After installing lldb, one runs it 

$ lldb
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'


The reason is the disagreement in paths for the python integration between lldb 
and the package. 
Running lldb -P, the path expected by the debugger is 
/usr/lib/local/lib/python3.11/dist-packages

But the actual path for the python files in the package python3-lldb-14 is
/usr/lib/llvm-14/lib/python3.11/dist-packages/


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

Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages lldb depends on:
ii  lldb-14  1:14.0.6-12

lldb recommends no packages.

lldb suggests no packages.

-- no debconf information

Bug#1050048: request-tracker5: depends on obsolete package fonts-noto-hinted

[Daijohn . Bester]

Source: request-tracker5
Severity: normal

Dear Maintainer,

The package request-tracker5 depends on the obsolete metapackage 
fonts-noto-hinted.

Please change the dependency to the appropriate package instead. Thank you.

Bug#1050047: request-tracker4: depends on obsolete package fonts-noto-hinted

[Daijohn . Bester]

Source: request-tracker4
Severity: normal

Dear Maintainer,

The package request-tracker4 depends on the obsolete metapackage 
fonts-noto-hinted.

Please change the dependency to the appropriate package instead. Thank you.

Bug#1032345: [INTL:ro] Romanian debconf templates translation of lxc

[Mathias Gibbens]

Control: tags -1 + pending

  Thanks for the contribution! It will be included in the next upload
of lxc.

Mathias


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

Bug#1050046: slic3r-prusa: depends on obsolete package fonts-noto-hinted

[Daijohn . Bester]

Source: slic3r-prusa
Version: 2.6.0+dfsg-2
Severity: normal

Dear Maintainer,

The package prusa-slicer depends on the obsolete metapackage fonts-noto-hinted.

Please change the dependency to the appropriate package instead. Thank you.

Bug#1043415: netdata: Integrated web server displays "File does not exist, or is not accessible: "

[jimmy]

I'm seeing this too with netdata-core 1.42.0-1.

Looks like the allow-symlinks patch was broken by
https://github.com/netdata/netdata/pull/15143 (and then
https://github.com/netdata/netdata/pull/15247) and was then obsoleted by
https://github.com/netdata/netdata/pull/15287.

Bug#1050045: systemd-nspawn fails to start systemd >=253 in QEMU-emulated container

[MichaIng]

Package: systemd
Version: 254.1-2

since systemd 253 was merged into Sid/unstable and Trixie/testing, 
systemd-nspawn fails to boot Sid and Trixie containers with foreign 
architectures via qemu-user-static and binfmt:

---
Spawning container rootfs on /root/rootfs.
Press Ctrl-] three times within 1s to kill container.
systemd 254.1-2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR 
+IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL 
+ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 
-PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD 
-BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)

Detected virtualization systemd-nspawn.
Detected architecture arm64.

Welcome to Debian GNU/Linux trixie/sid!

Hostname set to .
Failed to fork off sandboxing environment for executing generators: 
Invalid argument

[!!] Failed to start up manager.
Exiting PID 1...
Container rootfs failed with error code 255.
---

I am not sure whether this has to be addressed in systemd, 
systemd-container or qemu-user-static, but I am reporting it here as the 
issue appeared with systemd 253 (container end) and it fails the same 
way with various systemd-nspawn and qemu-user-static versions from 
Debian Bullseye, Bookworm, Trixie, Sid as well as Ubuntu Jammy.


Here is how to replicate on any Debian or Ubuntu host:
---
sudo apt -y install debootstrap dbus systemd-container qemu-user-static 
binfmt-support

sudo systemctl restart systemd-binfmt
debootstrap --arch=arm64 --variant=minbase --include=systemd-sysv trixie 
./rootfs

systemd-nspawn -bD rootfs
---
The same works well when doing the same with the bookworm suite (systemd 
252) or when booting a trixie or sid system with natively supported 
architecture, hence without QEMU.


The same error has been reported here: 
https://github.com/systemd/systemd/issues/26474
A fix was merged with systemd 254, but it does not work for this case. 
Also, the reported case seems to require CAP_SYS_ADMIN, while 
systemd-nspawn passes this capability anyway, and adding 
"--capability=CAP_SYS_ADMIN" hence has no effect either.


Does someone have an idea what the reason for this is? Shall this better 
be reported upstream, or does it need to be fixed in QEMU?


Best regards,

Micha

Bug#1042757: ublock-origin: embded javascript lib

[Markus Koschany]

Am Montag, dem 31.07.2023 um 11:56 + schrieb Bastien Roucariès:
> Source: ublock-origin
> Severity: serious
> Justification: not prefered form of modification
> 
> Dear Maintainer,
> 
> src/lib include a few library that are already packaged for debian.
> 
> per se it is not a serious bug, but we should try if possible after testing
> to
> use packaged version
> 
> The serious bug is due that for instance punycode was not in prefered form of
> modification due to being wepackaged (transpiled) in order to be an ES
> module.
> 
> They may be other transpiled package in this subdirectory

Hello Bastien,

thanks for the report. I have reviewed the src/lib directory and replaced the
embedded Javascript libraries of csstree and js-beautify with Debian's system
libraries. I also added the source file of hsluv to debian/missing-sources and
documented the licenses of these three Javascript libraries in
debian/copyright.

I decided against replacing punycode because punycode.js in ublock-origin looks
like the preferred form for me. The file is not minified and can be edited
without problems. I believe you were referring to hsluv instead. I believe this
issue is fixed in version 1.51.0+dfsg-2 soon.

Regards,

Markus



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

Bug#1049976: lxc: fail to start /etc/init.d/lxc-net when LXC_IPV6_NAT="true"

[Mathias Gibbens]

Control: tags -1 + pending

  Thanks for the report. I've cherry-picked that fix back into the
packaging for bookworm, and it should be included in the next point
release.

Mathias


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

Bug#1047041: python3-lxc: Fails to build source after successful build

[Mathias Gibbens]

  This seems to be caused by `./PKG-INFO` and `./python3_lxc.egg-info/`
being automatically generated when the upstream source is imported.
They don't exist in the upstream tarball, but something's generating
them when `gbp import-orig python3-lxc_.orig.tar.gz` is
invoked. And then during the build `./python3_lxc.egg-info/PKG-INFO` is
modified, which triggers this bug.

  My first thought was that these files shouldn't even be in the git
repo, but I'm not entirely sure how they're being generated in the
first place.

Mathias


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

Bug#1016558: O: muse-el

[Manphiz]

Nicholas D Steeves  writes:

> Hello,
>
> Sorry for the delay, I hadn't realised that I had forgotten to actually
> send this draft:
>
> On Fri, 11 Aug 2023 at 22:09, Manphiz  wrote:
>
>> Nicholas D Steeves  writes:
>
>> Now also uploaded my PGP keys to https://keys.openpgp.org/.  pgp.mit.edu
>> has been unstable for a while, so a good alternative is definitely a
>> plus :)
>
> For sure, and also, it's been the default keyserver in Debian since 2019
> (gnupg 2.2.17-1) ;) Yeah, I've also noticed pgp.mit.edu has gotten
> slower and more unreliable than in the past.  P.S. This might be a bit
> pedantic, but doesn't your key have five redundant signatures that could
> be deleted?
>

Should have removed the redundant signatures and reuploaded to
https://keys.openpgp.org, though I don't think I had 5 signatures on the
same IDs? Anyway, PTAL.

>> >> I: muse-el source: patch-not-forwarded-upstream
>> >> [debian/patches/0005-convert-a-muse-init.el-example-to-UTF-8.patch]
>> >>
>> >> I wonder whether you would also like to forward this patch upstream.
>> >
>> > If you really want to, go ahead, but I'm not interested in the FSF's
>> > identity verification for copyright assignment process, so this might
>> > end up as a futile effort.  In light of this, a "hey, we have a UTF8
>> > conversion patch...would you like to convert your copy to UTF8 either
>> > with or without our patch" might be smoother.  If you happen to have
>> > have done FSF copyright assignment paperwork, please go ahead and
>> > claim ownership of that trivial patch.
>>
>> Forwarded upstream.  As my pull request got merged fairly quickly I'm
>> slightly more optimistic here.
>
> Hmm, it appears that these patches were forwarded to a fork.  The Source
> is set to git://repo.or.cz/muse-el.git (debian/and the Homepage is set
> to https://www.gnu.org/software/emacs-muse/index.html (debian/control).
> As the new maintainer it's your right to switch upstream sources, but I
> recommend you ask some team members and #debian-mentors on irc or the
> mailing list about what the downsides to this may be; the mailing list
> archives might have a record of someone else asking a question like
> this.  I'll support your decision once you let me know you've
> investigated and considered.

So I did ask around #debian-emacs and #debian-mentors and the replies I
got was to better figure out the situation with the upstream.  So I
opened an issue on the github repo[1] and waiting for response.

>
> What is your intention here?  Are you rebasing our package onto this
> fork, or are you using the fork as a code dump, or something else?
>

Well to be honest I didn't realize the github one was a fork as the
d/watch file had been pointing there.

Also from your other mail:

> I found that this UTF8 issue was already fixed upstream:
> 
>   @@ -412,11 +433,11 @@
>   
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?h=externals/muse=be347db7f1ad56f0384f76011bfd148ff3352610
> 
> and note that it's now an official GNU project (via copyright assignment)
> 
>   Copyright (C) 2004-2020 Free Software Foundation, Inc.

So it should be clear that the Savannah one should be considered the
canonical upstream.  I'll update my question on github to ask for
whether Alex want to forward the patches in his repo to Savannah as
well.

Also as a result, I've marked the patch as "Forwarded: not-needed".

>> > I'm happy to sponsor from git when you finalise the changelog, but if
>> > ever you want to get some hands-on experience with dput (or dput-ng),
>> > then practise uploading to https://mentors.debian.net/.
>>
>> Uploaded using dput.  Would be great to have you to take a look as
>> well.  Thanks!
>
> The aspects relating to the upload look good to me.
>
> Oh, there's one more thing that needs to be fixed before we upload:
> Bug #1048114

Attempted to fix it in [2] where I just regenerated the changing file in
sbuild.

I have also rebuilt and reuploaded the source.changes to mentors[3].  PTAL.

Thanks!

>
> Take care,
> Nicholas

-- 
Manphiz

[1] https://github.com/alexott/muse/issues/16
[2] 
https://salsa.debian.org/emacsen-team/muse-el/-/commit/f5c217162d9c6f45c971cec2b8c70b2794bb77fe
[3] https://mentors.debian.net/package/muse-el/


signature.asc
Description: PGP signature

Bug#1043282: freeradius: TLS-Client-Cert-Common-Name contains incorrect value

[Bernhard Schmidt]

Control: forward -1 https://github.com/FreeRADIUS/freeradius-server/issues/4785
Control: fixed -1 3.2.3+dfsg-1

On 08/08/23 02:59 PM, Åke Holmlund wrote:

> We have a setup with TLS authentication where we use the CN of the
> client certificate ti check in LDAP if that CN has access to our VPN
> service. This was working fine in bullseye but breaks in bookworm. The
> reason is that TLS-Client-Cert-Common-Name no longer contains the CN
> from the client certificate but the CN from the CA certificate.
> 
> This is a known bug in freeradius 3.2.1 (see
> https://github.com/FreeRADIUS/freeradius-server/issues/4785) and is
> fixed in 3.2.2. I REALLY hope this can be fixed ASAP in bookworm
> because we have had to skip the LDAP check to get our VPN working
> again and that is not a good thing.

I have cherry-picked both commits mentioned in the GH issue, could you
please try the binaries at

https://people.debian.org/~berni/freeradius/

Thanks,
Bernhard

Bug#1041096: Unable to boot and reboot

[Rudy Godoy]

Hello, 

I’ve faced exactly the same problem as originally reported by Andreas. Had to 
manually fix the config.txt, after figuring out seven ACT LED blinks meant 
unable to find kernel(8).img

It has also affected the reboot process in some way, making the screen go blank 
and the ACT LED blink twice. Though this could be related to a networking 
(WiFi) issue I was trying to improve before getting into trouble.

Best regards.

RudyGodoy.com

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Bernhard Schmidt]

Control: tags -1 confirmed upstream
Control: forward -1 https://github.com/phaag/nfsen/issues/19
Control: found -1 1.7.1-1

On 31/07/23 08:16 AM, Marcelo Gondim wrote:

Hi,

> > The commit you mention is quite intrusive (a lot of source cleanup mixed
> > with the bugfix) and does not apply to 1.7.1

So, I tested some more.

With my installation (still on Bullseye) the official backport of 1.7.1
somewhat works. A few random channels in a profile sometimes show 0 and
throw errors like

Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-BER-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-MUC-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
ptr error - elementHeader > eor

when running a query against it, but it mostly works.

The patch you mentioned can be applied with just a single manually fixed
reject, it builds cleanly and the testsuite also works. But with this
patch it actually is worse, no data is ever created by nfprofile. No
error in the logs.

Plain 1.7.2 does not work either, same issue.

On 1.7.2 the patch you mentioned does not apply either, it has other
rejects. Looking at the changes src/lib/nffile.c had since 1.7.2 has
been released I would not be comfortable to do this.

The current git head appears to work fine, but that's not an option for
stable.

Looking at the commits I think it's virtually impossible to get a clean
"this minimally intrusive commit fixes the bug on top of the 1.7.1 in
stable", so I believe the only viable option would be 

- upload current snapshot to unstable fixing this bug
- as soon as there is a 1.7.3 release, upload that and provide a
  bookworm-backport for people using nfsen

Bernhard

Bug#1049374: krb5 1.18.3-6+deb11u4 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1049374 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: krb5
Version: 1.18.3-6+deb11u4

Explanation: fix free of uninitialised pointer [CVE-2023-36054]

Bug#1049373: krb5 1.20.1-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1049373 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: krb5
Version: 1.20.1-2+deb12u1

Explanation: fix freeing of uninitialised pointer [CVE-2023-36054]

Bug#1050044: bullseye-pu: package rar/2:5.5.0-1

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org

Hello,

[ Reason ]

I would like to update rar in bullseye because it is affected by
CVE-2022-30333. This issue has been fixed in all other suites already
and it makes sense to address this problem in bullseye too. A backport
is the only sensible approach because rar is closed source.

[ Impact ]

The RAR archiver would continue to be vulnerable.

[ Tests ]

Unfortunately rar is just a non-free binary without source code, so I
had to rely on manual testing. Since there was not enough information
available to reproduce the problem, I created a normal rar archive
with random files and folders and another one which consisted of
several symlinks and files with relative paths. The extract operation
seems to work correctly in both cases.

[ Risks ]

I'm not aware of any major changes like different command switches
etc. but rar is non-free and closed source, so there is always some
kind of risk.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

I don't attach a debdiff because of the closed source binary of rar.

Bug#1050030: Similar reproduction

[Elliott Mitchell]

affects 1050030 src:xen
quit

I'm seeing a similar situation, though instead using FreeBSD/x86 in the
VM.

For FreeBSD the bootloader appears to operate normally, but something
fails quickly after loading the kernel:

Loading kernel...
/boot/kernel/kernel text=0x18aa98 text=0xdfd150 text=0x675154 data=0x140 
data=0x1c38e8+0x43b718 0x8+0x18fe70+0x8+0x1ae449/
Loading configured modules...
/boot/entropy size=0x1000
/etc/hostid size=0x25
staging 0xe3e0 (not copying) tramp 0xe351b000 PT4 0xe3512000
Start @ 0x8038b000 ...
EFI framebuffer information:
addr, size 0xf000, 0x1d5000
dimensions 800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00

I believe all these messages are from FreeBSD's bootloader.  The first
message from the kernel should be "---<>---", yet that message
never shows.  Xen shows the domain spinning on a single processor which
makes me believe the FreeBSD kernel has loaded, panic()ed and the
debugger is loaded (but there is no VGA console).


>From reading the available information I suspect Tianocore/EDK2 may have
tried to move some functionality to a distinct build and neither setup
quite works.  Notably there is now a "OvmfPkg/OvmfXen.dsc" build
configuration.  The OVMF.fd for Qemu for Xen functionality may have been
moved /here/.  There might also be an attempt at functionality similar to
"ArmVirtPkg/ArmVirtXen.dsc" (Debian 978595) for x86.


-- 
(\___(\___(\__  --=> 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#1008136: lxcfs takes 2 or 3 CPU cores constantly

[Matthew Darwin]

bookworm seems better. Issue can be closed.

On 2023-08-18 16:27, Mathias Gibbens wrote:

Control: tags -1 + moreinfo

   Tagging with moreinfo. As this was reported against the version of
lxcfs in the now oldstable release, without additional information or
confirmation that the problem still affects the version of lxcfs in
bookworm, this bug will be closed in a few months.

Mathias

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

[Vincent Lefevre]

On 2023-08-18 07:35:33 +0200, Ansgar wrote:
> This seems the be the real issue:
> 
> +---
> | Debian Release: trixie/sid
> | [...]
> | merged-usr: no
> +---[ https://bugs.debian.org/1049969#5 ]
> 
> /bin *must* be a symlink to /usr/bin, so /usr/bin/run-parts must exist
> and cron's PATH is sufficient.
> 
> Please investigate why "usrmerge" is not installed (I assume this is an
> upgraded system).  Or, if it is installed, why /bin, /sbin, /lib* are
> not symlinks to their respective counterparts in /usr.

I've not upgraded init-system-helpers to 1.65.2 yet as there are
still unresolved major issues with usrmerge:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=usrmerge

My machines are very old (2015), and there is some risk to break things
(I've actually been in the process to replace them for several months,
but there are issues with the French administration, and this takes
time).

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

Bug#946179: [lxcfs] lxcfs tries to delete systemd cgroup folders, fails stopping lxc

[Mathias Gibbens]

Control: tags -1 + moreinfo

  Tagging with moreinfo. This bug was opened against the version of
lxcfs in stretch, which is now oldoldoldstable. Since so much has
changed since then, without additional information or confirmation that
the problem still affects the version of lxcfs in bookworm, this bug
will be closed in a few months.

Mathias


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

Bug#856393: lxcfs: error message from the kernel: cgroup: new mount options do not match the existing superblock, will be ignored

[Mathias Gibbens]

Control: tags -1 + moreinfo

  Tagging with moreinfo. The last confirmation of this bug was from
buster, which is now oldoldstable. Since so much has changed since
then, without additional information or confirmation that the problem
still affects the version of lxcfs in bookworm, this bug will be closed
in a few months.

Mathias


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

Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers

[Adam D. Barratt]

Control: close -1 5.10.191-1

On Fri, 2023-05-26 at 17:36 +0200, Ben Hutchings wrote:
> On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote:
[..]
> > > Julien Cristau reported a regression in ccp - the
> > > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered.  I
> > > > believe
> > > > this was introduced by the above commit, which depends on:
> > > > 
> > > > commit 8347b99473a313be6549a5b940bc3c56a71be81c
> > > > Author: Sean Christopherson 
> > > > Date:   Tue Apr 6 15:49:48 2021 -0700
> > > >  
> > > > crypto: ccp: Play nice with vmalloc'd memory for SEV
> > > > command structs
> > > > 
> > > > Ben.
> > > > 
> > > 
> > > Thanks for letting me know, now queued up.
> > 
> > Nope, now dropped, it breaks the build :(
> 
> I've now looked further and found that we need both:
> 
> d5760dee127b crypto: ccp: Reject SEV commands with mismatching
> command buffer
> 8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV
> command structs
> 
> (Not yet tested; I'll ask Julien if he can do that.)
> 

Having just upgraded several affected debian.org nodes, I'm happy to
confirm that the 5.10.191-1 kernel resolves the issue for us.

Regards,

Adam

Bug#1008136: lxcfs takes 2 or 3 CPU cores constantly

[Mathias Gibbens]

Control: tags -1 + moreinfo

  Tagging with moreinfo. As this was reported against the version of
lxcfs in the now oldstable release, without additional information or
confirmation that the problem still affects the version of lxcfs in
bookworm, this bug will be closed in a few months.

Mathias


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

Bug#1050043: fonts-noto-core: Add fonts-noto-mono to Depends

[Gunnar Hjalmarsson]

Package: fonts-noto-core
Version: 20201225-1
X-Debbugs-CC: j...@debian.org, fab...@debian.org, raphael.hal...@gmail.com

Since a while Noto is the default font for latin scripts in 
fontconfig-config:


https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785

The Debian fontconfig-config package includes an alternative Depends 
list with reasonably complete base font packages, enforcing at least one 
of those packages to be installed in order to prevent a broken system. 
At my suggestion fonts-noto-core was recently prepended to that list:


https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde

However, as was pointed out in , I 
overlooked that fonts-noto-core does not include monospace fonts, i.e. 
it does not really qualify as a complete base font package. To address 
that issue, I suggest that fonts-noto-mono is added to Depends in 
fonts-noto-core.


An alternative solution might be to create a meta package, e.g. 
fonts-noto-base, which would depend on fonts-noto-core and 
fonts-noto-mono, and replace fonts-noto-core with fonts-noto-base in the 
Depends list of fontconfig-config. Personally I think that would be to 
overdo it, though.


--
Rgds,
Gunnar Hjalmarsson

Bug#1046160: lxcfs: Fails to build source after successful build

[Mathias Gibbens]

Control: tags -1 + pending
  Fix pushed to salsa, and will be included in the next upload.

Mathias


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

Bug#1050042: gnupg2: in man pages, U+2010 HYPHEN instead of U+002D HYPHEN-MINUS

[Vincent Lefevre]

Source: gnupg2
Version: 2.2.40-1.1
Severity: normal

In various man pages, there are many U+2010 HYPHEN characters while
U+002D HYPHEN-MINUS would be expected.

For instance, for the gpg(1) man page:

   If you are going to verify detached signatures, make sure that the pro‐
   gram  knows about it; either give both filenames on the command line or
   use ‘‐’ to specify STDIN.
   ^^^ this one is incorrect

   For scripted or other unattended use of gpg make sure to  use  the  ma‐
   chine‐parseable  interface  and  not the default interface which is in‐
   tended for direct use by humans.  The machine‐parseable interface  pro‐
   vides a stable and well documented API independent of the locale or fu‐
   ture  changes of gpg.  To enable this interface use the options ‐‐with‐
   colons and ‐‐status‐fd.  For certain operations the option ‐‐command‐fd
   may come handy too.  See this man page and the file ‘DETAILS’  for  the
   specification  of the interface.  Note that the GnuPG ‘‘info’’ pages as
   well as the PDF version of the GnuPG manual features a chapter on unat‐
   tended use of GnuPG.  As an alternative the library GPGME can  be  used
   as a high‐level abstraction on top of that interface.

Ditto for all hyphens that appear in options.
Ditto in the list of options in section COMMANDS.
The program name "gpg‐agent" is also incorrect.
etc.

The gpg-agent(1) man page, like most gpg-* ones, has the same issue.

The gpg-zip(1) man page seems correct, except for 
in section AUTHOR.

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

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

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

Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x

[Andreas Beckmann]

On 18/08/2023 20.49, Paul Gevers wrote:

Hi Jonathan,

On 18-08-2023 18:48, Jonathan Wiltshire wrote:

I'm therefore inclined to make a stable update sooner than the point
release. How does this text sound?

| ca-certificates-java, a package to update the cacerts JKS keystore used
| for many java runtimes, may fail to install alongside OpenJDK because
| of a circular dependency. This is a regression in Debian 11 and 12.


The regression is that the problem seems to occur more frequently. I'm 
not convinced it's an actual regression as the circular dependency 
problem is known from *before* the bullseye release.


The actual regression is in openjdk-XX which removed some undocumented 
undefined behavior. This was not neccessarily on purpose.
ca-certificates-java relied on the fact that an unconfigured 
openjdk-jre-XX-headless could be used for its configuration, which is no 
longer the case. ca-certificates-java now has to pre-configure java to a 
usable state if ca-certificates-java gets configured before 
openjdk-XX-jre-headless was ever configured. That may happen due to the 
circular dependency.


The current fix may actually cause dpkg trigger cycles (due to the 
circular dependency), but that's a rare event. IIRC in my piuparts tests 
of this fix I encountered one new trigger cycle, while fixing about 
50-250 installation failures due to the ca-certificates-java failure.
(exact numbers are hard to estimate since that failure may not propagate 
transitively: if installing foo which depends on ca-certifictes-java 
fails, installing bar which depends on foo (and therefore 
ca-certificates-java, too) may succeed if apt swaps the configuration 
order of ca-certificates-java and openjdk-XX-jre-headless.


In the long run I'd like to bring the changes to bookworm that break the 
dependency cycle and postpone the ca-certificates-java setup to a 
trigger that runs after openjdk-xx-jre-headless got configured.
(That won't work for bullseye, since there is too much infrastructure 
missing in the ca-certificates stack, but in bookworm everything should 
be prepared, it was just not enabled.)


backporting ca-certificates-java from sid to bookworm needs careful 
auditing of the versions in package relationships and my last attempt on 
that failed since stable-pu didn't have a sufficiently new openjdk, yet.



Andreas

Bug#1050041: ITP: python-django-dynamic-fixture -- create dynamic model instances for testing purposes

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-dynamic-fixture
  Version : 3.1.2
  Upstream Contact: Paulo Cheque 
* URL : https://github.com/paulocheque/django-dynamic-fixture
* License : Expat or Apache-2
  Programming Lang: Python
  Description : create dynamic model instances for testing purposes

 Django Dynamic Fixture (DDF) is a complete and simple library to create dynamic
 model instances for testing purposes.
 .
 It lets you focus on your tests, instead of focusing on generating some dummy
 data which is boring and pollutes the test source code.
 .
 It exists to solve the anti-pattern of Static Fixtures and Factory objects.
 .
 Features:
  * Highly customizable: you can customize fields recursively
  * Deals with unique=True
  * Deals with cyclic dependencies (including self references)
  * Deals with many to many relationship (common M2M or M2M with additional
data, i.e. through=’table’)
  * Deals with custom fields (especially if the custom field inherits from a
django field)
  * Support for parallel tests
  * Deals with auto calculated attributes
  * It is easy to debug errors

I intend to maintain this as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmTfyKgRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqVQwf9EOgSZczWWY6gWGoxPhb7oXlrQsr6C9zj
xUyvZ12/zaUN3axHFK1N1cVa4T6L6gwU1rao24Y4vnj84p9WSwitMts/0hfQxqKC
tz1dwoYGUtYiwoG4LieaPlbBENflF/vsidCK2XRO+qkYQVcCDc+6Tkd++xyAL09q
nYf7CXiQmwInBDNF5J7WMzr3nZ+HiNL4FzlNNvxwFJB5zLTiaX/14ILDTHbtYB50
xzzkC/rAPhw0AWdtFJhvUFkxLw5aXilrQZsFif/syeOwQKUDo7rAdtrn8Hjti0ak
lkp6M+oA0BPs1VTiXrsgnwPxlau6Bo3X969BeAQkkO6YqWhsSas9DA==
=AZZe
-END PGP SIGNATURE-

Bug#1049379: bookworm-pu: package freedombox/23.6.2+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Mon, Aug 14, 2023 at 06:30:02PM -0400, James Valleroy wrote:
> FreedomBox has a feature to automatically install new versions of freedombox 
> package from backports. This feature is optional but recommended, so most 
> FreedomBox users will have it enabled.
> 
> This was working as expected for bullseye-backports. However for 
> bookworm-backports, there is a change in the Release file where the Suite and 
> Codename are no longer the same. The configuration produced by FreedomBox is 
> no longer valid due to this change (bug #1043969).

Please go ahead.

Thanks,

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

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

Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x

[Jonathan Wiltshire]

On Fri, Aug 18, 2023 at 08:49:55PM +0200, Paul Gevers wrote:
> Hi Jonathan,
> 
> On 18-08-2023 18:48, Jonathan Wiltshire wrote:
> > I'm therefore inclined to make a stable update sooner than the point
> > release. How does this text sound?
> > 
> > | ca-certificates-java, a package to update the cacerts JKS keystore used
> > | for many java runtimes, may fail to install alongside OpenJDK because
> > | of a circular dependency. This is a regression in Debian 11 and 12.
> 
> The regression is that the problem seems to occur more frequently. I'm not
> convinced it's an actual regression as the circular dependency problem is
> known from *before* the bullseye release.

That's fair; in which case:

| ca-certificates-java, a package to update the cacerts JKS keystore used
| for many java runtimes, may fail to install alongside OpenJDK because
| of a circular dependency. This update resolves the issue.



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

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



signature.asc
Description: PGP signature

Bug#1036644:

[James Hutchinson]

I am also affected by this, running Arch Linux on my Intel Nuc 8i3beh. I've
seen these same random mce broadcast error kernel panics (only capturable
via netconsole) ever since upgrading from the 5.15.x lts kernel series to
the 6.1.x series - latest I've tried is 6.1.45 and currently back to the
5.15.x branch for stability.

I update my Arch Linux installation on a rolling weekly basis so am right
upto date for all packages including intel-microcode. As others have
experienced, the problem seems more prominent (though not exclusively) when
the machine is Idle.

>>Maybe lowering "check_interval" or "monarch_timeout" in machinecheck will
cause the bug to strike more often, so a git bisect could be possible!? Or
raising those values may workaround the problem!?

I had similar thoughts and stumbled upon

/sys/kernel/debug/mce/fake_panic

Writing 1 to here will cause a fake panic such that the mce event will be
logged to dmesg but panic+reboot will not occur.

Interestingly we then get a couple more messages that possibly suggest that
the core lockup is somehow related to i915 as others suspect

[5.848032] mce: CPUs not responding to MCE broadcast (may include false
positives): 1,3
[5.848032] mce: CPUs not responding to MCE broadcast (may include false
positives): 1,3
[5.848035] mce: [Hardware Error]: Fake kernel panic: Timeout: Not all
CPUs entered broadcast exception handler
[5.848039] Disabling lock debugging due to kernel taint
[5.885355] mce: [Hardware Error]: Machine check events logged
[5.888283] mce: [Hardware Error]: CPU 2: Machine Check Exception: 5
Bank 4: ba0011000402
[5.892145] mce: [Hardware Error]: RIP !INEXACT! 10:
{fwtable_read32+0x7d/0x220 [i915]}
[5.897167] mce: [Hardware Error]: TSC d44e32bae41d
Might be interesting to see if the
RIP !INEXACT! 10: {fwtable_read32+0x7d/0x220 [i915]}
 message occurs for others with fake_panic enabled.

Unfortunately, fake_panic does not appear to be a workaround from my
experience; since the cores reported in the mce event become locked up
thereafter; such that any task scheduled onto those cores becomes locked-up
- for example I ran the sensors command which hung and eventually.

77798.629123] watchdog: BUG: soft lockup - CPU#2 stuck for 21s!
[sensors:1229265]
[77798.631037] Modules linked in: coretemp drivetemp netconsole
xt_conntrack ipt_REJECT nf_reject_ipv4 xt_connmark xt_mark iptable_mangle
xt_comment xt_addrtype iptable_raw wireguard curve25519_x86_64
libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libcurve25519_generic
libchacha ip6_udp_tunnel udp_tunnel rfcomm uinput xt_nat xt_tcpudp
iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
libcrc32c iptable_filter veth ts2020 snd_sof_pci_intel_cnl
snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation
soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof
snd_sof_utils soundwire_bus snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core
intel_rapl_msr intel_rapl_common snd_soc_sst_ipc intel_tcc_cooling
snd_soc_sst_dsp x86_pkg_temp_thermal intel_powerclamp
snd_soc_acpi_intel_match snd_soc_acpi kvm_intel snd_soc_core
snd_hda_codec_hdmi snd_compress kvm si2157 ac97_bus snd_hda_codec_realtek
snd_pcm_dmaengine snd_hda_codec_generic ledtrig_audio
[77798.631090]  irqbypass si2168 crct10dif_pclmul snd_hda_intel
crc32_pclmul polyval_clmulni snd_intel_dspcfg polyval_generic gf128mul
ghash_clmulni_intel snd_intel_sdw_acpi snd_hda_codec sha512_ssse3
dvb_usb_dvbsky dvb_usb_v2 btusb m88ds3103 snd_hda_core dvb_core btrtl btbcm
iTCO_wdt videobuf2_vmalloc snd_hwdep videobuf2_memops videobuf2_common
aesni_intel btintel crypto_simd snd_pcm intel_pmc_bxt btmtk cryptd
snd_timer rapl intel_cstate mei_pxp mei_hdcp iTCO_vendor_support ee1004 snd
videodev intel_uncore bluetooth mei_me e1000e intel_wmi_thunderbolt
i2c_i801 wmi_bmof soundcore pcspkr i2c_smbus mei mc i2c_mux ecdh_generic
intel_pch_thermal ir_rc6_decoder rc_rc6_mce ite_cir acpi_pad acpi_tad
mac_hid cfg80211 rfkill crypto_user loop fuse dm_mod bpf_preload ip_tables
x_tables ext4 crc32c_generic crc16 mbcache jbd2 mmc_block i915 drm_buddy
intel_gtt nvme rtsx_pci_sdmmc drm_display_helper mmc_core nvme_core
crc32c_intel cec xhci_pci rtsx_pci nvme_common video xhci_pci_renesas ttm
wmi
[77798.641974]  [last unloaded: i2c_dev]
[77798.656901] CPU: 2 PID: 1229265 Comm: sensors Tainted: G   M
   6.1.39-1-lts-custom-015e51c #1 0c9d39d05dfd27e4ed0b0da78692e6ddc0d0b631
[77798.659471] Hardware name: Intel(R) Client Systems NUC8i3BEH/NUC8BEB,
BIOS BECFL357.86A.0089.2021.0621.1343 06/21/2021
[77798.662012] RIP: 0010:smp_call_function_single+0xfe/0x140
[77798.664509] Code: 25 28 00 00 00 75 51 c9 c3 cc cc cc cc 48 89 e6 48 89
54 24 18 4c 89 44 24 10 e8 4d fe ff ff 8b 54 24 08 83 e2 01 74 0b f3 90
<8b> 54 24 08 83 e2 01 75 f5 eb b9 8b 05 89 b4 5d 02 85 c0 0f 85 65
[77798.667074] RSP: 0018:ad160582fcc0 EFLAGS: 0202
[77798.669635] RAX:  RBX: ad160582fd6c RCX:

Bug#1041282: jtreg6 - okay to upload upstream version 6.2+1?

[tony mancill]

On Wed, Aug 16, 2023 at 09:28:39AM +1200, Vladimir Petko wrote:
> Hi,
> 
>  The build.xml is not supported by the upstream, so I have updated the
> patch to include rule changes to use the provided Makefile[1].
> 
> Changes:
>   * Use Makefile to build jtreg (LP: #2031041).
> - Use --release option in Makefile compile options.
> - d/p/*: drop build.xml patches.
> - d/control: add libguice-java, zip.

Hello Vladimir, hi Emmanuel:

Vladimir, thank you for this patch (and others).  I applied it to the
current source repo and rebuild all of the build r-deps before I
realized that the source repo contains 6.2+1 [1] (not 6.1+2), which
hasn't been uploaded.

Are there any considerations or concerns about going ahead with an
upload of 6.2+1?  As I said, I was able to build openjdk-11, -17, and
-19 with that version.

Thanks,
tony

[1] 
https://salsa.debian.org/java-team/jtreg/-/commit/18fe40fc470b04bc735b425bba250db61340fcb3


signature.asc
Description: PGP signature

Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x

[Paul Gevers]

Hi Jonathan,

On 18-08-2023 18:48, Jonathan Wiltshire wrote:

I'm therefore inclined to make a stable update sooner than the point
release. How does this text sound?

| ca-certificates-java, a package to update the cacerts JKS keystore used
| for many java runtimes, may fail to install alongside OpenJDK because
| of a circular dependency. This is a regression in Debian 11 and 12.


The regression is that the problem seems to occur more frequently. I'm 
not convinced it's an actual regression as the circular dependency 
problem is known from *before* the bullseye release.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050040: /usr/bin/bup: "bup fuse" process lingers after unmounting

[Rob Leslie]

Package: bup
Version: 0.33.2-1~deb12u1
Severity: normal
File: /usr/bin/bup

Dear Maintainer,

When using "bup fuse", after unmounting the directory, the "bup fuse"
process lingers in the background and does not exit on its own.

> % ps x | grep fuse
>  327078 pts/7S+ 0:00 grep fuse
> % bup fuse /tmp/bup
> % mountpoint /tmp/bup
> /tmp/bup is a mountpoint
> % umount /tmp/bup
> % mountpoint /tmp/bup
> /tmp/bup is not a mountpoint
> zsh: exit 32mountpoint /tmp/bup
> % ps x | grep fuse   
>  331964 ?Ss 0:00 bup fuse /tmp/bup
>  338467 pts/7S+ 0:00 grep fuse
> % kill 331964

I don't believe this behavior existed in Debian bullseye; the "bup fuse"
process would exit normally after the directory was unmounted.


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

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

Versions of packages bup depends on:
ii  git   1:2.39.2-1.1
ii  libacl1   2.3.1-3
ii  libc6 2.36-9+deb12u1
ii  libpython3.11 3.11.2-6
ii  libreadline8  8.2-1.3
ii  par2  0.8.1-3
ii  python3   3.11.2-1+b1
ii  python3-pylibacl  0.7.0-2
ii  python3-pyxattr   0.8.1-1

Versions of packages bup recommends:
ii  bup-doc  0.33.2-1~deb12u1
ii  python3-fuse 2:1.0.5-1+b3
ii  python3-tornado  6.2.0-3

bup suggests no packages.

-- no debconf information

Bug#1050038: foomuuri: Package does not include any documentation

[Jan Prunk]

Package: foomuuri
Version: 0.19-2~bpo12+1
Severity: wishlist
X-Debbugs-Cc: janpr...@gmail.com

Dear Maintainer,

Package does not include any documentation inside /usr/share/doc/foomuuri/ .
Creating a file with mentioning (pointing to) the package official wiki would 
be usefull.
https://github.com/FoobarOy/foomuuri/wiki/

Best regards,
Jan

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

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

Versions of packages foomuuri depends on:
ii  nftables  1.0.6-2+deb12u1
ii  python3   3.11.2-1+b1
ii  python3-dbus  1.3.2-4+b1
ii  python3-gi3.42.2-3+b1
ii  python3-requests  2.28.1+dfsg-1
ii  python3-systemd   235-1+b2

Versions of packages foomuuri recommends:
ii  fping  5.1-1

Versions of packages foomuuri suggests:
ii  foomuuri-firewalld  0.19-2~bpo12+1

-- no debconf information

Bug#1050039: traceroute: Exit code is not reliable nor documented

[Alessandro Vesely]

Package: traceroute
Version: 1:2.1.0-2+deb11u1
Severity: normal

Dear Maintainer,

I resend this from Devuan, because the package is not forked.

I've been using traceroute to monitor network state of the server for years.
It is called for each interface by a cron job running a few times per hour.
Since yesterday, an interface stopped working, but the job never noticed it.
Manually calling traceroute only shows the (natted) modem interface:

:~# ip addr show eth1r
3: eth1r:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 00:26:55:e0:d0:e8 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1r
   valid_lft forever preferred_lft forever
inet6 fe80::226:55ff:fee0:d0e8/64 scope link 
   valid_lft forever preferred_lft forever

:~# traceroute -4 -n -i eth1r -m 4 -s 192.168.1.254 185.204.135.186
traceroute to 185.204.135.186 (185.204.135.186), 4 hops max, 60 byte packets
 1  192.168.1.1  0.235 ms  0.282 ms  0.289 ms
 2  * * *
 3  * * *
 4  * * *

Exit code is 0.  In fact recvmsg reports no error.  The relevant calls are:
23495 sendto(14, "@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", 32, 0, NULL, 0) = 32
23495 recvmsg(3, {msg_name={sa_family=AF_INET, sin_port=htons(33434), 
sin_addr=inet_addr("185.204.135.186")}, msg_namelen=28->16, 
msg_iov=[{iov_base="@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", iov_len=1280}], 
msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, 
cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1692345052, tv_usec=96190}}, 
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]}, 
{cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, 
ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, 
offender={sa_family=AF_INET, sin_port=htons(0), 
sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104, 
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 32
23495 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(33435), 
sin_addr=inet_addr("185.204.135.186")}, msg_namelen=28->16, 
msg_iov=[{iov_base="@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", iov_len=1280}], 
msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, 
cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1692345052, tv_usec=96276}}, 
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]}, 
{cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, 
ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, 
offender={sa_family=AF_INET, sin_port=htons(0), 
sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104, 
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 32
23495 recvmsg(5, {msg_name={sa_family=AF_INET, sin_port=htons(33436), 
sin_addr=inet_addr("185.204.135.186")}, msg_namelen=28->16, 
msg_iov=[{iov_base="@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_", iov_len=1280}], 
msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, 
cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1692345052, tv_usec=96277}}, 
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]}, 
{cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, 
ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, 
offender={sa_family=AF_INET, sin_port=htons(0), 
sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104, 
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 32
23495 +++ exited with 0 +++

The modem obviously needs a reset.  The point is that I was expecting
traceroute to detect that, since the interface doesn't work.  If this
is not a bug in the code, it is in the documentation, tagged 11 October
2006, which doesn't mention exit code at all.


Thanks
Ale


-- System Information:
Debian Release: 11.1
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-24-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages traceroute depends on:
ii  libc6  2.31-13+deb11u6

traceroute recommends no packages.

traceroute suggests no packages.

-- no debconf information

Bug#1037579: still ftbfs on arm64 and armhf

[Emanuele Rocca]

Hi Matthias,

On 2023-08-18 06:46, Matthias Klose wrote:
> still ftbfs on arm64 and armhf. would it be possible to pay attention to
> build failures after uploads, or even better to pay attention until the
> package migrates?

See https://bugs.debian.org/1037579#43

We are currently packaging the last upstream of both arm-compute-library
and armnn, they should build fine with GCC-13.

Bug#1023810: as if it were anything new

[Alex Volkov]

Just another act of sabotage against "init-system diversity" in Debian, no news 
at all. What was wrong with plain old /var/locl/acct, FFS?

Bug#1023810: Workaround

[Alex Volkov]

As a workaround, set LOCKFILE=/var/lock/acct in your /etc/defaults/acct.

Editing /etc/init.d/acct directly is less desirable, as Debian maintainters 
feeling too righteous are known to delete init.d scripts they deemed 
"obsolete" without any warning, while config files in /etc/defaults are 
relatively safe.

(I got my /var stuffed with ever-growing /var/log/pacct as the rotation 
stopped because of that stupid "subsys" shit. If this is not a sabotage, then 
what it is?)

Bug#1050037: RM: dipy [s390x] -- ANAIS; Little-endian buffer not supported on big-endian compiler

[Étienne Mollier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dipy

Hi ftpmaster,

dipy currently fails to build from source on a couple of release
architectures.  I have some fixes pending upload to get support
for arm64, ppc64el, riscv64 and possibly other unreleased debian
ports.  But tests on big endian architectures are also failing
with the following error:

>   ???
E   ValueError: Little-endian buffer not supported on big-endian 
compiler

Please kindly consider removing dipy from the s390x unstable
distribution.

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

PS: hope this will not be a duplicate, I didn't get feedback for
my initial message, and I suspect I erroneously sent the initial
message through a black hole instead of mail-submit, sorry about
that.  But it should be okay given the timing of feedback on the
tnseq-transit bug.


signature.asc
Description: PGP signature

Bug#1050025: mutter: non-upstreamed workaround for serial mismatch in Wayland drag-and-drop

[Simon McVittie]

On Fri, 18 Aug 2023 at 10:18:29 -0400, Jeremy Bícha wrote:
> I figure we can keep the patch for Debian 12 since it's there and not
> causing problems, but we can drop it for Ubuntu 23.10 and Debian
> Trixie.

Right, that's what I was thinking. Let's plan to drop this after the
mutter 44 transition has gone through, as I suggested for some other
non-upstreamed workarounds around the same time.

smcv

Bug#1042406: dh-r: throws "Use of uninitialized value $dep_line in substitution" warnings with some packages

[Nilesh Patra]

I am starting a discussion in the mailing list regarding this change.

Currently, dh-r converts test dependencies into "Recommends" and injects then 
into the binary
control file as such.
I feel that this maybe wrong, as you're essentially installing useless packages 
into users machine
who may not really need those packages at all. DESCRIPTION file adds a Suggests 
that could make the package
more useful but aren't entirely necessary. This aligns with the "Suggests" 
field (not Recommends)
in d/control as well.

However, I'm not super aware about R ecosystem's dependencies and use-cases, 
and seek opinions
of others on the mailing list.

PS: Do **NOT** CC me in this thread. I read the mailing list.

Thanks
Nilesh

On Fri, 28 Jul 2023 06:41:10 +0200 Andreas Tille  wrote:

Am Fri, Jul 28, 2023 at 08:07:01AM +0530 schrieb Nilesh Patra:
> 
> 
> On 28 July 2023 1:37:23 am IST, Andreas Tille  wrote:

> >> The reason that we don't see such problems in for instance
> >> r-bioc-bsgenome is because it has some values in the testdepends and
> >> recommendsinput ends up having some value[4].
> >> 
> >> I have attached a patch to fix this, please check.

> >
> >While reading the patch it definitely fixes the uninitialized value.
> >However, it does not fulfill the intended behaviour to add the
> >Test-Depends as Recommends.  I'm considering parsing DESCRIPTION
> >directly to do so.
> 
> I am not sure if I understand this. The behaviour of dh-r for adding recommends with and without the patch is exactly the same, i.e. there's no regression afaics.


Yes.
 
> If you're saying that relying on d/t/control for testdeps is suboptimal, then that's a different problem.


Yes.  But the problem was caused by the switch from d/t/control to
d/t/autopkgtest-pkg-r.conf and thus it exclusively happens in r-bioc-*
packages (in r-cran-* packages this did not happen).
 
> However IMHO adding test dependencies as recommends is not a good idea at all and I was surprised to see it while reading the code. While I can agree that adding them as recommends can help users run tests, I think the subset of people who actually would be interested in doing so is less. Recommends are installed by default by apt and so this ends up cluttering users system with un-needed stuff.


I think it was a good idea as long as we provided
/usr/share/doc/r-*/{run-unit-test,README.test} since the installed
codebase was fitting the docs that users can test the package on their
local machine.  Since also these docs were not installed any more it
makes sense to drop the Recommends which means your patch is solving
the problem.

> That said, I maybe missing the history of this decision here.
> 
> What do you think?


I think this is a good point to discuss adding Test-Depends as
Recommends on the mailing list.  However, I'm currently a bit offlineish
and will not be actively involved into this discussion (which is fine for
me).

Thanks a lot for bringing this up

Andreas. 


--
http://fam-tille.de

Bug#1037579: still ftbfs on arm64 and armhf

[Matthias Klose]

Control: reopen -1

still ftbfs on arm64 and armhf. would it be possible to pay attention to build 
failures after uploads, or even better to pay attention until the package migrates?

Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x

[Jonathan Wiltshire]

Hi,

On Wed, Jul 12, 2023 at 02:45:12PM +0200, Andreas Beckmann wrote:
> As a result new installations of openjdk-17-jre-headless from
> bookworm-security (or -pu) (and its circular dependency
> ca-certificates-java from bookworm) will fail, #1039472, (but
> upgrades seem to work fine, since the jre has been configured at
> least once in the past).

This seems to be a wider problem, several reports against the Debian
package and I have had some via work as well. I've also bumped into it in
an upstream project and personally.

I'm therefore inclined to make a stable update sooner than the point
release. How does this text sound?

| ca-certificates-java, a package to update the cacerts JKS keystore used
| for many java runtimes, may fail to install alongside OpenJDK because
| of a circular dependency. This is a regression in Debian 11 and 12.



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

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



signature.asc
Description: PGP signature

Bug#1000089: clisp: depends on obsolete pcre3 library

[Bastian Germann]

Control: tags -1 patch

On Sat, 1 Jul 2023 19:50:57 +0200 Bastian Germann wrote:
Maybe it is possible to drop the leaf package clisp-module-pcre which is the only user of pcre 
within clisp.


Please find a patch attached that has this implemented.diff -Nru clisp-2.49.20210628.gitde01f0f/debian/changelog 
clisp-2.49.20210628.gitde01f0f/debian/changelog
--- clisp-2.49.20210628.gitde01f0f/debian/changelog 2022-09-25 
09:46:30.0 +
+++ clisp-2.49.20210628.gitde01f0f/debian/changelog 2023-08-18 
16:39:51.0 +
@@ -1,3 +1,10 @@
+clisp (1:2.49.20210628.gitde01f0f-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop clisp-module-pcre. (Closes: #189)
+
+ -- Bastian Germann   Fri, 18 Aug 2023 16:39:51 +
+
 clisp (1:2.49.20210628.gitde01f0f-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru clisp-2.49.20210628.gitde01f0f/debian/control 
clisp-2.49.20210628.gitde01f0f/debian/control
--- clisp-2.49.20210628.gitde01f0f/debian/control   2022-09-25 
09:46:05.0 +
+++ clisp-2.49.20210628.gitde01f0f/debian/control   2022-09-25 
09:46:30.0 +
@@ -21,7 +21,6 @@
  libffcall-dev,
  libgdbm-dev,
  libpq-dev,
- libpcre3-dev,
  libdbus-1-dev,
  zlib1g-dev,
  libunistring-dev,
@@ -51,7 +50,6 @@
   clisp-module-gdbm,
   clisp-module-libsvm,
   clisp-module-pari,
-  clisp-module-pcre,
   clisp-module-postgresql,
   clisp-module-zlib,
   hyperspec
@@ -110,19 +108,6 @@
  This package adds a module to CLISP that implements an interface to the
  Berkeley DB.
 
-Package: clisp-module-pcre
-Architecture: any
-Depends: ${shlibs:Depends}, clisp (= ${binary:Version}), ${misc:Depends}
-Enhances: clisp
-Description: GNU CLISP module that adds libpcre support
- GNU CLISP is a Common Lisp implementation.
- It conforms to the ANSI Common Lisp standard, and offers many extensions.
- It runs on all desktop operating systems (GNU and Unix systems, macOS,
- Windows) and is particularly memory-efficient.
- .
- This adds a module to CLISP that implements an interface to the
- libpcre which implements Perl-compatible regular expressions.
-
 Package: clisp-module-postgresql
 Architecture: any
 Depends: ${shlibs:Depends}, clisp (= ${binary:Version}), ${misc:Depends}
diff -Nru clisp-2.49.20210628.gitde01f0f/debian/rules 
clisp-2.49.20210628.gitde01f0f/debian/rules
--- clisp-2.49.20210628.gitde01f0f/debian/rules 2022-09-25 09:35:36.0 
+
+++ clisp-2.49.20210628.gitde01f0f/debian/rules 2022-09-25 09:46:30.0 
+
@@ -24,7 +24,6 @@
--with-dynamic-modules \
--with-module=gdbm \
--with-module=berkeley-db \
-   --with-module=pcre \
--with-module=rawsock \
--with-module=clx/new-clx \
--with-module=bindings/glibc \

Bug#1050034: RM: tnseq-transit [s390x] -- ROM; wrong results on big endian systems caught by build-time tests

[Étienne Mollier]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: tnseq-tran...@packages.debian.org
Control: affects -1 + src:tnseq-transit

Hi ftpmaster,

Please remove tnseq-transit for the s390x architecture in
unstable, as the newer version fails its test suite on intricate
computational errors on big endian systems, as seen in the build
log[1].  This package has no reverse dependencies.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=tnseq-transit=s390x=3.3.0-1=1691922911=1

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

PS: hope this will not be a duplicate, I didn't get feedback for
my initial message, and I suspect I erroneously sent the initial
message through a black hole instead of mail-submit, sorry about
that.


signature.asc
Description: PGP signature

Bug#1050036: pmount: Can't mount anything since the recent update of libmount1

[Sébastien Dufromentel]

Package: pmount
Version: 0.9.23-6
Severity: important
X-Debbugs-Cc: el...@fadrienn.irlnc.org

Dear Maintainer,

pmount was still perfectly working until recently, but now it fails any mount
complaining about a missing NTFS signature (even if the mounted drive is an
ext4 one, so shouldn't have any NTFS signature). It started a few weeks ago,
when libmount1 was updated from 2.38 to 2.39, so I guess it's related.

I tried to use the -t option to avoid this, but then I get an error from mount
complaining about “not mount point or bad option”, so it doesn't work either.
Don't exactly know what else I can try to have it working.

pumount still works, thought.

Regards,


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

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

Versions of packages pmount depends on:
ii  libblkid1  2.39.1-4
ii  libc6  2.37-7

pmount recommends no packages.

Versions of packages pmount suggests:
pn  cryptsetup  

-- no debconf information

Bug#1050035: ITP: http-relay -- Relay HTTP requests from localhost to a remote host.

[Martin Pecka]

Package: wnpp
Severity: wishlist
Owner: Martin Pecka 

* Package name : http-relay
Version : 2.0.2
Upstream Author : Martin Pecka 
* URL : https://github.com/ctu-vras/http_relay
* License : BSD-3
Programming Lang: Python
Description : Relay HTTP requests from localhost to a remote host.

This HTTP relay properly processes also the nonstandard HTTP responses 
like `ICY 200 OK` produced by Shoutcast or NTRIP streaming servers.


The relay works properly with hostnames, IPv4 and IPv6 addresses. IPv6 
addresses can be specified with or without `[]`.

This package should be added to Debian because it allows easy relaying
of plain HTTP requests from local machine to another server. We use this
to provide internet access to some devices which cannot be configured to
have a default route and can only reach one specified host.

Doing this relaying purely through iptables is not possible because the
HTTP Host header needs to be rewritten, and Location header in the
response, too.

I hope I got all the packaging right. It installs on two different
versions of Ubuntu without a problem. As the package has no other
dependencies than Python 3, I hope the .deb files are quite universal.

I would like to have a sponsor look over this package and check my
approach - this is my frist Debian package.

You can find the built packages on
https://launchpad.net/~peci1/+archive/ubuntu/http-relay and the debian
packaging sources are on https://github.com/ctu-vras/http_relay, branch
debian.

Bug#999955: sqlite3-pcre: depends on obsolete pcre3 library

[Bastian Germann]

Upstream is dead so I suggestto remove this package.

Bug#999924: renderdoc: depends on obsolete pcre3 library

[Bastian Germann]

pcre3 is only used in the embedded swig copy.
So please think about how to get around building that.

Bug#1050033: renderdoc: Build with archive's swig

[Bastian Germann]

Source: renderdoc
Version: 1.27+dfsg-1
Severity: important
Control: block 24 by -1

renderdoc includes an outdated copy of swig that is used for the build.
Please build depend on Debian's swig instead. That has #48 already 
fixed.

Bug#1043810: cockpit-podman: Fails to build source after successful build

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 
https://github.com/cockpit-project/cockpit-podman/pull/1377

Lucas Nussbaum [2023-08-13 15:17 +0200]:
> > dpkg-source: info: building cockpit-podman using existing 
> > ./cockpit-podman_74.orig.tar.xz
> > dpkg-source: info: local changes detected, the modified files are:
> >  cockpit-podman-74/po/LINGUAS
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/cockpit-podman_74-1.diff.oxKlRx

Thanks for your report! I sent a PR to fix this.

Martin

Bug#1043775: cockpit-machines: Fails to build source after successful build

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 
https://github.com/cockpit-project/cockpit-machines/pull/1183

Lucas Nussbaum [2023-08-13 15:17 +0200]:
> > dpkg-source: info: building cockpit-machines using existing 
> > ./cockpit-machines_296.orig.tar.xz
> > dpkg-source: info: local changes detected, the modified files are:
> >  cockpit-machines-296/po/LINGUAS
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/cockpit-machines_296-1.diff.3514Kf

Thanks for your report! I sent an upstream PR to fix this.

Martin

Bug#1049458: celluloid: fails to start due to failed assertion in stream.c

[Stefan Breunig]

Hi,

very good hints. I have created upstream issue 
https://github.com/celluloid-player/celluloid/issues/880 which also has 
more detail than this bug report.


Thanks
Stefan

Bug#1050032: faketime fails with wine32 on x64 systems

[axet]

Package: faketime
Version: 0.9.10-2.1
Severity: normal

Dear Maintainer,

faketime wont work with wine32 binaiers on x64 systems. I ran simple tests
and found following error:

133803: calling init: /usr/lib/i386-linux-gnu/faketime/libfaketime.so.1
133803: 
133803: /usr/lib/i386-linux-gnu/faketime/libfaketime.so.1: error: 
symbol lookup error: undefined symbol: __ftime (fatal)
133803: /usr/lib/i386-linux-gnu/faketime/libfaketime.so.1: error: 
symbol lookup error: undefined symbol: pthread_cond_timedwait, version 
GLIBC_2.2.5 (fatal)
133803: /usr/lib/i386-linux-gnu/faketime/libfaketime.so.1: error: 
symbol lookup error: undefined symbol: timer_settime, version GLIBC_2.3.3 
(fatal)
133803: /usr/lib/i386-linux-gnu/faketime/libfaketime.so.1: error: 
symbol lookup error: undefined symbol: timer_gettime, version GLIBC_2.3.3 
(fatal)

Basically I'm running following command:

export LD_DEBUG=libs
LD_PRELOAD='/usr/$LIB/faketime/libfaketime.so.1' FAKETIME="2039-01-01 1:1:1" 
wine wine-1000/drive_c/windows/syswow64/cmd.exe /c date /t

following command works (x64 binary + x64 system)

FAKETIME="2001-01-01 1:1:1" wine wine-1000/drive_c/windows/system32/cmd.exe /c 
date /t

-- System Information:
Debian Release: 12.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages faketime depends on:
ii  libc62.36-9+deb12u1
ii  libfaketime  0.9.10-2.1

faketime recommends no packages.

faketime suggests no packages.

-- no debconf information

Bug#1032177: (no subject)

[Alexey Kuznetsov]

Try run

LD_DEBUG=libs

And tell us if you see any errors.

-- AK

Bug#1050031: coinor-bonmin: FTBFS with /usr/bin/ld: cannot find -lgfortran

[Emanuele Rocca]

Source: coinor-bonmin
Version: 1.8.9-1
Severity: serious
Tags: sid trixie ftbfs

Hi,

coinor-bonmin fails to build with the following error:

g++ -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o  .libs/BonCbc.o 
.libs/BonCbcNlpStrategy.o .libs/BonCbcNode.o .libs/BonBabInfos.o 
.libs/BonGuessHeuristic.o .libs/BonDiver.o -Wl,--whole-archive 
../Algorithms/.libs/libbonalgorithms.a 
../Interfaces/.libs/libbonmininterfaces.a Heuristics/.libs/libbonheuristics.a 
-Wl,--no-whole-archive  -lCbcSolver -lCbc -lpthread -lrt -lCgl -lOsiClp 
-lClpSolver -lClp -lOsi -lCoinUtils -lbz2 -lz -lipopt 
-L/usr/lib/gcc/x86_64-linux-gnu/13 
-L/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib -L/lib/../lib 
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/13/../../.. -llapack 
-ldmumps_seq -lgfortran -lquadmath -lblas -ldl -L/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/13/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crtn.o  -Wl,-z 
-Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,libbonmin.so.4 -o 
.libs/libbonmin.so.4.8.9
/usr/bin/ld: cannot find -lgfortran: No such file or directory
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:503: libbonmin.la] Error 1

Version 1.8.9-1 of the package did build properly in the past [1]. One
potentially significant difference is that the successful build was with
GCC-12, while the failure occurrs with GCC-13.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=coinor-bonmin=amd64=1.8.9-1%2Bb1=1690533628=0

Bug#1042055: mutter: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test -C /<>/obj-x86_64-linux-gnu --no-rebuild --verbose --timeout-mult

[Lucas Nussbaum]

On 18/08/23 at 10:33 +0100, Simon McVittie wrote:
> Control: clone -1 -2 -3 -4 -5
> Control: retitle -1 mutter: FTBFS: test-framebuffer-get-bits.c:40: assertion 
> failed (cogl_framebuffer_get_alpha_bits (fb_a) >= 1)
> Control: retitle -2 mutter: FTBFS: actor-event-hold test failed with exit 
> status 245
> Control: retitle -3 mutter: FTBFS: color-management test: Failed to reset 
> mocked colord state: Timeout was reached
> Control: retitle -4 mutter: FTBFS: override-redirect test timed out
> Control: retitle -5 mutter: FTBFS: set-parent-exported test: Failed to find 
> mocked color manager system service, Timeout was reached
> Control: severity -2 important
> Control: severity -3 important
> Control: severity -4 important
> Control: severity -5 important
> Control: tags -2 + unreproducible
> Control: tags -3 + unreproducible
> Control: tags -4 + unreproducible
> Control: tags -5 + unreproducible
> Control: block 1043030 by -1
> Control: block 1049934 by -1
> Control: block 1035092 by -1
> 
> On Tue, 25 Jul 2023 at 23:02:16 +0200, Lucas Nussbaum wrote:
> > FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 
> > MESON_TESTTHREADS=8 meson test -C /<>/obj-x86_64-linux-gnu 
> > --no-rebuild --verbose --timeout-multiplier 6 --no-stdsplit 
> > --print-errorlogs --no-suite flaky returned exit code 5
> 
> This is a long-winded way of saying "some tests failed". The more useful
> information for tracking regressions is either "some tests failed" if it's
> not possible to extract details, or the details of *which* tests failed.

Yeah, I know. Unfortunately, due to the variety of test frameworks in
the wild, it's hard to extract a more meaningful message...

> > >  98/212 mutter:cogl+cogl/conform / cogl-test-framebuffer-get-bits-gl3 
> > >  FAIL 1.19s   (exit status 250 or 
> > > signal 122 SIGinvalid)
> 
> I can reproduce this, and it's blocking other work on mutter 43. Version
> 44 in experimental does not seem to have this bug, though.
> 
> The assertion failure is:
> 
> > ERROR:../src/tests/cogl/conform/test-framebuffer-get-bits.c:40:test_framebuffer_get_bits:
> >  assertion failed (cogl_framebuffer_get_alpha_bits (fb_a) >= 1): (0 >= 1)
> 
> mutter passed tests when I uploaded it in mid June, so this presumably
> must be a regression triggered by changes in some dependency, perhaps
> Mesa. Let's use #1042055 for this failure and clones for the rest.
> 
> reproducible-builds also has this failure.
> 
> > > 140/212 mutter:clutter+clutter/conform / actor-event-hold 
> > >  FAIL 1.06s   (exit status 245 or 
> > > signal 117 SIGinvalid)
> 
> There is no obvious error message in the log (the test just exits). There's
> a warning, but it's non-fatal and appears in successful tests too. I can't
> reproduce this.
> 
> > > 169/212 mutter:core+mutter/unit / color-management
> > >  FAIL26.69s   (exit status 251 or 
> > > signal 123 SIGinvalid)
> 
> "Failed to reset mocked colord state: Timeout was reached". I can't
> reproduce this.
> 
> > > 194/212 mutter:core+mutter/stacking / override-redirect   
> > >  TIMEOUT360.11s   killed by signal 15 
> > > SIGTERM
> 
> Timed out, no additional information in the log. I can't reproduce this.
> 
> > > 196/212 mutter:core+mutter/stacking / set-parent-exported 
> > >  FAIL   176.22s   (exit status 251 or 
> > > signal 123 SIGinvalid)
> 
> "Failed to find mocked color manager system service, Timeout was reached".
> I can't reproduce this.

Hi,

> Does your archive rebuild infrastructure build other things in parallel on
> the same machine, or any other factor like that which could make it more
> likely to get stuck / take a long time than a production buildd?

No. What I do is that I perform a first pass over all packages, building 3
packages per node in parallel. But then, failed builds are retried
without other builds in parallel.

In other rebuilds I made since then, the failures other than the first
one (98/212 mutter:cogl+cogl/conform /
cogl-test-framebuffer-get-bits-gl3) did not happen, so maybe what
happened was:
- the first build failed as expected with 98/212
- the second build failed for an unknown reason with all errors above

I'm fine with you closing all those other bugs for now if you prefer.

Lucas

Bug#1050030: Potential regression: ovmf package update from Debian bookworm breaks Xen HVM boot

[Paul Leiber]

Package: ovmf
Version: 2022.11-6
Severity: important

Dear Maintainer,

After upgrading from Debian Bullseye to Debian Bookworm, existing HVM 
DomUs using "firmware = 'ovmf'" (specifically Windows Server 2022 and 
Windows 10) can't boot anymore. Booting these systems leads to the 
Windows error 0xc225. I wasn't able to fix this error. Booting an 
installation .iso leads to the same error. Booting the installation 
media with "firmware = 'bios'" leads to a normal boot.


This seems to be the effect of a change in ovmf sources, where a xen 
specific platform was created in 2019: 
https://lore.kernel.org/all/20190813113119.14804-1-anthony.per...@citrix.com/#t


With some help I found a workaround. I could successfully start the 
Windows DomU with ovmf firmware after removing the current ovmf package 
and installing a previous ovmf package from Debian repositories, 
specifically version 2020.11-2+deb11u1. This strongly indicates that the 
cause of this issue lies in the ovmf package.


My HVM config file:

type = "hvm"
memory = 6144
vcpus = 2
name = "kalliope"
firmware = 'ovmf'
firmware = '/usr/local/lib/ovmf/OVMF.fd'
vif = ['bridge=xenbr0,mac=XX:XX:XX:XX:XX:XX,ip=10.0.0.4']
disk = ['phy:/dev/vg0/matrix,hda,w']
device_model_version = 'qemu-xen'
hdtype = 'ahci'
pae = 1
acpi = 1
apic = 1
vga = 'stdvga'
videoram = 16
xen_platform_pci = 1
vendor_device = 'xenserver'
viridian = 1
on_crash = 'restart'
device_model_args_hvm = [
  # Debug OVMF
  '-chardev', 'file,id=debugcon,path=/var/log/xen/ovmf.log,',
  '-device', 'isa-debugcon,iobase=0x402,chardev=debugcon',
]
sdl = 0
serial = 'pty'
vnc = 1
vnclisten = "0.0.0.0"
vncpasswd = ""

As the Windows systems are not usable anymore, Xen is significantly 
reduced in functionality after the upgrade.


There is a Debian bug report which could be related, I also described my 
situation there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978595


This (or at least a very similar) issue seems to be fixed in 
Redhat/Fedora. A related bug report exists in 
https://bugzilla.redhat.com/show_bug.cgi?id=2170930



Additional information:

I also tried building Ovmf following 
https://lore.kernel.org/all/20190813113119.14804-1-anthony.per...@citrix.com/#t 
, but I wasn't fully able to create a working system:


(1) Using the resulting OVMF.fd from the build process with "firmware 
='/path/to/new/OVMF.fd' led consistently to a black screen in VNC or 
Spice with the text "Guest has not initialized the display (yet)".


(2) Replacing the OVMF.fd in /var/lib/ovmf with the freshly built 
OVMF.fd led to a slight improvement. I could then boot the Windows 
Server installation .iso, but booting the Windows 10 installation .iso 
lead to a crash where the TianoCore logo was visible, but nothing 
happened. The two existing DomUs were still no>


However, I am not sure that I followed the procedure correctly, I might 
very well have done something very wrong. Any pointers are welcome.


Thanks,

Paul

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Scott Kitterman]

On Friday, August 18, 2023 9:33:48 AM EDT Andreas Tille wrote:
> Hi Scott,
> 
> Am Fri, Aug 18, 2023 at 01:15:18PM + schrieb Scott Kitterman:
> > On August 18, 2023 1:04:26 PM UTC, Andreas Tille  wrote:
> > >> In Debian terms, it's not the preferred form for modification, so it's
> > >> not source.  In this regard DFSG goes farther than some software
> > >> licenses.> >
> > >I think the point Jeroen wanted to make is that these are actually
> > >source file archives which "by chance" are featuring a .whl extension
> > >rather than a .zip extension.
> > 
> > A wheel is not the preferred form for modification.  They're not wheels by
> > chance at all.
> Yes, thanks to Jeroen's hint I realised this as well and I agree that
> this is a nasty way to hide the fact that the files are actually source
> archives.

They aren't.

> However, you confirmed yourself that future_fstrings is an exception and
> comes with source and thus does not violate DFSG.  The only difference
> I personally can see is that the archives are just hiding what they are.
> We could simply add do some
>for whl in *.whl ; do ln -s $whl $(basename .whl).zip ; done
> and we have source archives that are obviously what they are.
> 
> > From a DFSG perspective,
> 
> Hmmm, the only thing where I can draw a violation of the DFSG is that
> there are no d/copyright entries for the source code that is hidden
> inside these *.whl files.  Otherwise its "just" duplicated code (in most
> cases) which is definitely not nice but IMHO not a violation of DFSG.
> 
The disagreement here is that Python wheels aren't source.  DFSG #2 requires 
the source be present and these aren't it.  If you look at the WAF entry in 
the FTP team reject FAQ, this is similar.  The FTP team view has long been 
that DFSG #2 means the actual preferred form for modification.

> > the most straightforward approach is to build-depend on the relevant
> > Debian packages and build any needed wheels from that.
> Do avoid source code duplication I'm willing to do that.  Yes, I
> perfectly agree that its pretty ugly (I'm just a bit unsure about
> the DFSG violation).  I'm wondering whether a simple
> 
>zip whl.zip /path/to/python/files ; mv whl.zip whl.whl
> 
> will be something that can replace the current packages.  I think
> we also need to patch the tests to fit the version numbers (if
> we do not want to cheat and simply use the version numbers of the
> original whl files to avoid patching).

Perhaps, but there are nuances to the wheel format.  Please use Wheel to 
generate them.

> >  It won't necessarily get you the same version as upstream uses, but it's
> >  definitely DFSG compliant.
> We also might symlink our resulting whl files with the version number
> pdm upstream might expect in their tests.  The question is, whether all
> this effort might break the tests in some way and we might end up with
> endless patching by at the same time loosing the chance to discuss with
> upstream.  But it might be time to discuss the issue with upstream
> anyway.

Perhaps.  If it were me, what I'd do is locate the missing tarballs and stash 
them in debian/missing-sources/ and worry about more complex solutions later.  
Once you're done that, you've met DSFG #2 and there's no need to strip the 
wheels from the binary.

It's not super maintainable, but it will allow you to focos on getting the 
tests working as upstream ships them without any Debian customizations that 
might cause Debian specific failures.

Scott K

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

Bug#1050025: mutter: non-upstreamed workaround for serial mismatch in Wayland drag-and-drop

[Jeremy Bícha]

On Fri, Aug 18, 2023 at 9:03 AM Simon McVittie  wrote:
> Source: mutter
> Version: 44.3-5
> Severity: normal
> Forwarded: https://gitlab.gnome.org/GNOME/mutter/-/issues/2216
>
> There is a non-upstreamed workaround in mutter for
> https://gitlab.gnome.org/GNOME/mutter/-/issues/2216. This is technical debt.
>
> This appears to be a workaround for a GTK bug, fixed in 3.24.31 and 4.5.1,
> which are both in Debian 12. Can we drop the mutter workaround?
>
> On the upstream issue, Marco mentions "the usage of flatpaks/snaps out
> there that may not include super-updated gtk versions" which could be a
> reason to keep the workaround for some reasonable grace period, but we
> shouldn't keep non-upstreamable workarounds hanging around forever.

Simon, I have dropped this patch in my Mutter 45 packaging.

I figure we can keep the patch for Debian 12 since it's there and not
causing problems, but we can drop it for Ubuntu 23.10 and Debian
Trixie.

Thank you,
Jeremy Bícha

Bug#1050029: gcc-11-doc should not be shipped in trixie

[Dmitry Baryshkov]

Source: gcc-11-doc
Version: 11.3.0-1
Severity: important
Control: block -1 by 1023690

Following gcc-11 removal, don't ship  gcc-11-doc in trixie

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Bug#1050018: monodoc-manual: Degrade monodoc-http Depends to Recommends

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is attached.diff -Nru mono-6.8.0.105+dfsg/debian/changelog 
mono-6.8.0.105+dfsg/debian/changelog
--- mono-6.8.0.105+dfsg/debian/changelog2022-12-09 14:33:03.0 
+0100
+++ mono-6.8.0.105+dfsg/debian/changelog2023-08-18 15:02:07.0 
+0200
@@ -1,3 +1,10 @@
+mono (6.8.0.105+dfsg-3.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Recommend monodoc-http.  (Closes: #1050018, #561240)
+
+ -- Bastian Germann   Fri, 18 Aug 2023 15:02:07 +0200
+
 mono (6.8.0.105+dfsg-3.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mono-6.8.0.105+dfsg/debian/control mono-6.8.0.105+dfsg/debian/control
--- mono-6.8.0.105+dfsg/debian/control  2022-12-09 14:28:17.0 +0100
+++ mono-6.8.0.105+dfsg/debian/control  2023-08-18 15:01:34.0 +0200
@@ -3068,7 +3068,8 @@
 Package: monodoc-manual
 Architecture: all
 Section: doc
-Depends: ${misc:Depends}, monodoc-http | monodoc-viewer
+Depends: ${misc:Depends}
+Recommends: monodoc-http | monodoc-viewer
 Suggests: monodoc-gtk-manual,
  monodoc-gecko-manual,
  monodoc-nunit-manual

Bug#1050001: Unwinding directory aliasing

[Simon McVittie]

On Fri, 18 Aug 2023 at 07:57:14 +0100, Ian Jackson wrote:
> I think we can probably fix it by backing out this change, and then
> doing usrmerge the traditional Debian way by making changes to
> debhelper, so that we move the files package by package, in the .debs.

What do you consider to be the end goal of this proposal?

If I understand your proposal correctly, it is to return all Debian
systems to their traditional (let's say circa 2010) layout, and then
restart the transition differently. Imagine for a moment that the
usrmerge package, debootstrap --merged-usr, etc. had never existed,
and all Debian systems were in their 2010 state (or equivalently, that
your proposed revert has happened and we are now ready for the second
stage of your plan).

If we carry out this transition package-by-package without central
coordination ("the traditional Debian way"), it seems to me that the
best we can achieve is for /bin, /sbin, /lib* to be symlink farms,
consisting of symlinks that are either owned by the same package that
owns the symlink target, or are unowned from dpkg's perspective and are
created by maintainer scripts.

Here's a simplified view of the resulting system:

/bin/sh -> /usr/bin/sh
/bin/rm -> /usr/bin/rm
/usr/bin/env (regular file)
/usr/bin/sh (regular file)
/usr/bin/perl (regular file)
/usr/bin/rm (regular file)

(Obviously in real life, /bin and /usr/bin are a lot larger than that,
and /sbin and /lib* are also necessary for a bootable system, but
considering a small number of /{usr/,}bin files is enough to illustrate
my point.)

This does some but not all of what merged-/usr does: calling /usr/bin/sh
would become a non-bug, but calling /bin/env would still be an error,
/bin would still represent non-trivial on-disk and/or in-dpkg-database
state, and we would still potentially have other issues triggered by
the directories being distinct from one another (like the one discussed
by the tech committee in #911225, which was exactly a regression caused
by having moved a library in the traditional Debian way).

The merged-/usr version of that same simplified system is this:

/bin -> usr/bin
/usr/bin/env (regular file)
/usr/bin/sh (regular file)
/usr/bin/perl (regular file)
/usr/bin/rm (regular file)

(Again, in real life we also have to consider /sbin and /lib*, but
showing /bin is enough to illustrate the difference.)

As was discussed in 2019 and repeatedly since then, some of the reasons
to want merged-/usr are only available with that layout, and are not
provided by the symlink farm.

If I remember correctly, openSUSE tried to get from unmerged /usr to
merged /usr by essentially the route you propose, successfully reached
the symlink-farm state, but then got stuck without a way to get from the
symlink farm to the single symbolic link. Do you have a plan for how that
would be achieved without breaking upgrades or going behind dpkg's back?

If your plan was a longer, slower, arguably more robust way to achieve
the same end goal, that would be more appealing than a longer, slower,
arguably more robust way to get halfway to the same end goal and then
become unable to go further.

smcv

Bug#1049438: r-cran-rgdal: autopkgtest needs update for new version of r-cran-sp

[Roger Bivand]

Dear Andreas,

Further, it looks as though r-cran-sf is not available at the point of failure, 
but may reading of your output may be guesswork. Are you turning warnings into 
errors? Locally, I cannot reproduce the problem with sf available for sp 2.0-0; 
when sf is not available, I do see problems (but more extensive than yours).

Hope this helps,

Roger

--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no


From: Roger Bivand 
Sent: 18 August 2023 14:54
To: Andreas Tille; Paul Gevers; 1049...@bugs.debian.org; Edzer Pebesma
Cc: Debian R
Subject: Re: Bug#1049438: r-cran-rgdal: autopkgtest needs update for new 
version of r-cran-sp

Dear Andreas,

No idea, but note that rgdal, rgeos, maptools and rgrass7 will be archived in 
October 2023.

This has been drawn to the attention of those interested on mailing lists since 
late 2022: https://github.com/r-spatial/evolution, 
https://r-spatial.org/r/2022/04/12/evolution.html, 
https://r-spatial.org/r/2022/12/14/evolution2.html, etc.

sp 2.0-0 by default uses sf, not rgdal, for all CRS and transformation, unless 
somehow you are setting an environment variable or an R option to look for 
rgdal instead. This option will stop working by the end of September 2023.

So the interaction you are seeing, but which I can't reproduce, is from your 
build of sf with your build of PROJ and GDAL in conjuction with the  new 
default settings of sp to use sf not rgdal.

So no updates to rgdal are going to be forthcoming, and your build system will 
have to move now very quickly to catch up with impending changes. rgdal will be 
leaving CRAN in about six weeks, you may move to forthcoming sp 2.1-0 which 
drops rgdal completely if that is easier.

Best wishes,

Roger

--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no


From: Andreas Tille 
Sent: 18 August 2023 13:58
To: Paul Gevers; 1049...@bugs.debian.org; Roger Bivand
Cc: Debian R
Subject: Re: Bug#1049438: r-cran-rgdal: autopkgtest needs update for new 
version of r-cran-sp

Control: tags -1 upstream
Control: forwarded -1 Roger Bivand 

Hi Roger,

the CI tests in Debian uncovered some conflict between recent rgdal and
version 2.0 of sp.  As you either can see in the bug report that was
filed[1] or in a recent CI build log[2] it fails with

In CRS("+init=epsg:4326") :> sp.tr <- spTransform(sp, CRS("+init=epsg:3857"))
 sf required for evolution_status==2L
Error in spTransform(sp, CRS("+init=epsg:3857")) :
  source crs creation failed: Invalid PROJ string syntax
Calls: spTransform -> spTransform

It would be great if you could adapt rgdal to the latest version of sp.

Kind regards
Andreas.


[1] https://bugs.debian.org/1049438
[2] https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/jobs/4562837#L790

--
http://fam-tille.de/

Bug#1042376: digikam crashes with "Illegal instruction"

[Steven Robbins]

On Monday, August 14, 2023 8:52:14 A.M. CDT Steven Robbins wrote:

> So I'm back to square 1, very confused by your crash.

I have made a change to digikam and uploaded 8.1.0-3 last night.   It should 
avoid calling SSE 4 functions if only SSE 2 is detected.  I'd appreciate if 
you could try it out and report back to this bug whether it fixes your crash or 
not.

It's a bit of a shot in the dark since it doesn't affect the specific function 
pointed at in your back trace.

Best,
-Steve


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

Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Andreas Tille]

Hi Scott,

Am Fri, Aug 18, 2023 at 01:15:18PM + schrieb Scott Kitterman:
> On August 18, 2023 1:04:26 PM UTC, Andreas Tille  wrote:
> >> In Debian terms, it's not the preferred form for modification, so it's not 
> >> source.  In this regard DFSG goes farther than some software licenses.
> >
> >I think the point Jeroen wanted to make is that these are actually
> >source file archives which "by chance" are featuring a .whl extension
> >rather than a .zip extension.
> 
> A wheel is not the preferred form for modification.  They're not wheels by 
> chance at all.

Yes, thanks to Jeroen's hint I realised this as well and I agree that
this is a nasty way to hide the fact that the files are actually source
archives.

However, you confirmed yourself that future_fstrings is an exception and
comes with source and thus does not violate DFSG.  The only difference
I personally can see is that the archives are just hiding what they are.
We could simply add do some
   for whl in *.whl ; do ln -s $whl $(basename .whl).zip ; done
and we have source archives that are obviously what they are.
 
> From a DFSG perspective,

Hmmm, the only thing where I can draw a violation of the DFSG is that
there are no d/copyright entries for the source code that is hidden
inside these *.whl files.  Otherwise its "just" duplicated code (in most
cases) which is definitely not nice but IMHO not a violation of DFSG.

> the most straightforward approach is to build-depend on the relevant Debian 
> packages and build any needed wheels from that.

Do avoid source code duplication I'm willing to do that.  Yes, I
perfectly agree that its pretty ugly (I'm just a bit unsure about
the DFSG violation).  I'm wondering whether a simple

   zip whl.zip /path/to/python/files ; mv whl.zip whl.whl

will be something that can replace the current packages.  I think
we also need to patch the tests to fit the version numbers (if
we do not want to cheat and simply use the version numbers of the
original whl files to avoid patching).

>  It won't necessarily get you the same version as upstream uses, but it's 
> definitely DFSG compliant.

We also might symlink our resulting whl files with the version number
pdm upstream might expect in their tests.  The question is, whether all
this effort might break the tests in some way and we might end up with
endless patching by at the same time loosing the chance to discuss with
upstream.  But it might be time to discuss the issue with upstream
anyway.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1050017: khelpcenter: Drop khtml

[Sune Stolborg Vuorela]

On Friday, August 18, 2023 3:11:57 PM CEST Bastian Germann wrote:
> Am 18.08.23 um 14:31 schrieb Sune Stolborg Vuorela:
> > Please stop this. It is not helpful. Once everything is released upstream,
> > it will end up in Debian.
> For khelpcenter maybe it is not helpful. But when we reach freeze for trixie
> and okular still has those optional dependencies, they should just be
> dropped to move on with the deprecated packages. They also block pcre3
> removal which is why I filed the bug in the first place.

Let's revisit once we are close to trixie release. Right now, it just gets in 
the way.

I expect khtml and kjs to disappear without much non-kde/qt team involvement 
by summer, maybe even easter. I don't expect trixie freeze to happen before 
that.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1049999: vagrant: the future of packaging vagrant in Debian

[Gwili . Stifter]

Source: vagrant
Followup-For: Bug #104

Please consider officially orphaning the package if realistically you are the 
only maintainer of this package. This should help increase the visibility of 
the problem and make users think more about whether using vagrant from debian 
is the right solution to whatever they may be trying to achieve.

Bug#1050028: rust-tokio-rustls: recent upgrade breaks reverse dependencies: keep from testing till resolved

[Jonas Smedegaard]

Source: rust-tokio-rustls
Version: 0.24.1-1
Severity: serious
Justification: reverse dependencies

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: affects -1 rust-hyper-rustls

Breaks reverse dependencies: keep from testing till resolved.

See bug#1049977 for related discussion.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTfcg0ACgkQLHwxRsGg
ASFNUxAAj105Of/nLfE9QqYVaJY6xXpSw5P1XO0a9BTC6L0WnFjZXkLP2HJONUXi
mHMQ3nXrdKVAB4SfCB674NZXs4kR6bhsJeFwkjMx/WEMxv83GRBEfCe2d2YVJjJq
O+mcDQLxiSnzkOsixvNboAGeeBBwwz02nSvcYFhH8Kj6zNHVHhtitjeG13atpqGd
/3uZ7nVl8vwAWhf3QzySgFfhWfdkCw3ltZR3adb14NNLFKcQnht5XEqiwoiZTqkN
ipi0OI+cfA4EWfzLOJq0Ph9cbRfD3BJTUfCVfNFe/+xUEIDtViYeJeWO6ROvxZ8i
8DD1FsZqJFIQLn2Zg6nQ41sShgmV08hM25BLtznTxcN9i3X+EtnDqgGePkbvzqb6
abQuKvuyx1zWW6RiN/XwlWCGtLnWYfpe3pchlkMEp/hjEE00BNrN484LWRjUcnVo
5zUa5PBKfFleZMs9zB+SFrcz+S2RaEn1Jj8DHjzl4k35rWBEy4FfEZT9X4fkERxA
mLVGlUaYlhe59oOajkmsVcEOAN4aHlXiVFOUUiV5jPH7uzbPy0Y74fG81PCFwbUa
Dg1mtCEOo7zqymdSOV+dGOI6YTDSew6jNhzNEe0GjHRSzCTfN1hr3VoWwztQEVZF
p18AmR/IijkhU3hStZAUtPt3s8nqc9MXZyKzUMfR0RNKvv4cKZw=
=YGQr
-END PGP SIGNATURE-

Bug#1050027: libcoq-mathcomp-classical: undeclared file conflict with libcoq-mathcomp-analysis/bookworm+trixie

[Helmut Grohne]

Package: libcoq-mathcomp-classical
Version: 0.6.4-1+b1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libcoq-mathcomp-analysis

libcoq-mathcomp-classical starts to ship the following files:

/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/boolp.glob
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/boolp.v
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/boolp.vo
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/cardinality.glob
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/cardinality.v
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/cardinality.vo
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/classical_sets.glob
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/classical_sets.v
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/classical_sets.vo
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/fsbigop.glob
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/fsbigop.v
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/fsbigop.vo
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/functions.glob
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/functions.v
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/functions.vo
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/mathcomp_extra.glob
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/mathcomp_extra.v
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/mathcomp_extra.vo
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/set_interval.glob
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/set_interval.v
/usr/lib/ocaml/coq/user-contrib/mathcomp/classical/set_interval.vo

They happen to also be part of libcoq-mathcomp-analysis as part of
bookworm and trixie. There is no Conflicts nor Replaces relation
addressing this conflict nor are there any diversions. As such, this
situation can result in unpack errors in an upgrade scenario.

Judging from the changelog (saying "package split") you mean to
restructure and therefore replace these files. If you agree, please add
the necessary Breaks+Replaces relations.

Helmut

Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Scott Kitterman]

On August 18, 2023 1:04:26 PM UTC, Andreas Tille  wrote:
>Hi Scott,
>
>Am Tue, Aug 15, 2023 at 02:18:35PM + schrieb Scott Kitterman:
>> >They are zip files containing python source code. It is possible to include
>> >compiled C extensions in wheels, but I checked and these wheels are all pure
>> >python, so no binary blobs are included.
>> 
>> In Debian terms, it's not the preferred form for modification, so it's not 
>> source.  In this regard DFSG goes farther than some software licenses.
>
>I think the point Jeroen wanted to make is that these are actually
>source file archives which "by chance" are featuring a .whl extension
>rather than a .zip extension.

A wheel is not the preferred form for modification.  They're not wheels by 
chance at all.

From a DFSG perspective, the most straightforward approach is to build-depend 
on the relevant Debian packages and build any needed wheels from that.  It 
won't necessarily get you the same version as upstream uses, but it's 
definitely DFSG compliant.

Scott K

Bug#1050026: r-bioc-metagenomeseq: autopkgtest regression

[Graham Inggs]

Source: r-bioc-metagenomeseq
Version: 1.42.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The upload of r-bioc-metagenomeseq 1.42.0-1 is failing its own
autopkgtest [1].  I've copied what I hope is the relevant part of the
log below.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-metagenomeseq/testing/amd64/


 48s Loading required package: glmnet
 48s Loading required package: Matrix
 49s Loaded glmnet 4.1-7
 49s Loading required package: RColorBrewer
106s [ FAIL 2 | WARN 6 | SKIP 0 | PASS 13 ]
106s
106s ══ Failed tests

106s ── Failure ('test-norm.R:28:3'): `cumNormStat` returns the
correct value ───
106s cumNormStat(lungData) not equal to 0.7014946.
106s names for target but not for current
106s ── Failure ('test-norm.R:34:3'): `cumNormStatFast` returns the
correct value ───
106s cumNormStatFast(lungData) not equal to 0.7014946.
106s names for target but not for current
106s
106s [ FAIL 2 | WARN 6 | SKIP 0 | PASS 13 ]
106s Error: Test failures
106s Execution halted