Bug#1051754: mpi-defaults: Please enable support for loong64 architecture

[John Paul Adrian Glaubitz]

Source: mpi-defaults
Version: 1.10.10+repack-2
Severity: normal
User: debian-de...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn

Hi!

We're currently bootstrapping the new architecture loong64 in Debian Ports
and while more than 11900 packages have already been built, we still lack
many packages.

One major blocker is mpi-defaults which currently has no loong64 support
and therefore blocks many numeric packages.

Adding loong64 does not pose any problems for the archive mirrors as the case
of src:postgresql-15 proves which added loong64 to debian/control recently [1].

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/postgresql/postgresql/-/commit/644130c26acebe008f94b8d41b86cd500551fc44

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Sebastian Ramacher]

Hi Helmut

thanks for the detailed explanation.

On 2023-09-04 22:33:54 +0200, Helmut Grohne wrote:
> Unless there is disagreement, I intend to move forward with moving
> systemd units on the grounds that the moratorium only is a
> recommendation and this transition request.

Skipping all the technical details, as I would not classify this as a
transition where the release team needs to be involved. We can of course
help with the rebuilds of the affected packages, but this change does
not require us to check for outdated binary packages in testing or to
make sure that everything migrates together.

For the systemd change, the following steps should be enough in general:

1. debhelper with support for service files in /usr migrates to testing.
2. Rebuild packages which currently have their service files.
3. debhelper installing service files to /usr per default migrates to testing.
4. Rebuild all packages with service files.

For packages where these steps are not enough, bugs are filed along
while preparing 1. and 3. This will include all packages which include
service files in Arch: all packages as we cannot binNMU them.

Depending on the number of packages in step 4., this would ideally not
be done during the time_t transition to avoid any surprises.

The other / to /usr file moves will need uploads anyway. So we cannot
help here (except for monitoring the status of the bugs during the
freeze). Regarding the move on d-i's side, please coordinate this change
with Cyril. From your explanation it is however not clear to me whether
we are blocked on finishing the /usr-merge change in the main archive by
d-i or not.

Cheers
-- 
Sebastian Ramacher

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Hideki Yamane]

Hi,

On Sun, 10 Sep 2023 18:29:36 +0200
Bill Allombert  wrote:
> Or we could generate DEBIAN/copyright from debian/copyright using data in
> license-common-list at build time. So maintainers would not need to manage 
> the copying
> themselves.

 One problem is, that some software declares that they use some licenses
 (e.g. MIT), but sometimes they modify the license term itself a bit.
 So, there's a difference between words in the license list and some words
 in the included license in such software.

 It'd be better to find such software and ask upstream to fix it to use
 proper license terms, by tagging it at BTS. And, it's NOT Debian specific
 issues, so it may be better to ask folks to join such a movement then, IMHO.


-- 
Hideki Yamane 

Bug#1051462: kdiff3: segfault when quitting the application

[Ritesh Raj Sarraf]

Package: kdiff3
Version: 1.10.5-1
Followup-For: Bug #1051462
X-Debbugs-Cc: r...@debian.org


Workaround is to disable "Word Wrap Diff Windows" under menu:

DiffView => Word Wrap Diff Windows

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-security'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages kdiff3 depends on:
ii  kio   5.107.0-1
ii  libc6 2.37-7
ii  libgcc-s1 13.2.0-3
ii  libkf5configcore5 5.107.0-1
ii  libkf5configwidgets5  5.107.0-2
ii  libkf5coreaddons5 5.107.0-1
ii  libkf5crash5  5.107.0-1
ii  libkf5i18n5   5.107.0-1+b1
ii  libkf5kiocore55.107.0-1
ii  libkf5kiowidgets5 5.107.0-1
ii  libkf5parts5  5.107.0-1
ii  libkf5widgetsaddons5  5.107.0-1
ii  libkf5xmlgui5 5.107.0-1+b1
ii  libqt5core5a  5.15.10+dfsg-3
ii  libqt5gui55.15.10+dfsg-3
ii  libqt5printsupport5   5.15.10+dfsg-3
ii  libqt5widgets55.15.10+dfsg-3
ii  libstdc++613.2.0-3

Versions of packages kdiff3 recommends:
ii  kdiff3-doc  1.10.5-1

kdiff3 suggests no packages.

-- no debconf information

Bug#1030129: question about proposed update 20230620~deb12u1

[grin]

Is this bug fixed in recently uploaded 20230620~deb12u1? Or are we waiting for 
20230710 backport?

