Bug#1034931: libfl-dev: missing Breaks+Replaces for flex-old when upgrading from bullseye

[Andreas Metzler]

On 2023-04-27 Helmut Grohne  wrote:
> Package: libfl-dev
> Version: 2.6.4-8.1
> Severity: serious
> Justification: dpkg unpack error

> Attempting to unpack libfl-dev/2.6.4-8.1 from Debian bookworm
> on a minimal Debian bullseye with flex-old/2.5.4a-10.1
> installed, causes an unpack error from dpkg due to
> /usr/include/FlexLexer.h being contained in both packages.
[...]
> Please ensure that libfl-dev has sufficient Breaks and Replaces declarations.

Hello,

we currently have:

Package: libfl-dev
Replaces: flex (<< 2.5.39), flex-old (<= 2.5.4a-10)
Breaks: flex (<< 2.5.39), flex-old (<= 2.5.4a-10)

However afaict there are no plans for splitting flex-old into flex-old
and libfl-old-dev so this file conflict is permanent, i.e. libfl-dev should
use unversioned Conflicts instead of versioned Breaks.

On sidenote I think flex should Conflict with flex-old like flex-old
does.

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#1035522: bullseye-pu: package debian-security-support/1:11+2023.05.04

[Adam D. Barratt]

On Thu, 2023-05-18 at 00:44 +, Holger Levsen wrote:
>  debian-security-support (1:11+2023.05.04) bullseye-updates;
> urgency=medium
> 

Hmmm. I didn't expect that would work, although apparently it did, at
least for the package to get as far as stable-new. I'm hoping dak also
dtrt for accepts of such packages, i.e. moves them to p-u as for any
other stable upload.

-updates isn't an upload target; packages enter it by SRM asking dak to
copy them from p-u.

Regards,

Adam

Bug#1036013: intel-microcode: new upstream version

[Salvatore Bonaccorso]

Control: tags -1 - security

On Sat, May 13, 2023 at 02:04:34AM +0200, Christoph Anton Mitterer wrote:
> Package: intel-microcode
> Version: 3.20230214.1
> Severity: normal
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Hey.
> 
> There's a new version 20230512 out which according to changelog
> fixes an undisclosed security issues for numerous platforms.

As per rectified comment in the release notes:

> Security updates for [INTEL-SA-NA]
> Microcode 20230512 update released on May 12, 2023, does not contain
> any security updates and the note, [INTEL-SA-NA] is meant to convey
> that there are no applicable (Not Applicable) security updates in
> the package.

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20230512

Regards,
Salvatore

Bug#1036248: exiv2: add brotli dependency to allow reading JpegXL metadata

[Stefan Breunig]

Package: exiv2
Version: 0.27.6-1
Severity: wishlist
X-Debbugs-Cc: stefan-deb...@yrden.de

Dear Maintainer,

please consider adding libbrotli(-dev) dependency to exiv2 so that it is able to
decode JpegXL metadata. With the packaged version:

  $ /usr/bin/exiv2 J.jxl   
  File name   : J.jxl
  File size   : 2160508 Bytes
  MIME type   : image/generic
  Image size  : 0 x 0
  J.jxl: No Exif data found in the file

With a version compiled with -DEXIV2_ENABLE_BROTLI=ON (default value):

  $ /tmp/exiv2/build/bin/exiv2 J.jxl
  Warning: Directory Photo has an unexpected next pointer; ignored.
  Warning: Directory Iop has an unexpected next pointer; ignored.
  Warning: Directory GPSInfo has an unexpected next pointer; ignored.
  File name   : J.jxl
  File size   : 2160508 Bytes
  MIME type   : image/jxl
  Image size  : 4000 x 3000
  Thumbnail   : image/jpeg, 3874 Bytes
  Camera make : GoPro
  Camera model: HERO5 Black
  Image timestamp : 2019:01:02 14:02:25.000
  ...

Thank you
Stefan

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 exiv2 depends on:
ii  libc62.36-9
ii  libexiv2-27  0.27.6-1
ii  libgcc-s112.2.0-14
ii  libstdc++6   12.2.0-14

exiv2 recommends no packages.

exiv2 suggests no packages.

-- debconf-show failed

Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Otto Kekäläinen]

Here is the apt resolver output for debugging:

# apt install default-mysql-server -o Debug::pkgDepCache::Marker=1 -o
Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
  MarkInstall default-mysql-server:amd64 < 1.0.7 -> 1.1.0 @ii pumU Ib > FU=1
  Installing mariadb-server:amd64 as Depends of default-mysql-server:amd64
 Removing: mariadb-server-10.5:amd64 as upgrade is not an option
for mariadb-server:amd64 (1:10.11.2-1)
  MarkDelete mariadb-server-10.5:amd64 < 1:10.5.19-0+deb11u2 @ii
mK Ib > FU=0
MarkInstall mariadb-server:amd64 < none -> 1:10.11.2-1 @un puN Ib > FU=0
Installing mariadb-common:amd64 as PreDepends of mariadb-server:amd64
  MarkInstall mariadb-common:amd64 < 1:10.5.19-0+deb11u2 ->
1:10.11.2-1 @ii pumU > FU=0
Installing mariadb-client:amd64 as Depends of mariadb-server:amd64
   Removing: mariadb-client-10.5:amd64 as upgrade is not an option
for mariadb-client:amd64 (1:10.11.2-1)
MarkDelete mariadb-client-10.5:amd64 < 1:10.5.19-0+deb11u2 @ii
mK Ib > FU=0
   Removing: mariadb-client-core-10.5:amd64 as upgrade is not an
option for mariadb-client:amd64 (1:10.11.2-1)
MarkDelete mariadb-client-core-10.5:amd64 <
1:10.5.19-0+deb11u2 @ii mK > FU=0
  MarkInstall mariadb-client:amd64 < none -> 1:10.11.2-1 @un puN Ib > FU=0
  Installing mariadb-client-core:amd64 as Depends of mariadb-client:amd64
 Removing: mariadb-server-core-10.5:amd64 as upgrade is not an
option for mariadb-client-core:amd64 (1:10.11.2-1)
  MarkDelete mariadb-server-core-10.5:amd64 <
1:10.5.19-0+deb11u2 @ii mK > FU=0
MarkInstall mariadb-client-core:amd64 < none -> 1:10.11.2-1
@un puN Ib > FU=0
Installing libc6:amd64 as Depends of mariadb-client-core:amd64
  MarkInstall libc6:amd64 < 2.31-13+deb11u5 -> 2.36-9 @ii pumU
NPb > FU=0
Installing libssl3:amd64 as Depends of mariadb-client-core:amd64
  MarkInstall libssl3:amd64 < none -> 3.0.8-1 @un puN > FU=0
Installing mariadb-server-core:amd64 as Depends of mariadb-server:amd64
  MarkInstall mariadb-server-core:amd64 < none -> 1:10.11.2-1 @un
puN Ib > FU=0
  Installing libpmem1:amd64 as Depends of mariadb-server-core:amd64
MarkInstall libpmem1:amd64 < none -> 1.12.1-2 @un puN Ib > FU=0
Installing libdaxctl1:amd64 as Depends of libpmem1:amd64
  MarkInstall libdaxctl1:amd64 < none -> 76.1-1 @un puN Ib > FU=0
  Installing libkmod2:amd64 as Depends of libdaxctl1:amd64
MarkInstall libkmod2:amd64 < none -> 30+20221128-1 @un puN Ib > FU=0
Installing libzstd1:amd64 as Depends of libkmod2:amd64
  MarkInstall libzstd1:amd64 < 1.4.8+dfsg-2.1 ->
1.5.4+dfsg2-5 @ii pumU > FU=0
Installing libndctl6:amd64 as Depends of libpmem1:amd64
  MarkInstall libndctl6:amd64 < none -> 76.1-1 @un puN > FU=0
  Installing libstdc++6:amd64 as Depends of mariadb-server-core:amd64
MarkInstall libstdc++6:amd64 < 10.2.1-6 -> 12.2.0-14 @ii pumU Ib > FU=0
Installing gcc-12-base:amd64 as Depends of libstdc++6:amd64
  MarkInstall gcc-12-base:amd64 < none -> 12.2.0-14 @un puN > FU=0
  Installing liburing2:amd64 as Depends of mariadb-server-core:amd64
MarkInstall liburing2:amd64 < none -> 2.3-3 @un puN > FU=0
Installing mariadb-plugin-provider-bzip2:amd64 as Recommends of
mariadb-server:amd64
  MarkInstall mariadb-plugin-provider-bzip2:amd64 < none ->
1:10.11.2-1 @un uN > FU=0
Installing mariadb-plugin-provider-lz4:amd64 as Recommends of
mariadb-server:amd64
  MarkInstall mariadb-plugin-provider-lz4:amd64 < none ->
1:10.11.2-1 @un uN > FU=0
Installing mariadb-plugin-provider-lzma:amd64 as Recommends of
mariadb-server:amd64
  MarkInstall mariadb-plugin-provider-lzma:amd64 < none ->
1:10.11.2-1 @un uN > FU=0
Installing mariadb-plugin-provider-lzo:amd64 as Recommends of
mariadb-server:amd64
  MarkInstall mariadb-plugin-provider-lzo:amd64 < none ->
1:10.11.2-1 @un uN Ib > FU=0
  Installing liblzo2-2:amd64 as Depends of mariadb-plugin-provider-lzo:amd64
MarkInstall liblzo2-2:amd64 < none -> 2.10-2 @un uN > FU=0
Installing mariadb-plugin-provider-snappy:amd64 as Recommends of
mariadb-server:amd64
  MarkInstall mariadb-plugin-provider-snappy:amd64 < none ->
1:10.11.2-1 @un uN Ib > FU=0
  Installing libsnappy1v5:amd64 as Depends of
mariadb-plugin-provider-snappy:amd64
MarkInstall libsnappy1v5:amd64 < 1.1.8-1 -> 1.1.9-3 @ii umU > FU=0
Installing pv:amd64 as Recommends of mariadb-server:amd64
  MarkInstall pv:amd64 < none -> 1.6.20-1 @un uN > FU=0
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following package was automatically installed and is no longer required:
  libaio1
Use 'apt autoremove' to remove it.
The following additional packages will be 

Bug#1000518: logcheck: separate filtering for apt term.log and or unattended-upgrades-dpkg.log etc?

[Paul Wise]

Thanks for the info and thoughts.

The idea would do something like your second suggestion; run logcheck
on apt logs separately, but within Debian instead of just on my system.
Perhaps we could also distribute the ignore regexes across packages
like logcheck itself does. Since not everyone is going to want this,
probably this would be in a separate apt logcheck package.

Since apt term.log collects all apt output, but doesn't collect output
from apt hooks (which is often useful), unattended-upgrades-dpkg.log
collects only automated apt output, but *does* collect output from apt
hooks, this idea is going to require some changes to one or either of
those packages so that users don't get duplicate entries.

The apt/u-u tools already report errors fine, this isn't about that,
but about reporting anomalous messages that aren't apt errors, like
notices or warnings from maintainer scripts or apt hooks etc.

The cron-apt error check is likewise not useful for this idea.

PS: do you know if logcheck supports printing nearby ignored lines for
context for each non-ignored log message that was printed? That would
be essential for this apt log filtering because the non-ignored
messages are usually produced by package maintainer scripts and the
ignored nearby lines contain the name of the relevant packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Otto Kekäläinen]

I did some more testing in throwaway containers.

In each test starting point was same:

apt-get install default-mysql-server zoph
sed s/bullseye/bookworm/g -i /etc/apt/sources.list
apt update

All cases ran apt 2.6.0.

I only varied the command that followed:

1) apt-get install default-mysql-server

Fails:

debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 16648 files and directories currently installed.)
Preparing to unpack .../mysql-common_5.8+1.1.0_all.deb ...
Unpacking mysql-common (5.8+1.1.0) over (5.8+1.0.7) ...
Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ...
Unpacking mariadb-common (1:10.11.2-1) over (1:10.5.19-0+deb11u2) ...
Preparing to unpack .../default-mysql-server_1.1.0_all.deb ...
Unpacking default-mysql-server (1.1.0) over (1.0.7) ...
dpkg: mariadb-client-10.5: dependency problems, but removing anyway as
you requested:
 mariadb-server-10.5 depends on mariadb-client-10.5 (>= 1:10.5.19-0+deb11u2).
 dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; however:
  Package default-mysql-client is not installed.
  Package virtual-mysql-client is not installed.
  Package mariadb-client-10.5 which provides virtual-mysql-client is
to be removed.
(Reading database ... 16648 files and directories currently installed.)
Removing mariadb-client-10.5 (1:10.5.19-0+deb11u2) ...
Removing mariadb-client-core-10.5 (1:10.5.19-0+deb11u2) ...
dpkg: mariadb-server-10.5: dependency problems, but removing anyway as
you requested:
 zoph depends on default-mysql-server | virtual-mysql-server; however:
  Package default-mysql-server is not configured yet.
  Package virtual-mysql-server is not installed.
  Package mariadb-server-10.5 which provides virtual-mysql-server is
to be removed.
Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ...
Stopping MariaDB database server: mariadbd failed!
invoke-rc.d: initscript mariadb, action "stop" failed.
dpkg: error processing package mariadb-server-10.5 (--remove):
 installed mariadb-server-10.5 package pre-removal script subprocess
returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
 mariadb-server-10.5
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)

# apt --fix-broken install mariadb-client
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 default-mysql-server : Depends: mariadb-server but it is not going to
be installed
 mariadb-client : Depends: mariadb-client-core (>= 1:10.11.2-1) but it
is not going to be installed
  Depends: libssl3 (>= 3.0.0) but it is not going to
be installed
  Breaks: mariadb-server-10.5 but 1:10.5.19-0+deb11u2
is to be installed
 mariadb-server-10.5 : Depends: mariadb-client-10.5 (>=
1:10.5.19-0+deb11u2) but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages
(or specify a solution).



2) apt upgrade

Passes:

Everything is unpacked and installed, and MariaDB server restart is
among the last things that happen and is successful.

Upgrade of default-mysql-server was postponed and starts only when
running 'apt full-upgrade'.



3) apt full-upgrade

Fails:

...
Preparing to unpack .../default-mysql-server_1.1.0_all.deb ...
Unpacking default-mysql-server (1.1.0) over (1.0.7) ...
dpkg: mariadb-client-10.5: dependency problems, but removing anyway as
you requested:
 mariadb-server-10.5 depends on mariadb-client-10.5 (>= 1:10.5.19-0+deb11u2).
 dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; however:
  Package default-mysql-client is not installed.
  Package virtual-mysql-client is not installed.
  Package mariadb-client-10.5 which provides virtual-mysql-client is
to be removed.
(Reading database ... 18487 files and directories currently installed.)
Removing mariadb-client-10.5 (1:10.5.19-0+deb11u2) ...
Removing mariadb-client-core-10.5 (1:10.5.19-0+deb11u2) ...
dpkg: mariadb-server-10.5: dependency problems, but removing anyway as
you requested:
 zoph depends on default-mysql-server | virtual-mysql-server; however:
  Package default-mysql-server is not configured yet.
  Package virtual-mysql-server is not installed.
  Package mariadb-server-10.5 which provides virtual-mysql-server is
to be removed.
Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ...
Stopping MariaDB database server: mariadbd failed!
invoke-rc.d: initscript mariadb, action "stop" failed.
dpkg: error processing package mariadb-server-10.5 (--remove):
 installed mariadb-server-10.5 package pre-removal script subprocess
returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
 mariadb-server-10.5
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an 

Bug#1036055: Acknowledgement (libk5crypto3: depend on latest libkrb5support0 to avoid crashing at load time)

[Otto Kekäläinen]

I confirm this works now in Debian Sid, and MariaDB restarts nicely
without issues:

# apt install libk5crypto3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libgssapi-krb5-2 libkrb5-3 libkrb5support0 libssl3
Suggested packages:
  krb5-doc krb5-user
Recommended packages:
  krb5-locales
The following NEW packages will be installed:
  libssl3
The following packages will be upgraded:
  libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0
4 upgraded, 1 newly installed, 0 to remove and 138 not upgraded.
Need to get 2589 kB of archives.
After this operation, 6029 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian sid/main amd64 libssl3 amd64
3.0.8-1 [2013 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 libkrb5support0
amd64 1.20.1-2 [32.3 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 libkrb5-3 amd64
1.20.1-2 [331 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 libgssapi-krb5-2
amd64 1.20.1-2 [134 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 libk5crypto3 amd64
1.20.1-2 [79.0 kB]
Fetched 2589 kB in 0s (8702 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libssl3:amd64.
(Reading database ... 10402 files and directories currently installed.)
Preparing to unpack .../libssl3_3.0.8-1_amd64.deb ...
Unpacking libssl3:amd64 (3.0.8-1) ...
Setting up libssl3:amd64 (3.0.8-1) ...
(Reading database ... 10414 files and directories currently installed.)
Preparing to unpack .../libgssapi-krb5-2_1.20.1-2_amd64.deb ...
Unpacking libgssapi-krb5-2:amd64 (1.20.1-2) over (1.18.3-6+deb11u3) ...
Preparing to unpack .../libkrb5support0_1.20.1-2_amd64.deb ...
Unpacking libkrb5support0:amd64 (1.20.1-2) over (1.18.3-6+deb11u3) ...
Setting up libkrb5support0:amd64 (1.20.1-2) ...
(Reading database ... 10414 files and directories currently installed.)
Preparing to unpack .../libkrb5-3_1.20.1-2_amd64.deb ...
Unpacking libkrb5-3:amd64 (1.20.1-2) over (1.18.3-6+deb11u3) ...
Setting up libkrb5-3:amd64 (1.20.1-2) ...
(Reading database ... 10414 files and directories currently installed.)
Preparing to unpack .../libk5crypto3_1.20.1-2_amd64.deb ...
Unpacking libk5crypto3:amd64 (1.20.1-2) over (1.20.1-1+b1) ...
Setting up libk5crypto3:amd64 (1.20.1-2) ...
Setting up libgssapi-krb5-2:amd64 (1.20.1-2) ...
Processing triggers for libc-bin (2.36-9) ...
root@920989b79865:/build# /etc/init.d/mariadb restart
Stopping MariaDB database server: mariadbd.
Starting MariaDB database server: mariadbd.

Bug#1036237: RFS: libwebservice-musicbrainz-perl/1.0.6-1 -- XML based Web service API to the MusicBrainz database

[Paul Wise]

On Wed, 2023-05-17 at 22:10 +0200, Michael Ablassmeier wrote:

> I am looking for a sponsor for my package
> "libwebservice-musicbrainz-perl":

I suggest moving your Perl packages into the Perl team.
You'll get shared maintenance and sponsorship when needed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1036246: unblock: iptables-netflow/2.6-4

[Axel Beckert]

Hi Sebastian,

Axel Beckert wrote:
> Please unblock iptables-netflow/2.6-4.

Sorry, but I saw only now that you already granted an unblock today
(well, actually yesterday in CEST as it's already past mightnight).

I waited with the unblock request until I was able to test a full
upgrade of a production-grade server using this package to make sure
that it was properly working under production settings. (And for
multiple, work and private reasons, this wasn't possible before this
night.)

Anyway, I've put quite some effort into testing this properly so
shortly before the release, so you might want to have a look
nevertheless. :-)

P.S.: And thanks for also unblocking debsums recently. There I was
waiting for some more feedback from Andreas, but noticed that it
migrated to testing even before I started writing an unblock request.
:-)

P.P.S.: Please tell me if in future I should write unblock requests
more earlier after the upload to spare the release team their own look
at it. So far my mode of operation was to only file the unblock
request if the package proved itself in unstable for a few days at
least.

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

Bug#1035522: bullseye-pu: package debian-security-support/1:11+2023.05.04

[Holger Levsen]

On Fri, May 12, 2023 at 08:30:22PM +0100, Adam D. Barratt wrote:
> It's only been a week, and one of the SRMs has been on a publicised
> (fvo publicised being relevant to DDs) week away. It's a little soon to
> be chasing. :-(

(again) I'm sorry if this felt as chasing, this wasn't my intention.

> I'm a bit confused here. Your own text above indicates that you're
> aware that there won't be any more point releases before the release,
> and that therefore the package *cannot* be in bullseye before the
> release. Point releases are the mechanism by which packages get updated
> in stable.

yes, that part I am and was familar with. Less clear was ${distro}-updates,
which thankfully got resolved through this bug. I think. ;)

> In any case, please go ahead.

thanks, done so now with this changelog:

 debian-security-support (1:11+2023.05.04) bullseye-updates; urgency=medium
 .
   [ Holger Levsen ]
   * set DEB_NEXT_VER_ID=12 as bookworm is the next release. Closes: #1034077.
 Thanks to Stuart Prescott.
 .
   [ Sylvain Beucler ]
   * security-support-limited: add gnupg1, see #982258.


-- 
cheers,
Holger

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

"I became an antifascist out of a sense of common decency.” – Marlene Dietrich


signature.asc
Description: PGP signature

Bug#1036246: unblock: iptables-netflow/2.6-4

[Axel Beckert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: iptables-netf...@packages.debian.org, a...@debian.org, 
a...@debian.org
Control: affects -1 + src:iptables-netflow

Please unblock iptables-netflow/2.6-4.

This is an update to fix the RC bug report at
https://bugs.debian.org/1035511 and fixes an upgrade issue from
Bullseye to Bookworm if iptables-netflow-dkms is upgraded while the
Bullseye kernel (and headers) are still installed — which is the case
in nearly every upgrade workflow.

[ Reason ]

Upgrades from Bullseye to Bookworm failed, at least until the Bullseye
kernel has been uninstalled.

[ Impact ]

Impact without this package update, admins will

* have to wait for iptables-netflow-dkms's postinst to succeed until
  they have rebooted into the Bookworm kernel and uninstalled the
  Bullseye kernel.

* have no chance of running the newer iptables-netflow-dkms version
  from Bookworm with the Bullseye kernel.

Impact of the change:

* Low. Cherry-picked an upstream commit explicitly fixing compilation
  with older kernels. Regression introduced upstream with 2.6 when
  fixing compilation with kernel 5.15. It adds some compat definitions
  into the #ifdef areas for older kernels. Does not affect compiling
  against Bookworm's 6.1 kernel.

[ Tests ]

* Installation on Sid. Still compiles fine.

  (Exception: Fails if the kernel 6.3 in Experimental is installed on
  Sid. But I consider a fix for that to be unsuitable at this stage of
  the freeze.)

* Installation on two Bullseye systems of which one is a production
  server heavily relying on exactly this package. Still works fine
  with the Sid package installed on Bullseye with stock Bullseye
  kernel, even during package upgrade and after a reboot (into the
  Bullseye kernel).

  Netflows generated with iptables-netflow-dkms continued to show up
  in nfdump's local cache after upgrading the package to the version
  currently in Sid as well as after rebooting (which guarantees that
  the newly built kernel module was really used, not just compiled).

  This test proves that a server will continue to provide the
  package's functionality even during a dist-upgrade even while still
  running under the Bullseye kernel. (Which was found in #1035511 to
  be not the case due to the failing compilation with the Bullseye
  kernel.)

* Upgrade of a server from Bullseye to Bookworm which is using this
  package in production. Upgrade failed as reported in #1035511. The
  failure was fixed by installing the package from Unstable using
  "dpkg -i" as expected.

  Netflows generated with iptables-netflow-dkms continued to show up
  in nfdump's local cache afterwards as well after the final reboot
  into Bookworm's kernel.

  This test proves that a server will continue to provide the
  package's functionality even during a dist-upgrade and that it still
  works fine under Bookworm's kernel, i.e. that it does NOT introduce
  a regression on Bookworm.

* Autopkgtest in Sid via autopkgtest-pkg-dkms:
  https://qa.debian.org/excuses.php?package=iptables-netflow says "No
  test results" for all tests. I'm not sure what this actually
  means. If I click on such a link I see:

  I: Summary:
  I: PASS 6.1.0-8-amd64
  I: PASS 6.1.0-8-cloud-amd64
  I: PASS 6.1.0-8-rt-amd64

  Maybe these passes were considered superficial as in the end it
  justs says twice:

  dkms-autopkgtest PASS (superficial)

[ Risks ]

* Future updates of the Bullseye kernel with backported kernel fixes
  might break some assumptions of the kernel version #ifdefs in this
  kernel module like the ones updated in this patch and hence might
  cause upgrade issues due to compilation issues again if someone
  upgrades from Bullseye to Bookworm only late in the Bullseye release
  cycle.

  But this is given with and without that upgrade, and it has happened
  in past stable releases as well. (Has IIRC last happened with
  backported kernel fixes in Buster.)

* It's a leaf package only in use on servers which generate netflows
  out of network traffic, e.g. for traffic statistics or security
  monitoring purposes.

[ Checklist ]

  [x] all changes are documented in the d/changelog

  (debian/.gitignore was added by the recent NMU by accident and
   has been removed in this upload again automatically without any
   manual change, hence its removal does not show up in the
   debian/changelog entry. It ending up in the debdiff is not a
   result of this upload but actually a result of the previous
   upload being build directly from git or so.)

  [x] I reviewed all changes and I approve them

  [x] attach debdiff against the package in testing

[ Other info ]

The cherry-picked upstream commit is
https://github.com/aabc/ipt-netflow/commit/0901f028617acca350132a65293ab80a480bf233

commit 0901f028617acca350132a65293ab80a480bf233
Author: Vadim Fedorenko 
Date:   Mon Mar 28 21:59:10 2022 +0300

fix building on 

Bug#1036245: “Any arguments after the -- are treated as filenames and arguments.” in the bash man page makes no sense the way stated

[Al Ma]

Package: bash
Version: 5.1-2+deb11u1
In the man page for bash we see the line,
“-- A -- signals the end of options and disables further option processing. Any 
arguments after the -- are treated as filenames and arguments. An argument of - 
is equivalent to --.”
I claim that the sentence “Any arguments after the -- are treated as filenames 
and arguments.” is strange and should be rewritten or dropped.
I see two main logical interpretations of this sentence:
(1) *For each argument 푥 after --, 푥 is treated as a filename and an argument 
simultaneously.* This can be expressed more succinctly without any loss of 
information: *For each argument 푥 after --, 푥 is treated as a filename.* This 
implies the original formulation as follows. Take any 푥 after --. By the 
succinct formulation, 푥 is treated as a filename. By assumption, 푥 is an 
argument. By default (as this has not been stated otherwise for the option --), 
arguments are also treated as arguments, so 푥 is also treated as an argument. 
Together, 푥 is treated as a filename and an argument. Q.E.D.
(2) *For each argument 푥 after --, 푥 is treated as a filename, or 푥 is treated 
as an argument.* This is a tautology, which you see as follows. Take any 푥 
after --. By default (as this has not been stated otherwise  for the option 
--), arguments are also treated as arguments, so 푥 is treated as an argument. 
Therefore, 〈any claim〉 or 푥 is treated as an or argument. The term 〈any claim〉 
can be arbitrary; in particular, *푥 is treated as a filename* would do. Q.E.D.
Summarizing, in case (1) the sentence can be shortened and in case (2) the 
sentence can be dropped, both without loss of information. Of course, assuming 
that the authors of the document really wish to say what they are saying.
We ask for the description of `--` to be rewritten clearly and succinctly.
Gratefully,
AlMa

Bug#1036244: unblock: noiz2sa/0.51a-13

[Markus Koschany]

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

Please unblock package noiz2sa

[ Reason ]

A long time ago noiz2sa shipped a symlink from the noiz2sa-data
/usr/share/doc directory to its arch-any /usr/share/doc directories to
save 0.14159265359 KB of disk space.
"This kind of overwriting another package's files cannot be detected
by dpkg." And that's why we have to use dpkg-maintscript-helper to fix
this issue. See also #1035632.

[ Impact ]

noiz2sa will be autoremoved.

[ Tests ]

piuparts agrees, it's all good now

[ Risks ]

A couple of nerds would be not amused to find out, that they cannot
play their favorite game in Bookworm.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock noiz2sa/0.51a-13
diff -Nru noiz2sa-0.51a/debian/changelog noiz2sa-0.51a/debian/changelog
--- noiz2sa-0.51a/debian/changelog  2021-11-02 14:55:01.0 +0100
+++ noiz2sa-0.51a/debian/changelog  2023-05-14 15:10:17.0 +0200
@@ -1,3 +1,10 @@
+noiz2sa (0.51a-13) unstable; urgency=medium
+
+  * Add noiz2sa.maintscript: Handle symlink to directory conversion.
+Thanks to Andreas Beckmann for the report. (Closes: #1035632)
+
+ -- Markus Koschany   Sun, 14 May 2023 15:10:17 +0200
+
 noiz2sa (0.51a-12) unstable; urgency=medium
 
   * d/control: Add Vcs fields.
diff -Nru noiz2sa-0.51a/debian/noiz2sa.maintscript 
noiz2sa-0.51a/debian/noiz2sa.maintscript
--- noiz2sa-0.51a/debian/noiz2sa.maintscript1970-01-01 01:00:00.0 
+0100
+++ noiz2sa-0.51a/debian/noiz2sa.maintscript2023-05-14 15:10:17.0 
+0200
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/noiz2sa noiz2sa-data 0.51a-13~

Bug#876626: [Xastir] Bug#876626: Xastir loose TCP/IP data afer 12 hours of use

[MLHPUB]

Hi,

I come back after too long time, sorry.
After submitting the bug, I could discuss with Tom Russo and Curt Mills 
(Xastir developers).
The problem was my configuration picking all reports Worldwide from 
APRS-IS up, overloading the software after a too long time.

A reasonable range solved the problem.

Regards,

Matthieu
F4ACU

Bug#1035654: non-essential adduser poses problems to purging packages

[Johannes Schauer Marin Rodrigues]

Hi,

here is a status update on the adduser situation.

Quoting Johannes Schauer Marin Rodrigues (2023-05-10 08:10:26)
> The remaining 14 failures belong to the following 9 source packages:
> 
> amavisd-new #1035841
> debian-edu-fai  #1035292
> desktop-autoloader  #1035291
> kismet  #1035290
> matrix-sydent   #1035844
> tcpcryptd   #1035845
> webdis  #1035435
> x2gobroker  #1035847
> x2gothinclient  #1034755
> 
> Out of these 9 remaining source packages, 5 had bugs already filed by Andreas
> Beckmann. I filed bugs with patches for the remaining 4 packages and offered
> to NMU if necessary.

amavisd-new #1035841 fixed in unstable, unblock approved, will transition 
tomorrow

debian-edu-fai #1035292, desktop-autoloader #1035291,  x2gobroker-* #1035847,
x2gothinclient #1034755 done by Mike Gabriel

kismet #1035290, matrix-sydent #1035844, tcpcryptd #1035845 not in testing (nor
stable) so no action required right now

webdis #1035435 NMU-ed to DELAYED/2

Mike, you said on IRC that you want to file the unblock bugs for
debian-edu-fai, desktop-autoloader, x2gobroker and x2gothinclient (which didn't
happen yet). If you like, I can file these for you. Just say the word. :)

Marc, the same offer to you for your recent adduser upload to unstable.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1036243: gwenview: Gwenview crashes opening certain JPEG files

[Matthieu LAPADU-HARGUES]

Package: gwenview
Version: 4:20.12.3-2
Severity: normal

Dear Maintainer,

Since a last update (I do not know which), Gwenview crashes with "old" JPEG
(before 2017).
It crashes everytime before browsing files in a folder.
Here is what is visible in terminal :

user@pc:~$ gwenview
org.kde.kdegraphics.gwenview.lib: Unresolved mime type  "image/x-mng"
org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type  "image/x-nikon-nrw"
org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type  "image/x-samsung-
srw"
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::at: __n (which is 19) >= this->size() (which is 19)
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = gwenview path = /usr/bin pid = 227715
KCrash: Arguments: /usr/bin/gwenview
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi

[2]+  Stoppé gwenview
user@pc:~$ QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 10 and type 'Read', disabling...
QSocketNotifier: Invalid socket 13 and type 'Read', disabling...
QSocketNotifier: Invalid socket 17 and type 'Read', disabling...
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
/tmp/drkonqi.lMIzOS:2: Error in sourced command file:
No symbol "s_kcrashErrorMessage" in current context.


[2]+  Stoppé gwenview

I remain available if you need more tests or a sample file.

Regards,

Matthieu


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

Kernel: Linux 5.10.0-23-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gwenview depends on:
ii  kinit  5.78.0-2
ii  kio5.78.0-5
ii  libc6  2.31-13+deb11u6
ii  libcfitsio93.490-3
ii  libexiv2-270.27.3-3+deb11u2
ii  libgcc-s1  10.2.1-6
ii  libjpeg62-turbo1:2.0.6-4
ii  libkf5activities5  5.78.0-2
ii  libkf5baloo5   5.78.0-3
ii  libkf5completion5  5.78.0-3
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5filemetadata35.78.0-2
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5itemmodels5  5.78.0-2
ii  libkf5itemviews5   5.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kdcraw5  20.12.0-1
ii  libkf5kiocore5 5.78.0-5
ii  libkf5kiofilewidgets5  5.78.0-5
ii  libkf5kiowidgets5  5.78.0-5
ii  libkf5kipi32.0.0   4:20.12.1-1
ii  libkf5notifications5   5.78.0-2
ii  libkf5parts5   5.78.0-3
ii  libkf5purpose-bin  5.78.0-2
ii  libkf5purpose5 5.78.0-2
ii  libkf5service-bin  5.78.0-2
ii  libkf5service5 5.78.0-2
ii  libkf5solid5   5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  liblcms2-2 2.12~rc1-2
ii  libphonon4qt5-44:4.11.1-4
ii  libpng16-161.6.37-3
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5printsupport55.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5x11extras5   5.15.2-2
ii  libstdc++6 10.2.1-6
ii  libtiff5   4.2.0-1+deb11u4
ii  libx11-6   2:1.7.2-1
ii  perl   5.32.1-4+deb11u2
ii  phonon4qt5 4:4.11.1-4

Versions of packages gwenview recommends:
ii  kamera 4:20.12.0-1
ii  kio-extras 4:20.12.2-1
ii  qt5-image-formats-plugins  5.15.2-2

Bug#1035435: webdis: fails to purge - command (deluser|adduser) in postrm not found

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2023-05-16 23:35:38)
> On Wed, 03 May 2023 14:45:01 +0200 Andreas Beckmann  wrote:
> > There is ongoing discussion how to handle system users on package
> > removal, see https://bugs.debian.org/621833
> > Consensus seems to be not to remove system users (to avoid reusing UIDs
> > which could grant access to the wrong files) but to "lock" them (where
> > "locking"/"unlocking" is not yet precisely defined). Until that has
> > been decided it should be sufficient to have the postrm script ignore
> > any errors from deluser:
> >   deluser ...

diff -Nru webdis-0.1.9+dfsg/debian/changelog webdis-0.1.9+dfsg/debian/changelog
--- webdis-0.1.9+dfsg/debian/changelog  2020-04-23 01:04:04.0 +0200
+++ webdis-0.1.9+dfsg/debian/changelog  2023-05-17 23:56:13.0 +0200
@@ -1,3 +1,10 @@
+webdis (0.1.9+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * ignore deluser not being available in postrm purge (closes: #1035435)
+
+ -- Johannes Schauer Marin Rodrigues   Wed, 17 May 2023 
23:56:13 +0200
+
 webdis (0.1.9+dfsg-1) unstable; urgency=medium
 
   * d/copyright: acknowledge upstream files relocation
diff -Nru webdis-0.1.9+dfsg/debian/webdis.postrm 
webdis-0.1.9+dfsg/debian/webdis.postrm
--- webdis-0.1.9+dfsg/debian/webdis.postrm  2018-08-25 09:53:40.0 
+0200
+++ webdis-0.1.9+dfsg/debian/webdis.postrm  2023-05-17 23:56:13.0 
+0200
@@ -15,7 +15,7 @@
 fi
 rm -rf $WEBDIS_LOG
 
-deluser --system webdis
+deluser --system webdis || true
 ;;
 
 *)

signature.asc
Description: signature

Bug#1036242: Subject: RFS: dmagnetic/0.37-1 -- Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art

[Thomas Dettbarn]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : dmagnetic
   Version  : 0.37-1
   Upstream contact : Thomas Dettbarn
 * URL  :https://www.dettus.net/dMagnetic/
 * License  : BSD-2-Clause
 * Vcs  : [fill in URL of packaging vcs]
   Section  : games

The source builds the following binary packages:

  dmagnetic - Interpreter to play textadventures from Magnetic Scrolls in 
glorious ANSI Art

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.37-1.dsc

Changes since the last upload:

 dmagnetic (0.37-1) unstable; urgency=medium
 .
   * Minor bugfixes
   * Reduced memory consumption
   * Better help screens

Regards,
--
  Thomas Dettbarn

Bug#1035845: tcpcryptd fails to purge without adduser

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2023-05-16 23:34:06)
> Quoting jo...@debian.org (2023-05-10 07:56:44)
> > To work around this problem, at least 125 source packages [codesearch] 
> > simply
> > ignore failures of calling the passwd or adduser tools during purge. The
> > following patch should fix this package by doing the same:
> > 
> > --%<-
> > diff -Nru tcpcrypt-0.5/debian/tcpcryptd.postrm 
> > tcpcrypt-0.5/debian/tcpcryptd.postrm
> > --- tcpcrypt-0.5/debian/tcpcryptd.postrm2016-04-01 
> > 23:45:55.0 +0200
> > +++ tcpcrypt-0.5/debian/tcpcryptd.postrm2023-05-10 
> > 07:54:45.0 +0200
> > @@ -6,7 +6,7 @@
> >  purge)
> > # add a debian-tcpcryptd user if one does not already exist
> > if getent passwd "$TCPCRYPT_USER" >/dev/null ; then
> > -deluser "$TCPCRYPT_USER"
> > +deluser "$TCPCRYPT_USER" || true
> > fi
> >  ;;
> >  esac
> > -->%-
> > 
> > If you prefer I can fix this via an NMU.
> 
> since time is running short, I am going to NMU tcpcryptd on Thursday with a
> delay of 2 days unless you disagree and/or want to do this yourself.

never mind, no urgency here, because tcpcryptd is not in testing (nor in the
current stable) and suffers from multiple RC bugs.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1035290: kismet: fails to purge - command (deluser|adduser) in postrm not found

[Johannes Schauer Marin Rodrigues]

Quoting Johannes Schauer Marin Rodrigues (2023-05-16 23:27:26)
> since time is running out, would you mind if I NMU kismet with this change
> and file the unblock request?

never mind, no urgency here, because kismet is not in testing (nor in the
current stable) and suffers from multiple RC bugs.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1034261: autofs attempts communication with portmapper (port 111) even for NFS4 mounts

[Salvatore Bonaccorso]

Hi Mike,

On Tue, May 16, 2023 at 09:33:11PM +, Mike Gabriel wrote:
> Control: severity -1 serious
> 
> On  Di 16 Mai 2023 19:20:23 CEST, Michael Kiermaier wrote:
> 
> > I consider this bug quite severe as it may break working setups after an
> > update.
> > 
> > The corresponding bug report for Ubuntu might be this one:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034261
> > 
> > It is the same bug reported on the autofs mailing list here:
> > https://www.spinics.net/lists/autofs/msg02389.html
> > Apparently, it has been introduced in the transition of autofs from
> > 5.1.7 to 5.1.8.
> > 
> > A fix has been posted here:
> > https://www.spinics.net/lists/autofs/msg02391.html
> > and again
> > https://www.spinics.net/lists/autofs/msg02434.html
> 
> I share your view on this, thus bumping severity.
> 
> The security team asked me to get the proposed patch into bookworm
> before the release.

Just to be clear about it, while I'm member of the security team, the
heads-up can be considered not with that hat on. But as both Debian
contributor and autofs user, I noticed the bug and pinged you offlist
because agreeing that this should be fixed for bookworm.

Note that the situation is bit unfortunate, there is not muc htime
left to get it in. Applying the isolated (verified) patch and asking
the release team for an unblock before 25th of May has still some
room.

> This patch will need to be applied to Debian's version of autofs:
> 
> https://mirrors.edge.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.9/autofs-5.1.8-fix-nfsv4-only-mounts-should-not-use-rpcbind.patch
> https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/commit/?id=80845bbcbc264f19c6c6a81d680e1f2b1ea6d3cc
> 
> I will work on this tomorrow.

Thank you for maintaining src:autofs!

Regards,
Salvatore

Bug#1036241: RM: tldp -- RoQA; RC-buggy; orphaned; low popcon; dead upstream

[Bastian Germann]

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

Please remove tldp. It has a long-standing RC bug which could have been 
resolved by importing a new upstream release.
The package has no reverse dependencies.

Bug#1036240: bullseye-pu: package kscreenlocker/5.20.5-1+deb11u1

[Patrick Franz]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: delta...@debian.org,debian-qt-...@lists.debian.org

[ Reason ]
When trying to unlock the screen and entering a wrong password,
it can lead to an endless loop when using the PAM module.
This fix applies a patch from upstream that fixes the
behaviour.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035732

[ Impact ]
The screen cannot be unlocked and log files get flooded.

[ Tests ]
The bug reporter confirmed that the applied patch fixes the
issue.

[ Risks ]
The risks are low. The patch comes directly from upstream and
has been applied to later versions of kscreenlocker.
In addition, only a single line in the code needs to be moved.

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

[ Changes ]

[ Other info ]
diffstat for kscreenlocker-5.20.5 kscreenlocker-5.20.5

 changelog |6 ++
 patches/auth_failure.diff |   15 +++
 patches/series|1 +
 3 files changed, 22 insertions(+)

diff -Nru kscreenlocker-5.20.5/debian/changelog 
kscreenlocker-5.20.5/debian/changelog
--- kscreenlocker-5.20.5/debian/changelog   2021-01-06 15:50:51.0 
+0100
+++ kscreenlocker-5.20.5/debian/changelog   2023-05-17 22:40:20.0 
+0200
@@ -1,3 +1,9 @@
+kscreenlocker (5.20.5-1+deb11u1) bullseye; urgency=medium
+
+  * Fix authentication error when using PAM (Closes: #1035732).
+
+ -- Patrick Franz   Wed, 17 May 2023 22:40:20 +0200
+
 kscreenlocker (5.20.5-1) unstable; urgency=medium
 
   [ Pino Toscano ]
diff -Nru kscreenlocker-5.20.5/debian/patches/auth_failure.diff 
kscreenlocker-5.20.5/debian/patches/auth_failure.diff
--- kscreenlocker-5.20.5/debian/patches/auth_failure.diff   1970-01-01 
01:00:00.0 +0100
+++ kscreenlocker-5.20.5/debian/patches/auth_failure.diff   2023-05-13 
11:24:07.0 +0200
@@ -0,0 +1,15 @@
+diff --git a/greeter/authenticator.cpp b/greeter/authenticator.cpp
+index b184e04..2dabd0f 100644
+--- a/greeter/authenticator.cpp
 b/greeter/authenticator.cpp
+@@ -281,9 +281,9 @@ void KCheckPass::handleVerify()
+ emit failed();
+ return;
+ case ConvPutAuthError:
++case ConvPutAuthAbort:
+ cantCheck();
+ return;
+-case ConvPutAuthAbort:
+ case ConvPutReadyForAuthentication:
+ m_ready = true;
+ if (m_mode == AuthenticationMode::Direct) {
diff -Nru kscreenlocker-5.20.5/debian/patches/series 
kscreenlocker-5.20.5/debian/patches/series
--- kscreenlocker-5.20.5/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ kscreenlocker-5.20.5/debian/patches/series  2023-05-13 11:21:34.0 
+0200
@@ -0,0 +1 @@
+auth_failure.diff

Bug#1036239: curl: CVE-2023-28319 CVE-2023-28320 CVE-2023-28321 CVE-2023-28322

[Salvatore Bonaccorso]

Source: curl
Version: 7.88.1-9
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for curl.

CVE-2023-28319[0]:
| UAF in SSH sha256 fingerprint check

CVE-2023-28320[1]:
| siglongjmp race condition

CVE-2023-28321[2]:
| IDN wildcard match

CVE-2023-28322[3]:
| more POST-after-PUT confusion

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28319
https://www.cve.org/CVERecord?id=CVE-2023-28319
[1] https://security-tracker.debian.org/tracker/CVE-2023-28320
https://www.cve.org/CVERecord?id=CVE-2023-28320
[2] https://security-tracker.debian.org/tracker/CVE-2023-28321
https://www.cve.org/CVERecord?id=CVE-2023-28321
[3] https://security-tracker.debian.org/tracker/CVE-2023-28322
https://www.cve.org/CVERecord?id=CVE-2023-28322

Regards,
Salvatore

Bug#1001084: ITP: meli -- terminal mail client

[Jonas Smedegaard]

0.7.2+20230517 draft 1 needs embedding 8 crates (6 missing, 1 unwanted, 1 
ahead);
runs and seems to work from a brief test use.

Main tasks are still to keep package up-to-date with upstream releases, and
to package more of the crates currently embedded.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary packages I built - then I will share those.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/meli/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Roger Lynn]

On 15/05/2023 19:00, Simon McVittie wrote:
> On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote:
>> People build things on Debian that are not Debian packages. People
>> compile binaries on Debian, and expect them to work on any system that
>> has sufficiently new libraries.
> 
> *raises hand*
> 
> Hello, I represent an example of those people. With my $work hat on,
> I'm involved in maintaining a family of Debian derivatives (the Steam
> Runtime) that is used to run Steam games on arbitrary distributions,
> including but not limited to Debian. Some of these binaries are built
> on a Debian derivative, but run on an arbitrary other distribution,
> using a RPATH[1] to find their non-glibc dependencies.

As another much smaller example, which I hope is still relevant, I have
taken binaries from Debian stable or oldstable armel and run them for
diagnostic purposes on embedded boards which only have Busybox installed and
for which I don't have a convenient build environment.

Regards,
Roger

PS Apologies if I've followed up incorrectly - I read debian-devel through
an NNTP gateway.

Bug#1035931: cjs: Please don't use mozjs78

[Jeremy Bícha]

On Wed, May 17, 2023 at 4:18 PM Bastian Germann  wrote:
> On Thu, 11 May 2023 07:24:34 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
>  wrote:
> > cjs uses mozjs78. mozjs78 is the SpiderMonkey JavaScript engine from
> > Firefox 78 ESR. Firefox 78 ESR received monthly security updates until
> > October 2021. Since mozjs78 is no longer supported, please switch to
> > mozjs102.
> >
> > This was done upstream recently in the (still unreleased) 5.7.
> >
> > https://github.com/linuxmint/cjs/commits/master
>
> This is tagged as https://github.com/linuxmint/cjs/releases/tag/master.mint21 
> so maybe this is worth importing now?
> It would be nice to get rid of the old mozjs78 with bookworm.

It is very late for a change like this to make it into Bookworm. But
if the Debian Cinnamon maintainers feel comfortable with the change,
they can talk to the Debian Release Team (and maybe the Security Team)
about it.

Thank you,
Jeremy Bícha

Bug#1036238: RFS: libnet-finger-perl/1.06-7 -- perl Module providing an API for Finger queries

[Michael Ablassmeier]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libnet-finger-perl":

 * Package name : libnet-finger-perl
   Version  : 1.06-7
   Upstream contact : Dennis Taylor, 
 * URL  : https://metacpan.org/pod/Net::Finger
 * License  : Artistic or GPL-1+
   Section  : perl

The source builds the following binary packages:

  libnet-finger-perl - perl Module providing an API for Finger queries

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

  https://mentors.debian.net/package/libnet-finger-perl/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libn/libnet-finger-perl/libnet-finger-perl_1.06-7.dsc

Changes since the last upload:

 libnet-finger-perl (1.06-7) unstable; urgency=medium
 .
   * Refresh packaging
+ don't use cdbs
+ update source format 3.0 (Closes: #1007277)
+ Update Standards-Version
+ Fix lintian warnings

Regards,
-- 
  Michael Ablassmeier

Bug#1036237: RFS: libwebservice-musicbrainz-perl/1.0.6-1 -- XML based Web service API to the MusicBrainz database

[Michael Ablassmeier]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libwebservice-musicbrainz-perl":

 * Package name : libwebservice-musicbrainz-perl
   Version  : 1.0.6-1
   Upstream contact : Bob Faist 
 * URL  : https://github.com/bfaist/webservice-musicbrainz
 * License  : Artistic or GPL-1+
   Section  : perl

The source builds the following binary packages:

  libwebservice-musicbrainz-perl - XML based Web service API to the MusicBrainz 
database

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

  https://mentors.debian.net/package/libwebservice-musicbrainz-perl/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libw/libwebservice-musicbrainz-perl/libwebservice-musicbrainz-perl_1.0.6-1.dsc

Changes since the last upload:

 libwebservice-musicbrainz-perl (1.0.6-1) unstable; urgency=medium
 .
   * New upstream release.
   * Refresh debian packaging to newest formats
   * Update Standards-Version
   * Fix various lintian warnings

Regards,
-- 
  Michael Ablassmeier

Bug#1036026: unblock: libssh/0.10.5-1

[Martin Pitt]

Control: tag -1 -moreinfo
Control: retitle -1 unblock: libssh/0.10.5-2

Hello Sebastian,

Sebastian Ramacher [2023-05-16 22:49 +0200]:
> It's too late for debhelper compat bumps. See 
> https://release.debian.org/bookworm/FAQ.html
>
> Please re-upload without that change and remove the moreinfo tag once
> that happened.

Good point. I reverted the change [1], resulting in attached debdiff. Uploaded
as libssh_0.10.5-2.dsc.

Thanks,

Martin

[1] https://salsa.debian.org/debian/libssh/-/commit/49823ffd5c9ce8
diff -Nru libssh-0.10.5/debian/changelog libssh-0.10.5/debian/changelog
--- libssh-0.10.5/debian/changelog  2023-05-10 06:00:26.0 +
+++ libssh-0.10.5/debian/changelog  2023-05-17 19:56:56.0 +
@@ -1,3 +1,10 @@
+libssh (0.10.5-2) unstable; urgency=medium
+
+  * Revert "Bump debhelper from old 12 to 13."
+This is not appropriate at this point of the release cycle any more.
+
+ -- Martin Pitt   Wed, 17 May 2023 19:56:56 +
+
 libssh (0.10.5-1) unstable; urgency=high
 
   [ Martin Pitt ]
diff -Nru libssh-0.10.5/debian/control libssh-0.10.5/debian/control
--- libssh-0.10.5/debian/control2023-05-10 06:00:26.0 +
+++ libssh-0.10.5/debian/control2023-05-17 19:56:56.0 +
@@ -4,7 +4,7 @@
 Maintainer: Laurent Bigonville 
 Uploaders: Mike Gabriel , Martin Pitt 
 Build-Depends: cmake (>= 2.8.5),
-   debhelper-compat (= 13),
+   debhelper-compat (= 12),
libcmocka-dev ,
libgcrypt-dev,
libkrb5-dev | heimdal-dev,


signature.asc
Description: PGP signature

Bug#1036231: mbedtls: please update to 3.4.0 for cmake support

[Andrea Pappacoda]

Il giorno mer 17 mag 2023 alle 20:26:52 +02:00:00, Matthias Geiger 
 ha scritto:
please update mbedtls to 3.4.0 . The 3.x release track includes the 
.cmake file

I'd need for another library I'm trying to package.


Hi Matthias, thanks for the report.

I'd love to package the 3.x branch, but there currently isn't any LTS 
release for it; the latest LTS is 2.28.x. I'm not going to package 
non-LTS versions in Debian, since they don't fit nicely with the stable 
release scheme.


If what you need for your package is just CMake dependency discovery, 
and not any library feature specific to the 3.x branch, what you could 
do instead is to patch the upstream build script to make use of a Find 
module which doesn't rely on .cmake Config files being available.


I currently do this for the yuzu package, which also depends on 
mbedtls. You can find my FindMbedTLS.cmake here: 



That file is tuned to yuzu's needs, i.e. it checks for the non-default 
CMAC support and only looks for the mbedcrypto library. If you can 
point me to the upstream project I'd be able to suggest a more 
appropriate file, or even send a patch upstream.


Thanks again for your report! I'll wait for your reply :)

Bug#1036236: ITP: cityhash -- hashing functions for strings

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, t...@debian.org, 
matthias.geiger1...@tutanota.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: cityhash
  Version : git snapshot
  Upstream Contact: Jyrki Alakuijala 
* URL : https://github.com/google/cityhash
* License : MIT
  Programming Lang: C++
  Description : hashing functions for strings

I intend to package cityhash. It's a library providing hashing functions fot 
strings.  The functions mix the
input bits thoroughly but are not suitable for cryptography. 
 This library is needed to fully devondor ppsspp. The packaging is already done 
and can be viewed at https://salsa.debian.org/debian/cityhash.
tar kindly agreed to sponsor the intial upload.

regrads,

werdahias

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmRlMrAgHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHXRNw/+Nrs52V66Y4O8
OicclBomJl+Om2+U924PQnAst4VBBW3OH2bSOZkCyZBtu/zFgbFpmQGdL4vcmu5Q
d7S9OpOmagmvy8fJumiPetmuD0VLCcN/nIxVAyG0enFeXX9ZG1Ti2Onlyhkl1mKD
E8zowrpwsLC3P3Zj5Zr/s5zW7XbnWvApCbL1Iv372eTbeneUQ2nXsoq0qjHX3RAg
CoIo/qq0oy54Y0HHGdoABjheLH7I5rl25DXVRK0ausHrAszz5wJBYEO6OHoQ4u3i
RXDjJbv+zLeHTMFB6kB00nLAhnVd8I5WVLAu7WWHCPjgmopRjxI9XUW/E9GB5ZMh
ZQlW8zOBrWlQx7EtzZRKuMKJiRluQpkuewzNwdmz9I99O50lB28lxDiKP5qngSOS
lcMs/mZasXBwpEJyPgmwmj64XbIeq3TsTKqARdbTT5RVmzGZE4n74PE7+GUKiuWz
X+i7Jbwx8Kyp1XNUM+FRZQ9JolCO2RgNsb5+tyRRJafkNRtNIQZON+N83hayYjGI
LXlAI+qIXQK01YFNctqf76T1crRywmo/sOqd+dDfGkUekWD/ohy8IUCpc4hkOaYs
ib4HHFdlANwwjRIAs6Z+eRABiQ73A9EBSISOODpEwTcDxILzjY7J6nNUbZmNSm6V
HwVAAv/VIE0MR2Q1W1N1fMPBQpAU7Z0=
=RM/7
-END PGP SIGNATURE-

Bug#1014093: ITP: vobsubocr -- subtitle converter from DVD VOB to SRT

[Jonas Smedegaard]

0.1.0 draft 2 needs embedding 21 crates (5 missing, 2 broken, 15 ahead); 
succesfully converts a set of russian subtitles.

Main tasks is still to package remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/vobsubocr/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1036235: RFP: authentication-milter -- A Perl implementation of email authentication standards rolled up into a single easy to use milter.

[Jamie McClelland]

Package: wnpp
Severity: wishlist

* Package name: authentication-milter
  Version : 3.20230214 
  Upstream Contact: Marc Bradshaw  
* URL : https://github.com/fastmail/authentication_milter 
* License : GPL 
  Programming Lang: Perl
  Description : A Perl implementation of email authentication standards 
rolled up into a single easy to use milter.

Debian currently provides opendmarc and opendkim packages. These seem to
be well-maintained by the debian maintainers, but the upstream
maintainer does not seem present (see 
https://github.com/trusteddomainproject/OpenDMARC/issues/240).

Authentication Milter seems actively maintained, and provides a single
package to handle DKIM, DMARC, SPF and more.

Most of the perl dependencies are already packaged in Debian, but a
handful would need to be added.

Bug#1036158: gcc-13: Please raise baseline for alpha to EV56

[Frank Scheiner]

Hi all,

On 17.05.23 11:27, John Paul Adrian Glaubitz wrote:

Hi Michael!

On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:

On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:

After a long discussion on IRC and the mailing list, we have agreed to raise the
baseline for the alpha architecture to EV56 to improve the generated code and 
fix
a number of issues. The change is already being implemented in the glibc 
packages
which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 
[2].

Could you raise the baseline for gcc on alpha to EV56?

I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".


Yes, please!

I suggest the following in debian/rules2:

ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
   CONFARGS += --with-cpu=ev56 --with-tune=ev6
endif

(the --with-tune only affects instruction scheduling and better tunes
code for ev6 and more recent machines, but allows execution down to
ev56.)  I have tested this in the past with a rebuild of most packages
that are in the base essential chroot in the past and it works well.


Doesn't that come with a speed penalty for EV56 machines? I'm asking because 
EV56 is
currently the baseline for QEMU when emulating Alpha.


How high will it be? I have some numbers from my PWS 500au for 7z 16.02
and openssl 3.0.7, so we could compare that later on.

With everything below EV56 dropped, I'd say let's get everything out of
the later (real) machines and use "ev67" here. Even my DS20E already
uses EV67s.

UPDATE: Reading through [1] and [2], it looks like there's no difference
between EV6 and EV67 for instruction scheduling. So fine as proposed.

[1]: https://gcc.gnu.org/onlinedocs/gcc/DEC-Alpha-Options.html
[2]:
https://uprrp2.uprrp.edu/help?key=SQLPRE72~SQLPRE_Command_Line~Arguments~ARCHITECTURE=VMS%20Help=

Cheers,
Frank

Bug#1036234: unblock: krb5/1.20.1-2

[Sam Hartman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: k...@packages.debian.org
Control: affects -1 + src:krb5

Please unblock package krb5


[ Reason ]

My fix for 1020424 was incomplete.
Even with that fix applied, you can end up installing the new crypto library 
with the old libkrb5support.
Unfortunately because of some internal changes  that can cause segfaults.
I've changed the .symbols file, and now libk5crypto depends on the new 
libkrb5support.
As a consequence the entire krb5 library upgrade from bullseye to bookworm 
needs to be done lockstep.
I try to avoid that, but apt appears to deal with it fine.


[ Impact ]
If the user mixes krb5 library versions from bullseye and bookworm they can get 
segfaults until they upgrade fully.



[ Tests ]
I've confirmed that libk5crypto3 now has tight dependencies manually.


[ Risks ]

Very minimal diff.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
diff --git a/debian/changelog b/debian/changelog
index cc56e29b95..39cc059e25 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+krb5 (1.20.1-2) unstable; urgency=medium
+
+  * Tighten dependencies on libkrb5support0.  This means that the entire
+upgrade from bullseye to bookworm needs to be lockstep, but it appears
+that's what is required, Closes: #1036055
+  
+
+ -- Sam Hartman   Mon, 15 May 2023 17:44:41 -0600
+
 krb5 (1.20.1-1) unstable; urgency=high
 
   [ Bastian Germann ]
diff --git a/debian/libkrb5support0.symbols b/debian/libkrb5support0.symbols
index 827d80898a..5c3de884f5 100644
--- a/debian/libkrb5support0.symbols
+++ b/debian/libkrb5support0.symbols
@@ -65,8 +65,8 @@ libkrb5support.so.0 libkrb5support0 #MINVER#
  k5_set_error_info_callout_fn@krb5support_0_MIT 1.12~alpha1+dfsg
  k5_siphash24@krb5support_0_MIT 1.18.2
  k5_strerror_r@krb5support_0_MIT 1.13~alpha1+dfsg
- k5_utf16le_to_utf8@krb5support_0_MIT 1.16
- k5_utf8_to_utf16le@krb5support_0_MIT 1.16
+ k5_utf16le_to_utf8@krb5support_0_MIT 1.20
+ k5_utf8_to_utf16le@krb5support_0_MIT 1.20
  k5_vset_error@krb5support_0_MIT 1.12~alpha1+dfsg
  krb5int_close_plugin@krb5support_0_MIT 1.7dfsg~beta2
  krb5int_close_plugin_dirs@krb5support_0_MIT 1.7dfsg~beta2


unblock krb5/1.20.1-2

Bug#1036233: /usr/libexec/gdm-wayland-session[…]: dbus-daemon[…]: [session uid=… pid=…] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1

[Al Ma]

Package: gdm3
Version: 3.38.2.1-1
In my journal log I see that an activated service org.freedesktop.systemd1 
failed:
Mai 17 20:37:18 AnonymizedComputerName /usr/libexec/gdm-wayland-session[1164]: 
SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry 
Mai 17 20:37:18 AnonymizedComputerName org.gnome.Shell.desktop[1038]: Window 
manager warning: Failed to parse saved session file: Datei 
»/var/lib/gdm3/.config/mutter/sessions/10b3c2ff926492598a1684348635677448000995.ms«
 konnte nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden Mai 17 
20:37:18 AnonymizedComputerName dbus-daemon[772]: [system] Successfully 
activated service 'org.freedesktop.PackageKit' Mai 17 20:37:18 
AnonymizedComputerName systemd[1]: Started PackageKit Daemon. Mai 17 20:37:18 
AnonymizedComputerName kernel: rfkill: input handler disabled Mai 17 20:37:18 
AnonymizedComputerName /usr/libexec/gdm-wayland-session[983]: dbus-daemon[983]: 
[session uid=119 pid=983] Activating service name='org.freedesktop.systemd1' 
requested by ':1.9' (uid=119 pid=1176 comm="/usr/libexec/gsd-sharing ") Mai 17 
20:37:18 AnonymizedComputerName /usr/libexec/gdm-wayland-session[983]: 
dbus-daemon[983]: [session uid=119 pid=983] Activated service 
'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with 
status 1
Failures are not good in general and make me worry (especially since my log 
shows many of them). How bad is this particular failure? Who is the culprit and 
what to do? The machine runs systemd 247.3-7+deb11u2, dbus 1.12.24-0+deb11u1, 
and gnome-settings-daemon 42.2-1 (which contains /usr/libexec/gsd-sharing).
Gratefully,
AlMa

Bug#1036232: org.gnome.Shell.desktop[…]: Window manager warning: Failed to parse saved session file:

[Al Ma]

Package: gnome-shell
Version: 42.3.1-2
In my journal I discovered a message that a saved session file could not be 
parsed:
Mai 17 20:03:28 AnonymizedComputerName org.gnome.Shell.desktop[1157]: glamor: 
No eglstream capable devices found Mai 17 20:03:28 AnonymizedComputerName 
gnome-shell[1049]: Unset XDG_SESSION_ID, getCurrentSessionProxy() called 
outside a user session. Asking logind directly. Mai 17 20:03:28 
AnonymizedComputerName gnome-shell[1049]: Will monitor session c1 Mai 17 
20:03:28 AnonymizedComputerName dbus-daemon[793]: [system] Activating via 
systemd: service name='org.freedesktop.locale1' 
unit='dbus-org.freedesktop.locale1.service' requested by ':1.35' (uid=119 
pid=1049 comm="/usr/bin/gnome-shell ") Mai 17 20:03:28 AnonymizedComputerName 
systemd[1]: Starting Locale Service... Mai 17 20:03:29 AnonymizedComputerName 
dbus-daemon[793]: [system] Successfully activated service 
'org.freedesktop.locale1' Mai 17 20:03:29 AnonymizedComputerName 
wpa_supplicant[812]: wlp179s0: CTRL-EVENT-REGDOM-CHANGE init=DRIVER 
type=COUNTRY alpha2=DE Mai 17 20:03:29 AnonymizedComputerName systemd[1]: 
Started Locale Service. Mai 17 20:03:29 AnonymizedComputerName 
/usr/libexec/gdm-wayland-session[998]: dbus-daemon[998]: [session uid=119 
pid=998] Activating service name='org.freedesktop.impl.portal.PermissionStore' 
requested by ':1.3' (uid=119 pid=1049 comm="/usr/bin/gnome-shell ") Mai 17 
20:03:29 AnonymizedComputerName NetworkManager[796]:  [1684346609.1113] 
policy: auto-activating connection 'AnonymizedWiFiName' (AnonymizedHexID) Mai 
17 20:03:29 AnonymizedComputerName NetworkManager[796]:  
[1684346609.1121] device (wlp179s0): Activation: starting connection 
'AnonymizedWiFiName' (AnonymizedHexID) Mai 17 20:03:29 AnonymizedComputerName 
NetworkManager[796]:  [1684346609.1123] device (wlp179s0): state change: 
disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Mai 17 
20:03:29 AnonymizedComputerName /usr/libexec/gdm-wayland-session[998]: 
dbus-daemon[998]: [session uid=119 pid=998] Successfully activated service 
'org.freedesktop.impl.portal.PermissionStore' Mai 17 20:03:29 
AnonymizedComputerName NetworkManager[796]:  [1684346609.1146] device 
(wlp179s0): set-hw-addr: reset MAC address to AnonymizedMACAddress (preserve) 
Mai 17 20:03:29 AnonymizedComputerName NetworkManager[796]:  
[1684346609.1155] device (wlp179s0): state change: prepare -> config (reason 
'none', sys-iface-state: 'managed') Mai 17 20:03:29 AnonymizedComputerName 
NetworkManager[796]:  [1684346609.1160] device (wlp179s0): Activation: 
(wifi) access point 'AnonymizedWiFiName' has security, but secrets are 
required. Mai 17 20:03:29 AnonymizedComputerName NetworkManager[796]:  
[1684346609.1161] device (wlp179s0): state change: config -> need-auth (reason 
'none', sys-iface-state: 'managed') Mai 17 20:03:29 AnonymizedComputerName 
NetworkManager[796]:  [1684346609.1164] 
sup-iface[db9ea4b039e47a74,0,wlp179s0]: wps: type pbc start... Mai 17 20:03:29 
AnonymizedComputerName NetworkManager[796]:  [1684346609.1289] device 
(wlp179s0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 
'managed') Mai 17 20:03:29 AnonymizedComputerName NetworkManager[796]:  
[1684346609.1296] device (wlp179s0): state change: prepare -> config (reason 
'none', sys-iface-state: 'managed') Mai 17 20:03:29 AnonymizedComputerName 
NetworkManager[796]:  [1684346609.1301] device (wlp179s0): Activation: 
(wifi) connection 'AnonymizedWiFiName' has security, and secrets exist. No new 
secrets needed. Mai 17 20:03:29 AnonymizedComputerName NetworkManager[796]: 
 [1684346609.1302] Config: added 'ssid' value 'AnonymizedWiFiName' Mai 17 
20:03:29 AnonymizedComputerName NetworkManager[796]:  [1684346609.1302] 
Config: added 'scan_ssid' value '1' Mai 17 20:03:29 AnonymizedComputerName 
NetworkManager[796]:  [1684346609.1302] Config: added 'bgscan' value 
'simple:30:-70:86400' Mai 17 20:03:29 AnonymizedComputerName 
NetworkManager[796]:  [1684346609.1303] Config: added 'key_mgmt' value 
'WPA-PSK WPA-PSK-SHA256 FT-PSK' Mai 17 20:03:29 AnonymizedComputerName 
NetworkManager[796]:  [1684346609.1303] Config: added 'auth_alg' value 
'OPEN' Mai 17 20:03:29 AnonymizedComputerName NetworkManager[796]:  
[1684346609.1303] Config: added 'psk' value '' Mai 17 20:03:29 
AnonymizedComputerName NetworkManager[796]:  [1684346609.1795] device 
(wlp179s0): supplicant interface state: disconnected -> scanning Mai 17 
20:03:29 AnonymizedComputerName NetworkManager[796]:  [1684346609.1795] 
device (p2p-dev-wlp179s0): supplicant management interface state: disconnected 
-> scanning Mai 17 20:03:29 AnonymizedComputerName dbus-daemon[793]: [system] 
Activating via systemd: service name='org.freedesktop.GeoClue2' 
unit='geoclue.service' requested by ':1.35' (uid=119 pid=1049 
comm="/usr/bin/gnome-shell ") Mai 17 20:03:29 AnonymizedComputerName 
systemd[1]: Starting Location Lookup Service... Mai 17 20:03:29 
AnonymizedComputerName polkitd(authority=local)[800]: 

Bug#1035911: [pre-approval] unblock: dpkg/1.21.22

[Guillem Jover]

Control: tags -1 - moreinfo

Hi!

On Wed, 2023-05-17 at 04:24:06 +0200, Guillem Jover wrote:
> Control: tags -1 moreinfo

Oops, missed the «-», but then that seems fine :), as earlier today I
noticed that a triggered autopkgtest for another package had failed,
so retriggered it as it looked like a transient issue, and it then
passed, so it should be actually good now.

Thanks,
Guillem

Bug#1036231: mbedtls: please update to 3.4.0 for cmake support

[Matthias Geiger]

Package: mbedtls
Severity: wishlist
X-Debbugs-Cc: matthias.geiger1...@tutanota.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

please update mbedtls to 3.4.0 . The 3.x release track includes the .cmake file
I'd need for another library I'm trying to package.

regards,

werdahias 


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

Kernel: Linux 6.3.2-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmRlHGggHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHXZHRAAu7fQZU2yxqsc
0ZTISQWZkc8DQBnFEb0Jm0Krq4n7PPbmC6RS+JhnubB5XISRbtyx6M44boa7APHM
8CooKCTQwyDwGXPAM0MeW0Wf6RNnYoZjWAPcigboIj2ntdYdcDo46AovE2BNFaw5
TkoPmV1gMPpVngZHsAO4hc6AIHHF5U7XIKCuNcg6kwGoFCYtIIuTD74ZPjZT6PU6
ysfD4VHTWc2CuUixxYhZ/z8OZjJKL8OcUZQdc020cUZ7A9t/8soxSeKUW7rnXi18
XgNPjUlV8hS3By1CHlbD6FcD+vm7L+9PwDCiTxw3OUU7MfQnke/yPn1OF3WotEck
dz+lofuYb9SuwA3Mw2EP96eHPAjPWg/GXhUobtmjXp2g4CQ370Dl9xbzbvfrJsIv
Kk1waZ3ZgIP6Xq14be/eOIqMVF6OqYNrAdUy2AXfvG6NlaqEheGXa0gjKJlVSn5s
tfM5NYLHbH3f/3GxTVnymnHbY151BJeXTAErZKS8rAPEIFqwMrTSyvM+OKLhBec4
YcyI48maM4nCq5QGQ5ouCrUQHNnPTNDGW4FVCKCcxlVmw16dL5QsVJXow1rum/46
X5MU9pYErU4r9h7miY4bupO7ZWzIwtrWYSCdIMM+Cxdt8MMBnwZARLyLIrzVT8ue
IQsXYtUqK9RCnJ/U9xHov2YyKCwmUss=
=w0ps
-END PGP SIGNATURE-

Bug#1035844: matrix-sydent fails to purge without adduser

[Johannes Schauer Marin Rodrigues]

Hi Hubert,

Quoting Hubert Chathi (2023-05-17 00:43:00)
> On Tue, 16 May 2023 23:31:16 +0200, Johannes Schauer Marin Rodrigues 
>  said:
> > since time is running short, I am going to NMU matrix-sydent on Thursday
> > with a delay of 2 days unless you disagree and/or want to do this yourself.
> Thanks for the report and the offer to fix it.  I'm not objecting to your
> NMU, but I wanted to point out that matrix-sydent isn't in testing (and
> AFAICT never has been), so it isn't holding up the release.  So I don't think
> there's any particular rush to fix this issue.  There's also another RC bug
> (https://bugs.debian.org/1029442) that would block it from migrating.

well that's even better news! Less work for me then because in that case,
closing this bug is of no urgency.

Would you like a merge request on the matrix-sydent packaging git fixing this
or will you take care of implementing this fix yourself?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1035899: (no subject)

[Al Ma]

Updating xwayland to version 2:21.1.3-1 removes this particular bug (and 
introduces others). So the package containing the program that issues the call 
with -initfd must depend on xwayland version ≥ 2:21.1.3-1. I have no idea which 
program it is or whether this has been already done upstream.

Bug#1036082: linphone: Unable to enable H.264 video codec required for Zoom SIP connections

[Petter Reinholdtsen]

[Petter Reinholdtsen]  writes:
> Nope.  It do not seem to be available in Bullseye.  I'll try with a
> Bookworm machine and see if there is greater success there.

I tested on Bookworm, and while it is different, I did not manage to
call the SIP endpoint of Zoom.

With the mediastreamer2-plugin-openh264 package installed, the H.264
option show up as enabled, and disabling and enabling it do not ask for
anything to be downloaded.  This is great.

The problem is that I try to connect it to my local Asterisk server,
which appear to not work.  I get a proxy account with the correct
settings, but linphone do not seem to reach the server.

Ignoring this, I try to enter the sip address of the Zoom room I want to
connect to, but entering it in the upper text field just pop up a 'add
contact' prompt that do not work (the 'sip address' field seem to be
write protected), and just pressing [enter] after cut-n-pasting the SIP
address just clear the field.

Cut-n-pasting the SIP address in the text field just below it also did
nothing.

In short, while H.264  might be working with Linphone in Bookworm, I
have no idea how to test it with my current setup.

Perhaps it only work when accepting the terms of the external service?

> Are you able to connect to Zoom yourself?

Would be interesting to know the answer to this question.

> Note, the majority of my issue with the current behaviour is the
> pretend to download and enable H.264 stuff, which appear to not really
> happen.  Perhaps the download code should be disabled or changed to
> suggest installing mediastreamer2-plugin-openh264?  How is this
> feature behaving in newer versions?

It behave a lot better.  I guess this issue can be seen as solved with
linphone version 5.1.65-4.  Still have not found a way to make Linphone
useful, but at least the download popup seem to be gone.

I am happy to debug some more, and am available on #debian-voip if
someone want direct contact.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1036230: scilab: Scilab shows white fill instead of plots

[Norbert]

Package: scilab
Version: 6.1.1+dfsg2-6
Severity: important
X-Debbugs-Cc: nrb...@gmail.com

Dear Maintainer,

in Debian 12 the following command

scilab -e "plot(1:100);quit;"

produces the following terminal output

```
$ scilab -e "plot(1:100);quit;"
Picked up _JAVA_OPTIONS:
-Djava.class.path=/usr/share/java/flexdock.jar:/usr/share/java/skinlf.jar:/usr/share/java/looks.jar:/usr/share/java/commons-
logging.jar:/usr/share/java/jhall.jar:/usr/share/java/lucene-
core-4.10.4.jar:/usr/share/java/lucene-analyzers-
common-4.10.4.jar:/usr/share/java/lucene-
queryparser-4.10.4.jar:/usr/share/maven-repo/org/freehep/freehep-
util/debian/freehep-util-debian.jar:/usr/share/maven-repo/org/freehep/freehep-
io/debian/freehep-io-debian.jar:/usr/share/maven-repo/org/freehep/freehep-
graphicsio/debian/freehep-graphicsio-debian.jar:/usr/share/java/freehep-
graphicsio-emf.jar:/usr/share/java/freehep-
graphics2d.jar:/usr/share/java/jrosetta-API.jar:/usr/share/java/jrosetta-
engine.jar:/usr/share/java/jgraphx.jar:/usr/share/java/jogl2.jar:/usr/share/java/gluegen2-rt.jar:/usr/share/java/jeuclid-
core.jar:/usr/share/java/jlatexmath-
fop.jar:/usr/share/java/fop.jar:/usr/share/java/saxon.jar:/usr/share/java/batik.jar:/usr/share/java/xml-
apis-ext.jar:/usr/share/java/commons-io.jar:/usr/share/java/xmlgraphics-
commons.jar:/usr/share/java/avalon-
framework.jar:/usr/share/java/jlatexmath.jar:/usr/share/java/ecj.jar:/usr/share/java/javax.activation.jar:/usr/share/java/jaxb-
runtime.jar:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar:/usr/share/scilab/modules/gui/jar/org.scilab.modules.gui.jar:/usr/share/scilab/modules/renderer/jar/org.scilab.modules.renderer.jar:/usr/share/scilab/modules/scinotes/jar/org.scilab.modules.scinotes.jar:/usr/share/scilab/modules/preferences/jar/org.scilab.modules.preferences.jar:/usr/share/scilab/modules/graph/jar/org.scilab.modules.graph.jar:/usr/share/scilab/modules/types/jar/org.scilab.modules.types.jar:/usr/share/scilab/modules/localization/jar/org.scilab.modules.localization.jar:/usr/share/scilab/modules/javasci/jar/org.scilab.modules.javasci.jar:/usr/share/scilab/modules/completion/jar/org.scilab.modules.completion.jar:/usr/share/scilab/modules/history_browser/jar/org.scilab.modules.history_browser.jar:/usr/share/scilab/modules/history_manager/jar/org.scilab.modules.history_manager.jar:/usr/share/scilab/modules/console/jar/org.scilab.modules.console.jar:/usr/share/scilab/modules/graphic_export/jar/org.scilab.modules.graphic_export.jar:/usr/share/scilab/modules/external_objects_java/tests/libintl.jar:/usr/share/scilab/modules/external_objects_java/jar/org.scilab.modules.external_objects_java.jar:/usr/share/scilab/modules/scirenderer/jar/scirenderer.jar:/usr/share/scilab/modules/ui_data/jar/org.scilab.modules.ui_data.jar:/usr/share/scilab/modules/helptools/jar/scilab_ja_JP_help.jar:/usr/share/scilab/modules/helptools/jar/scilab_en_US_help.jar:/usr/share/scilab/modules/helptools/jar/scilab_pt_BR_help.jar:/usr/share/scilab/modules/helptools/jar/scilab_images.jar:/usr/share/scilab/modules/helptools/jar/scilab_fr_FR_help.jar:/usr/share/scilab/modules/helptools/jar/org.scilab.modules.helptools.jar:/usr/share/scilab/modules/commons/jar/org.scilab.modules.commons.jar:/usr/share/scilab/modules/core/jar/org.scilab.modules.core.jar:/usr/share/scilab/modules/action_binding/jar/org.scilab.modules.action_binding.jar:/usr/share/scilab/modules/xcos/jar/org.scilab.modules.xcos.jar:/usr/share/scilab/modules/graphic_objects/jar/org.scilab.modules.graphic_objects.jar:
-Djava.library.path=/usr/lib/jni:/usr/lib/scilab --add-
opens=java.desktop/sun.awt.X11=ALL-UNNAMED --add-
opens=java.desktop/sun.java2d.opengl=ALL-UNNAMED --add-
opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED
Gtk-Message: 20:57:33.960: Failed to load module "canberra-gtk-module"
Exception in thread "AWT-EventQueue-0" com.jogamp.opengl.GLException: Caught
GLException: Profile GL4bc is not available on X11GraphicsDevice[type .x11,
connection :0.0, unitID 0, handle 0x7f449469b690, owner true,
ResourceToolkitLock[obj 0x1ef316f7, isOwner true, <1fd4bf76, 627651a1>[count 1,
qsz 0, owner ]]], but: [GLProfile[GLES1/GLES1.hw],
GLProfile[GLES2/GLES3.hw], GLProfile[GL2ES1/GLES1.hw],
GLProfile[GL4ES3/GL4.hw], GLProfile[GL2ES2/GL4.hw], GLProfile[GL4/GL4.hw],
GLProfile[GLES3/GLES3.hw], GLProfile[GL4/GL4.hw], GLProfile[GL3/GL4.hw],
GLProfile[GL2GL3/GL4.hw]]
at
com.jogamp.opengl.awt.GLJPanel$OffscreenBackend.initialize(GLJPanel.java:1795)
at
com.jogamp.opengl.awt.GLJPanel.initializeBackendImpl(GLJPanel.java:1377)
at com.jogamp.opengl.awt.GLJPanel.paintComponent(GLJPanel.java:549)
at java.desktop/javax.swing.JComponent.paint(JComponent.java:1119)
at
java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:952)
at java.desktop/javax.swing.JComponent.paint(JComponent.java:1128)
at
java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:952)
at 

Bug#1036229: unblock: fai/6.0.2

[Thomas Lange]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package fai


In a few configs and scripts the non-free-firmware section was added.
In the script mkdebmirror bullseye was replaced with bookworm.
The script 50-misc can now handle the non-free-firmware section, but
also handle older releases that do not have this section.
See changelog below.


[~]$ debdiff fai_6.0.1.dsc fai_6.0.2.dsc|diffstat
 bin/fai-mirror   |4 ++--
 conf/sources.list|6 +++---
 debian/changelog |   10 ++
 debian/fai-doc.doc-base.package  |3 ---
 debian/rules |3 ---
 doc/Makefile |7 +--
 examples/simple/scripts/LAST/50-misc |8 ++--
 utils/mkdebmirror|6 +++---
 8 files changed, 25 insertions(+), 22 deletions(-)



[ Reason ]
adding non-free-firmware is essential for the users, it's also important to 
support
older Debian releases.

[ Impact ]
(What is the impact for the user if the unblock isn't granted?)

[ Tests ]
I've review the code change and done manual tests of the new code and config.

[ Risks ]
The changes are not that big and mostly affect files in the fai-doc
package. Adding the non-free-firmware section is trivial. Also
removing the generation of postscript documentation is trivial.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock fai/6.0.2



diff -Nru fai-6.0.1/bin/fai-mirror fai-6.0.2/bin/fai-mirror
--- fai-6.0.1/bin/fai-mirror2022-09-25 12:00:17.0 +0200
+++ fai-6.0.2/bin/fai-mirror2023-05-07 16:29:11.0 +0200
@@ -365,7 +365,7 @@
 cat > $mirrordir/conf/distributions  bookworm, Closes: #1035608
+  * doc/Makefile, debian/rules,fai-doc.doc-base.package:
+do not create ps files
+
+ -- Thomas Lange   Sun, 07 May 2023 17:25:35 +0200
+
 fai (6.0.1) unstable; urgency=low
 
   [ Joerg Behrmann ]
diff -Nru fai-6.0.1/debian/fai-doc.doc-base.package 
fai-6.0.2/debian/fai-doc.doc-base.package
--- fai-6.0.1/debian/fai-doc.doc-base.package   2012-05-02 23:05:48.0 
+0200
+++ fai-6.0.2/debian/fai-doc.doc-base.package   2023-05-07 16:56:59.0 
+0200
@@ -5,9 +5,6 @@
  Debian GNU/Linux.
 Section: Debian
 
-Format: postscript
-Files: /usr/share/doc/fai-doc/fai-guide.ps.gz
-
 Format: text
 Files: /usr/share/doc/fai-doc/fai-guide.text.gz
 
diff -Nru fai-6.0.1/debian/rules fai-6.0.2/debian/rules
--- fai-6.0.1/debian/rules  2021-05-01 22:23:53.0 +0200
+++ fai-6.0.2/debian/rules  2023-05-07 16:56:59.0 +0200
@@ -15,9 +15,6 @@
 override_dh_installdocs:
dh_installdocs -Nfai-server -Nfai-quickstart
sed -i 's/FAIVERSIONSTRING/$(VERSIONSTRING)/' 
debian/fai-client/usr/share/doc/fai-client/README
-   # Remove embedded temporary directory for reproducible builds
-   sed -i -e 's,/tmp/tmp.*/fai-guide.ps,fai-guide.ps,g' 
debian/fai-doc/usr/share/doc/fai-doc/fai-guide.ps
-   sed -i -e 's,/tmp/tmp.*/fai-guide.dvi,fai-guide.dvi,g' 
debian/fai-doc/usr/share/doc/fai-doc/fai-guide.ps
 
 override_dh_installchangelogs:
dh_installchangelogs -Nfai-server -Nfai-quickstart
diff -Nru fai-6.0.1/doc/Makefile fai-6.0.2/doc/Makefile
--- fai-6.0.1/doc/Makefile  2022-10-06 19:06:21.0 +0200
+++ fai-6.0.2/doc/Makefile  2023-05-07 16:29:11.0 +0200
@@ -6,7 +6,7 @@
 OPT = --dblatex-opts "-P latex.output.revhistory=0"
 
 
-free:  text html ps pdf
+free:  text html pdf
 #  echo "`grep -c FIXME $(DOC).txt` FIXMEs left to fix:"
 #  grep FIXME $(DOC).txt
 
@@ -21,11 +21,6 @@
a2x $(OPT) -L --icons -a toc -a toclevels=3 -f pdf $(DOC).txt
rm -f $(DOC).xml $(DOC).fo
 
-.NOTPARALLEL:  ps
-ps: $(DOC).txt images
-   a2x $(OPT) -L --icons -a toc -a toclevels=3 -f ps $(DOC).txt
-   rm -f $(DOC).xml 

Bug#1036227: bookworm-pu: package r-cran-shiny/1.7.4+dfsg-3~deb12u1

[Andreas Tille]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: r-cran-sh...@packages.debian.org, 1035...@bugs.debian.org, 
debia...@lists.debian.org
Control: affects -1 + src:r-cran-shiny

I'd like to announce an upload to testing-proposed-updates

[ Reason ]
As discussed on the mailing list debian-release@l.d.o[1] the
accidental upload of r-base prevents r-cran-shiny from migrating
to testing since it has some failing tests due to the r-base
version conflict.  Thus an upload to testing-proposed-updates
seems an appropriate solution for this and this bug report is
about asking you for confirmation about this solution.

[ Impact ]
R-cran-shiny has an RC bug and is in danger to be not released
with bookworm.  It has quite some dependencies that would be
affected.

[ Tests ]
There is just a fixed symlink in the upload to fix the RC bug.
All tests are passing as usual.

[ Risks ]
The change to the package is minimal.

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

[ Changes ]

I propose to upload the following change to t-p-u:

$ git diff HEAD^
diff --git a/debian/changelog b/debian/changelog
index 21d12c3..a2b6c26 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+r-cran-shiny (1.7.4+dfsg-3~deb12u1) bookworm; urgency=medium
+
+  * Upload to testing-proposed-updates "bookworm" due to the fact that
+there was an accidental upload of a new version of r-base to unstable
+
+ -- Andreas Tille   Wed, 17 May 2023 07:56:25 +0200
+
 r-cran-shiny (1.7.4+dfsg-3) unstable; urgency=medium


Nilesh Patra suggested to use version 1.7.4+dfsg-2+deb12u1 but I
personally regard my version suggestion more logical (long explanation
given in [2]).


[ Other info ]

Please confirm that I should upload to t-p-u (and raise your opinion
about the most sensible version in your eyes).

Kind regards and thanks for working as release team
   Andreas.


[1] https://lists.debian.org/debian-release/2023/05/msg00623.html

Bug#1036226: ITP: libe131 -- library for the E1.31 (sACN) protocol

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, matthias.geiger1...@tutanota.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libe131
  Version : 1.4.0
  Upstream Contact: Hugo Hromic 
* URL : https://github.com/hhromic/libe131.git
* License : Apache-2.0
  Programming Lang: C
  Description : library for the  E1.31 (sACN) protocol

I intend to package libe131. It's one of the libraries needed to 
devendor Openrgb. Fron the description: 

>This is a lightweight C/C++ library that provides a simple API for packet, 
> client and server programming to be used for communicating with devices
> implementing the E1.31 (sACN) protocol. 

This protocol is appearantly used to control lighting devices.

The packaging is already done and can be viewed at 
https://salsa.debian.org/debian/libe131.

I'd need a sponsor for the initial upload.

regards,

werdahias

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmRlElkgHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHWYRhAArw/wFDMZ+5cw
UenwvAYy3Qnx5GRsnARooxAtF6yRUW3i/U06XnMSh06LAosqUItdqgWi+7hJuLlD
a50ZqSu4MrfSkFT3pCSTDXn9a6hmOBVSKaMTB8TCaUmFUV5tuF1f4rvMq7bXC61r
zbRsZYexWxeOafqSxC4AhiCEpD/SnnN0IGoQceVRD63jOxnNtAFXx88sQiQZu/he
6gvI4dEONXrtLS7LaK/+lIGSmX2tEmz5SMEJuvKJnxSso7WKZYbLblzMmhCp2Wti
oXsNr2uQL5z8zkdH4XzTohshB8jn7jjKDaAujPj/58D++GwiS8levmU+6TjXf7HR
IQwCv6yZ1tbcu1cYywHWjTbC0YwimBY6y8J7Jw8O63jWEzDj3sHroyCfXdrXPlj2
wxSTcvMzCvSWtoIFM0O51CKyGimh3935x7jsZmWg0VZOsEKWYmPD96DQ8ONFxAF/
brQaTZeH+Cr1F33pRpX3yXofEs7qJHwsbQcOKnHI6p8dqdQQzA8C91m0jby+Gz5D
WsmAEjfzHwkKWppjmRtKCz4kvL6cnnYgioS1caxGH8NiLN/Zbvi1RfZKV4oR18zZ
3ZBJ7AQBG0g5fdd3TvVi/nyC//MnAStz2ut3PooQgB9lXdchYjrG1Lj5eoRTIoIn
iHr2LFIuNIFhvopq0oE8jaznHRYuKQk=
=/256
-END PGP SIGNATURE-

Bug#940960: ITP: linenoise -- Minimal replacement for readline

[Jeremy Sowden]

On 2023-05-14, at 15:00:06 +0800, Blair Noctis wrote:
> On 2023/5/14 03:24, Jeremy Sowden wrote:
> > I came across linenoise because of a request to support it in nftables.
> > The request came from someone who wanted to install nftables in a
> > resource-constrained environment where the existing libreadline support
> > was too heavyweight.  In the case of osquery, would it possible to go
> > the other way?  Do you think that upstream would be open to adding
> > support for libreadline if we offered patches?
> 
> Feasible on the resource level I think, it links to many libraries anyway. But
> for using readline… they actually switched away from it in 2016:
> https://github.com/osquery/osquery/pull/2613
> 
> Considering their rather radical approach of vendoring everything, I don't 
> have
> too much hope for that.

Ah, right.  So much for that idea!

It occurs to me that it might make more sense for you to take the lead
in packaging linenoise since you have an interest in getting it into
Debian.  Would you like me to transfer ownership of the ITP bug to you?
Happy to lend a hand if you need one.

J.


signature.asc
Description: PGP signature

Bug#1036225: unblock: ibus-pinyin/1.5.0-10

[Gunnar Hjalmarsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-input-met...@lists.debian.org
Control: affects -1 + src:ibus-pinyin

Please unblock package ibus-pinyin.

[ Reason ]

https://bugs.debian.org/1036197 pointed out that a python file includes 
a gettext API which was removed in python3.10. When fixing that I also 
noticed that the Gtk version was not specified, which it needs to be on 
systems where gtk4 is present.


These issues have been fixed in ibus-pinyin 1.5.0-10 through two small 
patches.


[ Impact ]

Without the mentioned patches, the user can't open the Preferences 
window, which significantly reduces the usability of the package.


[ Tests ]

Manually installed the binary built by version 1.5.0-10 of the 
ibus-pinyin source, and confirmed that the issues were fixed as expected.


[ Risks ]

The fixes are standard python3 fixes, and should have been done long 
ago. Can't see any risk for adverse side effects.


[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

--
Cheers,
Gunnar Hjalmarssondiff --git a/debian/changelog b/debian/changelog
index e163562..67e8e68 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+ibus-pinyin (1.5.0-10) unstable; urgency=medium
+
+  * Team upload
+  * Upload to unstable
+
+ -- Gunnar Hjalmarsson   Wed, 17 May 2023 19:14:23 +0200
+
+ibus-pinyin (1.5.0-9) experimental; urgency=medium
+
+  * Team upload
+  * Fix removed python gettext API (closes: #1036197, LP: #2019921)
+  * Bump Standards-Version to 4.6.2
+  * Specify Gtk version (LP: #2019921)
+
+ -- Gunnar Hjalmarsson   Wed, 17 May 2023 08:17:28 +0200
+
 ibus-pinyin (1.5.0-8) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index 2a49cc4..630f00a 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Build-Depends:
  python3-dev,
  sqlite3,
  uuid-dev,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Homepage: https://github.com/ibus/ibus-pinyin
 Vcs-Git: https://salsa.debian.org/input-method-team/ibus-pinyin.git
 Vcs-Browser: https://salsa.debian.org/input-method-team/ibus-pinyin
diff --git a/debian/patches/Fix-removed-python-gettext-API.patch 
b/debian/patches/Fix-removed-python-gettext-API.patch
new file mode 100644
index 000..f800cd0
--- /dev/null
+++ b/debian/patches/Fix-removed-python-gettext-API.patch
@@ -0,0 +1,28 @@
+From: znwu 
+Date: Sun, 7 May 2023 18:17:11 -0700
+Subject: Fix removed python gettext API
+
+Origin: https://github.com/ibus/ibus-pinyin/commit/e2e10c40
+Bug-Debian: https://bugs.debian.org/1036197
+---
+ setup/main.py | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/setup/main.py b/setup/main.py
+index 3c13c4c..3f153a5 100644
+--- a/setup/main.py
 b/setup/main.py
+@@ -45,7 +45,12 @@ def __init__(self, engine):
+ locale.setlocale(locale.LC_ALL, "")
+ localedir = os.getenv("IBUS_LOCALEDIR")
+ gettext.bindtextdomain("ibus-pinyin", localedir)
+-gettext.bind_textdomain_codeset("ibus-pinyin", "UTF-8")
++# Python's gettext module doesn't provide all methods in
++# new Python version since Python 3.10
++try:
++gettext.bind_textdomain_codeset("ibus-pinyin", "UTF-8")
++except AttributeError:
++pass
+ 
+ self.__bus = IBus.Bus()
+ self.__config = self.__bus.get_config()
diff --git a/debian/patches/Specify-Gtk-version.patch 
b/debian/patches/Specify-Gtk-version.patch
new file mode 100644
index 000..925aaf0
--- /dev/null
+++ b/debian/patches/Specify-Gtk-version.patch
@@ -0,0 +1,15 @@
+Description: Specify Gtk version
+Author: Gunnar Hjalmarsson 
+Applied-Upstream: https://github.com/ibus/ibus-pinyin/commit/61677008
+
+--- a/setup/main.py
 b/setup/main.py
+@@ -27,6 +27,8 @@
+ import os
+ import sys
+ 
++from gi import require_version
++require_version ('Gtk', '3.0')
+ from gi.repository import GLib
+ from gi.repository import Gtk
+ from gi.repository import IBus
diff --git a/debian/patches/series b/debian/patches/series
index d467c09..c483696 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -15,3 +15,6 @@ ibus-pinyin-default-full.patch
 # python3 support
 python3.patch
 lua-5.4.patch
+
+Fix-removed-python-gettext-API.patch
+Specify-Gtk-version.patch

Bug#1036224: cups-filters: CVE-2023-24805

[Salvatore Bonaccorso]

Source: cups-filters
Version: 1.28.17-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cups-filters.

CVE-2023-24805[0]:
| RCE in cups-filters, beh CUPS backend

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-24805
https://www.cve.org/CVERecord?id=CVE-2023-24805
[1] https://www.openwall.com/lists/oss-security/2023/05/17/5
[2] https://github.com/OpenPrinting/cups-filters/commit/93e60d3df35

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

On 17/05/2023 at 16:47, Peter Ehlert wrote:

On May 17, 2023 5:48:14 AM Pascal Hambourg  wrote:


The proposed patch has not been accepted yet so is not applied to RC3.


Thanks, I was not aware of that.


If you are still willing to test it I can send you instructions.


Yes, I would like to try.
Instructions need to be simple. This is obviously new to me.


1. Copy the attached patched grub-installer onto a second USB drive 
formatted with FAT, ext* or any filesystem type the installer can read.


2. Start the installer (expert install recommended).

3. Between the steps "Load installer components from installation media" 
and "Install the GRUB boot loader", switch to a shell with Ctrl+Alt+F2.


4. Connect and mount the second USB drive seen as /dev/sdXY :
# mount -r /dev/sdXY /mnt

5. Copy the file (check the executable permission is preserved):
# cp /mnt/grub-installer /usr/bin/grub-installer

6. Unmount and disconnect the USB drive:
# umount /mnt

7. Switch back to the installer with Alt+F1 if text or Alt+F5 if 
graphic, and resume the installation.#! /bin/sh

# export DEBCONF_DEBUG=5
set -e
. /usr/share/debconf/confmodule
#set -x

if [ "$1" ]; then
ROOT="$1"
chroot=chroot
else
ROOT=
chroot=
fi

. /usr/share/grub-installer/functions.sh
. /usr/share/grub-installer/otheros.sh

newline="
"

db_capb backup

log() {
logger -t grub-installer "$@"
}

error() {
log "error: $@"
}

info() {
log "info: $@"
}

debug () {
[ -z "${DEBCONF_DEBUG}" ] || log "debug: $@"
}

ARCH="$(archdetect)"
info "architecture: $ARCH"
SUBARCH="${ARCH#*/}"

# XXX cjwatson 2019-03-25: This is all far too complicated and fragile, and
# should be replaced with in-target or similar.

# Ensure proc is mounted in all the $chroot calls;
# needed for RAID+LVM for example
initial_proc_contents="$(ls $ROOT/proc)"
if [ -z "$initial_proc_contents" ]; then
info "Mounting /proc into $ROOT"
if [ "$(udpkg --print-os)" = "kfreebsd" ]; then
mount -t linprocfs proc $ROOT/proc
elif [ "$(udpkg --print-os)" = "hurd" ]; then
mount -t proc none $ROOT/proc
else
mount -t proc proc $ROOT/proc
fi
fi

# On Linux, we need /run in the chroot to work around
# https://bugs.debian.org/918590.
if [ "$(udpkg --print-os)" = "linux" ] && [ ! -d "$ROOT/run/udev" ]; then
mount --bind /run $ROOT/run
fi

get_serial_console() {
# Get the last 'console=' entry (if none, the whole string is returned)
local defconsole="$(sed -e 's/.*\(console=[^ ]*\).*/\1/' /proc/cmdline)"
if echo "$defconsole" | grep -qe 'console=\(ttyS\|com\)'; then
echo "$defconsole"
fi
}

grub_serial_console() {
#$1=output of get_serial_console
local serconsole=${1##console=ttyS}
serconsole=${serconsole##console=com}
local unit=${serconsole%%,*}
local options=""
if echo $serconsole | grep -q ","; then
options=${serconsole##*,}
fi
local speed=$(echo "$options" | sed -e 's/^\([0-9]*\).*$/\1/')
# Take optional 1st (parity) and 2nd (word) characters after speed
options=${options##${speed}}
local parity=$(echo $options | sed 's/^\(.\?\).*$/\1/')
local word=$(echo $options | sed 's/^.\?\(.\?\).*$/\1/')
if [ -z "$speed" ]; then
speed="9600"
fi
case "$parity" in 
n) parity="--parity=no" ;;
e) parity="--parity=even" ;;
o) parity="--parity=odd" ;;
*) parity="" ;;
esac
if [ "$word" ]; then
word="--word=$word"
fi

echo serial --unit=$unit --speed=$speed $word $parity --stop=1
}

serial="$(get_serial_console)"

grub_probe () {
if [ "$is_grub_common_installed" != true ]; then
apt-install grub-common
is_grub_common_installed=true
fi
$chroot $ROOT grub-probe $@
}

# Usage: convert os_device
# Convert an OS device to the corresponding GRUB drive
convert () {
tmp_drive="$(grub_probe -d -t drive "$1")" || exit $?
if [ "$partition_offset" != 0 ]; then
tmp_part="$(echo "$tmp_drive" | sed 's%.*,\([0-9]*\)).*%\1%')"
if [ "$tmp_part" ] && [ "$tmp_part" != "$tmp_drive" ]; then
tmp_drive="$(echo "$tmp_drive" | sed 
"s%\(.*,\)[0-9]*\().*\)%\1`expr $tmp_part - $partition_offset`\2%")"
fi
fi
echo "$tmp_drive"
}

# Convert a linux non-devfs disk device name into the hurd's syntax
hurd_convert () {
dr_type=$(expr "$1" : '.*\([hs]d\)[a-h][0-9]*')
dr_letter=$(expr "$1" : '.*d\([a-h]\)[0-9]*')
dr_part=$(expr "$1" : '.*d[a-h]\([0-9]*\)')
case "$dr_letter" in
a) dr_num=0 ;;
b) dr_num=1 ;;
c) dr_num=2 ;;
d) dr_num=3 ;;
e) dr_num=4 ;;
f) 

Bug#1036223: RFP: alsa-scarlett-gui -- alsa-scarlett-gui is a Gtk4 GUI for the ALSA controls presented by the Linux kernel Focusrite Scarlett Gen 2/3 Mixer Driver.

[Thomas Mayer]

Package: wnpp
Severity: wishlist

* Package name: alsa-scarlett-gui
  Version : 0.2-7-g65c0
  Upstream Contact: Geoffrey D. Bennett 
* URL : https://github.com/geoffreybennett/alsa-scarlett-gui
* License : GPL
  Programming Lang: C
  Description : alsa-scarlett-gui is a Gtk4 GUI for the ALSA controls 
presented by the Linux kernel Focusrite Scarlett Gen 2/3 Mixer Driver.

The Focusrite Scarlett (and Clarett+) interfaces are class compliant USB audio 
interfaces meaning that they work “out of the box” on Linux as audio and MIDI 
interfaces (although on Gen 3 you need to disable MSD mode first). However, the 
Gen 2 6i6+, Gen 3 4i4+, and Clarett+ interfaces have a bunch of proprietary 
functionality that required a kernel driver to be written specifically for 
those devices.

Linux kernel support (“ALSA Focusrite Scarlett Gen 2/3 Mixer Driver”) for the 
proprietary functionality of Gen 2 devices was first added in 5.4, Gen 3 
devices in 5.14, and Clarett+ 8Pre is coming in 6.1.

Unfortunately, actually using this functionality used to be quite an awful 
experience. The existing applications like alsamixer and qasmixer become 
completely user-hostile with the hundreds of controls presented for the Gen 3 
18i20. Even the smallest Gen 3 4i4 interface at last count had 84 ALSA controls.

Bug#1036222: extrepo-offline-data: Element GPG key is expired

[Celejar]

Package: extrepo-offline-data
Version: 1.0.3
Severity: normal

When extrepo's element repo is enabled, 'apt update' throws the
following error:

~# apt update

...

Err:3 https://packages.element.io/debian bullseye InRelease
  The following signatures were invalid: EXPKEYSIG C2850B265AC085BD riot.im 
packages 
Reading package lists... Done
W: GPG error: https://packages.element.io/debian bullseye InRelease: The 
following signatures were invalid: EXPKEYSIG C2850B265AC085BD riot.im packages 

E: The repository 'https://packages.riot.im/debian bullseye InRelease' is not 
signed.
N: Updating from such a repository can't be done securely, and is therefore 
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration 
details.

See here:
https://github.com/vector-im/element-desktop/issues/807

Following upstream's directions to add the key and repo manually works
fine:
https://element.io/download#linux

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

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

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

-- no debconf information

Bug#1034378: Allow Percentage Formatting in apt

[Emir SARI]

(Re-sending, since my previous message formatting got messed-up)

Hello,

> 16 May 2023 tarihinde 16:41 itibarıyla David Kalnischkies 
>  şunu yazdı:
> 
> The first hunk seems wrong as our 'strprintf' 'prints to a std::string'
> given as first argument and doesn't return anything. Meantime, your
> change also uses std::printf which means it would print directly to
> stdout, which this code shouldn't do either.

Oops, silly mistake. Should be fine with the new patch.

> In general, I suppose the formatting currently is "Progress: [ 42%]" so
> "Progress: [ %42]" is your target?

Yes, correct.

> I think we could go with a "%d%%" string for all (four) cases (which is
> my other remark) and assemble the individual strings with e.g.
> "Progress: [%s]". The code could format a "%100" first to establish the
> maximum length and prepend spaces as needed for the real value.


I left the other three as-is for now, since it would probably require
casts ortype changes from int to double etc. Feel free to correct me
though. I amnew to C-like languages.

> Oh, and one more thing: Comments in code meant for translators are per
> convention prefixed with: "TRANSLATORS: " (see existing usages) and
> should try a little harder to convey what a string is used for,
> meanwhile a "localize according to your locale settings" could be
> said about each and every string…

Done.

Best regards,
Emir
From 4e7e0db117990e9469295934b0c7462e8c11255f Mon Sep 17 00:00:00 2001
From: Emir SARI 
Date: Fri, 5 May 2023 18:58:03 +0300
Subject: [PATCH] Apply i18n to percentage display

Languages like Turkish and French (and some other more), use a
custom percentage format, other than the standard 100%. Allowing
i18n to these values, make the apt interface a lot coherent with
the rest of the output, since they mostly appear next to translated
strings.

This commit also fixes the issue of "Progress: [100%]" to have
extra blank characters when the percentage sign is prepended to the
number; e.g. "Progress: [  %1]". Previously, it output [%  1] due
to the absolute placeholder format.
---
 apt-pkg/install-progress.cc | 12 +++-
 apt-private/acqprogress.cc  |  9 ++---
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/apt-pkg/install-progress.cc b/apt-pkg/install-progress.cc
index c7f7573..8378200 100644
--- a/apt-pkg/install-progress.cc
+++ b/apt-pkg/install-progress.cc
@@ -56,7 +56,17 @@ bool PackageManager::StatusChanged(std::string /*PackageName*/,
 {
int reporting_steps = _config->FindI("DpkgPM::Reporting-Steps", 1);
percentage = StepsDone/(double)TotalSteps * 100.0;
-   strprintf(progress_str, _("Progress: [%3li%%]"), std::lround(percentage));
+
+   std::string percent_str;
+   // TRANSLATORS: Percentage value; %d is the number, %% is the sign
+   strprintf(percent_str, _("%d%%"), std::lround(percentage));
+
+   if (percentage < 10)
+  percent_str.insert(0, "  ");
+   else if (percentage < 100)
+  percent_str.insert(0, " ");
+
+   strprintf(progress_str, _("Progress: [%s]"), percent_str.c_str());
 
if(percentage < (last_reported_progress + reporting_steps))
   return false;
diff --git a/apt-private/acqprogress.cc b/apt-private/acqprogress.cc
index fa7edfc..f54d732 100644
--- a/apt-private/acqprogress.cc
+++ b/apt-private/acqprogress.cc
@@ -232,9 +232,11 @@ bool AcqTextStatus::Pulse(pkgAcquire *Owner)
 	 if (I->CurrentItem->TotalSize > 0 && I->CurrentItem->Owner->Complete == false)
 	 {
 	if (Mode == Short)
-	   ioprintf(S, " %.0f%%", (I->CurrentItem->CurrentSize*100.0)/I->CurrentItem->TotalSize);
+   // TRANSLATORS: Percentage value; %0.f is the number, %% is the sign
+	   ioprintf(S, _(" %.0f%%"), (I->CurrentItem->CurrentSize*100.0)/I->CurrentItem->TotalSize);
 	else
-	   ioprintf(S, "/%sB %.0f%%", SizeToStr(I->CurrentItem->TotalSize).c_str(),
+// TRANSLATORS: Percentage value; %0.f is the number, %% is the sign
+	   ioprintf(S, _("/%sB %.0f%%"), SizeToStr(I->CurrentItem->TotalSize).c_str(),
 		 (I->CurrentItem->CurrentSize*100.0)/I->CurrentItem->TotalSize);
 	 }
 	 S << "]";
@@ -249,7 +251,8 @@ bool AcqTextStatus::Pulse(pkgAcquire *Owner)
// Put in the percent done
{
   std::stringstream S;
-  ioprintf(S, "%.0f%%", Percent);
+  // TRANSLATORS: Percentage value; %0.f is the number, %% is the sign
+  ioprintf(S, _("%.0f%%"), Percent);
   S << Line;
   Line = S.str();
   S.clear();
-- 
2.34.1

Bug#1034378: Allow Percentage Formatting in apt

[Emir SARI]

Hello,I will attach a new version while I still have some time and waitingfor account approval.16 May 2023 tarihinde 16:41 itibarıyla David Kalnischkies  şunu yazdı:The first hunk seems wrong as our 'strprintf' 'prints to a std::string'given as first argument and doesn't return anything. Meantime, yourchange also uses std::printf which means it would print directly tostdout, which this code shouldn't do either.Oops, silly mistake. Should be fine with the new patch.In general, I suppose the formatting currently is "Progress: [ 42%]" so"Progress: [ %42]" is your target?Yes, correct.I think we could go with a "%d%%" string for all (four) cases (which ismy other remark) and assemble the individual strings with e.g."Progress: [%s]". The code could format a "%100" first to establish themaximum length and prepend spaces as needed for the real value.I left the other three as-is for now, since it would probably require casts ortype changes from int to double etc. Feel free to correct me though. I amnew to C-like languages.Oh, and one more thing: Comments in code meant for translators are perconvention prefixed with: "TRANSLATORS: " (see existing usages) andshould try a little harder to convey what a string is used for,meanwhile a "localize according to your locale settings" could besaid about each and every string…Done.Best regards,EmirFrom 4e7e0db117990e9469295934b0c7462e8c11255f Mon Sep 17 00:00:00 2001
From: Emir SARI 
Date: Fri, 5 May 2023 18:58:03 +0300
Subject: [PATCH] Apply i18n to percentage display

Languages like Turkish and French (and some other more), use a
custom percentage format, other than the standard 100%. Allowing
i18n to these values, make the apt interface a lot coherent with
the rest of the output, since they mostly appear next to translated
strings.

This commit also fixes the issue of "Progress: [100%]" to have
extra blank characters when the percentage sign is prepended to the
number; e.g. "Progress: [  %1]". Previously, it output [%  1] due
to the absolute placeholder format.
---
 apt-pkg/install-progress.cc | 12 +++-
 apt-private/acqprogress.cc  |  9 ++---
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/apt-pkg/install-progress.cc b/apt-pkg/install-progress.cc
index c7f7573..8378200 100644
--- a/apt-pkg/install-progress.cc
+++ b/apt-pkg/install-progress.cc
@@ -56,7 +56,17 @@ bool PackageManager::StatusChanged(std::string /*PackageName*/,
 {
int reporting_steps = _config->FindI("DpkgPM::Reporting-Steps", 1);
percentage = StepsDone/(double)TotalSteps * 100.0;
-   strprintf(progress_str, _("Progress: [%3li%%]"), std::lround(percentage));
+
+   std::string percent_str;
+   // TRANSLATORS: Percentage value; %d is the number, %% is the sign
+   strprintf(percent_str, _("%d%%"), std::lround(percentage));
+
+   if (percentage < 10)
+  percent_str.insert(0, "  ");
+   else if (percentage < 100)
+  percent_str.insert(0, " ");
+
+   strprintf(progress_str, _("Progress: [%s]"), percent_str.c_str());
 
if(percentage < (last_reported_progress + reporting_steps))
   return false;
diff --git a/apt-private/acqprogress.cc b/apt-private/acqprogress.cc
index fa7edfc..f54d732 100644
--- a/apt-private/acqprogress.cc
+++ b/apt-private/acqprogress.cc
@@ -232,9 +232,11 @@ bool AcqTextStatus::Pulse(pkgAcquire *Owner)
 	 if (I->CurrentItem->TotalSize > 0 && I->CurrentItem->Owner->Complete == false)
 	 {
 	if (Mode == Short)
-	   ioprintf(S, " %.0f%%", (I->CurrentItem->CurrentSize*100.0)/I->CurrentItem->TotalSize);
+   // TRANSLATORS: Percentage value; %0.f is the number, %% is the sign
+	   ioprintf(S, _(" %.0f%%"), (I->CurrentItem->CurrentSize*100.0)/I->CurrentItem->TotalSize);
 	else
-	   ioprintf(S, "/%sB %.0f%%", SizeToStr(I->CurrentItem->TotalSize).c_str(),
+// TRANSLATORS: Percentage value; %0.f is the number, %% is the sign
+	   ioprintf(S, _("/%sB %.0f%%"), SizeToStr(I->CurrentItem->TotalSize).c_str(),
 		 (I->CurrentItem->CurrentSize*100.0)/I->CurrentItem->TotalSize);
 	 }
 	 S << "]";
@@ -249,7 +251,8 @@ bool AcqTextStatus::Pulse(pkgAcquire *Owner)
// Put in the percent done
{
   std::stringstream S;
-  ioprintf(S, "%.0f%%", Percent);
+  // TRANSLATORS: Percentage value; %0.f is the number, %% is the sign
+  ioprintf(S, _("%.0f%%"), Percent);
   S << Line;
   Line = S.str();
   S.clear();
-- 
2.34.1

Bug#1004961: libwmf: please fix cross-test on i386

[Andreas Metzler]

On 2023-05-17 Gianfranco Costamagna  wrote:
> control: tags -1 patch pending

> Hello, this debdiff will be uploaded in unstable once the current one 
> migrates.


Hello Gianfranco,

looks like you accidentally closed this bug instead of tagging it.

cu Andreas

Bug#1036221: mfem: please make the build reproducible

[Chris Lamb]

Source: mfem
Version: 4.5.2+ds-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
mfem could not be built reproducibly.

This was because it embedded the absolute build path in various .cmake
and C++ header/configuration files. As the paths these files reference
do not need to exist at runtime, it is safe to replace them with a
static alternative, which is what the attached patch does.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2023-05-17 08:25:54.810285060 -0700
--- b/debian/rules  2023-05-17 09:06:24.996983917 -0700
@@ -59,6 +59,7 @@
sed -i 
"s,/.*/lib/.*/libmfem.so.4.5.2,/usr/lib/x86_64-linux-gnu/libmfem.so.4.5.2,g" 
debian/libmfem-dev/usr/lib/cmake/mfem/MFEMTargets-*.cmake
 # one day someone will fix the -ffile-prefix-map
sed -i "s,/.*/lib/.*x86_64-linux-gnu,/usr/lib/x86_64-linux-gnu,g" 
debian/libmfem-dev/usr/lib/cmake/mfem/MFEMConfig.cmake
+   sed -i "s,$(CURDIR),/tmp/builddir/mfem,g" 
debian/libmfem-dev/usr/lib/cmake/mfem/MFEMConfig.cmake 
debian/libmfem-dev/usr/include/mfem/config/_config.hpp
 
 override_dh_auto_test:
@echo skipping test

Bug#1036220: refnx: please make the build reproducible

[Chris Lamb]

Source: refnx
Version: 0.1.33-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
refnx could not be built reproducibly.

This is because the PDF documentation includes the date via
\date{\today}}. A patch is attached that uses FORCE_SOURCE_DATE=1 to
make this use the value of SOURCE_DATE_EPOCH instead of the current
build date.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2023-05-17 08:25:37.906258599 -0700
--- b/debian/rules  2023-05-17 08:30:04.930630993 -0700
@@ -3,6 +3,7 @@
 # This file was automatically generated by stdeb 0.10.0 at
 # Fri, 14 Apr 2023 16:57:18 +0200
 export PYBUILD_NAME=refnx
+export FORCE_SOURCE_DATE=1
 %:
dh $@ --with python3 --buildsystem=pybuild
 

Bug#1036215: installation-reports: PXE netboot x86_64 libvirt guest on aarch64 host

[Cyril Brulebois]

Hi!

Emanuele Rocca  (2023-05-17):
> This report is about the successful installation of Bookworm on a x86_64 guest
> running on a aarch64 host. The guest was installed with virt-manager using PXE
> boot and UEFI Secure Boot enabled. Everything went smoothly except:
> 
> (A) some troubles with the UEFI PXE boot device to choose

Oh, wow. I'm skipping this as I still have some GRUB/OVMF debugging on
my own to finish. :)

> (B) failure to load the grub splash screen
> 
> (A)
> At VM startup I've entered the UEFI firmware and booted selecting the first
> PXEv4 option, see [0].
> 
> Choosing the first one *seemed* to work fine, but it ended up in a Secure Boot
> error (see [1]). Disabling Secure Boot did not fix the problem, I still got a
> "Invalid Parameter" error. It eventually became clear that I had to boot with
> [2] instead. I'm not really sure what the difference between the two may be,
> and if this is an issue in the Tianocore firmware.
> 
> At any rate, [2] worked fine with and without Secure Boot enabled. I went on
> with a preseeded installation, which finished uneventfully.
> 
> I then noticed the following errors in the libvirtd logs on the host (B):
> 
>  sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/isolinux/splash.png not 
> found for 192.168.122.7
>  sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/splash.png not found for 
> 192.168.122.7
> 
> The grub.cfg file under /debian-installer/amd64/grub/grub.cfg has the 
> following
> conditionals:
> 
>  if background_image /isolinux/splash.png; then
> [...]
>  elif background_image /splash.png; then
> 
> The splash screen is loaded correctly replacing either of those with
> /debian-installer/amd64/boot-screens/splash.png instead.

Adding an extra conditional in there really doesn't seem appropriate at
this point. Seeing how images/netboot/ is 745M, and how splash.png is
58K, I think I'd rather have it duplicated in a way that it's found in
/splash.png for both text and gtk installers (/isolinux/splash.png could
would be a weird location given the booting happens via GRUB).

Two words of caution though:

(1) Many archs, many builds for each, make sure not to break any when
tweaking the code. :) That being said, it should be seen via daily
builds, and worst case it happens on the buildds after uploading
debian-installer, and I need to either revert or fix on the spot and
re-upload an hour later.

(2) We should make sure the possible duplication doesn't interfere with
debian-installer--netboot-'s co-installability. It looks
like each of them uses a separate  top-level directory
anyway, but I thought I'd mention it anyway.

debian-installer-12-netboot-amd64: 
/usr/lib/debian-installer/images/12/amd64/gtk/pxelinux.0
debian-installer-12-netboot-amd64: 
/usr/lib/debian-installer/images/12/amd64/gtk/pxelinux.cfg

debian-installer-12-netboot-amd64: 
/usr/lib/debian-installer/images/12/amd64/text/pxelinux.0
debian-installer-12-netboot-amd64: 
/usr/lib/debian-installer/images/12/amd64/text/pxelinux.cfg


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


signature.asc
Description: PGP signature

Bug#1036219: Build tests are currently disabled

[Sebastien Bacher]

Package: libmysofa
Version: 1.3.1~dfsg0-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

The build tests are currently disabled and have been since the package 
was added but they seem to work correctly nowadays (tested in a Debian 
container and on Ubuntu builders[1]). The attached patch enable those


Cheers,
Sébastien

[1] https://launchpad.net/ubuntu/+source/libmysofa/1.3.1~dfsg0-1ubuntu1

diff -Nru libmysofa-1.3.1~dfsg0/debian/changelog libmysofa-1.3.1~dfsg0/debian/changelog
--- libmysofa-1.3.1~dfsg0/debian/changelog	2022-10-15 22:04:48.0 +0200
+++ libmysofa-1.3.1~dfsg0/debian/changelog	2023-05-17 11:36:35.0 +0200
@@ -1,3 +1,13 @@
+libmysofa (1.3.1~dfsg0-2) UNRELEASED; urgency=medium
+
+  * debian/control, debian/rules:
+- enable build tests
+  * debian/patches/debian_ignore_tests.patch:
+- ignore tests that require .sofa files which are excluded from the dfsg
+  tarball.
+
+ -- Sebastien Bacher   Wed, 17 May 2023 11:36:35 +0200
+
 libmysofa (1.3.1~dfsg0-1) unstable; urgency=medium
 
   * New upstream version 1.3.1~dfsg0
diff -Nru libmysofa-1.3.1~dfsg0/debian/control libmysofa-1.3.1~dfsg0/debian/control
--- libmysofa-1.3.1~dfsg0/debian/control	2022-10-15 22:04:48.0 +0200
+++ libmysofa-1.3.1~dfsg0/debian/control	2023-05-17 11:36:35.0 +0200
@@ -1,12 +1,14 @@
 Source: libmysofa
 Priority: optional
-Maintainer: Debian Multimedia Maintainers 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Multimedia Maintainers 
 Uploaders:
  IOhannes m zmölnig (Debian/GNU) ,
 Build-Depends:
  cmake,
  debhelper-compat (= 13),
  libcunit1-dev,
+ nodejs ,
  zlib1g-dev | libz-dev,
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
diff -Nru libmysofa-1.3.1~dfsg0/debian/patches/series libmysofa-1.3.1~dfsg0/debian/patches/series
--- libmysofa-1.3.1~dfsg0/debian/patches/series	2022-10-15 22:04:48.0 +0200
+++ libmysofa-1.3.1~dfsg0/debian/patches/series	2023-05-17 11:36:35.0 +0200
@@ -1 +1,2 @@
 dynamically-link-tools.patch
+debian_ignore_tests.patch
diff -Nru libmysofa-1.3.1~dfsg0/debian/patches/debian_ignore_tests.patch libmysofa-1.3.1~dfsg0/debian/patches/debian_ignore_tests.patch
--- libmysofa-1.3.1~dfsg0/debian/patches/debian_ignore_tests.patch	1970-01-01 01:00:00.0 +0100
+++ libmysofa-1.3.1~dfsg0/debian/patches/debian_ignore_tests.patch	2023-05-17 11:36:35.0 +0200
@@ -0,0 +1,27 @@
+# Description: ignore tests which depend on non dfsg files that Debian
+# is removing from the tarball
+# Upstream: not-needed
+Index: libmysofa-1.3.1~dfsg0/CMakeLists.txt
+===
+--- libmysofa-1.3.1~dfsg0.orig/CMakeLists.txt	2022-10-04 18:31:49.0 +0200
 libmysofa-1.3.1~dfsg0/CMakeLists.txt	2023-05-17 15:38:45.843397388 +0200
+@@ -57,8 +57,6 @@
+${PROJECT_SOURCE_DIR}/tests/Mesh2HRTF.sofa)
+   add_test(D1_48K_24bit_0.3s_FIR_SOFA src/mysofa2json
+${PROJECT_SOURCE_DIR}/tests/D1_48K_24bit_0.3s_FIR_SOFA.sofa)
+-  add_test(H20_44K_16bit_256tap_FIR_SOFA ${PROJECT_SOURCE_DIR}/tests/compareIgnoreNew.sh
+-   ${PROJECT_SOURCE_DIR}/tests/H20_44K_16bit_256tap_FIR_SOFA)
+   add_test(MIT_KEMAR_large_pinna ${PROJECT_SOURCE_DIR}/tests/compare.sh
+${PROJECT_SOURCE_DIR}/tests/MIT_KEMAR_large_pinna)
+   add_test(MIT_KEMAR_normal_pinna ${PROJECT_SOURCE_DIR}/tests/compareIgnoreNew.sh
+@@ -104,10 +102,6 @@
+${PROJECT_SOURCE_DIR}/tests/LISTEN_1002_IRC_1002_C_HRIR)
+   add_test(Pulse ${PROJECT_SOURCE_DIR}/tests/compare.sh ${PROJECT_SOURCE_DIR}/tests/Pulse)
+   add_test(Tester ${PROJECT_SOURCE_DIR}/tests/compare.sh ${PROJECT_SOURCE_DIR}/tests/tester)
+-  add_test(TU-Berlin_QU_KEMAR_anechoic_radius_0.5_1_2_3_m ${PROJECT_SOURCE_DIR}/tests/compare.sh
+-   ${PROJECT_SOURCE_DIR}/tests/TU-Berlin_QU_KEMAR_anechoic_radius_0.5_1_2_3_m)
+-  add_test(TU-Berlin_QU_KEMAR_anechoic_radius_0.5m ${PROJECT_SOURCE_DIR}/tests/compare.sh
+-   ${PROJECT_SOURCE_DIR}/tests/TU-Berlin_QU_KEMAR_anechoic_radius_0.5m)
+   add_test(example_dummy_sofa48 ${PROJECT_SOURCE_DIR}/tests/compare.sh
+${PROJECT_SOURCE_DIR}/tests/example_dummy_sofa48)
+   add_test(TestSOFA48_netcdf472 ${PROJECT_SOURCE_DIR}/tests/compare.sh
diff -Nru libmysofa-1.3.1~dfsg0/debian/rules libmysofa-1.3.1~dfsg0/debian/rules
--- libmysofa-1.3.1~dfsg0/debian/rules	2022-10-15 22:04:48.0 +0200
+++ libmysofa-1.3.1~dfsg0/debian/rules	2023-05-17 11:36:35.0 +0200
@@ -13,8 +13,9 @@
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 
+# the tests have hardcoded reference to build/src
 %:
-	dh $@
+	dh $@ --builddirectory=build
 
 override_dh_auto_configure:
 	dh_auto_configure -- \
@@ -23,9 +24,9 @@
 		-DCODE_COVERAGE=OFF \
 		$(empty)
 
+# no-parallel otherwise we are hitting test errors
 override_dh_auto_test:
-	# tests have been disabled, until we figure out how to make them not stall
-	@echo "skipping tests"
+	dh_auto_test 

Bug#1035096: GRUB not installed or installed to the wrong device

[Peter Ehlert]

On May 17, 2023 5:48:14 AM Pascal Hambourg  wrote:


On 17/05/2023 at 14:24, Peter Ehlert wrote:


On 5/7/23 13:18, Pascal Hambourg wrote:


Attached is a minimal patch which uses grub-installer/bootdev only
when if was manually set by the user, and not when the bootdev was set
by select_bootdev. I tested it with the last case. Test and feedback
appreciated.


Identical bug in RC 3 (debian-bookworm-DI-rc3-amd64-netinst.iso)


The proposed patch has not been accepted yet so is not applied to RC3.

Thanks, I was not aware of that.

If you are still willing to test it I can send you instructions.

Yes, I would like to try.
Instructions need to be simple. This is obviously new to me.
Thanks for the assistance



I can create a new installation-report if desired


This is not necessary, the bug report is not closed.

Bug#1036218: Could I request a rebase of the yuzu Debian bookworm package?

[Andrea Pappacoda]

Package: yuzu
Version: 0-1335+ds-1
Severity: important

Hi Eric, thanks for your interest in the yuzu package!

Il giorno mer 17 mag 2023 alle 12:02:45 +01:00:00, Eric Curtin 
 ha scritto:

Apparently there's been a significant performance recently:

https://tech4gamers.com/yuzu-performance-boost/

It's also segfaulting and crashing on my machine as soon as I start
the game, I'm using a arm64 Chromebook to run the Debian bookworm yuzu
package.


Debian bookworm is currently in hard freeze[1], meaning that I cannot 
update the yuzu package to include new features or performance 
improvements, but I can only make small changes and bug fixes. This 
means that no, I cannot update the yuzu package to its latest, faster, 
version, but I can try to fix your segfaults and crashes on arm64.


Could you please share more details about your crashes? What's the 
oldest working version that works for you?


You can find all the releases on the yuzu-mainline GitHub page: 



Please also check that a manual vcpkg build (from source) of version 
1335 works for you, to make sure that this isn't an issue specific to 
the Debian packaging.


Thanks for your report!

[1]: https://release.debian.org/bookworm/freeze_policy.html

Bug#1036217: mirror submission for mirror.blue3.com.br

[Samir Hanna Verza]

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

Submission-Type: new
Site: mirror.blue3.com.br
Type: leaf
Archive-architecture: amd64 arm64 armhf i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Samir Hanna Verza 
Country: BR Brazil
Location: Porto Alegre,RS
Sponsor: BLUE3 https://blue3.com.br
Comment: mirror.blue3.com.br/debian




Trace Url: http://mirror.blue3.com.br/debian/project/trace/
Trace Url: http://mirror.blue3.com.br/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.blue3.com.br/debian/project/trace/mirror.blue3.com.br

Bug#1036216: mirror submission for mirror.blue3.com.br

[Samir Hanna Verza]

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

Submission-Type: new
Site: mirror.blue3.com.br
Type: leaf
Archive-architecture: amd64 arm64 armhf i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Samir Hanna Verza 
Country: BR Brazil
Location: Porto Alegre,RS
Sponsor: BLUE3 https://blue3.com.br
Comment: mirror.blue3.com.br/debian




Trace Url: http://mirror.blue3.com.br/debian/project/trace/
Trace Url: http://mirror.blue3.com.br/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.blue3.com.br/debian/project/trace/mirror.blue3.com.br

Bug#1036215: installation-reports: PXE netboot x86_64 libvirt guest on aarch64 host

[Emanuele Rocca]

Package: installation-reports

Boot method: PXE netboot
Image version: netboot.tar.gz from 
https://deb.debian.org/debian/dists/testing/main/installer-amd64/20230515/images/netboot/

Machine: QEMU TCG x86_64 libvirt guest on aarch64 host

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

This report is about the successful installation of Bookworm on a x86_64 guest
running on a aarch64 host. The guest was installed with virt-manager using PXE
boot and UEFI Secure Boot enabled. Everything went smoothly except:

(A) some troubles with the UEFI PXE boot device to choose
(B) failure to load the grub splash screen

(A)
At VM startup I've entered the UEFI firmware and booted selecting the first
PXEv4 option, see [0].

Choosing the first one *seemed* to work fine, but it ended up in a Secure Boot
error (see [1]). Disabling Secure Boot did not fix the problem, I still got a
"Invalid Parameter" error. It eventually became clear that I had to boot with
[2] instead. I'm not really sure what the difference between the two may be,
and if this is an issue in the Tianocore firmware.

At any rate, [2] worked fine with and without Secure Boot enabled. I went on
with a preseeded installation, which finished uneventfully.

I then noticed the following errors in the libvirtd logs on the host (B):

 sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/isolinux/splash.png not 
found for 192.168.122.7
 sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/splash.png not found for 
192.168.122.7

The grub.cfg file under /debian-installer/amd64/grub/grub.cfg has the following
conditionals:

 if background_image /isolinux/splash.png; then
[...]
 elif background_image /splash.png; then

The splash screen is loaded correctly replacing either of those with
/debian-installer/amd64/boot-screens/splash.png instead.

[0] https://people.debian.org/~ema/RC3-x86_64-uefi-firmware.png
[1] https://people.debian.org/~ema/RC3-x86_64-uefi-firmware-sb-error.png
[2] https://people.debian.org/~ema/RC3-x86_64-uefi-firmware-right-entry.png

PS:

To test PXE boot with libvirt I've edited the default network with:

 $ sudo virsh net-edit default

Here's what the  part looks like:



  
  

I've untarred netboot.tar.gz under /srv/tftp/bookworm/.

After editing the network, I re-created it with:

 $ sudo virsh net-destroy default && sudo virsh net-start default

Although I'm not 100% sure it was necessary, I've also restarted libvirt and
shot a couple of dnsmasq processes that seemed to want to stick around: 

 $ sudo systemctl stop libvirtd && sudo pkill dnsmasq && sudo systemctl start 
libvirtd

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

On 17/05/2023 at 14:24, Peter Ehlert wrote:


On 5/7/23 13:18, Pascal Hambourg wrote:


Attached is a minimal patch which uses grub-installer/bootdev only 
when if was manually set by the user, and not when the bootdev was set 
by select_bootdev. I tested it with the last case. Test and feedback 
appreciated.


Identical bug in RC 3 (debian-bookworm-DI-rc3-amd64-netinst.iso)


The proposed patch has not been accepted yet so is not applied to RC3.
If you are still willing to test it I can send you instructions.


I can create a new installation-report if desired


This is not necessary, the bug report is not closed.

Bug#1035096: GRUB not installed or installed to the wrong device

[Peter Ehlert]

On 5/7/23 13:18, Pascal Hambourg wrote:

Control: retitle -1 GRUB not installed or installed to the wrong device

I found that grub-installer may generate a wrong bootdev value for 
grub-pc when state=2 and previous_state!=1. This may happen at least 
in the following three cases if the user selects the device in the 
proposed list:


- if the first device listed by grub-mkdevicemap is the installation 
media (/cdrom or /hd-media) or has no known partition table nor 
filesystem, GRUB may be installed to the disk containing /boot instead 
of the device selected by the user;


- if unsupported OS are detected by os-prober, bootdev may be empty 
and GRUB is not installed;


- if the user answers "no" to "Install the GRUB boot loader to your 
primary drive?", bootdev may be empty and GRUB is not installed.


It does not happen if the user chose "Enter the device manually".

The common root cause is grub-installer/bootdev being used without 
being manually set by the user even after bootdev was set by 
select_bootdev.


Attached is a minimal patch which uses grub-installer/bootdev only 
when if was manually set by the user, and not when the bootdev was set 
by select_bootdev. I tested it with the last case. Test and feedback 
appreciated.

Identical bug in RC 3 (debian-bookworm-DI-rc3-amd64-netinst.iso)
I can create a new installation-report if desired

Bug#1036212: visualvm: Version 2.1.5 doesn't work with Java 17

[Markus Koschany]

Am Mittwoch, dem 17.05.2023 um 12:24 +0200 schrieb david:
> Package: visualvm
> Version: Version 2.1.5 doesn't work with Java 17
> Severity: normal
> 
> Dear Maintainer,
> 
> I have installed visualvm with Java 17 configured. The app doesn't work in
> its
> installed version. Trying 2.1.6, downloaded from visualvm web page, it works
> without problem. Can we have this last version, please?

visualvm 2.1.5 works with Java 17


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

Bug#1036214: Tracking gets confused by using copysrc on binnmu'ed packages

[Christoph Berg]

Package: reprepro
Version: 5.3.0-1.2
Severity: normal

Hi,

we are using reprepro for apt.postgresql.org. It's been running very
stable over the past years, so thanks for that.

The workflow is that every distribution exists twice:
  sid-pgdg sid-pgdg-testing
  bullseye-pgdg bullseye-pgdg-testing
  ...
Uploaded packages go into *-pgdg-testing (reprepro processincoming on
.changes files) and after inspection that everything still works as
expected, they get copied over to *-pgdg:
  reprepro copysrc sid-pgdg sid-pgdg-testing postgresql-foo

(This works even in the presence of binary cruft, PostgreSQL extension
packages are compiled per PG major version. Once some PG version NN
goes out of support, src:postgresql-foo will no longer build
bin:postgresql-NN-foo, but we keep them around in the repo as long as
they are still installable.)

Ever since, I've seen warnings from reprepro that the tracking
database was missing references when copysrc'ing a new version into a
distribution when the previous version in there had been binnmued. But
since everything worked as expected, I didn't pay attention.

Now I have been inspecting the pool directory more closely, and I
found a lot of +b1.deb files that should long have been removed since
they were replaced by newer versions, e.g.:

postgresql-11_11.5-3.pgdg110+1+b1_amd64.deb <-- old
postgresql-11_11.20-1.pgdg110+1_amd64.deb   <-- current

The old version is not listed by "reprepro ls postgresql-11".

It is reported by "reprepro reportcruft bullseye-pgdg":
  binaries-without-source bullseye-pgdg postgresql-10 10.10-2.pgdg110+1+b1
But since that list also includes "proper" cruft (binaries that are no
longer built from a source package) that we want to keep, this isn't
the best command to find these.

What works is to use removetrack:

$ reprepro --verbose removetrack bullseye-pgdg postgresql-11 11.5-3.pgdg110+1+b1
Removed postgresql-11_11.5-3.pgdg110+1+b1 from bullseye-pgdg.
Deleting files no longer referenced...
deleting and forgetting 
pool/main/p/postgresql-11/postgresql-11-dbgsym_11.5-3.pgdg110+1+b1_amd64.deb
deleting and forgetting 
pool/main/p/postgresql-11/postgresql-11-dbgsym_11.5-3.pgdg110+1+b1_ppc64el.deb
...

The problem seems to never happen on *-pgdg-testing (which gets filled
by processincoming), only on *-pgdg (which gets filled by copysrc), so
I suspect the problem to be in that area.

Christoph

Bug#1036213: apache2: frequent SIGSEGV in mod_http2.so (purge_consumed_buckets)

[Stefan Eissing]

Sorry to hear about this. I think the recent change that could be relevant here 
is
the addition of:

h2_mplx.c#515:c1_purge_streams(m);

as seen in Apache httpd trunk and at https://github.com/icing/mod_h2.

This is intended to assure that streams and their requests are destroyed
in the right order when the connection is shut down.

Connection shutdown can happen at any time during request processing and
this makes it hard to reproduce issues in test cases. We have load tests
with well-behaving clients. Tests with mis-behaving ones are the tricky part.

It would be helpful if you could try 
https://github.com/icing/mod_h2/releases/tag/v2.0.15 
on your system, to see how that is faring.

Kind Regards,
Stefan

> Am 17.05.2023 um 12:24 schrieb Bastien Durel :
> 
> Package: apache2
> Version: 2.4.56-1~deb11u2
> Severity: important
> 
> Dear Maintainer,
> 
> I see many segmentation faults in apache2, for exemple in the last 24h I got:
> 
> Tue 2023-05-16 13:40:59 CEST 7757403333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 13:52:44 CEST 7983293333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 16:15:46 CEST 8107093333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 16:28:55 CEST 8174833333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 17:59:23 CEST 8231293333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 18:35:50 CEST 8269743333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 18:44:15 CEST 8319743333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 18:44:56 CEST 8361743333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 18:54:56 CEST 8226183333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 21:12:28 CEST 8362463333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 21:21:10 CEST 8539593333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 22:04:42 CEST 8587493333  11 present   
> /usr/sbin/apache2
> Tue 2023-05-16 23:26:09 CEST 8666103333  11 present   
> /usr/sbin/apache2
> Wed 2023-05-17 00:08:42 CEST 8659683333  11 present   
> /usr/sbin/apache2
> Wed 2023-05-17 00:24:04 CEST 8748073333  11 present   
> /usr/sbin/apache2
> Wed 2023-05-17 00:47:25 CEST 8786753333  11 present   
> /usr/sbin/apache2
> Wed 2023-05-17 01:42:14 CEST 8775803333  11 present   
> /usr/sbin/apache2
> Wed 2023-05-17 09:21:02 CEST 9497813333  11 present   
> /usr/sbin/apache2
> Wed 2023-05-17 09:50:49 CEST 9547843333  11 present   
> /usr/sbin/apache2
> 
> All crashes I looked into are at the same function: purge_consumed_buckets at 
> h2_bucket_beam.c:159
> 
> Here is the output of the "bt full" command from the core:
> 
> #0  0x7ffb03778981 in purge_consumed_buckets 
> (beam=beam@entry=0x7ffae452c0a0) at h2_bucket_beam.c:159
>b = 0x7ffae45ea108
> #1  0x7ffb03778aaf in beam_shutdown (how=APR_SHUTDOWN_READWRITE, 
> beam=) at h2_bucket_beam.c:258
> No locals.
> #2  beam_shutdown (how=APR_SHUTDOWN_READWRITE, beam=0x7ffae452c0a0) at 
> h2_bucket_beam.c:242
> No locals.
> #3  beam_cleanup (data=0x7ffae452c0a0) at h2_bucket_beam.c:265
>beam = 0x7ffae452c0a0
> #4  0x7ffb03e6780e in run_cleanups (cref=0x7ffae452c098) at 
> ./memory/unix/apr_pools.c:2629
>c = 
>c = 
> #5  apr_pool_destroy (pool=0x7ffae452c028) at ./memory/unix/apr_pools.c:987
>active = 
>allocator = 
> #6  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae4530028) at 
> ./memory/unix/apr_pools.c:997
>active = 
>allocator = 
> #7  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae4551028) at 
> ./memory/unix/apr_pools.c:997
>active = 
>allocator = 
> #8  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae45a1028) at 
> ./memory/unix/apr_pools.c:997
>active = 
>allocator = 
> #9  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae4606028) at 
> ./memory/unix/apr_pools.c:997
>active = 
>allocator = 
> #10 0x7ffb037914c5 in h2_session_pre_close (session=0x7ffae46060a0, 
> async=) at h2_session.c:1988
>status = 0
> #11 0x7ffb0377b745 in h2_c1_pre_close (ctx=, c= out>) at h2_c1.c:180
>status = 
>conn_ctx = 
> #12 0x56438478c9b0 in ap_run_pre_close_connection 
> (c=c@entry=0x7ffae4614360) at connection.c:44
>pHook = 
>n = 0
>rv = 0
> #13 0x56438478cade in ap_prep_lingering_close (c=0x7ffae4614360) at 
> connection.c:101
> No locals.
> #14 ap_start_lingering_close (c=0x7ffae4614360) at connection.c:127
>csd = 0x7ffae46140b0
> #15 0x7ffb03b08abe in process_lingering_close (cs=0x7ffae46142b0) at 
> event.c:1500
>csd = 0x7ffae46140b0
>dummybuf = 
> "\027\003\003\000\023\067\020\251\027\003\215Re\345\310{\f8\312X\332N\310\375",
>  '\000' ...
>nbytes = 0
>rv = 
>q = 
> #16 0x7ffb03b0a512 in process_socket (thd=thd@entry=0x7ffb037345c8, 
> p=, 

Bug#1036213: apache2: frequent SIGSEGV in mod_http2.so (purge_consumed_buckets)

[Bastien Durel]

Package: apache2
Version: 2.4.56-1~deb11u2
Severity: important

Dear Maintainer,

I see many segmentation faults in apache2, for exemple in the last 24h I got:

Tue 2023-05-16 13:40:59 CEST 7757403333  11 present   /usr/sbin/apache2
Tue 2023-05-16 13:52:44 CEST 7983293333  11 present   /usr/sbin/apache2
Tue 2023-05-16 16:15:46 CEST 8107093333  11 present   /usr/sbin/apache2
Tue 2023-05-16 16:28:55 CEST 8174833333  11 present   /usr/sbin/apache2
Tue 2023-05-16 17:59:23 CEST 8231293333  11 present   /usr/sbin/apache2
Tue 2023-05-16 18:35:50 CEST 8269743333  11 present   /usr/sbin/apache2
Tue 2023-05-16 18:44:15 CEST 8319743333  11 present   /usr/sbin/apache2
Tue 2023-05-16 18:44:56 CEST 8361743333  11 present   /usr/sbin/apache2
Tue 2023-05-16 18:54:56 CEST 8226183333  11 present   /usr/sbin/apache2
Tue 2023-05-16 21:12:28 CEST 8362463333  11 present   /usr/sbin/apache2
Tue 2023-05-16 21:21:10 CEST 8539593333  11 present   /usr/sbin/apache2
Tue 2023-05-16 22:04:42 CEST 8587493333  11 present   /usr/sbin/apache2
Tue 2023-05-16 23:26:09 CEST 8666103333  11 present   /usr/sbin/apache2
Wed 2023-05-17 00:08:42 CEST 8659683333  11 present   /usr/sbin/apache2
Wed 2023-05-17 00:24:04 CEST 8748073333  11 present   /usr/sbin/apache2
Wed 2023-05-17 00:47:25 CEST 8786753333  11 present   /usr/sbin/apache2
Wed 2023-05-17 01:42:14 CEST 8775803333  11 present   /usr/sbin/apache2
Wed 2023-05-17 09:21:02 CEST 9497813333  11 present   /usr/sbin/apache2
Wed 2023-05-17 09:50:49 CEST 9547843333  11 present   /usr/sbin/apache2

All crashes I looked into are at the same function: purge_consumed_buckets at 
h2_bucket_beam.c:159

Here is the output of the "bt full" command from the core:

#0  0x7ffb03778981 in purge_consumed_buckets 
(beam=beam@entry=0x7ffae452c0a0) at h2_bucket_beam.c:159
b = 0x7ffae45ea108
#1  0x7ffb03778aaf in beam_shutdown (how=APR_SHUTDOWN_READWRITE, 
beam=) at h2_bucket_beam.c:258
No locals.
#2  beam_shutdown (how=APR_SHUTDOWN_READWRITE, beam=0x7ffae452c0a0) at 
h2_bucket_beam.c:242
No locals.
#3  beam_cleanup (data=0x7ffae452c0a0) at h2_bucket_beam.c:265
beam = 0x7ffae452c0a0
#4  0x7ffb03e6780e in run_cleanups (cref=0x7ffae452c098) at 
./memory/unix/apr_pools.c:2629
c = 
c = 
#5  apr_pool_destroy (pool=0x7ffae452c028) at ./memory/unix/apr_pools.c:987
active = 
allocator = 
#6  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae4530028) at 
./memory/unix/apr_pools.c:997
active = 
allocator = 
#7  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae4551028) at 
./memory/unix/apr_pools.c:997
active = 
allocator = 
#8  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae45a1028) at 
./memory/unix/apr_pools.c:997
active = 
allocator = 
#9  0x7ffb03e6782d in apr_pool_destroy (pool=0x7ffae4606028) at 
./memory/unix/apr_pools.c:997
active = 
allocator = 
#10 0x7ffb037914c5 in h2_session_pre_close (session=0x7ffae46060a0, 
async=) at h2_session.c:1988
status = 0
#11 0x7ffb0377b745 in h2_c1_pre_close (ctx=, c=) at h2_c1.c:180
status = 
conn_ctx = 
#12 0x56438478c9b0 in ap_run_pre_close_connection 
(c=c@entry=0x7ffae4614360) at connection.c:44
pHook = 
n = 0
rv = 0
#13 0x56438478cade in ap_prep_lingering_close (c=0x7ffae4614360) at 
connection.c:101
No locals.
#14 ap_start_lingering_close (c=0x7ffae4614360) at connection.c:127
csd = 0x7ffae46140b0
#15 0x7ffb03b08abe in process_lingering_close (cs=0x7ffae46142b0) at 
event.c:1500
csd = 0x7ffae46140b0
dummybuf = 
"\027\003\003\000\023\067\020\251\027\003\215Re\345\310{\f8\312X\332N\310\375", 
'\000' ...
nbytes = 0
rv = 
q = 
#16 0x7ffb03b0a512 in process_socket (thd=thd@entry=0x7ffb037345c8, 
p=, sock=, cs=, 
my_child_num=my_child_num@entry=3, my_thread_num=my_thread_num@entry=16) at 
event.c:1238
c = 
conn_id = 
clogging = 
rv = 
rc = 
#17 0x7ffb03b0b125 in worker_thread (thd=0x7ffb037345c8, dummy=) at event.c:2199
csd = 0x7ffae46140b0
cs = 0x7ffae46142b0
te = 0x0
ptrans = 0x0
ti = 
process_slot = -855667096
thread_slot = 16
rv = 
is_idle = 0
#18 0x7ffb03e2aea7 in start_thread (arg=) at 
pthread_create.c:477
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140715157853952, 
-1517716079030320448, 140715846122926, 140715846122927, 140715157852032, 
8396800, 1520638580441989824, 1520521782042673856}, mask_was_saved = 0}}, priv 
= {pad = {0x0, 
  0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 
0}}}
not_first_call = 0
#19 0x7ffb03d4aa2f in clone () at 

Bug#1036212: visualvm: Version 2.1.5 doesn't work with Java 17

[david]

Package: visualvm
Version: Version 2.1.5 doesn't work with Java 17
Severity: normal

Dear Maintainer,

I have installed visualvm with Java 17 configured. The app doesn't work in its
installed version. Trying 2.1.6, downloaded from visualvm web page, it works
without problem. Can we have this last version, please?

Thanks.

-- 
David

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
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 visualvm depends on:
pn  default-jdk | java11-sdk  
pn  libnb-platform18-java 
pn  libvisualvm-jni   

visualvm recommends no packages.

visualvm suggests no packages.

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Cyril Brulebois]

Control: tag -1 - patch

Hi,

Thanks for the proposed patch but as discussed elsewhere it seemed too
risky to force 32 bpp on everyone, so I went for what looked like the
least risky (adding bochs.ko and cirrus.ko, manually and for the time
being).

Ben Hutchings  (2023-05-14):
> I think the problem is this GRUB has native drivers for Bochs and
> Cirrus that reprogram the framebuffer bit depth, and the kernel is then
> confused about what the bit depth is supposed to be.  With QXL, GRUB
> doesn't have a native driver so it doesn't reconfigure the framebuffer.

I've spent some time trying to reproduce these issues under UEFI but
without Secure Boot, and I failed. So I've moved to learning how to sign
a Linux kernel (certutil, pesign, mokutil, etc.), and I've added some
debugging information in various places.

Under Secure Boot, with the default QEMU driver (std aka. bochs),
initialization happens via:

drivers/firmware/efi/libstub/x86-stub.c

and its setup_graphics() that grabs the screen info part of boot params
and starts by zero-ing it:

si = _params->screen_info;
memset(si, 0, sizeof(*si));

before trying efi_setup_gop() and setup_uga() in turn; the former being
current, the latter being the old standard.

Moving on to:

drivers/firmware/efi/libstub/gop.c

we see that its efi_setup_gop() calls setup_gop(), which in turn calls
find_gop(). That last one gets hold of a suitable GOP pointer:
  
https://uefi.org/specs/UEFI/2.10/12_Protocols_Console_Support.html#graphics-output-protocol

The rest of setup_gop() then uses information contained within that
structure to derive all relevant information, filling the screen_info
structure. That structure is then trusted by efifb, which can do nothing
else but fail miserably…

The si (screen_info) is set starting here:
  
https://elixir.bootlin.com/linux/v6.1.27/source/drivers/firmware/efi/libstub/gop.c#L534

Adding some debug, here's what I get with GRUB set to 800x600x24:

info->version: 0
info->horizontal_resolution: 1024
info->vertical_resolution: 768
info->pixel_format: 1
  info->pixel_information.red_mask: 0
  info->pixel_information.green_mask: 0
  info->pixel_information.blue_mask: 0
  info->pixel_information.reserved_mask: 0
info->pixels_per_scan_line: 1024

Let's see:

 - Of course width, height, and pixels_per_scan_line are incorrect.

 - pixel_format 1 means PIXEL_BGR_RESERVED_8BIT_PER_COLOR aka
   PixelBlueGreenRedReserved8BitPerColor in the spec, which means:

   A pixel is 32-bits and byte zero represents blue, byte one
   represents green, byte two represents red, and byte three is
   reserved. This is the definition for the physical frame buffer.
   The byte values for the red, green, and blue components represent
   the color intensity. This color intensity value range from a
   minimum intensity of 0 to maximum intensity of 255.

 - And masks are all 0.

So for this particular GRUB configuration to work, I've verified that
fixing all those fields was leading to a correct display via efifb
(having dropped bochs.ko to stick to efifb):

info->horizontal_resolution = 800;
info->vertical_resolution   = 600;
info->pixels_per_scan_line  = 800;

info->pixel_format = PIXEL_BIT_MASK;
info->pixel_information.red_mask  = 0x00ff;
info->pixel_information.green_mask= 0xff00;
info->pixel_information.blue_mask = 0x00ff;
info->pixel_information.reserved_mask = 0x;

Setting PIXEL_BIT_MASK means masks become relevant, and bits set in
those are added to determine the actual color depth, instead of an
hardcoded 32, giving me (and efifb) 24. And even:

efifb: mode is 800x600x24, linelength=2400, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=0:8:8:8, shift=0:16:8:0

instead of the dreaded:

efifb: mode is 1024x768x32, linelength=4096, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

Now, where to go from here? It seems pretty clear to me at this point
that the Linux kernel only relies on information that was obtained via
that GOP pointer, and does its best afterward.

The way the function call works seems pretty similar to what happens in
GRUB, so I'd think that the problem is likely *not* in the kernel, but
rather:

 - GRUB fails to set mode information properly.

 - OVMF drops the ball and return some default information.


> Unfortunately, with Secure Boot we have to use a monolithic GRUB build
> so I can't easily exclude video_bochs and video_cirrus to see if that
> improves matters.

Applying my new pesign skills on GRUB is the next step, but I have to
spend some time on another topic before Bookworm… It it possible that
trying to build a debug-enabled OVMF package might yield interesting
results, since AFAIUI that's the one implementing the back and forth…
If that's indeed the case, it should be easy to see what's written by
GRUB vs. what's read by Linux?

Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)

[Andreas Tille]

Am Wed, May 17, 2023 at 02:07:22PM +0530 schrieb Nilesh Patra:
> On Wed, May 17, 2023 at 08:58:58AM +0200, Andreas Tille wrote:
> > I hope I was following developers reference about t-p-u[6] correctly
> > and pushed
> > I've choosen the version 1.7.4+dfsg-3~deb12u1 to match
> > the requirement that the version is lower than in unstable
> 
> I guess this should be alright. But as per devref, you may want to choose
> "1.7.4+dfsg-2+deb12u1".

This was my first consideration.  However, the changes simply fit to
1.7.4+dfsg-3 and by using the '~' separator the "smaller version than in
unstable" is fulfilled as well.  I don't mind much actually - just to
explain my choice.
 
> > I wonder whether dput is working with target distribution bookworm since
> > lintian  throws an error. 
> 
> It probably should. There's a d/ch entry I found for argon2 package
> here[7] in case that helps you.

Thanks for confirming.
 
> > Release team is in CC - do you think I should
> > file a bug right now or just after an upload?
> 
> devref says "Ask for authorization for uploading from the release
> managers."
> 
> So I suppose it makes sense to file a bug before you upload and ping
> them back again once you upload as per

Yepp, I'll do so and will ask what they consider the more sensible
version number.
 
> "After uploading and successful build on all platforms, contact the
> release team at debian-rele...@lists.debian.org and ask them to approve
> your upload."

Will do so.

Kind regards
   Andreas.

> > > > > [1] 
> > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz
> > > > > [2] 
> > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz
> > > > > [3] 
> > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz
> > > > > [4] 
> > > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/
> > > > [5] https://wiki.debian.org/TestingProposedUpdates
> > [6] 
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u
> [7] 
> https://tracker.debian.org/news/1429925/accepted-argon2-020171227-03deb12u1-source-into-testing-proposed-updates/
> 
> -- 
> Best,
> Nilesh



-- 
http://fam-tille.de

Bug#1030292: Cannot bind to privileged port

[Martin Argalas / CyberFoundry.net]

I have run into a similar strange issue as well.
After an uppgrade form Deb 11 bullseye to 12 bookworm my setup stopped 
working.

apt-cacher-ng fails to bind to a port higher than 32767.

Martin

--
On Thu, 02 Feb 2023 00:27:36 -0500 "Daniel Richard G." 
 wrote:

Package: apt-cacher-ng
Version: 3.7.4-1+b2
Severity: important

I want to run apt-cacher-ng on port 80 for a dedicated caching server.

After configuring via debconf to use that port, and restarting, nothing
is listening at localhost:80. I see the following in syslog:

2023-02-02T00:10:04.728949-05:00 image-debian64 systemd[1]: Starting 
apt-cacher-ng.service - Apt-Cacher NG software download proxy...
2023-02-02T00:10:04.740737-05:00 image-debian64 apt-cacher-ng[668]: 
Couldn't bind socket: Permission denied
2023-02-02T00:10:04.740858-05:00 image-debian64 apt-cacher-ng[668]: 
Couldn't bind socket: Permission denied
2023-02-02T00:10:04.743750-05:00 image-debian64 systemd[1]: Started 
apt-cacher-ng.service - Apt-Cacher NG software download proxy.

If this is a limitation of the current package, then it should be noted
in the documentation and debconf prompt.


--Daniel


--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1023585: loongarch64

[Maxonxie]

Dear brother, I thought the debian support for loong64 very good jobs 。 we will 
port our distro to loong64 for debian downstream. --  Regards, --Maxon


发自我的企业微信

Bug#1026812: rust-base64: please upgrade to branch v0.20

[Fabian Grünbichler]

with sequoia being released with base64 0.21 support, I will start
preparing updates for the crates below (at least those maintained by the
Rust team - coordinating with team members as necessary, of course).

I haven't decided yet whether uploading to experimental is the way to
go, or whether straight to unstable post-bookworm makes more sense.

I'll update this bug report accordingly.

Versions of rust-base64 in unstable:
  librust-base64-dev   0.13.0-1

Versions of rdeps of rust-base64 in unstable, that also exist in testing:
  librust-alacritty-terminal-dev   0.17.0-1 depends on  
   librust-base64-0.13+default-dev,
  librust-cargo-dev0.66.0-1 depends on  
   librust-base64-0.13+default-dev,
  librust-cookie-dev   0.16.0-1 depends on  
   librust-base64-0.13+default-dev,
  librust-fernet-dev   0.2.0+really0.1.4-2 depends 
on librust-base64-0.13+default-dev,
  librust-grep-printer-dev 0.1.6-1  depends on  
   librust-base64-0.13+default-dev,
  librust-jsonwebtoken-dev 8.2.0-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-oauth2-dev   4.3.0-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-pem-dev  1.0.2-1  depends on  
   librust-base64-0.13+default-dev,
  librust-plist-dev1.3.1-1  depends on  
   librust-base64-0.13+default-dev,
  librust-postgres-protocol-dev0.6.4-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-reqwest-dev  0.11.13-1depends on  
   librust-base64-0.13+default-dev,
  librust-ron-dev  0.7.1-1  depends on  
   librust-base64-0.13+default-dev,
  librust-ruma-common-dev  0.10.5-2 depends on  
   librust-base64-0.13+default-dev,
  librust-rust-argon2-dev  1.0.0-2  depends on  
   librust-base64-0.13+default-dev,
  librust-rustls-pemfile-dev   1.0.0-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-sequoia-autocrypt-dev0.24.0-1 depends on  
   librust-base64+default-dev (>= 0.12-~~),
  librust-sequoia-net-dev  0.25.0-2 depends on  
   librust-base64+default-dev (>= 0.12-~~),
  librust-sequoia-openpgp-dev  1.12.0-2 depends on  
   librust-base64-0.13+default-dev | librust-base64-0.12+default-dev,
  librust-sniffglue-dev0.15.0-3+b2  depends on  
   librust-base64-0.13+default-dev,
  librust-totp-rs-dev  3.0.1-2  depends on  
   librust-base64-0.13+default-dev,
  librust-transmission-client-dev  0.1.3-2  depends on  
   librust-base64-0.13+default-dev,
  librust-ureq-dev 2.6.2-3  depends on  
   librust-base64-0.13+default-dev,

Source packages in unstable whose autopkgtests are triggered by rust-base64:
  rust-base64ct1.5.1-1  triggered 
by librust-base64-dev=0.13.0-1
  rust-native-tls  0.2.11-1 triggered 
by librust-base64-dev=0.13.0-1
  rust-psa-crypto  0.9.2-2  triggered 
by librust-base64-dev=0.13.0-1
  rust-rustls  0.20.8-4 triggered 
by librust-base64-dev=0.13.0-1
  rust-ttf-parser  0.15.2-1 triggered 
by librust-base64-dev=0.13.0-1
  rust-webpki  0.22.0-1 triggered 
by librust-base64-dev=0.13.0-1

Bug#1036211: nss: support building without -Werror

[Helmut Grohne]

Source: nss
Version: 2:3.89-2
Severity: minor
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

every now and then nss, fails to build from source when built with the
next toolchain version due to employing -Werror by default. This is
unfortunate for architecture bootstrap, which tends to use bleeding edge
toolchains. An example of such a bug is #984258. As a consequence
debian-de...@lists.debian.org discussed ways around this limitation in
the thread at
https://lists.debian.org/debian-devel/2023/02/msg00276.html. The
conclusion was that passing -Wno-error via DEB_CFLAGS_APPEND was an
existing interface that should be easy enough to follow. As such, I am
asking nss to support this interface. Thus regular builds can continue
to default to -Werror while bootstrap builds have a standardized
mechanism to opt out of it. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru nss-3.89/debian/changelog nss-3.89/debian/changelog
--- nss-3.89/debian/changelog   2023-03-17 00:46:46.0 +0100
+++ nss-3.89/debian/changelog   2023-05-14 21:15:40.0 +0200
@@ -1,3 +1,10 @@
+nss (2:3.89-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support DEB_CFLAGS_APPEND=-Werror. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 14 May 2023 21:15:40 +0200
+
 nss (2:3.89-2) unstable; urgency=medium
 
   * nss/lib/ssl/sslinfo.c, nss/lib/ssl/sslt.h,
diff --minimal -Nru nss-3.89/debian/rules nss-3.89/debian/rules
--- nss-3.89/debian/rules   2022-08-23 23:57:38.0 +0200
+++ nss-3.89/debian/rules   2023-05-14 21:15:32.0 +0200
@@ -74,8 +74,9 @@
$(NULL)
 
 # Disable -Werror on less mainline architectures.
-ifneq (,$(filter-out i386 x86_64 aarch64,$(DEB_HOST_GNU_CPU)))
+ifneq (,$(filter-out i386 x86_64 aarch64,$(DEB_HOST_GNU_CPU))$(filter 
-Wno-error,$(CFLAGS)))
 COMMON_MAKE_FLAGS += NSS_ENABLE_WERROR=0
+CFLAGS := $(filter-out -Wno-error,$(CFLAGS))
 endif
 
 NSS_TOOLS := \

Bug#1036158: gcc-13: Please raise baseline for alpha to EV56

[John Paul Adrian Glaubitz]

Hi Michael!

On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
> On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> > After a long discussion on IRC and the mailing list, we have agreed to 
> > raise the
> > baseline for the alpha architecture to EV56 to improve the generated code 
> > and fix
> > a number of issues. The change is already being implemented in the glibc 
> > packages
> > which switches to EV56 [1] since hwcaps are no longer available with glibc 
> > 2.37 [2].
> > 
> > Could you raise the baseline for gcc on alpha to EV56?
> > 
> > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
> 
> Yes, please!
> 
> I suggest the following in debian/rules2:
> 
> ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
>   CONFARGS += --with-cpu=ev56 --with-tune=ev6
> endif
> 
> (the --with-tune only affects instruction scheduling and better tunes
> code for ev6 and more recent machines, but allows execution down to
> ev56.)  I have tested this in the past with a rebuild of most packages
> that are in the base essential chroot in the past and it works well.

Doesn't that come with a speed penalty for EV56 machines? I'm asking because 
EV56 is
currently the baseline for QEMU when emulating Alpha.

Adrian

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

Bug#1036210: unblock: android-platform-tools/29.0.6-28

[Emmanuel Bourg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: android-platform-to...@packages.debian.org
Control: affects -1 + src:android-platform-tools

Please unblock package android-platform-tools

This update fixes the RC bug #1034982



unblock android-platform-tools/29.0.6-28
diff --git a/debian/changelog b/debian/changelog
index 8511e438..c6844695 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+android-platform-tools (29.0.6-28) unstable; urgency=medium
+
+  * Team upload.
+  * Added the missing Replaces field for android-libnativehelper
+(Closes: #1034982)
+
+ -- Emmanuel Bourg   Wed, 17 May 2023 09:45:36 +0200
+
 android-platform-tools (29.0.6-27) unstable; urgency=medium
 
   [ Chirayu Desai ]
diff --git a/debian/control b/debian/control
index 11db424a..c0bacf63 100644
--- a/debian/control
+++ b/debian/control
@@ -270,6 +270,7 @@ Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends},
  android-liblog (= 1:${binary:Version}),
 Breaks: android-libnativehelper-dev (<< 29)
+Replaces: android-libnativehelper-dev (<< 29)
 Description: Support functions for Android's class libraries
  libnativehelper is a collection of JNI related utilities used in
  Android.
@@ -287,8 +288,8 @@ Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends},
  android-libnativehelper (= ${binary:Version}),
-Breaks: android-libnativehelper (<< 29)
-Replaces: android-libnativehelper (<< 29)
+Breaks: android-libnativehelper (<< 10.0.0+r36-1~)
+Replaces: android-libnativehelper (<< 10.0.0+r36-1~)
 Description: Support functions for Android's class libraries - Development 
files
  libnativehelper is a collection of JNI related utilities used in
  Android.

Bug#1036209: French update translation of tryton-server debconf

[bubub]

Package: tryton-server
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the french updated translation of tryton-server
debconf-po,
proofread by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

greetings,   bubu

fr.po.xz
Description: application/xz

Bug#1036208: [INTL:fr] Initial French translation of debconf steam-installer

[bubub]

Package: steam-installer
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the french translation of steam-installer po-debconf,
proofread by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

greetings,   bubu

fr.po.xz
Description: application/xz

Bug#1035972: isc-dhcp EOL'ed

[Moritz Muehlenhoff]

On Fri, May 12, 2023 at 08:58:01AM +, Holger Levsen wrote:
> On Fri, May 12, 2023 at 10:08:52AM +0200, Raphael Hertzog wrote:
> > > ISC is not longer maintaing any of the components of isc-dhcp (client,
> > > I propose to mark it as unsupported. Or at least, limited, if we still
> > > have hope in those security update exceptions they claim they could do.
> [...]
> > It's not a service to our users to claim that we will not support them.
> [...]
> > But I'm afraid that we will have to keep maintaining those for the benefit
> > of our stable/oldstable (and even ELTS) users. I'm pretty sure that all
> > the other distributions will also continue to maintain those packages for
> > the lifetime of their respective releases so that we will have
> > opportunities to share the workload and patches.

Agreed.

> Given what Raphael wrote, should this bug maybe be about marking isc-dhcp
> unsupported in trixie?

My take would be to mark it as unsupported after the trixie development cycle
has started (this flags awareness, but has no impact on stable releases)
and then revisit the support situation before the trixie freeze (Kea might be
a full replacment by then or maybe it turns out the patch support is ensured
despite upstream's EOL)

Cheers,
Moritz

Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)

[Nilesh Patra]

On Wed, May 17, 2023 at 08:58:58AM +0200, Andreas Tille wrote:
> Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra:
> > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote:
> > > I personally prefer "1" over 2 as it is less noise (and effort).
> > 
> > On second thoughts, I think sending it via testing-proposed-updates
> > would be a better thing to do, as this case perfectly fits the problem.
> 
> I hope I was following developers reference about t-p-u[6] correctly
> and pushed
> I've choosen the version 1.7.4+dfsg-3~deb12u1 to match
> the requirement that the version is lower than in unstable

I guess this should be alright. But as per devref, you may want to choose
"1.7.4+dfsg-2+deb12u1".

> I wonder whether dput is working with target distribution bookworm since
> lintian  throws an error. 

It probably should. There's a d/ch entry I found for argon2 package
here[7] in case that helps you.

> Release team is in CC - do you think I should
> file a bug right now or just after an upload?

devref says "Ask for authorization for uploading from the release
managers."

So I suppose it makes sense to file a bug before you upload and ping
them back again once you upload as per

"After uploading and successful build on all platforms, contact the
release team at debian-rele...@lists.debian.org and ask them to approve
your upload."

> > > > [1] 
> > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz
> > > > [2] 
> > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz
> > > > [3] 
> > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz
> > > > [4] 
> > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/
> > > [5] https://wiki.debian.org/TestingProposedUpdates
> [6] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u
[7] 
https://tracker.debian.org/news/1429925/accepted-argon2-020171227-03deb12u1-source-into-testing-proposed-updates/

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium

[Christoph Berg]

> === BEGIN
> 
> OPTION A:
> 
> Under Constitution 6.1.5, the Technical Committee recommends that the
> maintainers of individual packages should not proactively move files
> from the root filesystem to corresponding locations under /usr in the
> data.tar.* of packages.  So, /foo/bar should not move to /usr/foo/bar.
> 
> Files that are in /usr in the Debian 12 release should remain in /usr,
> while files that are in /bin, /lib* or /sbin in the Debian 12 release
> should remain in those directories.  If any files are moved from /bin,
> /lib* or /sbin into /usr after the Debian 12 release, they should be
> moved back to their Debian 12 locations.
> 
> This moratorium lasts until we vote to repeal it.  We expect to do that
> during the trixie development cycle, and sooner rather than later.
> We will continue to facilitate efforts to resolve the remaining issues
> that stand in the way of safely repealing the moratorium.
> 
> OPTION B:
> 
> As option A, except that only maintainers of essential and transitively
> essential packages should refrain from proactively moving files from the
> root filesystem to corresponding locations under /usr in the data.tar.*
> of packages.
> 
> OPTION N:
> 
> None of the above.
> 
> === END

I vote A > B > N.

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#1035843: unblock: jed/0.99.20~pre.178+dfsg-4

[Rafael Laboissière]

Control: tags -1 - moreinfo

* Paul Gevers  [2023-05-15 21:11]:


Control: tags -1 moreinfo

On 10-05-2023 07:33, Rafael Laboissière wrote:

The version in unstable fixes the RC bug #1035839. I introduced a
regression in the d/jed-common.preinst script when I tried to fix
Bug#1035780.


And a new RC bug against the version in unstable got filed today. 
Please remove the moreinfo tag once that bug has been triaged and/or 
fixed.


Bug#1036096 is fixed in version 0.99.20~pre.178+dfsg-5, now in unstable.

I am hereby removing the moreinfo tag, as you suggested. Please, tell me 
whether anything else should be done to unblock the jed package.


Thanks,

Rafael

Bug#1036154: Temporary fix - issue connected with [DSA 5340-1] webkit2gtk security update?

[Matthias Kirschner]

Hello Alberto,

* Alberto Garcia [2023-05-17 08:45 +0200]:
> https://github.com/astroidmail/astroid/issues/720
>
> And yes, it is unfortunately related to the webkit2gtk upgrade.
> 
> The good news is that it can be worked around locally without having to
> modify the astroid package (although it's a good idea to do that
> anyway).

Thank you Berto for the pointer to the local fix. 

Best regards,
Matthias

-- 
Matthias Kirschner - President - Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290
Registered at Amtsgericht Hamburg, VR 17030  |(fsfe.org/support)
Contact (fsfe.org/about/kirschner)   Weblog k7r.eu/blog.html


pgpKXwHoyhD2F.pgp
Description: PGP signature

Bug#1036207: RFS: javamail/1.6.5-2 [Team] -- JavaMail API Reference Implementation (documentation)

[sun min]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : javamail
   Version  : 1.6.5-2
   Upstream contact : [fill in name and email of upstream]
* URL  : https://jakartaee.github.io/mail-api
* License  : BSD-3-clause, EPL-2.0 or GPL-2 with Classpath exception
* Vcs  : https://salsa.debian.org/java-team/javamail
   Section  : java

The source builds the following binary packages:

  libmail-java - JavaMail API Reference Implementation
  libmail-java-doc - JavaMail API Reference Implementation (documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/j/javamail/javamail_1.6.5-2.dsc

Changes since the last upload:

javamail (1.6.5-2) experimental; urgency=medium
.
   * Team upload.
   * Fix ftbfs bug (Closes: #1036206)
   * Update upstream homepage (Closes: #1033247)


Best wishes,
--
sun min

Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)

[Andreas Tille]

Hi again,

Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra:
> On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote:
> > I personally prefer "1" over 2 as it is less noise (and effort).
> 
> On second thoughts, I think sending it via testing-proposed-updates
> would be a better thing to do, as this case perfectly fits the problem.

I hope I was following developers reference about t-p-u[6] correctly
and pushed

$ git diff HEAD^
diff --git a/debian/changelog b/debian/changelog
index 21d12c3..a2b6c26 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+r-cran-shiny (1.7.4+dfsg-3~deb12u1) bookworm; urgency=medium
+
+  * Upload to testing-proposed-updates "bookworm" due to the fact that
+there was an accidental upload of a new version of r-base to unstable
+
+ -- Andreas Tille   Wed, 17 May 2023 07:56:25 +0200
+
 r-cran-shiny (1.7.4+dfsg-3) unstable; urgency=medium
 
   * Fix link for normalize.css


to git.  I've choosen the version 1.7.4+dfsg-3~deb12u1 to match
the requirement that the version is lower than in unstable

$ if dpkg --compare-versions 1.7.4+dfsg-3 gt 1.7.4+dfsg-3~deb12u1 ; then echo 
"OK" ; else echo "hmmm" ; fi
OK

I wonder whether dput is working with target distribution bookworm since
lintian  throws an error.  Release team is in CC - do you think I should
file a bug right now or just after an upload?

Kind regards
Andreas. 
 
> > > [1] 
> > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz
> > > [2] 
> > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz
> > > [3] 
> > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz
> > > [4] 
> > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/
> > [5] https://wiki.debian.org/TestingProposedUpdates
[6] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u


-- 
http://fam-tille.de

Bug#1036154: Temporary fix - issue connected with [DSA 5340-1] webkit2gtk security update?

[Alberto Garcia]

On Tue, May 16, 2023 at 04:21:29PM +0200, Matthias Kirschner wrote:
> (Added Alberto in CC, as the issue might be connected with the
> webkit2gtk security update:
> https://lists.debian.org/debian-security-announce/2023/msg00029.html )

I think that it is this upstream bug:

https://github.com/astroidmail/astroid/issues/720

And yes, it is unfortunately related to the webkit2gtk upgrade.

The good news is that it can be worked around locally without having to
modify the astroid package (although it's a good idea to do that
anyway).

Berto

Bug#1036206: ftbfs: error: not in a module on the module source path

[sun min]

Source: javamail
Version: 1.6.5-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

This package failed to build from source, there are a lot of error saying:

"error: not in a module on the module source path"

Best wishes,
--
sun min