(Sidenote: found this bug because Ceph cannot build their release. 
[https://docs.ceph.com/en/latest/releases/reef/])

Peter

Bug#1051755: debhelper: dh_installdocs ignores debian/.docs

[IOhannes m zmoelnig]

Package: debhelper
Version: 13.11.6
Severity: important

Dear Maintainer,

with debhelper-13.11.6, dh_installdocs happily ignores the contents of
debian/.docs, and consequently does not install any documentation (apart
from the files that live directly in debian/, e.g. d/copyright or d/.TODO)

this appears to be a regression, as downgrading to debhelper_13.11.4 fixes the
problem.
(i haven't tried 13.11.5 yet)


thanks for maintaining debhelper!

cheers

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.1-1
ii  dpkg 1.22.0
ii  dpkg-dev 1.22.0
ii  dwz  0.15-1
ii  file 1:5.45-2
ii  libdebhelper-perl13.11.6
ii  libdpkg-perl 1.22.0
ii  man-db   2.11.2-3
ii  perl 5.36.0-9
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#1051756: unit-tests autopkgtest non-functional

[Michael Biebl]

Source: systemd
Version: 254.1-3
Severity: important

Looking at the debci logs, the "unit-tests" autopkgtest is currently
non-functional:

autopkgtest [09:25:30]: test unit-tests: [---
OK: 0 SKIP: 0 FAIL: 0


None of the unit-tests are executed.

Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?

[Sean Whitton]

Hello,

On Mon 11 Sep 2023 at 08:45pm +02, Jörg-Volker Peetz wrote:

> Hello,
> thanks for looking into this.
> From a terminal (rxvt-unicode) running my shell (mksh) I start emacs
> (emacs-lucid). After about 15 seconds the following warnings appear:
>
>  ■  Warning (comp): debian-el.el:90:26: Warning: reference to free variable 
> ‘di\
> red-mode-map’
>  ■  Warning (comp): debian-el.el:90:26: Warning: reference to free variable 
> ‘di\
> red-mode-map’
>  ■  Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of 
> u\
> nescaped single quotes (use \= or different quoting)
>  ■  Warning (comp): mmm-vars.el:869:2: Warning: defvar `mmm-classes-alist' 
> docs\
> tring has wrong usage of unescaped single quotes (use \= or different quoting)
>  ■  Warning (comp): mmm-auto.el:168:2: Warning: docstring has wrong usage of 
> un\
> escaped single quotes (use \= or different quoting)
>
> I stop emacs (C-x C-c) and start the next emacs. And again, after about the 
> same
> time the same warnings appear.
> As I understand it, the second emacs is re-compiling the modules mentioned in
> the warnings (and others, as can be seen in the eln-cache directory).

The fact the warnings appear does not necessarily mean that any
recompilation occurs.

> init.el is appended.

We'd need a reproduction with 'emacs -q'.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1051677: emacs: Provides backport of 29.1

[Sean Whitton]

Hello,

On Mon 11 Sep 2023 at 12:02pm -07, Manphiz wrote:

> Ah noted.  I guess they'll redirect me to the actual team/person
> handling the requested packages.

In this case you could have been that person!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#967339: fio: depends on deprecated GTK 2

[Martin Steigerwald]

Hi Bastian.

Am Samstag, dem 12.08.2023 um 14:08 +0200 schrieb Bastian Germann:
> Please remove the gfio package from Debian. I do not think anyboy will
> port to a newer gtk version.

Thanks for your merge request! I applied it and asked my sponsor to
upload.

Best,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1051757: libunwind8 doesn't support loongarch64

[Weihao Li]

Package: libunwind8
Version: 1.7.0~rc2-1
Severity: wishlist
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainer,

The current version of libunwind8 source package already provides 
support for the loongarch64, can simply add loong64 in control file to 
build loongarch64 binary package, hope to add support in future debian 
version.


Thanks
Weihao Li

Bug#1051758: ITP: python-ruyaml -- YAML 1.2 loader/dumper package for Python

[Carsten Schoenert]

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

* Package name: python-ruyaml
  Version : 0.91.0
  Upstream Contact: Anthon van der Neut, Ruamel bvba 

Sorin Sbarnea 
* URL : https://github.com/pycontribs/ruyaml
* License : MIT
  Programming Lang: Python
  Description : YAML 1.2 loader/dumper package for Python

 The ruyaml package is a fork of ruamel.yaml aimed to made in order to secure
 the future of the library, mainly by having a pool of maintainers and can be
 used as a drop-in replacement for python3-ruamel.yaml.

This package is a dependency for yamlfix (a simple opinionated yaml
formatter that keeps your comments) which I intend to package to.

Packaging will happen within the Debian Python Team.

Bug#1051756: unit-tests autopkgtest non-functional

[Michael Biebl]

Am 12.09.23 um 09:40 schrieb Michael Biebl:

Source: systemd
Version: 254.1-3
Severity: important

Looking at the debci logs, the "unit-tests" autopkgtest is currently
non-functional:

autopkgtest [09:25:30]: test unit-tests: [---
OK: 0 SKIP: 0 FAIL: 0


None of the unit-tests are executed.



https://salsa.debian.org/systemd-team/systemd/-/commit/a50fec8cf668ecdb6db8887a57e60638118e3feb 


from the upstream-ci branch needs to be pulled into debian/master


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?

[Jörg-Volker Peetz]

Hello Sean,

Sean Whitton wrote on 12/09/2023 09:41:

Hello,

On Mon 11 Sep 2023 at 08:45pm +02, Jörg-Volker Peetz wrote:


Hello,
thanks for looking into this.
 From a terminal (rxvt-unicode) running my shell (mksh) I start emacs
(emacs-lucid). After about 15 seconds the following warnings appear:

  ■  Warning (comp): debian-el.el:90:26: Warning: reference to free variable 
‘di\
red-mode-map’
  ■  Warning (comp): debian-el.el:90:26: Warning: reference to free variable 
‘di\
red-mode-map’
  ■  Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of 
u\
nescaped single quotes (use \= or different quoting)
  ■  Warning (comp): mmm-vars.el:869:2: Warning: defvar `mmm-classes-alist' 
docs\
tring has wrong usage of unescaped single quotes (use \= or different quoting)
  ■  Warning (comp): mmm-auto.el:168:2: Warning: docstring has wrong usage of 
un\
escaped single quotes (use \= or different quoting)

I stop emacs (C-x C-c) and start the next emacs. And again, after about the same
time the same warnings appear.
As I understand it, the second emacs is re-compiling the modules mentioned in
the warnings (and others, as can be seen in the eln-cache directory).


The fact the warnings appear does not necessarily mean that any
recompilation occurs.


The time stamp of the eln files in the cache directory changes.



init.el is appended.


We'd need a reproduction with 'emacs -q'.


Right you are... It doesn't happen with 'emacs -q'.
And putting just these lines:

;;; Set eln-cache dir
(when (boundp 'native-comp-eln-load-path)
  (setcar native-comp-eln-load-path
  (expand-file-name "~/.cache/emacs-eln-cache/" user-emacs-directory)))

into init.el and starting 'emacs' makes the flaw happen.
--
Regards,
Jörg.

Bug#1051465: [Debian-on-mobile-maintainers] Bug#1051465: unl0kr: Lacks automated migration when osk-sdl is already installed

[undef]

I seem to have dropped the BTS on reply, so including the history in 
this email.



Another option I realized might work is to add a `breaks` and `replaces` 
osk-sdl in unl0kr then ship a link from the osk-sdl keyscript to the 
unl0kr one in unl0kr. I haven't tested anything at this point, but this 
would mean we don't have to modify people's crypttab.


Some potential issues for this option:

* It would require an update to osk-sdl to make sure the crypttab config 
isn't removed if unl0kr is also installed.


* A user removing osk-sdl manually then installing unl0kr would need to 
configure things manually. Then again, neither would 3a below.


On 9/9/23 21:04, Arnaud Ferraris wrote:

Le 09/09/2023 à 11:27, undef via Debian-on-mobile-maintainers a écrit :

Thanks for getting the ball rolling on this one.

I think in the first instance we should switch c-s-m to unl0kr to 
catch new installs as you say. That'll stop the problem from getting 
worse. It would probably be a good idea to ask more technical users 
to make the switch too before making this type of change.


Yes, I believe this should be done ASAP as I think currently there's 
only the 2 of us actively using unl0kr, so getting it into more hands 
will likely help catch bugs and make it more stable.




After that, I have a couple of thoughts on the automated transition:

1. If unl0kr is installed while osk-sdl is it should probably do 
nothing. This avoids breaking working installs.


This is fine for now, but I think it should be revisited at some point 
in the future (ideally pre-trixie release, see below).




2. If unl0kr is installed and osk-sdl isn't it should check for 
osk-sdl's debconf setting indicating that c-s-m or similar configured 
crypttab in the first place. If this is set unl0kr could attempt to 
add its keyscript to the crypttab.


 a. This probably also requires a release of osk-sdl with the 
inverse to:


     * Deconfigure itself

     * Configure unl0kr

     * Set unl0kr's debconf flag as osk-sdl's is.


That sounds reasonable indeed.



3. A new install of unl0kr without osk-sdl ever having been installed 
could either:


 a. Do nothing, leaving the package installed in a dormant state 
as it is now.


 b. Prompt loudly using debconf then automatically attempt to 
configure (this is somewhat recommended against in debconf's docs).


 c. Just automatically attempt to configure (negating the need 
for 2).



I'm somewhat reticent to do 3c as this will break installs that are 
non-standard (say someone's configured a TPM or yubikey unlock), but 
there is at least some desire for the package automatically 
configuring the system: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028554


I think that 3a is the best option here, as it basically matches the 
current behaviour of osk-sdl, which is just fine.





That leaves the matter of how do we trigger the switch? Currently the 
only packages installed indicating FDE on Mobian devices are unl0kr 
and osk-sdl. I can't think of a neat way to cause one to be removed 
and replaced with the other without triggering the install on non-FDE 
devices.


I'm leaving the "how" aside for now, rather discussing the "why" here: 
IIUC osk-sdl is now unmaintained and will likely stay that way; 
therefore, as it's a rather critical component (in the sense that it 
deals with secrets/encryption) I believe it shouldn't be part of the 
upcoming Trixie release.


New installs (after the upcoming c-s-m changes are in) won't be 
affected, which is already a good thing; but I'm a bit reluctant to 
leave existing users with an unmaintained critical component, hence my 
belief that an automated migration would be nice.


As suggested by the bug severity this isn't an urgent matter though, 
and the idea of dropping osk-sdl for trixie can also be discussed.


Cheers,
Arnaud

PS: osk-sdl could be made a transitional package at some point, which 
would depend on unl0kr, and would take care of modifying the crypttab 
so unl0kr is used instead.





___
Debian-on-mobile-maintainers mailing list
debian-on-mobile-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers 




___
Debian-on-mobile-maintainers mailing list
debian-on-mobile-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers 

Bug#1051677: emacs: Provides backport of 29.1

[Manphiz]

Sean Whitton  writes:

> Hello,
>
> On Mon 11 Sep 2023 at 12:02pm -07, Manphiz wrote:
>
>> Ah noted.  I guess they'll redirect me to the actual team/person
>> handling the requested packages.
>
> In this case you could have been that person!

I'll try :P

-- 
Manphiz


signature.asc
Description: PGP signature

Bug#1051759: opencpn/5.8.4+dfsg-1~bpo12+1 -- Open Source Chartplotter and Marine GPS Navigation Software

[Alec Leamas]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my backport of the package "opencpn". 
This is a clean rebuild of the package in sid. I have DM rights for 
opencpn. However, this does not allow me to even upload for review by 
ftp-masters so I need some DD help to enter the NEW queue.


Details:

 * Package name : opencpn
   Version  : 5.8.4+dfsg-1~bpo12+1
   Upstream contact : Dave S. Register 
 * URL  : https://opencpn.org
 * License  : SGI-B-2.0, SGI-B-1.1, GPL-2, Expat, 
public-domain, GPL-2+, LGPL-2+, Khronos, BSD-3-clause, wxWidgets, 
GPL-3+, GPL-3, Expat or GPL-2+

 * Vcs  : https://gitlab.com/leamas/opencpn
   Section  : misc

The source builds two binary packages:

  opencpn - Open Source Chartplotter and Marine GPS Navigation Software
  opencpn-data - Open Source Chartplotter and Marine GPS Navigation 
Software (data)


More info on https://mentors.debian.net/package/opencpn or using

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.8.4+dfsg-1~bpo12+1.dsc


Changes since the last upload:

 opencpn (5.8.4+dfsg-1~bpo12+1) bookworm-backports; urgency=medium
 .
   * New upstream release
   * Rebuilt for bookworm-backports.

Regards,
--
  Alec Leamas

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Jonas Smedegaard]

Quoting Hideki Yamane (2023-09-12 09:27:12)
> On Sun, 10 Sep 2023 18:29:36 +0200
> Bill Allombert  wrote:
> > Or we could generate DEBIAN/copyright from debian/copyright using data in
> > license-common-list at build time. So maintainers would not need to manage 
> > the copying
> > themselves.
> 
>  One problem is, that some software declares that they use some licenses
>  (e.g. MIT), but sometimes they modify the license term itself a bit.
>  So, there's a difference between words in the license list and some words
>  in the included license in such software.
> 
>  It'd be better to find such software and ask upstream to fix it to use
>  proper license terms, by tagging it at BTS. And, it's NOT Debian specific
>  issues, so it may be better to ask folks to join such a movement then, IMHO.

I can only assume that the proposal for an automated DEBIAN/copyright
file is limited to source files *possible* to automatically process, and
consequently only relates to debian/copyright files written in the
machine-readable format.

The problem you describe about ambiguous MIT-derived licensing cannot,
in by understanding, occur using the machine-readable format - only with
less strictly structured debian/copyright files.

If you mean to say that ambiguous MIT declarations exist in
debian/copyright files written using the machine-readable format, then
please point to an example, as I cannot imagine how that would look.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#1051760: upstream autopgtest fails due to missing tzdata-legacy

[Michael Biebl]

Source: systemd
Version: 254.1-3
Severity: important

The upstream autopkgtest fails on Debian sid:

TEST-01-BASIC:  FAIL ( 55 s)
TEST-02-UNITTESTS:  FAIL (2401 s)
TEST-03-JOBS:   FAIL (  2 s)
TEST-04-JOURNAL:FAIL (  2 s)
TEST-05-RLIMITS:FAIL (  2 s)
TEST-06-SELINUX:SUCCESS  (  0 s)
TEST-07-PID1:   FAIL (  2 s)
TEST-13-NSPAWN: FAIL ( 55 s)
TEST-15-DROPIN: FAIL (  2 s)
TEST-16-EXTEND-TIMEOUT: FAIL (  1 s)
TEST-17-UDEV:   FAIL ( 54 s)
TEST-18-FAILUREACTION:  FAIL (  2 s)
TEST-19-CGROUP: FAIL (  1 s)
TEST-21-DFUZZER:SUCCESS  (  0 s)
TEST-22-TMPFILES:   FAIL (  3 s)
TEST-23-UNIT-FILE:  FAIL (  1 s)
TEST-24-CRYPTSETUP: FAIL ( 57 s)
TEST-25-IMPORT: FAIL (  2 s)
TEST-26-SYSTEMCTL:  FAIL (  1 s)
TEST-29-PORTABLE:   FAIL ( 60 s)
TEST-30-ONCLOCKCHANGE:  FAIL ( 53 s)
TEST-31-DEVICE-ENUMERATION: FAIL ( 53 s)
TEST-32-OOMPOLICY:  FAIL ( 53 s)
TEST-34-DYNAMICUSERMIGRATE: FAIL (  2 s)
TEST-35-LOGIN:  FAIL (  2 s)
TEST-36-NUMAPOLICY: FAIL ( 55 s)
TEST-38-FREEZER:FAIL ( 53 s)
TEST-43-PRIVATEUSER-UNPRIV: FAIL (  4 s)
TEST-44-LOG-NAMESPACE:  FAIL (  2 s)
TEST-45-TIMEDATE:   FAIL (  2 s)
TEST-46-HOMED:  FAIL (  2 s)
TEST-50-DISSECT:FAIL ( 59 s)
TEST-52-HONORFIRSTSHUTDOWN: FAIL (107 s)
TEST-53-ISSUE-16347:FAIL ( 54 s)
TEST-54-CREDS:  FAIL (  2 s)
TEST-55-OOMD:   FAIL ( 57 s)
TEST-58-REPART: FAIL ( 56 s)
TEST-59-RELOADING-RESTART:  FAIL (  2 s)
TEST-60-MOUNT-RATELIMIT:FAIL (  2 s)
TEST-62-RESTRICT-IFACES:FAIL ( 54 s)
TEST-63-PATH:   FAIL (  2 s)
TEST-64-UDEV-STORAGE:   FAIL (503 s)
TEST-65-ANALYZE:FAIL (  2 s)
TEST-66-DEVICE-ISOLATION:   FAIL ( 54 s)
TEST-67-INTEGRITY:  FAIL ( 59 s)
TEST-68-PROPAGATE-EXIT-STATUS:  FAIL (  2 s)
TEST-69-SHUTDOWN:   FAIL (  3 s)
TEST-70-TPM2:   FAIL ( 59 s)
TEST-71-HOSTNAME:   FAIL (  2 s)
TEST-72-SYSUPDATE:  FAIL (  2 s)
TEST-73-LOCALE: FAIL (  2 s)
TEST-74-AUX-UTILS:  FAIL (  2 s)
TEST-75-RESOLVED:   FAIL (  3 s)
TEST-76-SYSCTL: FAIL (  2 s)
TEST-77-OPENFILE:   FAIL (  2 s)
TEST-78-SIGQUEUE:   SUCCESS  (  2 s)
TEST-79-MEMPRESS:   SUCCESS  (  2 s)
TEST-80-NOTIFYACCESS:   FAIL (  2 s)
TEST-81-GENERATORS: FAIL (  2 s)
TEST-82-SOFTREBOOT: FAIL (  2 s)

TOTAL FAILURES: 56 OF 60


It appears tzdata-legacy is not installed in the autopkgtest VM despite
`tzdata-legacy | tzdata,`

Asking in #debci:

mbiebl >>
we have "Depends: tzdata-legacy | tzdata" in one of our autopkgtests.
This doesn't result in "tzdata-legacy" to be installed though (in sid)

Myon >>
why should it, when tzdata is already present
tzdata-legacy  | tzdata (<< 2023c-8) ,
(in B-D)

mbiebl >>
I thought tzdata-legacy is tried first and it only falls back to
installing tzdata if tzdata-legacy is not available

Myon >>
that's what the buildds do, but autopkgtest is different
but even there it will likely just use tzdata when that is already
installed from the base system, I think

mbiebl >>
ok, good to know
Will use tzdata-legacy  | tzdata (<< 2023c-8)  for
b-dep and tzdata-legacy | tzdata (<< 2023c-8) for debian/tests/control
then
helmut >>
@mbiebl  tzdata-legacy will be tried first unless one of the
alternatives is already satisfied at the time of resolving. your
solution is correct.
admittedly that number of packages that need a dependency on
tzdata-legacy makes me question whether the split was performed in the
right way

Bug#1051761: zram-tools: I get error during boot process that zramswap failed to start.

[Pankaj Agarwal]

Package: zram-tools
Version: 0.3.3.1-1.1
Severity: normal
X-Debbugs-Cc: quasar.pan...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
It started after I installed the zramtools package. I get two errors
one is related to not being able to reserve MMIO and the other relates to zram
swap service not starting.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I googled the problem, found some blogs that showed me how to configure
zramswap but that made the situation worse.
   * What was the outcome of this action?
The situation became worse with too many errors coming up as regards
zramswap.
   * What outcome did you expect instead?
I expect the syatem to boot cleanly without any errors. Although
zramswap apparently works when I see the system monitor.

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


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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-3+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- Configuration Files:
/etc/default/zramswap changed:
ALGO=lz4
PERCENT=50


-- no debconf information

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Linux regression tracking (Thorsten Leemhuis)]

On 12.09.23 00:57, Pablo Neira Ayuso wrote:
> On Mon, Sep 11, 2023 at 11:37:50PM +0200, Timo Sigurdsson wrote:
>>
>> recently, Debian updated their stable kernel from 6.1.38 to 6.1.52
>> which broke nftables ruleset loading on one of my machines with lots
>> of "Operation not supported" errors. I've reported this to the
>> Debian project (see link below) and Salvatore Bonaccorso and I
>> identified "netfilter: nf_tables: disallow rule addition to bound
>> chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending commit
>> that introduced the regression. Salvatore also found that this issue
>> affects the 5.10 stable tree as well (observed in 5.10.191), but he
>> cannot reproduce it on 6.4.13 and 6.5.2.
>>
>> The issue only occurs with some rulesets. While I can't trigger it
>> with simple/minimal rulesets that I use on some machines, it does
>> occur with a more complex ruleset that has been in use for months
>> (if not years, for large parts of it). I'm attaching a somewhat
>> stripped down version of the ruleset from the machine I originally
>> observed this issue on. It's still not a small or simple ruleset,
>> but I'll try to reduce it further when I have more time.
>>
>> The error messages shown when trying to load the ruleset don't seem
>> to be helpful. Just two simple examples: Just to give two simple
>> examples from the log when nftables fails to start:
>> /etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not 
>> supported
>> tcp option maxseg size 1-500 counter drop
>> ^
>> /etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not 
>> supported
>> tcp dport sip-tls accept
>> 
> 
> I can reproduce this issue with 5.10.191 and 6.1.52 and nftables v1.0.6,
> this is not reproducible with v1.0.7 and v1.0.8.
> 
>> Since the issue only affects some stable trees, Salvatore thought it
>> might be an incomplete backport that causes this.
>>
>> If you need further information, please let me know.
> 
> Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
> kernel check that rejects adding rules to bound chains. The incorrect
> bytecode adds the chain binding, attach it to the rule and it adds the
> rules to the chain binding. I have cherry-picked these three patches
> for nftables v1.0.6 userspace and your ruleset restores fine.
> [...]

H. Well, this sounds like a kernel regression to me that normally
should be dealt with on the kernel level, as users after updating the
kernel should never have to update any userspace stuff to continue what
they have been doing before the kernel update.

Can't the kernel somehow detect the incorrect bytecode and do the right
thing(tm) somehow?

But yes, don't worry, I know that reality is not black and white and
that it's crucial that things like package filtering do exactly what the
user expect it to do; that's why this might be one of those rare
situations where "user has to update userspace components to support
newer kernels" might be the better of two bad choices. But I had to ask
to ensure it's something like that.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

Bug#1051762: KDE Kontact WebDAV Server Configuration does not accept Server with self signed certificates

[Matthias Faulstich]

Package: kontact
Version: 4:22.12.3-1

Dear Maintainer,

While trying to configure a CalDAV Server like OwnCloud, which uses a self-
signed-certificate, the confirmation of the Certificate is not possible.
Please see attached screenshot.

When the confirmation dialog (Server-Authentifihierung - ...) appears, the
complete Dialog is not activated, no buttons can be clicked. Only the parent
dialogs (akonadi_davgroupware_resource_11 and Einrichten der DAV-Ressource...)
can be selected and clicked.

If one is quick enough, after closing the parent dialogs, the buttons of the
confirmation dialog can be clicked just before the dialog is closed
automatically. But the actions of the buttons will not be performed.

Kind regards
Matthias

Bug#1051763: dpkg: Please backport support for loong64 to oldstable and stable

[John Paul Adrian Glaubitz]

Source: dpkg
Version: 1.21.22
Severity: normal
User: debian-de...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn

Hello!

In order to be able to add loong64-specific changes to source packages, the 
dpkg version on the
infrastructure servers, in particular DAK, needs to be able to recognize 
loong64 in d/control.

Since the servers are running oldstable and stable and loong64 support was only 
added to dpkg
1.22.0, I would like to ask for loong64 to be backported to the dpkg version in 
oldstable and
stable.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1051764: Missing TARGET_OPTION_SAVE/RESTORE on riscv

[Mathieu Malaterre]

Package: gcc-13
Version: 13.2.0-3
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
Affects: src:highway

src:highway fails to compile on riscv64 with LTO. Confirmed upstream.

Bug#1051765: dummy audio output on a huawei mate d15 laptop

[Nikolay Sabelnikov]

Package: alsa-ucm-conf
Package: kernel
Package: firmware-sof-signed
 
On huawei mate d15 laptops, there is a problem with the sound output to the 
speakers or connector, and a dummy sound is written in the settings. I tried to 
edit the configs of the alsa package, but without success. And this problem 
applies to all distributions.  
data about the system with logs https://linux-hardware.org/?probe=a6ace6aed1
 
https://github.com/thesofproject/linux/tree/es8336-v6.0
https://bugzilla.kernel.org/show_bug.cgi?id=215119

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Florian Westphal]

Linux regression tracking (Thorsten Leemhuis)  wrote:
> On 12.09.23 00:57, Pablo Neira Ayuso wrote:
> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
> > kernel check that rejects adding rules to bound chains. The incorrect
> > bytecode adds the chain binding, attach it to the rule and it adds the
> > rules to the chain binding. I have cherry-picked these three patches
> > for nftables v1.0.6 userspace and your ruleset restores fine.
> > [...]
> 
> H. Well, this sounds like a kernel regression to me that normally
> should be dealt with on the kernel level, as users after updating the
> kernel should never have to update any userspace stuff to continue what
> they have been doing before the kernel update.

This is a combo of a userspace bug and this new sanity check that
rejects the incorrect ordering (adding rules to the already-bound
anonymous chain).

nf_tables uses a transaction allor-nothing model, this means that any
error that occurs during a transaction has to be reverse/undo all the
pending changes.  This has caused a myriad of bugs already.

So while this can be theoretically fixed in the kernel I don't see
a sane way to do it.  Error unwinding / recovery from deeply nested
errors is already too complex for my taste.

> Can't the kernel somehow detect the incorrect bytecode and do the right
> thing(tm) somehow?

Theoretically yes, but I don't feel competent enough to do it, just look
at all the UaF bugs of the past month.

Bug#1051766: lintian-brush: apply-multiarch-hints does not finish

[Andreas Tille]

Package: lintian-brush
Version: 0.150
Severity: grave
Justification: renders package unusable

Hi,

after upgrading to lintian-brush 0.150 apply-multiarch-hints just does
not end and I need to kill the actual xterm (even ^C does not back the
prompt).  After killing the xterm it leaves a broken git repository.

I cloned my test repository freshly from salsa and  downgraded to
lintian-brush 0.149.  Then I get:


 $ apply-multiarch-hints 
Traceback (most recent call last):
  File "/usr/bin/apply-multiarch-hints", line 8, in 
sys.exit(main())
 ^^
  File "/usr/lib/python3/dist-packages/lintian_brush/multiarch_hints.py", line 
512, in main
MultiArchHintFixer(hints),
^
TypeError: No constructor defined


No idea whether this gives some hint - but at least neither the git
repository is broken nor I have to interrupt really hard.

Kind regards
   Andreas.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.23.6
ii  libc62.37-8
ii  libgcc-s113.2.0-3
ii  liblzma5 5.4.4-0.1
ii  libpython3.113.11.5-3
ii  libssl3  3.0.10-1
ii  python3  3.11.4-5+b1
ii  python3-breezy   3.3.4-1
ii  python3-debian   0.1.49
ii  python3-debmutate0.67
ii  python3-distro-info  1.5
ii  python3-dulwich  0.21.6-1
ii  python3-iniparse 0.5-1
ii  python3-iso8601  1.0.2-1
ii  python3-levenshtein  0.12.2-2+b4
ii  python3-psycopg2 2.9.6-3
ii  python3-pyinotify0.9.6-2
ii  python3-ruamel.yaml  0.17.21-1
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.12.1-1
ii  python3-tqdm 4.64.1-1
ii  python3-upstream-ontologist  0.1.35-1

Versions of packages lintian-brush recommends:
ii  debhelper  13.11.6
ii  decopy 0.2.4.8-0.1
ii  dos2unix   7.5.1-1
ii  gpg2.2.40-1.1
ii  lintian2.116.3
ii  ognibuild  0.0.18+git20230208.1.9b890a2-1
ii  python3-bs44.12.2-2
ii  python3-debianbts  4.0.1
ii  python3-docutils   0.19+dfsg-7
ii  python3-lxml   4.9.3-1
ii  python3-markdown   3.4.4-1

Versions of packages lintian-brush suggests:
ii  brz-debian 2.8.78
ii  git-buildpackage   0.9.32
ii  gnome-pkg-tools0.22.9
ii  po-debconf 1.0.21+nmu1
ii  postgresql-common  254

-- no debconf information

Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?

[Sean Whitton]

Hello,

On Tue 12 Sep 2023 at 10:14am +02, Jörg-Volker Peetz wrote:

> Right you are... It doesn't happen with 'emacs -q'.
> And putting just these lines:
>
> ;;; Set eln-cache dir
> (when (boundp 'native-comp-eln-load-path)
>   (setcar native-comp-eln-load-path
>   (expand-file-name "~/.cache/emacs-eln-cache/" 
> user-emacs-directory)))
>
> into init.el and starting 'emacs' makes the flaw happen.

And how about if you put them into early-init.el?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1051677: emacs: Provides backport of 29.1

[Sean Whitton]

Hello,

On Tue 12 Sep 2023 at 01:31am -07, Manphiz wrote:

> I'll try :P

No, not now, it's already in backports-NEW.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1051492: is subject necessary

[Alfred Agrell]

And that commit does indeed change window handling:

https://salsa.debian.org/wine-team/wine/-/commit/e055001f272c3a3d7a0b28865f1de9fda13c2f10#fb90e219a3e9d2931384a3375b23cedfd6b428fb

Manually applying that piece to upstream Wine reproduces the issue (or 
at least reproduces issue #1043052 - I don't have Syberia, so I can't 
test that one).


The problem is that escape.drawable is often assigned 0 in the loop, and 
if that happens, it undoes the X11DRV_get_whole_window( top ) and does 
something inappropriate.


Since escape.drawable is already set to 0 at the top of that function, I 
have no idea what warning that patch is trying to remove, and I believe 
the best solution would be simply reverting that part.

Bug#1051767: RM: bornagain [arm64 armel armhf i386 ppc64el s390x] -- ROM; not yet supported by upstream

[Picca Frédéric-Emmanuel]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: bornag...@packages.debian.org, pi...@debian.org
Control: affects -1 + src:bornagain


previously the unit test were not activated. So now we have a real picture of 
what is working and what is not working.

thanks

Bug#1051748: RFP: pdf2htmlex -- convert PDF to HTML without losing text or format

[Johannes Schauer Marin Rodrigues]

Hi,

On Tue, 12 Sep 2023 10:57:57 +0500 Lev Lamberov  wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: pdf2htmlex
>   Version : 0.18.8rc1
>   Upstream Author : Lu Wang  and other contributors
> * URL or Web page : https://github.com/pdf2htmlEX/pdf2htmlEX
> * License : GPL-3+
>   Description : convert PDF to HTML without losing text or format
> 

you are aware that pdf2htmlex used to be part of Debian? It is still in
old-old-stable. It was removed with this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921471

Are you sure it is wise to include that package into Debian again? The issue
tracker is very low on activity:

https://github.com/pdf2htmlEX/pdf2htmlEX/issues

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1051769: ia64 generates wrong-code with LTO

[Mathieu Malaterre]

Package: gcc-12
Version: 12.2.0-12

highway does not seems to work on ia64 with LTO:

https://buildd.debian.org/status/fetch.php?pkg=highway&arch=ia64&ver=1.0.7-3&stamp=1694507301&raw=0

The fun part is that even gdb crash on the generated exe:

 % gdb tests/copy_test
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "ia64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tests/copy_test...
(gdb) r
Starting program: /home/malat/highway-1.0.7/obj-ia64-linux-gnu/tests/copy_test
Failed to read a valid object file image from memory.
Running main() from ./googletest/src/gtest_main.cc

Program received signal SIGSEGV, Segmentation fault.
zsh: abort  gdb tests/copy_test

Bug#1051768: monitoring-plugins-basic: check_disk is very slow

[Arnaud Gomes]

Package: monitoring-plugins-basic
Version: 2.3.3-5
Severity: normal
Tags: patch

Dear Maintainer,

Since upgrading from bullseye to bookworm, check_disk has gotten very
slow on a machine with a huge number of mount points (in excess of 16000).

Our standard call to check_disk used to take around 10 seconds on bullseye,
now it is more than one hour (I gave up before it finished so I can't tell
exactly how long).

The bug has been fixed upstream in commit 0dd1110:
https://github.com/monitoring-plugins/monitoring-plugins/commit/0dd11100aa92bab172293ec9615a8a56b0e35ee6

For reference, here is the upstream bug report:
https://github.com/monitoring-plugins/monitoring-plugins/issues/1919

Could you please cherry-pick commit 0dd1110 in a future release of the
package?

Thanks!

-- 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/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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/bash
Init: systemd (via /run/systemd/system)

Versions of packages monitoring-plugins-basic depends on:
ii  iputils-ping   3:20221126-1
ii  libc6  2.36-9+deb12u1
ii  libssl33.0.9-1
ii  monitoring-plugins-common  2.3.3-5
ii  procps 2:4.0.2-3
ii  ucf3.0043+nmu1

Versions of packages monitoring-plugins-basic recommends:
ii  libcap2-bin  1:2.66-4

Versions of packages monitoring-plugins-basic suggests:
pn  icinga2  

-- no debconf information

Bug#1051770: move services and binaries for AD DC setup to package samba-ad-dc

[Lee Garrett]

Source: samba
Severity: minor
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I believe it would be a good idea to move the binaries and services required for
AD DC operation to the package samba-ad-dc. Currently it's possible to run such
a setup without installing the package, as it's just a metapackage.

Moving the binaries/services over would have the benefit of being able to drop
the support of this package separately from the samba server, as it currently is
for oldstable and older.

Greetings,
Lee


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

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Bug#1051770: move services and binaries for AD DC setup to package samba-ad-dc

[Michael Tokarev]

Control: tag -1 + moreinfo

12.09.2023 14:14, Lee Garrett wrote:

Source: samba
Severity: minor
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I believe it would be a good idea to move the binaries and services required for
AD DC operation to the package samba-ad-dc. Currently it's possible to run such
a setup without installing the package, as it's just a metapackage.


Sure it is a meta-package, and it is described as such.


Moving the binaries/services over would have the benefit of being able to drop
the support of this package separately from the samba server, as it currently is
for oldstable and older.


Which binaries/services do you mean, specially?  I for one know just one: it is
samba.service (and the init script) which starts samba-ad-dc, that's just two 
files.

/mjt

Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?

[Jörg-Volker Peetz]

Hello Sean,

Sean Whitton wrote on 12/09/2023 12:42:

Hello,

On Tue 12 Sep 2023 at 10:14am +02, Jörg-Volker Peetz wrote:


Right you are... It doesn't happen with 'emacs -q'.
And putting just these lines:

;;; Set eln-cache dir
(when (boundp 'native-comp-eln-load-path)
   (setcar native-comp-eln-load-path
   (expand-file-name "~/.cache/emacs-eln-cache/" user-emacs-directory)))

into init.el and starting 'emacs' makes the flaw happen.


And how about if you put them into early-init.el?


thank you very much, that did the trick :-)
Just now I learned about the Early Init File from you.
As far as I'm concerned, the bug can be closed.
--
Regards,
Jörg.

Bug#1051771: RM: genx [arm64 armel armhf i386 mips64el s390x] -- ROM; failure due to the numba dependency

[Picca Frédéric-Emmanuel]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: g...@packages.debian.org, pi...@debian.org
Control: affects -1 + src:genx

Hello, the new version of genx added test about the numba part. Currently the 
numba  package is in bad shape for the listed architecture. So it should be 
great to reset the status of genx and  migrate with only the few working 
architectures. If numba improved during the release cycle then more 
architecture could be supported by genx.

thanks for considering

Frederic

Bug#1051772: Fwd: ia64 generates wrong-code with LTO

[Mathieu Malaterre]

Package: gcc-13
Version: 13.2.0-3

highway does not seem to work on ia64 with LTO (see #1051769).

On yttrium with gcc-13:

% /usr/bin/g++-13 -g -O2 -ffile-prefix-map=/home/malat/highway-1.0.7=.
-flto=auto -ffat-lto-objects -specs=/usr/share/dpkg/pie-compile.specs
-Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time
-D_FORTIFY_SOURCE=2 -flto=auto -ffat-lto-objects
-specs=/usr/share/dpkg/pie-link.specs -fPIE -pie
CMakeFiles/copy_test.dir/hwy/contrib/algo/copy_test.cc.o -o
tests/copy_test
-Wl,-rpath,/home/malat/highway-1.0.7/obj-ia64-linux-gnu
libhwy_test.so.1.0.7 libhwy_contrib.so.1.0.7
/usr/lib/ia64-linux-gnu/libgtest.a
/usr/lib/ia64-linux-gnu/libgtest_main.a libhwy.so.1.0.7
/usr/lib/ia64-linux-gnu/libgtest.a

% gdb ./tests/copy_test
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "ia64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./tests/copy_test...
(gdb) r
Starting program: /home/malat/highway-1.0.7/obj-ia64-linux-gnu/tests/copy_test
Failed to read a valid object file image from memory.
Running main() from ./googletest/src/gtest_main.cc

Program received signal SIGSEGV, Segmentation fault.
zsh: abort  gdb ./tests/copy_test

Bug#1051773: mirror listing update for mirror.siwoo.org

[Archive of Siwoo]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirror.siwoo.org
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Archive of Siwoo 
Country: KR Korea, Republic of
Location: Gwangju, Republic of Korea
Sponsor: Siwoo Lim https://blog.siwoo.life
Comment: Recently, due to the relocation of IDC, we are also trying to change 
the mirror server to a new
  system. Therefore, I would like to request that all information of the 
existing "anigil.com "
 be changed to the new system "siwoo.org ".




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

Bug#1051774: python3-pysnmp4: Asyncio backend is incompatible with default Python 3.11

[Adam Cecile]

Package: python3-pysnmp4
Version: 4.4.12-2
Severity: important

Hello,

Current version shipped with Debian 12 is partially broken, asyncio backend is
using deprecated feature that have been removed from Python 3.11:

Traceback (most recent call last):
  File "/home/acecile/dev/c/ltms/monitoring/check-ntcip-road-
sign/check_ntcip_road_sign.py", line 16, in 
from pysnmp.hlapi.asyncio import SnmpEngine, getCmd, CommunityData,
UdpTransportTarget, ContextData, ObjectType, ObjectIdentity
  File "/usr/lib/python3/dist-packages/pysnmp/hlapi/asyncio/__init__.py", line
12, in 
from pysnmp.hlapi.asyncio.transport import *
  File "/usr/lib/python3/dist-packages/pysnmp/hlapi/asyncio/transport.py", line
9, in 
from pysnmp.carrier.asyncio.dgram import udp, udp6
  File "/usr/lib/python3/dist-packages/pysnmp/carrier/asyncio/dgram/udp.py",
line 35, in 
from pysnmp.carrier.asyncio.dgram.base import DgramAsyncioProtocol
  File "/usr/lib/python3/dist-packages/pysnmp/carrier/asyncio/dgram/base.py",
line 36, in 
from pysnmp.carrier.asyncio.base import AbstractAsyncioTransport
  File "/usr/lib/python3/dist-packages/pysnmp/carrier/asyncio/base.py", line
33, in 
from pysnmp.carrier.asyncio.dispatch import AsyncioDispatcher
  File "/usr/lib/python3/dist-packages/pysnmp/carrier/asyncio/dispatch.py",
line 46, in 
class AsyncioDispatcher(AbstractTransportDispatcher):
  File "/usr/lib/python3/dist-packages/pysnmp/carrier/asyncio/dispatch.py",
line 57, in AsyncioDispatcher
@asyncio.coroutine
 ^

After looking at GitHub, here is what I figured out:

* Upstream maintainer of pySNMP4 has passed away so no more update are being
done (https://github.com/etingof/pysnmp/issues/429)
* A new upstream seems to have taken over the project
(https://github.com/lextudio/pysnmp)
* It is probably possible to backport a couple of asyncio fix to get the
package working with Python 3.11, I may be able to help but I'm not sure if
this is the way to go
(https://github.com/lextudio/pysnmp/commits/main/pysnmp/carrier/asyncio/dispatch.py)

In my opinion the bug is serious enough to require a fix for Debian 12, but it
is not my call. I'll try to backport asyncio fixes from new upstream into
stable package to see if it helps.

Best regards, Adam.


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

Kernel: Linux 6.1.0-11-amd64 (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 python3-pysnmp4 depends on:
ii  python3   3.11.2-1+b1
ii  python3-pyasn10.4.8-3
ii  python3-pycryptodome  3.11.0+dfsg1-4
ii  python3-pysmi 0.3.2-3

python3-pysnmp4 recommends no packages.

python3-pysnmp4 suggests no packages.

-- no debconf information

Bug#1050929: telegram-desktop: System window decorations disabled on Wayland after 4.9.3

[Nicholas Guriev]

Hello!

On Mon, 4 Sep 2023 21:35:22 -0300 z411  wrote:
> Telegram already used Wayland before this (as do all Qt5/Qt6 apps) and 
> it had the option for system decorations. The icon also worked, for some 
> reason it doesn't work now.

Since version 4.8.3 Telegram Desktop needs Qt6 for complete Wayland
integration.  Although, our package is build against Qt5 yet. Some plugins that
tdesktop relies on were not built against the latest Qt, and migration was
postponed.

> The latest official release (4.9.3) also works on Wayland with system 
> decorations, and the 4.8.1 Debian package works as well. Even with 
> QT_QPA_PLATFORM=wayland. It even shows some warnings related to Wayland 
> and xeyes shows me it's not running under XWayland. Please correct me if 
> I'm wrong.
> 
> > In genuine Wayland there is no such thing as system decorations.
> 
> As far as I understand, there is, there's the xdg-decoration-v1 protocol 
> supported by KWin and Sway which they use to draw system decorations on 
> Wayland windows.

You are right but this protocol is an optional part of Wayland. KWin in KDE
Plasma implements the protocol, Mutter in GNOME does not.

For now, I will block the native Wayland integration and the coming update will
prefer Xwayland because of unresolved glitches. The default window frame looks
not as intended, it has no context menu, and it can double while switching the
checkbox "Use system window frame" in the Settings.

Of course, you always can force native Wayland but at your own risk. I will
also add a patch restoring the checkbox in all modes.

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Timo Sigurdsson]

Hi Pablo,

Pablo Neira Ayuso schrieb am 12.09.2023 00:57 (GMT +02:00):

> Hi Timo,
> 
> On Mon, Sep 11, 2023 at 11:37:50PM +0200, Timo Sigurdsson wrote:
>> Hi,
>> 
>> recently, Debian updated their stable kernel from 6.1.38 to 6.1.52
>> which broke nftables ruleset loading on one of my machines with lots
>> of "Operation not supported" errors. I've reported this to the
>> Debian project (see link below) and Salvatore Bonaccorso and I
>> identified "netfilter: nf_tables: disallow rule addition to bound
>> chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending commit
>> that introduced the regression. Salvatore also found that this issue
>> affects the 5.10 stable tree as well (observed in 5.10.191), but he
>> cannot reproduce it on 6.4.13 and 6.5.2.
>> 
>> The issue only occurs with some rulesets. While I can't trigger it
>> with simple/minimal rulesets that I use on some machines, it does
>> occur with a more complex ruleset that has been in use for months
>> (if not years, for large parts of it). I'm attaching a somewhat
>> stripped down version of the ruleset from the machine I originally
>> observed this issue on. It's still not a small or simple ruleset,
>> but I'll try to reduce it further when I have more time.
>> 
>> The error messages shown when trying to load the ruleset don't seem
>> to be helpful. Just two simple examples: Just to give two simple
>> examples from the log when nftables fails to start:
>> /etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not
>> supported
>> tcp option maxseg size 1-500 counter drop
>> ^
>> /etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not
>> supported
>> tcp dport sip-tls accept
>> 
> 
> I can reproduce this issue with 5.10.191 and 6.1.52 and nftables v1.0.6,
> this is not reproducible with v1.0.7 and v1.0.8.
> 
>> Since the issue only affects some stable trees, Salvatore thought it
>> might be an incomplete backport that causes this.
>> 
>> If you need further information, please let me know.
> 
> Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
> kernel check that rejects adding rules to bound chains. The incorrect
> bytecode adds the chain binding, attach it to the rule and it adds the
> rules to the chain binding. I have cherry-picked these three patches
> for nftables v1.0.6 userspace and your ruleset restores fine.

hmm, that doesn't explain why Salvatore didn't observe this with more recent 
kernels.

Salvatore, did you use newer userspace components when you tested your 6.4.13 
and 6.5.2 builds?

As for the regression and how it be dealt with: Personally, I don't really care 
whether the regression is solved in the kernel or userspace. If everybody 
agrees that this is the best or only viable option and Debian decides to push a 
nftables update to fix this, that works for me. But I do feel the burden to 
justify this should be high. A kernel change that leaves users without a 
working packet filter after upgrading their machines is serious, if you ask me. 
And since it affects several stable/longterm trees, I would assume this will 
hit other stable (non-rolling) distributions as well, since they will also use 
older userspace components (unless this is behavior specific to nftables 1.0.6 
but not older versions). They probably should get a heads up then.


Regards,

Timo

Bug#1051775: hardinfo: Please add support for hardinfo

[yalingfang]

Package: hardinfo
Version: 0.5.1+git20180227-2.1
Severity: wishlist
Tags: patch
User:debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainers,

   When I compiled hardinfo for loongarch architecture, the unsupport arch 
happened.

We have added loong64 check for hardinfo, the patch

can be found in the attachment.

or you can refer the patch https://github.com/lpereira/hardinfo/pull/631

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

Thanks!

Description: Add loongarch64 support
Signed-off-by: liuxiang 
Pull request link: https://github.com/lpereira/hardinfo/pull/631
Last-Update: 2023-09-12

--- hardinfo-0.5.1+git20180227.orig/CMakeLists.txt
+++ hardinfo-0.5.1+git20180227/CMakeLists.txt
@@ -50,6 +50,8 @@ elseif(${CMAKE_HOST_SYSTEM_PROCESSOR} MA
 	set(HARDINFO_ARCH "sh")
 elseif(${CMAKE_HOST_SYSTEM_PROCESSOR} MATCHES "(riscv|riscv32|riscv64)")
 	set(HARDINFO_ARCH "riscv")
+elseif(${CMAKE_HOST_SYSTEM_PROCESSOR} MATCHES "loongarch64")
+   set(HARDINFO_ARCH "loongarch64")
 else()
 	message(FATAL_ERROR "Unsupported architecture: ${CMAKE_HOST_SYSTEM_PROCESSOR}")
 endif()
--- /dev/null
+++ hardinfo-0.5.1+git20180227/includes/loongarch64/processor-platform.h
@@ -0,0 +1,28 @@
+/*
+ *HardInfo - Displays System Information
+ *Copyright (C) 2003-2006 Leandro A. F. Pereira 
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation, version 2.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License
+ *along with this program; if not, write to the Free Software
+ *Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef __PROCESSOR_PLATFORM_H__
+#define __PROCESSOR_PLATFORM_H__
+
+struct _Processor {
+gchar *model_name;
+gchar *vendor_id;
+gfloat bogomips, cpu_mhz;
+};
+
+#endif /* __PROCESSOR_PLATFORM_H__ */
--- /dev/null
+++ hardinfo-0.5.1+git20180227/modules/devices/loongarch64/processor.c
@@ -0,0 +1,81 @@
+/*
+ *HardInfo - Displays System Information
+ *Copyright (C) 2003-2006 Leandro A. F. Pereira 
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation, version 2.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License
+ *along with this program; if not, write to the Free Software
+ *Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include "hardinfo.h"
+#include "devices.h"
+#include "cpu_util.h"
+
+GSList *
+processor_scan(void)
+{
+Processor *processor;
+FILE *cpuinfo;
+gchar buffer[128];
+
+cpuinfo = fopen(PROC_CPUINFO, "r");
+if (!cpuinfo)
+return NULL;
+
+processor = g_new0(Processor, 1);
+while (fgets(buffer, 128, cpuinfo)) {
+gchar **tmp = g_strsplit(buffer, ":", 2);
+
+if (tmp[0] && tmp[1]) {
+tmp[0] = g_strstrip(tmp[0]);
+tmp[1] = g_strstrip(tmp[1]);
+
+get_str("system type", processor->vendor_id);
+get_str("model name", processor->model_name);
+get_float("CPU MHz", processor->cpu_mhz);
+get_float("BogoMIPS", processor->bogomips);
+}
+g_strfreev(tmp);
+}
+
+fclose(cpuinfo);
+
+return g_slist_append(NULL, processor);
+}
+
+gchar *processor_name(GSList * processors) {
+return processor_name_default(processors);
+}
+
+gchar *processor_describe(GSList * processors) {
+return processor_describe_default(processors);
+}
+
+gchar *
+processor_get_info(GSList *processors)
+{
+Processor *processor = (Processor *)processors->data;
+
+return g_strdup_printf("[%s]\n"
+"%s=%s\n"
+"%s=%s\n"
+"%s=%.2f %s\n" /* frequency */
+"%s=%.2f\n"/* bogoMIPS */
+"%s=%s\n", /* byte order */
+_("Processor"),
+_("Model"), processor->model_name,
+_("System Type"), processor->vendor_id,
+_("Frequency"), processor->cpu_mhz, _("MHz"),
+_("BogoMIPS"), processor->bogomips,
+_("Byte Order"), byte_order_str()
+   );
+}

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Timo Sigurdsson]

Hi,

Florian Westphal schrieb am 12.09.2023 12:27 (GMT +02:00):

> Linux regression tracking (Thorsten Leemhuis) 
> wrote:
>> On 12.09.23 00:57, Pablo Neira Ayuso wrote:
>> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
>> > kernel check that rejects adding rules to bound chains. The incorrect
>> > bytecode adds the chain binding, attach it to the rule and it adds the
>> > rules to the chain binding. I have cherry-picked these three patches
>> > for nftables v1.0.6 userspace and your ruleset restores fine.
>> > [...]
>> 
>> H. Well, this sounds like a kernel regression to me that normally
>> should be dealt with on the kernel level, as users after updating the
>> kernel should never have to update any userspace stuff to continue what
>> they have been doing before the kernel update.
> 
> This is a combo of a userspace bug and this new sanity check that
> rejects the incorrect ordering (adding rules to the already-bound
> anonymous chain).
> 

Out of curiosity, did the incorrect ordering or bytecode from the older 
userspace components actually lead to a wrong representation of the rules in 
the kernel or did the rules still work despite all that?

Thanks,

Timo 

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Florian Westphal]

Timo Sigurdsson  wrote:
> > Linux regression tracking (Thorsten Leemhuis) 
> > wrote:
> >> On 12.09.23 00:57, Pablo Neira Ayuso wrote:
> >> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
> >> > kernel check that rejects adding rules to bound chains. The incorrect
> >> > bytecode adds the chain binding, attach it to the rule and it adds the
> >> > rules to the chain binding. I have cherry-picked these three patches
> >> > for nftables v1.0.6 userspace and your ruleset restores fine.
> >> > [...]
> >> 
> >> H. Well, this sounds like a kernel regression to me that normally
> >> should be dealt with on the kernel level, as users after updating the
> >> kernel should never have to update any userspace stuff to continue what
> >> they have been doing before the kernel update.
> > 
> > This is a combo of a userspace bug and this new sanity check that
> > rejects the incorrect ordering (adding rules to the already-bound
> > anonymous chain).
> > 
> 
> Out of curiosity, did the incorrect ordering or bytecode from the older 
> userspace components actually lead to a wrong representation of the rules in 
> the kernel or did the rules still work despite all that?

It works, but without the stricter behaviour userspace can trigger
memory corruption in the kernel. nftables userland will not trigger this.

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Pablo Neira Ayuso]

On Tue, Sep 12, 2023 at 01:39:59PM +0200, Timo Sigurdsson wrote:
> Hi Pablo,
> 
> Pablo Neira Ayuso schrieb am 12.09.2023 00:57 (GMT +02:00):
> 
> > Hi Timo,
> > 
> > On Mon, Sep 11, 2023 at 11:37:50PM +0200, Timo Sigurdsson wrote:
> >> Hi,
> >> 
> >> recently, Debian updated their stable kernel from 6.1.38 to 6.1.52
> >> which broke nftables ruleset loading on one of my machines with lots
> >> of "Operation not supported" errors. I've reported this to the
> >> Debian project (see link below) and Salvatore Bonaccorso and I
> >> identified "netfilter: nf_tables: disallow rule addition to bound
> >> chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending commit
> >> that introduced the regression. Salvatore also found that this issue
> >> affects the 5.10 stable tree as well (observed in 5.10.191), but he
> >> cannot reproduce it on 6.4.13 and 6.5.2.
> >> 
> >> The issue only occurs with some rulesets. While I can't trigger it
> >> with simple/minimal rulesets that I use on some machines, it does
> >> occur with a more complex ruleset that has been in use for months
> >> (if not years, for large parts of it). I'm attaching a somewhat
> >> stripped down version of the ruleset from the machine I originally
> >> observed this issue on. It's still not a small or simple ruleset,
> >> but I'll try to reduce it further when I have more time.
> >> 
> >> The error messages shown when trying to load the ruleset don't seem
> >> to be helpful. Just two simple examples: Just to give two simple
> >> examples from the log when nftables fails to start:
> >> /etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not
> >> supported
> >> tcp option maxseg size 1-500 counter drop
> >> ^
> >> /etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not
> >> supported
> >> tcp dport sip-tls accept
> >> 
> > 
> > I can reproduce this issue with 5.10.191 and 6.1.52 and nftables v1.0.6,
> > this is not reproducible with v1.0.7 and v1.0.8.
> > 
> >> Since the issue only affects some stable trees, Salvatore thought it
> >> might be an incomplete backport that causes this.
> >> 
> >> If you need further information, please let me know.
> > 
> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
> > kernel check that rejects adding rules to bound chains. The incorrect
> > bytecode adds the chain binding, attach it to the rule and it adds the
> > rules to the chain binding. I have cherry-picked these three patches
> > for nftables v1.0.6 userspace and your ruleset restores fine.
> 
> hmm, that doesn't explain why Salvatore didn't observe this with
> more recent kernels.
>
> Salvatore, did you use newer userspace components when you tested
> your 6.4.13 and 6.5.2 builds?
> 
> As for the regression and how it be dealt with: Personally, I don't
> really care whether the regression is solved in the kernel or
> userspace. If everybody agrees that this is the best or only viable
> option and Debian decides to push a nftables update to fix this,
> that works for me. But I do feel the burden to justify this should
> be high. A kernel change that leaves users without a working packet
> filter after upgrading their machines is serious, if you ask me. And
> since it affects several stable/longterm trees, I would assume this
> will hit other stable (non-rolling) distributions as well, since
> they will also use older userspace components (unless this is
> behavior specific to nftables 1.0.6 but not older versions). They
> probably should get a heads up then.

There is coverage for the chain binding feature in our tests
infrastructure, but unfortunately the bug did not trigger with newer
nftables versions. In the future, I will keep an eye with running our
tests on older userspace nftables versions when working on stable
trees.

Bug#1051776: libxxhash-dev: libxxhash.pc has doubled ${prefix}s

[Michael R. Crusoe]

Package: libxxhash-dev
Version: 0.8.2-1
Severity: normal
X-Debbugs-Cc: cru...@debian.org

In 0.8.1-1, libxxhash.pc defines the following

exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib/x86_64-linux-gnu

In 0.8.2-1 the prefixes are doubled:

exec_prefix=${prefix}/${prefix}
includedir=${prefix}/${prefix}/include
libdir=${exec_prefix}/${exec_prefix}/lib/x86_64-linux-gnu

This produces nonsense results like

# pkg-config --variable libdir libxxhash
/usr//usr//usr//usr/lib/x86_64-linux-gnu

Which breaks any package with a build-dep on libxxhash-dev and which 
uses pkg-config, like seqan-raptor and its autopkgtests


Looks like the error came from 
https://salsa.debian.org/debian/xxhash/-/commit/1ac98075f1dc2da1b188250ff86fe8ac7975bce3


Attached is a patch to fix this

--
Michael R. Crusoe

commit 91f5401f9535e5490c3c48edfc71abbf7e24956f
Author: Michael R. Crusoe 
Date:   Tue Sep 12 13:57:10 2023 +0200

d/patches: fix libxxhash.pc.in

diff --git a/debian/changelog b/debian/changelog
index 5f7db32..57d3d53 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xxhash (0.8.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * d/patches: fix libxxhash.pc.in
+
+ -- Michael R. Crusoe   Tue, 12 Sep 2023 13:57:05 +0200
+
 xxhash (0.8.2-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
index d55a483..4f86ca6 100644
--- a/debian/patches/reproducible-build.patch
+++ b/debian/patches/reproducible-build.patch
@@ -2,20 +2,14 @@ Description: Make the build reproducible
 Author: Chris Lamb 
 Last-Update: 2023-09-10
 
 a/libxxhash.pc.in
-+++ b/libxxhash.pc.in
-@@ -2,10 +2,10 @@
+--- xxhash.orig/libxxhash.pc.in
 xxhash/libxxhash.pc.in
+@@ -2,7 +2,7 @@
  #   Copyright (C) 2012-2021, Yann Collet, Facebook
  #   BSD 2-Clause License (https://www.opensource.org/licenses/bsd-license.php)
  
 -prefix=@PREFIX@
--exec_prefix=@EXECPREFIX@
--includedir=@INCLUDEDIR@
--libdir=@LIBDIR@
 +prefix=/usr
-+exec_prefix=${prefix}/@EXECPREFIX@
-+includedir=${prefix}/@INCLUDEDIR@
-+libdir=${exec_prefix}/@LIBDIR@
- 
- Name: xxhash
- Description: extremely fast hash algorithm
+ exec_prefix=@EXECPREFIX@
+ includedir=@INCLUDEDIR@
+ libdir=@LIBDIR@


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051777: python3-pymdownx: Update package with a recent upstream version

[Carsten Schoenert]

Package: python3-pymdownx
Version: 9.5-2
Severity: wishlist

Hi,

please package a recent version of pymdown-extensions, the current
version in the archive is almost over a year old.

Thanks!

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

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

Versions of packages python3-pymdownx depends on:
ii  python3   3.11.4-5+b1
ii  python3-markdown  3.4.4-1

python3-pymdownx recommends no packages.

python3-pymdownx suggests no packages.

-- no debconf information

Bug#1051644: adduser: [INTL:pt] Update on Portuguese translation of MANPAGE

[Marc Haber]

Control: tags -1 moreinfo

Hi Américo,

thanks for your work. Can you please give the translation a meaningful
copyright clause, it surely isn't copyright 2010 by the FSF.

Thank you in advance.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1051778: gnuradio: Block "RFNoC Graph (Device)" cannot be used in GNURadio companion

[Thomas Lorblanchès]

Package: gnuradio
Version: 3.10.5.1-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Under GNURadio companion (Debian 12), I want to use the "RFNoC Graph (Device)" 
block.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Drag the "RFNoc Graph (Device)" menu entry and drop it on the flowgraph window.
   * What was the outcome of this action?
The block does not appear in the flowgraph window.
The following error messages are printed in the terminal:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/blocks/_templates.py",
line 77, in render
return template.render(**namespace)
   
  File "/usr/lib/python3/dist-packages/mako/template.py", line 439, in render
return runtime._render(self, self.callable_, args, data)
   ^
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 874, in _render
_render_context(
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 916, in
_render_context
_exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 943, in
_exec_template
callable_(context, *args, **kwargs)
  File "memory:0x7f3068b802d0", line 43, in render_body
  File "/usr/lib/python3.11/ast.py", line 64, in literal_eval
node_or_string = parse(node_or_string.lstrip(" \t"), mode='eval')
 
  File "/usr/lib/python3.11/ast.py", line 50, in parse
return compile(source, filename, mode, flags,
   ^^
  File "", line 0

SyntaxError: invalid syntax

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/Application.py", line
409, in _handle_action
flow_graph_update()
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/Application.py", line
110, in flow_graph_update
fg.update()
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/canvas/flowgraph.py",
line 192, in update
self.rewrite()
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/FlowGraph.py", line
232, in rewrite
self.renew_namespace()
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/FlowGraph.py", line
284, in renew_namespace
for variable_block in self.get_variables():
  
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/FlowGraph.py", line
73, in get_variables
return expr_utils.sort_objects(variables, attrgetter('name'),
methodcaller('get_var_make'))

  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/utils/expr_utils.py",
line 61, in sort_objects
id2expr = {get_id(obj): get_expr(obj) for obj in objects}
  ^^^
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/utils/expr_utils.py",
line 61, in 
id2expr = {get_id(obj): get_expr(obj) for obj in objects}
^
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/blocks/block.py", line
396, in get_var_make
return self.templates.render('var_make')
   ^
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/blocks/_templates.py",
line 79, in render
raise TemplateError(error, text)
gnuradio.grc.core.errors.TemplateError: (SyntaxError('invalid syntax',
('', 0, 0, '', 0, 0)), '<%\nimport ast\n# Sanitize\n
graph_args = ast.literal_eval(dev_addr.strip())\ndev_args_s =
ast.literal_eval(dev_args.strip())\nclock_source_s =
ast.literal_eval(clock_source.strip())\ntime_source_s =
ast.literal_eval(time_source.strip())\n# Build full dev args\nif
dev_args_s:\ngraph_args += f",{clock_source_s}"\nif
clock_source_s:\ngraph_args += f",clock_source={clock_source_s}"\n
if time_source_s:\ngraph_args +=
f",time_source={time_source_s}"\n%>\nself.rfnoc_graph = ${id} =
uhd.rfnoc_graph(uhd.device_addr("${graph_args}"))\n')

   * What outcome did you expect instead?

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


-- 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-12-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnuradio depends on:
ii  gnome-terminal [x-terminal-emulator]  3.46.8-1
ii  libboost-program-options1.74.0

Bug#1041312: [Pkg-fonts-devel] Bug#1041312: fonts-noto: Migrate to new upstream sources, and split the fonts according to upstream

[fabian]

Hi Amr,

Am 2023-07-17 12:19, schrieb Amr Ibrahim:

https://github.com/notofonts/notofonts.github.io


the fonts appear to be organized into different subdirectories with 
varying content.


Do you know upstream's stance on this? Is hinted/ttf always preferable 
over unhinted/* and what's the matter with the fonts in googlefonts/*? 
And how about the unhinted/variable-ttf, unhinted/slim-variable-ttf and 
unhinted/otf variants?


You can see from that website that upstream releases individual font 
files. So

please try to re-package the font files in Debian accordingly.


They offer a snapshow of the entire repository for download in the 
Releases section:


https://github.com/notofonts/notofonts.github.io/releases

These could be downloaded, have the undesired fonts stripped off, get 
repacked and split up into indiviual Debian packages.


I have to admit that I just tried this for the fun, but gave up when the 
download size reached 1GB. o_O


Cheers,

 - Fabian

Bug#1050071: llvm-defaults: move to 16

[Adrian Bunk]

On Mon, Sep 11, 2023 at 10:36:00AM +0100, Simon McVittie wrote:
> On Sat, 19 Aug 2023 at 10:39:44 +0200, Sylvestre Ledru wrote:
> > llvm-defaults has been pointing to 16 in experimental for quite sometime.
> > Opening this transition to make sure it is on your radar! :)
> > 
> > I opened bug #1050070 & #1050069 for future removals.
> 
> Mesa is a significant user of LLVM, and hard-codes its own non-default
> version of LLVM which often runs ahead of the default (currently 15).
> It seems to be relatively common for a LLVM version upgrade to cause
> regressions or uninstallability on at least one architecture, and also
> relatively common for a LLVM version upgrade to be necessary to unblock
> features or bug fixes in Mesa, which I assume is why the Mesa maintainers
> have felt the need to control this themselves.
> 
> Should Mesa try moving to -16 *before* the default changes? It would
> seem unhelpful to move the rest of the distribution to a version that
> Mesa can't use for whatever reason.
>...

Mesa is not the sole user of a non-default LLVM.

This transition is about changing the default, which affects the 
packages that use the default version.

Users of non-default LLVM like mesa/rustc/chromium/ghc/qt6-tools/... 
move at their own pace (otherwise they would use the default LLVM).

> smcv

cu
Adrian

Bug#1050071: llvm-defaults: move to 16

[Sylvestre Ledru]

Le 12/09/2023 à 14:29, Adrian Bunk a écrit :

On Mon, Sep 11, 2023 at 10:36:00AM +0100, Simon McVittie wrote:

On Sat, 19 Aug 2023 at 10:39:44 +0200, Sylvestre Ledru wrote:

llvm-defaults has been pointing to 16 in experimental for quite sometime.
Opening this transition to make sure it is on your radar! :)

I opened bug #1050070 & #1050069 for future removals.


Mesa is a significant user of LLVM, and hard-codes its own non-default
version of LLVM which often runs ahead of the default (currently 15).
It seems to be relatively common for a LLVM version upgrade to cause
regressions or uninstallability on at least one architecture, and also
relatively common for a LLVM version upgrade to be necessary to unblock
features or bug fixes in Mesa, which I assume is why the Mesa maintainers
have felt the need to control this themselves.

Should Mesa try moving to -16 *before* the default changes? It would
seem unhelpful to move the rest of the distribution to a version that
Mesa can't use for whatever reason.
...


Mesa is not the sole user of a non-default LLVM.

This transition is about changing the default, which affects the
packages that use the default version.

Users of non-default LLVM like mesa/rustc/chromium/ghc/qt6-tools/...
move at their own pace (otherwise they would use the default LLVM).


and they can jump from defaults to specific or the other way around

Cheers,
Sylvestre

Bug#1051778: gnuradio: Block "RFNoC Graph (Device)" cannot be used in GNURadio companion

[Thomas Lorblanchès]

Seems to be related to this bug/fix: 
https://github.com/gnuradio/gnuradio/commit/8e42db980c891ac4e7a1e9ca4fa10fc0f65b5979

Bug#1051780: focus-follows-mouse doesn't work with gnome-shell/mutter 45-rc

[Roderich Schupp]

Package: libmutter-13-0
Version: 45~rc-4
Severity: normal
X-Debbugs-Cc: roderich.sch...@gmail.com

I use focus-follows-mouse, ie. gsettings

org.gnome.desktop.wm.preferences focus-mode 'mouse'
org.gnome.desktop.wm.preferences focus-new-windows 'smart'
org.gnome.mutter focus-change-on-pointer-rest false

but gnome-shell/mutter 45-rc behaves as if focus-mode is set to 'click'.
No change in behaviour, when I set focus-mode to 'sloppy' or toggle
focus-change-on-pointer-rest.


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

Kernel: Linux 6.5.2 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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)

Versions of packages libmutter-13-0 depends on:
ii  adwaita-icon-theme 44.0-1
ii  gsettings-desktop-schemas  45~rc-1
ii  libatk1.0-02.49.91-2
ii  libc6  2.38-3
ii  libcairo-gobject2  1.17.8-3
ii  libcairo2  1.17.8-3
ii  libcanberra0   0.30-10
ii  libcolord2 1.4.6-2.2
ii  libdrm22.4.115-1
ii  libegl11.6.0-1
ii  libeis11.0.901-2
ii  libfontconfig1 2.14.2-5
ii  libfribidi01.0.13-3
ii  libgbm123.1.7-1
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libgl1 1.6.0-1
ii  libglib2.0-0   2.78.0-1
ii  libgnome-desktop-4-2   44.0-2
ii  libgraphene-1.0-0  1.10.8-1
ii  libgudev-1.0-0 238-2
ii  libharfbuzz0b  8.0.1-1
ii  libice62:1.0.10-1
ii  libinput10 1.23.0-2
ii  libjson-glib-1.0-0 1.6.6-1
ii  liblcms2-2 2.14-2
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpangocairo-1.0-01.51.0+ds-2
ii  libpangoft2-1.0-0  1.51.0+ds-2
ii  libpipewire-0.3-0  0.3.79-2
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6+b1
ii  libsystemd0254.1-3
ii  libudev1   254.1-3
ii  libwacom9  2.7.0-1
ii  libwayland-server0 1.22.0-2.1
ii  libx11-6   2:1.8.6-1
ii  libx11-xcb12:1.8.6-1
ii  libxau61:1.0.9-1
ii  libxcb-randr0  1.15-1
ii  libxcb-res01.15-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxkbcommon-x11-0 1.5.0-1
ii  libxkbcommon0  1.5.0-1
ii  libxkbfile11:1.1.0-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxtst6   2:1.2.3-1.1
ii  mutter-common  45~rc-4
ii  mutter-common-bin  45~rc-4

libmutter-13-0 recommends no packages.

libmutter-13-0 suggests no packages.

Versions of packages libmutter-13-0 is related to:
ii  libegl-mesa0 [libegl-vendor]  23.1.7-1
ii  libgl1-mesa-dri   23.1.7-1
ii  libglx-mesa0 [libglx-vendor]  23.1.7-1

-- no debconf information

Bug#1051779: ITP: docopt-ng -- command-line arguments parser (python3)

[Hugh McMaster]

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

* Package name: docopt-ng
  Version : 0.9.0
  Upstream Contact: Nick Crews 
* URL : https://jazzband.co/projects/docopt-ng
* License : MIT
  Programming Lang: Python
  Description : command-line arguments parser (python3)

docopt-ng is a fork of the original docopt, which helps users
create beautiful command-line interfaces.
.
docopt-ng parses a command-line string and ensures that all options,
arguments and commands match the usage patterns and option descriptions
specified in a Python program's docstring.
.
Users can define valid usage patterns, option descriptions, arguments and
commands using patterns and syntax familiar to users command-line programs.
.
This is the Python 3-compatible version of the package.


The original docopt project has not been updated for many years.
docopt-ng is maintained by the jazzband project and comes with
maintenance, typehints, and complete test coverage.

Bug#1051781: python3-h5py: where is the egg files

[Picca Frédéric-Emmanuel]

Package: python3-h5py
Version: 3.7.0-8
Severity: important
X-Debbugs-Cc: pi...@debian.org

Dear Maintainer,

I am thre maintainer of silx

This package depende of python3-h5py and contain entry points.

The build  is ok, but once installed I get this error message when I try to 
start the application

$ silx view
Traceback (most recent call last):
  File "/usr/bin/silx", line 33, in 
sys.exit(load_entry_point('silx==1.1.2', 'console_scripts', 'silx')())
 
  File "/usr/lib/python3/dist-packages/silx/__main__.py", line 67, in main
status = launcher.execute(sys.argv)
 ^^
  File "/usr/lib/python3/dist-packages/silx/utils/launcher.py", line 294, in 
execute
return command.execute(command_argv)
   ^
  File "/usr/lib/python3/dist-packages/silx/utils/launcher.py", line 128, in 
execute
status = func(argv)
 ^^
  File "/usr/lib/python3/dist-packages/silx/app/view/main.py", line 214, in main
mainQt(options)
  File "/usr/lib/python3/dist-packages/silx/app/view/main.py", line 156, in 
mainQt
import silx.gui.utils.matplotlib  # noqa

  File "/usr/lib/python3/dist-packages/silx/gui/utils/matplotlib.py", line 39, 
in 
from pkg_resources import parse_version
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3327, 
in 
@_call_aside
 ^^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3302, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3340, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  ^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 631, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 968, in 
require
needed = self.resolve(parse_requirements(requirements))
 ^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 829, in 
resolve
dist = self._resolve_dist(
   ^^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 870, in 
_resolve_dist
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'h5py' distribution was not found and 
is required by hdf5plugin, silx


$ apt show python3-silx
Package: python3-silx
Version: 1.1.2+dfsg-2
Priority: optional
Section: python
Source: silx
Maintainer: Debian Science Maintainers 

Installed-Size: 13,1 MB
Depends: python3 (<< 3.12), python3 (>= 3.11~), python3-dateutil, 
python3-fabio, python3-h5py, python3-hdf5plugin, python3-mako, 
python3-matplotlib, python3-numpy (>= 1:1.22.0), python3-numpy-abi9, 
python3-opengl, python3-pil, python3-pkg-resources, python3-pyopencl, 
python3-pyqt5, python3-pyqt5.qtopengl, python3-pyqt5.qtsvg, python3-qtconsole, 
python3-scipy, python3:any, libc6 (>= 2.33), libgcc-s1 (>= 3.0), libgomp1 (>= 
4.9), libstdc++6 (>= 5.2)
Homepage: https://github.com/silx-kit/silx


So my question is what should be canged in h5py in order to make this work.

thanks

Frederic



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

Kernel: Linux 6.4.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-h5py depends on:
ii  python3-h5py-serial  3.7.0-8

python3-h5py recommends no packages.

Versions of packages python3-h5py suggests:
pn  python-h5py-doc  

-- no debconf information

Bug#1051782: ITP: kiwix-zim -- script to check for updates to your local ZIM library

[Kunal Mehta]

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

* Package name: kiwix-zim
  Version : 3.0
  Upstream Contact: jojo2357
* URL : https://github.com/jojo2357
* License : GPL-2
  Programming Lang: bash
  Description : script to check for updates to your local ZIM library

kiwix-zim accompanies kiwix/kiwix-tools by automatically downloading new
versions of ZIM files when they are available from the Kiwix server.

I've suggested a slightly more clear name like `kiwix-zim-updater` upstream
at .

Bug#1051783: uqm: flaky autopkgtest: savegames: Missing/invalid savegame, exit status 12

[Simon McVittie]

Source: uqm
Version: 0.8.0+dfsg-2
Severity: important
User: debian...@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 + src:libsdl2

The uqm autopkgtest 'savegames' intermittently fails on ci.debian.net,
which the testing migration infrastructure assumes is a regression in a
package that was upgraded, preventing packages like libsdl2 from migrating
to testing until the uqm autopkgtest is retried. For example, please see:

https://ci.debian.net/data/autopkgtest/testing/amd64/u/uqm/36300400/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/u/uqm/36300400/artifacts.tar.gz

https://ci.debian.net/data/autopkgtest/testing/ppc64el/u/uqm/37721045/log.gz
https://ci.debian.net/data/autopkgtest/testing/ppc64el/u/uqm/37721045/artifacts.tar.gz

https://ci.debian.net/data/autopkgtest/testing/ppc64el/u/uqm/36877335/log.gz
https://ci.debian.net/data/autopkgtest/testing/ppc64el/u/uqm/36877335/artifacts.tar.gz

If this test is known to be unreliable, please mark it with
"Restrictions: flaky" so that it doesn't stop other packages from
migrating.

Thanks,
smcv

Bug#1041312: [Pkg-fonts-devel] Bug#1041312: fonts-noto: Migrate to new upstream sources, and split the fonts according to upstream

[Jonas Smedegaard]

Hi Amr,

Quoting Amr Ibrahim (2023-07-17 12:19:49)
> Upstream has new sources of fonts-noto:
> 
> https://notofonts.github.io/
> 
> https://github.com/notofonts/notofonts.github.io
> 
> You can see from that website that upstream releases individual font files. So
> please try to re-package the font files in Debian accordingly.

Thanks for reporting this.  Honestly I thought it had been reported long
ago - I remember upstream also reaching out about it, but cannot easily
locate now where that conversation took place.

The URI you point at is confusing, however: Upstream use git both to
track _sources_ for the Noto fonts and as a means to _distribute_
precompiled fonts - and notofonts.github.io is (mainly, at least) about
the latter.

The change needed is not only to shift to a different source location,
but also to change to actually compile the fonts from source, not only
redistribute precompiled font files as has been done until now.

I have a draft source package lying around since a few years now, but
have not yet set aside the time to organize it for use with those
several hundred source packages that fonts-noto will become...


> Please also notice that noto-cjk now has its own source repository:
> https://github.com/notofonts/noto-cjk
> 
> So please package noto-cjk in its own source package if possible.

That is a different issue.  Please report issues individually, not
bundled, as it is much easier to merge if issues turns out to be too
similar than to split a bundled of issues being discussed together.

Regarding this issue specifically, don't bother, however: It is a
duplicate of an ancient issue already solved since quite some time - see
bug#805021 or the source package fonts-noto-cjk).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1051468: cannot install BIOS machine with mini.iso, error creating /target/sys/firmware/efi/efivars

[Marc Haber]

On Fri, Sep 08, 2023 at 09:37:53PM +0200, Philip Hands wrote:
> If you'd like to test the result of building that merge request into a
> mini.iso, you can give it a go with this:
> 
> https://salsa.debian.org/philh/grub-installer/-/jobs/4675763/artifacts/file/debian/output/debian-202306XX+salsaci+20230908+294-amd64-gtkmini.iso

I can confirm that this .iso installs fine on both BIOS and EFI VMs in
libvirt and kvm on amd64.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1051784: ITP: python-kr8s -- A batteries-included Python client library for Kubernetes that feels familiar for folks who already know how to use kubectl

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
guilherme@gmail.com

* Package name: python-kr8s
  Version : 0.8.17
  Upstream Contact: Jacob Tomlimson 
* URL : https://github.com/kr8s-org/kr8s
* License : BSD
  Programming Lang: Python
  Description : Library for Kubernetes similar to use kubectl

 This library provides a simple and extensible way to interact with Kubernetes
 clusters. The way of use is very similar to the 'kubectl' command and provides
 most of the features that this command has.
 .
 Features:
 .
 - API inspired by 'kubectl' to reduce the developer learning curve.
 - Sensible standards for reducing boilerplate.
 - No hubris-generated code, just human-readable code.
 - It also has an asynchronous API that can be used with 'asyncio' and 'trio'.
 - Client caching to reduce API object passing.
 - Batteries included providing useful utilities and methods inspired by
   'kubectl'.
 .
 Packaging will happen within the Debian Python Team.

Bug#1051677: emacs: Provides backport of 29.1

[Manphiz]

Sean Whitton  writes:

> Hello,
>
> On Tue 12 Sep 2023 at 01:31am -07, Manphiz wrote:
>
>> I'll try :P
>
> No, not now,

Haha, of course not now.  I meant I'll try to become someone they'll
refer to in the (not too extremely far) future.

> it's already in backports-NEW.

\o/

-- 
Manphiz


signature.asc
Description: PGP signature

Bug#1042993: dkms: DKMS fails to build amd64 kernel module in i386 userland

[Stefan Monnier]

Ping?

Any idea what change might have caused this?  It worked fine for kernel 6.1.0-7.


Stefan


Stefan Monnier [2023-08-03 18:37:23] wrote:

> Package: dkms
> Version: 3.0.11-3
> Severity: normal
>
> Dear Maintainer,
>
> My machine is running Debian testing i386 but with an amd64 kernel
> (to make better use of my 8GB of RAM).  I also have `dkms` and `tp-smapi-dkms`
> installed.
>
> Until recently this worked fine and built the `tp-smapi` kernel module for
> my `amd64` kernel.  But now installation of the 6.4.0-1-amd64 kernel causes
> problems when dkms tries to build the dkms package.
>
> More specifically I get the following error:
>
> dkms: running auto installation service for kernel 6.4.0-1-amd64.
> Sign command: /lib/modules/6.4.0-1-amd64/build/scripts/sign-file
> Signing key: /var/lib/dkms/mok.key
> Public certificate (MOK): /var/lib/dkms/mok.pub
>
> Building module:
> Cleaning build area...
> make -j2 KERNELRELEASE=6.4.0-1-amd64 -C /lib/modules/6.4.0-1-amd64/build
> M=/var/lib/dkms/tp_smapi/0.43/build HDAPS=1...(bad exit status: 2)
> Error! Bad return status for module build on kernel: 6.4.0-1-amd64 
> (x86_64)
> Consult /var/lib/dkms/tp_smapi/0.43/build/make.log for more information.
> dkms autoinstall on 6.4.0-1-amd64/x86_64 failed for tp_smapi(10)
> Error! One or more modules failed to install during autoinstall.
> Refer to previous errors for more information.
>
> and `/var/lib/dkms/tp_smapi/0.43/build/make.log` says:
>
> DKMS make.log for tp_smapi-0.43 for kernel 6.4.0-1-amd64 (x86_64)
> jeu 03 aoû 2023 18:35:09 EDT
> make : on entre dans le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 
> »
>   CC [M]  /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o
> /bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
> make[1]: *** [/usr/src/linux-
> headers-6.4.0-1-common/scripts/Makefile.build:257 :
> /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o] Erreur 127
> make[1]: *** Attente des tâches non terminées
>   CC [M]  /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o
> /bin/bash: ligne 1: x86_64-linux-gnu-gcc-13 : commande introuvable
> make[1]: *** [/usr/src/linux-
> headers-6.4.0-1-common/scripts/Makefile.build:257 :
> /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o] Erreur 127
> make: *** [/usr/src/linux-headers-6.4.0-1-common/Makefile:2051 :
> /var/lib/dkms/tp_smapi/0.43/build] Erreur 2
> make : on quitte le répertoire « /usr/src/linux-headers-6.4.0-1-amd64 »
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable-security'), (100, 'stable')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
>
> Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 dkms depends on:
> ii  build-essential  12.10
> ii  dpkg-dev 1.21.22
> ii  gcc [c-compiler] 4:13.1.0-4
> ii  gcc-10 [c-compiler]  10.4.0-7
> ii  gcc-11 [c-compiler]  11.4.0-2
> ii  gcc-12 [c-compiler]  12.3.0-6
> ii  gcc-13 [c-compiler]  13.1.0-9
> ii  gcc-9 [c-compiler]   9.3.0-22
> ii  kmod 30+20230519-1
> ii  lsb-release  12.0-2
> ii  make 4.3-4.1
> ii  patch2.7.6-7
>
> Versions of packages dkms recommends:
> ii  fakeroot 1.32.1-1
> iu  linux-headers-amd64 [linux-headers-generic]  6.4.4-1
> ii  sudo 1.9.14p2-1
>
> Versions of packages dkms suggests:
> ii  e2fsprogs  1.47.0-2
> ii  menu   2.1.50
>
> -- Configuration Files:
> /etc/modprobe.d/dkms.conf changed:
>
>
> -- no debconf information

Bug#1051503: closed by intrigeri (Re: [pkg-apparmor] Bug#1051503: AppArmor blocks Evolution launch)

[intrigeri]

Control: reopen -1
Control: reassign -1 apparmor-utils
Control: retitle -1 aa-logprof does not support mount rules
Control: tag -1 + upstream
Control: tag -1 - moreinfo

Hi,

dp217 (2023-09-11):
> That wasn't a request for help with a new profile.
> (which you cite as the reason for closing the bug report)
>
> aa-logprof "is an interactive tool used to review AppArmor generated messages 
> and update AppArmor security profiles.
> Running aa-logprof will scan the log file and if there are new AppArmor 
> events that are not covered by the existing profile set, the user will be 
> prompted with suggested modifications to augment the profile."
>
> But nowhere is it stated that some messages are quietly ignored, which leads 
> to unexpected results.The user then has a legitimate right to assume that it 
> is a bug.
>
> See wiki "A software bug is an error, flaw or fault in the design, 
> development, or operation of computer software that causes it to produce an 
> incorrect or unexpected result, or to behave in unintended ways."
>
> If a program doesn't do what it claims to do, then what is it if not a bug?

Please forgive me for drawing incorrect conclusions:the initial bug
report, its title, the fact it was reported against another package
than the one that ships aa-logprof, suggested to me something very
different than what you're saying now. Thanks for clarifying.

I'm reopening the bug report and fixing the metadata to make it
clearer what it is about.

Cheers,
-- 
intrigeri

Bug#1038403:

[Arturo Ingenito]

I support this request, as a new user who experience Debian I think lack of a 
user friendly interface to manage minor update to packages, but also to help 
transition from a major release of Debian, like do mint-updater or 
update-manager (from ubuntu) for not technical user.

I think as MVP that only manage update and major update could be enough.
Yes I know there is already UnattendedUpgrades package, but it lacks of user 
frienldy ui and only do minor update not a major of OS 
(https://wiki.debian.org/UnattendedUpgrades)
There is also a wiki page in Debian for AutomatedUpgrade, that summarizes the 
problem explaining how Ubuntu handle it 
(https://wiki.debian.org/AutomatedUpgrade)

Can we start from a fork of this tools and integrate in Debian?

Thanks

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Daniel Kiper]

Hey,

Adding Lidong...

Sebastian, Lidong is working on a fix for this issue.

Lidong, please keep Sebastain in the loop.

Daniel

On Sat, Sep 09, 2023 at 03:41:55PM +0200, Sebastian Andrzej Siewior wrote:
> Package: grub2
> Version: 2.12~rc1-9
> Severity: Serious
> control: forwarded -1 https://savannah.gnu.org/bugs/?64376
>
> I have a single XFS partition which contains the root filesystem and the
> boot partition. Since the recent upgrade to the 2.12 series I can't boot
> anymore because grub complains that it can't find normal.mod and remains in
> the rescue shell.
> The ls command kind of works. A ls in /boot/grub/i386-pc/ (where the
> normal.mod should be) shows a few files and then abort with the error
> message: 'error: invalid XFS directory entry'.
>
> I figured out that if I remove that directory and create a new one only
> with normal.mod then it was able to find it and complained about onother file.
> I then repeated the game until I had more files… The invocation of 
> grub-install
> copied all files and broke it again.
>
> I then looked at various places and stumbled uppon
> https://savannah.gnu.org/bugs/?64376 and this indeed matches what I see.
> I rebuilt the grub2 package with commit ef7850c757fb3 ("fs/xfs: Fix
> issues found while fuzzing the XFS filesystem") reverted, installed from
> a rescue system and voila it boots again.
>
> My xfs filesystem is a normal v5 as in:
> | # xfs_info /dev/sdb1
> | meta-data=/dev/sdb1  isize=512agcount=4, agsize=655360 blks
> |  =   sectsz=512   attr=2, projid32bit=1
> |  =   crc=1finobt=1, sparse=1, rmapbt=1
> |  =   reflink=1bigtime=0 inobtcount=0 
> nrext64=0
> | data =   bsize=4096   blocks=2621440, imaxpct=25
> |  =   sunit=0  swidth=0 blks
> | naming   =version 2  bsize=4096   ascii-ci=0, ftype=1
> | log  =internal log   bsize=4096   blocks=3693, version=2
> |  =   sectsz=512   sunit=0 blks, lazy-count=1
> | realtime =none   extsz=4096   blocks=0, rtextents=0
>
> Sebastian

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Helmut Grohne]

Hi Sebastian,

On Tue, Sep 12, 2023 at 09:24:45AM +0200, Sebastian Ramacher wrote:
> thanks for the detailed explanation.

thanks for following up in detail.

> On 2023-09-04 22:33:54 +0200, Helmut Grohne wrote:
> Skipping all the technical details, as I would not classify this as a
> transition where the release team needs to be involved. We can of course
> help with the rebuilds of the affected packages, but this change does
> not require us to check for outdated binary packages in testing or to
> make sure that everything migrates together.

It certainly is not a usual transition and also will not migrate
together. In that sense, I agree. Yet, I think this is something that
the release team wants to know is going on and consider how it interacts
with other transitions (e.g. time64). In essence, I think we agree. :)

> For the systemd change, the following steps should be enough in general:
> 
> 1. debhelper with support for service files in /usr migrates to testing.

done

> 2. Rebuild packages which currently have their service files.

A guinea pig package "location" has been uploaded with support from
Jochen. I don't have numbers on the number of packages that manually
install to /lib, but it is many. So this will likely require collective
effort rather than me sending patches.

> 3. debhelper installing service files to /usr per default migrates to testing.

I'm unsure when to do this as I see a moderate risk here. The dumat
report currently looks promising, but we also might run into a stream of
RC bugs.

> 4. Rebuild all packages with service files.

I note that the deadline for this practically is trixie and that this
doesn't really block any other part of the transition.

> For packages where these steps are not enough, bugs are filed along
> while preparing 1. and 3. This will include all packages which include
> service files in Arch: all packages as we cannot binNMU them.
> 
> Depending on the number of packages in step 4., this would ideally not
> be done during the time_t transition to avoid any surprises.

I'd hope half of the packages that could be binNMUed have a maintainer
upload in the relevant time frame. That also has the benefit of
spreading any bad effects over time rather than breaking the archive at
once.

Regarding the time64 transition, I expect bad interaction. Essentially,
time64 will restructure a large amount of packages (moving files from
one binary package to another retaining the name on 64bit architectures
and thus employing Replaces). As we combine this with mass-moving files
from / to /usr, we get exactly that DEP17-P1 scenario that the
moratorium was meant to prevent. This interaction is not avoidable by
clever timing, because it affects upgrades from bookworm to trixie. I've
talked to Steve already to make him aware. The current plan is to just
handle this on an individual level and applying the proposed mitigations
to issues detected by dumat.

> The other / to /usr file moves will need uploads anyway. So we cannot
> help here (except for monitoring the status of the bugs during the
> freeze). Regarding the move on d-i's side, please coordinate this change
> with Cyril. From your explanation it is however not clear to me whether
> we are blocked on finishing the /usr-merge change in the main archive by
> d-i or not.

Let me clarify that in filing this transition bug, my intention was not
to get assistance from the release team, but making you aware of what is
going on and giving you a reasonable chance to object.

The d-i part is rather critical from my point of view. Since d-i still
is unmerged, moving files from / to /usr in udebs is likely to break
d-i. This explicitly does not cover systemd units though when systemd
drops support for split-/usr (next release), d-i will likely be broken
anyway. So until d-i is fixed, the remaining moratorium should cover at
least all source packages that build udebs.

Some of this may be overly cautious, but I'd rather be cautious than
temporarily break the archive and that way cause lots of work to
unsuspecting developers. Developer time is a scarce resource and some of
what we're up to has a risk of consuming lots of that.

In any case, I take that at least Paul and Sebastian do not veto moving
forward with this. Cyril will probably take some time, but will unlikely
comment non-udeb aspects. No clue about Graham. I therefore intend to
slowly move forward with the actual conversion in a way that causes
least possible disruption and will keep you updated when I expect
non-trivial disruption.

Helmut

Bug#1051498: RFS: strace/6.5-0.1 [NMU] -- System call tracer

[Bastian Germann]

Control: tags -1 moreinfo

Even a LowNMU needs a bug report to act on.
Please file a request for the new version and then reference it in the 
changelog.
Please untag moreinfo when you are done.

Bug#1042450: elpa-org: #+LANGUAGE: de-de is not working in LaTeX export

[Max Nikulin]

H.-Dirk Schmitt writes:

> In difference to the 9.5 version the setting `#+LANGUAGE: de-de` is not 
working any more.
> The option of the babel LaTeX package is in this case now empty.
>
> An easy mitigation is to use instead `de-de` the `de` language code.


The following upstream commit restored "de-de" language definition:

893c5d085 2023-09-08 19:33:25 +0200 Juan Manuel Macias: ox-latex.el: 
Fixes and improvements in `org-latex-language-alist'.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=893c5d085

See the emacs-orgmode mailing list thread for details
https://list.orgmode.org/orgmode/877coywan5@posteo.net/
Juan Manuel Macías. Re: [patch] Fixes and improvements in 
org-latex-language-alist. Sun, 10 Sep 2023 11:06:06 +


Changes will be included into the next major Org mode release.

#+language: de
#+latex_header: \usepackage[AUTO]{babel}

results in

\usepackage[ngerman]{babel}
\hypersetup{
 % ...
 pdflang={German}}

It is a bit different from Org mode 9.5 however

\usepackage[germanb]{babel}
\hypersetup{
 % ...
 pdflang={Germanb}}

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Paul Tagliamonte]

Subject: gdm3 won't allow logins when a smarcard with a x.509 credential is 
plugged in
Package: gdm3
Version: 45~beta-1
Severity: important
thanks

Hey GNOME maintainers,

I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
when I reboot, and entering my username causes it to loop back to
username entry again (no password prompt). After some help from smcv, I
narrowed down the issue to the interactions between my smartcard
development tools installed locally and gdm3.

The journal shows the following output:

| Sep 12 10:18:47 nyx gdm-launch-environment][1851]: 
pam_unix(gdm-launch-environment:session): session opened for user 
Debian-gdm(uid=116) by (uid=0)
| Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:02 nyx gdm-smartcard][2749]: gkr-pam: no password is available 
for user
| Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:03 nyx gdm-smartcard][3505]: gkr-pam: no password is available 
for user
| Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:34 nyx gdm-smartcard][4045]: gkr-pam: no password is available 
for user
| Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM adding faulty module: pam_sss.so

(I do not have libpam-sss installed - after I got this error I installed
 it to see if I could unlock myself, but it didn't do much and I purged
 it again).

I have not configured my machine to use gdm-smartcard (nor do I want
to); but I do have a lot of smartcard stuff installed due to other hobby
work. I have NSS set up to talk with OpenSC, but that's only for TLS
keying material via GNOME, not system login.

When I unplugged my Yubikey which is both WebAuthN and a x.509
Smartcard, I was able to log in as usual.

My hunch is that I believe gdm-smartcard thinks it's supposed to kick
into gear and authenticate my smartcard, but it isn't configured to do
so (heck, it hasn't been told how to match my UPN/Email
SAN/Subject/Serial to UID, nor an x.509 CA to use for user
authentication). However, it kicking into gear has kicked me out of my
ability to login :)

I suspect the fix here is to explicitly toggle on gdm-smartcard when it's
properly configured, rather than implicitly running when the right deps
are installed and an x509 cert is found on an OpenSC token when it can't
properly authenticate it.

Fondly,
  paultag


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

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

Versions of packages gdm3 depends on:
ii  accountsservice23.13.9-4
ii  adduser3.137
ii  cool-retro-term [x-terminal-emulator]  1.2.0+ds2-1+b1
ii  dbus [default-dbus-system-bus] 1.14.10-1
ii  dbus-bin   1.14.10-1
ii  dbus-daemon1.14.10-1
ii  dconf-cli  0.40.0-4
ii  dconf-gsettings-backend0.40.0-4
ii  debconf [debconf-2.0]  1.5.82
ii  foot [x-terminal-emulator] 1.15.3-1
ii  gir1.2-gdm-1.0 45~beta-1
ii  gnome-session [x-session-manager]  44.0-4
ii  gnome-session-bin  44.0-4
ii  gnome-session-common   44.0-4
ii  gnome-settings-daemon  45~rc-1
ii  gnome-shell44.4-1
ii  gnome-terminal [x-terminal-emulator]   3.49.99-1
ii  gsettings-desktop-schemas  45~rc-1
ii  libaccountsservice023.13.9-4
ii  libaudit1  1:3.1.1-1
ii  libc6  2.37-8
ii  libcanberra-gtk3-0 0.30-10
ii  libcanberra0 

Bug#1051643: Info received (Bug#1051643: Acknowledgement (linux-image-6.1.0-11-686-pae: kernel BUG at mm/usercopy.c:101!))

[Jiann-Ming Su]

I spoke too soon... it's happening on 6.1.0-12-686 as well:

# apt-get update
Get:1 http://security.debian.org/debian-security bookworm-security/updates
InRelease [48.0 kB]
0% [Waiting for headers] [1 InRelease 0 B/48.0 kB 0%]
Message from syslogd@mini1 at Sep 12 11:07:33 ...
 kernel:[123507.826321] usercopy: Kernel memory exposure attempt detected
from kmap (offset 0, size 16384)!
Hit:2 http://ftp.us.debian.org/debian bookworm InRelease
Get:3 http://ftp.us.debian.org/debian bookworm-updates InRelease [52.1 kB]
0% [3 InRelease 0 B/52.1 kB 0%] [1 InRelease 0 B/48.0 kB 0%]
Message from syslogd@mini1 at Sep 12 11:07:33 ...
 kernel:[123508.220983] usercopy: Kernel memory exposure attempt detected
from kmap (offset 0, size 16384)!

[123452.464498] [ cut here ]
[123452.464530] kernel BUG at mm/usercopy.c:101!
[123452.464566] invalid opcode:  [#1] PREEMPT SMP
[123452.464606] CPU: 1 PID: 7495 Comm: http Not tainted 6.1.0-12-686 #1
 Debian 6.1.52-1
[123452.464653] Hardware name: Apple Computer, Inc.
Macmini1,1/Mac-F4208EC8, BIOS MM11.88Z.0055.B08.0610121326 10/12/06
[123452.464729] EIP: usercopy_abort+0x65/0x67
[123452.464772] Code: 44 cb bb d8 d9 b1 cc 89 4d f0 b9 12 55 b0 cc 0f 45 cb
ff 75 0c ff 75 08 57 52 56 50 ff 75 f0 51 68 78 d9 b1 cc e8 8a 8e ff ff
<0f> 0b 56 31 d2 b8 22 da b1 cc ff 75 ec 8b 4d f0 e8 86 ff ff ff 56
[123452.464886] EAX: 0052 EBX: ccb1d9d8 ECX: 0001 EDX: 0001
[123452.464930] ESI: ccb3449c EDI: ccb3449c EBP: c349fce0 ESP: c349fcac
[123452.464974] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS:
00010246
[123452.465024] CR0: 80050033 CR2: 01be6000 CR3: 0e3d2000 CR4: 06d0
[123452.465068] Call Trace:
[123452.465093]  ? __die_body.cold+0x14/0x1a
[123452.465126]  ? __die+0x21/0x26
[123452.465152]  ? die+0x28/0x50
[123452.465179]  ? do_trap+0xbb/0xe0
[123452.465206]  ? do_error_trap+0x4c/0x60
[123452.465235]  ? usercopy_abort+0x65/0x67
[123452.465271]  ? exc_overflow+0x40/0x40
[123452.465303]  ? exc_invalid_op+0x44/0x60
[123452.465338]  ? usercopy_abort+0x65/0x67
[123452.465372]  ? handle_exception+0x133/0x133
[123452.465409]  ? up_read+0x7b/0x80
[123452.465436]  ? exc_overflow+0x40/0x40
[123452.465467]  ? usercopy_abort+0x65/0x67
[123452.465501]  ? exc_overflow+0x40/0x40
[123452.465532]  ? usercopy_abort+0x65/0x67
[123452.465565]  __check_object_size.cold+0xae/0xae
[123452.465605]  ? kmap_high+0x6f/0x1f0
[123452.465639]  simple_copy_to_iter+0x1c/0x40
[123452.465670]  __skb_datagram_iter+0x163/0x320
[123452.465703]  skb_copy_datagram_iter+0x2d/0x80
[123452.465738]  ? skb_free_datagram+0x20/0x20
[123452.465768]  tcp_recvmsg_locked+0x30e/0x890
[123452.465806]  tcp_recvmsg+0x6f/0x1e0
[123452.465839]  ? tcp_recv_timestamp+0x240/0x240
[123452.465876]  inet_recvmsg+0x54/0x130
[123452.465906]  ? security_socket_recvmsg+0x41/0x60
[123452.465942]  sock_recvmsg+0x73/0x90
[123452.465978]  ? ipip_gso_segment+0x30/0x30
[123452.466015]  sock_read_iter+0x84/0xe0
[123452.466050]  vfs_read+0x288/0x2c0
[123452.466083]  ksys_read+0xab/0xe0
[123452.466110]  __ia32_sys_read+0x15/0x20
[123452.466138]  __do_fast_syscall_32+0x68/0xb0
[123452.466171]  ? syscall_exit_to_user_mode+0x29/0x40
[123452.466205]  ? __do_fast_syscall_32+0x72/0xb0
[123452.466237]  ? exit_to_user_mode_prepare+0x14d/0x1a0
[123452.466273]  ? sysvec_reboot+0x30/0x30
[123452.466302]  do_fast_syscall_32+0x29/0x60
[123452.466334]  do_SYSENTER_32+0x15/0x20
[123452.466369]  entry_SYSENTER_32+0x98/0xf1
[123452.466399] EIP: 0xb7f3d559
[123452.466425] Code: 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01
10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80
<5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
[123452.466530] EAX: ffda EBX: 0003 ECX: 01be5df0 EDX: 0001
[123452.466573] ESI: b778eff4 EDI:  EBP: 01be4bb0 ESP: bf8d9b50
[123452.466617] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS:
0246
[123452.466670] Modules linked in: tls tun ath5k i915 ath snd_hda_codec_idt
mac80211 snd_hda_codec_generic drm_buddy ledtrig_audio drm_display_helper
libarc4 snd_hda_intel cec snd_intel_dspcfg kvm_intel snd_intel_sdw_acpi
rc_core cfg80211 snd_hda_codec ttm kvm iTCO_wdt intel_pmc_bxt
iTCO_vendor_support snd_hda_core watchdog applesmc snd_hwdep drm_kms_helper
at24 snd_pcm xt_tcpudp irqbypass i2c_algo_bit snd_timer pcspkr xt_conntrack
rng_core snd fb_sys_fops rfkill nf_conntrack syscopyarea soundcore
sysfillrect sysimgblt nf_defrag_ipv6 tpm_infineon nf_defrag_ipv4 button
acpi_cpufreq nft_compat apple_mfi_fastcharge evdev nf_tables sg nfnetlink
binfmt_misc drm loop fuse efi_pstore dm_mod configfs ip_tables x_tables
autofs4 xfs libcrc32c crc32c_generic hid_apple hid_appleir hid_generic
usbhid hid sd_mod t10_pi crc64_rocksoft crc64 sr_mod crc_t10dif cdrom
crct10dif_generic crct10dif_common ata_generic ata_piix ahci libahci libata
firewire_ohci scsi_mod firewire_core ehci_pci i2c_i801 i2c_smbus
[123452.466844]  scsi_common lpc_ich uhci_hcd ehci_hcd crc_itu_

Bug#1051786: CVE-2023-4863: Heap buffer overflow in WebP

[Jeffrey Cliff]

Subject: CVE-2023-4863: Heap buffer overflow in WebP
Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 



On Tue, Sep 12, 2023 at 9:07 AM Jeffrey Cliff  wrote:
>
> Dear Maintainer,
>
> 116.0.5845.187 fixes a critical remote vulnerability in chrome
>
> [$NA][1479274] Critical CVE-2023-4863: Heap buffer overflow in WebP.
> Reported by Apple Security Engineering and Architecture (SEAR) and The Citizen
> Lab at The University of Torontoʼs Munk School on 2023-09-06
>
> https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html
>
> Might want to look into this at least
>
> Jeff Cliff
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500,
> 'oldstable-debug')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-gnulibre (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_CA:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
>
>
> Versions of packages chromium depends on:
> pn  chromium-common
> ii  libasound2 1.2.9-2
> ii  libatk-bridge2.0-0 2.49.91-2
> ii  libatk1.0-02.49.91-2
> ii  libatomic1 13.2.0-3
> ii  libatspi2.0-0  2.49.91-2
> ii  libbrotli1 1.0.9-2+b6
> ii  libc6  2.37-7
> ii  libcairo2  1.17.8-3
> ii  libcups2   2.4.2-5
> ii  libdbus-1-31.14.10-1devuan1
> ii  libdouble-conversion3  3.3.0-1
> ii  libdrm22.4.115-1
> ii  libevent-2.1-7 2.1.12-stable-8
> ii  libexpat1  2.5.0-2
> ii  libflac12  1.4.3+ds-2
> ii  libfontconfig1 2.14.2-5
> ii  libfreetype6   2.13.2+dfsg-1
> ii  libgbm123.1.7-1
> ii  libgcc-s1  13.2.0-3
> ii  libglib2.0-0   2.77.3-1
> ii  libgtk-3-0 3.24.38-4
> ii  libjpeg62-turbo1:2.1.5-2
> ii  libjsoncpp25   1.9.5-6
> ii  liblcms2-2 2.14-2
> ii  libminizip11:1.2.13.dfsg-3
> ii  libnspr4   2:4.35-1.1
> ii  libnss32:3.92-1
> pn  libopenh264-7  
> ii  libopenjp2-7   2.5.0-2
> ii  libopus0   1.4-1
> ii  libpango-1.0-0 1.51.0+ds-2
> ii  libpng16-161.6.40-1
> ii  libpulse0  16.1+dfsg1-2+b1
> ii  libsnappy1v5   1.1.10-1
> ii  libstdc++6 13.2.0-3
> ii  libwebp7   1.2.4-0.2
> ii  libwebpdemux2  1.2.4-0.2
> ii  libwebpmux31.2.4-0.2
> ii  libwoff1   1.0.2-2
> ii  libx11-6   2:1.8.6-1
> ii  libxcb11.15-1
> ii  libxcomposite1 1:0.4.5-1
> ii  libxdamage11:1.1.6-1
> ii  libxext6   2:1.3.4-1+b1
> ii  libxfixes3 1:6.0.0-2
> ii  libxkbcommon0  1.5.0-1
> ii  libxml22.9.14+dfsg-1.3
> ii  libxnvctrl0525.125.06-1
> ii  libxrandr2 2:1.5.2-2+b1
> ii  libxslt1.1 1.1.35-1
> ii  zlib1g 1:1.2.13.dfsg-3
>
> Versions of packages chromium recommends:
> pn  chromium-sandbox  
>
> Versions of packages chromium suggests:
> pn  chromium-driver  
> pn  chromium-l10n
> pn  chromium-shell   



-- 

End the campaign to Cancel Richard Stallman - go to stallmansupport.org !

Bug#1051787: Subject: CVE-2023-4863: Heap buffer overflow in WebP

[Jeffrey Cliff]

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Dear Maintainer,

116.0.5845.187 fixes a critical remote vulnerability in chrome

[$NA][1479274] Critical CVE-2023-4863: Heap buffer overflow in WebP.
Reported by Apple Security Engineering and Architecture (SEAR) and The Citizen
Lab at The University of Torontoʼs Munk School on 2023-09-06

https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html

Might want to look into this at least

(attempt 3, my reportbug broke sorry)

Jeff Cliff

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

Kernel: Linux 6.5.0-gnulibre (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled


Versions of packages chromium depends on:
pn  chromium-common
ii  libasound2 1.2.9-2
ii  libatk-bridge2.0-0 2.49.91-2
ii  libatk1.0-02.49.91-2
ii  libatomic1 13.2.0-3
ii  libatspi2.0-0  2.49.91-2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.37-7
ii  libcairo2  1.17.8-3
ii  libcups2   2.4.2-5
ii  libdbus-1-31.14.10-1devuan1
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.115-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-2
ii  libflac12  1.4.3+ds-2
ii  libfontconfig1 2.14.2-5
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.1.7-1
ii  libgcc-s1  13.2.0-3
ii  libglib2.0-0   2.77.3-1
ii  libgtk-3-0 3.24.38-4
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip11:1.2.13.dfsg-3
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.92-1
pn  libopenh264-7  
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 13.2.0-3
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.6-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Bug#1051748: RFP: pdf2htmlex -- convert PDF to HTML without losing text or format

[Lev Lamberov]

Hi,

Вт 12 сен 2023 @ 13:01 Johannes Schauer Marin Rodrigues :

> Hi,
>
> On Tue, 12 Sep 2023 10:57:57 +0500 Lev Lamberov  wrote:
>> Package: wnpp
>> Severity: wishlist
>> 
>> * Package name: pdf2htmlex
>>   Version : 0.18.8rc1
>>   Upstream Author : Lu Wang  and other contributors
>> * URL or Web page : https://github.com/pdf2htmlEX/pdf2htmlEX
>> * License : GPL-3+
>>   Description : convert PDF to HTML without losing text or format
>> 
>
> you are aware that pdf2htmlex used to be part of Debian? It is still in
> old-old-stable. It was removed with this bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921471
>
> Are you sure it is wise to include that package into Debian again? The issue
> tracker is very low on activity:
>
> https://github.com/pdf2htmlEX/pdf2htmlEX/issues
>
> Thanks!

Well, the upstream is indeed not very active (the latest commit is on 13
Mar this year). I admit that it looks more like an abandonware, but
probably someone™ could step forward and care for it (I personally lack
the relevant competence). Recently I had to convert LaTeX source (XeTeX,
in fact) to HTML and in fact the best result I got was with
LaTeX->PDF->HTML, where the last convertion was done with this
pdf2htmlex. It produced HTML document which looks exactly like PDF
produced by LaTeX. So, I thought that this tool can be of use to someone
else.

Cheers!
Lev

Bug#1051774: Asyncio fix available

[Adam Cecile]

Hello,


So it turns out there was two issues here:

* New "lextudio" upstream patch broke asyncio support by converting 
regular function returning future into awaitable function returning 
Future (double await needed).


I fixed the issue and send a PR upstream: 
https://github.com/lextudio/pysnmp/pull/24


Bug was already reported but not taken in account: 
https://github.com/lextudio/pysnmp/issues/19


* Upstream "lextudio" patches to fix asyncio backend (including my own 
PR from today) had to be merged into debian package.


I created an upstream based branch here to see what patches have been 
cherry-picked: 
https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commits/4.4.12+cherry-pick-asyncio-lextudio-fixes/


And created a Debian 4.4.12-3 release so I can build and test the 
package: 
https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commit/a5f17d27c7813dbdb64cdf674d1855a77c3eb0f0



I'll now try to reach Debian Python team to see if we should proceed 
further.


Regards, Adam.

Bug#1041272: transmission-daemon: Crashes every few hours, SEGV on systemctl error message

[Pavel Kreuzt]

Package: transmission-daemon
Followup-For: Bug #1041272
X-Debbugs-Cc: pkre...@gmail.com

Don't know if this is related to the new patch or some other issue on my side, 
since this machine had some stability problemas a while ago. Please note I'm on 
ARM64, in case that could affect the results. Before trying the proposed 
update, I was running a self-packaged .deb with proposed patch on former issue 
and didn't have this problem. This is the output of systemctl status:

Process: 22391 ExecStart=/usr/bin/transmission-daemon -f --log-error 
(code=killed, signal=SEGV)
   Main PID: 22391 (code=killed, signal=SEGV)
 Status: "Uploading 326.72 KBps, Downloading 158.81 KBps."
CPU: 3h 13min 54.061s


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

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

Versions of packages transmission-daemon depends on:
ii  adduser3.134
ii  libc6  2.36-9+deb12u1
ii  libcurl4   7.88.1-10+deb12u1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libminiupnpc17 2.2.4-1+b1
ii  libnatpmp1 20150609-7.1+b2
ii  libssl33.0.9-1
ii  libsystemd0252.12-1~deb12u1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4
ii  transmission-common3.00-2.1+deb12u1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages transmission-daemon recommends:
ii  transmission-cli  3.00-2.1+deb12u1

transmission-daemon suggests no packages.

-- no debconf information

Bug#1051788: The apparmor profile blocks pages rendering with webkitgtk 2.41

[Sebastien Bacher]

Package: surf
Version: 2.1+git20221016-4
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

The surf autopkgtest had been failing on Ubuntu following the webkitgtk 
2.41 update which was discussed on 
https://bugs.webkit.org/show_bug.cgi?id=261268


Turned out the problem was specific to Ubuntu because it is due to the 
apparmor profile which Debian isn't enforcing by default. Basically the 
process isn't allowed to read /usr/share/glvnd/egl_vendor.d and failing 
to use the egl library as a consequence.

The attached patch fixes the issue

Note that there are some extra apparmor denials in the journal which 
might be worth fixing (but not essential to fix the rendering issue)



audit: type=1400 audit(1694175887.447:1795): apparmor="DENIED" 
operation="open" class="file" profile="/usr/bin/surf" 
name="/etc/machine-id" pid=94729 comm="surf" requested_mask="r" 
denied_mask="r" fsuid=1000 ouid=0


audit: type=1400 audit(1694175892.387:1811): apparmor="DENIED" 
operation="open" class="file" profile="/usr/bin/surf" 
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-64263ce8-7b7e-4897-a75c-d2ae2c3de03e.scope/memory.current" 
pid=94729 comm="PressureMonitor" requested_mask="r" denied_mask="r" 
fsuid=1000 ouid=1000


audit: type=1400 audit(1694175887.383:1789): apparmor="DENIED" 
operation="open" class="file" profile="/usr/bin/surf" 
name="/usr/share/glvnd/egl_vendor.d/" pid=94729 comm="surf" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0


audit: type=1400 audit(1694175887.383:1790): apparmor="DENIED" 
operation="open" class="file" profile="/usr/bin/surf" 
name="/sys/devices/virtual/dmi/id/chassis_type" pid=94729 comm="surf" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0


audit: type=1400 audit(1694175887.383:1791): apparmor="DENIED" 
operation="open" class="file" profile="/usr/bin/surf" 
name="/sys/firmware/acpi/pm_profile" pid=94729 comm="surf" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0


Cheers,
Sébastien Bacher

diff -Nru surf-2.1+git20221016/debian/changelog surf-2.1+git20221016/debian/changelog
--- surf-2.1+git20221016/debian/changelog	2022-12-23 12:35:07.0 +0100
+++ surf-2.1+git20221016/debian/changelog	2023-09-09 22:58:31.0 +0200
@@ -1,3 +1,11 @@
+surf (2.1+git20221016-5) UNRELEASED; urgency=medium
+
+  * debian/usr.bin.surf:
+- include the vulkan abstraction, without it the browser renders white
+  pages with the new webkitgtk (lp: #2034907)
+
+ -- Sebastien Bacher   Sat, 09 Sep 2023 22:58:31 +0200
+
 surf (2.1+git20221016-4) unstable; urgency=medium
 
   * Bump version of test dependency apparmor-profiles-extra.
diff -Nru surf-2.1+git20221016/debian/usr.bin.surf surf-2.1+git20221016/debian/usr.bin.surf
--- surf-2.1+git20221016/debian/usr.bin.surf	2022-08-29 19:58:49.0 +0200
+++ surf-2.1+git20221016/debian/usr.bin.surf	2023-09-09 15:40:08.0 +0200
@@ -14,6 +14,7 @@
   #include 
   #include 
   #include 
+  #include 
 
   owner @{HOME}/.surf/ w,
   owner @{HOME}/.surf/** rwkl,

Bug#1051787: Subject: CVE-2023-4863: Heap buffer overflow in WebP

[Andres Salomon]

clone 1051787 -1
reassign -1 libwebp
thanks

This bug's actually in libwebp. Unfortunately we're still embedding it 
in chromium, so we likely need to fix both chromium *and* libwebp in 
debian. There hasn't been a libwebp release yet, but the two relevant 
git commits are


and what appears to be a followup fix to that,



On Tue, Sep 12 2023 at 09:12:40 AM -06:00:00, Jeffrey Cliff 
 wrote:

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team >


Dear Maintainer,

116.0.5845.187 fixes a critical remote vulnerability in chrome

[$NA][1479274] Critical CVE-2023-4863: Heap buffer overflow in WebP.
Reported by Apple Security Engineering and Architecture (SEAR) and 
The Citizen

Lab at The University of Torontoʼs Munk School on 2023-09-06



Might want to look into this at least

(attempt 3, my reportbug broke sorry)

Jeff Cliff

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

Kernel: Linux 6.5.0-gnulibre (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled


Versions of packages chromium depends on:
pn  chromium-common
ii  libasound2 1.2.9-2
ii  libatk-bridge2.0-0 2.49.91-2
ii  libatk1.0-02.49.91-2
ii  libatomic1 13.2.0-3
ii  libatspi2.0-0  2.49.91-2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.37-7
ii  libcairo2  1.17.8-3
ii  libcups2   2.4.2-5
ii  libdbus-1-31.14.10-1devuan1
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.115-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-2
ii  libflac12  1.4.3+ds-2
ii  libfontconfig1 2.14.2-5
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.1.7-1
ii  libgcc-s1  13.2.0-3
ii  libglib2.0-0   2.77.3-1
ii  libgtk-3-0 3.24.38-4
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip11:1.2.13.dfsg-3
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.92-1
pn  libopenh264-7  
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 13.2.0-3
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.6-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Sebastian Andrzej Siewior]

On 2023-09-12 15:43:34 [+0200], Daniel Kiper wrote:
> Hey,
Hi,

> Adding Lidong...
> 
> Sebastian, Lidong is working on a fix for this issue.

ach great.

> Lidong, please keep Sebastain in the loop.
> 
> Daniel
Sebastian

Bug#1051789: RM: sphinxcontrib-youtube -- RoQA; abandoned packaging, MIA

[William Desportes]

Package: ftp.debian.org
Severity: normal
Usertags: rm-request
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

Due to #943690 and the current packaging status, please proceed with deleting 
the package sphinxcontrib-youtube.
The package is not maintained, no new version since 2014. Only one version was 
uploaded.

--
William Desportes

Bug#1051514: grub-common: Please remove grub-common.service from boot hot path

[Julian Andres Klode]

On Sun, Sep 10, 2023 at 03:45:52PM +0200, Paul Menzel wrote:
> Dear Andres,
> 
> 
> Thank you for your reply.
> 
> Am 10.09.23 um 13:54 schrieb Julian Andres Klode:
> > On Sat, Sep 09, 2023 at 12:21:29AM +0200, Paul Menzel wrote:
> > > Package: grub-common
> > > Version: 2.12~rc1-9
> > > Severity: normal
> 
> > > The unit `grub-common.service` is installed to the multi-user.target and
> > > therefore run during boot-up, slowing down the boot, especially as shell
> > > commands are used.
> > > 
> > > ```
> > > $ systemctl cat grub-common.service
> > > # /lib/systemd/system/grub-common.service
> > > [Unit]
> > > Description=Record successful boot for GRUB
> > > After=suspend.target hibernate.target hybrid-sleep.target
> > > suspend-then-hibernate.target
> > > ConditionPathExists=/boot/grub/grub.cfg
> > > 
> > > [Service]
> > > Type=oneshot
> > > Restart=no
> > > ExecStartPre=/bin/sh -c '[ -s /boot/grub/grubenv ] || rm -f
> > > /boot/grub/grubenv; mkdir -p /boot/grub'
> > > ExecStart=grub-editenv /boot/grub/grubenv unset recordfail
> > > ExecStartPost=/bin/sh -c 'if grub-editenv /boot/grub/grubenv list | grep 
> > > -q
> > > initrdless_boot_fallback_triggered=1; then echo "grub: GRUB_FORCE_PARTUUID
> > > set, initrdless boot paniced, fallback triggered."; fi'
> > > StandardOutput=kmsg
> > > 
> > > [Install]
> > > WantedBy=multi-user.target suspend.target hibernate.target
> > > hybrid-sleep.target suspend-then-hibernate.target
> > > ```
> > 
> > As you can see, there are no Before relations in the service,
> > so grub-common is not in the hot path, nothing depends on it
> > having finished startup.
> > 
> > I'm sure this was well intended and not a troll attempt, but
> > systemd doesn't start services in a sequence, so services can
> > run in parallel and there is in general very little ordering
> > requirements.
> 
> That is exactly, what I was saying. Due to the missing ordering, systemd
> starts this service as early as possible causing pressure on the possibly
> scarce system resources at the beginning. So care has to be taken
> introducing these things. Looking into decreasing the start time of an
> Ubuntu system once, grub-common showed up there, so it will make the startup
> time of quite a lot of Debian systems longer now too. Please keep in mind,
> that Debian is also run on older systems.

I think bug reports like this are ill-advised, it is not our decision
to make how to start services and abusing timers for this is wrong.

If you want units that do not contribute to the target to run only
when idle, then my suggestion would be to add such a feature to
systemd itself rather than go around trying to hack each such instance
with timers.

That said, I strongly disagree with the assessment. Boot is not
interactive so it is less of a priority to have it fast vs having
a performant interactive session.

On the extreme, if you boot into your desktop and then it eats up
all your cores and locks up the UI on your resource constrained
device that's a worse experience than waiting longer at boot and
then having things work correctly.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1051790: ITP: xdg-desktop-portal-lxqt -- xdg-desktop-portal implemenation for libfm-qt xdg-desktop-portal that is using Qt/KF5/libfm-qt

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+l...@tracker.debian.org

* Package name: xdg-desktop-portal-lxqt
  Version : 0.4.0
  Upstream Contact: tsujan
* URL : https://github.com/lxqt/xdg-desktop-portal-lxqt
* License : LGPL-2.1+
  Programming Lang: C
  Description : xdg-desktop-portal implemenation for libfm-qt

 The package will be maintained under LXQt team.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
https://czchen.org/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1051791: Patch: add InRelease files with signature

[Cyprien Nicolas]

Package: debarchiver
Version: 0.11.7
Severity: important
Tags: patch

Dear Maintainer,

We use debarchiver for a company repository, and since we started
upgrading our servers to Bookworm, our hosts fail to verify our
repository:

W: Pas d'entrée de hachage dans le fichier Release 
/var/lib/apt/lists/partial/debian.octopuce.fr_octopuce_dists_bookworm_Release
E: Le dépôt http://debian.octopuce.fr/octopuce bookworm Release ne fournit que 
de faibles informations de sécurité.

Sorry for the French, I no longer have the full LC_ALL=C output, the
first one said "No Hash entry in Release file", and the second one
someting about "weak security".

With respect to #825123, we checked our signing key (rsa2048) and the
default signature algorithm (sha256) but the issue is unreleated.

We found out that the InRelease file is not generated by
debarchiver. We patched debarchiver to do so, along with the
Release.gpg file, and now the repository is verified.

I'm not sure how to add patches with reportbug yet, so I put it inline
here:

-*- Patch Begins here -*-
--- debarchiver.orig2021-09-07 15:10:31.0 +0200
+++ debarchiver 2023-09-12 17:23:12.171618835 +0200
@@ -1302,17 +1302,26 @@
  3);
 if ($gpgkey) {
 unlink("$path/Release.gpg");
+unlink("$path/InRelease");
if ($gpgpassfile) {
cmdaction("cat $gpgpassfile | gpg --batch --no-tty -a -b -s -u 
$gpgkey " .
  "--pinentry-mode loopback --passphrase-fd 0 -o 
$path/Release.gpg $path/Release",
  "Sign Release file for $path with key '$gpgkey'",
  3);
+   cmdaction("cat $gpgpassfile | gpg --batch --no-tty --clearsign -u 
$gpgkey " .
+ "--pinentry-mode loopback --passphrase-fd 0 -o 
$path/InRelease $path/Release",
+ "Sign InRelease file for $path with key '$gpgkey'",
+ 3);
}
else {
cmdaction("gpg -a -b -s -u $gpgkey " .
  "-o $path/Release.gpg $path/Release",
  "Sign Release file for $path with key '$gpgkey'",
  3);
+   cmdaction("gpg --clearsign -u $gpgkey " .
+ "-o $path/InRelease $path/Release",
+ "Sign InRelease file for $path with key '$gpgkey'",
+ 3);
}
 }
 unlink("$configpath");
-*- Patch Ends here -*-

Kind regards,
Cyprien

-- 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/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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/bash
Init: systemd (via /run/systemd/system)

Versions of packages debarchiver depends on:
ii  adduser3.134
ii  apt-utils  2.6.1
ii  dpkg-dev   1.21.22
ii  opalmod0.2.2.1

Versions of packages debarchiver recommends:
ii  mailutils [mailx]   1:3.15-4
ii  postfix [mail-transport-agent]  3.7.6-0+deb12u2

Versions of packages debarchiver suggests:
pn  devscripts  
ii  gnupg   2.2.40-1.1

-- Configuration Files:
/etc/cron.d/debarchiver changed:
MAILTO=""
*/5 * * * * debarchiver /usr/local/bin/debarchiver-patch-inrelease 
--scanall -so | logger -t debarchiver -p daemon.info

/etc/debarchiver.conf changed:
$destdir = "/var/www/debian/octopuce/dists";
$inputdir = "/var/lib/debarchiver/incoming";
$copycmd = "mv -f";
$rmcmd = "true";
$vrfycmd = "dscverify";
$cinstall = "installed";
$verifysignatures = 1;
$ignoredestcheck = 0;
$verifysignaturesdistinput = 0;
$bzip = 1;
 %distinputdirs =
(
oldoldoldstable => 'oldoldoldstable',
oldoldstable => 'oldoldstable',
oldstable => 'oldstable',
stable => 'stable',
testing => 'testing',
unstable => 'unstable',
experimental => 'experimental'
);
@distributions = ('oldoldoldstable', 'oldoldstable','oldstable', 'stable', 
'testing', 'unstable', 'experimental');
$majordefault = "main";
 %distmapping =
(
oldoldoldstable => 'stretch',
oldoldstable => 'buster',
oldstable => 'bullseye',
stable => 'bookworm',
testing => 'trixie',
unstable => 'sid',
experimental => 'experimental',
);
@architectures = ('i386', 'amd64', 'all');
@sections = ('main', 'contrib', 'non-free');
  @mailtos = ('packa...@octopuce.fr');
$mailfrom = "debarchi...@debian.octopuce.fr";
%release = ('origin' => "debian.octopuce.fr",
'label' => "Octopuce official repository",
'description' => "Octopuce-specific packages official 
repository");
$cachedir = '/var/cache/debarchiver';
$gpgkey = "AB4B62BCAB86B190C0543F84F83BC4CC8181979A";
$gpgpassfile = "";
1;


-- no debconf information
--- deba

Bug#1051706: debian-archive-keyring: maintainer scripts remove Stable key

[Jonathan Wiltshire]

Hi,

On Mon, Sep 11, 2023 at 04:32:09PM +0300, Martin-Éric Racine wrote:
> Maintainer scripts in 2023.4 remove the Bookworm key. Bookworm is the current 
> Stable release.
> 
> Unpacking debian-archive-keyring (2023.4) over (2023.3) ...
> Setting up debian-archive-keyring (2023.4) ...
> Removing obsolete conffile 
> /etc/apt/trusted.gpg.d/debian-archive-bookworm-stable.gpg ...
> Removing obsolete conffile 
> /etc/apt/trusted.gpg.d/debian-archive-bookworm-security-automatic.gpg ...
> Removing obsolete conffile 
> /etc/apt/trusted.gpg.d/debian-archive-bookworm-automatic.gpg ...
> 
> Perhaps this was meant to remove the keys of older releases instead?

No, this sounds like the clean-up behaviour I intended. Do you not have the
equivalent .asc key fragments still on disk?

-- 
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#1051792: sed: Support for build profile

[Gioele Barabucci]

Package: src:sed
Version: 4.9-1
Tags: patch

Dear sed maintainers,

even when the  build profile is used, `texinfo` remains a 
required build dependency.


A MR that fixes this issue is available at:

https://salsa.debian.org/debian/sed/-/merge_requests/2

Regards,

--
Gioele Barabucci

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Jonas Smedegaard  writes:

> If you mean to say that ambiguous MIT declarations exist in
> debian/copyright files written using the machine-readable format, then
> please point to an example, as I cannot imagine how that would look.

I can see it: people use License: Expat but then include some license that
is essentially, but not precisely, the same as Expat.  If we then tell
people that they can omit the text of the license and we'll fill it in
automatically, they'll remove the actual text and we'll fill it in with
the wrong thing.

This is just a bug in handling the debian/copyright file, though.  If we
take this approach, we'll need to be very explicit that you can only use
whatever triggers the automatic inclusion of the license text if your
license text is word-for-word identical.  Otherwise, you'll need to cut
and paste it into the file as always.

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

Bug#1051793: simple-cdd: GNUPGHOME is not always passed correctly to gpg

[Jonathan Hettwer (bauen1)]

Package: simple-cdd
Version: 0.6.9
Severity: normal
X-Debbugs-Cc: j24...@gmail.com, j24...@gmail.com

Dear simple-cdd Authors and/or Maintainers,

When `GNUPGHOME` is not set, simple-cdd defaults it to `$PWD/tmp/gpg-keyring`, 
this is
done in 
.

However if `GNUPGHOME` is set internally like this, then it is not always 
passed along to all calls to `gpg` in 
.

For example running `simple-cdd` in a rootless podman container where only 
parts of my home directory are mounted in, leaving ~ as
a read-only empty directory.

Because `GNUPGHOME` is not passed a long in at least 
,
 this results in the following error:

> gpg: Fatal: can't create directory '/home/jh/.gnupg': Read-only file system
> Traceback (most recent call last):
>   File "/usr/bin/simple-cdd", line 674, in 
> scdd.read_configuration()
>   File "/usr/bin/simple-cdd", line 179, in read_configuration
> verify_release_keys.extend(gnupg.list_valid_keys(keyring_file))
>   File "/usr/lib/python3/dist-packages/simple_cdd/gnupg.py", line 82, in 
> list_valid_keys
> keys_raw = subprocess.check_output(["gpg",
>^^^
>   File "/usr/lib/python3.11/subprocess.py", line 466, in check_output
> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
>^
>   File "/usr/lib/python3.11/subprocess.py", line 571, in run
> raise CalledProcessError(retcode, process.args,
> subprocess.CalledProcessError: Command '['gpg', '--batch', 
> '--no-default-keyring', '--keyring', 
> '/usr/share/keyrings/debian-archive-keyring.gpg', '--list-keys', 
> '--with-colons']' returned non-zero exit status 2.

I suspect the same is also true for 
.

Thanks a lot, Jonathan Hettwer (bauen1)

-- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Simon McVittie]

On Tue, 12 Sep 2023 at 10:52:16 -0400, Paul Tagliamonte wrote:
> I have NSS set up to talk with OpenSC

"NSS" is unfortunately ambiguous in this context. Is this the glibc Name
Service Switch (the thing that for example libnss-systemd integrates
with), or Mozilla's Netscape Security Services (libnss3), or some secret
third thing also named NSS?

Whichever one it is, can you be more specific about what was involved in
"setting it up to talk with OpenSC"?

smcv

Bug#1051747: p11tool should use libssl3

[Andreas Metzler]

On 2023-09-12 Philipp Marek via Pkg-gnutls-maint 
 wrote:
> Package: gnutls-bin
> Version: 3.8.1-4+b1
> Severity: normal
> X-Debbugs-Cc: phil...@marek.priv.at

> After removing libssl1.1:amd64=1.1.1o-1 I can't run p11tool any more:

> # LD_DEBUG=libs p11tool
>1708431: find library=libcrypto.so.1.0.1 [0]; searching
>...
>1708431: find library=libcrypto.so.1.0.0 [0]; searching
[..]


Are you actually testing /usr/bin/p11tool as shipped by gnutls-bin?
Please doublecheck.

cu Andreas

Bug#1051794: paje.app: Please add original homepage (exists)

[Ben Tris]

Source: paje.app
Version: 1.98-1.1
Severity: wishlist
X-Debbugs-Cc: benatt...@gezapig.nl

Dear Maintainer,

This home page is well made.
homepage: https://paje.sourceforge.net/


-- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1051795: m2crypto: Fails testsuite with OpenSSL 3.1

[Sebastian Andrzej Siewior]

Package: m2crypto
Version: 0.38.0-4
Severity: important
Control: affects -1 + src:openssl
Control: tags -1 + upstream patch fixed-upstream

Hi,

As far as I can tell, m2crypto compiles and passes the testsuite if
compiled and run against openssl 3.0 or 3.1. What currently fails is if
m2crypto is compiled against 3.0 adn the testsuite run against 3.1. This
can be seen
https://release.debian.org/britney/pseudo-excuses-experimental.html

https://ci.debian.net/data/autopkgtest/unstable/amd64/m/m2crypto/37743405/log.gz

I did a little testing and noticed that upstream already took care of
this with commit
957df43e0e16e ("OpenSSL changed error message yet again.")

https://gitlab.com/m2crypto/m2crypto/-/commit/957df43e0e16e6649bf4834c21ae63d0a80d9095

I can confirm that this change fixes the problem.
The commit in question is part of m2crypto 0.39.0. Could you please
upload m2crypto 0.39.0? :)

Sebastian

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Paul Tagliamonte]

On Tue, Sep 12, 2023 at 05:27:15PM +0100, Simon McVittie wrote:
> On Tue, 12 Sep 2023 at 10:52:16 -0400, Paul Tagliamonte wrote:
> > I have NSS set up to talk with OpenSC
> 
> "NSS" is unfortunately ambiguous in this context. Is this the glibc Name
> Service Switch (the thing that for example libnss-systemd integrates
> with), or Mozilla's Netscape Security Services (libnss3), or some secret
> third thing also named NSS?

Ah, very sorry. libnss3.

I usually use OpenSC in the following configuration:

```
modutil -add "OpenSC" \
  -libfile /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so \
  -dbdir sql:$HOME/.pki/nssdb
```

However, when I went to confirm my notes[1] against my running system, I
found it to be in a different state (using onepin-opensc-pkcs11.so,
which is new to me):

| An aside:
|
| [1]: My notes are in the form of manpages for stuf I do infrequently but
| want to remember. Here's a markdon of the yubkey manpage when I noodle
| with using it in OpenSC mode, in case this is helpful for more
| information: https://gist.github.com/paultag/2c35b62e85a032856c2cb97345c3d24d
|
| That's from 2017, so the world has changed quite a bit, and some of it
| is bad / outdated advice, so I'd just use it to help understand likely
| system configuration than best practice -- for instance, don't use
| pkcs#11 for ssh keys anymore pls :)

Related output when using `modutil -list -dbdir sql:$HOME/.pki/nssdb`

I'm seeing a slightly different configuration (hurmm, odd):

```
  2. OpenSC smartcard framework (0.22)
library name: /usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so
   uri: 
pkcs11:library-manufacturer=OpenSC%20Project;library-description=OpenSC%20smartcard%20framework;library-version=0.23
 slots: 1 slot attached
status: loaded

 slot:
token:
  uri: pkcs11:
```

dpkg output from the packages I know about off the top of my head that
would be involved that aren't in the last report:

ii  opensc   0.23.0-1   
   amd64Smart card utilities with support for PKCS#15 
compatible cards
ii  opensc-pkcs11:amd64  0.23.0-1   
   amd64Smart card utilities (PKCS#11 module)
ii  libnss3:amd642:3.92-1   
   amd64Network Security Service libraries
ii  libnss3-dev:amd642:3.92-1   
   amd64Development files for the Network Security Service 
libraries
ii  libnss3-tools2:3.92-1   
   amd64Network Security Service tools
ii  libykpiv-dev:amd64   2.2.0-1.1  
   amd64Development files for the YubiKey PIV Library
ii  libykpiv2:amd64  2.2.0-1.1  
   amd64Library for communication with the YubiKey PIV 
smartcard
ii  pcscd2.0.0-1
   amd64Middleware to access a smart card using PC/SC 
(daemon side)
ii  libccid  1.5.2-1
   amd64PC/SC driver for USB CCID smart card readers

-- 
:wq


signature.asc
Description: PGP signature

Bug#1051747: p11tool should use libssl3

[Philipp Marek]

Are you actually testing /usr/bin/p11tool as shipped by gnutls-bin?
Please doublecheck.



I believe I do?


location:
$ which p11tool
/usr/bin/p11tool

no symlink or such stuff:
$ ls -al /usr/bin/p11tool
-rwxr-xr-x 1 root root 339720  6. Sep 18:26 /usr/bin/p11tool

file comes from:
$ dpkg-query -S /usr/bin/p11tool
gnutls-bin: /usr/bin/p11tool

package's files are not modified:
$ debsums gnutls-bin
/usr/bin/certtool
 OK
/usr/bin/danetool
 OK
/usr/bin/gnutls-cli  
 OK
/usr/bin/gnutls-cli-debug
 OK
/usr/bin/gnutls-serv 
 OK
/usr/bin/ocsptool
 OK
/usr/bin/p11tool 
 OK
/usr/bin/psktool 
 OK
/usr/share/doc/gnutls-bin/changelog.Debian.amd64.gz  
 OK
/usr/share/doc/gnutls-bin/changelog.Debian.gz
 OK
/usr/share/doc/gnutls-bin/changelog.gz   
 OK
/usr/share/doc/gnutls-bin/copyright  
 OK
/usr/share/doc/gnutls-bin/examples/certtool.cfg  
 OK
/usr/share/man/man1/certtool.1.gz
 OK
/usr/share/man/man1/danetool.1.gz
 OK
/usr/share/man/man1/gnutls-cli-debug.1.gz
 OK
/usr/share/man/man1/gnutls-cli.1.gz  
 OK
/usr/share/man/man1/gnutls-serv.1.gz 
 OK
/usr/share/man/man1/ocsptool.1.gz
 OK
/usr/share/man/man1/p11tool.1.gz 
 OK
/usr/share/man/man1/psktool.1.gz 
 OK
/usr/share/man/man1/tpmtool.1.gz 
 OK


$ LC_ALL=C dpkg-query -l gnutls-bin
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description

+++-==---===
ii  gnutls-bin 3.8.1-4+b1   amd64GNU TLS library - 
commandline utilities


is there something that I overlooked?

Bug#1051747: p11tool should use libssl3

[Andreas Metzler]

On 2023-09-12 Philipp Marek via Pkg-gnutls-maint 
 wrote:
> > Are you actually testing /usr/bin/p11tool as shipped by gnutls-bin?
> > Please doublecheck.


> I believe I do?


> location:
> $ which p11tool
> /usr/bin/p11tool
[...]

Thank you.

I suspect the culprit might be one of pkcs11 modules you are using, not
p11-toool itself.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1051796: thunderbird: message headers NOT displayed in message list or message for some, not all, messages, OK in evolution, balsa

[js]

Package: thunderbird
Version: 1:117.0~b5-1
Severity: important

Dear Maintainer,

==

   * What led up to the situation?
 Thunderbird is my default mail client. Inbox has about 1300 mails
 in it and occassionally messages appear garbled (ie message headers
 not displayed or selected message in list doesn't match preview
 pane). Up to now, this was easily corrected by repairing the
 folder.

 Today (Sept 12) this is not the case: repairing the folder **very briefly 
**
 displays the headers correctly and then they disappear.

 Note that the mail folders themselves are fine: opening another
 email client (I tried evolution, balsa, claws-mail) displays
 correctly all the message headers missing from thunderbird.

 This is limited to thunderbird display of message headers. When replying
 to a message with empty From, To, Subject, thunderbird correctly
 fills in the missing fields (list of recipients, subject, etc.)

   * What exactly did you do (or not do) that was effective (or ineffective)?
 Repaired the folder several times, upgraded dbus and rebooted, but
 problem persists.

   * What outcome did you expect instead?
 In the past this behavior has sometimes happened, only in
 thunderbird (but not in other mail clients) and folder repair fixed
 it.


==

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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.8-1
ii  fontconfig   2.14.2-3
ii  kdialog  4:22.12.3-1
ii  libasound2   1.2.9-1
ii  libatk1.0-0  2.48.3-1
ii  libc62.37-5
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.10-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-3
ii  libfreetype6 2.13.1+dfsg-1
ii  libgcc-s113.2.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.77.2-1
ii  libgtk-3-0   3.24.38-2
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.50.14+ds-1
ii  libstdc++6   13.2.0-1
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.44.0-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2
ii  myspell-es [myspell-dictionary]   1.11-20
ii  myspell-fr [myspell-dictionary]   1.4-30
ii  myspell-he [myspell-dictionary]   1.4-3.1

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.3.7-1
ii  libgssapi-krb5-2  1.20.1-2

-- no debconf information

Bug#1051797: libtk-img-doc: dpkg extraction error during upgrading

[Davide Prina]

Package: libtk-img-doc
Version: 1:1.4.14+dfsg-2
Severity: normal
X-Debbugs-Cc: davide.pr...@null.net

Dear mainteiner,

during the upgrade of the package from version 1:1.4.15+dfsg-1 to
version 1:1.4.14+dfsg-2 I have the following error:

dpkg: errore nell'elaborare l'archivio 
/tmp/user/0/apt-dpkg-install-f3K6IA/18-libtk-img-doc_1%3a1.4.15+dfsg-1_all.deb 
(--unpack):
 tentata sovrascrittura di "/usr/share/doc/libtk-img/README.gz" presente anche 
nel pacchetto libtk-img:amd64 1:1.4.15+dfsg-1

I try to translate:
dpkg: error processing the archive 
/tmp/user/0/apt-dpkg-install-f3K6IA/18-libtk-img-doc_1%3a1.4.15+dfsg-1_all.deb 
(--unpack):
 try to overwrite of "/usr/share/doc/libtk-img/README.gz" present also in the 
package libtk-img:amd64 1:1.4.15+dfsg-1

Ciao
Davide

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

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

libtk-img-doc depends on no packages.

libtk-img-doc recommends no packages.

Versions of packages libtk-img-doc suggests:
ii  libtk-img  1:1.4.15+dfsg-1

-- no debconf information

Bug#1051787: Subject: CVE-2023-4863: Heap buffer overflow in WebP

[Andres Salomon]

reassign 1051787 libwebp
thanks


Actually I'm mistaken, we're building against the system libwebp so 
there's no need to update chromium at all for this CVE. The webp fix is 
the only (linux) change that chromium made between .180 and .187.





On Tue, Sep 12 2023 at 11:34:26 AM -04:00:00, Andres Salomon 
 wrote:

clone 1051787 -1
reassign -1 libwebp
thanks

This bug's actually in libwebp. Unfortunately we're still embedding 
it in chromium, so we likely need to fix both chromium *and* libwebp 
in debian. There hasn't been a libwebp release yet, but the two 
relevant git commits are


and what appears to be a followup fix to that,



On Tue, Sep 12 2023 at 09:12:40 AM -06:00:00, Jeffrey Cliff 
 wrote:

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team >


Dear Maintainer,

116.0.5845.187 fixes a critical remote vulnerability in chrome

[$NA][1479274] Critical CVE-2023-4863: Heap buffer overflow in WebP.
Reported by Apple Security Engineering and Architecture (SEAR) and 
The Citizen

Lab at The University of Torontoʼs Munk School on 2023-09-06



Might want to look into this at least

(attempt 3, my reportbug broke sorry)

Jeff Cliff

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

Kernel: Linux 6.5.0-gnulibre (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled


Versions of packages chromium depends on:
pn  chromium-common
ii  libasound2 1.2.9-2
ii  libatk-bridge2.0-0 2.49.91-2
ii  libatk1.0-02.49.91-2
ii  libatomic1 13.2.0-3
ii  libatspi2.0-0  2.49.91-2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.37-7
ii  libcairo2  1.17.8-3
ii  libcups2   2.4.2-5
ii  libdbus-1-31.14.10-1devuan1
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.115-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-2
ii  libflac12  1.4.3+ds-2
ii  libfontconfig1 2.14.2-5
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.1.7-1
ii  libgcc-s1  13.2.0-3
ii  libglib2.0-0   2.77.3-1
ii  libgtk-3-0 3.24.38-4
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip11:1.2.13.dfsg-3
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.92-1
pn  libopenh264-7  
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 13.2.0-3
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.6-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Bug#1051796: thunderbird not displaying message headers correctly.

[js jb]

I've noticed that the behavior described in this bug tends to happen in 
messages whose attachments were deleted.
thanks